一文了解增长黑客

A/B Test 或“病毒营销”就是增长黑客？增长黑客完全是产品同学的工作？如果你也这么认为，别等了！赶紧进来！咱们深入交流一下！来自一名尝试理解增长黑客的小开发。

作为开发同学，你或许已经有过或即将遇到类似的困惑：增长黑客就是病毒营销？开发参与增长过程就是搞搞报表；跑跑数据；且毫无挑战？增长是产品同学的事情，对开发同学而言就是继续以往需求 > 实现 > 交付的常规流程，没有其他变化？

如果你也遇到了这些困惑，或者你即将参与增长过程，希望在起步阶段就能发挥主观能动性，那就请继续往下看。

本文主要是笔者针对《增长黑客》一书的总结：一方面，浓缩了书中的关键知识点；另一方面，结合笔者经验，在必要的地方提供简要的举例说明。既算是笔者对《增长黑客》的知识梳理，也希望能帮助其他同学提高学习效率。

二、什么是增长黑客？

两个关键词：数据指导；快速试验。

一个作用：促进 AARRR 中的一项或多项指标的增长。

AARRR漏斗模型：获客/Acquisition、激活/Activation、留存/Retention、付费/Revenue、推荐/Referral。此外，还存在 RARRA 模型，5个概念没有变，但提高了留存的重要性。

三、怎么实践增长黑客？

这里隐藏了细节，仅为了帮助同学们更快构建知识框架，详细内容请前往文末获取。

接下来，我们以这张脑图为框架，逐步展开。

四、前提：确定产品是不可或缺的

你可以理解为找到产品的 “Aha moment”。

1. What？

“Aha moment” 就是产品使用户眼前一亮的时刻，是用户真正发现产品核心价值——产品为何存在、他们为何需要它以及他们能从中得到什么——的时刻。

2. Why？

为什么需要这一步？

• 浪费时间——将精力浪费在推广一个缺乏核心价值的产品上；
• 不好的产品会使早期用户流失，甚至成为愤怒的批判者。

3. How？

这里提供 4 个方法来发现产品的 Aha moment。

1）向活跃用户发起问卷调查，这里需注意 3 点：

1. 目标群体是活跃用户。
2. 失望度比满意度更能衡量用户对产品的忠诚度。比如：如果这个产品明天就无法使用了你会有多失望？如果本产品无法使用了，你会用什么替代产品？你向别人推荐过本产品吗？等等。
3. 相关负面评价达到40%。说明产品具备了不可或缺性（具备市场期待值）。如果在25%~40%，说明产品需要微调。如果不足25%，那你可能需要思考：你的目标群体和你的产品是否匹配？你的产品还需要完善哪些功能？

2）衡量用户留存 & 收集用户数据

• 确定观察的单位时间（月、周、日）。
• 确定合理的留存率（60%、10%、90%）。
• 收集用户行为数据和一些属性，并深入分析（这里要注意隐私边界）。某个群体的活跃行为，可能就是这个群体的 “Aha moment”。

3）优化信息传达

最常见的就是 A/B Test，但 A/B Test 也有其局限性。这里还可以了解一下 bandit算法（多臂赌博机模型）或其他测试方式。

4）针对产品进行高效试验

涉及产品的修改往往成本较高，而且对用户影响较大，因此这里要注意应优先测试那些经之前的经验证实、能够优化结果并改进用户体验的改动。对于耗时耗力的测试，团队应当通过严密的论证将风险降到最低。

此外，对于工具型的产品，“Aha moment”需要场景化落地。

以腾讯问卷为例，在用研方面，它可以为用研同学提供样本库、问卷管理、丰富的统计视图和交叉分析、以及回收数据下载或同步到腾讯文档。显然，这就是问卷的 “Aha moment” 路径。

但这个路径显然无法在教育、报名、政府/企业信息收集等场景下复现。那么，就要通过上述手段，更高效地找到这些场景下的“Aha moment”。

五、准备：获得支持/组建团队/找准方向

1. 获取高层支持

1）增长团队需要跨职能/部门沟通，这必然需要更高层对增长团队的支持进行表态。

2）增长试验需要资源，并要求高频且连续的，这时候除了资源上的支持。在试验的必要性被证明为前提，更需要高层的授权以及对试验失败的容忍。

3）高层协助处理组织内部的敏感问题和可能出现的摩擦

增长团队需要获取足够的资源进行快速试验，必然会与其他团队的资源相冲突。

例如，团队人员不足，导致增长团队成员要兼顾产品的功能迭代。但两三个月下来，产品的功能迭代挤压了增长团队成员的所有开发时间。这个问题使增长团队徒有其名，具体增长工作几乎没有落实。

要解决这个问题，显然就需要相关职能团队的上级负责人在资源协调方面给予支持。除此之外，也需要进行第一次增长团队会议，就排期、试验节奏和目标明确共识，保障后续增长试验的持续推进。

2. 组建增长团队

公司发展初期成立独立增长团队的阻力是最小的，因为这时公司架构还没有成型，资源归属和汇报制度还没有正式确立下来。

要保证试验顺利、快速推进，增长团队不可避免地需要跨职能沟通，这时候，团队里面必然需要多个角色，如：团队负责人、产品经理、工程师、数据分析师、设计师甚至营销专员等等。

需要注意的是：

1）这里描述的是角色，一个团队成员有可能同时担任多个角色，尤其在项目和增长团队的初期。

2）负责人要能够准确把控增长目标；管理试验进度。但不限定负责人的专业背景，他可以是产品经理，可以是数据分析师甚至工程师等等。

3）营销专员可以是仅在增长工作的某个阶段才存在于团队内的，短期目标达成后即离开，有时候他可能是产品经理兼任；有时候可能是外部顾问；有时候可能是团队负责人。关键在于，从营销的角度，可能给增长工作带来更多有价值的建议。

4）要激励所有团队成员毫无保留的提出关于增长试验的想法，其意义不但在于广泛收集创意，更在于保持团队活力，确保增长试验不至于停滞

5）团队成员间的信息高度同步，工作内容高度协调。其目的在于支撑试验快速、连续地进行。

3. 确定增长杠杆

前面我们已经介绍了如何找到了产品的 “Aha moment”。但要想稳定复现“Aha moment”，就需要更多的工作：

1）找到用户对产品核心价值的体验最直接相关的行为——这就涉及到前面提到的，用户体验到 “Aha moment” 的操作路径了。

2）收集并整合数据资源——但用户反馈同样重要。

3）确定北极星指标，指标随着团队发展可能变化，甚至存在一个核心指标下，不同团队进一步负责不同的更细节的北极星指标。

4）确定核心指标和增长等式——所有与增长相关的关键因素都在这个等式中有所体现，而这些因素相加共同驱动公司的增长。

确定增长杠杆的另一层意义，就是为之后的增长工作指引方向。

六、实践——开始增长循环

1. 核心方法

在开篇已经提及：数据指导 + 快速试验。

2. 快速试验

这里只提要点：

1）鼓励所有团队成员毫无保留的提出试验想法，这对保持增长节奏和团队活力十分重要。

2）试验可能会有很多，因此需要一些打分机制来帮助我们排定优先级——但不要过渡纠结分数准确性，仅作参考即可，关键还是要看北极星指标，切勿本末倒置。书中列举的可用的方法有：ICE、TIR和PIE模型（具体见下图）。

A/B Test 存在其局限性，例如，不能多维地描述测试结果。因此，我们常常还需要别的测试方法（如 bandit算法）快速试验不等于一股脑的进行一堆不知道是否有效的试验，所有进行的试验一定是经过论证的、具有一定影响力的。

3. 具体实践——AARRR

这是常见的增长模型之一，亦指用户在产品使用周期中的几个关键过程。除此之外，也演化出了 RARRA 模型，甚至。以及更多这里相信很多产品同学比我更专业。我仅从各个指标罗列一下具体方法。

七、最后的话

如果你以前对增长黑客没有了解，看完此文，你可能会发现，虽然你没有增长黑客的概念，但《增长黑客》中很多要求、方法、原理等，其实都已经在我们的日常工作中有所实践，包括：成员间高度协调；信息同步；在什么时候获取高层支持；数据洞察；病毒营销等等。拆开来看，每个问题都有更多更详尽的书籍值得推荐（见文末“延伸阅读”）。

显然，《增长黑客》并没有提出太多新的观点或工具。笔者认为，这本书更多的是关于“促进增长目标”方面，总结了一系列经验。

在传统筒仓模式下，各个部门、职能岗位各司其职，互补相关，遵照着一套流程完成一系列的版本迭代。看起来各团队、岗位的信息是极容易不对称的。实际上，现在很多公司在崇尚扁平化发展。

笔者在 2017 至 2020 年间，在国内流行的招聘平台上，也常看到一些招聘单位将扁平化管理作为卖点之一（甚至包括一些非互联网公司）。但实际上，绝对的扁平随着团队规模增大，风险和问题会随之而来（参考：企业管理层次 “扁平化” 跟 “金字塔” 各有哪些优缺点？- 知乎 ）。

笔者过去曾就职的某单位，团队从不到 50人在一年内快速扩充至 100+ 人。扁平化在此带来的问题就是多数成员都有数不清的大小会议和沟通成本，专注于本质工作的时间不足 50%。而不得不在管理上，对信息进行逐层过滤（又回归了金字塔管理模型，只是层次并不算特别深）。

因此，笔者大胆猜想，整体采用传统的筒仓结构、或金字塔结构，在如增长团队等特殊职能团队上采用扁平化结构——在团队内保持信息高度同步，成员高度协调——会不会是最佳实践？

说完书本内容和团队，最后再讲讲增长过程吧。笔者作为一名团队内的开发成员，一开始对增长黑客的概念其实是模糊不清的。

或许其他同学（尤其是开发同学）也会有如我这般的误解：增长是产品运营或其他产品同学的事情，与开发无关；增长黑客就是病毒营销；增长黑客就是一堆AB Test……（实际上，除了AB Test，上面不提到了还有多臂赌博机嘛~）。

实际上，增长黑客的核心方法，笔者认为就是上文总结的“数据指导 + 快速试验”。无论是团队组成、获取高层支持、保持团队高度协调还是明确北极星指标和增长杠杆，最终都是为保障快速试验进行的。

而开发同学，在这其中不但要协助实施具体试验。也要根据自己掌握的信息主动为团队工作提供协助，或从自己的角度提出更多试验构想（书中讲述为何打破筒仓时，提供的BitTorrent的案例令我大受启发，详见下方引用）。

接连不断的成功让BitTorrent移动团队大受鼓舞，每一个人都开始提出可以测试的想法。他们测试的其中一个想法只有那些拥有无私精神的技术人员才能想到：自动关闭应用以节省手机电量。移动团队在对免费版App的“超级用户”（那些频繁使用App但还没有升级到专业版的人）进行专项调查的时候发现了这个增长机会。调查发现这些用户的一个主要痛点是由于高强度使用造成的手机电量迅速流失。

于是，工程师很快提出了一个想法：打造一个专属于专业版的功能，当App检测到用户手机电量只剩不到35%时便自动关闭耗电的后台文件传输。

他们在免费版App里推广这一功能，当用户电量不足时，App便会提示他们专业版提供这个功能，吸引他们马上升级。这个新功能十分受用户欢迎，也使公司收入增加了47%。

（来自《增长黑客》第一章第一节——打破筒仓）

这篇文章篇幅较大，因此就不在此罗列增长所需的数据分析方法和具体工具了，有兴趣的同学欢迎关注后续的文章。

八、延伸阅读

书单中，有的书笔者也没看完，但就已读内容而言，笔者认为对理解并实践增长黑客有较大帮助，因此罗列出来，仅供参考：

《在你身边为你设计. Ⅲ，腾讯服务设计思维与实战》

注意到《增长黑客》书中，洞察用户需求并改进用户体验，既是增长黑客的要求，也是实践的基本方法。该书由腾讯的用户研究与体验设计部编著，关于如何洞察用户需求；打造设计团队；提出方案并推动落实等方面提出了系统的方法论。值得参考借鉴。

《OKR工作法：谷歌、领英等顶级公司的高绩效秘籍》

一本两小时就能看完的书。《增长黑客》实践要求团队以数据为指导，在明确的方向上，保持高度的协调和沟通，这个观点与OKR工作法的要求高度相似。实际上，OKR目前也在包括腾讯在内的多家国内公司有推广，要想更好落实、举一反三，无疑很有必要先去系统地了解一下。

《敏捷软件开发：原则、模式与实践》

同样，《增长黑客》描述的关于高度协调、快速试验的观点和具体方法，与敏捷开发持续迭代、持续交付的观点也多有相似。目前，国内已经有很多互联网公司都推崇敏捷开发，但在理解和实践上，却五花八门。了解敏捷开发的历史背景和核心观点，相必对增长黑客的实践也有帮助。

《思考，快与慢》

本书从人在思考中存在的两个系统（运用直觉、进行快速思考的系统1和需付出努力、运行更慢的系统2）展开，描述了人的思考和选择过程。其中有许多基于消费者购买行为的案例（实际上，作者也是一名曾获得诺贝尔奖的经济学家）。在《增长黑客》第八章 “变现：提高每位用户带来的收益” 的“优化定价” 一节中也有提及，因此也安利一下。

《上瘾》

笔者还没看过，不过是《增长黑客》书中有提及的一本书，专门讲如何让用户“形成一种习惯的”，并提出了一个由触发物、投资、行动、回报四部分组成的“上瘾模型”。似乎对提升用户留存很有帮助。

怎么实践增长黑客详情：