编辑导语：需求，是产品经理不可避免的工作日常。产品经理每时每刻都在与需打交道，因此必须处理好需求，工作才能顺利地进行下去。所以，产品经理需要在工作中建立自己的“需求池”，让需求宽进严出，保证开发的需求都是有助于产品发展的。而如何管理好需求池，这是产品经理必须练好的基本功。
产品经理的日常工作中，最频繁的一项是「接需求」，特别是 B 端产品经理。记得有一次和朋友聊天，说刚入职的时候有需求池中 100 条记录，工作 2 年离职后，需求池中只剩下 300 条了。
如果你感觉每天被需求包围，东一头西一头忙忙碌碌而无价值产出，那就好好思考下，是不是需求池管理出了问题。
一、为什么要做需求池管理？
1. 人是很容易健忘的
特别是产品经理每天要和研发、运营以及和业务方沟通，会记录大量的反馈和要求，如果没有一个地方来管理这些内容，我都想象不到工作该有多混乱。
甚至在思考业务的时候，产生灵光一现的想法，比如半夜睡不着，想到一个不错的方案，如果不记录下来，很可能再也无法想起来。
2. 需求池给自己看的
刚才说了，人是健忘的，很多信息如果不及时记录，那就等于以后不会在想起来做。有一个记录清晰，分类明确的需求池，也是帮助产品经理做好产品规划的好武器。
3. 需求池是合作伙伴看的
运营、销售、市场或者兄弟团队给我们提了那么多需求，现在进度怎么样了？
老是来问你也不是个事，有个需求池一目了然，减少不必要的沟通，也能增加你在合作团队中的靠谱度，让合作的小伙伴明白你的计划和进度。
版本规划要用到版本的内容，很大程度上来自需求池，也是版本迭代的一部分。
二、完整记录原始需求
做好需求池管理的第一步：完整记录原始需求。
虽然不是所有的需求都会进需求池的，但要尽量保证完善的记录反馈结果，或许沟通的时候觉得不合理，回过头来思考，或许还会有新的发现。
沟通原始记录：谁反馈、什么问题、场景。
需求池是作为沟通的原始记录，要包括以下几个信息：
- 需求来源（参与人员）：方便后续追踪和反馈；
- 场景（沟通内容）：谁在什么场景下发生的、遇到了什么问题、想达到什么结果，反馈问题的人，不一定是遇到问题的人，一定要找到需要解决问题的人。
如果是和外部团队合作，是需要确定一下合作的时间节点，避免影响进度。
收集需求的过程中，和不同类型的用户沟通，方法也不一样。
比如面对核心客户或核心支撑的业务团队，除了接收反馈，还要主动探听业务目标和场景。
特别是 B 端业务，因为他们是跑在其他客户或业务的前面，我们要通过和这些用户紧密配合，让我们的产品时刻保持行业领先，通过解决核心用户的问题，给其他用户提供业务思考和解决方案。
三、需求分类、设置优先级并反馈
拿到这么多需求，我们要把需求管理起来，形成我们的工作内容。整理需求的过程，就是把用户反馈，翻译成产品需求，分类并制定优先级。
在整理需求之前，产品经理内心要明确 2 件事：负责产品的定位，以及当前阶段产品的目标。这样才能在管理需求的时候，有统一的衡量标准，确定好需求的优先级。
优先级的方法很多，比如说紧急重要 4 象限等，我这边的优先级划分标准：
- bug：评估影响，要尽快解决；
- 老板需求：尽快解决，给你发工资的人，偶尔给你提一个需求，难道还要拒绝？还不赶紧处理好？
- 能给业务或客户带来直接价值的大小，确定优先级高低；
- 与产品的定位契合，与公司发展大方向有关的，虽然和现阶段目标无关，但也是要记录到需求池中，虽然优先级可能不高，但会比较重要，需要时常拿出来看看。
1. 结果反馈
我们做完需求分析、分类、优先级划分后，要给提需求的小伙伴一个直观的反馈：比如说 bug 马上修复，或需求在未来 1 个月内上线，甚至如果需求不符合当前产品的定位，可以拒绝。
有一个明确的反馈，业务小伙伴也会根据你的节奏，配合你的工作。
2. 需求池参考格式
举个例子：内部运营工具自动应答工具，不支持设置的关键词搜索，业务团队也反应过好几次，那这个要不要立即做呢？
看下产品当前阶段的目标：当前是要做一款快速拉新工具，帮助运营团队快速获客。虽然自动应答工具搜索不好用，但搜索的场景极少，遇到这种情况，可以查数据库解决问题。于是这个需求的优先级设置的比较低。
最后给业务团队反馈：已列入需求池，遇到类似问题找产品解决，但近半年不会有调整的计划。
四、避免踩坑
需求池最终是服务于版本的，B 端产品经理一定要在深入理解业务的前提下，整理需求并与业务验证，基于业务的目标来制定版本。
在收集需求时，要确保信息的完整和准确，不要想当然的加戏，添加一些自己想象出来的需求，虽然有可能给客户一些惊喜，但大概率是给自己挖坑。
#专栏作家#
司马特小队，公众号：司马特小分队，人人都是产品经理专栏作家。8年+互联网资深产品经验，多年B端产品管理经验。具有多个从0到1的大型B端产品的孵化、重构、迭代经验；主要教授产业互联网产品相关的硬核知识点。