产品经理也是人之使用需求漏斗管理需求加工节奏

上一篇，我们详细介绍了Adapt需求漏斗模型，通过对一个真实需求管理案例的剖析，我们分析了什么样的需求流动才是相对合理的。在需求管理中，需求做不完、需求永远大于研发容量才是正常的。

那么，作为需求管理核心角色之一的产品经理，如何通过Adapt需求漏斗模型来管理需求加工节奏，产品经理团队应如何使用需求漏斗，并帮助团队决策、改善？——这是很多读者都很感兴趣的一点，我们希望帮助读者更好理解，并将漏斗模型应用到需求管理工作中。

从需求管理全局来看，需求加工是有节奏要求的，产品经理也不能只是文档工具人。

读完本篇后，相信你也可以学会使用需求漏斗，有效管理需求节奏了。

文末有彩色高清漏斗模型图获取方式

Adapt需求漏斗模型首先解决的是需求透明的问题。

意向、规划、容量、交付、速率5层，基本总结涵盖了团队需求管理的全流程状态，帮助团队首先将需求管理状况透明出来，结合漏斗模型给到的参考值，初步分析当前需求管理问题出在哪。

第二个要解决的问题，则是在做好需求透明后，如何管理好需求加工、研发节奏，保证需求质量，帮助决策——这也是本篇的核心内容。

为了帮助读者更好的理解，我们对Adapt需求漏斗模型进行了优化，增加了漏斗每一层的价值、面向的问题，以及优化改进方向：

图 / 更新后的需求漏斗模型

课代表总结

5层漏斗，面向5个问题，从上到下分别是：

创意够不够、规划快不快、容量够不够、交付快不快、速率稳不稳。

下文会用最简单的方式解读这5个问题。理解之后，可以轻松的将Adapt需求漏斗模型应用到工作中。

1

创意够不够

对应漏斗第一层，即需求的意向/提出数，用于衡量需求是否已经全部捕获，以及产品经理的工作重点。

产品经理要思考的是需求都捕获了吗？如果捕获不足，应该想办法去挖掘用户需求；如果需求足够，产品经理需求将需求重心转向识别重点需求，作为已优选需求开展后续工作。

第一层是产品经理管理需求加工节奏的起点，做好了需求意向的捕获和重点需求的识别，才能更好的进行需求规划等后续工作。

2

规划快不快

对应漏斗第二层，包括已优选、编写中、已业务评审等状况的需求数量。

我们首先需要认识一个问题：需求规划快不快，到底如何衡量？

已被认定为重点的需求（高价值或高优先级），产品经理有投入足够时间去梳理吗？规划快不快，不在于绝对时间长短，而是要考虑对需求价值的思考是否充分。这一点，可以通过上线的情况来复盘产品经理对价值的思考。

说完了产品经理，接下来就进入产研测矛盾冲突最集中的一点：容量问题。

3

容量够不够

对应漏斗第三层，即待排期+已排期（未来月份）的需求数。

容量问题是产品与研发矛盾最集中的地方，通常研发容量不是想变就能变的，也需要有一定量的需求合理积压量。

首先还是再次说明上一篇中反复提及的一个重点，树立正确的需求积压观念：需求积压并非全是坏事，也不是出现了需求积压就一定要加人。

本节涉及两个重点问题：需不需要加人、怎么加；以及，加人到底谁说了算？

1. 人何时应该加、怎么加

加不加人、怎么加，需要产品团队共同决策，是不同小队之间借调人力支持，还是额外从外部引入人力。

小队人力借调的判断依据

一个小队需要调同领域小队人力支持，判断依据是该小队需求积压的价值高于其他小队。如果价值高，则一定程度上可以由产品总监协调人力调用；如果价值低，那么也只能说，该积压就积压在那里吧。

2. 人随价值动，不是谁声音大就调谁那

特别注意一点，研发人力通常不应该由研发团队的某个领导来调整。

我们说人力调整本质上是产能分配的问题，人放在哪里是一种投资行为。研发CTO、分组经理们不应陷入谁声音大，调人到哪里的问题。 

如果有这种想法，你或许应该思考一下：业务目标没有达成，是需求没有做完导致的，还是积压的需求本身就价值不高？

这里不是试图说明研发不对结果负责，而需求价值本身就是一种投资行为，上线后的结果和投资一样，结果的不确定性是很高的。所以，研发团队也不用抱怨需求上线后没有达成预期。而是需要持续改善，与产品团队共同回顾改善，探索创新。

这一节讲的是人的问题，涉及数个观念的改善，如果有疑问，可以在评论区留言与我们沟通。

4

交付快不快

对应漏斗第四层，包括本月已排期、研发中、待验收、验收中、待上线、已上线的需求数。

这一层代表着交付快不快。已排上期的需求，本质上就是与迭代节奏相关了。每周发版，而且需求量是均匀的，已排期需求的交付速度自然会有所体现。

这里所谓的快不快，要思考的是当前能否支撑业务。如果能，那就是快的。

另外，研发迭代节奏受限于特定行业和系统复杂度的情况，我们发现通常时间花费比较多的是规划阶段。规划快不快，一定程度上决定着端到端的交付时效问题。需求漏斗能帮助你从全局看优化点。

5

速率稳不稳

对应漏斗第五层，指上月需求吞吐量。

这一层代表着速率稳不稳，这是一个很好的观察团队变化的点。突然的变化，不排除需求断层导致的，或是小队人员规模迅速扩大，或是人员减少等。

原因很多，重要的是看该数据是否与你对团队现状的理解一致。如果不一致，就需要去看看是什么原因，分析并解决隐藏在底下的问题。

本篇主要介绍了Adapt需求漏斗模型的应用问题，你可以结合团队的需求管理情况，制作自己团队的需求漏斗模型了。

如果有问题，可以在本公众号回复“进群”联系进群，我们可以结合漏斗数据，帮你分析问题，共同探讨改进方向。

本篇与上篇Adapt需求漏斗模型介绍配合阅读，效果更佳。点击第一个链接，阅读Adapt需求漏斗模型整体介绍。

1. Adapt 需求漏斗模型整体介绍

2. Adapt 规模化敏捷框架解读

3. Adapt 框架与其他敏捷框架有啥区别

4. Adapt 框架的落地案例

关注并在本公众号内回复“漏斗”，下载Adapt需求漏斗模型彩色高清电子图。