B端产品运营:需求管理的避坑指南

  • 来源:网络
  • 更新日期:2020-08-05

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不要直接对对方的想法提出异议,而是站在对方的立场上思考问题,给出解决方案; 如果方案很多,可从最为重要的可以给客户带来利益的三点着手,引起客户兴趣; 表明方案时,要表明确定的信息,简明扼要,言简意赅,不要反复修改,避免让对方产生厌恶情绪。 二、需求分析 避坑指南姿势三:对于客户需求,用心听,但不要照着做,用5W1H1V方法深挖客户需求

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

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

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

1)What(对象) —— 可以用这个产品或功能能做什么?解决什么问题?

2)Where(场所)——在哪会用这个产品或功能?

3)Why(目的) ——为什么需要这个产品或功能?和其它产品的区别?

4)When(时间) ——在什么时候会用这个产品或功能?

5)Who(人员) ——产品或功能为谁设计?谁来用?

6)How(方法) ——如何使用这个产品或功能?

7)value(价值) ——产品的价值?

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

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

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

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

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

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

三、迭代上线 避坑指南姿势五:上线时间避开产品使用高峰时段

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

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

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

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

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

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

 

作者:产品运营术与道

来源:产品运营术与道