编辑导语：B端产品相比于C端有许多不同的地方，用户群体的差异也很大。本文作者总结了B端产品需求的特点，讲述了B端产品与C端产品在需求层面的差异以及B端产品产生这些特点的原因，一起来学习一下吧。

抓住特点，趋近本质。

B端产品相比于C端，有很多不同之处，这篇文章将总结两者在需求层面的差异，也是应读者之约，帮助大家做个全面的梳理，同时将分析为什么会产生这些特点，以及基于这些特点，对我们的工作有哪些启发。

一、业务强驱动

1. 现象

是指大部分B端产品的主要需求都来源于业务方，由业务驱动、业务主导，而非像C端产品那样，产品经理对需求有很大的自主权，能够基于个人理解来主导需求。甚至包括迭代节奏，有的业务方也会干预。

这也是很多B端产品经理缺乏成就感，感觉自己是个工具人的主因。

当然也有少量没有明确业务属主的B端产品，这类产品业务驱动特点就比较弱，产品经理发挥空间比较大，不过这类产品数量少，也不是主要业务领域，一般较难成为刚需。

2. 原因

根本原因是B端产品是为了解决组织内某个或某一类具体业务领域问题，而业务方是离业务最近、离使用用户最近的，所以从谁更懂用户、谁才更能真正解决用户问题的角度看， 业务方驱动产品需求是正常的，而非根据职能决定。

其次是公司特点。如果公司是强业务驱动的公司，那么这个特点就非常明显，如果公司对产品比较侧重，那么这个特点相对就弱。

3. 启发

要想与业务共同驱动产品，只有一种解决方式：不断学习业务，不断了解用户。

B端产品需求无论是业务驱动，还是产品驱动，共同目标都是为了解决业务、用户问题，所以，从目标出发，B端产品经理要想发挥更大价值，不被业务牵着走，只有不断深入业务，不断通过各种方式了解用户，尽量与用户直接、深入的交流，才能逐步提升自己的业务、用户理解力，才能逐渐与业务方共同推动产品发展，而非坐在办公室接收二手需求、YY需求。

不过这是一个漫长的过程，对业务的了解绝不是一蹴而就的，是常读常新，也需要不断迭代，对用户使用场景的了解也绝不是几次调研就能深入的，是需要持续的，从不同角度、不同场景、不同角色挖掘，才能形成全面认识。

所以，虽然我们一直在说用B端产品经理另一价值是用产品化方案解决业务问题，但不应仅局限于产品化方案。

二、不同用户群差异大

1. 现象及原因

无论是做B端还是C端产品，对用户精准分群是分析用户的基本条件之一。

当我们从不同维度对用户进行分群后，就会发现B端产品与C端产品在不同用户群体间需求关系很不一样，这里我用一张图来表现两者区别。

在很多B端产品中，不同用户群体需求差异巨大，甚至经常出现两个群体需求相互冲突，不可调和的情况。当然相互间也存在一定的交集，交集大小也各有不同。而C端产品是同大于异，需求交集远大于差异，否则就不会有这个产品的出现了。

B端产品用户群体常见差异主要有以下几个方面：

1）角色差异。不同角色，需求差异大。这是因为角色的划分一般就是按照需求内聚程度来划分的，如果需求、权限相同，就不会划分那么多角色了；

2）组织差异。不同BG、部门、业务线甚至小组，由于业务特点、管理流程、方式等差异，导致需求差异；

3）管理层级差异。在很多管理工具中，一线员工、一线管理者、中层管理者、高层管理者所形成的四个管理层级，所对应的需求差异很大，在很多场景中完全不相同或相互冲突，例如：

• 一线员工需要产品提升日常的工作效率；
• 各级管理者需要一线员工产生的各种业务、行为数据；
• 一线管理者侧重过程数据，高层管理者侧重结果数据。

管理者为了数据更加丰富、准确，就会要求一线员工做更多的事情，做的更及时，这必然与一线员工“多一事不如少一事”的诉求相冲突。

4）用户深度差异。是指新手用户、中间用户、专家用户的需求差异。因为对产品使用深度不同、背景不同所产生的需求差异，新手用户期望的是简单易上手，专家用户则期望满足更多、更丰富的深度、个性化的需求，当这类需求多起来，与新手用户功能揉在一起，必然会增加功能复杂度和使用门槛。C端产品里对专家用户需求相对照顾得比较少，因为人数较少，但是B端产品的专家用户往往是重点业务方，不能采用与C端一样的应对策略

对SaaS产品而言，除了上述差异外，还有客户间的差异

5）客户规模差异。不同规模的客户，同样业务的需求差异是很大的。小团队的管理方式与大团队的管理方式截然不同，所要求的能力和深度自然不一样；

6）客户行业差异。不同行业的客户需求差异也很大，银行与制造业、互联网与运输业，隔行如隔山，业务差异也如隔山，这也就是很多发展非常久的SaaS公司都开始做行业化的原因；

7）客户性质差异。民营企业与国企、军工与其他性质企业，客户性质的不同也是造成需求差异的原因之一。

2. 启发

不同维度的差异，所带来的启发是不同的，这里从产品经理几个日常重点工作来写一些通用启发。

1）用户调研。因为不同群体需求差异很大，所以我们做的调研，不仅要看样本量，还要覆盖同一维度多个用户群，例如我们想调研一线管理者的需求，那么就要多调研几个业务部门，来了解不同业务部门一线管理者的需求痛点，从而设计覆盖面更全的方案，提升方案的ROI，而该如何选择这些维度，主要是看哪个维度差异大。这样调研的信息才能更全面，我们的用户画像才能更精准；

2）用户分析。做用户分析也是一样，需要从差异大的几个维度对用户进行分群，然后进行分析，甚至要多个维度综合起来进行分群，例如按角色分成5类，按业务部门分为4类，如果这两个维度差异都很大，我们可能就需要把用户分成5*4=20个群体，不过这会造成分析工作量指数级上升，所以，B端产品用户分群的维度选择和划分方式需要合理取舍与平衡；

3）需求优先级。因为不同群体需求差异大甚至相互冲突，这个时候需求的取舍和优先级的划分就变得更加困难，很多C端的优先级分析方法就变得不适用了，例如我们熟知的KANO模型，在B端场景中适用范围就很小，所以在分析需求优先级时，需要从群体价值角度分析需求价值，再来判断优先级，即所面向用户群价值越高的才能更优先；

4）产品设计。如果不同群体需求在不同模块，产品方案设计还是比较简单的，但当不同群体需求汇聚在相同功能模块中时，会极大增加产品设计难度，因为你需要权衡、取舍，找到最全面的解决方案。同时为了提升功能的普适性，一般都会增加一些配置能力，但这势必增加了使用成本，尤其是新手用户，学习和使用门槛又会升高一些，就会陷入易用性与灵活性矛盾的漩涡中。

另外一个可能带来的问题是为了兼容不同群体需求，导致各个群体都没完全满足，只是满足了一部分。

5、交互设计。为了兼容不同群体需求，产品的灵活性与扩展性就有了更高的要求，因此无论是从底层数据库设计还是到界面上的交互设计，都需要充分考虑未来的扩展性，所采用的设计方式要充分兼容多种极端、异常场景。

三、复杂度高

1. 现象

无论是否设计过B端产品，尤其是C端转B端的同学，会发现B端产品相比C端复杂度要高很多，主要体现在：

1. 逻辑复杂。各种或明或暗的功能逻辑非常多、流程长、要求多，全部揉在一起，防不胜防；
2. 功能设计复杂。很多人会觉得一个应该很简单的功能，为什么要设计的这么复杂，我只是要做个筛选，为什么还要理解“或与非”，甚至还要写脚本。

2. 原因

1）产品功能逻辑复杂的背后是业务本身就复杂、场景多、流程长。这是天然的复杂性，大部分都不是从产品设计上能解决的；

2）功能设计复杂主要是因为用户使用场景众多且差异大，具体体现在

• 各类正向/逆向流程、正常/边际场景，导致逻辑上需兼容的场景多，更复杂；
• 有时候为了满足10%的专家用户的使用场景，会额外增加不少复杂度。

3）历史数据兼容。为了兼容历史数据，也会极大增加复杂性

3. 启发

• 从能力模型上。B端产品经理需要训练、提升更强的逻辑分析能力；
• 客观分析复杂性，学会区分。很多产品所体现的复杂性是背后业务逻辑导致的，我们需要仔细分析，正视这个复杂性，从而剥离出我们能够解决的部分；

四、集体性

B端产品需求的集体性包含多个方面。

1. 集体诉求优先

在B端产品中，当个人诉求与集体诉求冲突时，个人诉求需为集体利益让步。例如，同样是IM工具，当面向C端用户时，会提供诸如黑名单之类的功能，但如果用于企业内部，则不会提供此类功能。甚至有的企业通信工具还会增加类似“强制接收”的功能，如钉钉的“钉一下”、飞书的“加急”，对于信息接收方，这个功能必然会有一定的打扰，但为了提高企业内整体的沟通效率，会以集体诉求优先。

2. 同一群体需求趋同

在特点2用户分群基础上，同一用户群体内，不同用户的需求是高度趋同的，可以作为一个集体表达。可能不同用户对同一个问题有各自的想法，但其痛点大体都是一样的。

这是因为对用户分群本身就是根据差异来划分的，当根据明确边界划分完后，会发现各个群体内用户使用场景、需求差别不大。

3. 多人协作

B端产品中有很多同一个任务目标，需要一群人协作完成的场景，例如同一个对象的详情页，可能多人同时编辑，这个时候一定要有相应的产品策略支持或规避，否则就会出现数据错乱的情况。

五、喜“旧”厌“新”

1. 现象

喜新厌旧是人的天性，但B端产品恰好相反，如果不是业务变化，B端用户的需求一般非常稳定，而是“喜旧厌新”。

2. 原因

1. 用户需求的背后是业务运作方式，见我的上一篇《B端产品冰山模型》，如果业务不变，用户需求也不会有其他变化，所以B端产品需求是比较稳定的；
2. 迁移成本高。由于前面提到的各种原因，导致B端产品复杂，学习成本高，因此用户转移到新体验上的成本也比C端高很多，每次“换新”都需要重新学习、重新适应，在自己的舒适区中，没人愿意主动跳出；

3. 启发

1）把握迭代节奏。每一次改变，都是对用户习惯的冲击，改变越大，用户的反弹就会越大，所以需要比较把握好迭代节奏，在评估一定要改的前提，用小步快跑的方式推动用户习惯的变化，避免用力过猛；

2）用户习惯从“娃娃”抓起。对于一些具备条件的SaaS产品，可以从“娃娃”抓起，提前进入大学，尽早培养用户习惯，这比后面再重新做广告效果更好，例如蓝湖进入大学做的各类活动，飞书组织的校园内的“飞行家”们。

六、阶段性

1. 现象

B端产品随着业务方向、制度变化，有比较明显的阶段性，即某个时间点急需一些功能支持，过了这个时间就不再生效了。

2. 原因

业务上新制度、新规范的实施，往往需要工具上的支持，旧规则的调整，新规则的上线，需要和业务保持同步甚至前置，所以一旦业务上有变化，工具需要马上更新。

3. 启发

时间是判断需求优先级的重要因素之一，业务变化带来的需求变化有明确的时间要求，这能帮助我们更好的判断需求优先级，

七、特权

1. 现象

在C端产品中，绝大部分用户的重要性是一样的、需求权重也是一样的，这体现了C端产品“平权”的特点，当然也会存在人民币玩家与免费玩家的区别，但总体还是比较少，差距也不会特别大。

而在B端产品中，则经常出现“特权”需求（这里的“权”是指“权重”），即某些用户甚至不是用户的需求权重非常高，远高于普通用户。

2. 原因

对不同需求赋予权重，本质上是在资源有限的情况下，根据用户影响力对需求做的取舍。所以需求权重背后是提需求的人或所服务的用户对产品影响力的体现。

1. 关键干系人。B端产品干系人对产品影响力主要源于业务相关性和手中权力，业务相关性越高、手中权力越大，这些关键干系人需求就会有一定的“特权”；
2. 氪金用户。SaaS产品通常会根据付费金额、客户行业影响力对客户进行分类，其中影响力高、付费高的客户会享有一定“特权”，他们的需求会被优先满足。

3. 启发

根据这一特点，我们做B端需求价值评估、优先级判断时，就要把权重考虑进来，这里总结了一个B端产品需求优先级中判断重要性的公式：

重要性=人数×频率×节约时间×影响力

以上这些特点并非在每类B端产品中都会体现，但无论体现了哪些特点，都可以根据这些特点的启发，来指导我们的日常工作。

作者：周翔；公众号：周翔Fly；

本文由 @周翔 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。