凭什么ToB的产品经理不能“站着把钱赚了”？

　　ToB和ToC的产品经理对用户的期望值截然不同。
　　ToB产品设计是帮用户解决问题，希望用户用完即走，或者默默使用，但润雨细无声，让用户感知不到。
　　ToC产品设计，会想尽一切办法占据用户时间，拉长用户使用时长。
　　总的来看，ToB产品占据的是用户时间背后的价值，提供的价值越大，用户越愿意付费。
　　从这个角度来看，ToB产品经理更霸道，不care用户使用时长，更关注产品能给用户提升多少效率、带来多少价值。
　　本文为一位产品经理对ToB产品设计的思考（下篇），细致分享ToB产品设计与ToC的差异之处。
　　该文来自去年的一次分享中的一页ppt，由于分享时间有限，表达很浅，这里会把那次分享的部分，分成几次，分篇阐述。
　　想你应该看过类似上图这样的一些视频。是的，ToB就是这样，客户会要求你关掉美颜，关掉滤镜，卸妆到客户现场，接受笔录一般的询问，同时，我假设你也能想到一些类似下图的场景，还会无情地和其他类似你一样的小伙伴在一起，按照既定动作开始表演，那个曾经在公司穿着短裤的长毛叔叔，和穿着拖鞋抠脚大汉，你要收起你的固有气质，唯唯诺诺的拿出你产品。
　　甚至像每年体检一样，不管是弱点，还是细节，还是隐藏的娇羞，通通都成为评价你产品好坏的指标。你想，除了产品质量过硬，你还有什么办法？
　　ToB的产品，需要经得起各种角度刁钻的检验。从用户的角度，很多ToC的产品是一个玩具，坏了不会太影响生活，我也可以去玩其他的，作为开发商，赔点金币钻石也是一个可行方案。而ToB的产品大都坏了就是致命的，例如银行金融体系死机了，医院开药系统出问题了，你想想哪个不是让你的生活都无法进行下去。按照上篇的计划，我们这篇谈谈以下两个话题。
　　ToB系统设计的时候，一般我们都为了精确，希望能通过数字的指标来规范产品对外暴露的能力。例如，我们对外公布产品的可用性，99。95或者更高的99。99，我们对外公布产品的可连续性99。9996。
　　各种监控、备份时间的承诺，各种接口的调用量，返回统计的要求，若客户对我们系统不满意，还可以通过API自行使用。甚至有对各家云厂商统一的API调用框架。这些在ToC里面，基本上是不会涉及的。
　　我们得习惯思路上的转变，或者是说思路跟着场景去转变。
　　上篇也提到过，ToC的决策链基本上只有自己，那么责任链很短，最多会追加1到2个人，例如孩子乱花钱了，责任链一般到父母这个层级就结束了。而ToB的责任链就相对长很多。一般责任链都长于决策联，产品设计需要同时考虑责任和决策链。
　　什么意思呢，举个例子，可能是一个开发在用我们的产品，他的领导并不会去对任何一个细节仔细查看，可是一旦除了问题，这个领导，以及领导的领导都会收到问责。
　　甚至在一些行业，会有行政处罚，影响仕途或者是整个团队都受到监管机构的处罚。造成的连带影响，不仅仅是经济上的，可能对整个职业和人生的。你的产品设计和执行的质量，会被责任链不断放大。
　　因此，我们不得不回到之前的数字，你的每个设计都希望能有一个框，这个框把最好的情况装在里面，也把最坏的情况装在里面。让人能从上帝的视角，一眼看到这个框。不然，他怎么能放心地生活呢。
　　这下就明白了，我们经常说用户就是上帝，但一般都是从服务的角度去理解这句话，而ToB则需要从产品的角度去理解这句话，让他真的有一个上帝的视角，既能看到全局，也能看到具像。你需要准备这些内容，客户或者咨询机构或者合作伙伴，需要问你战略的规划；有时候客户也会问你细节，你的实现与设计，有时候客户也提一些你觉得不合理的要求，都需要在一开始产品设计的时候想到。
　　我们做ToC的时候，一般比较忌讳一个产品一开始就设计得面面俱到，因为你会抓不住重点，也会因为消耗太多的时间在那些不重要的点上而错过了机会。
　　虽然我们在ToB里面做需求的时候，也会层层迭代，但一开始对长远的规划要求更高，因为这个生意能明确看到的是要做几十年，一百年，不知道多少年的。你想想，你的数据库系统里面存的是老百姓的社保数据，是大家的收入，你觉得他需要几个地域的备份，需要能追溯多少年呢。
　　玩具VS工具，其实最本质的是责任。ToB产品设计的责任感来得更直接，稍有疏忽，你会让一个客户的项目直接失败，数千万的投资归为泡影。你会引起看病的钱取不出来，甚至一封封律师函接踵而至。从一开始，ToB产品设计就要求我们设计最好的产品，做最坏的打算，提供最精确的数据，回答每一个要是这样怎么办。
　　还有一个问题，就是服务。
　　服务虽然不是ToB产品独有的话题，但在ToC里面服务明显会轻很多。有一个简单的理解，ToC里面基本上我只需要解释服务以后简单的操作，而ToB里面需要贴身的服务，现场的服务，724小时的服务，保持微笑而又表里如一、不卑不亢如沐春风般的跪式服务，不管是售前售后还是售中，无微不至。
　　那么一个问题来了，能不能站着，把钱挣了。可以，但不是现在。
　　服务的问题其实是一个产品能力问题的延伸，也是一个公共产品社会化服务标准之前的必经阶段。没有人去咨询水和电怎么使用了，因为这个足够简单，市场也透明得像水一样，无形得像电一样，我曾经问过Gartner的分析师，他们分析一些什么样的行业，得到的答案是那些市场上还不明晰的行业。
　　若寡头已经出现，已经没有什么有力的竞争者或者颠覆式变革，也就没有什么好分析谁强谁弱，咨询机构的信息是给买家看的，自然也就没有谁买这些信息，因为太明显了。
　　我们的服务是弥补我们产品能力不足，因为我们做得不够好，或者市场现在就是那么不成熟，我们需要不断地应对客户咨询的问题，不断地去客户现场解释、培训、对比测试。我们需要半夜爬起来处理问题，然后赔礼道歉。至若产品能力打磨到极致，市场上领导地位已经形成，就是另外光景。
　　因此，产品设计更全面的方式，需要考虑产品的后手，服务化能力。虽然一开始我们可能想得很好，能力很全面，但终究产品经理会在一些地方妥协给现实，你终究不是一个站在上帝身边的天使。因此，哪些在危机情况需要可以手动处理，你还得考虑进去。
　　服务其实从一开始会一直延续到最后。你一开始就会收到用户的需求，或者你去抽象，或者你去调研，这就是服务的开端，你会不断地理解用户，也在悄悄地影响用户，通过你的服务，让他接受你的方案，然后说服第二个，第三个用户，看你们的偶像都这样玩哦。ToB产品经常在做标杆客户案例，这样可以让这一个行业的人，都按照某种成功经验去复制，效率高，重复工作少。
　　然后，在到销售过程中的培训，方案的讲解，poc测试，报价与合同，投标，后面的交付以及后续支持维护，有些公有云情况未包含全，每个环节在人力的消耗要远远大于ToC产品，即服务的提供密度要大于ToC产品。
　　到这里，原计划的4个点，基本上说完，但其实还有一些小点未能提到。例如，在数据分析和反馈上，ToB和ToC是差别较大的，因为基数不够。常有一些个案就能掩盖真相。再如，在回款周期以及财务计算上，商业模式，成本计算等。但本文主要讲产品设计上的，因此这些直接略过。
　　ToB产品设计的4个特点到这里，正文基本上就结束了。我们来回顾下，我们从人性和理性、有情和无情，玩具和工具，卖艺和卖身4个角度来讲解了ToC和ToB产品的差异。总的来说，是群里与个体的差异，是角色和自然人的差异，是商业模式上的差异。作为产品经理，自主去总结其中道理，是我们的本质工作。
　　来源：产品猎人祝百万