谈To B产品路径逻辑：To B产品的核心本质到底是什么？

今天，我们开始断断续续聊一聊ToB的产品。

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

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

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

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

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

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

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

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

事实上，ToB的很多产品都需要非常强大的市场销售体系，需要针对B端机构中最重要的那个决策者进行定向营销，从而影响他的决策。 这个关键的决策者可以是老板本人，也可以是某个具体业务的负责人，无论如何，这个角色都是ToB产品能够走出去落地的关键性KOL 。

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

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

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

钉钉在推出之后，其一系列功能都是围绕着中小公司的老板打造的 ，就比如“Ding”这个功能，其核心目的是防止在沟通中出现“假死”——明明看到了老板的留言，却假装没看到。但微信企业版在推出之后，所有的功能几乎都是围绕着员工开展的，并没有让老板用起来很爽的功能，反倒是因为微信企业版和微信之间有着千丝万缕的联系，导致很多老板因为反感员工工作时聊微信，而天然地反感微信企业版。

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

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

ToB和ToC在产品路径上有什么不同？

我在比较早前的一篇文章《 进阶之路：站在高视角看产品是一种怎样的体验？ 》中，曾经提及过一个概念，叫做“产品路径”。简单来说，就是用户在使用产品时，我们是如何通过功能设置和引导，逐步将用户导入到各个功能上，最终解决用户的具体问题。 产品路径从本质上来说，其实是用户流量的流转路径，每一次跳转就是一次用户转化，多条产品路径汇聚在一起形成流量漏斗 。

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

我们先来看看ToC的产品路径

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

我们来举个例子。

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

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

打开摩拜App——点击扫码——扫一扫自动跳入开锁等待状态——等待几秒自动完成开锁——骑行结束手动锁车，系统自动结费。

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

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

打开ofo App——点击扫码——扫一扫跳转获取密码——手动输入车锁密码——点击开锁键——骑行结束手动锁车——拨乱密码锁——打开ofo App——点击支付。

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

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

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

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

我们再来看一个例子。

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

选中一个患者——选中需要进行的随访模板——选择随访的日期——指派随访的护士——护士执行随访并填写随访记录——护士关闭完成随访。

整个过程至少六步。

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

此时，我们与ToC的产品进行对比会发现， ToC的产品路径是站在用户的即时性需求角度来考虑的，也就是用户当下的体验，而ToB的产品路径一般是站在计划性需求的角度来考虑的 ，无论是一次随访、一次采购、一次财务报销，它都是一次计划。不会有哪个用户会提前计划自己去和谁聊微信，也不会去提前计划自己去骑行某台单车（预约单车可不算计划）， ToC的产品需要在路径上尽可能短，从而满足即时性需求，而ToB的产品路径是由计划好的业务本身决定的，少一步业务就走不下去了 ，不能因为省麻烦就在随访中不填写随访记录，也不能因为省事就把报销系统中的发票一环省掉。

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

小结

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

产品说到底是为用户服务的，无论是ToC的产品解决的是当下即时性的需求，还是ToB的产品解决的是计划性的标准化需求，在其产品价值上都是一致的。在未来的文章中，我将逐步尝试讨论ToB和ToC的产品在体验上的不同侧重点，ToC和ToB的PM如何互相转岗，以及ToB在运营中的侧重点，并逐步尝试讨论“互联网+”中那些和ToB紧密相连的各种产品形态，等等。期望逐步丰富对ToB产品逻辑和方法论的多样化探讨与交流。

#专栏作家

帅帅的帅，“优护家” 联合创始人兼COO；前微软小冰初创成员，前微软高级产品经理；北京大学计算机系硕士。专注产品、运营和商业的分析，热衷产品方法论的总结。热爱足球、民谣音乐、吉他弹唱、软笔书法、阅读和旅游，热爱生活。

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