1、面向人群、场景的差异

从字面解释，应该是Business，也就是商业，具体点来说就是从事商业活动的商业机构主体。

主体其实是个组织，由一群不同角色的C构成，不同角色的C有不同的工作职能，有不同的工作场景，也有不同的需求。

一般不同的角色C之间有职能或业务上的关联性：

比如a是b的领导，b的采购申请单需要经过a审批；

比如a是护士，b是医生，a处登记的患者就会出现在b的待接诊列表中。

而C端产品面向的客户往往是一类具有相似特征的人群，他们往往具有很多高度相似的共性属性、场景、痛点和需求，我们可以简单理解为一种角色：

比如一群宝妈，他们大都有针对婴幼儿的饮食、护理、疾病相关的生活类问题；

比如一群产品经理，他们大都有针对产品类的知识学习和话题讨论等需求

所以to B和to C产品面向的人群角色种类往往是不同的。

To B类的产品需要解决不同职能的人群在不同场景下的需求，而且场景之间具备不同程度的关联性，要求更全面；

To C类的产品则主要解决某一类高度相似的人群在几个主要场景下的痛点需求，会更聚焦。

2、使用决策者的差异

To B产品哪些方面应该满足使用者，哪些方面满足决策者的需求？

To B产品在做产品定位的时候，一定要注意一点：定位需要契合决策者的核心诉求。

产品最后一定是由决策者买单，虽然使用者的使用感受会对决策者是否购买该产品产生很大影响，或者说决策者本身也是使用者。但是决策者更会从是否对整个组织的目标有益的角度考虑购买

比如使用者（员工）最希望产品使用易用；

但是决策者（老板）更希望产品能够帮助组织提升效率、提高收入能力、降低成本消耗。

比如希望有强大的营销功能，帮助组织强化引流能力，从而带来更多的订单和销售额。

这两个目的都是基于自身的立场出发的，并没有对错。

员工希望操作简单、便捷，这样自己工作更轻松，

而老板希望通过产品帮助组织提升各方面能力，并带来更多的收入。

本质上两者并不冲突，但是当产品只考虑使用者的需求，而忽视决策者的需求时，那么它被购买的几率就大大降低了。

所以，在优先级上，产品最优先的应该先满足决策者的需求，其次才是使用者的需求。

而to C本身使用者就是决策者，其立场也是一致的。

3、客户调研方式的差异

To B ：去一线接触客户，客户描述的需求≠客户真正的需求。

To B客户的调研方式离不开直面一线客户，直面客户工作的环境，实际的线下场景，

绝不是坐在办公室，仅靠看看行业分析、数据统计、客户案例就够了的。

每个行业都有其独特的专属的特性，而且大都较为复杂、场景众多、流程环绕、影响因素众多，这么一件复杂的事，必须要亲自到一线环境下去体验才能有更切身的体会、深入的认识。

实地调研+线上采访+客户数据的观察分析，是to B客户调研的3大利器。

能保质保量的执行上述3大利器，基本不会产生很大的偏差。

而且因为to B的场景复杂，客户提供的需求，往往夹杂着各类因素的影响和其主观意志，所以如何去伪存真，让需求还原本质，则是to B产品经理很重要的一项能力。

在这个行业，产品经理是很容易被“污染过”的间接获取的客户需求带偏的，最后会导致各种问题

客户说了A需求，结果A做出来后实际要B；

产品最后变成了给客户定制了，缺乏通用型；

客户说了A需求，但是其实他并不着急用A，损失需他需求排期做了A却不用等等。

所以to B的需求调研的第一选择，永远是直面客户，到客户中去。

To C：选准用户群体，明确用户画像，通过平台数据不断精细化，通过数据分析和场景化思维挖掘用户的需求+问卷调研+用户访谈。

4、需求分析的原则差异

To B需求分析模型：

5、产品设计侧重点差异

To B：最终的产品形态一定是庞大的，分支众多、功能全面，我们常常看到saas产品有非常多的模块，如果不区分模块，会让整个产品无法结构化，功能之间都是杂糅在一起，非常混乱。

To C：则相对清楚很多，功能也没有saas那么庞杂。

因为to B业务往往是由多个子业务构成，子业务之间具有强关联性。

因此当你要做一款面向市场销售的to B产品时，你无法通过一个小业务、一个小场景、一个小功能去满足客户，客户大概率不会愿意为此买单的。

你首先需要形成一个最小产品闭环（MVP），他可能由多个模块构成，解决to B客户核心流程，或者部分分支流程，前提一定是闭环的流程。

这是模块之间的闭环。

客户只为一套满足组织运作的系统买单，除非他找不到更好的。

比如腾爱医生，作为一个轻量化的面对B的在线咨询产品，在诊所saas系统还未发展起来的时候其实是非常受欢迎的，哪怕他没有核心诊疗环节的功能，也受到了很多诊所的青睐。然而毕竟作为单一功能的产品虽然适合切入，但是其竞争力却无法和整体解决方案的saas产品相提并论，后来随着很多诊所saas陆续上新在线咨询的功能后，腾爱被迫下线关闭。

而to C可以只提供一个功能就能面世，比如提供一个手机充值功能，当然其也要满足闭环的要求，只不过这是模块内的闭环。

6、产品价值差异

B端产品在需求分析时必须仅仅围绕为用户提供最高效、完整的解决方案。

这里有两个关键字：高效率、完整。缺一不可。

什么是提高效率？

下面各种生活工作场景中的案例，都可以被定义为提升效率：

（1）原先用手写的菜单，搬到线上电脑上点击一下已经内置的菜单名进行点菜，缩短了时间

（2）原先线下需要3步操作的，搬到线上只需要2步了，缩短了流程步骤

（3）原先填了报销资料需要拿到财务室，财务再进行审核，搬到线上直接将流程提交给下一步财务，减少了实际线下场景的不便利性

（4）原先需要一个个数据地核对金额，现在直接通过一张线上对账单就可以一目了然，自动对账，降低了工作的复杂度

。。。。

这些例子都是在各种维度上提升效率，从而为B端客户带来价值。

什么是提供完整的解决方案？

比如为B端客户提供一套系统，帮助他有能力运营从线上潜在客户——线上成交客户——进店客户——出店后客户维护，等全场景、全流程的解决方案。

To C的产品核心目的：

1、给C端用户提供了某种独有价值：可能是一项更高效的服务、价格更低的产品、传统方式无法获取的产品（海购）等等

2、提供良好的用户体验

3、挖掘用户的价值，这种价值可以是传播价值、互动价值、商业价值。

7、产品主导权差异

虽说to B的产品和to C的产品都是基于用户的痛点寻找解决方案的，但是两者有很大一个区别：

我们假设做的是一款面向to B的saas类工具，而不是基于B to B、或者B to C的交易平台

从工具角度来讲，我们要为B提供工具来解决B在传统业务中遇到的困难。

B端业务经过多年的发展，都有一套相对科学、稳定的成型流程，这是被B端相对复杂的环境验证过的，因此其形成的各个职能分工（模块）、各个业务流（流程）、各个角色下的具体工作（功能）、各种类型的数据（字段）都具备较强的历史沉淀，且符合其自身特点，我们需要“尊重”他们，不能随意地进行主观修改。

当然并不是说我们要把这些传统的线下的东西一摸一样照搬到线上，我们依然可以将其中那些明显低效、复杂、不合理的“模块、流程、功能、字段”进行简化、或者优化，最终达到提升整体业务效率的目的。

因此 to B产品的主导权相对较低，受原先的线下业务限制较多。to B的产品很大程度是由客户、行业决定，而并非产品设计者，产品设计者需要理解行业，理解客户，而并非基于自身的想法进行产品设计。

不然做出来的产品，要么无法被使用，要么会被吐槽很难用，那将是灾难性的。

而C端产品可以做很多自主设计和创新，比如业务创新、功能创新、交互创新。。。

To C产品完全可以自主决定发展方向，在制定产品战略时不需要过分考虑像to B的既有业务，自主性就会大很多。

8、对产品经理能力要求差异

To B ：要求了解行业，很强的业务理解能力、逻辑能力、结构化能力、流程化能力、项目推进能力、一定的技术积累

To C：逻辑能力要求相对低些，需要市场和用户嗅觉、敏锐度和创新意识