凭什么To B的产品经理可以更“霸道”?

作者 /祝百万

来源 /本文系产品猎人“Hunter”计划投稿作品

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

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

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

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

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

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

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

自从有To B以来,鲜有产品经理的岗位。传统To B领域里面,产品并非是必要的岗位。有些是用项目经理,有些是用售前和研发去支持。但不管工作职责的划分如何,对于产品设计的关键点,并没有因此而改变。

然后,大多产品的认识和了解,容易停留在To C的情形,因为产品经理的兴盛,是随着To C来的,若一个To C产品领域的大神有一个法则,那么大家都会争相模仿,甚至奉为圭臬,若稍有不同,便会招来争论。好像大家都习惯了经典物理,突然量子大门打开了,但大家都容易以最初的方式理解新的情况。

本文将会论述4点To C和To B不一样的地方:

有情 VS 无情

人性 VS 理性

卖身 VS 卖艺

玩具 VS 工具

本文为上篇,仅论述前两点,对于第一点,又分为4小点:

个体 VS 角色

情绪 VS 问题

瞬间决策 VS 决策链

留下 VS 离开

不管是To C还是To B的产品,设计出来,虽然都是人在使用,但是对于个人来说,他可以跳出他的社会角色来使用。而我们设计的产品,大都是当用户处于职位角色才使用的。

例如一个人打游戏的时候,不管他平时的职位高低,是从事什么行业,他都能按照自己想要的方式去操作这个游戏。

而若某个公司的DBA使用腾讯云的数据库,他就必须按照规范来,这里的规范,其实就是社会角色对他的约束,游戏可以不想玩了直接推出,大不了这局就输了,而线上的操作则必须按时保证质量的完成,大部分To C设计出来的产品天然是社会角色退相干的。

因此,产品设计的时候,我们得考虑这个职位的角色赋予个人的规则来设计,例如,一个DBA通常是把业务切换放在对客户影响,或则还是收入影响最小的时候,而这个时候往往对于个人来说,是他们的休息时间。即To B和To C产品,至少在这个情景的时间点上其实是错开的。

其次,使用的情绪是不一样的。往往个人使用某个消耗其时间较长的产品,是为了表达或者宣泄某种情绪,或者是让产品来抚慰自身。若是不断的刷视频,是后者,若是不断的发视频,是前者。他们当情绪得到满足就会完成一次大脑刺激放松,最后归于无聊,然后再度循环,终而乐此不疲的不断循环,可能内容不一样,但形式大都是相同。

而To B的设计,往往是带着问题的。通过使用产品,解决我的某个问题,例如解决我计算量不够的问题,帮我做图片识别,帮我提供更大的访问带宽。这里的不一样,会导致我们设计产品的许多出发点不一样。

例如,当你的目的是要让客户情绪得到满足,那可以多留他一些时间,让信息一层层的传达到他,层层深入,循循善诱,而又欲盖弥彰,各种关卡不断的挑战用户的猎奇与满足。而当你要解决问题,那必然是高效的,及时的,准确的,可预期的。这样设计出来的产品形式,就会完全不一样。

再次,个体的决策过程和企业会差别很大。个体的思维误区,冲动决策,从众心里是非常常见的,也是我们产品设计时候可以利用的点。例如设计一个产品的展示中,美女在使用某种化妆品,人们会不自主的认为使用了该化妆品,就能会和这个演员一样了。也几乎不会有人直接去追问该化妆品的成分以及百分比、生产过程的副产品可能有哪些、吸收后的药动力代谢、相关的研究论文和国内外声音等。

然而To B的决策就是如此,尤其是大公司,他们看完广告基本的态度是“好的”,“呵呵”,一定要做测试验证,或者是要求你去交流,讲清楚原理和风险。这样,他们做下来的决策,才会是风险最小的。

因此这里的设计,也会让我们很多得到很多经验,例如不必去过多的去把他们导向到一个可能并不适用的场景,或者刺激用户,因为他们足够的理性。他们会很快回过神来,同时,运营活动也不必保太多期望,因为那些目前不需要的,他们是几乎没有冲动消费的情况的,服务器不用,反正便宜,不买就亏了,先屯着,剁手党在这里是几乎不存在的; 其实我们很少去提今年运营活动增量,有多少是由于活动本身带来的额外量,而不是本来就有的增量,或提前透支的量,直接去做同比,其实并不是一个逻辑上自洽的解释。(这个问题,我将会在后面的文章展开讨论)

有了前面三点的论述,第四点就好理解了。To B设计是要帮助用户解决问题,因此希望的是赶快用了就走,没事你真的连用都不要用,或者说是默默的在用,但润物细无声,让你感觉不到,这是最妙的。这个和小龙对微信的小程序定义算是不谋而合了,但推导的出发点是不一样的。

而大多To C的设计,会想尽一切办法占据用户时间,甚至某些产品的考核,就是看用户使用、观看时长,用得越多,我广告的机会和时间也越多,获取用户信息也越多,能做运营的口子也越多,对于收入的想象空间也越多。

而To B,是在占据产品背后的暗时间,或者是说时间背后的价值,提供的价值越大,用户越愿意付费。例如,原来的AI服务,3小时计算完成,而升级后,10秒计算完成,显然升级后的,和用户的接触时间少了,但却更高效了,也能收更多的钱。

接下来,我们开始讨论第二个大点,也分为4个小点:

模糊 VS 精确

便捷 VS 强大

意外 VS 确定

休闲 VS 压力

首先来说第一点,和第二点。在功能设计的时候,To C和To B的立意,是不一样的。你使用微信的时候,你会发现不能批量操作的地方很多,也不能自定义你的菜单,要把聊天记录和聊天中的视频上传到云盘备份,还不能直接操作,诸多不便。

然后To C的产品会给你一堆为什么要这样做的理由,而你又能说出一堆你的需求。这里有一个区别很大的地方就是,一个基本的To B产品,是没有选择用户群体的机会的。你需要能支撑所有用户,当然未必是所有的场景。

例如,用户买域名,不管是大客户还是中长尾,都无差别的需要域名,因此功能上,需要既满足对技术没有积累的初步使用的客户,也要满足在功能上要求细致的重度使用客户。但是一旦设计复杂了,两种客户看到对方的视图,就会觉得产品不友好。因此,这里的设计,就天然变成了京东+拼多多在一个APP里面,我们设计的时候,不得不考虑。

第三个点,To B客户对确定性的期望要远远大于To C。例如,出现了故障,到底什么时候恢复,到底这次问题影响的时间多久,下次还会出现类似问题吗,是否有能覆盖我损失的赔偿方案。而To C里面,若出现故障,一般会告诉你稍后重试,除非是事先的停服,然后版本跟新后,给你总送一些钻石,金币,用户会有一种感恩戴德的感觉,因为没有那里规定必须要给。

有一个非常小,但很有代表性的例子,数据库做退货退费的功能的时候,有一个按钮叫做“销毁”其实本想表达的是既销毁也退钱,而用户从字面上看,看不到退费的意思,因此一些用户不敢点,来提工单退费。一个小小按钮的表达,意思并没有满足用户期望的关键点,导致了这个案例,最后还得补上。

最后一点,是很多人使用To B产品不一样的地方。曾经有多次都听人说过,觉得钉钉的设计,是反人类的。非常的让人讨厌,不断的弹消息,自动语音等。然而,从工作的角度,会发现这个无比的方便。再有一个例子,也很典型,企业微信刚开始的时候,和微信一样,没一条消息是不展示时间的,当然也没有已读未读,To C的时候,展示出来其实会给看消息的人带来压力,而To B就不是。

我们数据库在设计的时候,有错误日志了,主从断开了,应该都是把消息给到客户。这类功能,都有一个共同的特点,就是给客户的压力明显比To C的大。To C更多时候会避免把复杂的东西给到客户,因为我们自己也天然是客户,我们能从客户的角度理解,并消化这些情况,游戏的设计者,一般都是非常重度的玩家,天天都在用自己的产品,你才能做好。

而To B我们天然不是客户,客户还在不断变化,你也许了解游戏,但你不一定了解金融,或者零售,世间的行业太多,一个人的经验,你是不可能全行业覆盖的。因此,也很难设计以一个统一的策略,发现每种客户都是最好的。

所谓众口难调,To C和To B的解决办法是不一样的,To C是,请出去,我们不卖牛排,To B是,有川味和麻酱,还不喜欢的,佐料在那边,自己打。因此,我们在基础能力设定上,会把更多的选择权交给客户,然后为了体验优化,再到上层去封装解决方案。这样,你才能够最快速的建立基本能力,然后再慢慢重构。

上篇到此结束,总的来说,To C产品在角色、情绪、场景等的不同,导致了功能、压力、确定性等的要求也不一样。若我们习惯了“传统”的产品思路,就非常容易带来各种问题。下篇中,我们将从服务、SLA的角度来继续讨论这个话题。

To C的产品设计,有些时候其实可以囫囵吞枣,模糊一些,因为你为了把一个东西表达清楚,可能会让产品本身变得极端复杂,而大部分个人、或者大部分场景并不需要这么清晰。设计简单就好。

而To B的设计,则不然。尽量的表达精确,因为一个不明白的描述,会直接涉及到用户在设计自己方案的时候出现问题,最后伤害到最终的数量不可预期的用户,也就是说,这里的模糊或者是精确,会被放大,To C里面很少会被放大,即便以后,也不会想To B这样明显的放大,例如客户对一个字符集的理解错误,会导致他所有用户数据变成乱码。