酷应用

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

百家作者：腾讯创业 2019-06-21 01:00:51

点击上方蓝色字体“腾讯创业” 选择关注公众号

创投圈大小事，你都能尽在掌握

腾讯创业 | ID：qqchuangye

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

本文来源“产品猎人”（ID：qqchanpin），腾讯创业经授权后转载。

作者 / 祝百万

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这样明显的放大，例如客户对一个字符集的理解错误，会导致他所有用户数据变成乱码。

END

你怎么理解To B和To C产品设计的区别？

欢迎评论区留言，与大家分享。

一周热文回顾