《从0开始学产品策划》第三期：需求不是终点，而是起点（下）

编者注:第一部分章节发布之后，许多同学都在后台提出了许多好问题，我们会从中选取一部分，邀请胡澈进行回答，请各位继续关注我们的连载。

本章主要讲解了需求是如何诞生这个话题，欢迎分享到朋友圈并积极讨论。

关注市场发展

无论是什么样的产品，如果不推向市场，那就不能称之为真正意义上的产品。在日常的市场分析和用户调研中，常常会出现很有趣的一幕：产品经理经过一系列的调研，发现市场巨大，用户都十分欢迎自己的产品，而且好像没有什么竞争对手。这真让人兴奋！但实际上，永远不要相信没有竞争对手这回事，很多时候往往是因为你在搜集信息的时候忽略了一些关键信息，或者是调研的内容不够全面，没有及时发现竞争对手的踪迹。如果没有比较好的工具，产品经理对市场的预测和用户需求的调研时常会陷入自己设立的陷阱——夸大了市场。

虽然大部分时候，产品经理不需要专职做市场分析的事情，但产品经理可以花时间去了解市场动向和用户，这是一件多么有价值的事情。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，有的来自测试。参与的人越多，意见就越不容易统一，产品方案最后往往就变成了一个大家的产物，但谁对这个被修改多次的方案负责呢？

产品经理不得不负责这个方案（满怀着大家的期待，多次争论的产物），然后去说服设计师，说服工程师……方案常常会变成一个大家都喜欢但是奇怪的方案。适度妥协方案是常见的现象，但如果产品经理对于别人的评审意见照收不误，最后出来的方案会变成四不像，但因为项目的要求开发工程师会尽快开发，谁知道后续还会出现什么“黑天鹅”事件，很有可能最后开发出来的效果不是产品经理想要的，也不是用户想要的。

对于这个评审过程，我称之为需求难产。如果每次需求都遭遇这样那样的问题，如果每次需求最后都变成了众人评审妥协的方案，那么对于产品经理来说就是个灾难。我们可以做些什么来确保方案始终是为用户设计的方案呢？不如试一试下面的一些方法。

●尽快确认产品原则，在评审之前就告知所有相关人员，确保产品经理和其他人原则一致。

●产品经理要思考清楚自己的方案，以便随时应对别人的挑战。

●往往在只有一个方案时（尽管是最佳的方案）最容易受到挑战。所以产品经理一开始就可以多考虑出几套方案。当评审人员了解了多个方案之后，自然会做出最佳的选择。

●有效地引导评审人员认可产品经理最想实现的方案。对产品经理来说，最难过的一关就是老板的挑战。老板往往会有很多的想法和需求想要在这个方案中被满足，产品经理要学会控制老板的预期和需求，引导老板认可自己的方案。最简单的莫过于同时推荐几套方案，让老板自己选择。通过对比，老板会认可产品经理的方案。

●提前和相关的设计师、开发者定好方案，避免他们对方案的调整一无所知。

●最好可以提前和用户研究员一起沟通方案，了解在方案实现过程中有可能需要关注的数据。产品经理善用数据是专业度的体现。