—— BEGIN ——
我本人是做To C产品出身的，但是，却在过去相当长的一段时间中从事To B产品的设计，带着我的创业团队逐渐摸索出如何做出一款被称得上还不错的To B的产品，也在这个过程中学习到了To B的产品的本质，以及与To C的产品之间的区别。
我想花费一些时间和笔墨，通过思考和讨论的方式，来分享一些我自己做To B产品的感受和方法论，希望能够与同样是做To B产品的PM一起来探讨和沟通，互相学习，共同进步。
在这篇文章中，我首先尝试讨论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的产品路径是由计划好的业务本身决定的，少一步业务就走不下去了，不能因为省麻烦就在随访中不填写随访记录，也不能因为省事就把报销系统中的发票一环省掉。
所以，站在这样的角度去看时，我们能够清晰的分辨出ToB产品路径的规范性和标准性，这一点是和ToC产品路径最大的区别。
小结
To B的产品是非常值得大书特书的，无论从产品逻辑层面，还是从产品规划层面，都值得我们产品经理花费更多的时间和经理去探讨。
产品说到底是为用户服务的，无论是To C的产品解决的是当下即时性的需求，还是To B的产品解决的是计划性的标准化需求，在其产品价值上都是一致的。
—— END ——
