一、前言

需求收集得到的各种用户需求素材，是产品项目发展的唯一来源支撑，可以说需求收集的质量影响着产品项目最终的质量。需求收集流程的执行情况，也是一个公司管理是否规范的试金石，也可以衡量一个公司是否真正“以市场为导向、以用户为中心”。本文档的编写主要用于对产品专员/助理、产品经理及产品工作相关小伙伴，进行需求收集管理时，通过规范指导工作使用，让需求收集相关工作得以规范地开展，推动后续项目研发工作的有序进行。

二、需求规范

1. 需求的定义

1）用户需求

? 通常我们做产品的时候都讲以用户为中心，以需求为导向。这里的需求都有一个前提，就是关联了用户，所以我们平时更多的都是在讲用户需求，也就是与“人”相关。

? 需求可以分为单个需求（指单个用户的某种需求）和市场需求（指用户全体某种需求的集合）。

? 需求既是产品的组成部分，也是产品最终要达到的目的。它既是原因，也是结果。一个产品是由需求发起，也是结束于满足需求。需求也可以来源于市场，随着时间及市场趋势会需要产品不断地更新和创新。

2）产品需求

面对同样的用户需求，不同的人，提供了不同的解决方案，从用户需求到提供产品方案的过程，我们把它称为定义产品需求的过程，用户需求并不等于产品需求。产品需求，一般意义上是指，对产品的一个全方位的整体规划描述，就是通过一段话或几段话描述对产品的设计、包装等精准的要求。

3）需求真伪

真需求/强需求/刚需

? 产品的主流用户愿意为这个需求付钱

? 产品的主流用户愿不愿意为这个需求付出时间

? 产品的主流用户愿不愿意把这个产品分享给朋友

伪需求/弱需求/软需

? 用户对问题表述“错误”或者缺乏对解决方案的“想象力”

? 项目不具备可行性

? 不是用户抱怨的问题，团队自己抱头想出来的基本是伪需求

? 没有倾听用户内心的诉求而强行拉动的需求不是真正的需求

? 先有技术后有产品，再寻找使用人群和硬套应用场景

? 用户不知道自己更想要的，不知道自己还想要的

? …

4）其他说明

市场需求为立项前期分析市场所用，可作为本阶段的参考依据，但本阶段无需重复采集分析。

2. 需求收集目的

需求收集的目的在于：通过收集以“市场为导向”的用户需求，保持公司产品的核心竞争力，最终实现产品价值。具体说来：

1）深刻理解市场需求、用户需求，准确把控行业发展趋势，保持高度的市场敏感度。

2）保证产品研发是围绕用户需求来展开，真正实现产品研发“以市场为导向、以用户为中心”，而不是闭门造车。

3）实现产品创新，通过有创新性的新卖点、新产品的持续不断推出，保证公司产品核心的竞争优势。

4）及时获得竞争对手相关产品及市场策略，做到“知己知彼”。

5）通过需求收集等相关活动，有机串接市场营销部门与产品研发部门，建立跨职能部门的流程进行需求开发。

6）加强与用户互动，提升用户忠诚度及粘性。

3. 需求收集原则

1）以公司的产品愿景、产品战略为指导大方向。

2）需求采集应该面向那些细分的目标用户群，而非普遍撒网。

3）对不同的用户需求进行优先级排序出现需求冲突时，采用科学的方法进行取舍。

4）需求收集应该收集用户真正面临的问题和业务场景，这样才能够捕获用户真正的需求，而不是只盯住用户提出系统需要实现什么样的功能，“需求收集”不是“需求汇总”。

5）需求收集流程要真正发挥作用，必须在组织层面通过组织规范化来保证需求有效性和真实性。

6）尽可能避免预设立场，我们应当首先成为产品的忠实用户。对用户，我们应当通过与用户互动的手段来“倾听用户的心声”。

三、需求收集指导

1. 收集方法

2. 记录方法

记录用户的某个需求看似一件简单易做的事情，感觉上只需要指出用户想要干什么，产品能够提供什么就可以了，实则不然。每个人分析问题的角度和解决问题的方式都不尽相同，产品经理要尽可能降低这种需求理解上的成本，比如不完整和二义性是需求定义和表达需要避免的。

3. 建档管理

? 需求命名、采集时间（方便追溯管理）

? 需求收集者、职能部门（记录参与人）

? 需求来源（例：问卷调查、用户访谈…可具体描述）

? 应用场景、用户痛点（例：老年人用户手机录入信息，年纪大不会使用手机打字）

? 期望方案（初设想碎片化方案）

? 是否加急需求

四、需求验证指导

1. 黄金圈法则

? 思维模式处在最外层的人，他们知道自己想要做什么，但很少去思考怎么做才更好；

? 处在中间层的人知道如何更好地去完成任务和目标，却很少思考做这件事情的原因；

? 而处在最中心圈的人则是以“为什么”为出发点，他们拥有内在动机，能够实现自我激励，而只有这样的人才能成为伟大的领导者，才能激励和影响到身边的人。

小窍门

逆向思维，如果无法问出用户想要什么，那就去问他们不想要什么，不满意什么。简而言之，就是“倾听抱怨”。听用户对现有产品（产品、竞品、替代品）的抱怨，听用户对其他方面的抱怨。

2. 需求验证漏斗

黄金圈从外到内依次是：做什么（what）、怎么做（how）以及为什么（why）。

? 用户告诉你的需求是what，比如你通过问卷调查或者买家评价与反馈所收集到的信息等。what层面是用户评价和痛点，它让你“发现可能的机会”，但这个机会不一定会形成需求。发现机会，并不代表我们要立刻开始寻求解决方案，因为需求可能只是伪需求，或者根本就不具备任何可行性。

? 用户表现出来的需求是how，即用户在使用产品、选择产品时的动作和结果，它可以对用户的需求进行行动表达上的证伪，验证What层面会呈现出的“需求”。 判断需求不能只是听用户怎么说（what），一定要通过看他怎么做（how）来验证。

? 用户内心真正的需求是why，即用户一系列动作背后的原因，为什么要使用该产品而不使用其他产品等。找到这个原因，才能最终验证需求是否是真需求，也决定了用户最后是否会为你的解决方案买单。验证需求是要经历how层面直接的验证，同时追索到why层面进行分析才能最终确认。

小窍门

5Y分析法：连续问5个为什么从而发现根本原因

五、需求转化指导

（一）需求过滤

将需求池里的需求进行第一轮过滤：

1）需求分真伪，只满足真需求

例用户需要一匹更快的马，我们可以给他汽车。他不是想要马只是想要更快，还原到动机和人性。

2）需求分广度，只满足80%的用户

不同用户有不同的需求，按照二八原则，我们只需要去满足80%的用户。

3）需求分频率，只满足高频需求

单次或偶尔需要我们可以将之约等于不需要。

4）需求分痛度，只满足痛点需求

用户痛点究竟是多痛，反问一个用户问题就可以知道答案，你愿意花多少钱去解决这个问题。

5）需求分时机，对的时机做对的事

在哪个时间节点上线这个功能点是不一样的，需要产品经理去评估。

（二）优先级排序

利用常用的几种需求优先级排序方法，进行权重分配，得到最后的优先级评估结果。评估维度及方法由产品经理自行选取。在通过加权求得最后的需求优先级评估值。评估值越大，优先级越高。为了降低模型的主观因素，建议每个维度由多人进行打分，取平均分会有更好的效果。最后，由于模型是线性的，仅起到参考作用，还是需要产品经理做出最终决策。

1. 目标契合度（20%）

目标对需求优先级的影响非常关键，因为目标体现了需求实现的最终价值。我们需要结合产品当前阶段目标和发展线路图，进行需求契合程度的判断。

2. 需求价值（10%）

需求价值分为用户价值，公司价值两块来分析，使用四象限法进行分数指标的确定。在不同的产品类型侧重的价值方向不同，所以究竟是用户价值更重要还是公司价值更重要是需要通过自己判断的。但如果两者都体现了很好的价值，那么评分自然可以较高。

3. 客户满意度模型（Kano模型）（10%）

KANO模型定义了三个层次的顾客需求：基本型需求、期望型需求和兴奋型需求。这三种需求根据绩效指标分类就是基本因素、绩效因素和激励因素。

? 基本型需求：顾客认为产品“必须有”的属性或功能。当其特性不充足（不满足顾客需求）时，顾客很不满意；当其特性充足（满足顾客需求）时，无所谓满意不满意，顾客充其量是满意。

? 期望型需求：要求提供的产品或服务比较优秀，但并不是“必须”的产品属性或服务行为，有些期望型需求连顾客都不太清楚，但是是他们希望得到的。在市场调查中，顾客谈论的通常是期望型需求，期望型需求在产品中实现的越多，顾客就越满意;当没有满意这些需求时，顾客就不满意。

? 兴奋型需求：要求提供给顾客一些完全出乎意料的产品属性或服务行为，使顾客产生惊喜。当其特性不充足时，并且是无关紧要的特性，则顾客无所谓，当产品提供了这类需求中的服务时，顾客就会对产品非常满意，从而提高顾客的忠诚度。

4. 重要紧急程度（10%）

5. ROI投入产出比（20%）

? 投入产出比，也称投入产出率，英文缩写：ROI，是指项目全部投资与运行寿命期内产出的工业增加值总和之比。它适用于科技项目、 技术改造项目和设备更新项目的经济效果评价指标。其值越小，表明经济效果越好。

? 投入的计算期是指项目的建设期(或改造期)，这一点没有疑义。

? “投入产出比”中的“投入”是指项目全部静态投资额；“产出”是指项目全部运行寿命期内各年增加值的总和。用公式表示就是：R = K/IN = 1/N。上式中，K为投资总额，IN为项目寿命期内各年增加值的总和，N = IN/K，N值越大，项目经济性越好。

6. 需求来源（10%）

需求来源也是一个参考维度，因为谁提的需求可以用来判断需求的真实场景和实现价值。

7. 需求依赖（约束）（10%）

这里的需求依赖主要指的是本需要求是否是其他需求的前置需求，或后置需求。这体现了开发中的前后排期关系，非常重要。一般包含前置需求的优先级、重要性和紧迫性，高于后置需求。

8. 技术风险（10%）

开发的难度，可能出现的开发风险程度。注意工期过长，也会导致风险增加，所以只要开发上的不确定因素越多（如服务器资源，开源系统性能等），此值越低。