增长黑客专家 Andrew Chen：50 页 PPT，手把手教你打造增长团队

编者按：“增长黑客”是互联网创业者Sean Ellis发明的一个术语，指的是一个介于技术和市场之间的新型团队角色，主要依靠技术和数据的力量来达成各种营销目标，而非传统意义上靠砸钱来获取用户的市场推广角色。不过这个词的流行是Andrew Chen的功劳——曾在Uber当过增长副总裁的他写了一系列文章来介绍增长黑客。不过相对于增长黑客的单打独斗，增长团队则是集体协作。那么什么是增长团队？为什么要建立增长团队？增长团队与增长黑客的区别在哪里？增长团队的关注点应该是什么？就这些问题，Andrew Chen用50张片子的幻灯片来释疑。

建设一支新的增长团队很难。你得找出宏观的组织性问题——如何适应营销、产品等职能——以及微观方面的，如怎么去衡量这些团队的成功。这是一个棘手的主题，也是目前很多团队正在思考的东西。

几个月前，我给Uber的增长团队上了一些课，就自己从不同的组织结构中学到的东西谈了谈，内容可以分为这5大类别：

1. 为什么要建立一支增长团队？

2. “增长黑客”与增长团队的区别在哪里？

3. 增长与营销/产品/其他的区别在哪里？

4. 增长团队的焦点应该放在哪里？

5. 我正在创立或者加入一支增长团队！我应该有哪些期望？

为了回答这些问题，我和Brian Balfour基于Reforge的材料（这方面的话题可以到他们的网站去了解更多的实用参考材料）做了一份演示片。

以下就是演示片，希望能对你们有所帮助。

上图：今天我想讲几个建设公司的增长团队所需要的关键主题。首先，是为什么需要建设这么一支队伍。然后是个人从业者与组织所需的不同技能集——以及跟现有的像产品和营销等职能所需技能集的不同。最后，是团队应该聚焦什么地方以及如何在早期产生影响。

这些主题的想法源自若干地方——跟Slack、Dropbox、Hubspot、Pinterest等的增长团队负责人的交流和讨论，但也包括了我在Uber的个人体会。

上图：你们当中很多人也许还记得Uber曾经是这样的。

这支增长团队起初是由Ed Baker在2013年创立的。它曾试验过很多不同的组织配置——我在它成立了几年后加入，在那里呆了3年，并且把自己的很多时间用在推动平台乘客端的增长上面。

上图：我在Uber的时候，有很多出色的项目都是在增长团队发起的。我的中国同事（China Growth）取得了不可思议的进展——当然美国和其他地方也有不错的发展。

巅峰的时候包括中国增长团队在内的整个增长团队规模达到了500人以上。对于这家公司来说这是一个令人吃惊充满活力的时段。我从中获益良多并且对今天能够分享其中的一些想法感到兴奋。

这些年来Uber的变化很大。我们变更过logo好几次。但我认为Uber仍然有好些东西可以传递给生态体系的其他人。

先从基础讲起……

关键问题#1：为什么要建立增长团队？

上图：为什么要建立增长团队？我们知道很多公司都有正式的增长团队，有的则是由增长PM/营销人员等组成的非正式团队。

上图：上图是建立了增长团队的公司，从这些公司的行业跨度和新鲜性就可以看出增长团队的普及度。

我们也听说了很多董事会都在让他们的CEO要往增长团队的建设去投入。为什么会出现这种情况？

产品死亡周期

上图：讨论产品死亡周期的最简单方式。

不幸的是，这往往就是我们的产品交付和发布方式。有人有愿景，有人开发了一些功能并且进行了发布。一开始产品可能有点冲劲，但是当增长放缓时，却不知道该作何着手。他们跟一些客户交谈，问对方想要什么，然后再次尝试。他们又增加了一些功能，重新发布，于是这个周期周而复始。

这个周期跑得太多之后，突然之间，你就死了。

酒好还怕巷子深

上图：事实表明，做了未必就能吸引客户。更好的产品，更多的功能未必相当于增长。

很多推动更多用户获取、留存、互动的关键杠杆有时候并不在大多数出色的产品领导的工具包里。对增长很关键但往往不被视为产品核心的技能可以列一长串：广告技术集成，注册渠道A/B测试，优化通告发送，测试价格点，测试聚类曲线等。是，偶尔有人都懂这些——但是很罕见！

此外，没人可以驱动这个。相反，你需要将其注入到你的组织目标和DNA里面。你需要在公司的更大框架内集中这些努力。

增长是工具，工具是解决不同类型问题的流程

上图：因此，我们寻求建立一个增长的框架，这是一个门类，本身就是一个组织结构。

不同的流程

我们把“设计思维”与“敏捷工程”视为不同的组织结构、工作流、哲学与技能集体系。这些是公司内部工作机制的关键。

同样地，我们也可以把增长团队当做一个体系来建设。

上图：产品增长是一门把科学方法应用到业务KPI上面的学科。

这为提高指标提供了一个基础系统，不管这些指标是收入、获取、留存、互动还是其他的关键业务指标。

增长流程的主要步骤

上图：就像你对科学方法的预期一样，增长流程的主要步骤包括理解数据、建立识别特定流程之所以会出现的假设，对那些想法进行优先排序，进行试验，然后重复这个循环。

这样一来，如果你认为自己的活跃用户数低的话，就可以分析数据，然后了解到你需要更多漏斗顶端的用户获取，接着假设付费广告和推荐的组合也许管用，再去执行计划来验证想法。

相对于开发更多用户不想要的功能然后指望会出现魔术般的增长，这种做法要好得多，有针对性得多。（也许你还是应该开发那些功能，但原因不要是为了增长！）

关键问题#2：增长黑客与增长团队之别

上图：第二个主题。谈谈“增长黑客”与“增长团队”之间的区别。这一点很重要。

孤胆英雄注定失败

上图：在增长技能集的早期阶段是没有团队的。会有一些个人和初创企业创始人把必要的想法、工作流和策略组合到一起。其中一些家伙会以玩笑的口吻自称为“增长黑客”。

随着技能集的发展，有一件事情开始变得明朗，那就是如果想发挥真正影响，尤其是在更大/更复杂产品的背景下发挥影响，你得把一群人组织起来。

增长是一项团队运动

上图：因此增长团队就应运而生，其哲学是你想要的不是有所有手段的孤胆英雄以及一群帮助者。相反，你需要建立一个有着广泛技能集的组织。

增长是一项团队运动，为了对你的KPI实施科学方法，你需要一堆能帮助你的人。

大多数使命需要跨职能配合

上图：对于增长团队的大部分使命来说，你需要很多不同的职能角色的帮忙——从产品、营销、工程，到数据、运营、财务等。你要把来自独立团队的所有这些家伙整合起来成为一个增长组织。

增长团队的5种潜在角色

上图：这些角色都是干什么的？

• 增长经理（Growth PM）：负责试验路线图的产品经理

• 增长工程师（Growth engineer）：聚焦技术决策和执行试验的工程师

• 增长营销师（Growth marketer）：具备特定渠道（付费营销、SEO、电子邮件等）专业知识的全能营销人员。

• 增长数据分析师（Growth da）：聚焦于建立洞察（用户生命周期的宏观方面以及特定试验的微观方面）的分析师

• 增长设计师（Growth designer）：领导UX的设计师，同时强调速度

你可能还得涉及到其他的职能——比方说在Uber，很多围绕着激励开支的决定必须把财务或者定价方面的人员纳入。而且你总是得把运营放进来去考虑其影响。

例子：增长团队——NUX（新用户体验）

上图：视你要解决的问题而异，增长团队的构成可能会略有不同。对于新用户体验来说——这可能包括了增加注册转化，甚至可能还包括集成进广告里面——你也许会特别强调工程师。你可能想要Android和iOS工程师。此外甚至还包括营销绩效的人，一些数据分析师去看看指标等。

例子：增长团队——SEO（搜索引擎优化）

上图：另一方面，如果你在做SEO的话，就未必需要工程师了。这更多是与优化网页结构、内容去向等有关。这种情况下，你可能会强调SEO营销、数据以及web全栈工程师。

没有完美的组织结构

最终的目标是要根据你的洞察和假设定义问题，并且配置好团队成员来解决特定问题。不同的团队也许强调不同的技能，视其他团队的使命不同，增长团队所适应的宏观组织结构也许也许有一些复杂性。

跨职能团队结构

上图：一个常见的结构是把增长团队当作一组pod，每一个都对应各自职能。比如增长经理向产品等汇报，所有的人组成增长团队。很多产品团队都是这个样子，所以相对比较适合。

独立团队结构

另外一种做法是像Facebook和早期的Uber增长团队，其结构类似一个业务部门。那些角色得向总经理汇报。这种结构的好处是团队内部有很大的独立性，但是拆分各种组织也会带来复杂性，有时候还会引起冲突。

混合结构

上图：显然你也可以选择混合模型。

关于增长团队3个要回答的关键问题

上图：太多初创企业都是从“我需要一个增长团队!”开始，然后随便建立一个组织而没从根本上去思考过。最终，你得从你要解决的问题开始。从KPI、你产生的洞察开始，然后再去执行。你要按照问题领域和想要的执行类型配置人员。组织结构要根据这些来设计。

关键问题3：增长跟营销/产品/魔法/等等有什么不同？

上图：我经常会被问到这个问题。难道增长和营销不是一回事儿吗？难道增长跟产品不是一回事儿吗？难道让大家都负责增长不行吗？

在这个环节里，我们将审视一下它们的不同。

增长与营销

首先，说到营销与增长，其中有很多方面是你想要解决的：

• 品牌营销

• 活动

• 内容营销

• 电子邮件

• 付费营销

• 病毒式传播/推荐功能

• 新的用户体验

• 用户对用户通知

• ......

所有这些你可以采用一堆不同的配置，但大概而言通常归为3类职能：

• 品牌

• 增长营销

• 增长产品

通常很显然的是，品牌最后还是要归结到营销。类似地，像NUX和产品生成通知最终都要落到增长团队身上。但一些中间手段，像SEO/付费营销/电子邮件等，也都有可能出现。这些我都见过。Facebook把很多效果营销放到增长团队里面。Uber就是这样开始的，但最终都放到了营销上。可能的配置有很多。

增长与产品

上图：如果核心产品团队有工程师、设计师和PM，那增长团队也有这些角色，有什么区别呢？一切都要取决于他们做什么。产品团队聚焦于创造核心价值。随着时间转移去增强产品/市场匹配。这意味着在核心的互动周期中要把心思放在每一次小小的交互上面——这是一个寸距之赛，积小胜为大胜。

另一方面，增长团队应该专注于传播核心价值——要让尽可能多的家伙体验到那种价值。

在让用户尽可能频繁体验到核心价值上面可以进行妥协——你可以想象把这件事情放到另外一个团队，但如果解决方案往往需要经常反复/量化驱动的话，也许就应该由增长团队去做。

3种所有权模型

上图：你还得决定所有权模式。有两个极端：增长即服务（GaaS）以及自动化。以及介乎其间的一切。

“增长即服务”这种模式下，团队在技术上并不拥有任何功能或者代码库。他们跳到了产品的最高价值部分，进行他们的分析和优化，交付一堆的改进，然后继续。团队要保持温柔，这一点很重要，因为他们是客人，但他们保持轻量也很重要。如果增长团队最终拥有他们碰到的每一块代码的话，那他们最终就会陷入到一切的维护模式当中。

另一方面，完全的所有权模式意味着增长团队可以拥有新的用户漏斗、通知、广告技术、A/B测试平台、支付流，以及许多其他数字胜过直觉的关键领域。这样可以管用，但然后团队需要恰当地配置人员。

不同模型的优缺点：GaaS——优点是敏捷，缺点是容易冲突；自治——优点是可控，缺点是会臃肿；混合——优点理论上是各取所长，缺点很难划清团队之间的界限。

上图：每一种模式都会有各自的优缺点。Uber各自模式都试过，不过慢慢地开始拥有产品越来越多的部分。但是你得根据自己的约束、组织和产品需求决定选择哪一种。

关键问题#4：增长团队的关注点应该是什么

一旦增长团队建立起来之后，其关注点应该放在什么地方？就像之前讨论过那样，他们的使命和工具包应该跟营销或者产品团队使用的那些有所不同。尤其是在团队的早期阶段，应该有一些唾手可得的东西选用。

尽管直接跳到用户获取或者看看流失情况很容易，但是从更高的角度去看看这个体系还是很有帮助的。先从优先级框架开始。

确定优先项目的框架

上图：最终有3样关键的东西需要进行权衡——有一个尤其棘手：

• 投入。执行需要付出多少的设计/工程/营销资源？

• 成功。取得成功的可能性有多大？

• 提升。这个比较棘手——如果管用的话，对整体增长会产生多大的影响？

每一次增长试验最终都是根据这三样东西的排名选择出来的优先事项，慢慢地，你的增长团队在如何选择方面就会变得很明智。但我还想就增长团队可能会出问题的地方提供一些注意事项。

选择增长项目最常见的反模式是把影响到0.01%用户的功能改进+50%视为可喜可贺，却觉得一项影响50%活跃用户的功能改进只有5%很小。当然你只要算一下就知道后者要重要得多，因为你最终希望那些自下而上的试验要实现自上而下的KPI。

另一个常见的反模式是把焦点放在大规模的、好处巨大的项目而不是不需要太多努力、但好处不大或适度的项目。几乎每个人都会过高估计自己的成功机会，所以最好是多进行试验而不是孤注一掷……除非你已经穷尽了好做的想法，或者你已经有了足够的资源来建立大小项目的池子。

关于每一种因素的一些注意事项：

• 一般而言，投入是最容易理解的。如果你定义好了项目，你的团队就能够像其他任何东西一样针对它来执行。我一般建议增长团队早期要向低投入的项目倾斜。

• 成功可能会引起争议，因为对增长有效的东西未必是用户自己会报告的东西——因此，团队成员通常会说，“我永远也不想要这个。我永远也不做这个。”是的，你执行了最佳实践并且管用。典型的例子是渴望给登录页增加全面内容，那些东西会链接到无数新地方。但是一个很好理解的设计模式是只需提供必要的信息完成登录即可——不要画蛇添足。

• 提升在这三个因素当中是最难理解的。但同时也是最强大的手段，因为它为增长团队应该关注产品的什么地方提供了有力的指南。

那么我们就进一步看看这个因素。

提升=覆盖 x 影响

上图：提升最终都是靠绝对量来衡量的——获得了多少额外的订户，产生的注册数等。可以用两个组件来计算——接触和影响。接触是指有多少最终用户接触到了某功能的变化。影响是指作为变化的结果指标改进了多少。

这两个因素里面，影响的随机性往往最强。有时候一个改变可以推动改进+5%，有时候可以改进+50%。基本上绝大部分项目的结果都在这两个数之间。对于某些项目来说，如果产品体验可以发生多次的话，影响会非常巨大——比方说，一个新的高度相关的统治在产品的核心互动循环里面发出。或者某个显著放大病毒式循环的东西，导致飞轮转得越来越快。（但这已经超出常规了——不过这也告诉你有这种途径去创造巨大影响）

另外接触则是一个经常被误解的出色手段。这往往是理解那种最好项目的最有效点。

上图：基本上，大多数产品团队都聚焦在让他们的核心产品体验更好上，这对他们的核心用户是有好处的。这有很多好处——毕竟，他们是参与度最高的一群人，从货币化的角度来说是最有价值的，在多边平台里，是他们产生的照片/内容/销售等维持了整个生态体系的其他部分。

另一方面，核心用户往往只占你的总活跃用户的一小部分。

上图：视你如何定义核心用户而言，这个群体往往只占到活跃用户群的5-25%。如果光看能产生内容而不仅仅是消费的那部分用户群的话，这部分人通常只占很小的比例。或者创作大量内容的那部分硬核用户，相对被动消费者而言总是很小的比例。

因此，如果你有定向瞄准你的活跃用户而不是核心用户的项目的话，那你的到达量会多4到20倍！

但这还不是全部，还有更多的同心圆。

上图：平均而言，在任何一个月的时间里你的注册用户里面可能只有10-50%是活跃的。50%已经是世界级的表现——就像Facebook及其家族。通常大多数产品都在10-20%附近，因为绝大部分产品都有大量的昙花一现式的奇迹：那些试过产品一次，然后就永远不再回来的人。

这种层面的项目应该聚焦在激活上。如果你知道是什么让用户变得活跃的话，那就可以在用户引导流程中把那个东西引入进来，从而将他们转化为活跃或者核心用户。

对有着大量已有受众的产品来说，另一组活动就是从不活跃/流失的状态转移到回归使用产品的状态。他们有没有收到相关邮件让他们重新激活呢？如果他们忘了密码，你有没有像对待注册一样重视优化相关流程呢？

独立访客

上图：当然，对于很多产品来说（更多是web相关的），有些人是光看产品但从未注册的。大多数登录页可能只有10-50%的转化率（注册）！此外，很多产品都有“侧门”——像Dropbox的共享文件链接，或者YouTube的视频页面——是这些产生了绝大部分的流量。那些地方就成为优化的关键地方。

上图：当然，除了所有跟你的产品互动过（即便在登出的状态）的所有人之外，还有一个更大的群体范围——也就是你的主要获取渠道范围内的每个从未听说过你的人（无论是在Facebook还是Google或者其他）。这才是真正的漏斗获取的顶部。

当然，还有各种你还没有试验过的渠道。所以这就是为什么增加新渠道（比如在还没有的时候尝试一下推荐系统）会成为一大推进器的原因。

跳出当前用户群去思考到达规模

上图：说了这么多其实是想说如果你要找提升增长空间的最大手段的话，这个东西可能就在于到达（Reach）。当你发现你的增长团队的项目跟核心产品团队发生冲突时，不妨考虑上述同心圆——一步步地切入到更大的用户范围，无论是面向新用户、流失用户，以及所有尚未认同你产品的边缘人等。

另一个极好的练习是看看现有的功能和路线图，把一切接触非用户（或者不活跃用户）环节圈出来。你会惊讶地发现它们一般都是很新的。

上图是Airbnb的增长团队的分享，他们做的就是这种练习——在所有33个环节里面只有6个是针对非用户的。增长团队可以迅速扩展这个列表，给处在边缘的受众一些爱。

关键问题#5：对增长团队的预期

上图：最后一个话题。假设说你作为个人正在思考加入（或者成立）公司的增长团队。你应该作何预期？又应该怎么去评估这个机会呢？

上图：建立一支成功的增长团队涉及到很多组织和文化方面的东西。首先，要有领导DNA——是否理解了增长团队是干什么的？尤其是在产品和营销的同行那里。或者这个东西是不是由CEO或者董事会硬推而没有获得领导层认同的？如果大家根本不理解增长团队的使命的话，事情就会很痛苦。

公司文化也是一个重要方面。如果文化像鼓励试验的Uber 1.0那样的话，只要每次试验的范围在1、2座城市之内，或者影响面只有1%的话，那就很好。“快速行动打破陈规”。另一方面，如果公司设计极端并且具有品牌意识额话，做起来就会更加困难。苹果和Snap就以很少进行A/B测试著称，这种情况直到最近才有所改变。在评估一家公司的试验时，比方说了解他们对主页大的变化的接受程度就是很好的。或者对新用户流的改变。

就像之前讨论过一样，所有权模式可以是两个极端：SWAT团队模式，很少/没有代码所有权，或者很强的所有权领域，像NUX/通知/广告技术等。这两种都能用，只是要确保知道你要做的是什么，以及相应的人员配置与之匹配。

在我看来，最好的情况是要有这么一支团队：

• 认同要有一支增长团队，并且知道它如何补充现有职能

• 支持试验，即便是极端的试验，只要试验是在小范围内进行

• 专门人员已经安置就位，对于活跃用户群以外的一切偏向于强所有权。

当然，最糟糕的版本是大家其实不明白为什么要成立增长团队，对快速试验存在大量风险规避，并且不配置员工……就只是到处跑期望说服其他团队实现你的惊艳想法。这是失败的配方。

实施过程可能会碰到的问题

上图：在实现增长团队上有一些常见的异议。有时候公司的激励手段是为了奖励大型复杂的项目（有代号、有高管跟进的那种）而不是很多轻量的改变。这种做法融入到了项目的评审方式，绩效考核等一切。

类似地，在创立增长团队之前，几乎肯定会有家伙会留意产品的增长部分。因为把那些责任移走，或者开始侵蚀跟核心产品团队有重叠的“互动”部分，导致出现抗体，令增长项目进展变得缓慢许多。

确保大家达成共识

上图：组织的基础必须是已经准备好接受一支增长团队，而这个则要从对环境已经发生改变有了根本理解开始：

• 增长技术产品已经改变，指导手册在过去10年也已经有变化了

• 为了实现增长，必须配置专门的人员以及有明确的路线图——“开发好他们就会来”不管用了

• 建立增长试验的管道需要不同的流程。这种科学方法同样应用到KPI上。这不仅仅是营销和产品项目的子集

• 最后，要想使增长取得成功的团队结构和技能是不一样的

你能想象的是，形成这种互相理解的基础本身就需要很大的努力。你还需要取得所在初创企业CEO或者部门经理以及更高层的帮助。以及你所有的同事。

上图：这些是克服不可避免的组织摩擦的一些策略。其中包括1）理解文化根源2）CEO/创始人认同并授权3）教育，教育，不断地教育4）着眼全局，小处做起5）分出轻重缓急，积小胜为大胜6）用数据总结得失

感谢观看！

原文链接：https://andrewchen.co/how-to-build-a-growth-team/

编译组出品。郝鹏程编辑。