>科技>>正文

凭什么To B的产品经理不能“站着把钱赚了”?

原标题:凭什么To B的产品经理不能“站着把钱赚了”?

来源丨产品猎人

作者丨祝百万

To B和To C的产品经理对用户的期望值截然不同。

To B产品设计是帮用户解决问题,希望用户用完即走,或者默默使用,但润雨细无声,让用户感知不到。

To C产品设计,会想尽一切办法占据用户时间,拉长用户使用时长。

总的来看,To B产品占据的是用户时间背后的价值,提供的价值越大,用户越愿意付费。

从这个角度来看,To B产品经理更“霸道”,不care用户使用时长,更关注产品能给用户提升多少效率、带来多少价值。

本文为一位产品经理对To B产品设计的思考(下篇),细致分享To B产品设计与To C的差异之处。

该文来自去年的一次分享中的一页ppt,由于分享时间有限,表达很浅,这里会把那次分享的部分,分成几次,分篇阐述。

想你应该看过类似上图这样的一些视频。是的,To B就是这样,客户会要求你关掉美颜,关掉滤镜,卸妆到客户现场,接受笔录一般的询问,同时,我假设你也能想到一些类似下图的场景,还会无情地和其他类似你一样的小伙伴在一起,按照既定动作开始表演,那个曾经在公司穿着短裤的长毛叔叔,和穿着拖鞋抠脚大汉,你要收起你的固有气质,唯唯诺诺的拿出你产品。

甚至像每年体检一样,不管是弱点,还是细节,还是隐藏的娇羞,通通都成为评价你产品好坏的指标。你想,除了产品质量过硬,你还有什么办法?

ToB的产品,需要经得起各种角度刁钻的检验。从用户的角度,很多ToC的产品是一个玩具,坏了不会太影响生活,我也可以去玩其他的,作为开发商,赔点金币钻石也是一个可行方案。而ToB的产品大都坏了就是致命的,例如银行金融体系死机了,医院开药系统出问题了,你想想哪个不是让你的生活都无法进行下去。按照上篇的计划,我们这篇谈谈以下两个话题。

ToB系统设计的时候,一般我们都为了精确,希望能通过数字的指标来规范产品对外暴露的能力。例如,我们对外公布产品的可用性,99.95%或者更高的99.99%,我们对外公布产品的可连续性99.9996%。

各种监控、备份时间的承诺,各种接口的调用量,返回统计的要求,若客户对我们系统不满意,还可以通过API自行使用。甚至有对各家云厂商统一的API调用框架。这些在ToC里面,基本上是不会涉及的。

我们得习惯思路上的转变,或者是说思路跟着场景去转变。

上篇也提到过,ToC的决策链基本上只有自己,那么责任链很短,最多会追加1到2个人,例如孩子乱花钱了,责任链一般到父母这个层级就结束了。而ToB的责任链就相对长很多。一般责任链都长于决策联,产品设计需要同时考虑责任和决策链。

什么意思呢,举个例子,可能是一个开发在用我们的产品,他的领导并不会去对任何一个细节仔细查看,可是一旦除了问题,这个领导,以及领导的领导都会收到问责。

甚至在一些行业,会有行政处罚,影响仕途或者是整个团队都受到监管机构的处罚。造成的连带影响,不仅仅是经济上的,可能对整个职业和人生的。你的产品设计和执行的质量,会被责任链不断放大。

因此,我们不得不回到之前的数字,你的每个设计都希望能有一个框,这个框把最好的情况装在里面,也把最坏的情况装在里面。让人能从上帝的视角,一眼看到这个框。不然,他怎么能放心地生活呢。

这下就明白了,我们经常说用户就是上帝,但一般都是从服务的角度去理解这句话,而ToB则需要从产品的角度去理解这句话,让他真的有一个上帝的视角,既能看到全局,也能看到具像。你需要准备这些内容,客户或者咨询机构或者合作伙伴,需要问你战略的规划;有时候客户也会问你细节,你的实现与设计,有时候客户也提一些你觉得不合理的要求,都需要在一开始产品设计的时候想到。

我们做ToC的时候,一般比较忌讳一个产品一开始就设计得面面俱到,因为你会抓不住重点,也会因为消耗太多的时间在那些不重要的点上而错过了机会。

虽然我们在ToB里面做需求的时候,也会层层迭代,但一开始对长远的规划要求更高,因为这个生意能明确看到的是要做几十年,一百年,不知道多少年的。你想想,你的数据库系统里面存的是老百姓的社保数据,是大家的收入,你觉得他需要几个地域的备份,需要能追溯多少年呢。

玩具VS工具,其实最本质的是责任。ToB产品设计的责任感来得更直接,稍有疏忽,你会让一个客户的项目直接失败,数千万的投资归为泡影。你会引起看病的钱取不出来,甚至一封封律师函接踵而至。从一开始,To B产品设计就要求我们设计最好的产品,做最坏的打算,提供最精确的数据,回答每一个“要是这样”怎么办。

还有一个问题,就是服务。

服务虽然不是ToB产品独有的话题,但在ToC里面服务明显会轻很多。有一个简单的理解,ToC里面基本上我只需要解释服务以后简单的操作,而ToB里面需要贴身的服务,现场的服务,7*24小时的服务,保持微笑而又表里如一、不卑不亢如沐春风般的跪式服务,不管是售前售后还是售中,无微不至。

那么一个问题来了,能不能站着,把钱挣了。可以,但不是现在。

服务的问题其实是一个产品能力问题的延伸,也是一个公共产品社会化服务标准之前的必经阶段。没有人去咨询水和电怎么使用了,因为这个足够简单,市场也透明得像水一样,无形得像电一样,我曾经问过Gartner的分析师,他们分析一些什么样的行业,得到的答案是那些市场上还不明晰的行业。

若寡头已经出现,已经没有什么有力的竞争者或者颠覆式变革,也就没有什么好分析谁强谁弱,咨询机构的信息是给买家看的,自然也就没有谁买这些信息,因为太明显了。

我们的服务是弥补我们产品能力不足,因为我们做得不够好,或者市场现在就是那么不成熟,我们需要不断地应对客户咨询的问题,不断地去客户现场解释、培训、对比测试。我们需要半夜爬起来处理问题,然后赔礼道歉。至若产品能力打磨到极致,市场上领导地位已经形成,就是另外光景。

因此,产品设计更全面的方式,需要考虑产品的后手,服务化能力。虽然一开始我们可能想得很好,能力很全面,但终究产品经理会在一些地方妥协给现实,你终究不是一个站在上帝身边的天使。因此,哪些在危机情况需要可以手动处理,你还得考虑进去。

服务其实从一开始会一直延续到最后。你一开始就会收到用户的需求,或者你去抽象,或者你去调研,这就是服务的开端,你会不断地理解用户,也在悄悄地影响用户,通过你的服务,让他接受你的方案,然后说服第二个,第三个用户,看你们的偶像都这样玩哦。ToB产品经常在做标杆客户案例,这样可以让这一个行业的人,都按照某种成功经验去复制,效率高,重复工作少。

然后,在到销售过程中的培训,方案的讲解,poc测试,报价与合同,投标,后面的交付以及后续支持维护,有些公有云情况未包含全,每个环节在人力的消耗要远远大于ToC产品,即服务的提供密度要大于ToC产品。

到这里,原计划的4个点,基本上说完,但其实还有一些小点未能提到。例如,在数据分析和反馈上,ToB和ToC是差别较大的,因为基数不够。常有一些个案就能掩盖真相。再如,在回款周期以及财务计算上,商业模式,成本计算等。但本文主要讲产品设计上的,因此这些直接略过。

To B产品设计的4个特点到这里,正文基本上就结束了。我们来回顾下,我们从人性和理性、有情和无情,玩具和工具,卖艺和卖身4个角度来讲解了ToC和ToB产品的差异。总的来说,是群里与个体的差异,是角色和自然人的差异,是商业模式上的差异。作为产品经理,自主去总结其中道理,是我们的本质工作。返回搜狐,查看更多

责任编辑:

声明:该文观点仅代表作者本人,搜狐号系信息发布平台,搜狐仅提供信息存储空间服务。
tob toc poc测试 api ppt
阅读 ()
投诉
免费获取
今日搜狐热点
今日推荐