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

需求管理是产品经理日常工作中很重要的一环今天阿G 就结合自己的一些工作体会，和大家聊聊这个话题我把需求管理拆分成这6 个部分：需求收集、建立需求池、需求分析、需求反馈（需求排期）、需求跟进、需求变更需求收集1. 需求来源我把 B 端产品的需求来源，总结成3 个维度1）内部需求：公司内部的需求2）外部需求：公司外部的需求3）自创需求：产品经理自己YY 的需求2. 收集手段工具的话，这里推荐我偶像苏杰老师的需求采集「Z」苏杰老师的「Z」模型虽然这个工具表面看起来比较适合 C 端产品，但万变不离其宗，其核心思想我们完全可以移植到 B 端产品上具体可以自行搜索，这里就不过多赘述了我结合上面需求来源，再讲讲实际工作中每个维度有哪些收集的手段1）内部需求：业务反馈、头脑风暴通常业务方有需求会及时的向你反馈（有时候会多到数不清下面会讲如何做需求过滤），毕竟业务同学也希望尽量通过系统解决不必要或重复的人工2）外部需求：调查问卷、客户访谈、客户反馈如果你做的 B 端产品是带有商业化属性，那么很多需求都会来自甲方爸爸这个时候定期的客户访谈、调查问卷就必不可少了当然，作为一名合格的产品经理，不应该整天坐在电脑前等着别人来反馈需求。

我们应该更主动、更积极去沟通，去调研，去挖掘需求，这样才能得到更快的成长3）自创需求：有些时候我们也会通过：数据分析、经验总结，去自创需求建立需求池收集了很多需求后，就需要建立需求池来管理这些需求接下来我们就一起重新认识需求池1. 工具一般我们使用Excel、禅道、JIRA等工具来建立需求池2. 使用原则3. 包含信息通常建立需求池时，需要包含以下信息：（ * 为必填项）需求池模板截图4. 分类在大一点的产品团队里面，有时候是多个产品经理负责同一个产品/产品线，这时就要把需求池划分为：个人需求池、团队需求池原则上个人需求池是为团队需求池服务的需求分析需求收集完，也建立好需求池，接下来就是重头戏：需求分析而需求分析的第一步，就是根据需求内容的必要性、合理性、完整性、可行性去筛选、过滤1. 需求过滤根据工作经验，我总结出 3 大需要过滤的需求：1）不用处理的需求：一般这种需求，都有以下3 点明显的特征2）不合理的需求例如 OA 流程，某些业务方要求上线自动审批这个需求咋听好像可以提升业务方的工作效率，其实非常不合理自动审批是否意味着这些节点可以不用出现在流程上？如果需要查看流程内容，直接将审批节点换成抄送节点即可。

我们不能被业务/客户带着走，得时刻“提防 ”着他们，要想清楚需求内容和现实业务指标是否匹配，区分想要的和 需要的应该做和 可以做3）非体现本质的需求最经典的就是那句 “想要更快的一匹马 ” 在实际工作中，有很多需求方自以为懂产品、懂研发，就会直接和你说这里要怎么做、应该这样做、做这个功能就行了 我们绝对不能照着做，只需要用心去倾听需求，然后用自己的专业能力把业务需求转化成产品需求一定要学习如何透过现象看本质（听起来挺玄乎的，但真的得这么做），不然你永远都不知道，业务/客户提的需求下面暗藏了什么 2. 鉴别伪需求上面讲了这么多种需要过滤的伪需求，那在实际工作中，我们应该如何去鉴别那些没有真实使用场景的伪需求呢？在这里给大家介绍一个工具： 5W1H 1） WHO ：场景中都有哪些角色参与2） WHEN ：在什么时间点发生3） WHERE ：在哪种场景下发生4） WHY ：需求的背景和动机5） WHAT ：需求方表达的需求是什么（他们到底要什么）总结一句话：谁，在什么时候，什么场景下，为了达到什么目的（获得什么收益），干了什么事情3. 需求分类通过前面两步，我们就可以筛选出合适的需求，那需求分析就算完了吗？不，还差最后一步：需求分类。

我们可以用「重要紧急四象限」这个工具，结合实际的投入产出比来做分类 B 端产品不建议使用 KANO 模型，收效甚微）1）重要紧急：马上做，例如线上 BUG2）重要不紧急：未来做，制定版本迭代，例如3）不重要紧急：下次做，4）不重要不紧急：不做，同时反思一下自己，为什么经过前面两步之后，还有这种需求进入需求池需求反馈（需求排期）接到需求，并且做完需求分析后，我们要尽快告诉提需求者结果，给人留下 “件件有着落，事事有回音” 的好印象，毕竟产品经理是很需要在团队中构建影响力的根据刚才的需求分类，如果是重要紧急的需求，那么就应该将需求分析的结果（最好附上原型）以文档的形式和提需求者确认B 端产品一般需要和业务/ 客户确认的内容：如果不需要再修改，那么最好以邮件的形式再正式确认一遍，甚至是可以打印出来让对方确认签字，避免日后背锅需求跟进正式确认需求后，我们要做的就是需求跟进，一般分为以下几点：1. 需求评审如何做好一场完美的需求评审，其实是一件很有技术的工作首先我们写完文档后，不要着急约会议室、约人来做需求评审，那样大概率你会被各种人怼到怀疑人生应该先把文档初稿，拿给上级领导看一下，让他帮你做一些修改。

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

解决办法：可以尝试使用 MECE 原则（相互独立，可以穷举），将业务流程每个节点的异常情况都考虑进去2. 开发 /技术方案有问题系统的架构不具备低耦合、高可用的特性，在后期维护就比较容易出问题解决办法：在系统建设初期就要考虑后期扩展；或者后期维护时，定期抽出一些时间来做重构（内部B 端产品更应该如此）3. 业务 /客户变更这点真的是避免不了的，不管前期说得多好，想变的时候他们绝不手软。