接着上篇《搭讪是产品经理的基本功，需求管理也是！（上）》来继续讲需求管理。

经过对产品定位的梳理，我们总算明确了产品的目标用户群体，接下来就可以开始进行需求的收集、分析活动了，总体流程包含这么几个部分：需求的收集——需求的分析和筛选——需求优先级排序。

需求收集——5种需求来源

不同规模的公司，在需求收集这个环节所使用的方法也不尽相同。这是因为需求收集这件事情本身是会耗费成本的（时间成本、人力成本、资金成本），而处在不同阶段的互联网公司，自然而然对待成本的态度不同。创业型公司一般来说，都倾向于使用低成本的需求收集方式（少数融资数轮的土豪公司除外），而大公司则会有比较专业的用户研究团队等来做相关方面的需求收集工作。

在我经历的项目实践中，需求采集的方式主要有以下几种，如图所示：

1、用户调研

用户调研是通过问卷调查、用户访谈、行业数据报告等手段来收集需求的方式。

通常来说，用户访谈和问卷调查需要结合起来使用，它们分别从定性和定量的两个角度去了解用户需求。用户访谈的提纲通常是开放式问题，适合与较少的访谈对象进行深入交流；而调查问卷则封闭式问题比较多，适合大用户量的信息收集，但不够深入。我通常的做法是先做用户访谈，了解用户大概比较关注的一些点，然后据此来设计问卷。

用户访谈是最常用的方法，主要形式是和用户进行一对一或一对多的直接交流，最好是采用面对面的方式。如果条件不允许，则用电话、qq、微信等方式来进行沟通，从而获取用户需求；要想真正了解用户需求，就要尽量走到用户中去，了解他们的想法，深入了解他们在真实环境下的感受、痛点和期望。有技巧的访谈者能发现受访者对于某项任务/产品所持观点中最重要的部分，却不引入访谈者的偏见。

问卷调查是我们在日常生活中经常碰到的，最常见的就是每次商家都会让用户做问卷满意度评价。

网络问卷调查通常都是通过互联网渠道，设计问卷由用户填写，然后回收问卷，统计问卷数据，了解用户反馈的方式来了解用户需求。线上问卷调查工具网站有：麦客、问卷星、金数据等，传播的渠道可以是微信公众号、微博、微信群、QQ群或者邮箱、短信等。在做调查问卷的时候，需要围绕调查目的去设计相应的问题，同时还需要注意问题的准确性，问题不能问得太过空泛或者太过虚；另外还要注意问题的长度和问题的数量，设计的问题长度应该在填写者愿意认真填写的时间长度内完成。

行业数据报告，作为一名产品经理，应该对互联网中的事情有更多的了解，互联网行业的变化日新月异，各种新的产品呈出不穷，而互联网的各种信息也能够给我们提供更多的需求信息。通过行业数据报告挖掘需求，也就是所说的文献调研，它可以是一些专业的分析报告，也可以是一些比较干货的资讯文章，与之相关的各种动态。在这里，我推荐几个常看的网站，产品经理圈子相关网站——人人都是产品经理社区；TMT媒体以及创业类信息平台——极客公园、36氪、虎嗅网、钛媒体、爱范儿、品途；数据分析类网站——艾瑞网、TalkingData、友盟、企鹅智酷、中国互联网络信息中心。

2、竞品分析

竞品分析是找到同类竞争产品，深入体验竞品功能，为产品设计及需求收集寻求思路。

竞品分析可以在产品设计之初就开始进行，也可以在产品后期迭代的过程中进行分析，前面也已经提到过每次竞品分析的目标是有所不同的，而我们这次做竞品分析的目标，就是为了收集用户需求。在体验竞品的过程中，我们可以研究别人是怎么拟定产品战略、方向的，为了这个产品方向做了哪些功能，这个功能的背后对应的又是用户的哪些需求。

上图是网友对美拍和秒拍进行的竞品分析。

3、头脑风暴

头脑风暴就是一群人围绕一个特定的话题进行讨论。

我常常拉着我们家的产品经理、设计师、运营、市场、销售，甚至开发进行一场头脑风暴，当然，教科书上说参与者最好有不同的阅历和学科背景，这样更容易产生更多创新的观点。嗯，我看我们这个团队阵容就挺搭的。

在头脑风暴的整个过程中，我会先明确讨论的议题，并且会注意引导和发散大家的思维，让所有的人都能够参与其中。讨论时注意让参与者自由畅谈，并且不对他们产生的观点和说法进行任何的批评，而且产生的观点要足够多。头脑风暴是一种发散式的讨论，特别要注意对讨论内容进行详细的记录，这时候可以使用录音、拍照、思维导图等方式对整个过程进行记录，方便后期整理，避免遗漏重要观点。

4、用户反馈

用户反馈是产品在测试阶段或正式发布后，我们会收到很多的用户反馈。

通常来说，用户反馈是在产品上线之后，产品经理能够在用户的反馈中了解到用户的使用情况，也能够通过用户反馈了解到用户所遇到的问题，以及用户的想法和期望。

收集用户反馈有哪些渠道呢？产品内的反馈入口、用户QQ群、知乎、微博、微信、贴吧、产品社区、客服、销售等等都是收集用户反馈的渠道。产品经理可以考虑铺设多个反馈的入口，让用户能够随时随地只要遇到或者想到一些问题都能够快速反馈。

5、数据分析

数据分析在产品上线后，就可以收集到产品的相关数据了。

比如常规的访客数据、浏览数据、在每个页面的浏览时长等概括数据，还包括比较精细的用户行为数据，如点击事件、转化漏斗、用户画像等，这些都是产品数据的范畴。产品经理可以依据数据，来衡量产品迭代的效果，也可以通过数据来快速验证自己的想法。比如某天某个页面的某项数据指标急剧下降，官网注册转化率最近三个月都持续走低，面对这些现象，我们都需要通过数据来分析原因，必要时结合一下用户访谈会更有效果。

当然，需求收集也并不仅仅是产品设计之前的工作，而是一个贯穿始终的过程；它并不仅仅是产品经理的事情，团队里的每一个人都能向产品经理提出需求。上面所述的5种基本方法，都是面向用户层面的需求收集，但一个产品的需求，不仅仅来自于用户本身，有时候团队内部也会产生需求，如运营团队提出的统计需求，销售团队提出的CRM需求等。需要注意的是，从公司业务方向、老板/领导、运营、市场、客服等获取的需求，并不能直接当成最终的需求，还需要更深一层去挖掘需求，并且最终评审确定最终需求。

最后总结一下，这几种需求收集方法都是独立的，可根据产品的特性以及产品的发展阶段来选择一种或几种进行组合使用。

需求分析和筛选

经历了一次高强度的需求收集运动，绝大部分PM都已经得到了很多的备选需求，像是好不容易去果园摘了一箩筐的橘子回来。接下来，我们就要把一些还没有成熟的橘子给挑拣出去，对我们收集进来的需求进行分析和筛选。

如何分析与筛选需求呢？

我们先来看一个《精益创业》中的故事：

同步云存储服务Dropbox的创始人德鲁休斯顿（Drew Houston）在没用写一行代码的前提下，拍了一段视频通过在YouTube上发布视频来聚拢早期用户，后面这个视频被疯狂转载，于是他们就有了信心开始正式开发这个产品。

德鲁休斯顿（Drew Houston）并没有急于马上动手开发，是因为在当时需要克服重大的技术障碍，且投入成本暂时无法预估。取而代之的是，他选择了在目标人群中发布一则宣传视频，一本正经地向科技爱好者“虚构”了Dropbox的产品功能，用这个方法来验证用户需求是否真的存在。我们称这个方法为可用性测试，用来验证发现的需求是否确实存在。

当然这种方法，一般是用来测试产品大方向的需求，对于产品大方向已经明确，在收集具体的产品功能模块需求的时候，就不太合适了。

很多产品经理去面试的时候，可能都碰到过这么一个问题：

在过去的产品工作中，你是如何评估需求的？哪些需求该做？哪些需求不该做？评估的标准又是什么？

有些产品经理可能会说依靠自己的产品直觉，拍脑门进行决定；或者是老板决定后，产品经理来执行。这两种方式有其一定的道理和适用场景，不过都并不适合产品新人，一是因为产品新人对市场情况、用户需求的不了解，并不能有很好的产品直觉；二是如果每次直接都是老板拍板。久而久之，你也就成了执行的机器，而丧失了独立思考的能力。

作为产品新人，我们可以借用其它靠谱的分析理论来进行需求的分析和筛选工作。

1、筛掉明显不合理的需求

哪些是不合理的需求？比如当前技术不可能实现的或者是明显意义不大的，投入产出比比较低的，无匹配的产品使用场景的，明显不合理的需求等，都可以归类为不合理的需求。

2、再来看如何做需求分析

把明显不合理的需求排除后，我们就需要把剩下的需求一个一个进行分析了。首先要了解需求的三个分类：用户讲述的、用户实际想要的、用户的潜在需求，这是三件不同的事情，却又有着千丝万缕的联系。我们需要通过用户描述的需求，找到用户实际需求，发掘潜在需求.

举个例子：

一天晚上，小明和妈妈走在回家的路上，突然小明感到饿了，闹着妈妈说：“妈妈，妈妈，我要吃肯德基，我要吃鸡腿。”但是附近没有kfc之类的西式快餐店铺，妈妈有点犯愁，怎么办呢？但又不能饿着小明，妈妈突然想起来早上路过面包店买的面包还在包里，便拿出面包给小明充饥，小明一看还有面包，于是很高兴地开始吃了起来。

我们按照需求的三个分类来分析一下这个问题：

1. 用户描述：想吃鸡腿
2. 用户实际想要的：饿了，只要有好吃的都行
3. 用户的潜在需求：饮料？水果？

这个故事相对来说比较简单，但是也比较具有代表性。孩子不是很能表达自己的需求，但是妈妈很了解自己的孩子，所以能找到孩子的实际需求，在我们的工作场景中，我们也要多花些时间了解我们的用户，同时可以参考借鉴一下阿里巴巴前CEO卫哲的“3+1思考法”去分析用户需求：

• 需求从哪里来，目标用户是谁？

到底是我们想做，还是客户想要，亦或是老板想要，给谁解决问题；

• 有多少人有这样的需求？这个需求紧迫吗？

有多少人有这样的需求意味着市场的容量，紧迫程度意味着解决需求的价值；

• 用户的痛点是什么？使用场景是什么？（用产品之前／后）

解决了什么问题，不解决会存在什么问题，用户问题的使用场景我们是不是真的找到了；

• +1 怎么验证需求是否解决与解决效果？

解决之后在网站数据上会有什么表现？是网站数据提升了，还是用户反馈效果比较好。

我从前阿里产品经理苏杰的博客文章《卫哲的3+1思考法：测量项目“靠谱程度”》中把卫哲和产品经理之间对话给扒了下来，我们还是来好好感受一下画风吧：

卫：你们怎么想到要做这个产品的？（需求从何而来，目标客户是谁？）

我：我们在和卖家接触的时候发现有很多人花很多时间了解竞争对手的情况和市场上什么好卖。（需求来源的描述，这里注意到“卖家”“很多时间”“对手的情况”均是概念模糊的，没有一个明确的描述或定义。卫哲下面的提问也是在对这些模糊概念的提问。）

 

卫：有多少卖家做这件事？多久做一次？（有多少人有这样的需求？这个需求紧迫吗？这里就是对“卖家”“很多时间”的一个提问。）

我：大部分卖家每周都会做几次

 

卫：他们现在是怎么了解竞争对手的情况和市场上什么好卖的？（询问使用产品前的场景，这里是对“对手的情况”进行一个提问，从而知道对手的情况到底是什么情况。）

我：他们现在每天都会上淘宝进行搜索，找到同类商品卖得好的卖家，然后看他的关键字设置有什么特点，价格是多少，卖了多少个，做了什么活动，每周要花好几小时。（关键字、价格、销量等词汇对“对手的情况”有了一个较为明确的描述。）

 

卫：那用了你们的产品，他们怎么做这件事？

我：用了我们的产品，他们一方面可以看到针对他的某个宝贝，同行的类似宝贝有哪些，价格如何，销量如何。另一方面可以看到某一类目下特定关键字下，哪些宝贝卖得最好。（解决方案）

 

卫：也就是说你们是帮他们节约时间？小企业的时间是不值钱的，中国是这样，美国也是这样。（通过以上的问题，成功挖掘出了真正的需求“为卖家节约时间”）

我：…

 

卫：这些数据他们自己在网上能看到吗？（如果没有这个产品，用户会死吗？侧面帮助分析需求的重要性和紧急性）

我：能，但有些统计和分析，比如平均价格，有多少人比他价格高之类的他不知道。

 

卫：那知道了这些信息之后呢？他能做什么？（询问使用产品后的场景，继续挖掘需求。）

我：他可以做一些关键字的修改，价格的修改，或者换一下推广的商品，做直通车的时候可以更有的放矢。

 

卫：那我们的功能有没有和推广挂钩，比如和直通车做整合？直接让他做直通车的优化？（挖掘出新的需求或者说是更深层次的需求“商家需要解决方案”。）

我一愣，这个问题我还没有想过，但立刻意识到这可能是个方向：还没有，不过的确是个很好的方向。

 

卫：那客户在用了你们的产品后，网站数据上会有什么反应？（解决之后在网站数据上会有什么表现？产品目标是必须有明确的成功标准的，并且必须是可衡量的。）

我：也许卖家的搜索行为会减少吧，修改的次数会增加。

……

怎么样，是不是被ceo们的分析思路给深深折服了。通过这一系列的问题，我们大致就能够将每一个需求是否要做，什么时候做，优先级如何有了一个大致的预测了。

3、需求的减法

我一直信奉一个产品理念——少即是多。其实，有时候决定不做什么往往比决定做什么更加重要。产品的需求可以说是无上限的，大量的堆积需求，会使得产品非常臃肿，而且毫无特色，而需求的过多，还会导致工期过长，拖慢了产品推出市场的进度，对产品百害而无一利。因此，应该倾向于做“轻产品”，学会做需求的减法。这方面，苹果前ceo乔布斯就是个做减法的大师，苹果的所有产品都透露着一种极简风格。

这就涉及到我们接下来要讨论的话题，如何判断需求的优先级了。

如何判断需求的优先级

评估需求的优先级也是产品经理的一项重要能力，在前面已经通过需求分析评估和筛选了哪些需求该做，哪些需求不该做，对于决定要做的需求，由于数量过多，不可能全部都在同一时间全部开发完毕。这个时候，就需要产品经理对所有的需求来定义一下优先级，优先级高的需求优先研发，优先级低的需求延迟研发。

由于我们整个部分都是在介绍如何从0到1的打造一款产品，所以新产品在未上线之前，是没有相关的运营数据作为支撑的。这个时候，大部分在定义需求的优先级时，我们一般通过需求对用户的重要性和紧迫性来判断。

KANO模型是用来进行判断需求重要性的一条非常有用的法则。KANO模型定义了三个层次的用户需求:基本型需求、期望型需求和兴奋型需求。基本需求是必须具备的，即使不说也应该做到，这部分需求一般是产品初期需要做的功能。期望型需求是用户期望的，用户能够较清晰地知道的。而兴奋型需求是超出用户预期的，用户不知道有这方面的需求，如果提供，用户满意度会更高。一般情况下，用户需求的重要性依次为：基本型需求→ 期望型需求→ 兴奋型需求。

考虑完了需求的重要性问题，我们接下来考虑需求的紧迫性问题。通常情况而言，基本型需求的重要性最高，且也最紧迫，所以基本型需求的优先级默认是最高的。但是由于公司其它部门，如运营、市场、销售等部门业务需求的迫切需要，会同时研发一部分期望需求（重要不紧急）和兴奋型需求（紧急不重要）。

来个经典的案例讲解下如何进行用户需求的优先级排序。

话说，网上流传腾讯有一道经典的面试题，题目的具体内容是这样的：

1998年，QQ开始规划，1999年2月推出Beta1版本，1999年5月Beta2，1999年8月Beta3。Beta1版本只能实现3个特性，优先推哪三个呢？请从以下选项里勾选：

1. 卡通头像
2. QQ表情
3. 聊天记录管理器
4. 看谁在线上
5. 安全性
6. 传文件
7. 很小的.exe文件
8. 视频
9. 聊天室
10. 语音
11. 速度超快0.5秒反应
12. 皮肤管理

大家可以尝试着用KANO模型进行需求的优先级排序，但是别忘了结合当时的互联网发展状况及背景进行分析，想好了答案可以关注我公众号与我进行沟通交流。

当上述的重要性和紧迫性问题都考虑完整后，我们就可以输出一份高质量的功能需求列表了，同时也意味着我们即将进入需求管理的阶段。（下篇接着来讲这些内容）

ps：限于篇幅，需求描述这篇将会分为上、中、下三篇文章来讲，如对我的文章有更多想法和意见，欢迎关注我的公众号找我交流。

作者：壹百度（微信公众号：倒退集），在线教育企业服务领域产品经理，创业公司Team Leader。常常自诩是文艺青年和极客青年的结合体，在宅与不宅之间可以自由切换，曾主导多款重量级产品的产品策划和设计工作。

本文由 @壹百度 原创发布于人人都是产品经理。未经许可，禁止转载。