需求是每个产品经理日常工作都离不开的一部分，贯穿着产品的整个生命周期。

先来讲一个小故事

一天，和朋友一起吃饭，互相问候了下最近正在忙的事情，我就把那时候正在做的产品需求管理的工作跟他大致说了一遍，没想到朋友倒是挺能触类旁通，说道，这不是和搭讪很像吗？

我感到很意外，心想这哪能扯上什么关系。

朋友微微一笑，开始给我科普了起来：你看，如果把妹纸比作一个需求，是不是先得到妹纸多的地方去找需求？比如商场、咖啡吧、夜店……

朋友接着说道，当你来到商场，是不是已经算是采集到了很多需求了？下面是不是就要评估和筛选需求了？比如说妹纸旁边有男性的，这个就大大增加了搭讪的复杂程度，因为有障碍，这种妹纸是不是就不在你考虑范围之内了；而被你看上的，是不是就算是经过了评估筛选了的，那么你是不是就可以进行下一步的动作，上前去搭讪了。比如“你好，刚刚在那边看到你……”这样操作下来，你是不是就得到了自己想要妹纸的微信，可以愉快地进入下一个阶段的发展了。

我默默地点了点头，看着不远处几个姑娘亭亭玉立着，一下顿悟道，看来搭讪和需求管理一样，都是产品经理的基本功啊。

……

当然，本故事纯属虚构，如有雷同，请拨打妖妖灵，接下来进入正文部分。

需求的本质

什么是需求？

需求是每个产品经理日常工作都离不开的一部分，贯穿着产品的整个生命周期，产品经理的招聘信息上也充满了“做好全面的需求分析与管控”、“收集和挖掘产品需求”等这样的字眼。营销学之父菲利普·科特勒在他的著作《营销管理》当中为我们界定了三个概念：

1.需要：某些基本方面没有得到满足而产生的不足或短缺的感觉

需要是指人们对某种东西感到缺失的一种心理状态，比如饿了想吃饭，困了想睡觉。身为人本心理学中流砥柱的马斯洛童鞋早早就对人类需要的层次进行了分级，1954年，出版了影响深远的巨著《动机与人格》，书中系统地阐述了著名的“马斯洛需要层次理论”。他认为人类的需要层次有高低不同，低层次的需要是生理需要，向上依次是安全需要、爱与归属、社交的需要，再上去是尊重和自我实现的需要。当人类的较低需要得到满足时，就会开始追求更高一个层次的需要。

2.欲望：想得到基本需要的具体满足物的愿望

与需要不同，欲望有明确的指向性和选择性，比需要更加具体。比如，当你对某个女生有好感，于是产生了想要和她进行交往的欲望（注意这个时候不是模糊的社交需要了，而是具体和某一个人社交的欲望）。但欲望又是建立在不同的社会经济、文化和个性等基础之上，对个体而言是具有个性的一件事情，比如一个美国人饿了想吃汉堡、薯条，而一个中国人饿了则想吃米饭和菜肴。

3.需求：需求是对于有能力购买并且愿意购买的某个具体产品的欲望

比如特斯拉作为这个星球上最豪华的智能电动车，产品经理想必都在朝思暮想。但对于买不起特斯拉的人来说，他们对特斯拉的需要只是一种欲望，因为他们不具备购买能力。

简单梳理一下，会发现在需要、欲望、需求三者之间存在着这样的层级关系：

很多人看到上面也许就有点困惑了，因为我们平时做的产品需求的概念，好像并不符合上面教科书的理论，毕竟很多需求用户都不具备购买能力。简单来说，那是因为在互联网行业内，“免费”的商业模式逐渐打破了欲望与需求之间的壁垒，许多互联网公司已不再对其提供的基本产品进行收费（如腾讯的qq、百度的搜索、360的杀毒软件），而是通过其它途径来获取商业利润（如广告、增值服务等）。换而言之，是免费这一伟大的商业模式，将营销教科书上的理论进行了重构和颠覆，所谓创新当然不会在理论的条条框框里束缚住。

那需求的本质又是什么？

手机qq里面的附近的人，想必大家都玩过。如果有一个用户给手机qq的产品经理提了一个需求，说希望能在附近的人里面提供一个付费服务，只要付了费就能够在附近的人中进行置顶出现。

你觉得这个需求的本质是什么？

我们来尝试简单分析一下，用户希望能够置顶出现在附近的人列表里面，那么他当然是希望有人来找他聊天，以增加存在感。而我们知道，qq用户玩附近的人，很大程度上都是看对方头像的颜值去决定要不要和这个人进行聊天或者互动，而一个人如果长得比较丑，头像比较难看，那么即使你把他的头像置顶到列表的最上方，依然不会收到多少互动信息。这个时候，你会发现，即使给了他这么一个置顶的功能，他依然没有解决自己需要被关注、需要社交增加存在感的本质需求。换个角度来想，兴许给他一款美颜相机，让他也可以轻松地拍出好看的头像，是不是能够更加容易地解决他的问题。

相信很多产品经理也都看过“客户要买的不是钻头，是洞”和“福特造车”这两个故事，其实这些互联网上流传已久的故事，要告诉我们的，也无非是这么一个道理——作为产品经理，应该透过表面需求去发现用户真实目的或者欲望。

所以，需求的本质其实是动机。产品经理需要通过用户的回复、行为、反馈、抱怨等现象，去深刻把握用户的本质需求，就像用户要的其实不是一匹更快的马，而是更快地到达目的地。

总结互联网的两种需求：一种是使我们生活更方便，另一种是解决我们的无聊。

需求的前奏——产品定位

前面我们已经讲述了如何搭建产品模型。

通过梳理产品模型，我们可以清楚地了解一个产品应该如何定位自己，首先想到要做什么事，是否值得做，是否能够做，是否充分理解了用户，然后要找到一个好的定位的落脚点。有了自己的产品定位后，我们就可以更好地开展下面的工作，产品定位是产品设计的方向，也是指导产品需求收集的方向。很多产品经理在做需求管理的工作之前，都忽略了这至关重要的一步，只有在产品定位得到项目团队成员的统一认识，才能让团队后续的工作更有效率和凝聚力。

那么，什么是产品定位？

比如“最简单易用的拍照软件”、“产品经理交流成长的社区”、“一个专为程序员找工作的网站”、“一个神奇的网站”……诸如此类都算是产品定位。

产品定位是指确定某产品在消费者或用户心目中的形象和地位，即通过塑造产品或企业的鲜明个性或特色，树立产品在市场上的形象，从而使市场上的目标用户了解和认识本企业的产品。如国内BAT三大互联网巨头，它们的产品都有属于它们自身特有的定位，百度的产品定位或者特色在于搜索和技术；而阿里巴巴的产品定位有着明显的电商属性；腾讯的产品更不用说，qq和微信带有强烈的社交属性；

产品定位简单来说，就是用一句话概括你的产品，包括使用人群、主要功能和产品特色。比如某产品的口号是“简单好用的团队协作软件”，我们来分析一下，它这句话的产品定位：

使用人群：有团队协作需求的人

主要功能：提供团队协作功能，线上办公

产品特色：简单、好用

包含了这三个要素的产品定位，算是基本满足了传达产品形象的要求。有了产品定位，其实就已经为产品限定了一个大致的需求范围，这样就不至于让团队成员在千头万绪中感到无从下手，难以取舍，产品团队的其它人员就可以根据产品定位开始去收集用户需求。

平常大家都在谈需求，但好像并没有一个明确的概念来界定一个需求到底包含哪些东西，在收集需求之前，产品经理又应该如何更清楚、更科学地描述一个用户需求。

用户需求主要包括三个要素：目标用户、使用场景、用户目标。

举个计步软件的小栗子：

目标用户：软件重度使用者，经常徒步旅行

使用场景：刚走完一趟徽杭古道，一天下来走了接近3万多步

用户目标：想要将这个牛逼的纪录分享到朋友圈，让更多的人看到

一个用户需求，可以看作是“目标用户”在“合理场景”下的“用户目标”，其实就是解决了“谁在什么环境下想要解决什么问题”。每个需求其实都是一个生动的小故事，产品经理在向团队其它成员描述需求的时候，只有把这些小故事讲的生动活泼，让别人有身临其境的感觉，才能算是真正把需求给传达清楚了。

回到刚才计步软件的例子上，作为一名产品经理，在你向其它成员传达用户想要能够分享自己的徒步纪录到朋友圈这个需求时，是不是应该夸张地描述一下如果用户走了多少多少公里，消耗了多少多少卡路里，这个时候把这条消息分享到朋友圈，肯定会吸引用户好友的点赞和评论，让用户的存在感爆棚，那不就对我们产品产生了正向作用么（同时还能起到产品传播的作用）。

这样一来，明确了产品定位，知道了如何清晰而准确地描述一个用户需求，我们就可以放心地开始需求的收集、分析和筛选之旅了。

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

需求收集——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之类的西式快餐店铺，妈妈有点犯愁，怎么办呢？但又不能饿着小明，妈妈突然想起来早上路过面包店买的面包还在包里，便拿出面包给小明充饥，小明一看还有面包，于是很高兴地开始吃了起来。

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

用户描述：想吃鸡腿

用户实际想要的：饿了，只要有好吃的都行

用户的潜在需求：饮料？水果？

这个故事相对来说比较简单，但是也比较具有代表性。孩子不是很能表达自己的需求，但是妈妈很了解自己的孩子，所以能找到孩子的实际需求，在我们的工作场景中，我们也要多花些时间了解我们的用户，同时可以参考借鉴一下阿里巴巴前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个特性，优先推哪三个呢？请从以下选项里勾选：

卡通头像

QQ表情

聊天记录管理器

看谁在线上

安全性

传文件

很小的.exe文件

视频

聊天室

语音

速度超快0.5秒反应

皮肤管理

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

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

我们已经通过需求分析和筛选，评定了需求的优先级，这时候就应该把这些整理好的需求，通过一个表格给呈现出来，功能需求列表Feature List就是这样一个承载器。

输出功能需求列表

什么是功能需求列表？顾名思义，就是把需求分析、筛选和评定优先级之后的结果，以产品功能的形式展现出来，再用列表的方式将其呈现。这是需求分析之后，提出解决方案的第一步。

功能需求列表的价值，一是在于帮助产品经理自己理清思路，二是在于帮助项目团队的其它成员了解产品功能需求，好让他们提前做好相关准备。

我们来看一下功能需求列表大致包含哪些内容：

模块：一般来说，每个模块下分3~6个子模块是合理的，否则要考虑重新划分。

子模块：也就是一级模块的二级分类，这里就已经涉及到产品架构的梳理了（但我们这里只是大致地梳理一下，后期在产品设计的下一个环节“搭框架”会进一步调整）。

功能：要给用户提供什么功能，给这个功能起个名字。

功能描述：这个功能具体包含哪些操作，可以描述的具体一些，如支持用户填写基本信息可自由创建课程，进入课程空间就可对课程进行编辑和管理，还可发布、删除课程等。

用户价值描述：也就是可以给用户提供什么价值。

需求优先级：这块是整个Feature List工作中核心的部分，判断的准确直接影响着将来产品的方向，我们只需要将我们之前评定的需求优先级照抄过来就好。

开发量：一般由研发部门的项目经理或者开发来确定。

投入产出比：简单来说，就是商业价值除以开发工作量（或开发难度），当然每个团队可以找出一个合适自己产品需求ROI的计算方法。

备注：觉得需要强调的，比较特殊的东西。

上图是功能需求列表的一部分，当然现在也有越来越多的产品经理直接通过脑图软件来进行功能需求的梳理，然后通过脑图软件自带的标注、附件、笔记、优先级排序等功能进行说明，比如下图这样的：

形式其实并不是那么重要，重要的是团队成员能够通过你的文档更加清楚地了解产品的功能需求，也便于产品经理和团队成员进行沟通。有了这份功能需求列表，我们就可以召集团队相关成员进行一次需求评审会议了。

参加需求评审会议的可以有产品经理、老板/领导、运营以及市场相关人员、开发主管、测试经理等。为了保证需求评审能够顺利进行，最好提前做好相关的准备，产品经理要能够讲清楚需求的来源，为什么要做这个需求，做这个需求有什么意义，这个需求需要哪些功能配合，同类竞品是否有该功能需求，为什么这个需求的优先级比较高……

整个需求评审的过程，考验了产品经理对需求的熟悉程度以及对需求的判断能力。同时，参与评审的人也将会对你提出的需求提出自己的看法，是否同意该需求，并且会提出同意或者不同意该需求的理由。需求评审是多人围绕已经收集到的需求进行评审的过程，通过集合大家的智慧，能够避免一个人闭门造车拍脑袋进行决策的局限。

如果时间比较充足，有些产品经理在需求评审会议上还会展示产品低保真原型，用来辅助说明，让大家更加理解这个需求以及需求以后会是怎样的样子，这样也能够让自己在讲解需求的时候更加有依有据，避免错过一些有用的需求。当然，我们这里只是第一次需求评审，到了后期产品原型乃至ui设计稿全部定稿的时候，依然需要进行产品的需求评审。

如何管理需求——需求池

之前就已经说过，需求是每个产品经理日常工作都离不开的一部分，贯穿着产品的整个生命周期。所以，如何管理需求，就成为所有产品经理必备的一项技能了。

在这里要给大家介绍一下需求池这个东西。

什么是需求池？

嗯，你可以把它类比为一个需求的收集器。需求池其实就是存放跟产品有关的未来可能会做的功能点的聚集地，然后在规划新版本的时候，从池子里根据“轻重缓急”和“优先级”来筛选出几个需求，排一排、整一整，弄成一个新的版本项目计划。

需求池工具有很多，比如Project、Execl、MindManager等等都可以作为需求池管理工具，你也可以使用一些团队协作软件（如tower、tita、明道、teambition等）里面的项目管理功能来做需求池工具。

一般来说，我会将需求池按产品的功能模块来进行划分，这样所有关于产品功能的需求都会被归类到相应的产品模块里。当然，这个需求池里还会包含来自运营及其它部门的需求。我们要做的就是告诉这些需求提出者，他们的需求我们都重视了，已经放到了需求池当中，但是是否安排开发需要根据所有需求进行“轻重缓急”和“优先级”的权重比较才能决定。我们需要定期去审核和分析这些需求，是做还是不做、要做的话是什么时候做？

对需求池的建议有两点：

1、不必考虑能不能做或者是做了没用什么的这样的限制，先不必设置伪命题，只要是觉得OK的，都可以先列出来，在产品生命周期管理中，靠谱的、不靠谱的、紧急的、不紧急的；

2、需求池需要产品经理经常去整理，不然就失去了需求池本身的意义，如果你不去整理，不论是市场环境，用户行为都有可能发生变化，任何一个产品都是变化很快的，这个时间段的需求有可能过一段时间就失去意义了。这个整理其实就是复原了一次需求的分析和筛选过程，同时还要去进行需求的优先级定义，每一次安排产品版本计划的时候都要重新审视一遍需求。

总结

需求管理是一个完整的闭环过程，同时也贯穿着产品经理工作的每一天，比如：

1、我们是不是每天都要去思考这个需求是否需要去做？这个需求到底重要不重要，紧急不紧急；

2、我们是不是经常都要去用工具把需求给做出来，用visio这样的流程图工具去梳理业务流程，用axure这样的原型工具去设计产品原型，做的同时还得思考这个功能需求究竟放在产品的哪个功能模块合适；

3、我们是不是每天都要去和各种人沟通需求，和设计师沟通需求，和前端工程师沟通需求，和后台开发沟通需求，还要和测试、市场、运营、销售等沟通需求。同时，你还要和用户谈需求，让用户了解和认识你的产品；

不得不说，要做好产品经理真不是一件容易的事情。

原文链接：http://www.woshipm.com/pmd/421678.html

----------------------------------------------------------------------------------------------

阅读更多好文，请关注公众号：

新雨社