产品经理B端产品如何做需求管理

1、需求管理是产品经理日常工作中很重要的一环。今天阿G 就结合自己的一些工作体会，和大家聊聊这个话题。我把需求管理拆分成这6 个部分：需求收集、建立需求池、需求分析、需求反馈（需求排期）、需求跟进、需求变更。需求收集需求来源我把 B 端产品的需求来源，总结成3 个维度。1）内部需求：公司内部的需求2）外部需求：公司外部的需求3）自创需求：产品经理自己YY 的需求收集手段工具的话，这里推荐我偶像苏杰老师的需求采集Z。苏杰老师的Z模型虽然这个工具表面看起来比较适合 C 端产品，但万变不离其宗，其核心思想我们完全可以移植到 B 端产品上。具体可以自行搜索，这里就不过多赘述了。我结合上面需求来源，再讲讲实

2、际工作中每个维度有哪些收集的手段。1）内部需求：业务反馈、头脑风暴通常业务方有需求会及时的向你反馈（有时候会多到数不清下面会讲如何做需求过滤），毕竟业务同学也希望尽量通过系统解决不必要或重复的人工。2）外部需求：调查问卷、客户访谈、客户反馈如果你做的 B 端产品是带有商业化属性，那么很多需求都会来自甲方爸爸。这个时候定期的客户访谈、调查问卷就必不可少了。当然，作为一名合格的产品经理，不应该整天坐在电脑前等着别人来反馈需求。我们应该更主动、更积极去沟通，去调研，去挖掘需求，这样才能得到更快的成长。3）自创需求：有些时候我们也会通过：数据分析、经验总结，去自创需求。建立需求池收集了很多需求后，就需

3、要建立需求池来管理这些需求。接下来我们就一起重新认识需求池。工具一般我们使用Excel、禅道、JIRA等工具来建立需求池。使用原则包含信息通常建立需求池时，需要包含以下信息：（ * 为必填项）需求池模板截图分类在大一点的产品团队里面，有时候是多个产品经理负责同一个产品/产品线，这时就要把需求池划分为：个人需求池、团队需求池。原则上个人需求池是为团队需求池服务的。需求分析需求收集完，也建立好需求池，接下来就是重头戏：需求分析。而需求分析的第一步，就是根据需求内容的必要性、合理性、完整性、可行性去筛选、过滤。需求过滤根据工作经验，我总结出 3 大需要过滤的需求：1）不用处理的需求：一般这种需求，都

4、有以下3 点明显的特征2）不合理的需求例如 OA 流程，某些业务方要求上线自动审批。这个需求咋听好像可以提升业务方的工作效率，其实非常不合理。自动审批是否意味着这些节点可以不用出现在流程上？如果需要查看流程内容，直接将审批节点换成抄送节点即可。我们不能被业务/客户带着走，得时刻“提防 ”着他们，要想清楚需求内容和现实业务指标是否匹配，区分。想要的和 需要的应该做和 可以做3）非体现本质的需求最经典的就是那句 “想要更快的一匹马 ” 。在实际工作中，有很多需求方自以为懂产品、懂研发，就会直接和你说这里要怎么做、应该这样做、做这个功能就行了 我们绝对不能照着做，只需要用心去倾听需求，然后用自己的专

5、业能力把业务需求转化成产品需求。一定要学习如何透过现象看本质（听起来挺玄乎的，但真的得这么做），不然你永远都不知道，业务/客户提的需求下面暗藏了什么 鉴别伪需求上面讲了这么多种需要过滤的伪需求，那在实际工作中，我们应该如何去鉴别那些没有真实使用场景的伪需求呢？在这里给大家介绍一个工具： 5W1H 。WHO ：场景中都有哪些角色参与WHEN ：在什么时间点发生WHERE ：在哪种场景下发生WHY ：需求的背景和动机WHAT ：需求方表达的需求是什么（他们到底要什么）总结一句话：谁，在什么时候，什么场景下，为了达到什么目的（获得什么收益），干了什么事情。需求分类通过前面两步，我们就可以筛选出合适的

6、需求，那需求分析就算完了吗？不，还差最后一步：需求分类。我们可以用重要紧急四象限这个工具，结合实际的投入产出比来做分类。（ B 端产品不建议使用 KANO 模型，收效甚微）1）重要紧急：马上做，例如线上 BUG2）重要不紧急：未来做，制定版本迭代，例如3）不重要紧急：下次做，4）不重要不紧急：不做，同时反思一下自己，为什么经过前面两步之后，还有这种需求进入需求池。需求反馈（需求排期）接到需求，并且做完需求分析后，我们要尽快告诉提需求者结果，给人留下 “件件有着落，事事有回音” 的好印象，毕竟产品经理是很需要在团队中构建影响力的。根据刚才的需求分类，如果是重要紧急的需求，那么就应该将需求分析的结

7、果（最好附上原型）以文档的形式和提需求者确认。B 端产品一般需要和业务/ 客户确认的内容：如果不需要再修改，那么最好以邮件的形式再正式确认一遍，甚至是可以打印出来让对方确认签字，避免日后背锅。需求跟进正式确认需求后，我们要做的就是需求跟进，一般分为以下几点：需求评审如何做好一场完美的需求评审，其实是一件很有技术的工作。首先我们写完文档后，不要着急约会议室、约人来做需求评审，那样大概率你会被各种人怼到怀疑人生。应该先把文档初稿，拿给上级领导看一下，让他帮你做一些修改。接着约上业务方，过一遍需求方案。然后约上关键研发人员，对一下里面的需求逻辑。这样一套组合拳下来，基本会议开始前，需求就已经和大部分

8、关键干系人达成了共识。除了能少挨怼，还能提升会议效率，何乐不为？需求开发终于通过需求评审，终于通过立项，你以为熬出头了？呵呵，开发阶段作为产品经理也是需要时刻关注的。研发过程中会有很多小细节，在需求评审时大家没发现，所以我们需要时刻准备着为开发同学做需求解释、需求澄清，消除信息不对称。需求测试/验收/ 上线千呼万唤，需求终于做完了，这时我们还需要充当测试同学的小助手，帮他完成测试。有时还要写用户操作手册，在需求验收阶段培训业务方。在上线阶段做开发、运维同学的秘书，帮他们检查上线清单是否有某项遗漏。效果监控上线之后，我们仍然不能掉以轻心。要通过埋点数据，看用户行为和业务效果是否达到预期，然后做下一轮的迭代计划。需求变更到目前为止，一切都很顺利。但是，实际工作中，一定会出现让人闻风丧胆的需求变更。说实话，不管需求分析阶段做的多严谨，需求文档写得多完美，需求变更通常是逃不掉的。根据工作情况，我总结了需求变更出现的几点原因：产品方案有问题产品经理的锅，别说客户的需求提供不完整，在需求分析阶段没有发现问题就只能让产品背锅。解决办法：可以尝试使用 MECE 原则（相互独立，可以穷举），将业务流程每个节点的异常情况都考虑进去。开发