需求池管理

编辑导语：需求，是产品经理不可避免的工作日常。产品经理每时每刻都在与需打交道，因此必须处理好需求，工作才能顺利地进行下去。所以，产品经理需要在工作中建立自己的“需求池”，让需求宽进严出，保证开发的需求都是有助于产品发展的。而如何管理好需求池，这是产品经理必须练好的基本功。

产品经理的日常工作中，最频繁的一项是「接需求」，特别是 B 端产品经理。记得有一次和朋友聊天，说刚入职的时候有需求池中 100 条记录，工作 2 年离职后，需求池中只剩下 300 条了。

如果你感觉每天被需求包围，东一头西一头忙忙碌碌而无价值产出，那就好好思考下，是不是需求池管理出了问题。

一、为什么要做需求池管理？

1. 人是很容易健忘的

特别是产品经理每天要和研发、运营以及和业务方沟通，会记录大量的反馈和要求，如果没有一个地方来管理这些内容，我都想象不到工作该有多混乱。

甚至在思考业务的时候，产生灵光一现的想法，比如半夜睡不着，想到一个不错的方案，如果不记录下来，很可能再也无法想起来。

2. 需求池给自己看的

刚才说了，人是健忘的，很多信息如果不及时记录，那就等于以后不会在想起来做。有一个记录清晰，分类明确的需求池，也是帮助产品经理做好产品规划的好武器。

3. 需求池是合作伙伴看的

运营、销售、市场或者兄弟团队给我们提了那么多需求，现在进度怎么样了？

老是来问你也不是个事，有个需求池一目了然，减少不必要的沟通，也能增加你在合作团队中的靠谱度，让合作的小伙伴明白你的计划和进度。

版本规划要用到版本的内容，很大程度上来自需求池，也是版本迭代的一部分。

二、完整记录原始需求

做好需求池管理的第一步：完整记录原始需求。

虽然不是所有的需求都会进需求池的，但要尽量保证完善的记录反馈结果，或许沟通的时候觉得不合理，回过头来思考，或许还会有新的发现。

沟通原始记录：谁反馈、什么问题、场景。
需求池是作为沟通的原始记录，要包括以下几个信息：

• 需求来源（参与人员）：方便后续追踪和反馈；
• 场景（沟通内容）：谁在什么场景下发生的、遇到了什么问题、想达到什么结果，反馈问题的人，不一定是遇到问题的人，一定要找到需要解决问题的人。

如果是和外部团队合作，是需要确定一下合作的时间节点，避免影响进度。

收集需求的过程中，和不同类型的用户沟通，方法也不一样。
比如面对核心客户或核心支撑的业务团队，除了接收反馈，还要主动探听业务目标和场景。

特别是 B 端业务，因为他们是跑在其他客户或业务的前面，我们要通过和这些用户紧密配合，让我们的产品时刻保持行业领先，通过解决核心用户的问题，给其他用户提供业务思考和解决方案。

三、需求分类、设置优先级并反馈

拿到这么多需求，我们要把需求管理起来，形成我们的工作内容。整理需求的过程，就是把用户反馈，翻译成产品需求，分类并制定优先级。

在整理需求之前，产品经理内心要明确 2 件事：负责产品的定位，以及当前阶段产品的目标。这样才能在管理需求的时候，有统一的衡量标准，确定好需求的优先级。

优先级的方法很多，比如说紧急重要 4 象限等，我这边的优先级划分标准：

1. bug：评估影响，要尽快解决；
2. 老板需求：尽快解决，给你发工资的人，偶尔给你提一个需求，难道还要拒绝？还不赶紧处理好？
3. 能给业务或客户带来直接价值的大小，确定优先级高低；
4. 与产品的定位契合，与公司发展大方向有关的，虽然和现阶段目标无关，但也是要记录到需求池中，虽然优先级可能不高，但会比较重要，需要时常拿出来看看。

   1. 结果反馈

   我们做完需求分析、分类、优先级划分后，要给提需求的小伙伴一个直观的反馈：比如说 bug 马上修复，或需求在未来 1 个月内上线，甚至如果需求不符合当前产品的定位，可以拒绝。

有一个明确的反馈，业务小伙伴也会根据你的节奏，配合你的工作。

2. 需求池参考格式

举个例子：内部运营工具自动应答工具，不支持设置的关键词搜索，业务团队也反应过好几次，那这个要不要立即做呢？

看下产品当前阶段的目标：当前是要做一款快速拉新工具，帮助运营团队快速获客。虽然自动应答工具搜索不好用，但搜索的场景极少，遇到这种情况，可以查数据库解决问题。于是这个需求的优先级设置的比较低。

最后给业务团队反馈：已列入需求池，遇到类似问题找产品解决，但近半年不会有调整的计划。

四、避免踩坑

需求池最终是服务于版本的，B 端产品经理一定要在深入理解业务的前提下，整理需求并与业务验证，基于业务的目标来制定版本。

在收集需求时，要确保信息的完整和准确，不要想当然的加戏，添加一些自己想象出来的需求，虽然有可能给客户一些惊喜，但大概率是给自己挖坑。

产品教练

产品教练