我在ToB公司做产品运营的血泪教训

之前我在经营ToB的时候,拿ToB产品当ToC产品,走了很多弯路。产品一直没有走上正向运营的道路,也没有赚钱,导致ToB运营出现很多麻烦。

经过最近一段时间的思考和拓展新的商业模式,我意识到ToB的运营不仅仅是掌握一些技能。

在过去两年的工作中,我在ToB产品的运营上踩过很多坑。可以简单地归结为思维、认知和经验上的问题。这三个问题让我一把鼻涕一把泪。也希望这三个问题能帮你摆脱转行ToB运营的尴尬局面。

2018年,一次偶然的机会,我进入了国内一家优秀的AI公司,开始运营SaaS产品。当初对SaaS产品和ToB产品没有一个明显的概念,从教育公司的C端运营到企业服务的B端运营,脑子里还是有指标的,以用户数为核心。

一年多来,我做的大部分工作对最终结果都是无效的。结果后期在队里找不到自己的位置,只能通过内部调动来换位置,然后又遇到了一件让我更加尴尬的事情。

现在想想,因为思想不成熟,换工作还是会面临目前的困境或者其他问题。只有先了解了,才能更好的施展才华。

第一,思想深度不够

最早的SaaS产品不适合用户,所以我们团队对产品进行了修改,使其更适合C端用户。

【/s2/】产品通过PFM阶段后,我觉得产品可以大规模推广,赢得客户,所以团队也把北极星指数定为用户数。【/s2/】可悲的是,这个目标只关注用户数量,而不关注用户能给背后带来的价值,也不关注用户对公司最大的贡献。

这也和产品的商业逻辑有关,因为商品不是直接卖给用户,而是通过流量来实现广告,这看似很合理,实则很不合理。

因为互联网已经发展到私有域流量的阶段,每个pc或者M终端留下的流量价值很低,对广告主价值的贡献也很低,导致整个环节无法很好的流动。

【/s2/】当初我的认知还没有上升到商业逻辑,只停留在KPI阶段。

我认为只要我通过各种手段完成公司交给我的任务,那么我就是一个优秀的人,团队也是一个优秀的团队;同样是KPI导向,所以我只关注KPI的完成程度,忘记了KPI可以为团队带来的最终目标贡献价值。

我在ToB公司做产品运营的血泪教训 产品经理 好文分享 第1张

虽然我超额完成了KPI,但对团队来说还是浪费资源,投入产出比不成正比。

【/s2/】关注个人利益得失导致我在团队中话语权低,逐渐被边缘化。当然,被边缘化也有我在职场生存的一些沙雕技巧。我能在一家中型公司生存下来,也是一个奇迹。

按照我的情商逻辑,我可能只适合留在小公司,目前可能更好。

第二,拒绝上前线

ToB的运营本质上是把产品卖给用户,让用户用真钱省钱,而不是耗费用户感受不到的宝贵时间,或者让用户贡献出自己应有的价值来帮助你完成KPI或者获取有价值的信息来提升你的业务。

而且,ToB的决策过程漫长,接触到的很多用户都不是能做决策的用户。

【/s2/】在运营过程中,只靠通过网络接触产品的用户,感觉对这些用户很了解。所有的运营规划和运营行动都是围绕这些用户设计的。【/s2/】看起来操作工作是正确的,但我只讨好底层能接触到的用户,并没有深入思考购买产品的决策者的需求。

在ToB产品的运营过程中,应考虑产品用户和决策购买者之间的利益和冲突。在运营规划中,一些节点对产品用户进行倾斜,一些运营行为辅助决策购买者进行决策。

【/s2/】太多的工具到达了产品的用户手中,会导致决策购买者没有下定决心购买。

如果你想了解双方的需求,只通过销售和售前把他们的想法处理的信息带过来是不准确的,如果你在一线没有遇到客户,或者在沟通会上两次被客户蹂躏。只有深入一线,才能对用户的需求和双方的矛盾有更深入的了解。

运营商总是把自己当成互联网上的高端阵地。其实运营商和销售人员是没有区别的。不要把自己看得太高——看得太高,摔得很惨。

【/s2/】我从心底里完全拒绝与客户见面,【/s2/】因为我觉得运营者应该坐在工作站上,思考产品的大方向,从战略上决定产品的发展方向和生命周期。而且运营商有最出彩的创意,不应该把重点放在与用户的沟通上。

【/s2/】也是这个思路让我远离了一线用户,远离了产品真正的发展方向。

当没有足够的输入信息时,不要考虑做顶层策略。ToB的运营就是行业的运营,TOB因为对行业信息了解不够,很容易走错路。

自身思想深度有问题,导致对产品的认知和对过往经验的判断出现很大失误,这也是ToB运营的一个大坑。

为了能有所作为,我选择了换部门,一开始我是在为自己的智慧鼓掌。现在,跳进另一个坑和这个坑有一个主要原因。个人觉得和认知不清,经验重用有很大关系。

第三,认知问题

认知的问题是缺乏对产品和客户的了解,但这两个方向是运营好的基础。有句话叫基础不牢,地动山摇。

其实在操作上也很实用。连根本问题都不清楚。只会拼凑网上流传的操作技巧,偶尔也能有不错的效果,但是做不好产品操作。

【/s2/】在产品认知方面,没有考虑产品的实现路径、产品的目标群体、销售产品的方式,导致后期工作异常被动。

如果你正在寻找一份与ToB相关的工作,它可能对你有很大的参考价值。如果你已经从事过类似产品的运营,我觉得你应该拓展更多的东西,而不是只盯着眼前以鸡毛为方向的用户数量。

单纯的游戏用户数量在ToB企业是无法生存的。只有实现了,才能有更高的存在价值。

在转岗过程中,急于跳出目前的坑,另一个团队的调查不清楚。由于团队的产品以程为导向,所以决定在团队层面扩大开发人员,在开发人员中发挥影响力,通过接触开发人员来实现。

所谓的开发者运营还是走了很大的弯路,没有直接把产品卖给用户。

这种逻辑在ToC的产品运营中经常看到。毕竟,ToC的用户和采购决策者是同一个用户,但ToB的产品逻辑不是这样。即使用户认为该产品易于使用,决策者也可能不支持购买。

我在ToB公司做产品运营的血泪教训 产品经理 好文分享 第2张

比如MySQL和Oracle数据库,公司宁愿找大量程序员使用各种开源免费组件,也不愿意买性能更高的企业服务器数据库。

开发者的产品也有这样的问题。即使我们的产品被开发者很好的使用,用户付费时也很容易出现两个极端,有实力的公司可能会自己开发相关产品。

对他们来说,数据是核心,不太可能用一个商业产品。而且产品的学习成本极高,只能向用户输出解决方案和私有化部署,用户购买解决方案和私有化部署的钱足够组件团队通过自学解决问题。

对于一个实力弱的团队,老板认为请程序员就是解决所有问题。现在想买商业软件,肯定是实力不行。

而且,产品不是完全开源的。程序员花时间学习一个实际上不能在生产环境中使用的产品,他们更愿意把时间花在完全开源的组件上。

而且公司做这种事也不是完全下定决心,因为培养用户习惯的路还很长,就算当初下定决心,也不一定会坚持下去。

作为底层员工,没有办法给出合理的建议,而老板更愿意听取其他大公司的结论和经验,或者职业培训讲师的想法。一旦有人说难做,老板就容易动摇,底层执行的人很快就被动了。

所以,ToB的产品一定要考虑产品的盈利模式,最直接的方式最有效,不要培养用户的习惯。周转快能体现运营商的价值。想清楚产品用户和决策者的矛盾,综合考虑产品是否有坚持的必要。

否则,作为ToB的运营会和我一样,因为产品的实现路径会在顶层框架的变化中落到最后。

在后来的采访中,我逐渐发现ToB企业会看运营商带来的销量,包括阿里和JD.COM。他们更注重你的流动性,商业意识,整个运营框架的逻辑思维,很少考虑产品的用户数量。

做产品运营的时候,一定要做对公司核心指标有价值贡献的工作,否则很快就会被淘汰。

第四,经验问题

【/s2/】习惯了C端产品的操作方法和技巧的小伙伴,一定要注意自己在B端产品中的经验重用。我也是用自己在C端的经验做B端,这也是这两年运营最大的失败。

尤其是一些小公司的产品运营商,产品的成长模式比较简单,只有渠道,渠道,渠道!基本没有数据驱动的操作。只要用户可以多种方式成长,公司的KPI就完成了。

b面是另一套逻辑。B端获得客户的成本远高于C端,B端的产品更注重用户的续用率。新产品成本很高,续费是赚的。

【/s2/】因此,调查用户对产品核心功能的使用情况和用户反馈尤为重要,因此用数据带动B侧产品运营迫在眉睫。

B端线索进入客户进行交易是一个漫长的过程,很少有用户会主动进行交易。这个过程中的转化漏斗,漏斗中的关键行为,都成了操作的必需品。

但是大多数公司没有系统的B端操作工具,导致操作人员在工作中盲目。用户留存和转化的关键节点纯粹是猜测:也许,也许,也许,这些话不应该从运营商的嘴里说出来。

但是在B端操作,就变成了真实情况。

无论是我见过的小公司,还是我经历过的中型公司,B端用户转型完全依靠业务个人的主动性,能被运营控制的环节很少,也导致了运营人员能参与和控制的流程很少。以以往的经验,B端运营做的是争取客户的工作。

现在想想,做b面手术挺难过的。

【/s2/】我认为作为B方的运营商,首先要抛弃原有AARRR模型的理论应用,优先考虑产品的实现路径;然后思考产品的支付能力和转化路径;最后,想想流量获取。

而且运营在用户转型的路径上应该有更多的参与,最好的方式是使用便捷的工具或者搭建B端转型的SOP。

我也很感谢前雇主的包容,让我在工作中明白了这些。现在我将记录下来,与大家分享,让大家在ToB运营转型的过程中少走弯路。

ToB运营的存在有其自然的原因,但现在大家还在混乱中,运营商需要一起摸索过河。

我不喜欢把所有的原因都归咎于公司领导能力差,市场环境差。客观因素确实存在,运营价值在各种失败中找到出路,共同将产品和商业模式引向市场,为公司创造价值,完成自我成长。

可惜我顿悟的太晚了。工作之初,我把产品体验差归结为产品体验差,产品用户群体窄,所有为自己找借口的解决方案最终都伤害了自己,带下了一滴苦涩的眼泪。

作者:张穆微信官方账号:运营官张穆

为您推荐

发表评论

电子邮件地址不会被公开。