首页 > 其他分享 >深度研究:接连创造高估值、高增长神话的PLG

深度研究:接连创造高估值、高增长神话的PLG

时间:2023-04-25 23:03:14浏览次数:97  
标签:神话 增长 用户 模式 PLG 接连 产品 团队

组织架构不匹配、权责分配不清晰以及团队协作无机制是推进PLG业务面临的三大核心挑战,而安全软件公司Snyk以其指数级营收和估值增长的成功实践证明,构建合适且高效团队是助力PLG创新实现高速增长的关键,其经验值得借鉴。本文将通过分析Synk如何构建起全能型跨职能团队,如何定义PLG团队核心权责,以及如何制定引领性指标驱动团队高效协作,为SaaS企业构建PLG团队提供最佳实践和关键启示。

一流的 PLG团队 应该是什么样子的?

这是常困扰创始人、投资者和领导者的问题之一。这也是那些正在优化现有PLG模式的企业和那些正在从头开始构建PLG模式的公司所关心的首要问题。一些常见的问题包括:

  • 是否应该有一个专门的团队,还是直接让产品团队负责业务的推进和执行?
  • 是否应该有人或者团队对自助式的服务所带来的营收负责?如果是的话,那么应该谁来负责?
  • PLG团队需要哪些人才、技能和经验?如何召集到这些人

01. 从组织、权责和协作机制入手,打造PLG团队的九大启示

从团队组建、权责共识到协作模式设置,是Synk打造高效运作PLG团队,高效实践PLG创新的核心关键。

安全软件公司Snyk

1.1 团队组建:最大化利用内部人力资源,构建全能型跨职能团队

那么PLG团队到底是什么?我们又如何构建它?

PLG团队是全能型的跨职能团队,被授权创造、发展和迭代全链路的产品体验和增长模式,以推动客户的获取、留存和变现。基于上述定义,我们可以总结出以下三点:

  • 相互关联的增长结果:每个增长结果都作为一个更大的增长模式的一部分而相互作用
  • 全链路用户体验历程:关注产品整个生命周期的端到端的用户体验。
  • 全能型跨职能团队:保证团队想法和能力的多样性,可独立推动产品开发、优化和交付。

增长模型和增长战略重点将决定PLG团队在任何特定时间内的优先级。有时,重点将需要通过自助式服务来改进激活效果,作为改善长期留存和未来变现潜能的高优先级手段。在其他时候,重点可能会转移到通过内容飞轮(如产品驱动SEO)或病毒飞轮(如推介分享机制)来实现新用户增长。变现计划可能包括自助服务或通过产品驱动销售(PLS)过程中和企业GTM销售团队的协作。较大的PLG团队能够同时执行多个重点领域。

因此,PLG团队通常是按增长结果(获客、变现和留存)而不是按产品功能或产品架构来组织的。随着时间的推移,该组织不断发展,以适应更多元的增长模式和市场的变化。

以增长结果为导向使PLG团队能够实践任何能实现该增长目标的策略。例如,优化用户激活的团队可以通过打开新的获取渠道来获客,去挖掘ICP以实现更高的激活率,或者通过优化注册和登录体验提高激活率;专注于新用户获取的团队可以通过产品建立一个新的增长飞轮,以用户口碑撬动病毒传播。

增长的场景包括公司网站、网络应用、移动应用、集成第三方平台的内容、通知(电子邮件、Slack/Teams),以及更多(例如开发工具领域的IDE),这就是整个产品视角的重要性所在。

以Snyk为例,仅获客目标而言,就尝试过以下的策略:

  • 网站登陆页面和登录流程的转换优化
  • 建立基于内容的SEO优化的增长飞轮
  • 建立和优化团队邀请和推荐机制
  • 不需要注册的免费试用工具

为了在整个用户和客户生命周期中有效地专注于增长目标,PLG团队需要真正的跨职能团队,是能在不同的场景和媒介上工作的多元化团队。产品经理、开发人员和设计师往往构成该团队的核心角色。根据我的经验,PLG团队还必须包括决策科学团队/人员,以及增长型营销人员。这种多样性不仅为创新和实验的新路径带来了更合适的工具箱,也带来了更丰富的创造性想法。

虽然很难给出唯一正确的团队构成,但一个好的经验法则是,在B2B SaaS的PLG团队中,每个团队都应该有:

  • 1名产品经理
  • 1名工程经理
  • 3-5名工程师
  • 1名设计师
  • 1名增长型营销人员

决策科学团队/人员更多是作为一种共享资源和中心职能,可以支持两到三个团队,并帮助连接起整个生命周期的数据,而增长型营销人员通常会成为团队专家。例如,一个专注于激活的团队最好得到生命周期营销专家的支持,而一个专注于获客的团队将受益于有搜索引擎相关专业知识的专家的帮助。在工程方面,一般来说,开始时规模较小,并随着时间的推移而扩大规模是首选。规模较小、处于早期阶段的组织的团队可能会有更多的工程经理参与。

多年来,我了解到的一些最令人惊奇、最成功的招聘其实往往就在眼皮底下。这就是为什么投资于内部人才的流动或许是一个很大的优势,例如:

  • 横向岗位调配:例如管理平台的产品经理调配到PLG的产品经理的岗位。
  • 优秀人才晋升:例如明星级的增长PM承担更多PLG增长模式发展的职责
  • 团队角色转型:例如有才华的工程师转型为PLG团队中产品管理者角色。

对于PLG团队的成员来说,适应高度协作是核心要求,否则,就难以最大化体验到跨职能协作带来的价值。他们需要是个行动派,能快速调整,接受失败,并将其作为学习过程的必要部分,同时非常乐于分享他们的想法和实施经验。

同时,他们应该有超强的好奇心,喜欢与用户交谈并向他们学习,并通过工作所能创造出的可量化的、高质量的影响而感受到巨大的成就感。不是每个人都觉得这样的工作环境是非常舒服且合适的,但这没关系,但在招聘PLG人才的时候,必须要牢记这些特质,这将有助于避免招到不合适的人所带来的高昂代价。

安全软件公司Snyk PLG团队-团队组建

1.2 权责共识:以PLG模式主导,并辅以SLG、MLG加速企业增长

考虑获客、留存和变现三个核心增长环节。每个企业都需要能够回答以下问题:

  • 如何获取用户/团队?
  • 如何留存用户/团队?
  • 如何变现用户/团队?

在每个增长环节中,企业会基于核心的(或者协作性)的增长模型,或者理解为增长驱动力,包括产品驱动、营销驱动和销售驱动。

当用户体验到产品价值时,大多数公司留存用户和团队的主要增长驱动力都是通过产品驱动的,许多企业还将拥有或希望通过产品驱动增长的模式来实现获客和变现,这是终端用户时代为PLG创新模式带来的增长红利

增长模型是用于描述和量化产品的增长的核心。创始人或早期的增长团队可能会创建最初始的增长方式,但随着时间的推移,PLG团队通常需要通过更成熟的增长模型,确保他们能更直接地观察到的增长飞轮的效果、增长团队的经验、产品的演变过程以及公司增长战略的调整或更广泛的市场变化,使企业能持续对市场保持敏锐的嗅觉和快速的响应能力,以更好地迭代增长模型,入局企业关注的战略机会。

但增长模型不仅限于主导PLG团队的执行计划,还需要为公司其他团队如销售、营销和研发团队制定计划,因为增长目标通常是多部门共同协作来完成。

如果没有这个专门的团队,通常不存在有人能对增长模型负责,除非是企业构建了特定的增长团队负责整体的增长,但更糟糕的事实是,在一些企业里,增长模型甚至没有被创建和量化。增长模型的缺失,将会导致不理智的需求优先级判断,尤其是一些竞争性的优先事项,如建立功能X以帮助完成下一个大交易,但这可能同时意味着一些更重要的产品增长计划没有足够的资金和资源,或完全被忽略。

这里需要注意的是,PLG团队不是负责增长计划的唯一团队,例如当MLG和SLG的增长模式成为重要驱动力的时候,PLG团队需要进一步与销售团队和营销团队进行高效协作。优秀的PLG组织,会将增长融入其DNA,只是会将产品作为优先级更高的驱动力,PLG团队需要判断该驱动力能否支持整体增长模式,或者是否能加速或抑制微观和宏观增长飞轮,判断新功能的初始和持续成功的标准可以包括功能层面和产品层面的相关核心增长指标。

在这种情况下,拥有PLG团队可以成为一种超级力量,因为PLG团队可以专注于识别和跟踪:

  • 增长模式中的核心制约因素
  • 找到并减轻这些限制
  • 让增长飞轮更快地运转起来
  • 以及在适当的地方和时间引入新的飞轮

若企业将PLG的成功押注在单一的团队上,如产品团队,那么失败的可能性会很高。企业各团队(传统企业中按职能分配的团队)需要意识到增长模式的存在,以及他们所做的事情是如何促进增长的。因此考虑将这个团队命名为 “PLG团队 “,或许将其称为 “生命周期团队”会更合适。

另一个重要的考虑是时机:什么时候是创建专门的PLG团队的正确时机?一般公认的建议是在产品市场匹配(PMF)之后。在这之前,团队的每个人都应该专注于达到这个关键的里程碑,而且不要低估小规模起步的价值,这将是企业持续实践新工作模式的关键时期,如此团队才能围绕可能的新工作方式建立起肌肉记忆,小团队在早期时会非常有效,并且能为团队的扩大提供早期验证,为后续的规模化沉淀可复用资产。

安全软件公司Snyk PLG团队-权责共识

1.3 协作模式:制定合适指标,并收集可靠产品数据驱动持续迭代

大多数B2B公司默认将收入视为北极星指标。然而,收入是一个滞后的指标,与许多团队的日常活动相去甚远,因此,了解整个公司的团队如何为实现收入目标,并如何做出贡献至关重要,并合适的指标指导团队的日常协作。

对于以产品驱动增长的公司来说,收入与用户、团队和公司能从产品中体验到的价值密切相关。因此,在PLG公司中,北极星指标(NSM)应该更大程度去描述和代表产品价值,NSM通常是基于产品参与度的指标,以此来衡量用户感受产品价值的情况来判断未来的营收潜力,并且公司中每个面向客户的职能部门都有能力以某种方式影响这个指标。

基于产品价值而定制的北极星指标,可以进一步拆解,以衡量相关的增长环节,因此,它可以作为回归分析的基础,帮助定义围绕PLG为核心的重点指标,如激活和频次等情况,以此作为营收的前置指标,预测营收的潜力。这种逆向分析可以帮助团队特定的增长策略能带来的实际影响和增长效果。PLG团队的日常协作模式就是对北极星以及其进一步拆解的增长指标进行研究、定义,并基于真实的产品数据持续优化用户体验。

限于篇幅,请进入Runwise.co创新社区查看原文.     [原文链接]:

创新案例|安全软件Snyk如何打造高效PLG团队实现ARR年增长1.6倍

 

其中“Runwise.co创新社区” 连接到 https://runwise.co?source=csdn

标签:神话,增长,用户,模式,PLG,接连,产品,团队
From: https://www.cnblogs.com/runwisedigital/p/17354259.html

相关文章

  • 2023.4.25-人月神话-4月份读后感3
    最近,我阅读了人月神话的下一部分,我有了许多的感悟。过去,我对于自顶向下的设计不够重视。好的自顶向下设计从几个方面避免了bug。首先,清晰的结构和表达方式更容易对需求和模块功能进行精准的描述。其次,模块分割和模块独立性避免了系统级的bug。另外,细节的隐藏使结构上的缺陷更加容......
  • 人月神话阅读笔记2
    第七章对其他软件工程师提出的反驳进行回应。作者认为,虽然软件工程领域在过去几十年中发展迅猛,但是由于软件项目本身的特殊性以及人类本质的复杂性,软件开发仍然存在很多挑战和困难。因此,要想使软件开发过程更加高效和有序,需要深入研究软件开发的本质和规律,并制定相应的开发方法论......
  • 《人月神话》读后感1
      《人月神话》是一本由弗雷德里克·P·布鲁克斯所著的软件工程经典书籍,探讨了软件开发过程中的一些普遍问题和挑战。  第一二章主要介绍了软件工程中的两个重要概念:人月和管理。人月是指开发一个软件项目所需的时间,管理则是指在软件项目中合理地组织和管理人员的活动。在阅......
  • 人月神话阅读笔记06
    继续干将莫邪看到这个阅读题目,一般不会将他跟编程的阅读笔记联系起来,但是,这个模块主要讲述的是资源的合理利用,其中也包含着“工欲善其事,必先利其器”的道理;主要强调了合理的资源利用更有助于项目的完成,较好的编程方法(也可以是更适合自己的方法),更加有利于项目的实现与完成!整体......
  • 人月神话1
    第一次看到《人月神话》这本书,若不是老师推荐,还以为是本神话小说呢!由于对软件工程了解的不多,对这本书的解读不深刻。不过,从很多方面可以了解到这是一本畅销的、具有深远意义的书。这本书讲述了几十年前软件专案管理问题与经验,作者将大型系统开发比作一个焦油坑,我原本以为软件开......
  • 人月神话读后感03
    以下仅为我对一些章节的感受第11章:未雨绸缪为舍弃而计划,无论如何,你一定要这么做唯一不变的就是变化本身程序维护就是:前进两步,后退一步。随着修改的增多,还可能变为:前进一步,后退一步。第12章:干将莫邪工具很重要,需要专门人员开发“仿真装置”很重要不确定性是所有情况中最糟的,因为它......
  • 人月神话读书笔记02
    我过去是怎么做的:单纯把编程作为工作这样做为什么不好:没有乐趣就没有动力解决办法:第一章焦油坑编程系统产品只有编程系统产品才是真正有用的产品,是大多数系统开发的目标。职业的乐趣创建事物的纯粹快乐;eg:当自己写完第一个helloworld时候的欣喜来源于开发对......
  • 人月神话读书笔记03
    本次阅读第七章 我过去是怎么做的在编程之前没有清晰的目标,写到什么就去做什么这种做法为什么不好思路不够清晰,导致编程没有逻辑性如何解决:7.为什么巴比伦塔会失败?关于巴比伦塔的故事:维基百科TowerofBabel7.1巴比伦塔的管理教训据《创世纪》记载,巴比伦塔是人类继......
  • 人月神话读后感02
    ——众所周知,一名孕妇需要36-42周才能够产下胎儿,那么如果有10名孕妇,产下胎儿的时间可以缩短到一个月以内。如果您真的着急,希望在2周之内要个孩子,那么我们只能够再添加一倍的人手。——写在最前。一般来说,本人读书之后,都会在一两个星期之内总结并且完成读书笔记,不过《人月神话》是......
  • 2023.4.18-人月神话-4月份读后感1
    最近,我阅读了人月神话的一部分,有了一些感受。过去,我对于编程的乐趣不是很了解。编程为什么有趣?首先是一种创建事务的纯粹快乐,其次快乐来自于开发对其他人有用的东西,第三是整个过程体现出魔术般的力量,第四是学习的乐趣,最后乐趣还来自于工作在如此易于驾驭的介质上。编程非常有趣,在......