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

11 评论 35855 浏览 238 收藏 11 分钟

今天,我们开始断断续续聊一聊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;前微软小冰初创成员,前微软高级产品经理;北京大学计算机系硕士。专注产品、运营和商业的分析,热衷产品方法论的总结。热爱足球、民谣音乐、吉他弹唱、软笔书法、阅读和旅游,热爱生活。

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

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 受教了

    来自上海 回复
  2. 我这里负责的是速通领域的我看到的决策链中 只有执行层面的才会把具体的产品路径。而执行层面又容易受限制决策人影响。

    来自福建 回复
  3. 有没有什么书是关于在TOB模式下的产品探索的,求指导

    来自福建 回复
  4. ToB用户群是固定的,业务流程相对来说比较清晰,搞定老板就搞定了;
    ToC用户群有一个大致的范围,但是会增加或者减少,根据产品能实现、满足的需求来界定的,业务流程也是在不断探索中

    来自浙江 回复
  5. 关注作者了

    回复
  6. 首先感谢作者的分享。接下来我说一下我的观点,我并不完全认同作者对于B端和C端区别的说法,我的看法是,不管是C端还是B端都可以优化,优化的是交互流程,业务流程不管C端还是B端,一般情况下都是不能优化的。就拿C端产品摩拜单车举例,解锁就是个业务流程,是不能省略的,个人看法,欢迎指教

    来自北京 回复
    1. 赞同!我觉得你说的算是在业务基础上的体验优化,站在效率优化角度,尽可能多的标准化路径。我觉得不冲突,应该是先有业务路径,然后是优化。之后准备继续写有关体验的文章,欢迎继续一起讨论!

      回复
  7. to B产品是将现实中的工作流程通过系统简化或智能化,从而提高工作效率

    来自北京 回复
  8. 2B:计划步骤, 2C:路径优化

    来自四川 回复
  9. 厉害!关注作者大大了 :mrgreen:

    来自广东 回复