Snyk 如何打造产品驱动增长的巨兽 | Ben Williams（Snyk 产品副总裁）

Ben Williams 2022-11-06

Snyk 如何打造产品驱动增长的巨兽 | Ben Williams（Snyk 产品副总裁）

翻译

增长循环与策略聚焦

Ben Williams：

能够识别各种微观和宏观循环，理解它们之间的关联，并将它们记录在定性模型中，从而形成关于增长方式的共同认知，这确实非常强大。在此基础上，再辅以定量分析来引导季度间的重点聚焦，确保你能有意识地进行投资决策，这将成为一个巨大的推动力。在一个高绩效的增长团队中，你永远不会缺乏想法。因此，在纷繁的想法中知道应该聚焦何处，正是策略所扮演的重要角色。

节目介绍

Lenny：

欢迎来到 Lenny’s Podcast。我是 Lenny，我的目标是帮助大家更好地掌握打造和增长产品的技艺。我会采访世界级的产品领导者和增长专家，从他们在打造和扩展当今最成功公司过程中积累的宝贵经验中学习。今天的嘉宾是 Ben Williams。Ben 是 Snyk 的产品副总裁，Snyk 很可能是你从未听说过的最大、也最有趣的公司之一。Snyk 让开发者能够轻松发现代码中的安全问题，而 Snyk 的起步之路有太多值得借鉴之处——它通过产品驱动增长起步，演变为产品驱动销售（product-led sales），非常注重社区驱动增长（community-led growth），同时高度聚焦开发者，而这已经成为当下最具商业价值的目标市场之一。

我们在对话中探讨了创始人如何获得前一百名用户，他们早期尝试商业化时犯了什么错误，何时招募了第一批市场和销售人员，他们如何搭建和扩展增长团队与产品团队，关于免费增值（freemium）模式中该包含什么、不该包含什么他们得出了哪些结论，以及更多内容。你很快就会听到，Ben 是英国人，所以这期节目会自动变得更加文雅，我迫不及待让你听到。接下来，有请 Ben Williams。

正式对话

Lenny：

Ben，欢迎来到播客。

Ben Williams：

非常感谢，Lenny。首先感谢你的邀请。很高兴终于见到你。我必须说，你通过新闻通讯和现在这个播客所创建的内容，对于产品增长和更广泛的科技社区来说都是非常棒的资源，所以能受邀上节目真的很荣幸，希望听众能从中收获一些有用的东西。

Lenny：

太棒了，非常感谢。我毫不怀疑大家一定能收获很多有用的东西。我非常期待聊聊 Snyk 以及你们在那里打造的产品。我觉得 Snyk 是一家很少被谈及但又极其迷人的公司，尤其是在它的起步方式和扩张路径方面，同时它也处于众多趋势的交汇点——产品驱动增长、社区驱动增长、以开发者为中心的增长，以及整体安全领域都非常有趣。所以我非常期待我们的对话。

Ben Williams：

我也是。

Ben 的职业背景

Lenny：

在深入这些话题之前，我想先简单聊聊你的背景。你目前是 Snyk 的产品副总裁，我很好奇你是如何走到这个角色的，以及在职业生涯中做过的一些精彩的事情。

Ben Williams：

我尽量简短。我的专业背景是计算机科学，90年代末从曼彻斯特大学毕业。当时我已经拿到了一份开发者的工作，但后来又得到了一些其他有趣的机会，其中一个就是加入一家小型创业公司，为产品和工程人员构建需求管理工具。那时还在敏捷（Agile）出现之前，但开发者工具、工程工具这个领域，我一直自然而然地被吸引，这也成了我整个职业生涯的专攻方向。我实际上是以解决方案工程师（solutions engineer）的身份加入那家公司的，做了很多产品演示之类的工作。我与产品团队关系非常紧密，同时每天都在和客户交流，这条路径——我想在业内也很常见——正是我进入产品领域的方式。

从 IBM 到 Snyk 的职业历程

几年之后，经历了几次收购，我来到了 IBM 的 Rational 软件开发者工具团队。我在那里负责部分产品战略和一系列项目。我在那里确实学到了大量有用的东西，但也意识到自己强烈偏好在小型、快速成长的组织中工作，而不是一个拥有 35 万人的庞然大物。中间有一段有趣而意外的插曲——我在一家金融科技公司主导了一次 DevOps 转型，之后又做了一些咨询和顾问工作——然后我加入了 CloudBees。这是一家采用开放核心模式的 DevOps 创业公司。我在那里负责产品设计增长。我在那待了三年，经历了多轮融资和一段高速增长期，最终加入了 Snyk，组建我们的增长组织，主导开发者体验相关的项目。我现在在 Snyk 的职责范围已经不仅限于增长组织了，不过最初就是这样开始的。

Lenny：

太棒了。为了让大家对 Snyk 有多成功、规模有多大有个概念，一个是 Snyk 到底做什么，我们还没聊过这个，另外就是目前公司和业务规模的一些数据。

Ben Williams：

我们是一家开发者安全公司，让开发者及其团队在保持快速迭代的同时，以极其简单的方式改善安全态势。所以，Snyk 能够发现并自动修复代码、开源依赖、容器、基础设施和云配置中的漏洞，这一切都由市场上最好的安全情报数据作为支撑，同时我们对开发者体验有着极致的专注，这正是我们真正与众不同的地方。这也是一个增长惊人的业务，拥有一批专注于 PLG 的杰出投资人和董事会成员，从 boldstart 的 Ed Sim 到 Slack 的 CPO Tamar Yehoshua。公司成立于 2015 年，F 轮融资后的最新估值是 86 亿美元。我们现在为数百万开发者提供安全保障，付费客户超过 2000 家，目前大约有 1300 名员工，其中约 500 人在研发部门，产品组织有将近 70 人。这里的人创造了一种了不起的文化，总而言之，这是一个非常令人兴奋的地方。

Lenny：

好的。你早期加入的时候，有预感到它会达到这样的规模吗？

Ben Williams：

是的，我觉得是因为我当时并没有在找新工作，最终却加入了 Snyk。当他们第一次联系我时，在整个面试过程中，我和每个人交谈后都越来越被这里的人才素质、公司的愿景和使命所打动。而你提到的那些——PLG、社区驱动增长、以开发者为重心、安全领域——如果你把我职业上真正感兴趣的、让我非常兴奋的所有事情画一个维恩图，那 Snyk 正好落在正中间。所以，这真的很酷。

Snyk 的起源与最初一百个用户

Lenny：

太好了。这是一个很好的过渡，正好是我想要开始聊的话题——Snyk 是如何起步的，Snyk 是如何获得前一百个用户的。我知道你当时不一定在场，但我很好奇你能分享多少关于创始人如何找到前一百个用户的故事。他们是如何触达到最初的开发者、让大家兴奋起来的？

Ben Williams：

我觉得这是一个非常有趣的故事。所以如果你不介意的话，我想花一点时间，因为我觉得回顾一下背景很重要——

Lenny：

请说。

Ben Williams：

好的，就回顾一下整个市场。PLG，或者说自底向上，和安全，这两个词以前从来没被人放在同一个句子里说过，对吧？安全一直是一个集中化的职能。安全项目在历史上更多是关于审计、监管和执行，而不是赋能开发者或赋权给开发者。销售方式也总是自顶向下的。买方被认为是不可绕过的 CISO 和其他应用安全负责人。当时市面上的安全工具都迎合这种格局，而这些工具会拖慢开发者的速度，造成大量挫败感，遭到很多抵触——这实在不是实现持续采纳、强参与度和高留存率的理想配方，而最终，基于这类方案的应用安全项目也没有达到它们真正需要的有效性。

所以，正是对这一现状的认识，加上 DevOps 带来的相邻市场变革，激发了 Snyk 的创意。创始人 Guy、Danny 和 Assaf 看到了一个真正不同的机会。他们相信，改善应用安全态势最有效的方式是开发者优先的方法。他们知道开发者越来越关心自己代码的安全性，就像他们关心代码的性能和功能质量一样。但他们也知道，要让开发者真正拥有安全自主权，他们需要比以往任何时候都好得多、摩擦小得多的工具。而回顾起来，他们的方法非常聪明——专注于社区。这还不完全是我们现在所理解的社区驱动增长的全貌，但已经很接近了。

他们起步时的早期聚焦非常窄——单一用户画像、单一上下文、单一用例。对 Snyk 来说，这意味着使用 Node.js 构建应用、希望确保自己引入应用的开源依赖是安全的开发者。开源软件是构建现代软件的巨大加速器。今天的平均软件应用至少有 75% 由开源库和组件构成。因此，这越来越成为恶意攻击者的主要攻击向量——他们可以在一个开源组件中找到一个漏洞，然后在每一个使用该组件的应用中发现并利用它。而与此同时，至少在当时，开源软件在安全漏洞方面的测试要少得多，开源库的维护者往往安全意识也较弱。了解了这个背景，再加上 Node.js 作为运行时正在获得越来越多的关注，企业在越来越多地采用它，越来越多的专门会议等等，但社区仍然足够小，Snyk 可以对其产生有意义的影响力。Guy 和其他人全力以赴地深度参与那个社区——他们在开发者大会上演讲、参加 meetups、构建线上内容等等。他们反复向社区提出的问题是：你的应用中是否存在已知漏洞？而 Snyk 就是来帮助他们回答这个问题的。顺便说一个有趣的小知识，如果你在 Urban Dictionary 上搜索 Snyk，你会发现它是 “so now you know” 的缩写。但所有这一切之所以能够奏效，我认为真正的原因是并行的产品驱动方式。所以，虽然在早期 Snyk 对于”你的产品如何变现用户”这个问题的答案还远不够清晰，但对于”你的产品如何获取和留存用户”这个问题，答案一直都是产品驱动的。

初期产品：开发者优先的命令行工具

Ben Williams： Snyk 的最初版本是一个命令行工具。它是为开发者打造的工具，可以在本地运行，也可以轻松集成到 CI/CD 流水线中以获得早期反馈。它让开发者能够对自己的应用安全承担更多责任，这与当时典型的传统技术完全不同——那些工具由安全团队在开发流程后期才运行，反馈周期漫长，问题被甩过墙丢给开发者，不可避免地令开发者倍感挫败。而这一切都建立在一个基本信念之上：对于以软件为核心的组织来说，应对保持安全这一挑战的唯一可行路径——我说的可行，真正指的是可持续有效的——唯一可持续有效的路径，就是采用这种由开发者主导的方式来应对挑战。所以说，这确实是对整个行业的彻底颠覆，也正因如此，开发者采纳对我们来说一直都是核心优先级。

免费增值策略与第一批用户

带着这样的理念，Snyk 从第一天起就在某种形式上提供免费使用。早期策略始终是创造有价值且触手可及的东西，以一种独特且有差异化的方式解决真实问题，然后让它无处不在。既然开发者主导的采纳是核心关注点，免费增值的市场策略就是显而易见的选择。所以，最终回到你最初的问题，以上就是所有的背景，包括他们在什么情况下、什么时候、以什么方式做的，而最初那一百来个用户确实就是创始人们通过参与 Node.js 社区以及由此带来的关注获得的。我想在尝试任何商业化之前，我们大概已经有五千名左右的免费用户。

Lenny： 太棒了。你讲的这些我想展开聊的内容很多，因为有趣的是，你描述的路径和我最近写的关于消费者增长策略的系列文章非常吻合。有了想法之后的前三步是：确定你的超级具体的”是谁”，也就是你的目标用户画像；想出一个能抓住他们、让他们兴奋的钩子；然后去他们所在的地方，向他们推销你的钩子。那么 Snyk 的超级具体的”是谁”，你说的是使用 Node.js 构建应用的开源开发者，对吗？

Ben Williams： 准确地说，是 Node.js 开发者，他们使用开源 Node 组件来构建自己的应用。

Lenny： 明白了。在这方面还有没有其他限定条件？还是说这就是用户的两三个核心特征？

Ben Williams： 基本就是这些。社区确实在增长，规模足够大，有不错的商业机会——但又在技术层面足够聚焦，意味着可以在合理的时间内把产品推向市场。

Lenny： 有道理。然后那个钩子基本上就是”你的代码库中存在已知漏洞”，如果我是工程师的话，大概会想，“天哪，糟了，我得赶紧搞清楚。我现在害怕了。”

Ben Williams： 没错。然后呢，so now you know（现在你知道了），对吧？

Lenny： 对对对，完全正确。好的，那关于”在哪里”这一点，你说他们去了开源社区。你有没有更具体的信息，这些社区都是些什么？是某个特定论坛？是 GitHub 上的某个地方？是 Reddit 吗？你知道这些社区具体在哪里吗？

Ben Williams： 其实与其说是某个特定的地点，不如说是那群专注于 Node.js 的开发者社区本身。早期的传播工作主要是在开发者大会上进行的。我记得是在阿姆斯特丹的 Velocity Conference 上，Guy 和 Assaf 第一次向世界展示了 Snyk，然后就从那里发展起来了。

Lenny： 我明白了，有意思。所以主要是线下活动、开发者大会和 meetups，而且应该是面向 Node.js 开发者的。

Ben Williams： 没错，是的。

深度优先的聚焦策略

Lenny： 好，那之后发生了什么？前一百个用户之后，是进入了下一阶段的增长，还是在那个阶段停留了很久？大概的下一步是什么？

Ben Williams： 是的。我觉得那种聚焦才是真正关键的要素。从窄聚焦起步、围绕社区参与来构建，我觉得这是现在已经被充分验证过的打法了，尤其是在开发者工具领域——比如 New Relic 就曾以 Ruby 社区而闻名。但归根结底它之所以重要，是因为这种深度优先而非广度优先的策略。Snyk 采取的深度优先策略对于在通往产品市场匹配 (product-market fit) 的道路上有效验证解决方案至关重要。一个 JavaScript 开发者根本不在乎你是否支持 Golang 或 Rust，但如果你生态系统中的某个关键功能——比如自动化包升级——不可用，他们绝对会在意。

当然，跨所有语言和生态系统的开源组件漏洞这个更大的问题，是一个非常普遍的问题，影响着整个行业。但这恰恰说明了那里有待释放的潜在机会。而 Snyk 的关键，我认为就是不要过早地铺得太广。它专注于为那个特定的 Node.js 开发者群体打磨好初始用例——就像我说的，足够窄以便能够真正聚焦、快速构建一个解决真实问题的有说服力的方案，但又足够宽，从增长的角度来看是可行的。事实上，仅在当时，NPM（Node Package Manager）就托管了大约 20 万个开源包，每月被超过 200 万开发者下载约 25 亿次。而一个典型的 Node 应用会有数百个依赖项，其中大多数是间接依赖，因此是隐藏的、不太容易被发现的。但每一个依赖项都带来了某些安全风险。所以说，我认为在向更广的范围扩展之前先打磨好那个窄而深的用例，绝对至关重要，这也是关于找到产品市场匹配并在撒更大网之前建立稳固势头的普遍可靠建议。当然，维持这种聚焦确实很难，因为更大市场的诱惑非常大，但归根结底，你必须先构建好产品并做好市场推广，才能真正抓住那个机会。

Lenny： 你有没有感觉到那种聚焦是什么时候扩展到相邻群体的？在增长故事进行到第几年的时候发生的？或者有没有什么里程碑？因为我知道每个人都会想，我们迟早会扩展，但问题是什么时候扩展、什么时候合理、什么时候太早。你对那个阶段有什么见解吗？

产品驱动获客与扩张时机

Ben Williams： 当然有。首先，如果我们聊 PLG 和 Snyk 的故事，我其实很喜欢你和 Julian Shapiro 聊天时他对产品驱动获客 (product-led acquisition) 的定义。在那种近乎偏执地追求找到产品市场匹配的基础上，创始人确实应该思考他们的产品将如何增长，这在考虑迈出下一步时当然非常重要。所以，用一个简化的定义来说，假设你已经通过强劲的留存率证明找到了产品市场匹配，那么真正的问题就是你的产品的新用户将从哪里来。我认为创始人对此应该有强有力的假设，否则本质上就是在赌”只要我们建好了，他们就会来”这种心态。

Ben Williams： 因此，如果你的获客策略是产品驱动的，那么理解并有意识地设计早期的获客增长闭环，我认为这是创始人不可推卸的责任。花时间把这些闭环设计进产品中，这是关键。当我说”产品”时，我实际上指的是整个产品体验——考虑用户和客户可能与你产生的每一个接触点，无论在核心应用之内还是之外。以 Snyk 为例，我们很早就相信可以通过在 GitHub 上发起修复 pull request 来构建强大的内容闭环。新用户注册 Snyk，连接他们的 GitHub 账户，Snyk 扫描他们的代码，发现漏洞，自动创建带有 Snyk 品牌的 pull request 来修复这些漏洞。仓库中的其他开发者会看到并与之交互，其中一些人会点击链接进入 Snyk，创建账户，还有一些人则会连接自己的仓库，于是这个闭环就持续运转。所以，这是一个公司生成、公司分发的内容闭环，对我们来说实际上非常强大，因为它同时既是获客闭环，也是互动闭环。

随着时间推移，我们通过增加对 GitHub 之外的其他源代码控制系统的支持来扩展这个闭环。我们还叠加了一系列新的闭环，我认为如果创始人能在产品早期迭代阶段就有意识地思考这些问题，那么当产品与市场真正契合时，你就会拥有更大的优势，而这些在 Snyk 的发展过程中是一步步内置进去的。所以，当我们找到产品市场匹配时，这些已经准备好了。但我觉得要具体讲 Snyk 如何迈出下一步的话，这跟我们之前聊天时提到的那个话题有关——我们谈到过一些在搭建自助服务收入渠道方面的失败经历——

Lenny： 实际上在我们聊那部分之前——我确实想聊那部分——我很喜欢你刚刚分享的这个故事。我之前没听说过这种增长策略，基本上就是用户连接 GitHub 账户，你找到所有漏洞，推送修复，人们看到 Snyk 为他们做了这件事，它就提供了所有这些价值，而你说这确实非常有效。这是一个非常成功的案例。

Ben Williams： 首先要说的是，把代码与安全扫描像那样集成在一起，在当时是首创。

Lenny： 对，简直是魔法。

Ben Williams： 之前没有人做过。但关键在于我们最终控制了内容。所以，修复 pull request 不仅仅在代码层面做了有用的事情，而且 pull request 的所有描述都在解释漏洞的情况、教育用户，全部都是 Snyk 品牌化的内容，写着”如果你觉得这有用，点击这里，来了解更多关于这个漏洞的信息。如果你还没有账户，就注册一个。“它让现有用户不断回访。

你如果没有账户就注册一个，它让现有用户不断回访，同时带来了新用户，而且是大量新用户。

Lenny： 你会在里面写着：“你的代码库中有已知漏洞吗？点击这里查看。“这个闭环是不是早期增长的主要驱动力？

Ben Williams： 我认为那是其中一个闭环。我们从相当早期开始还有另外几个内容闭环，更偏向程序化 SEO 资产的那种，它们在新用户增长方面同样发挥了非常重要的作用。

Lenny： 如果这些比较容易解释的话，很想听听那些闭环的情况，然后我们可以聊聊那个没成功的东西——你正要说到的自助变现的部分。

多层增长闭环

Ben Williams： 实际上我们到现在已经有不少闭环了，先从头说起。

Lenny： 你可真幸运。

Ben Williams： 是啊，说来有趣，我算是一个”闭环主义者”。不过确实，我们有一系列闭环。公司生成、公司分发的内容闭环对我们来说效果非常好。我们有一个叫 Snyk Advisor 的辅助产品。Snyk Advisor 基本上是一个供开发者搜索和发现开源包的服务，当他们在考虑将某些包集成到自己的软件应用中时会用到它。它的独特之处在于索引了所有的包管理器。它会学习这些包的相关信息，用大量元数据来增强这些信息，当然包括 Snyk 的安全扫描结果，但我们也会了解这些软件在 GitHub 或其他地方的源仓库上的维护活跃程度。

我们构建了一种包健康评分，所以任何人在 Google 上搜索某个功能的包或者按名称搜索某个特定包时，Snyk Advisor 都会排在搜索结果的前列。他们会登陆这个页面，对那个包有一个清晰的了解，可以查看类似的包，而这当然是一个 Snyk 的网站，我们有行动号召按钮，写着”如果你想持续保障你的应用安全，就来加入我们吧。“这是一个很好的闭环。这全部是程序化资产。有成千上万个这样的包页面，但它们都是持续自动生成的。

Lenny： 明白了。就是对开源库进行程序化生成的、更优质的索引，你可以集成进来。这太聪明了。它之所以是程序化的，是因为你可以提供安全漏洞方面的信息，还有维护和活跃度方面的信息。有意思，说得通。这些都是你可以直接收集的数据。太棒了。好的，这是其中一个。还有什么对你们的自助增长特别有效的东西吗？

Ben Williams： 最近一个很有意思的是安全教育。我们把 Snyk 视为推动 DevSecOps 转型的变革推动者，拥有这种能力当然好，但我们真正想要达到的状态是，开发者真正理解并且能够更好地防止安全漏洞被注入他们的代码。其中一件事，同样也是与行业中传统厂商做法相当不同的——是我们坚信安全教育应该民主化。

我们一直在打造一批高质量但精简的开发者安全课程，聚焦于面向开发者的安全问题和漏洞，并把这些内容公开呈现。同样，它们是完全公开的。没有任何付费墙来限制访问。所有传统方案都需要你注册、付费才能访问超过寥寥几节的内容。但这些课程全部公开在公共领域。这对我们来说作为公司生成、公司分发的内容闭环，效果也非常好。

Lenny： 太酷了。SEO 加上以一种有趣的方式与 GitHub 集成。我猜当有人在公司里使用 Snyk 然后传播给同事时，应该也有很强的公司内部病毒式传播吧？

Ben Williams： 对，嗯，我没讲那些。我觉得那些机制已经被广泛理解了。我们既有推荐闭环，也有邀请闭环。

Lenny： 好的，太棒了。回到那个没成功的话题，我想你提到过有一次自助服务导向的变现尝试，遇到了一些挑战。能聊聊这个吗？

自助变现的困境与转折

Ben Williams： 当时，几件事情已经到位了。有价值的产品，有了；强劲的开发者用户增长，有了；强留存，有了。但最初的自助变现努力，实际上只在个人开发者每月支付一百美元这一层看到了一些吸引力。而在大公司中的采购，并没有像大家期望的那样发生。那是 Snyk 历史中一个非常关键的阶段。当时不少投资者没有出手，也许是对于创始人在没有已验证的变现路径的情况下就大力投入做用户规模这件事，缺乏早期信心。我之前提到的 BOLDStart 的 Ed，他是最早真正相信这件事的人之一，我认为他在那个时期为维持公司的生命线起到了非常关键的作用。但很显然，还有大量工作要做。团队深入钻研，真正搞清楚了瓶颈在哪里，并在这个过程中深刻认识到，满足企业买家更广泛的治理需求有多么重要。

这意味着几件事。首先，需要构建大规模治理方面的基本功能——就是那些达到一定规模的公司所期望的东西：报表、完善的用户管理等等。其次，是时候超越那种深度优先的策略了。深度优先的策略对于走到那个阶段至关重要，但要迈出下一步就不够了。仔细想想，当公司规模达到一定程度时，你会开始看到技术栈的多样化，而所有这些技术栈都需要安全保障。事后来看，只支持使用其中一小部分技术栈的开发者，显然无法满足安全团队的需求，而安全团队才是最终对整个应用资产安全负责的人。在接下来的几个月里，团队努力工作，开始构建对更多语言和生态系统的支持，并添加那些基本功能。

回想起来，Snyk 当时只是走在了开发者优先安全这一不可逆转的趋势前面。那时唯一的买家是安全团队，开发者优先的安全在很大程度上还不是 CISO 和应用安全（AppSec）负责人在推动的方向。但如果你像我之前提到的那样，把 Snyk 视为一个变革推动者，视为客户 DevSecOps 转型旅程中的关键一环，你就会意识到，我们开始与那些安全负责人建立关系有多么重要。也是那个时候，引入第一批销售和工程方向的招聘也恰逢其时。

Lenny： 所以你们基本上发现纯自助行不通，离不开销售去说服高层，这很合理。如果负责安全的高层都不认可，你怎么能信任一家公司来保障你的安全呢？说得通。

Ben Williams： 现在情况已经不完全是这样了。有些组织的采购决策中心仍然主要在应用安全（AppSec）团队，但也有不少组织中，技术负责人在安全投资的采购决策中扮演重要角色。不过，无论采购中心在哪里，有一件事一直没变，那就是开发者的影响力。

Lenny： 我想象，随着品牌的成长，说服别人也变得更容易了——“看，这么多其他公司都在用，应该没问题。”

Ben Williams： 当然。

自助变现与销售的关系

Lenny： 想确认一下，根据你在 Snyk 的经验，自助变现从来没有真正奏效过。它作为一种进入公司的方式是有效的，开发者开始小规模使用，但你们需要销售和市场来真正推动变现。这是你的发现吗？

Ben Williams： 回顾那个阶段，是的。但现在情况很不同了。我们有很多纯自助的客户规模做得相当大。

Lenny： 了解，这很有意思。我很少听到这样的情况——一开始销售很重要，后来却变得不那么重要了——或者说我猜想销售仍然非常重要，但出现了一个可以纯自助的客群。很令人着迷。

Ben Williams： 是的，但我觉得有一点很重要，需要承认，产品在销售过程中一直扮演着非常关键的角色。

赢得开发者的心

Lenny： 这正好引出我想问的问题。你几次提到了他（指前文提到的 Ed），他有一个很棒的 Newsletter，经常谈到你们。我觉得他对 Snyk 的进展非常自豪。他经常说，做开发者产品，你必须赢得开发者的心，做出真正管用的东西。对于那些面向开发者的人，你有什么经验或建议，关于如何赢得开发者的心，让工程师和开发者对你正在构建的东西感到兴奋？

Ben Williams： 我觉得有两点。首先，从根本上说，要让一个人对使用一个产品感到兴奋，他得足够在意——他得有一个你在解决的问题。我认为有两件事。第一，有一个正在发生且仍在持续的转变。要让开发者真正把安全视为自己工作中不可或缺的一部分，就像他们对待功能质量或性能那样，我认为还有很长的路要走。我们在这方面正在取得扎实的进展，情况一直在变化，但仍有很长的路要走。但现实是，我认为在大多数公司里，开发者不得不关心安全，因为他们的公司需要安全保障。那么关键就在于，如何让这些开发者的安全工作尽可能无痛？

这意味着真正在他们所在的地方与他们会合，与他们的工具集成，想办法把安全带给他们，而不是试图把他们从工作流中拉出来。心流（flow）对开发者来说是一个极其重要的概念，你要努力让他们尽可能长时间地保持心流。GitHub 的 Pull Request 就是一个很好的例子。一个人注册 Snyk，理论上他可以是 Snyk 唯一的用户，连接自己的代码仓库。转眼之间，我们就开始保护、加固那些仓库——可能有一百、一千名开发者在 GitHub 中使用那些代码，全都从 Snyk 中受益，而无需注册。这就是把产品带到用户面前、而不是把他们从工作流中拉出来的典型案例。我认为这一点至关重要。

Lenny： 作为局外人听你讲这些，这是一个几乎不需你费什么力气就能帮你避免安全问题的产品，替你干了大量工作。站在现在回头看，很难想象它不成功。我很好奇，在早期到底是什么让人觉得这事可能行不通？是人们怀疑它是否足够智能来发现安全漏洞？还是时机不对，人们还没准备好、对安全的关注度不够？你认为早期遇到挑战的原因是什么？因为回头看，这就是一个理所当然会成功的产品。怎么可能不成功？听起来就是一个各方全赢的神奇产品。

Ben Williams：

早期挑战与突破

Ben Williams： 首先要说的是，挑战并不在开发者采用方面。即便最初几次自助服务的尝试在打入一些大客户时遇到了困难，开发者的采用和免费用户基数仍然在以非常好的速度增长。这种势头一直在不断积累，也正是这种势头，最终在随后的这些年里为销售驱动型业务提供了源源不断的动力。但确实是我之前提到的那些绊脚石需要被克服——当第一批销售和市场营销人员加入我们、我们开始与客户进行对话时，我们也在产品上做了一些调整以满足需求：增加了更多语言和生态系统的支持，打造了那些基础性的功能——然后一切就真正解锁了，从那以后就像火箭起飞一样。

Lenny： 明白了。听起来最大的挑战是变现。做这件事能不能赚钱？开发者喜欢它，疯狂地使用它，但人们是否愿意在组织内部大规模部署并为此付一大笔钱？

Ben Williams： 没错，是的。

增长团队的起源与演进

Lenny： 好，明白了。我想更深入地聊聊你的增长团队和产品团队，以及在产品驱动增长和销售的组织中，你是如何考虑组建这类团队的。第一个问题是，Snyk 的增长团队是怎么开始的？早期是什么样的，现在又是什么样的？

Ben Williams： 在各个地方有一些零散的尝试。我们有一个小型的增长营销职能团队，还有一些研发部门中对关键增长服务的负责团队——比如有一个团队负责新用户引导流程。但直到我加入，我们才真正将增长团队的概念正式化。在那之前，一切都是比较零散的。当我加入后，我们创建了现在所说的”开发者增长组”。在那之前，大家对增长团队应该是什么样的、它跟核心产品团队的工作方式可能有什么不同，理解上并不太强。而且我认为，整体上这比人们通常预期的要晚得多，规模也更大。通常你可能会用一两个人、三四个人的规模来启动增长团队，然后逐步扩展。但我们的起点比那大得多。不过与此同时，这种自下而上的”开发者优先”方法，在团队的思维和运作方式上已经深深烙入了公司的 DNA 中。是的，即使在增长组成立之前，我们就已经在快速增长了。我认为当时发生的一个重要变化，是从简单的免费增值模式转向了一个全面的、协调良好的产品驱动增长策略。更常见的做法是更早起步、以更小的规模开始，而不是像 Snyk 这样——但因为一个”完美风暴”式的组合，这在我们这里行得通：我们的产品从一开始就内置了自下而上的增长能力；我们的创始人对产品如何增长有深刻的理解；而且高层对扩展这一模式有着强烈的共识和支持。启动增长组时面临的问题，实际上更多是关于如何让飞轮转得更快，而不是如何让它从静止开始转动。

Lenny： 你们最初把团队的精力聚焦在哪个方向？飞轮的哪个部分？

增长团队的结构与聚焦

Ben Williams： 目前我们有专门的团队分别聚焦于获客、激活和变现，另外还有一个支撑团队负责我们的增长平台，包括所有的数据和实验基础设施。但整体宏观结构是随着时间不断调整的，目的是让我们能够专注于增长模型中最大的瓶颈。在最初阶段，我们只专注于获客和激活，有意推迟了对自助变现收入渠道相关投资，直到我们确信：第一，我们已经练就了足以支撑规模化增长的能力；第二，我们解决了用户旅程早期存在的一些更紧迫的问题。这一点很重要——我们要对自己有效连接开发者与 Snyk 价值的能力有充分的信心，这样引入并优化自助变现收入渠道才有意义。同时，我也非常想避免我在跨职能协作和增长方面见过的一个常见失败模式。

当我加入时，系统中存在着一种内在的张力，在研发团队和增长营销团队之间尤为明显。两个团队都有非常出色的人才，有大量很好的想法，但其中很多就是无法落地执行，这导致了大量摩擦和挫败感，根本原因是不同职能之间的激励不一致。在创建增长组时，我们通过确保每个增长团队都是真正的跨职能团队来解决这个问题——每个团队中的所有人都围绕共同的目标和 KPI 对齐。每个团队都配备了工程师、一名工程经理、一名产品经理、一名设计师、一名增长营销人员以及决策科学支持。这种增长团队的基本形态对大多数人来说应该不陌生，但过去几年我跟不少人交流过，出乎意料地了解到，在产品团队中纳入增长营销人员其实并不常见。我个人认为这里面错失了很多机会，而且我预计这会逐渐成为常态，而非例外。

决策科学：比数据科学更注重行动

Lenny： 好，我想聊聊这个，但在那之前，你说每个团队里还有一位决策科学人员。这是怎么回事？挺有意思的。

Ben Williams： 是的。我们从基础的 BI 数据分析师视角起步，但随着时间推移，我们希望对数据施加更深层次的分析，从而能够开始构建预测模型，帮助我们做出更好的决策，并最终驱动和赋能一些终端产品体验。于是我们建立了一个决策科学职能，这些人非常聪明。

Lenny： 这跟数据科学类似吗，还是一个独立的……好的。你们称他们为决策科学人员而不是数据科学人员，这真的很酷，因为这暗示着更强的可行动性。

Ben Williams： 是的，我也这么认为。

Lenny： 哇，很酷。我之前没听过这个说法。这让我想起 Annie Duke 以及她关于如何做出更好决策的那套理论，我很喜欢……这是其他公司也在做的，还是你们自己想出来的叫法？

Ben Williams： 我不确定。我不觉得我们在做的事情有多么革命性，也许只是名字上，我说不好。

Lenny： 对，名字很酷。我没听过别人这么用。它暗示着一种偏向行动的倾向，而不是”我们要用数据做一堆酷炫的东西”。有意思。好，那你说每个团队中还嵌入了一位增长营销人员，那能不能大致讲讲这些团队的整体构成？你刚才简单提过，那你觉得在团队中嵌入增长营销人员的价值是什么，你有什么心得？

Ben Williams：

Ben Williams： 组建平衡的团队非常重要，在多个维度上保持高度的多样性。聚焦到职能多样性上——这也就是你问到的在团队中嵌入增长营销人员的问题——这样做的一个重大好处是，你能获得更广泛的创意来源，同时拥有更大的执行工具箱。在增长团队中，这通常体现为能够更快地测试和学习，进行更多并行且方向一致的实验。也许我可以举一个最近的例子。在一个以获客为重心的团队中配备一位增长营销人员，使我们在网站上进行了轻量级的实验，创建了一个 SEO 优化页面。这个页面效果非常好，无论是从流量还是转化率来看都表现出色，而且创建它完全不需要工程资源。增长营销人员和团队一起讨论后，共同认为这件事值得尝试。

但增长营销人员能够独立执行这项工作，而工程师们则同时在处理其他事情。在此基础上，基于那个页面的成功，团队随后构建了一个功能性的辅助产品（sidecar product），让用户基本上无需注册就能试用 Snyk，只需将他们的代码放入让我们扫描，就能立即给出一些结果。我们在访客流量方面看到了非常好的成效，流量显著增加，注册率如预期略有下降，但整体新增用户数有了大幅提升，而且这些用户的意向度明显更高，这在后续更高的激活率中得到了验证。

Lenny： 太棒了。所以在增长体系下基本有四个团队：获客、激活、变现，以及一个实验平台团队。对吗？

Ben Williams： 对，没错。而且这个团队还负责将这些数据提供给组织内其他部门使用。产品驱动销售（product-led sales）对我们来说是一个非常重要的业务模式，因此我们需要将用户及其团队、所在公司在产品中的行为洞察和认知提取出来，以聪明的方式提供给外部的 GTM 团队，让他们能够聚焦于最重要的事情。这是该团队工作的重要组成部分。

产品驱动销售与变现

Lenny： 很有意思，你们简直是产品驱动销售的典范。这就是从 PLG 到 PLS 的新趋势，显而易见，销售在这个过程中扮演着重要角色。而变现几乎全部通过销售完成，这一点也很有意思。酷，这不是一个问题，只是自言自语的一个想法。

SEO 与内容团队

Lenny： 我还有一个想法——你谈到 SEO 是你们增长中非常重要的一部分。那么负责 SEO 和内容的是什么团队？我猜他们在获客团队中，可能有一位内容人员嵌入在那个团队里。

Ben Williams： 我们团队里有一位我见过的最聪明的 SEO 专家，她叫 Joanna。她是增长营销团队的，但与增长团队的合作非常紧密。她手下有几个人，当我们围绕 SEO 构建闭环时，会把她和她的团队纳入到具体项目中。拥有这样一位在 SEO 方面理解远超我的人非常重要，尤其是在紧跟 Google 不断调整算法这件事上。

Lenny： 那她本人会亲自撰写内容吗？不管是编辑性的内容还是程序化生成的页面，还是她会外包给别人——

Ben Williams： 不会，但她做得很好的一件事是，持续提供和更新关于内容应如何组织结构才能带来良好效果的指南。

Lenny： 所以最终写内容的就是工程师和 PM 们？哇，很酷。

Ben Williams： 对，完全正确。

建立增长团队的建议

Lenny： 对于正在搭建增长团队的人，无论是在类似领域还是面向 B2B、以产品驱动销售为导向的企业，你有什么建议？你觉得最重要的是要把哪些事情做好？

Ben Williams： 这是一个很大的话题。根据我看到过的成功经验和失败教训，我有很多想法。我可以大致把这些归纳为三个主要方面：第一是人员与流程，第二是策略，第三是数据。这三者互相关联，要真正做好增长，缺一不可。先说人员——这一点前面其实已经涉及了一些，即平衡的团队。你必须拥有这样的平衡团队，既有多样性来产生好的创意，又有执行力来把想法落地。这是第一件事。

但仍然在人员这个话题上，我有一个心智模型，就是人的潜力本质上是无上限的，但有很多情境因素会阻碍人们发挥他们的潜力。可能是思维方式上的问题，可能是组织层面的障碍，可能是与同事之间的关系或更广泛的团队动态问题，甚至可能是他们根本就不在合适的岗位上。

所以从根本上说，我认为管理者和领导者的职责就是帮助人们识别这些障碍，并与他们一起找到蓬勃发展和成长的方式。在增长组织中，这一点尤其重要，因为有些人天然地不太适合增长工作。这并不意味着他们不够优秀——他们只是不会在增长的情境下发挥出最好的水平。

所以当你组建增长团队时，通常会先从内部转岗开始。这时候，人的匹配度问题可能比外部招聘更容易被忽略——毕竟在招聘过程中，你通常会在面试时明确考察这些因素。我可以用开发者来举个例子。

在增长情境中茁壮成长的开发者

所以在增长情境中真正茁壮成长的开发者，是那些被快速行动、不断迭代以创造可衡量影响所驱动的人。他们不会对自己的工作产生执念。他们拥抱不完美，将其视为过程的一部分。他们会毫不犹豫地舍弃自己的代码，甚至自己的想法。他们充满好奇心，始终在寻找更贴近用户的方式。

优秀的增长工程师与深层技术挑战者

那些通常会成为优秀增长工程师的人，往往具备上述特质。而我也认识一些非常出色的工程师，他们最大的动力来自于攻克真正深层的技术挑战，他们享受过程本身不亚于享受结果。这些人在增长领域中往往会遇到困难。当然，现实从来不会这么简单。没有人真正处于这个光谱的两端。但有一个问题非常重要，需要努力回答：这个人能否在这个环境中发挥出最好的水平？我认为这是非常关键的一点。

技能、知识与团队赋能

同时，你还需要确保他们在技能和知识方面也具备充分的条件。他们需要具备合适的技能和知识，才能在你的增长流程中发挥最佳水平。理想状态是，每个增长团队成员都拥有共同的语言体系，对增长流程感到得心应手，能够熟练运用数据和实验平台，理解数据，并具备正确的技能和思维方式。

教育与团队提升

我认为教育在其中扮演着重要角色。我们非常推崇 Reforge，同时也开发了一系列内部项目来对齐和提升团队能力。我们学到的一个经验是——从简单开始，随着团队积累经验再逐步深入，这一点非常重要。比如在实验方面，一开始不要急着引入多变量测试或序贯抽样等替代评估方法。

当团队还在刚刚尝试、试探深浅的时候，贸然引入这些复杂概念反而容易导致大量错误。这是我想给的一个建议。

对齐：从执行到战略

但人们还需要保持良好的对齐。我在最近参加的另一档播客中谈过这个问题。我的意思是，他们的执行需要与不断演进的商业策略保持对齐。增长策略需要与公司的发展方向保持对齐，同时又反过来影响公司的发展方向。增长策略需要与产品策略建立连接，理想情况下，KPI 之间应该有重叠和对齐，这样增长团队和核心产品团队才能朝着同一个方向努力。团队的技能和经验也需要与策略对齐。如果当前重点是激活和获客，那么一个擅长方案与定价的专家在那个时间点可能就不是最合适的技能组合。

领导者还需要做好规划，确保随着增长团队的工作重点不可避免地随时间转移时，所需的技能随时可用。但说到底，我认为每个人都应该能够轻松回答一个问题：自己为什么在这里，自己正在做的事情为什么重要。

愿景与使命框架

我不知道是不是有点跑题了，但我有一个我喜欢的愿景和使命框架，它可以帮你得出很好的、简洁的关于理想未来状态以及你在其中所扮演角色的表述。如果可以的话，我可以简单谈谈这个。

Lenny： 好，来说说吧。这个听起来太好，不能错过。

Ben Williams： 好的。愿景是你希望在未来五到十年内为用户和客户实现的那种理想状态。如果你执行得不够有效、不够高效或不够快，你的竞争对手同样可以实现它。你总可以在愿景声明前面加上”在未来……”这样的前缀。

愿景应该与你的目标市场绑定——不能太宽，也不能太窄。关键的一点是，它不应该提及你的公司、你的产品，或任何与解决方案相关的内容。对这一切完全保持中立。

然后是使命，它是指你将不懈迭代的东西，让你逐步趋近愿景所描绘的理想状态。它应该回答你将如何实现愿景，描述你的基本方法是什么。换句话说，你将做什么以及怎么做。理想情况下，它应该把你的独特差异化优势编码进去。以 Snyk 整体为例，如果谈到优势，我们可能会提到我们无可比拟的安全智能和对应用上下文的理解。

这个框架的一个妙处在于，如果你觉得有用，你可以在每个层级上应用它——从公司层面一直到单个团队。这不意味着这个过程不困难，你需要投入大量时间，但它给了你一套框架、一组边界，帮助你最终得出精心打磨的、经得起时间检验的陈述。

Lenny： 有没有你可以分享的愿景和使命的例子，不管是 Snyk 的还是其他的？

Ben Williams： 有的，我给你一个 Snyk 增长组的例子。愿景是：每位开发者都能安全地释放他们的创造力。使命是：通过无摩擦的自助采用和扩展，将每位开发者及其组织与 Snyk 平台的价值连接起来。

Lenny： 很有意思，愿景远远超越了 Snyk 当前业务焦点。而且正如你所说，它是一层层向下传递的对吧？有公司的愿景和使命，然后是增长团队的愿景和使命。

Ben Williams： 是的。

Lenny： 太棒了。

Ben Williams： 没错。

更广泛的产品组织与增长团队的关系

Lenny： 我想换个话题，谈谈你的产品工作。我们已经聊了很多增长组织的事情。我很好奇更广泛的产品组织是什么样的。你有多少个团队？你是怎么组织架构的？是按产品划分、按用户划分、还是按成果划分？然后这些团队又是如何与增长团队协作的？

Ben Williams： 当然，我很乐意展开聊聊这些。我之前提到过建设增长团队的三个领域。我不知道你是否希望我把另外两个也讲完——因为我们之前只谈了……

Lenny： 哦对，好的，先把那条线讲完。

增长流程的核心要素

Ben Williams： 好的。人和流程是第一个领域，我们先快速讲讲流程。在流程方面，你至少需要一套被充分理解和文档化的增长流程、实践和工作节奏。增长团队在某些方面需要与做核心产品的研发团队采用不同的工作方式。如果忽视这一点，只是把增长责任交给一个现有团队而不与他们一起实施适当的工作方式，我认为这是一个常见的陷阱。

理想状态是，增长流程能够持续被优化和迭代，尝试建立更高的可预测性。但我发现在增长流程中最为重要的一件事，是建立快速学习的节奏，并提供将这些学习成果社会化的手段——在正确的时间、正确的地点将它们呈现出来，使其能在合适的情境中被利用。如果你思考实验的本质，它不是为了交付成果，而是为了生成组织可以有效利用的学习成果，从而最终交付成果。

不一定现在，不一定明天，但在未来某个时刻。但令人遗憾的是，如果没有好的流程，学习成果很容易就会束之高阁、无人问津。那你就要问了，意义何在？所以，当人和流程走上正轨时，你会开始看到大家热情地分享学习成果；你会看到各种想法以经过精心打磨的假设形式，基于数据和学到的经验，从每个人那里源源不断地涌现出来；你会看到各种不同角色的人主动承担起端到端的实验管理与执行责任，而不是把这件事推给产品经理或工程师和技术负责人。所以，这就是人和流程，而策略则是——

Lenny： 在我们讲最后一块之前，让我快速插入一个问题。

Ben Williams： 好的。

Lenny： 关于学习成果这个话题。我越来越多地听到对”学习成果作为产出”这个理念的反对声音。因为很多情况下……作为领导者，你不会说”太好了，我们学了好多东西，但什么都没做成”。你怎么看待这个张力？一方面我们确实想学习，但另一方面我们也想推动指标、增长业务，而学习的意义更多是帮助做出决策，而不仅仅是学习本身。你怎么看待这种平衡？

Ben Williams： 归根结底，你的目标是创造影响力，这一点无可回避。但学习成果是实现目标的手段。这就像有一句我很喜欢的话，大意是专注于用户通往价值的路径，而不是专注于变现。因为如果你专注于前者，后者自然水到渠成。这和学习成果与影响力的关系是一样的。如果你直接试图专注于影响力本身，可能会事倍功半。但如果你专注于逐步获取所需的学习成果，那就会为创造影响力铺平道路。

Lenny： 我猜你们的 OKR 和目标仍然是”把这个指标提升某个百分比”，但你把它视为输出，而输入是”让我们学一大堆什么东西有效、什么东西无效，然后用这些来指导我们在哪里加大投入”。

Ben Williams： 正是如此。

Lenny： 好。

Ben Williams： 你需要专注于这一点——当你构建一个策略性机会时，你确实在思考成果，但你不会直接跳到终态。你需要思考的是：我们能用什么最快的方式来验证这个假设？从中学到了什么，然后把这些带入下一轮、再下一轮实验中……你是在沿途一步步铺路。你大概知道目的地在哪，但具体怎么到达，你在开始时并不清楚。这就是学习成果带你走的那条路。

增长策略

Lenny： 好的。然后我们说到策略。

Ben Williams： 策略，对。策略是个很好的话题。在最基本的层面上，你需要能回答这些问题：你如何获客？你如何留存用户？你如何变现？我知道你之前和 Elena 更深入地聊过这个话题，但在此基础上你需要更多的细节，来指导增长团队去哪里寻找策略性机会，以及如何着手。我发现的最好方式来阐述一个增长策略——一个能够真正有效指导团队执行的增长策略——就是基于闭环的模型，Reforge 在这方面有非常好的文档化方法。

能够识别各种微观和宏观闭环，理解它们如何相互连接，能够用定性模型将它们文档化，以传达关于你们如何增长的共识理解。这非常强大。在此基础上再补充定量分析，就能帮助指导季度间的聚焦方向，确保你在投入方向上是经过深思熟虑的。这会成为一个很大的赋能因素。

在一个高绩效的增长团队中，你永远不会缺想法。所以知道在那片想法的汪洋中该聚焦哪里，是策略非常重要的角色。在早期阶段，你可能只有一两个核心闭环，但不可避免地，你需要随时间推移叠加和连接新的闭环。拥有一个框架来做这件事，拥有一个框架来定期在以下背景下重新审视：增长团队的学习成果、公司整体策略的变化、产品的演进、新功能的加入等等，以及市场的变化。这会让团队在创造及时影响力方面提升一个层次。

所以你在那里构建的模型，能让你随时知道增长中最大的瓶颈在哪里，并让你能够相应地平衡增长投入。这确实很精妙。我们有时会聚焦于广泛的瓶颈和机会，有时则会有更窄的聚焦。比如专注于推动激活和互动的改善，甚至更窄——比如通过空状态来实现这一点。

Lenny： 我想快速展开策略这一块。你如何将这个”增长模型、增长闭环”的理念操作化？你搞清楚了”这是我们增长的方式”，那你怎么在战术上将它连接到策略？是”这是我们的增长方式，这是我们本季度要聚焦的地方，优化闭环的这个环节”，还是有其他方式？基本上就是把它写下来。

Ben Williams： 很简单，首先是在增长方式上达成对齐——不同的闭环是什么、它们如何运作、不同团队的角色是什么、他们在推动这些闭环加速运转中扮演什么角色。我认为这是第一件事，建立这种共同的词汇和理解。

其次是理解这些闭环的运作方式——什么是制约它们的因素，它们的输入是什么？加速这些闭环运转的机会在哪里？多个闭环如何在宏观层面协同工作？

特别是利用数据来识别和理解增长模型中最大的瓶颈在哪里，并就此达成对齐，从而确定团队在未来一个季度或两个季度需要聚焦的方向。

而且这是不断变化的。正如我提到的，有很多东西需要反馈到那个模型中——增长闭环的表现、你们正在积累的学习成果等等。这意味着它在不断变化，你在不断重新评估，它在指导季度间的规划。

Lenny： 好的，为了让听众更具体地理解。你们的一个闭环就是与 GitHub 的集成——自动修复他们的代码并创建 PR。你可能会在某个时刻发现，从用户点击那个链接到真正成为用户，这个过程中的摩擦太大了，太多人流失了。所以针对这个环节，比如激活团队的一个策略可能是”我们要优化漏斗的这个部分”——从 GitHub 点击到注册成为用户，并让他们到达一个发现价值的点，对吧？

Ben Williams： 对，就是这类事情。或者更早的时候，比如拿同一个闭环的例子来说——这已经是很久以前的事了，所以我可以公开讲——我们从 GitHub 开始，之后想要扩展那个闭环的覆盖范围。我们已经看到了成功，看到了那个闭环的表现在增长，但我们认为有机会通过增加对 Bitbucket 的支持来扩展它。然后突然之间，我们用 Bitbucket 启动了同样的闭环，接着是 GitLab，以此类推。

Lenny： 太好了。好吧，光这一块我们就可以再聊一整小时，所以先继续，留给付费版第二季。

数据基础与增长团队

Ben Williams： 最后要说的就是数据。增长团队没有数据根本无法运转——即使在产品早期阶段，还没达到足够流量来在合理时间内跑正式测试的时候，你仍然需要信号来帮助你学习、指导决策，既包括定量的，当然也包括通过与用户对话获得的定性洞察。我在这方面的建议就是尽早投资——先投基础设施，再投工具链，等达到一定规模后再投入专人。这些都是搭建增长团队的核心基础，能让数据最终几乎支撑所有关键决策。

Snyk 的情况比较有趣——我们不存在数据不够的问题。事实上，数据极其丰富，甚至太多了。我们收集了绝对所有的数据。我很早就发现的问题是：我们缺乏足够的行为维度数据，而且在收集什么数据、如何收集这些数据上不够有目的性，这导致数据难以信赖，而这就变成了一个大问题。

所以我们投入了工具和流程来建设事件追踪方案（event tracking plans），现在我们会在 CI 流程中测试埋点代码是否符合 schema 规范。这样我们对数据就有了绝对的信心。所以，达到可信的行为数据这一步，绝对是关键所在。

尽早投资数据

我之所以说要尽早投资，是因为要记住，积累到足够从中学习的数据也是需要时间的——比如围绕留存做一些关键决策。另外你还需要足够的数据来跑回归分析，用来帮助定义激活指标或互动状态等等。所以越早开始收集越好。总而言之——人、流程、策略和数据，这四样东西你全部需要，才能搭建和运转一个有效的增长团队。

当所有这些都运转起来的时候，它就像火箭燃料一样驱动专注和创造力。但与此同时，放慢脚步去建立这些成熟度——尤其是在 Snyk 这样高速扩张的节奏下——几乎是不可能的。你仍然得在搭建这些东西的同时把活干完。你必须接受一路上会犯很多错误，必须百分之百对此坦然，并且要把这些错误当作学习机会，从中找到改进的空间。

增长组织的价值不止于 KPI

还有一点也很有用——说到 KPI 和团队的职责，这当然是增长团队必须要产生影响的方式，也是他们主要被问责的方式。但我认为同样值得思考的是增长组织的效能，不应仅仅看他们在实验、新产品体验以及核心增长 KPI 上带来的影响，还要看他们如何赋能和提升整个组织的其他部分。

举个例子，我们整个产品驱动销售的流程，背后靠的是一个不断演进的模型，描述我们对用户、团队、账户以及使用和采用模式与信号的理解，这些模型指导着我们的 GTM 团队聚焦在哪里、如何聚焦。增长团队的洞察往往远远超出增长本身的用途，但如果你不分享出去，别人不可能知道这东西对他有用。所以增长团队的学习成果——即使是来自错误或失败的——我们都会广泛而显眼地传播开来。

我们希望每一个研发团队都能在适当的地方利用实验来学习、创造业务影响。所以我们在这方面做的一件事，就是为行为分析和实验平台的采纳铺好一条平坦的道路，辅导各团队上手，让任何人都能尽可能轻松地开始享受平台带来的好处。我们还建设了关于数据驱动开发、关于实验的内部培训项目，以及帮助指标设计等的内部工具。

还有，构建核心平台服务时要考虑对增长以外的人也有用。比如我们构建了支持情境化引导（contextual onboarding）的服务，最初确实就是这个目的，但现在这些同样的服务可以在产品任何地方用来提供情境化体验。我知道这说得有点散，但希望里面有一两件有用的事情。

Lenny： 嗯，有两件事我想快速跟进一下，然后我们可以聊产品团队的部分。你说你们会传播学习成果和实验结果，这方面有什么技巧可以分享吗？你们用什么工具来做这件事？是有人在 Slack 里发东西？还是发一封邮件出去？你们到底怎么传播这些学习成果，让一个销售人员能够拿来用？

传播学习成果的机制

Ben Williams： 好的。首先，我们有一大堆 Slack 频道——Snyk 基本上就是靠 Slack 运转的，所以有非常多的 Slack 频道。即使在我们规划实验的阶段，这些频道也都是公开的，我们欢迎大家在上面协作。但从仪式感的角度来说，我们努力将产生和利用学习成果的方式制度化，这是我个人非常看重的一件事。所以我们有团队级别的”影响与学习回顾会”（impact and learnings reviews），大致是借鉴了好几年前——大概六年前——Brian Balfour 写的一篇博客文章，描述了他在 HubSpot 时期类似的仪式。

如果让我选增长团队中最重要的一个会议，那就是这个。各团队持续记录从数据探索、实验、用户研究等过程中获得的任何学习成果，记录在他们每周的影响与学习文档中。

有些团队发现两两结对、深入专门的研讨会议来深挖特定相关话题效果更好。但不管以什么形式产出，最终都会放进那份文档里。

到了会议本身，通常由 PM 主持。大部分时间用来讨论已记录的学习成果、它们的含义、如何在后续工作中加以利用、对其他团队可能有什么关联等等。相对较少的一部分时间会看关键指标。有些团队甚至把这部分完全拆分到了一个单独的会议中。而团队实际在做什么事——这个完全不花时间讨论。重点在于成果和学习。这是团队层面的。

然后我们在整个组的层面每月也跑一次同样的会议。由增长组的产品、工程或营销总监主持，所有增长团队汇聚在一起，分享一些关键的学习成果——当然不可能分享所有内容，他们挑选的是对其他团队有潜在相关性和实用性的成果。我们用户研究团队分享所谓的”开发者洞察”也是固定议程之一。这是我个人最喜欢的会议之一。每次都会录像，之后向全公司传播。是的，我觉得这真的很重要，而且我们还在不断地通过各种渠道把这些信息分发出去。

Lenny： 太酷了。这个会议是任何人都可以参加的——比如一个销售人员也可以来看产品团队最近从实验中学到了什么有趣的东西。多酷啊。你能不能分享一下你们整理的那份文档的模板？我们可以放在节目附注里。

Ben Williams： 当然可以。

Lenny： 好。

Lenny： 好。那么关于那个会议，你说基本上是由产品职能方面的人来主持，分享他们在最近的实验中所学到的经验，比如过去一个月内的。

Ben Williams： 通常团队层面的例会是由 PM 主导的，这更多是从 facilitation 的角度来说。而那些 learnings 是由团队中各个成员带来的，每个贡献了 learning 的人会向团队分享，并从那里展开讨论。到了 group 层面，则由增长组的各位总监来主持，每个团队可能由工程负责人、技术负责人、设计师或产品经理来代表，分享当月的关键 learnings。

Lenny： 明白了。PM 最擅长的就是主持会议，这很合理。好的，这是一个很好的过渡，我们可以聊聊产品组织架构。我很好奇你们的产品团队是怎么搭建的，以及它和增长团队之间是怎么协作的。

Ben Williams： 好。产品组织方面，你想了解什么？

Lenny： 大方向上，你们是怎么搭建的？有多少个团队？是按 outcome 来划分，还是按产品的 surface area 来划分？增长团队是和产品组织并列的，还是产品组织内部的一个单元，或者是深度整合在一起的？不过我觉得应该不是整合的方式。组织架构图大概是什么样的？

产品组织与增长团队的结构

Ben Williams： 我觉得我们在产品和更大的研发组织方面采用了相当常见的模式。组织的大部分是按职能归属来划分的，核心产品中有很多非常复杂的领域，所以拥有本地化的知识对于拥有和运营团队所发布的代码很重要。而增长团队则不同，是按 outcome 来构建的，我们已经讨论过这一点——负责获客、激活、互动、变现等领域。这些 outcome 和团队的职责范围会随着时间变化，我们也谈到过。但这里的关键区别在于，这些团队通常工作在他们并不拥有代码的产品领域上，我认为这是我们增长团队和产品团队在结构上的核心不同——当然也有一些例外。其中一个增长团队实际上拥有引导流程等部分，所以这确实需要很高的信任度。

这需要在我们工作方式中建立非常透明的沟通机制。我们定期召开的一个会议是实验方案评审。这些是临时性的会议，由实验负责人主持——可能是 PM，也可能是团队中其他人。但重要的是，会邀请很多人参加，尤其是其他团队的利益相关者——当我们可能要在他们的产品界面上做实验时，他们不会是第一次才知道这件事。我们会尽量让他们参与到实验方案的共同设计中，这样他们就能完全认同。把他们邀请到这些实验评审中非常关键。如果我们要在某个产品界面上运行实验，就需要确保实验方案中的一切都严丝合缝，尤其是排期方面，因为我们最不希望看到的是，实验跑到一周半的时候，产品团队对正在进行的实验毫不知情，在该界面上做了一些改动，从而完全使实验失效。

Lenny： 明白了。那么从组织架构上看，你下面是否有一位直接负责人专门管产品团队，另一位专门管增长团队？还是各位总监直接向你汇报？这个结构是怎样的？

Ben Williams： 我们的 CPO 在高管团队中，他负责整个产品组织。他下面有四位——我想应该说是四位 VP，分别负责不同领域。有几位 VP 负责产品的不同部分：首先是我们的应用安全产品，其次是云安全产品，第三个是平台，第四个是我们所说的开发者旅程，也就是我负责的领域，其中包含几个 group，增长组就是其中之一。

Lenny： 明白了。好的。在进入非常精彩的快问快答环节之前，我还想问几个非常具体的实操问题。第一个是，对于免费增值产品，始终存在一个问题：什么应该放在免费版，什么应该放在付费版？关于如何思考这个问题，你有什么经验可以分享？什么应该在免费版中，什么应该在付费墙后面？

免费与付费的边界

Ben Williams： 是不是 Elena 在你的节目上也谈过，那些能够促进你增长模型的东西适合放在免费版，而那些会增加摩擦的则应该放在付费版？我非常喜欢这个指导原则。我还想补充一点，对于很多企业来说，还需要考虑服务成本的因素。如果向免费用户提供某项功能因为使用量太大而成本过高，那显然你会想把它留给付费版。归根结底，这也是 Heroku 最近完全取消免费层的全部原因。我认为从免费版到最高版本，每个版本都应该对目标客户、使用场景有清晰的定义，并且要把从一个版本升级到下一个版本的驱动因素梳理清楚——你要非常明确是什么在驱动用户从一个版本迈向下一个版本。对于 Snyk 来说，从免费版升级到付费版的真正驱动力，是当你想要保护业务关键代码，并且开始有治理和合规方面的需求时。

我觉得另一个有趣的维度是如何看待试用。和大多数事情一样，我觉得我们在 Snyk 仍在摸索。我不知道这里是否曾经有过完美的答案，甚至是正确的答案，不同产品之间肯定不同。我们有自助试用来支持对我们的付费版功能的限时评估。但我们会定期、有意识地重新审视这个模式。我认为定期挑战自己很重要，确保不会掉进这样的陷阱：简单地假设过去最合适的方案现在和未来也最合适。如果试用时长不是以时间而是以某种使用量维度来限制呢？或者如果我们完全没有试用期，而是把更多功能放进免费版但加上合理的限制呢？做这些改变会如何影响我们的增长模型？

回答这些问题并不总是容易的，但我认为有一些方法可以帮助你进行测试。比如，你可以将试用期内参与度低且未转化的用户和团队作为一个群组，在试用结束后将他们回落到一个增强版的免费计划中，然后监测他们的参与度。所以确实有一些手段可以尝试，但我认为持续挑战自己、重新审视现有模式——包括各计划之间的具体边界、你如何支持用户评估以及计划之间的流转方式——这个习惯非常重要。

另外，谈到产品驱动增长和销售时，我们之前讨论了自助模式。显然，这对 Snyk 来说非常重要，但销售主导的模式同样至关重要，影响力也非常大。你需要在产品驱动增长和销售主导这两个维度上都考虑计划设计和相应的运作模式。当你拥有一个包含产品驱动销售的强大产品驱动增长基础时，从产品中产生大量高质量线索的角度来看，你会处于一个非常有利的地位。我们实际上追踪一个叫做”产品驱动收入”的指标，它基本上涵盖了我们观察到在销售接触之前产品中已有基于价值的实质性活动的所有客户收入。这个指标实际上能非常有趣地反映你公司在所有收入渠道（自助和销售主导）上的产品驱动增长效率。令人着迷的是，产品驱动群组在净留存方面的贡献相对更大。所以当你在思考定价打包时，确实需要认真思考和理解免费增值模式在宏观层面的贡献，并明确你要优化的目标——在当前收入与潜在未来收入之间取得平衡。

产品驱动客户的净留存优势

Lenny： 产品驱动线索带来的净收入留存增长，主要是因为他们起始价格更低吗？还是说他们最终确实成为了更好的客户？

Ben Williams： 这个问题问得很好。我不确定自己能给出一个很好的回答。

Lenny： 没关系。

Ben Williams： 我也还在研究这个问题。

Lenny： 这确实是一个很好的引导，促使人们思考如何让更多客户和用户数增长。你谈到过确定试用时长、试用中放什么内容、免费版放什么等的重要性。在迭代过程中有没有什么让你感到意外的东西？有没有什么特别的心得？

Ben Williams： 我不会说有什么让我惊讶的，但有一点我觉得回头看或许是显而易见的，那就是不同规模、不同复杂度、不同行业的公司——从高度受监管的行业到另一端的行业——它们需要不同的时间来妥善评估产品。所以以某种方式适应这些差异，无论是动态试用时长，还是基于使用量的试用时长之类的，我觉得非常重要。这绝对是需要思考的事情。

Lenny： 很好，这是一个很棒的经验。我知道 Elena 经常谈到试用往往让人吃亏，因为你没有给人们足够的时间在公司层面真正评估产品，所以这很合理。我想聊的最后一个战术问题是关于激活里程碑。我正在和 Yuri 一起做一项调研，应该会在这期节目播出前发布。不过现在我想先了解一下，你是如何设定一个新 Snyk 用户的激活里程碑的。也许可以简单分享一下你怎么看待什么是激活里程碑？为什么它很重要？然后你们如何为 Snyk 定义它？用户在你的产品中被认为已激活的里程碑是什么？

激活里程碑的定义

Ben Williams： 首先，什么是激活？对我们来说，激活意味着团队围绕 Snyk 的使用形成了习惯。而当我说使用时，我实际上指的是获得核心价值——最终来说就是修复漏洞。不只是登录，甚至不只是发现漏洞，而是修复漏洞。围绕这一点建立习惯。我之所以说团队而不是用户，是因为我们实际上大部分激活和参与度的定义都是基于团队的。这非常重要，因为归根结底安全是一项团队运动。这个团队可能是一个人，这种情况下用户就等同于团队，但通常一个团队有多个人，我们实际上期望不同的人在团队激活旅程中承担不同的角色。

我们还希望统计围绕修复的聚合层面的活动，这些活动有时发生在平台之外，我们无法在用户层面明确测量。所以在激活过程中，我们设定了设置时刻（setup moments）、顿悟时刻（aha moments）和习惯时刻（habit moments）。我们定义的作为团队被激活的习惯时刻，与团队创建后 30 天内修复漏洞相关。选择这个标准的原因是它与下游指标有显著相关性。在这种情况下，与激活后的三个月留存相关——同样，留存也不是仅仅回来登录，而是仍在修复漏洞。所以在前 30 天内修复了漏洞的团队，三个月后仍然在修复的可能性要大得多。

Lenny： 这很有意思，我很喜欢这个思路。你们是怎么得出这个数字的？是不是有决策科学家分析了某个拐点，发现大约 30 天时出现变化？现实中可能不是恰好 30 天，但这是一个足够接近的整数，对吧？

Ben Williams： 对，就是这样。确实有幸有一位决策科学家参与其中。我们首先需要收集大量基线数据。所以在构建好数据平台之后，我们实际上需要等待一段时间来积累一个好的数据集。我们做了大量的分位数分析，大量的数据探索，应用了机器学习模型，同时还配合了一系列用户电话调研。但我们首先从识别核心人物画像和用例开始——团队激活旅程中不同用户的不同角色，定义我们的留存指标——即仍在修复，判断一个团队是否仍在修复。同时结合自然使用行为和预期的自然使用频率。然后我们找到了与长期留存改善最强相关的习惯时刻。大多数数字层面的分析来自我们的机器学习运维平台。

但在那之后，我们反过来推算——那是习惯时刻，那是我们认为的激活，但团队要达到那里需要经历一系列步骤。那么之前的顿悟时刻是什么？设置时刻是什么？团队需要经历哪些具体步骤才能到达那个设置时刻？这就是整个流程。最终这是一个非常强大的模型，让我们能够输入一组用户层面的行为，我们知道这些行为可以影响通往激活路径上的不同步骤。

最有价值的 SaaS 工具

Lenny： 太棒了，我很期待这篇文章发布，这是一个非常好的案例，展示了公司如何得出激活里程碑以及如何设定它。我还想到了一个问题，也许以后我会问每个人。我知道我一直说要结束了，但还有一个问题——如果不合适我们就跳过。你提到了一些你们使用的工具，我很好奇，如果让你想想对你们组织来说最重要的五款 SaaS 产品是什么（排除 Salesforce 这种显而易见的），你会想到什么？

Ben Williams： 你说组织的时候，是指整个 Snyk 还是增长团队？

Lenny： 先从增长团队说起吧，看看能聊到哪。

增长团队的工具栈

Ben Williams： 首先我想到的是 Amplitude。然后是 Segment，它负责把产品中的数据传输到 Amplitude 以及其他需要数据的地方——不管是下游的 BI 系统、Snowflake 及其上层的 Looker，还是 Marketo 之类的营销自动化系统。所以 Amplitude 算一个。下一个我会说 FullStory，它做会话回放绝对是极好的。它很好地弥合了数据和使用者之间的鸿沟。再说 userinterviews.com，它和 usertesting.com 类似，两者都是获取快速、经过筛选的用户研究参与者的出色服务。还有一个是 Sprig。Sprig 是一个非常棒的应用内调查平台，这也是我们主要的使用场景，但它还能做不少其他酷炫的事情，比如在应用内测试 UX 设计。我说了几个了？

Lenny： 我算了一下，四个。如果还有想补充的可以加第五个。如果没有，我们也可以继续往下走。这份清单很有意思。

Ben Williams： 那就四个吧。

Lenny： 好的。在整个产品团队中，还有什么其他你觉得特别好用的工具吗？

Ben Williams： Airtable。实际上 Airtable 对增长和产品团队都适用，就是如此灵活，几乎什么都能做。事实上如果回到增长的话题，我应该最先提到它，因为我们绝大多数的实验方案、知识库和用户研究库都存放在那里。

Lenny： 好的，我喜欢这个问题，以后我打算每期都问。非常好。接下来是预告过的环节，一个令人兴奋的快问快答。我会快速抛出一连串问题，你想到什么就回答什么，我们尽量简短利落。第一个问题：你最常推荐给别人的两三本书是什么？

快问快答

Ben Williams： 我一直怕被问到这个，因为好书太多了。那我就选几本最近几个月读过的、很享受的书。对于像我这样的产品和增长 Geek，或者任何对数据有超过随便看看的兴趣的人，我推荐 Douglas Hubbard 的《How to Measure Anything》。第二本，之前你采访过 Marty Cagan，他提到了 Jake Knapp 和 John Zeratsky 合著的《Sprint》，我也很喜欢那本书，但就我个人而言，他们还有一本《Make Time》，这本书从根本上改变了我和信息之间的关系，我向所有时间紧张的从业者、产品人推荐它。第三本，我想推荐 Nicole Perlroth 的《This Is How They Tell Me the World Ends》，它为你呈现了数字间谍世界的精彩图景。

Lenny： 哦，那本书我读过。Tim Ferriss 曾经推荐过。那是一本非常疯狂的书，非常精彩。好的，我很喜欢这些推荐。很棒的选择。除了你正在录的这档播客之外，你最喜欢的播客是什么？

Ben Williams： 大概是 Ben Gilbert 和 David Rosenthal 主持的《Acquired》。我只希望自己有足够的时间把他们所有的节目都听完。

Lenny： 他们的节目确实很长。我最近参加了一个活动，他们在现场做了一期直播播客采访，非常酷。那两位真是专业。你最近最喜欢的电影或电视剧是什么？

Ben Williams： 电影的话，Disney Plus 上的《Turning Red》，我们和孩子一起看的，非常有趣。电视剧的话，最新一季的《Curb》一如既往让我笑到流泪。

Lenny： 他们有一阵子没出新季了。所以你说的那一季已经有点时间了。

Ben Williams： 新一季要来了。

Lenny： 哦，是吗？我不是很喜欢看那个节目。我妻子很爱看。那种尴尬感太让人煎熬了。但她还是会看。

Ben Williams： 我妻子其实也一样，她看不了，因为太让她尴尬了。

Lenny： 我们两家正好反过来。

Ben Williams： 我就喜欢那种尴尬。

Lenny： 天哪。一个产品领导者喜欢这种感觉还挺合适的。你最喜欢问候选人的面试问题是什么？

Ben Williams： 如果不算作弊的话，我想分享几个。第一个是我招聘任何人时都喜欢问的——想象三年后，你和现在有什么不同？很多人会下意识地告诉你他们期望达到的职位或头衔，但我真正想看到的是谦逊的信号，是他们对个人和职业成长领域的自我认知。那些能坦诚说出自己需要在哪些方面努力、把自己作为人来成长的人，我非常欣赏。另外，在整个面试过程中，我都在关注好奇心这个特质。日常工作中，优秀的 PM 应该像我六岁的儿子那样频繁地问”为什么”——那可是非常多。所以我会通过对话的过程来判断这一点。这不算一个具体的问题，但确实是我在寻找的东西。

还有一个，我想反过来分享一个，因为 Adam Fishman 之前提到过一个主题，就是你在面试一家公司时，也要评估将来可能共事的人的维度。这是我最近被一位候选人问到的问题，我觉得实在太精彩了——“请告诉我，你最近个人亲自参与过哪些关于多元、公平、包容和归属感的倡议？“这对他们来说是一个非常好的方式，来测试自己的个人价值观是否与未来密切合作的同事的价值观相契合。我非常喜欢这个问题。

Lenny： 太棒了。顺便说一句，我很喜欢你多次引用了之前其他期节目的内容。你绝对是这个播客的深度用户，我真的非常感谢。

Ben Williams： 哈哈，好吧。

Lenny： 最后一个问题。在行业中，你最尊敬的思想领袖或领导者是谁？

Ben Williams： 这个问题我也稍微变通一下。你说的”行业”，我理解是安全行业，但我想从产品领域来回答，具体来说是产品运营（product operations）。在我看来，这个领域没人比 Christine Ittner 懂得更多。如果你有机会和她聊聊，我相信那会是一场非常有趣的对话，一定会分享出很多真知灼见。

Lenny： 哇，我一定要请她上这个播客。这是我的新目标了。我之前没听说过她，太棒了。谢谢你的推荐。Ben，这次对话太棒了，有太多干货、故事和洞见。非常感谢你来。最后两个问题：如果大家想联系你、了解更多，或者想加入 Snyk 工作，在哪里可以找到你？以及，听众怎样能帮到你？

Ben Williams： 首先，非常感谢邀请我上节目，Lenny。我很喜欢聊这些话题，也很感激你愿意让我畅所欲言。至于找到我，我在 Twitter 上不太活跃，LinkedIn 上花的时间更多一些，不过这两个平台你都可以通过 @SemanticBen 找到我。至于大家如何帮到我，我开始以顾问身份接一些新客户，所以如果你觉得我能帮上忙，欢迎联系。

Lenny： 在你走之前，我不能不问一下 Semantic Ben 这个名字的来历。

Ben Williams： 当然。其实那是在 IBM 工作的时候，我当时专注于 linked data 方向。

Lenny： 于是就成了 Semantic Ben。好的，太棒了。Ben，非常感谢你来，感谢大家收听。

Ben Williams： 谢谢，Lenny。保重。

Lenny： 非常感谢大家的收听。如果你觉得这期节目有价值，可以在 Apple Podcast、Spotify 或你喜欢的播客应用上订阅本节目。也请考虑给我们评分或留下评论，这真的能帮助更多听众发现这个播客。你可以在 lennyspodcast.com 找到往期所有节目或了解更多关于本节目的信息。下期再见。

术语表

原文中文
acquisition获客
acquisition loop获客闭环
activation激活
BitbucketBitbucket
Brian BalfourBrian Balfour（增长领域专家，Reforge 联合创始人）
community-led growth社区驱动增长
company generated, company distributed公司生成、公司分发
content loops内容闭环
contextual onboarding情境化引导
decision science决策科学
developer growth group开发者增长组
developer insights开发者洞察
DevSecOpsDevSecOps
empty states空状态
engagement loop互动闭环
event tracking plans事件追踪方案
freemium免费增值
GitLabGitLab
growth group增长组
growth loops增长闭环
growth platform增长平台
GTMGTM（Go-To-Market，推向市场）
impact and learnings reviews影响与学习回顾会
invite loops邀请闭环
juggernaut巨兽（指势不可挡的力量）
linked datalinked data（关联数据）
Node Package Manager (NPM)Node 包管理器
OKROKR
package health score包健康评分
product operations产品运营
product-led acquisition产品驱动获客
product-led growth产品驱动增长
product-led sales产品驱动销售
product-market fit产品市场匹配
programmatic SEO程序化 SEO
referral loops推荐闭环
ReforgeReforge（增长领域的专业培训社区/框架）
schemaschema（数据模式）
self-serve monetization自助变现
session replays会话回放
side car product辅助产品
solutions engineer解决方案工程师
VP of Product产品副总裁

此文档由 AI 分片翻译（translate_long_document）