B端产品在需求搜集、分析、迭代上线的方法上与C端大同小异，但由于B端产品使用对象的角色多样性，跨部门协作的流程复杂性，B端产品的需求管理相比于C端“坑”更多。

作为一名B端产品运营，你是否面对和处理过这类问题：

• 销售吐槽：新功能客户不买单，真正亟需解决的问题没解决；
• 客户生气：某个常用的功能突然下架而中断使用，某个功能答应了做却未按期迭代上线；
• 客服怒怼：产品功能布局分散影响培训客户的效率；一个功能突然上线，客户问起我们竟然才知道；
• 运营哭了：需求来自客户、销售、服务、风控、法务等部门，搜集、分析和管理乱。

以上这些问题我都遇到过，掉在同一个坑里的场景也不在少数。在这个过程中整理了本文，提醒自己长记性，如有总结的不对的，欢迎大家指出~

B端产品需求管理的“坑”主要分布在需求采集、分析、迭代上线三个阶段：

一、需求采集

避坑指南姿势一：收拢需求采集渠道，建立共享需求反馈池，根据需求类型及迭代状态进行分类管理，让需求采集及时记录不遗漏，需求规划及进度一目了然

B端的需求来源分为公司内部和公司外部，细分如下：

需求来源角色多，反馈的信息杂，采集需求的效率低，容易出现错漏。对于以上各渠道反馈的问题和需求，如果完全由运营对接，不免焦头烂额，如果漏掉重点需求，还将造成客户投诉。基于此：

1）针对各渠道建立统一对接人。比如SMB客户的反馈汇总至客服，KA客户反馈汇总到客户成功，销售需求汇总至销售支持；

2）通过各渠道对接人将需求共同维护至共享文档，建立需求池，及时记录，在开始新一轮评审时进行需求方的提醒、补充，避免遗漏；

3）对已上线的需求、已提测的需求、挂起的需求、当前迭代已确认的需求，可进行单独建表管理；

4）经常review以及重新排定需求池的优先级，基于新的变量的出现，重新整体排一下需求的优先级；

各环节进度在表格中的呈现如下，供参考：

该表流程主要为需求侧、产品侧和运营侧，未提及技术侧（比如评审时间、UI、各端开发时间、提测时间等）。

避坑指南姿势二：对业务侧宣导需求初筛规则，在需求首次被提及时，需求反馈对象或需求对接人可对需求进行初筛和答复客户。

对于客户需求，无原则的统一收下并承诺支持，不一定能获得客户的认可。一方面，客户提出需求时，说的是解决办法，而我们真正要了解的是客户的痛点，并给出可行的解决方案。

另一方面，某一功能是否当下立刻满足，不一定是客户为之买单的根本原因。当需求在首次被提出时，业务人员无须像产研侧一样，掌握Y模型、5W2H等需求分析方法，但可提供基本的初筛规则，可帮助在前期过滤掉不少不合理需求。

另外，无论是业务侧还是产研侧，在拒绝需求时都要注意语言的艺术：

1. 不要直接对对方的想法提出异议，而是站在对方的立场上思考问题，给出解决方案；
2. 如果方案很多，可从最为重要的可以给客户带来利益的三点着手，引起客户兴趣；
3. 表明方案时，要表明确定的信息，简明扼要，言简意赅，不要反复修改，避免让对方产生厌恶情绪。

二、需求分析

避坑指南姿势三：对于客户需求，用心听，但不要照着做，用5W1H1V方法深挖客户需求

需求分析是指从问题到解决方案的转化，或者说从用户需求到产品功能的转化。创新工场董事长李开复曾发微博说道：“很多工程师和产品经理不了解：顾客要买的其实不是某个产品，而是他们需要运用一个产品来完成某件任务或解决某个问题。”

有句著名的话：“顾客不是要买钻头，顾客要买的是洞。”更进一步说，用户要买的不是洞，而是洞背后反应的更深层次的需求。用户需求背后是目标和动机，更深度的是深度价值观，是人性需求，即马斯洛需求。

因此，为避免中间人传达的信息误差，产品运营在收到需求时，应组织与客户直接交流，以客户提出的解决方案为起点，运用5W1H1V方法分析问题，先将这六个问题列出，得到回答后，再考虑列出一些小问题，并对问题进行综合分析研究，从而产生更新的创造性设想或决策。

1）What（对象） —— 可以用这个产品或功能能做什么？解决什么问题？

2）Where（场所）——在哪会用这个产品或功能？

3）Why（目的） ——为什么需要这个产品或功能？和其它产品的区别？

4）When（时间） ——在什么时候会用这个产品或功能？

5）Who（人员） ——产品或功能为谁设计？谁来用?

6）How（方法） ——如何使用这个产品或功能？

7）value（价值） ——产品的价值？

避坑指南姿势四：在沟通后存在需求变动时，及时留下会议记录，并更新相关文档；需求评估阶段，相关部门都需参加评审，验收方案

为避免客户需求反馈片段分散，提升需求沟通效率，需引导客户完整体验产品，提出不足之处。经过需求沟通后，如有修改，需及时修改文档，避免因为历史文档，导致错误开发；为了避免解决方案与用户需求不符，造成资源浪费，在方案原型阶段需跟客户进行可用性确定。

另外，B端产品的功能使用角色不仅一个，进行功能设计、评审、上线时，需做到多方信息确认，举几个例子：

1）涉及风控和合规的业务，相关功能上线涉及审核机制或敏感词库的建立；

2）对于现有客户能感知到的产品变化，需要与客服同步，并做好上线时的客户通知；

3）对于客户的定制化需求，如设计为通用需求，将给业务带来咨询与处理压力…

三、迭代上线

避坑指南姿势五：上线时间避开产品使用高峰时段

不要为了赶上线时间，把需求安排在周五或临近下班的时间点上线。出现问题时影响客户体验，且难以召集人员解决，上线时间应尽量固定时间在非周五、非产品高频使用的时间段。

避坑指南姿势六：需求方参与上线验收

除测试、产品对产品进行验收外，运营、需求方需先对产品进行验收后，再上线、引导客户使用，避免漏掉上线需求，或有使用问题。

避坑指南姿势七：上线及效果评估准备

上线前做好相关团队培训，准备上线通告、使用指引。如需同步上线推广，需提前准备好上线推广的内容和活动素材；通过上线前后的产品数据分析、渠道反馈等，进行效果评估。

需求管理贯穿整个团队，产品的需求管理不只是需求的记录，而是需求的策划、实现、效果评估都需要。每个团队需求管理方式可能都不尽相同，适合的方法论才是最好的，如果你也踩过什么坑，欢迎留言分享~

作者：产品运营术与道

来源：产品运营术与道

相关阅读：

如何做好平台B端运营？

B端运营活动复盘：找准目的和用户