To B产品的核心本质，到底是什么？

本文转自微信公众号：人人都是产品经理（ID：woshipm），作者：帅帅的帅，优护家联合创始人、前微软小冰高级产品经理。

我本人是做To C产品出身的，但是，却在过去相当长的一段时间中从事To B产品的设计，带着我的创业团队逐渐摸索出如何做出一款被称得上还不错的To B产品，也在这个过程中学习到了To B的产品本质，以及与To C产品之间的区别。

我想花费一些时间和笔墨，通过思考和讨论的方式，来分享一些我自己做To B产品的感受和方法论，希望能够与同样是做To B产品的产品经理一起来探讨和沟通，互相学习，共同进步。

在这篇文章中，我首先尝试讨论To B产品的核心决策者，然后讨论其中关键的产品路径逻辑，并期望以此为起点，逐步开始在后续文章中深入讨论To B中的产品和运营。

To B产品中的“B”到底指代什么？

首先谈谈To B中的这个“B”。

B从字面解释，应该是Business，也就是商业。比如当年的阿里巴巴B2B电商平台，就是将采购、供应双方进行连接，从而形成供应链电商体系。

站在商业模式的角度来说，To B中的“B”指代的就是从事商业活动的商业机构主体，可是站在产品的角度来说，并非如此这么简单。

许多做To B的产品经理在经历了产品研发之后，发现产品根本无法卖出，B端机构根本不采用，其中一个很重要的原因是，B端机构中那个重要的决策者不愿意使用。

事实上，To B的很多产品都需要非常强大的市场销售体系，需要针对B端机构中最重要的那个决策者进行定向营销，从而影响他的决策。

这个关键的决策者可以是老板本人，也可以是某个具体业务的负责人，无论如何，这个角色都是To B产品能够走出去落地的关键性KOL。

为了说明决策者的重要性，我举一个例子。

在OA办公SaaS类To B产品中，钉钉可谓是一骑绝尘，曾经一度将广告刷满深圳地铁，颇有挑衅腾讯之意。随着大众创业的浪潮，面向中小企业的OA办公SaaS市场一下子成为竞争红海，众多做各种SaaS的企业冲入其中，国外红遍半边天的Slack也是这其中的弄潮儿。

由于OA在功能上，有一部分功能属于即时沟通，与IM很接近，所以微信顺理成章地加入其中，在2015年轰轰烈烈地推出了微信企业版。可是，非常遗憾，微信企业版推出至今，鲜有人用，其核心的原因就在于： 微信企业版本质上应该是To B产品，但是它并没有服务好决策者。

钉钉在推出之后，其一系列功能都是围绕着中小公司的老板打造的，就比如“Ding”这个功能，其核心目的是防止在沟通中出现“假死”——明明看到了老板的留言，却假装没看到。

但微信企业版在推出之后，所有的功能几乎都是围绕着员工开展的，并没有让老板用起来很爽的功能，反倒是因为微信企业版和微信之间有着千丝万缕的联系，导致很多老板因为反感员工工作时聊微信，而天然地反感微信企业版。

决策者在To B中是很重要的，前阿里巴巴的CEO卫哲在一次分享中提及： 所谓的B2B，其实是Business Person To Business Person，人与人之间的交易才促成了企业与企业之间的交易。我们国家酒文化流行，也是说明要向做成生意，首先要能在酒场上成为朋友。

所以To B的“B”指代的是商业机构中的核心决策者或者KOL。

To B和To C在产品路径上有什么不同？

我在比较早前的一篇文章《 进阶之路：站在高视角看产品是一种怎样的体验？ 》中，曾经提及过一个概念，叫做“产品路径”。

简单来说，就是用户在使用产品时，我们是如何通过功能设置和引导，逐步将用户导入到各个功能上，最终解决用户的具体问题。

产品路径从本质上来说，其实是用户流量的流转路径，每一次跳转就是一次用户转化，多条产品路径汇聚在一起形成流量漏斗。

任何产品都有产品路径，因为任何功能都是逐步完成的，无论是一步完成，还是N步完成。

我们先来看看To C的产品路径。

当我们站在To C的产品角度来看时，产品路径越长，其实损失掉的用户也就越大，因为每一步跳转带来的可能都是用户放弃使用的风险。因此，我们设计产品路径时，需要考虑的最关键因素是，如何尽量缩短产品路径，从而能够确保用户的体验和每一步的留存转化都能足够多，尽可能减少损失用户。

我们来举个例子：

摩拜单车和ofo在产品路径设计上是有非常大区别的，这一点也是为什么摩拜总给人以体验更优的印象。

摩拜的产品使用主路径是这样的：

打开摩拜App

▼

点击扫码

▼

扫一扫自动跳入开锁等待状态

▼

等待几秒自动完成开锁

▼

骑行结束手动锁车，系统自动结费

摩拜的整个使用过程只有五步（由于中间需要等待，我将扫一扫和等待开锁分为两步）。

再看看ofo的产品使用主路径：

打开ofo App

▼

点击扫码

▼

扫一扫跳转获取密码

▼

手动输入车锁密码

▼

点击开锁键

▼

骑行结束手动锁车

▼

拨乱密码锁

▼

打开ofo App

▼

点击支付

ofo的整个使用过程长达九步。

这样一对比，两个产品在使用过程中的主路径长度相差近一倍，这直接反应在了用户体验上。

在To C的产品中，产品路径每多一步，就是增加一次用户体验断点的风险，万一在这一步出现了bug或者网络问题，直接导致的就是用户流失，转化率下降。

问题来了，To B的产品也是这样看待产品路径的吗？

我们再来看一个例子。

假如我们想为某家医院做一套患者随访（随访是指医院对出院患者的持续病情追踪手段）的工具，我们会怎么思考这个问题呢？当我们深入去和医院来沟通这些需求时，我们会发现，一个随访大概有如下步骤：

选中一个患者

▼

选中需要进行的随访模板

▼

选择随访的日期

▼

指派随访的护士

▼

护士执行随访并填写随访记录

▼

护士关闭完成随访

整个过程至少六步。

我们会发现，这个过程是固定的，一个也省不了，无论是医院A还是医院B，一个随访都至少需要以上的六步，我们无论怎么去优化也是不可能去节省产品路径的。

此时，我们与To C的产品进行对比会发现，To C的产品路径是站在用户的即时性需求角度来考虑的，也就是用户当下的体验。

而To B的产品路径一般是站在计划性需求的角度来考虑的，无论是一次随访、一次采购、一次财务报销，它都是一次计划。不会有哪个用户会提前计划自己去和谁聊微信，也不会去提前计划自己去骑行某台单车（预约单车可不算计划）。

To C的产品需要在路径上尽可能短，从而满足即时性需求，而To B的产品路径是由计划好的业务本身决定的，少一步业务就走不下去了，不能因为省麻烦就在随访中不填写随访记录，也不能因为省事就把报销系统中的发票一环省掉。

所以，站在这样的角度去看时，我们能够清晰的分辨出To B产品路径的规范性和标准性，这一点是和To C产品路径最大的区别。

总结

To B产品，无论从产品逻辑层面，还是从产品规划层面，都值得我们产品经理花费更多的时间和经理去探讨。

产品说到底是为用户服务的，无论是To C产品解决的是当下即时性的需求，还是To B产品解决的是计划性的标准化需求，在其产品价值上都是一致的。