上图：今天，我将介绍几个关键主题，帮助你在为公司组建增长团队时理清思路。首先，为什么你可能会想先创建这样一个团队。然后，个人从业者与整个组织在技能组合上的差异，以及它们与产品和市场营销等现有职能的区别。最后，团队应重点关注哪些方面，以及如何在早期阶段产生影响。
这些主题中的想法来自多个方面——包括与 Slack、Dropbox、HubSpot、Pinterest 等公司的增长团队负责人进行的访谈和讨论，也包括我在 Uber 的个人经历。
上图：你们中的很多人可能还记得 Uber 曾经是这个样子。它一路向右上方增长。
增长团队最初创建于 2013 年，由 Ed Baker 创立。它尝试过许多不同的组织架构——我是在它创建几年后加入的，并在那里待了大约 3 年；我大部分时间都在负责推动平台上乘客端的增长。
上图：在我任职 Uber 期间，许多令人惊叹的项目都是由增长团队推动的。我的中国增长团队同事们取得了令人难以置信的进展——特别感谢 Ben Chiang、Han Qin、Michelle Chen、Jia Zou、Vinay Ramani 以及其他许多人——此外，美国及世界其他地区也都取得了大量进展。
Uber 这些年来发生了很大变化。我们当然也多次更换了 logo。但我认为，有一些非常关键的东西是我们可以传递给生态系统中的其他人的。
让我们从基础开始……
上图：首先，为什么要从一开始就组建增长团队？我们知道，很多公司都有正式的增长团队，也有一些公司虽然没有正式团队，但会有增长类的 PM、市场人员等在各自忙碌。
上图：当你只看行业内公司的横截面时，会发现许多最新、最优秀的 B2B 和消费类公司都已经组建了增长团队。
我们也听说过，许多董事会会要求 CEO 投资增长团队。为什么这件事最初会出现呢？
上图：谈论“产品死亡循环”最简单的方式。
不幸的是，产品往往就是这样被推出并发布的。先有一个有愿景的人，做出一些功能，然后上线发布。他们也许会在一开始获得一波增长，但当增长趋于平缓时，就不清楚下一步该往哪里走了。他们去和一些客户交流，询问他们想要什么，然后再试一次。他们再增加几个功能，重新发布，于是这个循环就这样继续下去。
这样做太多次，你就会突然发现，自己已经“死了”。
为什么？
上文：事实证明，“只要你把它做出来，人们未必就会来”。更好的产品和更多的功能，并不一定等于增长。
推动更多用户获取、留存和参与度的许多关键杠杆，有时都不在大多数优秀产品负责人的工具箱里。有一长串至关重要、但却不常被视为产品核心的技能：广告技术集成、注册漏斗的 A/B 测试、通知触达优化、价格点测试、用户群组曲线测试，等等。没错，偶尔会有人样样精通——但这样的人很少！
此外，单靠某一个人无法推动这一切。相反，你需要把它融入组织目标和组织 DNA 之中。你需要在公司的更大框架内统筹这些努力。
我们已经逐渐认识到，“设计思维”和“敏捷工程”本身就是各自独立的一套组织结构、工作流程、理念和技能组合。它们是我们在公司内开展工作的关键所在。
同样地，我们也可以把增长团队构建成一个系统。
它为提升各项指标提供了一套底层系统，无论是收入、获客、留存、参与度，还是其他关键业务指标。
上文：而且正如你对科学方法所预料的那样，这些步骤是建立在理解数据、提出能够解释某些流程为何发生的假设、优先排序这些想法、开展实验，然后重复这一循环之上的。
这样一来，如果你认为活跃用户数偏低，你就可以分析数据，了解到你需要在漏斗顶部获取更多用户；然后假设付费广告与推荐的组合能帮上忙，接着就据此执行。
这比单纯构建更多用户要求的功能，并指望增长会因此神奇提升，要好得多，也更有针对性。（也许你还是应该去做那些功能，但不要为了增长而做！）
上图：第二个主题。让我们来谈谈“增长黑客”——这是 Sean Ellis 发明、而我帮助推广的一个术语——与“增长团队”之间的区别。这一点很重要。
上图：在增长技能体系的早期，并没有团队。那时有一些个人和创业公司创始人正在把必要的想法、工作流程和战术整合起来。其中一些人会半开玩笑地称自己为“增长黑客”。
随着这项技能的发展，显然要做出任何有影响力的事情，尤其是在更大、更复杂的产品场景中，你需要组织起整群人。
上图：因此，增长团队应运而生，其理念是：你不希望只有一个掌握所有杠杆的天才，以及一群辅助者。相反，你需要建立一个具备广泛技能组合的组织。
增长是一项团队运动，而要对你的关键绩效指标（KPI）执行科学方法，你需要很多能够帮助你的人。
上图：对于增长团队的大多数任务，你都需要许多不同职能角色的协助——来自产品、市场、工程、数据、运营、财务等等。你把这些人组合成一个个独立团队，并将他们组织在一起，形成一个增长组织。
上图：这些角色中的人都在做什么？
-
增长产品经理：负责实验路线图的产品经理
-
增长工程师：专注于技术决策并实施实验的工程师
-
增长营销人员：一位多才多艺的营销人员，精通特定渠道——从付费营销到 SEO，再到电子邮件等
-
增长数据：专注于挖掘洞察的分析师——既包括用户生命周期层面的宏观洞察，也包括针对具体实验的微观洞察
-
增长设计：主导 UX 的设计师，但更强调速度
你也可能会让其他职能部门参与进来——例如在 Uber，关于激励支出的许多决策都必须让财务或定价团队的人参与。而且你总是需要把运营团队也纳入进来，考虑它会如何影响一线的实际情况。
上图：根据你试图解决的问题不同，团队构成也会有所不同。对于新用户体验——这可能包括提高注册转化率，甚至还可能包括与广告的整合——你大概会更强调工程师。你会希望有 Android 和 iOS 工程师。此外，还需要一些效果营销人员、一些数据分析师来查看指标，等等。
上图：另一方面，如果你在做 SEO，那么你可能不需要设计师。这可能更多是关于优化页面结构、内容放在哪里等等。在这种情况下，你可能会更强调 SEO 营销、数据分析，以及一名负责网页的全栈工程师。
最终，目标是根据你的洞察和假设来定义问题，并为解决该特定问题配置团队。不同的团队可能会强调不同的技能，而增长团队在整体组织结构中的位置也会因其他团队的使命不同而带来一些复杂性。
上图：一种常见的组织方式是把 Growth Team 视为一组小组，每个小组都与各自的职能矩阵式协作。比如，你可能会有一位向 Product 汇报的 Growth PM，再加上其他成员，他们合在一起就是增长团队。许多产品团队都是这种样子，而且这种设置方式也是为此而设计的。
或者，在 Facebook 以及 Uber 增长团队早期的组织形态中，你会看到更像业务单元的设置方式。各个职能向一位 GM 汇报，下面再分设不同的小组。这种方式的优点是在团队内部创造了很强的独立性，但其复杂之处在于你把不同的组织拆分开了——这也可能带来复杂性，有时甚至会引发冲突。
上图：显然，你也可以按需取舍，采用混合模式。
上面：太多初创公司一开始就喊着“我需要一个增长团队！”，然后不加思考地接受某种随机的组织架构配置，而没有从根本上把事情想清楚。归根结底，你必须从自己要解决的问题出发。先从 KPI 和你已经获得的洞察开始，然后再进入执行。你要根据问题领域以及你想要的执行类型来配置人员。组织结构则由此自然推导出来。
上面：这是我经常被问到的一个问题。增长和营销不就是一回事吗？增长和产品不也一样吗？难道不能让每个人都对增长负责吗？
在这一部分里，我会讲一些实际上的差异。
首先，就营销和增长而言，你会想要解决很多不同的专业领域：
-
品牌营销
-
公关
-
活动
-
内容营销
-
电子邮件
-
SEO
-
付费营销
-
病毒式/推荐功能
-
新用户体验
-
用户之间的通知
-
等等
你可以将所有这些功能放在许多不同的配置中，但大致来说，你通常会有三类功能：
-
品牌
-
增长营销
-
增长产品
通常很明显，品牌最终会归入市场营销。同样，像 NUX 和产品生成通知这类内容，也会归入增长团队。但一些中间手段，比如 SEO/付费营销/邮件等，可能放在任一团队中都可以。我见过两种情况。Facebook 将大量效果营销放在增长团队内部。Uber 也是从那样开始的，但最后全部都归入了市场营销。可能的组织方式有很多种。
上面：如果核心产品团队有工程师、设计师和 PM，增长团队也有这些角色，那它们有什么区别？这完全取决于它们做什么。产品团队专注于创造核心价值，随着时间推移不断提升产品/市场契合度。这意味着要对核心参与循环中的每一个细微交互都极度关注——这是一场以英寸计较的比赛，而这些英寸至关重要。
另一方面，增长团队应该专注于把核心价值推向世界——让尽可能多的人体验到这种价值。
在让用户尽可能频繁地体验核心价值这件事上，有一个中间地带——你可以想象把它放在任一团队里，但如果解决方案往往是高度迭代、数据驱动的，那么也许应该把它放在增长团队。
上面：你还必须决定所有权模式。这里有两个极端：Growth-as-a-Service 和 Autonomous，以及介于两者之间的一切形式。
在“Growth as a Service”模式下，团队在技术上并不拥有任何功能或代码库。他们会切入产品中价值最高的部分，进行分析和优化，推出一批改进，然后转向下一个目标。团队保持克制很重要，因为他们是“客人”，但同样重要的是他们要保持轻量。如果增长团队最终拥有他们接触到的每一段代码，那么最终他们会把所有事情都拖入维护模式。
另一方面，完全所有权模型意味着增长团队可以负责新用户漏斗、通知、广告技术、A/B 测试平台、支付流程，以及许多其他关键领域——在这些地方，数据胜过直觉。这个模式是可行的，但前提是团队必须配备得当。
上面：归根结底，每种模式都有很多优缺点。Uber 走过了整个光谱，但随着时间推移，逐渐拥有了产品中越来越多的部分。不过，你需要根据自身的限制、组织架构和产品需求来做决定。
一旦增长团队建立起来，他们应该把重点放在哪儿？如前所述，他们的使命和工具集应当与营销团队或产品团队所使用的不同。尤其是在团队初期，应该有一些容易摘取的低垂果实，可以很轻松地被拿下。
尽管很容易直接切入用户获取，或者去看流失率，但让我们先退一步，从系统层面来审视。先从一个优先级排序框架开始。
上图：归根结底，你需要权衡三件关键的事情——其中有一件尤其棘手：
-
投入。执行这件事需要多少设计/工程/营销资源？
-
成功率。它有多大可能取得成功？
-
上升空间。这是最棘手的一项——但如果它奏效了，会对整体增长产生多大影响？
每一次增长实验，最终都是基于这三个维度的排序来做优先级判断，而且随着时间推移，你的增长团队会越来越懂得如何选择。但我想先提供一些关于增长团队在优先级排序上可能会犯错的说明。
在选择增长项目时，最常见的反模式是：一个只影响 0.01% 用户的功能即使提升了 +50%，也会被大肆庆祝；但一个影响 50% 活跃用户、只提升 +5% 的改动，却显得“小得多”。当然，算一算就会发现，后者重要得多，因为你最终希望这些自下而上的实验能够推动你自上而下的 KPI。
另一个常见的反模式，是优先选择投入大、收益也大的项目，而不是低投入、低/中等收益的项目。几乎每个人都会高估自己成功的概率，所以更好的做法是持续推进更多执行层面的工作，而不是去押重注……直到你把容易实现的点子都用完，或者你已经有足够的资源去构建一个由大小项目组成的组合。
关于每个因素的一些说明：
-
一般来说，Effort 是最容易理解的。如果你定义了一个项目，你的团队就能像执行其他任何事情一样去推进它。我在这里通常给出的建议是，在增长团队早期，要偏向选择低 Effort 的项目。
-
Success rate 可能会有争议，因为在增长中有效的东西，并不一定是用户会主动反馈的——因此，团队里的人通常会说：“我绝不会想要这个。我绝不会这么做。” 但事实上，你实施最佳实践后，事情就真的奏效了。这里的经典例子，是想在落地页上加入全面的内容，并链接到无数其他地方。业内早已形成一种被广泛理解的设计模式：只提供达到注册所需的必要信息——仅此而已。
-
不过，在这三者之中，Upside 是最难理解的。但它也是最有力量的杠杆，因为它能为增长团队应当把重点放在产品的哪个部分提供强有力的指引。
让我们深入了解一下 Upside。
上图：Upside 最终是以绝对值来衡量的——你新增了多少订阅用户、产生了多少注册量，等等。你可以用两个组成部分来计算它：Reach 和 Impact。Reach 是衡量有多少终端用户受到了某项功能变化的影响。Impact 是指这一变化使指标发生了多大幅度的移动。
在这两个因素中，Impact 往往最不稳定。有时你所做的改动会让结果提升 +5%，有时则可能提升 +50%。总体来说，对于绝大多数项目，你通常会得到介于两者之间的结果。对于某些项目，如果它是一个可以多次发生的产品体验，Impact 可能会非常大——例如，在产品核心互动循环中发送的一条高度相关的新通知。或者某个显著放大病毒传播循环的机制，使飞轮转得越来越快。（但这并非常态——不过这也说明，你可能应该把注意力放在这些影响极大的案例上）
另一方面，Reach 是一个非常强大的杠杆，但常常被误解。这通常是理解最佳项目类型的最佳切入点。
上面：通常，大多数产品团队都专注于提升其核心产品体验，这会让核心用户受益。这有很多好处——毕竟，他们是参与度最高的用户，从变现角度来看也是最有价值的，而且在一个多边平台中，他们会产出照片/内容/销量等，支撑整个生态系统的其余部分。
另一方面，核心用户往往只占总活跃用户的一小部分。
上面：根据你对核心用户的定义不同，他们通常只占活跃用户群的 5% 到 25%。如果你看的是用户群中真正产生内容、而不仅仅是消费内容的那部分，你会发现其比例通常都很小。或者说，看看那些大量产出内容的硬核用户，与纯被动的消费者之间的比例，也总是很小。
因此，如果你有一些项目可以针对活跃用户，而不是核心用户，那么你的触达范围可能会扩大 4 到 20 倍！哇。
但这还不是全部，还有更多同心圆。
上图：平均而言，你注册用户中每个月可能只有 10% 到 50% 处于活跃状态。50% 已经是世界级表现——比如 Facebook 及其同类产品。通常，大多数产品更接近 10% 到 20%，因为绝大多数产品都有大量“一次性用户”：他们只尝试过一次产品，然后就再也没有回来。
处于这个层级的项目应该聚焦于激活。如果你能理解是什么让用户变得活跃，那么你就可以在 onboarding 流程中把这些因素引入进去，从而将他们转化为活跃用户或核心用户。
这里另一类活动——对于拥有庞大、成熟受众的产品而言——是让不活跃/流失用户重新回到产品中。他们是否收到了相关邮件，以便重新激活？如果他们忘记了密码，你是否像优化注册流程那样严肃地优化这条流程？
上面：当然，对于很多产品——这更偏向于网页产品——会有一些人看过产品，但从未注册。大多数落地页的注册转化率可能只有 10% 到 50%！此外，很多产品还有“侧门”——比如 Dropbox 的共享文件链接，或者 YouTube 的视频页面——它们承载了大部分流量。这些都会成为必须重点优化的关键位置。
上面：当然，比所有曾经与产品有过互动的人——即使是在未登录状态下——更大的一群人，是你主要获客渠道中的所有用户（无论是在 Facebook、Google 还是其他平台上），他们之前甚至从未听说过你。这才是真正的漏斗顶部获客。
当然，还有所有你甚至还没尝试过的渠道。这就是为什么新增一个渠道——比如在尚不存在时去尝试推荐系统——会成为如此强大的增长杠杆。
上文：总而言之，如果你正在寻找增长上最具杠杆效应的突破口，那大概率是在解决“触达”问题。想想那些同心圆：当你发现增长团队的项目与核心产品团队发生重叠时，就要往更外层的同心圆移动，不管那意味着面向新用户、流失用户，还是那些尚未接受你产品、处在边缘地带的所有人。
另一个很有意思的练习，是审视你现有的功能和路线图，把所有触达非用户（或不活跃用户）的内容圈出来，而不是那些面向活跃/核心用户的内容。你会惊讶地发现，这类内容通常少得可怜。
以上内容来自 Airbnb 的增长团队，他们确实做过这个练习——33 个项目里，只有 6 个是面向非用户的。（向 Gustaf 致敬，是他负责了他们的访客增长！）增长团队可以迅速扩展这份清单，并给予受众边缘地带的所有人更多关注与支持。
上文：最后一个话题。假设你个人正在考虑加入一家公司的增长团队，或者从零开始组建一个增长团队。你应该期待什么，又该如何评估这个机会？
上文：有许多组织和文化层面的因素，可能会妨碍建立一个成功的增长团队。首先是领导层的 DNA——大家是否真正理解增长团队的职责？尤其是在产品和市场同级伙伴中？还是说，这只是 CEO 或董事会自上而下强行推动的事情，而缺乏管理层的认同？如果人们从根本上不理解增长团队的使命，过程就会很痛苦。
公司文化也是一个重要因素。如果公司的文化像 Uber 1.0 那样，鼓励实验——只要实验范围一次只限于一两个城市，或者作为 1% 的测试——那就很好。“快速行动，打破常规。” 另一方面，如果公司对设计和品牌极度重视，情况就会更难。众所周知，Apple 和 Snap 在最近这个时代之前，很少进行 A/B 测试。在评估一家公司是否适合做实验时，最好了解大家对主页进行重大改动的接受程度，比如即使只是 1% 的流量测试也是如此。或者在新用户流程中也是一样。
如前所述，所有权模型可以处于一个光谱的两端：SWAT 小组模式，几乎没有代码所有权；或者对 NUX/通知/广告技术等领域拥有强所有权。这两种方式都可行，只要你清楚自己在做什么，并且人员配置与之匹配即可。
恕我直言，在我看来，最理想的情况是拥有这样一个团队：
-
真正认同设立增长团队，并且知道它如何与现有职能相互补充
-
支持实验，即使是非常激进的实验，只要先在小范围内进行测试
-
已就位的专职人员，倾向于对活跃用户群体之外的所有事务承担强烈的主人翁责任
当然，最糟糕的情况是，大家根本不明白为什么要有增长团队；对快速实验极度规避风险，而且没有任何专职人员……只期待你四处奔走，说服其他团队去构建你那些惊艳的想法。这注定会失败。
上图：在组建增长团队这件事上，常见的分歧点有很多。有时，公司的激励机制会更奖励大型、复杂的项目（带有代号和高层监督），而不是许多能推动业务前进的轻量级改动。这种偏好会渗透到从项目评审、绩效考核到其他一切环节中。
同样地，在成立增长团队之前，几乎可以肯定已经有人在负责产品中与增长相关的部分。通过把这些职责移走，或者开始侵入与核心产品团队重叠的“用户参与”领域，就可能会出现一种“抗体”，让增长项目变得慢得多，慢得多。
上图：组织的基础必须准备好接受一个增长团队，而这始于一个根本性的认知——环境已经发生了变化：
-
科技产品的增长方式已经改变，过去十年的打法也已经改变
-
必须明确分配人力和路线图资源来推动增长实现——“建好了自然会有人来”这套行不通
-
创建一条增长实验流水线，需要一种不同的流程。将科学方法应用到 KPI 上，而不仅仅是营销和产品项目的一个子集
-
最后，要让这件事成功，所需的团队结构和技能组合也不同
你可以想象，建立这种相互理解的基础本身就是一项重大工程。而且你还需要初创公司 CEO、你所在业务单元的总经理，以及他们上一级管理者的帮助。还有你所有的同级同事。
上图：有一些策略可以帮助你克服不可避免的组织摩擦。下面列出其中一些。
