zoukankan      html  css  js  c++  java
  • 谈To B产品路径逻辑:To B产品的核心本质到底是什么?

    转自:http://www.woshipm.com/pmd/665647.html

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

  • 相关阅读:
    《深度探索C++对象模型》1
    《C++标准库》
    关于多级分类的封装
    git常用命令
    使用BigDecimal进行精确运算
    关于强制装换
    page分页
    pageContext.request.contextPath 和 request.getContextPath()
    springMVC + mybatis 搜索 分页等
    mybatis 动态sql
  • 原文地址:https://www.cnblogs.com/yeahwell/p/12883221.html
Copyright © 2011-2022 走看看