B端产品的需求决策模型及实践指导

人人都是产品经理 • 4年前扫码分享

我是创始人李岩：很抱歉！给自己产品做个广告，点击进来看看。

提升需求决策的质量或业务决策的质量是产品最重要的必修课，保持持续高质量的决策水平，能够保证团队的效率，提升公司内部管理效率。

B端产品的需求决策模型及实践指导

需求决策质量对个人和团队效率都起到杠杠作用，好的模型可以降低对个人能力的依赖性，减少变动变量，减少需求决策过程中的不稳定性，提升需求决策质量。

B端产品的需求决策模型及实践指导

01 为什么要构建需求决策模型

需求决策是产品经理的基本&重要的工作，这部分工作影响了后续成倍的工作量，对团队工作的质和量都起到杠杠作用，需求决策的正确率影响了团队/公司的效率及机会。

需求决策在没有框架指引下，高度依赖产品经理的个人经验及素质，并且即便是同一个产品经理，面对不同的场景时，其需求决策的质量受限于其经验和知识背景，也具有一定的不稳定性。

需求决策模型可以将需求决策过程中的影响因子提炼出来，将部分的因子通过产品团队整理和共同迭代变成固定变量而非依赖个人判断的可变变量；通过需求决策过程的把控，降低个人决策的不稳定性，提升需求决策的质量；通过需求决策过程中的中间输出结果整理，也可以让相关人员或其他产品经理协助识别需求决策过程中可以的判断错误，进而提升需求评审环节时的有效性。

02 B端产品的特点及对需求决策模型的要求

B端产品普遍是付费产品，B端产品需求的决策很可能会直接影响续约或新签，而部分对用户有很大价值，但对续约或新签没有价值的功能优先级也可能会低。B端需求决策模型上，公司商业价值影响因素更大，如对续约的影响，对新签的影响等。

而C端产品在刚开始普遍是免费产品，更多的考虑用户价值，较少的考虑商业价值，而后期即便考虑商业价值，商业价值和需求功能之间的关联性较B端也是相对弱。

因此，一些C端常用的KANO模型、四象限模型可以作为判断用户价值的辅助，而不能直接应用于B端需求决策模型。

B端产品的需求决策模型及实践指导

KANO模型

四象限模型

03 公司业务梳理

1. 基本框架：用故事地图梳理短期固定变量

B端需求决策前，最重要的是梳理清楚业务逻辑，这里的业务逻辑包括业务角色、业务场景、业务场景中涉及的功能特性，业务在商业中的价值，以及战略定位。

这些对于一个公司而言是短期不会变，是需求决策的基础框架。而这些基础框架则构成了需求决策过程中的固定变量（短期的固定变量，长期可迭代）。 基础框架影响决策模型，保证整体需求内容不偏离主航道，而不被单点价值影响 。

用户故事地图是很好的梳理业务角色及业务场景，并可以结合业务商业价值及战略定位的一个实用工具。举例如下：

2. 用户故事地图实践指导

首先，用户故事地图最重要的是梳理清楚业务角色、业务故事（流程）、故事细节，及对应的商业价值和战略定位。这里面涉及一些定义，如下：

用户情绪：业务环节中，用户情绪越低用户价值越大（在价值判断的时候参考，不一定在用户故事地图中画出）
用户价值：（新体验价值-旧体验价值）-替代成本（评估商业价值的时候需要用到）
商业价值：（用户价值*付费比例）*（付费意愿*用户群数量）
战略定位：由公司战略层根据公司定位、战略、当前发展确定

其次，以季度或年度刷新企业级别的用户故事地图，基于市场环节的变化和领导层认知的变化及时刷新用户故事地图， 理论上B端产品的企业级别用户地图一旦确定，短期很少变动，即便变动也更多的是变动“故事细节”；

最后，企业级别的用户故事地图在短期对于需求决策模型来讲是固定变量，这里可以减少因不同产品人员能力或认知偏差造成的偏离大方向。 企业级别用户故事地图中故事的模块对应的商业价值和战略定位，作为需求决策表的输入参数。

04 需求决策影响因素梳理

1. 个人能力：用户洞察

用户洞察是对用户的理解和对用户场景的理解，这是一个持续加强的部分，比如用户当前是怎么解决问题的？是否有其他替代方案？用户是否会从当前的解决方案中迁移过来？如果不做有什么不好？

对用户洞察的能力会直接影响主观判断部分的准确度，断产品价值的时候会有偏差【（新体验-旧体验）-迁移成本】，这里可以通过公式的分解，在需求评审环节，其他同学帮忙把关。

2. 其他需求决策的影响因素

需求、需求面向的用户群、解决的问题、当前用户的量级、当前用户频次、目标用户的量级、目标用户频次、时效性（紧急程度）、前置需求、对用户实际价值、用户的可感知价值、开发成本、其他成本、是否影响续费、是否影响新签、其他商业价值、投入产出比等。

这里有的因素是比较容易判断的，也不容易出错如当前的用户量，这样依来产品人员中等水平即可。

有的因素比较容易依赖个人经验、能力判断，比如用户可感知价值、商业价值等， 这些比较依赖个人经验、能力判断的因素也是需求评审过程中的重点 ，需要产品团队协作把关。

3. 梳理一个最稳健的需求决策表

需求决策表是将需求评估时涉及的各维度均考虑到，以降低需求设计过程中忽视的因素或存在的漏洞，比如“价值感知度”评估，也可以让产品设计同学更多的考虑如果让用户感知到该功能或特性的价值，以优化产品设计，“其他人力成本”也可以让在需求评估的时候除了考虑研发成本也考虑到需求上线之后的其他事项，如下：

4. 需求决策表补充说明

需求决策表维度梳理：

需求决策表的维度是在四象限模型基础上衍生，结合自己多年的产品经理经验逐步拆解、梳理及归纳而来。

字段补充说明：

用户可感知价值=用户实际价值*可感知度
投入产出系数=（总价值度*用户量）/总成本，使用投资产品系数，是因为一个功能（仅是产品的很小一部分）的价值很难直接用钱来衡量，这里用相对值来替代人民币的值，用投入产出系数替代投入产出比
前置需求：前置需求为1不代表不做，前置需求和当前需求如果并行开发，则也可以接纳，但不建议；
紧急程度：有的是因为客户投诉原因紧急，有的是因为配合用户年度周期性场景紧急，如展会场景；圣诞节祝福场景；因为借助这些场景可以借势，所以也就相对紧急。

字段底色说明：

橙色底：是来自于用户故事地图的固定变量；
黄色底：是相对固定的变量，即不太容易错的部分，但评审的时候需要关注；
红色底：是更依赖相关人经验、能力判断的部分，也是评审的重点；

应用说明：

可以跟进自己的业务、产品、特性适当调整需求评审表，如增加需求的来源，需求负责人等在评审需求的时候好追踪；
一次评审的需求不应该过多，当需求过多的时候，不同小团队应该内部按需求评评审表过滤一遍需求；
需求评审表可以做简化，但应尽可能的让强大依赖人的经验评估的部分变得可拆解；
需求对应的公司级别的/大业务级别的用户故事地图是需求评审的基础框架，保证需求不要偏离主航道，因为虽然有的需求单点投资回报率高，但如果偏离主航道，那么不利于构建主航道的价值壁垒，当一个需求涉及多个故事模块的时候可以以商业价值或战略定位价值高的模块为准；
需求评审表中生的投资产出系数、紧急程度、模块商业价值、模块战略价值，构成需求决策模型的4要素，生成需求决策图；