首页/文章/ 详情

破解三大迷思,革新ToB企业面向客户价值的运营模式

5月前浏览4172

 

 

作者:大海Harry  2023年新年伊始



01

ToB企业运营三大迷思


不是危言耸听,据彭博(Bloomberg)商业调查曾有数据显示,大约有4/5的ToB创业公司在一年内就宣告失败了。为什么?回望过去这三年,对比ToC市场,ToB市场的相对确定性也显得企者不立。如疫情对客户组织形态的影响、国家政策的不断推出、AIGC技术掀起浪潮,无不要求着企业提升响应力和适应力。今天大多数ToB企业还是传统销售型组织而不是互联网型组织,他们抑制变化,而非响应变化;束缚敏捷性,而非提升适应力;追求自身的成功,而非先是客户的成功。以至于太多ToB企业出现了生存和发展的障碍,艰苦卓绝却又深陷泥潭,不断内卷缺乏创新。


或许他们踩到了ToB企业运营模式的三个坑,即企业在文化价值观、业务系统、组织能力这三个方面共性存在的迷思。企业的运营模式本身并没有对错之分,但下述的迷思可能会导致工作方式的失调乃至失控。你可能会发现自己认同所有这些,因为一个迷思不可避免地会导致下一个迷思

 


一.文化价值观的迷思


//迷思的表现:

“以客户为中心”仅仅是停留在墙上的口号

不论从SaaS订阅制还是纵观整个ToB商业逻辑,客户的成功都是业务可持续增长的关键。我一直认为订阅制是超级酷的商业模型,客户成功也是代表着一种更高维的商业意识(先利他再利己)在觉醒。


客户成功在国内运行短短几年下来,核心理念没有太多变化,但不同ToB企业的客户成功运营模式各有深浅,有的束之高阁,高喊“以客户为中心”、“全员客户成功”的口号。


深知“客户成功他们未必活,客户不成功他们必死。”的ToB企业怎么越到后期越离“客户成功”越远?以至于只停留在了墙上。

《发现利润区》里有段话,阐述了这一现象,现实情况也的确如此:

 
     

以客户为中心的思想之所以难以成型,是因为企业成功后的一些后遗症。随着时间的推移,企业的重心会发生转移。如图所示,在企业的创业阶段,企业工作的重心在于客户。小企业必须紧密追随客户,否则它便会失败。随着企业的成长,企业的重心会发生小规模的微妙的转移——它会慢慢脱离客户,转而关注企业自身。在企业的成型阶段,企业规模越发庞大,企业的重心也会越来越远离客户,向自身倾斜。最终,企业重心将完全转移到企业自身。此时,企业会全身心关注内部事务,比如内部预算、内部资源整合以及内部管理等,因此便更加难以实施以客户为中心的思想。


二.业务系统的迷思


//迷思的表现1:

成效是利己的、度量是描绘结果的

当ToB企业从内部设定目标成效时,往往是为了实现自我的经营信念。

如某一个招聘类HR SaaS公司在2022年底 制定未来3年的经营目标:1. 实现销售业绩大幅增长 2. 提升内部效率降低运营成本 3.探索产品一体化。

大家看到是否觉得无可厚非?但这样的目标成效意味着组织从这开始就很可能与真实的客户价值和服务目的断链。在成效定义时就偏离初心,接下来的一切运营行为都会受到影响


这家招聘类HR SaaS公司制定目标成效时应该问自己未来三年如何能帮助更多的XX目标客群提高员工招聘体验为客户的业务部门做增值。这样的视角转换将立即引发组织内行动的转变。团队可能会开始更多地考虑简化招聘审批流程,产品的业务价值归因,以及开始为客户内部人资数字化转型所需的种种服务做设计。这将与初期设定的目标成效时的组织行为都完全不同。


其次关于目标成效的度量,ToB企业会自然利用常见的财务指标来度量。如上述的初始目标成效的度量就将会是ARR提升XX%,毛利率提升至XX%等,遗憾的是这样的度量与客户价值成效的目标再次断链,客户成效达成,你无法扩大影响,客户成效未达成,你也很难发现并停止


理想情况下,应该先定义对客户价值成效的度量,然后才是执行工作得到财务结果Output,前者是后者的前置指标Input。如,客户成功团队的度量,客户健康度就是前置指标,客户续约率就是结果指标。


大部分情况下,利己的成效与度量都是组织经营的安慰剂。试想如果Input都无法干预和影响Output,我们是准备对着财务指标去祷告吗?


//迷思的表现2:

期望复 制成功企业的业务体系,对PLG等概念有着莫名的执念

ToB企业搭建业务体系的关键是动态适配自身组织的战略定位,业务上下文,不应照抄成功企业的系统。


例如某一个服务中小客户的企业建立初期就号召全员学习华为业务体系,试图也在自身企业内构建建立对应的三个系统,即IPD(产品集成开发)、LTC(机会至收款)、ITR(售后)。但这样搭建其业务体系明显高配低就导致实际投入巨大,还未开始迈向市场,内部成本就已经严重超标。


相对于外部直接拷贝,我倾向企业进行内部萃取最佳实践,如发展初期当某些销售经理可以连续赢单,企业可以认为这种销售打法是适配自身产品的,是可行的,这样内部萃取的销售打法才值得在企业内去花大力气去复 制


另外,美国在ToB数字化行业上是先知先行者,近两年诞生了诸如PLG、Revops、H2H、ABM等概念。拿PLG为例,今天PLG几乎被新一代 SaaS公司奉为圭臬,似乎PLG成立解决销售效率低下的银弹。值得肯定的是,PLG确实承载着ToB企业下一个发展阶段的美好期待。但需要指出的是,提升产品力本身是所有ToB公司的本分,而且PLG也有限定的适配范围,结果上看国内ToB市场的销售模式远未达到需以PLG为主。ToB企业执着于单方面的产品驱动增长,在未来竞争环境下,可能会错过真正的增长机会。


//迷思的表现3:

不尊重ToB产品生命周期的纪律

不可逃避的是,ToB公司在成长的不同阶段会面临不同的挑战。如SaaS产品的PMF阶段就类似于产品的“成人礼”,你可以不举办任何仪式但你必须面对自己的童年、青春期还是成人阶段。据我的咨询观察,PMF阶段就有两大陷阱:对自己的客户价值创造开始自我欺骗和等不及开始规模化增长。陷入这些陷阱最后都会付出代价,因为客户会用脚投票。


关联到G7物联创始人翟学魂的一个独到观点“要遵守 ToB 产品生命周期的纪律,这个纪律指的是 ToB 企业不要挑战和跨越产品的每一个周期,否则会付出沉重的代价。”这个观点里很深刻的是「纪律」二字,而不是规律


ToB业务怕错,不怕慢。ToB创业容易控制不住欲望,如渴望产品一体化、提前规模化、跨能力交叉销售等,ToB公司必须要围绕客户价值创造和遵循经营常识来运作了。

 


三.组织能力的迷思


//迷思的表现1:

团队是按职能惯性建立的

我们需要面对的是,那些发展了几十年的业务流程、实践、组织架构、财务事项以及其他支持内部职能的事物,都不是以外部客户的视角来运作的。


在过去ToB企业会基于销售漏斗(Funnel-based)来构建团队,习惯性从市场营销、SDR、销售、实施一直到客户成功来考量团队组建、并试图设计团队间的价值流转。我们仍然被传统的预算机制和组织结构所约束。这样按职能惯性组建的团队容易产生以下问题:

1.客户是输出物。一旦客户离开销售漏斗,理论上他们就会被组织遗忘。

2.组织中各部门之间是错位的。谁是你们的客户?可惜的是,对于漏斗顶部的市场部,销售部门或许成了你们的内部“客户”。当团队方向就不一致的情况下,老生常谈的营销与销售协同的问题本质就解决不了。

3.转型工作难度增加。在这种团队结构下,转型工作必须卷入整个企业、所有部门才能完成,这也就导致了笨重的工作流程和各种转型路障。


基于销售漏斗(Funnel-based)来构建团队而不是以客户为中心(Account-based)来构建团队。这也是源于一种自我保护的倾向,确保我们所拥有的技能被重视。

一个满是售前咨询专家的团队,当然会努力确保组建售前咨询团队——不管它成本是否高耸。一个满是AI技术专家的团队,当然会努力确保使用最新的AI技术 —— 不管它是否是给客户带来价值的解决方案。

 


//迷思的表现2:

工作是根据人员技能与经验确定的

ToB企业管理者,你是否有因为团队内有同事操盘过抖音自媒体,你就想让他也为公司做一个抖音号试试?有时我们仅仅因为工作内容是团队可以做的, 甚至是因为我们想让团队忙碌起来而展开工作。但是,这些工作如果并没有与我们上面定义的价值成效和度量对齐,那么从这一开始就注定了价值成效上的失败和时间的浪费,只是为工作而工作。


当团队能够看到他们为什么要做这项工作,明确了价值成效和成功度量,他们就会知道什么时候该转向、什么时候该加速来助力目标的实现。


例如某招聘类HR SaaS公司的市场线索团队从原先的成效与度量分别是帮助公司从市场转化更多销售线索和SQLs改变成帮助客户建立初期的安全感和X周期客户与品牌互动的频率频次。那所需的工作可能是:增加与客户互动的渠道与方式、增多利他的内容与活动。对应的所需技能就是自媒体运营、内容生产、社群、电话互动了。


在ToB企业常见的做法是将公司整体的经营目标拆分至部门KPI,进而拆到岗位。例如你的客户实施团队的实施顾问岗位的KPI可能是:项目接单率,项目验收通过率、项目准时交付率等。但这样容易让实施团队在执行中容易忽略了客户价值成效而在追踪这些KPI结果。


//迷思的表现3:

领导者对组织能力的变革犹豫不决

导致企业领导者对组织能力的变革犹豫不决的关键原因是害怕失调、失控已至失败。但是,我们要如何定义失败呢?组织变革本身没有确定的终点。所有的ToB企业都是在一个不断演进的状态中开展经营活动的。如果组织能力的变革转型能够提高效率或带来增收,并在这个数字时代提供持续的竞争优势,那么企业为什么要停止转型呢?


我们是时候反思面对转型的心态了。很多ToB企业领导者都是产研背景,想必都明白软件工程里的经典法则“康威定律”:任何组织在设计一个系统或产品时,都会产生一个复 制该组织沟通结构的架构。换句话说,如果团队是孤立的,结果也将是孤立的;变革中的挫折和阻力,大多数源自于你的运营模式产生的后果。

 

在数字化转型浪潮中,ToB企业很多时候扮演的是赋能者,类似诊断病情提供方案的医生。相信你们在客户经营过程中都会面临到由于客户的CXO以及各管理方对自己的组织或业务数字化变革决心不足所带来的挑战。


现如今,ToB企业自身到了需要面对自己的数字化变革决心的时候了。不要出现“医者不信医”和“医者无法自医”的尴尬处境。


02

面向客户价值的企业运营新模式


需要强调的是ToB企业运营模型的变革也是手段不是目的,回溯自己的初心是第一步。以终为始,检视传统的职能和层级结构探寻业务与客户价值流的阻碍。另外,不必惧怕组织级的运营的复杂性,面对这样的复杂性,意味着必须找到运营本质,根本性地简化运营模式。


如果你的组织仍在根据团队能做什么以及只利己得思考为企业实现什么来设计工作。

如果你一直在探寻变革,以帮助你的企业/组织成为真正以最大化创造客户价值为目标,并相信这样可以带来真正的盈利增长。

如果你期望组织可以更好的适应当下多变的市场和拓展能力,构建高响应力的敏捷组织。

那就尝试一下面向客户价值的运营新模型吧。


只是,ToB企业你要实施它,需要有十足的勇气,因为它完全颠覆了你根深蒂固的经营习惯、组织结构。


一.根本性地简化运营模式 


这样面向客户价值的简化运营模式,可以转型客户价值主张和组织交付运作方式。这个运营元模式即客户决定成效→成效决定度量→度量决定工作→工作决定技能→技能决定团队。

 

1.客户决定成效:

一切从客户开始,为ToB企业经营设定的成效目标必须由客户的价值需求来驱动。

2.成效决定度量:

进而客户的价值成效决定了你的度量指标 —— 度量正确的事情。

3.度量决定工作:

一旦明确了这些度量指标,ToB组织就可以设计正确的工作、更多的激发创新来推动指标达成。

4.工作决定技能:

基于正确的工作,推导完成工作所需的技能,进而进行内部技能发展或外部引入。

5.技能决定团队:

设计满足技能要求的团队结构。


什么是驱动国内ToB业务发展的关键动能?我认为是创新。不论是产品创新、运营创新、营销创新还是服务创新,而不是未来仍然在“Copy to china”。然而,这种思考模式和运营模式可以帮助企业激发组织中的员工创造性地思考和行动,去探索新的想法,真正是围绕客户价值来开展工作和提升技能


二.对企业运营革新的行动建议


不论你是ToB企业里的CXO还是部门负责人,乃至骨干一线,都值得去思考去行动。我分享几点运营变革的行动建议给到大家。


//对于ToB企业CXO:

1.行动之前先打消你的财务顾虑。

尽管“以客户为中心”已经成为ToB经营核心理念,但诸如投资回报率(ROI)和ARR、销售额、毛利率、续费率等传统的财务指标,仍然主导着你们的经营决策。上述运营模式的财务逻辑是通过规模化的客户价值创造带来规模化盈利增长。关于经营成本可以通过经营投资举措的前置评估与价值回检来控制。


2.利用精益切片在短期速赢。

首先不要将大海煮沸(don’t boil the ocean),将面向客户价值的运营新模式进行全面转型的话,的确存在复杂度高、风险大、失败率高等问题。建议ToB企业可以从“薄的切片”(thin slice)开刀,定位于某个客户价值成效目标,但切口必须“很深”,要贯穿组织的每个层面,如从Sale VP一直到程序开发人员。


通过这样的精益切片来速赢的同时,可以识别组织中拒绝变化的抗体,然后再针对这些问题去想对策。然后另外来一刀薄片去解决其他问题。持续做下去,你将创造了一种良好的文化,让人们自觉地融入其中,而不是强制性地推行。”

 

彼得.德鲁克的名言:“管理就是把事情做正确;领导就是做正确的事情。”现在是高管团队挺身而出,自我颠覆,成为数字时代领导者的时候了。


//对于ToB企业中高层:

需要你们去劝说面向客户价值的变革并获得支持,而不是不愿意改变固有习惯,自身成为变革的阻力。


需要你们去加强将工作举措与价值成效关联的能力,根据度量指标适时作出举措调整,而不是等着产出业务结果


需要你们更多地去共同讨论如何将工作举措设计成可执行的细节,以确保价值成效交付,而不是只是追着Deadline。


//对于ToB企业骨干一线:

假如你们所在ToB企业短期内没有改变,而且财务结果导向的KPI依然让你们处在于困境的话,无法破局的话。请你们要深信:解决你自己所面对的问题的途径关键是在于你如何解决别人的问题。


建议你们拿起「面向客户价值」这个工具去回检自己的所有工作,不论是市场活动设计、客户案例标题、售前讲标还是续约谈判等等。

 

篇幅有限,未尽之处,欢迎阅读伙伴朋友可以vx:tracy25200找到我一起互动交流。



新年伊始,ToB企业需要从根本上重新构想自己如何创造价值,需要重新思考如何通过生态系统最大化创造价值,并转型自己的企业以实现新的价值创造模式。


如果你不能回答“我们为什么还在这个商业世界”或者“我们为客户增加了什么独特的价值”这些问题,那么你可能充其量只是让企业能够照常经营和“留在游戏中”,而不是为成功建立真正的长期竞争优势而演进。


很欣喜的是看到很多国内ToB企业在疫情期间开始修炼内功,回溯企业的愿景使命价值观。

就像这样,开始行动吧!哪怕只是一小步~




来源:工业软件产品分析
理论游戏控制
著作权归作者所有,欢迎分享,未经许可,不得转载
首次发布时间:2024-07-13
最近编辑:5月前
石寒ColdStone
让制造业从业者过上舒适的生活
获赞 14粉丝 1文章 38课程 0
点赞
收藏
作者推荐

读书笔记:产品经理如何与开发沟通

产品研发是开发的职责;向开发解释研发什么产品,是产品经理的职责。不同规模和成熟度的机构中,开发团队的独立程度存在差异。在小创业公司中,由于资源有限,开发团队可能只有一名或几名成员,这时CEO、CTO或主程需要承担产品经理的职责。随着公司的发展,产品复杂度提高,开发团队需要更加专注于解决方案的实现和维护,这时就需要产品管理介入,以解决业务、市场和客户需求等方面的问题。为了确保产品和开发团队之间的顺利配合,成熟的公司通常有一套标准的操作流程。这些流程基于常见的软件开发范式,如敏捷、Scrum或瀑布流模型。对于不熟悉这些框架的产品新人来说,了解这些范式是非常必要的。通过了解这些流程和范式,产品经理和开发团队可以更好地协同工作,确保产品的顺利研发和交付。01跟开发经理安排工作在许多软件企业中,史诗、故事和需求这些敏捷概念已经成为标准的工作方法。这些概念的引入,使得工作范围更加清晰,有助于更好地规划工作。史诗可以被视为一系列故事的集合,它以某种有意义的方式展现了实现更宏大的产品愿景所需的实际过程,并将其封装起来。而为了实现史诗所需的增量开发过程,通常需要多个故事的组合。在开始规划敏捷冲刺时,产品经理应与开发团队密切合作。他们需要仔细检查待实现的史诗,确保每位团队成员都能理解它对客户的价值。只有当团队真正理解了史诗的价值后,产品经理才能开始将其拆解为一个个独立的故事和需求。除了产品经理,开发经理在团队中也扮演着重要的角色。他们是公司的资深开发人员,具备一系列关键技能。首先,他们非常熟悉团队中每位程序员的技术实力和弱项,能够高效地分配任务和安排工作。其次,由于经验丰富,开发经理能准确预估产品待办事项清单中各项工作(即“故事点”)的工作量。这有助于确保项目按计划进行,并合理分配资源。此外,开发经理具备预警能力。他们能尽早提醒团队注意预期存在的问题或偶然遇到的问题。在情况严重时,他们甚至会直接给出警告,并调动团队成员开展头脑风暴,寻找解决方案。基于这些技能,开发经理能够对开发工作进行合理评估和有效规划。一旦对故事点有了准确的估计并确定工作日志,产品经理就能够更准确地预估开发速度。随着时间的推进,他们还可以借此不断改善整个流程。在分配需求时,产品经理应尊重开发经理的判断。通常来说,产品经理更擅长帮助开发团队解答与特定需求相关的一次性问题(比如,“该列表应显示全部描述信息,还是截取一部分”)。而技术出身的产品经理应保持一定的距离,让开发团队更有效地处理其工作。通过这样的协作方式,团队能够更加高效地实现产品愿景,为客户创造更多价值。02如何与开发沟通帮助开发深入理解客户问题,他们理解之后,可发挥创新精神去解决这些问题。下面提供一些建议,帮助你思考如何与开发沟通:帮助开发理解问题,但是不要过度干预解决方案在与开发团队进行沟通时,帮助开发人员更好地理解问题是至关重要的。为了达到这个目的,可以考虑以下建议:直接接触客户:如果条件允许,可以安排开发人员直接与客户交流。这种面对面的沟通可以让他们亲身体验客户的问题和痛点,从而更深入地理解需求和期望。传达市场反馈:如果开发人员无法直接接触客户,你需要作为桥梁,将市场和客户的反馈传达给他们。将这些信息准确地传达给开发团队,可以帮助他们更好地理解问题的本质。鼓励创新:开发人员通常具有深厚的专业技术能力,让他们在理解问题后自由发挥,寻找解决方案往往能够带来意想不到的好结果。不要过度限制或指导他们的思考过程,给予他们足够的空间去创新和尝试。避免过度描述:在传达问题时,要避免陷入细节之中。过多的细节可能会让开发人员迷失方向,或者产生不必要的困扰。重点在于传达问题的核心和背景,而不是具体的细节或解决方案。共同决策:与开发团队一起讨论问题,共同寻找解决方案。这样可以增强团队的凝聚力和合作精神,同时也能确保解决方案更加贴合实际需求。提供反馈渠道:确保开发团队有一个有效的反馈渠道,可以在遇到问题或困惑时及时提出。这样可以避免在开发过程中出现信息不对称的情况。保持沟通畅通:定期与开发团队进行沟通,了解他们的进展和遇到的困难。这样可以及时解决问题,确保项目的顺利进行。通过以上方法,可以帮助开发团队更好地理解问题,并激发他们的创新精神,从而为产品带来更好的解决方案。2.让工程师恪守时间表,履行应尽的义务在项目管理中,时间表是重要的工具,用于确保项目按时完成。然而,工程师往往倾向于追求完美,这可能会威胁到时间表的执行。为了解决这个问题,可以考虑以下建议:明确优先级:与开发团队明确沟通项目的优先级,让他们了解哪些任务是关键的,需要首先完成。这样可以帮助他们更好地集中精力,优先处理重要的任务。设定里程碑:设定清晰的里程碑,以便监控项目的进度。这样可以让开发团队了解项目的进度,以及他们需要在何时完成哪些任务。提供清晰的目标:确保开发团队明确了解项目的目标,以及每个任务的预期结果。这样可以帮助他们更好地理解项目的整体方向,避免偏离目标。及时反馈:当开发团队遇到困难或延误时,鼓励他们及时反馈。这样可以让项目管理团队及时调整计划,避免问题累积导致更大的延误。避免过度优化:提醒开发团队,在追求完美解决方案的同时,也要考虑时间表的限制。帮助他们平衡质量和时间的要求,避免过度优化导致项目延期。建立协作机制:鼓励开发团队与其他相关部门建立良好的协作机制。这样可以更好地协调资源,避免因沟通不畅导致的时间延误。灵活调整计划:在项目管理过程中,根据实际情况灵活调整计划。如果发现时间表过于紧张或存在其他问题,及时与开发团队沟通,共同寻找解决方案。3.永远支持你的团队与开发团队沟通,确保他们知道你们是一个团队,荣辱与共,项目进展不顺,你也要担责任。项目即使失败了,也不要责备他们,沟通过程,只要能用“我们”,就不要用“他们”。4.迟来的赞赏与肯定,要给足大多数时候,工程师们默默地加班加点,精心设计和完善产品方案,却很少有机会在公众场合展示自己的成果,所以很容易被人忽视。我们应该让他们知道,他们的努力和付出是被人看见和认可的。每当我们和别人谈论或想起这些工程师时,无论何时何地,都应该发自内心地肯定他们的付出和努力。他们的辛勤工作让我们的产品更加出色,让我们的机会成为可能。5.客户增减这些事,不要引起开发的过分忧虑,但也不要撒谎作为开发与客户之间的桥梁,产品经理的观点和态度对于产品的未来发展具有重要影响。当客户对产品不满意时,产品经理需要如实告诉开发团队,但同时也要保持乐观态度,相信开发团队有能力解决问题、扭转局面。为了让开发团队更好地理解产品的价值和意义,产品经理需要让他们看到产品是如何解决客户的痛点和需求、为公司创造收益的。每个人都希望自己的贡献得到认可,因此,产品经理应该多与开发团队分享成功案例和故事,让他们感受到自己的努力对于公司的重要性。当需要用客户的反馈来支持某个项目的合理性时,产品经理需要与开发团队一起详细讨论客户的反馈意见。通过与开发团队的沟通和协作,产品经理可以帮助他们更好地理解客户需求,从而为客户提供更优质的产品和服务。来源:工业软件产品分析

未登录
还没有评论
课程
培训
服务
行家
VIP会员 学习计划 福利任务
下载APP
联系我们
帮助与反馈