总结在ToB产品运营的坑，摆脱无效果的尴尬局面

以前做ToB运营的时候，我把ToB的产品当成ToC的产品，走了很多弯路。产品从来没有走过正向运营的道路，也没有赚到钱，这也给我在ToB的运营带来了很多麻烦。经过最近的思考和新商业模式的拓展，我意识到ToB的运营不仅仅是掌握一些技能。在这两年的工作中，我踩了很多ToB产品运营的坑，可以简单归结为思想问题、认知问题、经验问题。这三个问题让我流鼻涕流泪。我也希望这三个问题能让你摆脱转行ToB运营的尴尬局面。在2018年的偶然机会中，我进入了国内优秀的人工智能公司，开始运营SaaS产品。一开始，我对SaaS产品和ToB产品没有明显的概念，从教育公司的C端运营到企业服务的B端运营，我仍然认为以用户数量为核心的指标仍然存在。一年多来，我所做的大部分工作对最终结果都是无效的。以至于后来，我在团队中找不到自己的位置，所以我不得不通过内部转移来改变我的职位，然后我遇到了另一件让我更尴尬的事情。现在想想，因为思想不成熟，转岗换工作还是会面临目前的困境或者其他问题。只有先想清楚，才能更好的施展才华。第一，最早的SaaS产品思维深度不够，不适合用户使用，所以我们的团队对产品进行了改造，使其更适合C端用户。在PFM阶段之后，我认为产品可以大规模推广和获取客户，所以团队也将北极星指标定为用户数量。可悲的是，这个目标只*用户的数量，而不*用户背后的价值，也不*用户对公司的最大贡献。这也与产品的商业逻辑有关，因为产品不直接销售给用户，而是通过流量到广告的实现路径，这似乎非常合理，但非常不合理。由于互联网已经发展到私有域流量阶段，PC或m端的流量价值非常低，对广告商的价值贡献也很低，导致整个链接无法很好地流通。一开始，我的认知还没有上升到商业逻辑上，只是停留在KPI阶段。我认为只要我通过各种方式完成公司给我的任务，那么我就是一个优秀的人，一个团队，一个优秀的团队；也以KPI为导向，让我只*KPI的完成，忘记KPI可以为团队带来的最终目标贡献价值。虽然我超额完成了KPI，但对团队来说仍然是资源的浪费，投入产出比不成正比。*个人利益的得失，导致我在团队中的话语权低下，逐渐被边缘化。当然，边缘化和一些沙雕工作场所的生存技能也是我在中型公司生存的奇迹。按照我的情商逻辑，我可能只适合呆在小公司，现在可能会更好。第二，拒绝一线ToB运营，本质上要把产品卖给用户，让用户花真钱，而不是消耗用户感受不到的宝贵时间，或者让用户贡献应有的价值，帮助你完成KPI或者获取有价值的信息来完善业务。而且Tob的决策过程很长，很多用户都不是能做决策的用户。在操作过程中，我只依靠用户通过网络接触产品，觉得他们很了解用户的这部分，所有的操作规划和操作行动都围绕这部分用户设计，似乎操作工作非常正确，但只取悦底层用户，没有深入思考购买产品决策者的需求。在ToB产品的运营过程中，应考虑产品用户与决策买家之间的利益和冲突。在运营规划中，一些节点倾向于产品用户，一些运营行动帮助决策买家做出决策。通过工具过多接触产品的用户，会导致决策买家无法下定决心购买。如果你想了解双方的需求，不要去一线看客户，也不要在沟通会议上被客户蹂躏两次。仅仅通过销售和预售来处理他们的想法是不准确的。只有深入一线，才能深入了解用户的需求和双方的矛盾。运营商总是把自己视为互联网的高端职位。事实上，运营商和销售人员没有区别。不要把自己看得太高——看得太高，摔得很惨。我完全拒绝去一线看客户，因为我认为运营商应该坐在车站上，思考产品的总体方向，从战略上决定产品的发展方向和生命周期，运营商有最多的想法，不应该专注于与用户的沟通。也正是这个想法让我远离了一线用户和产品的真正发展方向。当输入信息不足时，不要考虑顶层战略问题。Tob的运营是行业的运营，对行业信息了解不够，很容易走上偏向的路线。由于他们自己的思想深度存在问题，他们自己的产品认知和以往的经验判断很容易出现更大的错误，但也是TOB操作中的一个相对较大的坑。为了做点什么，我选择了更换部门。一开始，我还在为自己的智慧鼓掌。现在，跳进另一个坑和这个坑的主要原因确实存在。就我个人而言，我认为这与认知不清楚和经验重用有很大关系。三、认知问题认知问题根本不了解产品和客户，但这两个方向是做好运营的基础。俗话说，根基不牢，地动山摇。事实上，它在运营工作中也同样实用，甚至根本问题也不清楚，只会拼凑在互联网上传播的运营技能，偶尔可以取得良好的效果，但不能做好产品运营。在产品认知方面，我没有考虑产品实现路径和产品目标群体，也没有考虑产品销售方式，导致后期工作异常被动。如果你正在寻找与ToB相关的工作，它可能对你有很大的参考价值。如果你从事类似产品的运营，我认为你应该扩大更多的东西，而不是用鸡毛作为箭头，只*你面前的用户数量。在ToB企业中，纯玩用户数是无法生存的。只有实现，才能有更高的存在价值。在转岗过程中，急于跳出现在的坑，对另一个团队的调查并不清楚。因为团队的产品是面向程序猿的，所以决定在团队层面扩大开发者，成为开发者的影响力，通过触摸开发者来实现。所谓的开发者操作仍然走了很大的弯路，并没有直接向用户销售产品。这种逻辑经常出现在TOC的产品操作中。毕竟，TOC的用户和购买决策者是同一个用户，但TOB的产品逻辑并非如此。即使用户认为产品很容易使用，决策者也不一定支持购买。例如，在MySQL和Oracle数据库中，公司宁愿找到大量程序员免费使用开源组件，也不愿购买性能更高的企业服务器数据库。在开发人员的产品中也存在这样的问题。即使我们的产品使开发人员使用得很好，用户在付费时也很容易出现两个极端。强大的公司可能会开发自己的相关产品。对他们来说，数据是核心，不太可能使用商业产品。此外，产品的学习成本非常高，只能输出用户解决方案和私有化部署，用户购买解决方案和私有化部署的资金足以通过自主研究解决问题。实力不是很强的团队，老板认为邀请程序员来解决所有的问题，你现在真的想买商业软件，一定是你的实力不好。而且，产品不是完全开源的。程序员花时间学习一个在生产环境中无法实际使用的产品，他们更愿意把时间花在完全开源的组件上。此外，通过培养用户习惯，公司还没有完全决心做这样的事情。即使他们一开始就下定决心，他们也可能无法坚持下去。作为底层员工，没有办法给出合理的建议，老板更愿意听其他更大公司的结论和经验，或者专业培训讲师的想法。一旦有人说这很难做到，老板很容易动摇，底层执行的人很快就会变得非常被动。因此，ToB产品必须考虑产品的赚钱模式，最直接、最有效的方式，不要培养用户习惯。只有快速交易才能体现运营商的价值。要想清楚产品用户与决策者之间的矛盾，综合考虑产品是否有必要坚持。否则作为ToB的操作就会和我一样，因为产品的实现路径，在顶层框架的变化中，就会跌到底。在我接下来的采访中，我逐渐发现TOB企业将调查运营商带来的销售，包括阿里巴巴、京东等职位。他们更注重你的实现能力、商业网络和运营框架的逻辑思维，很少考虑产品的用户数量。在产品运营中，我们必须为公司的核心指标做出贡献，否则很快就会被淘汰。四、经验问题习惯了C端产品的操作方法和技能，到B端产品必须注意自己的经验重用问题，我也有自己的C端经验做B端，也是过去两年运营工作中最大的失败。特别是一些小公司的产品运营商，产品增长模式相对单一，只有渠道、渠道、渠道！基本上没有数据驱动操作。只要用户能以不同的方式增长，公司的KPI就能完成。B端是另一套逻辑，B端的客户获取成本远高于C端，B端的产品更注重用户的续费率。拉新的成本很高，续费都是赚来的。因此，对用户使用产品核心功能和用户反馈的调查尤为重要，因此迫切需要使用数据来驱动B端产品的操作。B端线索进入客户交易是一个漫长的过程，很少有人期望用户主动交易。在此过程中，漏斗的转换和漏斗中的关键行为已成为操作的必要条件。大多数公司没有系统的B端操作工具，导致操作人员在工作中失明，用户保留和转换的关键节点纯粹是猜测：也许，可能，可能，这些词不应该从操作人员的嘴里说出来。然而，在B端的操作中，它已经成为一种真实的情况。无论是我见过的小公司还是我经历过的中型公司，B端的用户转型仅仅依赖于商业个人主动性的推广，很少有链接可以控制操作，这也导致操作人员很少参与和控制过程。根据以往的经验，B端的操作可以做客户获取工作。现在想想，作为B端的操作还是很可悲的。我认为作为B端运营商，首先放弃原AARR模型的理论应用，优先考虑产品的实现路径；然后考虑产品的支付能力和转换路径；最后考虑获取流量。此外，操作应该更多地参与用户转换的路径，最好的方法是通过方便的工具或构建B端转换的SOP。我也非常感谢前俱乐部的宽容，让我在工作中理解这些事情，现在记录下来与大家分享，让大家在转型Tob操作的过程中少走弯路。Tob操作自然有他的自然道理，但现在大家还处于混乱状态，需要操作人员一起摸索过河。我不喜欢把所有的原因都归咎于公司领导和市场环境。客观因素确实存在，运营的价值在各种失败中找到了出路，引领产品和商业模式走向市场，为公司创造价值，完成自我成长。不幸的是，我顿悟得太晚了。在工作开始的时候，我把产品不容易做的原因归咎于产品体验不好，产品用户群太窄。所有为自己找借口的解决方案最终都伤害了自己，流下了苦涩的眼泪。