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

如果你既懂产品，又会写，欢迎标注“Hunter计划+文章名称”投稿至：[email protected]