在相对成熟、处于发展期的团队，需求管理就是产品经理的核心工作之一。就像长途驾车既要保证方向正确、目标清晰，也要保证在驾驶中的平稳、安全不出差错。——从点子到产品

一、产品经理要对每个需求了如指掌

需求可以理解为是用户在一定时期内未经满足的需要，如果已经满足了，不是需求而是已经成型的方案或产品。需求的来源往往十分广泛，可能来自老板、产品经理、业务、客服、用户等与产品相关的任何一个人。

对于产品经理来说，需求是工作的开始。包含问题梳理、可行性分析、方案选择和具体执行四个方面。从想法到形成需求，再到可以落地的功能，需要过关斩将，经历各类评审和研讨。产品经理在需求方和有限的研发资源之间纠结，不仅考验沟通协调能力，更加考验对需求本身的把握程度。

1、产品需求的来源

需求从来源渠道上大致可以分为用户、老板、同事以及产品经理自己四个类别。

11来源于用户的产品需求

产品是提供给用户使用的。产品是否符合用户需求、使用过程是否顺畅、是否帮助用户解决了问题或达到了目的，需要产品经理时刻保持关注。可以通过收集用户反馈、做用户调研访谈、客服跟进或直接混迹在用户群体等方式，收集用户心声。从他们的牢骚和吐槽中，定位到背后的真实问题，并不断完善产品。

12来源于上级领导的产品需求

上级提了一个需求，让产品经理去执行。这个时候就要采用对用户完全不同的做法了。产品经理在接到领导需求时，第一件要事就是弄清楚前因后果。领导有比产品经理更多的信息源，有些可能领导以为产品经理应该知道。如果双方信息不对称，产品经理不知道背景，在执行上可能跑偏。

其次，上级领导想要的是结果，而不是具体做某件事情。因此产品经理在接到任务时要思考：有无更好的实现方案、能否进行轻量化尝试、需要用产品来实现时，轻量化、少打扰的拿到结果总是好的。拿到结果，证明可行或者不可行，给出后续的计划和建议，就是最好的答复。

13来源于相关业务同事的产品需求

运营、客服等相关业务部门同事，会根据实操过程中遇到的问题提出需求。

对于此类产品需求上线，产品经理前期要思考资源是否充足、是否能解决目前的业务问题，是否还有更好的解决方案。只有和同事配合顺畅，才能够实现产品良性发展。

14 来源于产品经理自身的需求

产品经理在迭代的过程中，最重要、也是最容易忽略的就是自身的需求。产品经理要掌握自己对于产品的目标及规划。可以通过对OKRs的目标拆解，来明确自身需求，规划好每个版本的功能以及进度节点，掌握自身产品节奏。同时，在每次版本中都预留一些位置，插入可能出现的用户、老板、同事等各方面的需求。这样就能在处理好新增需求的同时，也做好版本把控，保证产品朝着自己期望的目标前进。

二、需求评审时需要传达什么信息

需求评审要传递的信息，主要包括产品的价值、功能及实现。价值即为什么要做这个需求，上线之后的价值是什么。功能指为了支撑这个价值，需求包含了哪些功能呢。实现即针对每一个功能，该怎么实现。

比如，产品经理做一个预约票功能，价值就是使得旅客在票量紧张的时候，能够第一时间收到余票信息通知。功能是需要呈现A、B、C等三个维度的信息采集。实现就是每个数据的口径是什么，在前端如何展现，以什么样的形式通知到旅客。

需求本身大致可以分为：功能优化，功能拓展，新项目。不同类别的需求，在评审会上传递的信息重点不太一样。功能优化重点在讲清楚如何做。功能拓展重点在讲清楚是什么，与原有功能的联系是什么，可能要单独组会。新项目重点在讲清楚为什么要立这个项目，项目包括哪些模块，模块间的联系是什么，每个模块的功能及实现。

从信息量上来说，新项目的评审是密度最高的，也是最考验表达逻辑及评审效率的。高效评审，是向协作团队传达出了统一的项目价值，能够让他们理解彼此的角色，任务及需要落地的行动，最关键的，彼此角色之间的关联是什么。

人对新事物的信任感是相对低的。产品经理在需求评审会上最重要的任务，是帮助大家建立这种信任感，传递两个信号：这个事儿值得做；这个事儿能做。

1、用最直接的方式说明需求价值

不仅产品经理要了解需求价值，协作团队也需要了解需求价值。可以采用量化指标，数字切入的方式在最短的时间内传递信息。比如说在开发礼遇卡领卡端口，这个功能的价值也很多种描述方式：效率提升、提升旅客粘性，领导很关注等等，但这些不够直接。想在最短时间内说明这个重要很重要，就要用数字说话，例如预计能引流旅客xx人，经测算会带来增量收益xx万元。

2、说明为需求设计方案之前的准备工作

这一点经常会被忽略，但实际上很重要，尤其是对新项目的评审来说。人对新事物的信任感是相对低的，所以要让领导、同事了解产品经理为此做过的准备工作及相关的核心结论。例如做过哪些市场、竞品调研；公司战略层有一些什么指示；尝试过一些测试小体量案例及其核心结论。

这一步的重点不在于让需求变得更清晰，而在于提升协作团队对新需求的信任感。我作为产品经理，已经把可能存在的问题及应对方案尽量考虑周全了。

3、逻辑+模块的表达方式

对内容密度较高新项目而言，会出现听不懂+不知道现在讲到哪一步了的负面效果。本质上都是因为，没有在听众脑中建立起逻辑主线。逻辑+模块思维其实类似于建立目录，先看目录，再看细节，遇到不懂的问题再回到目录来，渐渐地就搞懂了。逻辑链通畅，需求评审就成功了一大半。

4、上帝视角与用户视角的结合

关于产品有两个常用的视角，上帝视角和用户视角。前者是产品经理在设计方案时常用到的，后者是用户从进入产品到退出所经历的完整过程。只说上帝视角，不容易理解，别人理解起来困难；只说用户视角，太零碎，不容易记住主线。

5、学会区分听众的提问

在短时间内完全讲清楚一个新项目，几乎是不可能的，听众也一定消化不了。当领导同事提问时需要学会判断，什么样的问题该当场解答，什么样的问题下来私聊。高效的需求评审不是解决100的问题，而是在1个小时的时间里解决最重要的问题。以下两类最好能够当场回答：（1）关乎价值，关乎为什么做；（2）关乎完整性，这个问题不解决，整个产品逻辑不通。

三、工具：WSJF模型

WSJF，即Weighted Shortest Job First，中文翻译是加权最短作业优先。WSJF是算出来的一个比值，分子是需求的价值，分母是实现的成本，也就是说，经过WSJF模型计算后，先做的需求，都是价值高且成本低的。

在实际操作中可以把所有被插需求、被压紧急需求、已排期需求被调整优先级的理由进行整理，然后聚类分析。会发现无外乎是之后发现，无非是决策层、战略、商业、体验等维度。可以根据业务需求，拆解各类影响因素并进行打分，如：

决策分：从高到低10分满，权重为5；

战略分：从高到低10分满，权重为3；

商业分：从高到低10分满，权重为2；

体验分：从高到低10分满，权重为1。

权重比值的计算可以用过往需求来估算，一般不需要特别精确，只要符合目前公司的价值观即可（如果是体验第一，那就体验权重高；如果是推重点项目，那就战略权重高）。

分母的计算相对标准且简单，通常考虑完成时间及成本。比如A功能价值100万（每个月）需10个月完成，另一个B功能价值20万（每个月）需1个月完成。通过WSJF模型计算，前者每个月价值是10万，后者每个月价值是20万。如果先做第一个，意味着我们只能在10个月后，拿到20万的收益，那么开发A功能的成本要计算上延期B带来的价值损失。

一个好的需求价值评估模型，能够帮助产品团队省掉扯皮，也能让整个产品良性发展，研发资源利用率更高。但最好的方法和模型，永远是根据自己所处的条件分析改造得来的，而不是用已有的成型方法。