|
|
编者注：第一部分章节发布之后，许多同学都在后台提出了许多好问题，我们会从中选取一部分，邀请胡澈进行回答，请各位继续关注我们的连载。
相关：认清项目本质【从0开始学产品策划 ①】
从失败到成功【从0开始学产品策划④】
产品需求沟通出问题怎么办？【从0开始学产品策划⑤】
如何有效地通过项目把握用户预期【从0开始学产品策划⑥】
通过人物角色了解用户期望【从0开始学产品策划⑦
产品经理如何防止事情变糟？【从0开始学产品策划⑧】
本章主要讲解了需求是如何诞生这个话题，欢迎分享到朋友圈并积极讨论。
在经过如此漫长的阅读旅途之后，欢迎各位有志成为产品经理的朋友来到这一小节。别担心我们即将上路会带来的紧张，事实上，当你阅读完前面铺垫的章节，已经走在了成为产品经理的路上。而接下来，抛却理论性的分析和描述，我将从项目需求写起。请记住：需求不是终点，而是起点。
如果把产品看成是产品经理的孩子，难免会和许多父母一样担心“输在起跑线”上。就好像脑子中冒出了许多好点子的人，时刻担心自己的点子被别人抢先实现了。实际上，这些战略层面的事情还不是最应该考虑的问题，对于一个项目来说，真正需要关注的意义是开始，当项目正式启动了之后，是否可以按照Roadmap 进行，各个环节和相关人员是否可以保证质量？而项目最开始就要求产品经理提供本次迭代的Feature List，并及时提供需求文档给开发团队、设计团队及测试团队。因此，项目开始的时候，产品经理的压力会非常大。
Feature List 的来源是需求，而需求的来源有很多：用户、产品经理、老板……与其说人人都是产品经理，不如说人人都有需求。因此，一开始产品经理需要做的是搜集各方的需求。通过搜集对应的需求，产品经理可以有效地进行需求管理，准确评估需求的优先级，然后根据所选择的需求思考对应的功能方案。
一个需求的诞生就是如此简单。
一个需求的诞生
上文所述是刚入门产品经理时的我对于需求的理解。随着经历的项目越来越多，发布的产品版本也越来越多，我深刻地感受到产品需求并非只是简单地积累、筛选、排优先级这么简单。正如蓝图之于摩天大楼一般，需求的规划决定了这个产品的发展方向——是成为平庸的产品，还是成为优秀的产品；是迎合主流群体，还是迎合特定人群；是专注一个方向，还是四处出击。对于产品经理来说，需求与孩子不同，我们可以等他出生后再思考如何培养这个孩子，而需求则从一开始就要考虑后续的发展。
一般来说，产品经理可以将整个项目分为两个阶段。
- 探索产品：产品经理需要清楚产品的规划和发展。
- 执行计划：推动开发进度，让功能尽快实现。
探索产品就是管理需求的过程。产品经理不仅需要到处搜集产品需求，还要明确自己及整个产品团队对于产品的阶段性目标和长期目标，明确产品功能的定位，从全局视角出发思考产品方向。除了关注眼前，还要考虑市场的发展。市场并非是一成不变的，而是在发生着日新月异的变化，今天流行的产品可能就是明日黄花。用户是流动的群体，他们追求好用的产品，而不是固守成规，成为过时产品的拥趸。虽然产品经理不用考虑太多技术方面的问题，但产品的拓展性及方案的实现需要被有效管理。
明确产品定位及目标
虽然人人都在说需求，每个人都可以说出几个痛点来，但产品并非一开始就为了不断修补体验。产品应该有自己的性格，而这种“人格化”的内涵，是产品经理赋予的。乔布斯崇善“NO BUTTON”，才有了iPhone 的设计；贝索斯耐得住寂寞，追求长远目标，才会掏钱设置一个“万年钟”（Long Now Foundation）。
我在写作这本书之前，就一直在思考本书的目标和定位是什么。产品经理这一行其实存在这样一种现象，产品经理与产品经理之间很难直观地进行对比，尤其是优秀的产品经理更难分出高低。如果像金庸小说中描述的那样，举办一场产品经理的“华山论剑”，估计三天三夜也比不出个孰高孰低。我认为，对于产品经理来说，业务能力熟练程度的差距真的不是特别明显，但对于产品的领悟力则很容易出现很大的差距——幸好，大部分大公司的产品经理不需要太多领悟。有老板在做决策，有极强的执行力也是优秀的一种体现。
而我内心怀有一种情结，正如彼得•德鲁克所说：企业家精神。什么是企业家精神？创新是企业家特有的工具。凭借创新，他们将变化看作是开创另一个企业或服务的机遇。企业家必须有目的地寻找创新的来源，寻找预示成功创新机会的变化和征兆。产品经理应该是具备企业家精神的人，勇于寻找创新的来源，通过不断地探索，找到更好的产品解决方案。他们不仅可以大幅度地提高资源产出比，而且可以努力开创新市场和新用户群，尽力满足他们的需求。
因此，我把我的想法聚合成这样一个产品，灌入企业家精神及创新的源泉，希望通过另一种视角去讲述产品经理成长的故事。我曾经想写关于我这两年的所见所闻、所思所得，写一本名为“产品经理日记”的书，但大部分时候，这种缺乏条理的描述对于想要成为产品经理的入门者来说，难免有点看小说的意思；而接下来几年，对于初入门的产品经理来说，业务能力和对于整个产品研发流程的熟练掌握才是重点。因此，我把此书定义为：产品经理的第一本书。不需要太多生涩的道理，而应该像三字经一样，方便刚入门和未入门的人学习理解。
正是基于这样的考虑，我决定多加入一些人文视角，弱化技术视角，即通过日常的事物去描述做产品的“道”与“术”，而非像一本严肃的教科书絮絮叨叨地说着各种技术名词和概念。做产品应该是快乐的。我在写作此书的过程中虽然极度痛苦，不仅要考虑日常工作的压力，每天把下班时间都花费在这个产品上，还要时常面临思路不畅、缪斯女神离我而去的情况，但当我描绘做产品的分分秒秒时，我发现自己其实在不断地学习和成长，把自己所学所知整理出来，不仅能提升写作能力，对于产品的感悟也会越来越深刻。
所以，产品一定带有产品经理的性格，而不是不断累加需求生成的乐高积木。产品经理在一开始就应该想清楚，我需要做一款什么样的产品，要有哪些功能，满足哪些需求，服务于哪些用户，最关键的是在探索产品的过程中，我是否有一个基本的产品原则？有了一个比较明确的产品原则，需求的优先级才有筛选和比较的意义。
那么如何定义一个产品原则呢？虽然网上时常有一些文章分享产品设计的原则，但我宁愿称之为方法，而不是原则。如果把产品拟人化，产品原则应该体现产品的三观。
- 价值观：哪些能做，哪些不能做？
- 世界观：我们要满足用户的哪些核心需求？
- 产品观（人生观）：产品需要什么样的生态环境？
哪些能做，哪些不能做？条条大路通罗马，产品想要成功自然也少不了一些捷径。恰如虚竹凭借逍遥子百年功力，从小沙弥成长为逍遥派掌门；萧峰从小刻苦练习，锻炼出阳刚内力；而段誉误打误撞学习了“北冥神功”，专门吸取别人的内力。做产品一样会有类似的问题，所以Google 的名言是“不作恶”（Don’t beevil）。产品经理除了要有道德操守之外，还要明确一点：尊重用户。
我们要满足用户的哪些核心需求？其实这句话有问题，我们不需要满足用户的“哪些”核心需求，只需要满足“一个”。每一个产品都有一个核心场景，而核心场景下会有一个最需要被满足的需求。如果有其他需求和这个核心需求不相关，甚至影响这个需求的满足，那么这些需求都应该先被搁置，专心把资源投入到一开始就定义好的核心需求上。一般来说，建议产品经理在探索产品的时候专注于满足一个需求即可，然后再考虑从核心需求出发进行拓展。这样做，不仅容易锁定核心用户群，而且容易形成有效的产品原则，也便于在后续的产品开发过程中使所有人员都保持一致的目标。
产品需要什么样的生态环境？市场竞争激烈，产品层出不穷，恰如白垩纪时代，巨型恐龙横行但却遭遇天灾，无法继续生存；小型哺乳动物则因为身体具备恒温特性，而且身材小，热量流失较少，帮助它们在黑夜和寒冷下存活。产品如何在某个生态环境下生存发展，是每个产品经理都需要考虑的问题。正如很多学生在高考结束之后都不清楚自己要去哪所学校、哪个专业一样，眼瞅着计算机专业热门，结果几年后大量计算机专业毕业生狭路相逢；考量着金融贸易是今后的重头戏，结果一毕业就遭遇了金融危机，只能感慨就业形势严峻。产品经理在一开始给产品进行定位并设立产品原则时，就必须考虑到后续的发展。
当然，产品经理需要根据当时环境做出最佳决策。最佳的决策可能不是最好的决策。例如，一个网站一开始就要求完美拓展的架构，可以同时承载一百万人的后台服务，最佳的容灾策略……这是典型的脱离实际。产品经理需要看到几年后的发展，也需要关注眼下的情况。没有最完美，只有最适合。
定义了基本的产品原则之后，我相信大部分产品经理都会从中受益。在接下来的产品宣讲和开发过程中，产品经理不需要多次重复产品方向，也不需要犹豫是否做成决策。因为产品原则就好像一个标尺，可以在产品经理做决策的过程中起到度量的作用。
除了产品原则之外，产品经理最好定义一下每个原则的优先级。有的时候，虽然大家的方向一致，但是在实际的操作过程中，常常出现具体细节上的分歧。
大部分时候虽然大家都尊重基本的产品原则，但每个人都会有自己的观点，他们认为自己的想法是正确的。不仅如此，每个人都从自己的视角出发，就会出现观念上的差异，尤其痛苦的是每个人都觉得自己是用户，而其他伙伴的方案都没有满足自己的需求。这时就体现了产品原则优先级的重要意义，如果一开始就已经把对应的优先级定义好，大家按照这个优先级来解决问题，或许会顺利很多。不过，在项目过程中会出现一些沟通上的问题，为了方案而争论是个好事情，可以把一些场景讨论得更加清楚——但请记住，无论如何，产品经理一定要在会议和讨论上进行有效地管理，按照《罗伯特议事规则》来提高会议的价值。产品经理要倾听，要快速找到争论的关键点并进行解答，及时把天马行空的伙伴拉回到现实，总结出一个最佳的方案。
关注市场发展
无论是什么样的产品，如果不推向市场，那就不能称之为真正意义上的产品。在日常的市场分析和用户调研中，常常会出现很有趣的一幕：产品经理经过一系列的调研，发现市场巨大，用户都十分欢迎自己的产品，而且好像没有什么竞争对手。这真让人兴奋！但实际上，永远不要相信没有竞争对手这回事，很多时候往往是因为你在搜集信息的时候忽略了一些关键信息，或者是调研的内容不够全面，没有及时发现竞争对手的踪迹。如果没有比较好的工具，产品经理对市场的预测和用户需求的调研时常会陷入自己设立的陷阱——夸大了市场。
虽然大部分时候，产品经理不需要专职做市场分析的事情，但产品经理可以花时间去了解市场动向和用户，这是一件多么有价值的事情。QQ 空间的专家工程师Stone 是一个非常关注用户的人，他有一个有趣的习惯：时常会去百度等搜索引擎输入“为什么”三个字。因为大部分搜索引擎都有自动关键词智能提示，所以就可以看到以“为什么”开头的一些热门问题。通过搜索引擎的用户行为去分析市场和用户需求，真是一个让人称赞的做法！
接下来介绍一下我了解的市场调研方法，可能会比较粗糙，但希望能抛砖引玉，供大家一阅。
用户调研问卷：问卷虽然看起来是一种朴实无华甚至漏洞百出的方法，但因成本低、效果也还可以使其成为众多公司最喜爱的调研方法。使用调研问卷的关键是题目和题型的设计，要保证被调查者大部分时候都能按照事实反应，而不是随意填写，否则容易出现废卷。
数据搜索：市场上有如此多的第三方咨询公司，他们的报告都是非常有价值的参考资料。如果有更多的成本投入，可以考虑长期使用付费的服务，随时方便地查询智库文档，可以从中找到许多优秀的报告。
产品测试：Dropbox曾经做过一个有意思的试验：他们在产品开发之前先建立了一个网站，并通过一个概念包装吸引了种子用户，通过种子用户的数量，他们准确判断了云储存市场的前景。
在Dropbox 早期的种子用户获取阶段，经历过两次用户小规模爆发阶段。一次是配合产品的演示视频加内测邀请的活动，在网站首页上面嵌入了一个演示的视频，一句鼓励人们留下Email 的文案，以及一个可以注册邮箱的输入框（LandingPage在这里）。配合着这个登录页面，以及之后在Hacker News 论坛上面发布的帖子，Dropbox 获得了第一波用户。
Dropbox 的第二波用户来自 Digg。2008 年3 月11 日，在登上了Digg 之后，Dropbox 因为瞬间大流量进入，造成服务器宕机。而这一次的报道，为Dropbox带来的效果是超出预期的，登记排队的用户数在一天之内从5000 上升到了75000。
如果从Dropbox 两年（已达到400 万用户数）的发展历程来看，这两次的效果仅是其用户数增长曲线上面一段小小的曲线。但是，从这两个网站（HN 和Digg）上面过来的用户，因为具备极客精神、勇于尝鲜的态度，以及可以接受不完美科技产品的宽容性格，成为了 Dropbox 在接下来的迭代和测试过程中的风向标。而更重要的是，在这个过程中，Dropbox 的团队左手抓用户数量的发展，右手抓产品功能的专注，通过有“节制”的定位，将产品的气质一直维持在一个微妙的平衡点上。——摘自ifanr
Dropbox 的试验非常值得学习。这种测试方法不仅有效地了解了用户对于产品价值的认可，并且可以很快速地评估市场机会和规模，cool！
竞争对手分析
别小看竞争对手产品的作用，别人的失败或者成功经验，都是产品经理值得参考的信息。为什么他们会失败？是因为对用户需求的理解有问题，还是因为市场饱和了？是产品策略有问题，还是核心用户找错了？如果产品经理可以分析这些问题，就可以快速地找到竞争对手做得不好的地方，而这有可能就是市场的机会。
还有许多有效的方法可以帮助产品经理分析市场、了解用户，但一定要了解产品的目标，善于发现机会。产品目标是多次谈及的话题，如果产品经理失去了目标，那绝对是糟糕的事情。发现机会则是在考验产品经理的嗅觉。善用信息的产品经理可以从信息中挖掘出许多有价值的机会。
无论如何，了解你的用户才是最根本的，难道不是吗？
对技术方案的关注
关注技术方案并非是要和工程师探讨方案的实现，也不是要越过边界对工程师指手画脚。产品经理关心技术方案是为了确认需求的实现，虽然已经进行了文档沟通和当面沟通，但有一些需求细节仍可能未沟通清楚，容易造成误解。如果找工程师了解技术方案，就能比较容易地达成一致的理解，确保后续工作有条不紊地进行。
了解技术方案不仅能方便双方理解需求，更能方便产品经理及时预估风险。根据需求复杂度的不同，项目的开发资源常常得不到最好的支持，产品经理一开始就应该把所有相关人员都召集到一起，制定好基本的方案，确认每个环节都有人认领，大家都达成一致的理解。如果可以提前安排好排期和联调时间，那真是再好不过的事情。
不过在实际方案的制定过程中，还会出现很多意外情况，最常见的一种就是如何对多个技术方案取舍，并确保每个工程师都认可。因为客户端和后台经常会有一些技术方案上的灰色地带，有些工程师为了减轻自己的压力，常常会推荐最佳方案之外的另一套方案。这时，如果产品经理了解技术方案就可以做出恰当的决策。
如果产品经理对技术比较了解，和工程师交流时会更加方便，尤其是当自己希望加入一些锦上添花的元素时，可以和工程师一起讨论需求，以及如何将它做得更加完美——对于工程师来说，将产品做得足够有趣和有用也是他们所追求的目标。
PK！需求难产怎么办
制定了产品原则，了解了用户画像，沟通了技术方案，这时需求就可以直接变成文档交付给开发工程师了吗？在一个常见的产品研发流程中有一个阶段叫作产品需求评审。这种评审是有多方介入的，但最关键的是产品经理团队内部如何明确需求的方案和优先级。毕竟开发资源比较有限，产品版本规划需要有对应的目标。
正如Marty Cagan在《启示录》一书中曾提到过的一个概念：产品评审团，其目标是更好更快地做出可靠的产品决策。腾讯亦有这种流程。产品负责人每周都会聚在一起，集中讨论接下来的发展计划和产品规划。在这个漫长的会议上，会诞生产品的版本规划和阶段性目标，同时明确Feature List 中每个功能的优先级。明确了优先级之后，产品经理就需要把需求转化成方案。大部分时候，需求变成功能方案要经历这样一个过程。
1、产品经理和交互设计师先进行沟通，输出基本的方案。
2、产品经理用交互稿和需求文档向上级汇报具体方案。
3、召集开发工程师和测试工程师，正式宣讲需求，交互稿则交给视觉设计师进行设计排期。
这三个阶段是产品经理遭遇PK 最多的时候，需要和交互设计师PK 哪个交互方案更佳，需要和上级讨论方案可行性，需要和工程师沟通需求详情和实现。写到这儿，我想起了电影《勇敢的心》中，梅尔•吉布森饰演的华莱士带领苏格兰人大吼：“Are you ready for a war？”
当然这样说有点夸张，但是产品经理在方案细化的过程中的确需要不断地和别人PK。毕竟，产品经理最懂用户，最了解用户的需求点；产品经理应该知道用户喜欢什么样的设计，需要在设计感和实用性之间找到一个平衡点；产品经理可以和工程师探讨技术方案的实现，找到实现需求功能的最佳方案。
因此，产品经理需要不断地和不同角色的人沟通功能的目标和效果。人与人的沟通是很有趣的事情，尤其是与设计师、工程师这种专业领域的伙伴，他们怀有专业的知识体系和理念，有各自的目标和审美，而产品经理如果缺乏决策力，很容易做出一个不令人满意的方案。如果产品经理缺乏影响力，则合作的伙伴们就很难接受方案。在专业度和用户体验方面进行权衡，是产品经理需求PK 的关键。
对于产品经理来说，这三个评审阶段是非常有价值的。因此产品经理可以通过了解其他人的反馈来调整方案，并找到更好的解决方案。对产品经理来说，有效地结合其他产品经理、设计师、工程师的建议，并对原有方案进行优化、评审和PK，是非常有价值的。
但产品经理一定要在评审之前就明确自己的观点、方案的可行性和坚持的理由。如果一个产品经理足够自信，在评审过程中就很容易获得其他人的认可，产生影响力。
反之，如果产品经理在评审阶段依然没有足够的自信和对方案的足够熟悉，那么其他人会觉得你没有想清楚这个方案，或者是缺乏信心去说服别人采用自己的方案，这常常会引起工程师和设计师对于产品经理能力的不认可，减弱产品经理自身的影响力。
随着产品评审流程的进行，产品经理常常会收获许多意见，有的来自老板，有的来自资深设计师，有点来自开发Leader，有的来自测试。参与的人越多，意见就越不容易统一，产品方案最后往往就变成了一个大家的产物，但谁对这个被修改多次的方案负责呢？
产品经理不得不负责这个方案（满怀着大家的期待，多次争论的产物），然后去说服设计师，说服工程师……方案常常会变成一个大家都喜欢但是奇怪的方案。适度妥协方案是常见的现象，但如果产品经理对于别人的评审意见照收不误，最后出来的方案会变成四不像，但因为项目的要求开发工程师会尽快开发，谁知道后续还会出现什么“黑天鹅”事件，很有可能最后开发出来的效果不是产品经理想要的，也不是用户想要的。
对于这个评审过程，我称之为需求难产。如果每次需求都遭遇这样那样的问题，如果每次需求最后都变成了众人评审妥协的方案，那么对于产品经理来说就是个灾难。我们可以做些什么来确保方案始终是为用户设计的方案呢？不如试一试下面的一些方法。
●尽快确认产品原则，在评审之前就告知所有相关人员，确保产品经理和其他人原则一致。
●产品经理要思考清楚自己的方案，以便随时应对别人的挑战。
●往往在只有一个方案时（尽管是最佳的方案）最容易受到挑战。所以产品经理一开始就可以多考虑出几套方案。当评审人员了解了多个方案之后，自然会做出最佳的选择。
●有效地引导评审人员认可产品经理最想实现的方案。对产品经理来说，最难过的一关就是老板的挑战。老板往往会有很多的想法和需求想要在这个方案中被满足，产品经理要学会控制老板的预期和需求，引导老板认可自己的方案。最简单的莫过于同时推荐几套方案，让老板自己选择。通过对比，老板会认可产品经理的方案。
●提前和相关的设计师、开发者定好方案，避免他们对方案的调整一无所知。
●最好可以提前和用户研究员一起沟通方案，了解在方案实现过程中有可能需要关注的数据。产品经理善用数据是专业度的体现。
相关：认清项目本质【从0开始学产品策划 ①】
需求不是终点，而是起点【从0开始学产品策划②\③】
从失败到成功【从0开始学产品策划④】
via：腾讯大讲堂
|
|
发表于 2014-11-7 00:37:41
发表于 2014-11-7 11:48:46