maxOS

增长黑客

读书

看完增长黑客的第一感觉就是它是对敏捷开发的补充。如果说精益创业告诉我们如何通过快速试错来从 0 到 1 的去构建一个产品,那么增长黑客则是从 1 到 100 的持续提升产品价值的过程。无论是精益创业还是增长黑客,其核心都是通过数据驱动和假设驱动来推进产品的演进。而敏捷开发在其中所扮演的角色则是高质量的持续交付,再次基础之上,我们才能够不间断的循环试验和改进。

在增长黑客这本书中,作者给出了大量的案例,并在最后的几章中着重介绍了增长黑客适用的几个场景,也就是互联网圈经常说的 AARRR 模型中的:

使用条件

并非任何时候打可以用增长黑客的方法去实现大量的用户增长,增长黑客只是方法,每个方法都有其局限性,对于增长黑客而言,它的基础条件是被市场认可的产品,如果产品还是在 0 到 1 的阶段,那么此时的关注点是如何找到核心用户,过早的投入到增长黑客中可能无法避免因为核心功能的缺失而导致较高的流失率。

同时增长黑客是基于数据驱动和假设驱动的方式在进行试验,在无法获取一手的可量化的数据的情况下进行增长黑客,就如同在黑夜中摸索一般,往往找不到方向。

同时增长黑客中所提倡的假设驱动,在有数据的前提下需要快速对假设进行验证,而验证都是需要付出成本的,对于软公司来说这里的成本更多的是时间成本,如果无法在 1-2 周的时间内完成相应的假设并发布上线,那么长时间的消耗也会导致团队迟迟看不到验证的结果,对于后续的假设的可信度也会产生更大的怀疑。

增长黑客与敏捷开发

二者的相同点在于都是对市场的快速反应,强调高效、低成本的进行试验和快速交付。不同点则在于关注的方向,敏捷开发更加关注产品的交付,价值部分则由代表客户的 PO 来决定,PO 需要向每位成员解释某个用户故事的价值所在;增长黑客则关注指标,价值是由可量化指标直接反应出来,所有人可以很容易的看出价值所在。

如同敏捷开发的 Backlog -> Grooming -> Planning -> Implement -> Review/Feedback -> Backlog 的循环的流程相似。增长黑客的方法分为四个阶段:分析 -> 假设 -> 排列优先级 -> 实施 -> 验证 -> 分析的循环。

分析基于已有的数据,来找出当前指标与期望之间的差异,并找出所有可能的原因。 假设根据分析得出来的结果找出的解决方案,可以简单理解为需求或是用户故事。 优先级相当于敏捷开发中的 Grooming & Planning 的环节,决定本次试验/冲刺需要做的内容。 实施将假设付诸于实践,如果是功能上的改进,那么是开发团队进行功能开发,也可以理解为是一次敏捷冲刺。 验证当功能发布上线之后,持续追踪预期的指标,并与预期的指标进行对比。

黑客增长强调试验,所谓试验可以理解为小成本的进行试错,整个从分析到验证的过程就可以理解为是一次试验,相当于敏捷开发中的一次冲刺。不同之处在于敏捷开发更加强调工程方面的交付,而增长黑客则强调整个团队的协作,开发团队依然保持敏捷的方法,数据团队为最终的验证提供可量化的指标,产品和运营通过分析指标和用户行为来不断提出新的指标和假设,从而保持整个团队都在高效的运转。

试验一次试验我们可以认为是敏捷开发中的一次冲刺,每次冲刺都有一个既定的指标。 指标是一个可以被量化的指标,例如用户留存率或者转化率。

我们可以使用用户故事的格式来描述一次试验,假如针对某类用户某些事情,我预期可以将某个指标提升到某个数值

指标

增长黑客的核心点在于北极星指标,可以理解为如果我们只需要为这个项目制定一个核心指标,那么这个指标就是北极星指标。之所以称之为北极星,是因为它是团队前进的方向,团队所做的任何努力都是为了努力实现这个指标。

北极星指标是一个大的方向,但是每一次试验则有试验的指标。试验指标一定是可以在某种程度上达成北极星指标的,作为一个很宽泛的指标,北极星指标并不适合直接用来作为试验的指标。北极星指标通常比较宽泛,其影响因素也非常多,而试验则需要聚焦去解决某个具体的问题,这个问题的解决它可能影响北极星指标,也可以不影响,因此我们需要另外一个与之相关的,也就是一定会产生好或者不好的影响的指标来直接观察。

从商业的角度去看,最终衡量指标永远是收入。收入能否作为一个合适的指标对不同的公司来说也会有差异,例如企业可以通过变卖固定资产来提升收入,但是很多时候我们并非想要这种一次性的收入,而是可持续的收入。基于订阅服务的产品更多的使用 MRR 来作为一个衡量指标。MRR 可以作为一个北极星指标来关注,如果是作为试验指标则会过于宽泛。因为 MRR 的影响因素太多了,团队应对的方案也就会有很多,相较于从上百个方案中选择一个合适的,从十几个或者几个当中选择就会容易很多。

试验指标

实验指标是对北极星指标的细分,其关键在于明确产品产品增长公示,以收入为例。MRR = 付费用户量 × ARPU。对于像 Spotify 或者 Xbox Game Pass 这种有着固定月租费用的,ARPU 永远等于月租费,那么这个指标自然而然就是付费用户量。

如果我们继续将范围缩小,付费用户量 = 活跃用户量 × 付费转化率。根据 2/8 定律,绝大多数软件中只有 20% 的用户是付费用户,那么可以根据产品已有的数据来对比这辆个数值:

  1. 目前的付费用户的比例是否达到 20%,有多少的差距;
  2. 目前的活跃用户量是否达到预期的目标,有多少的差距。

这个公式还可以继续细分下去,其中的某一个因素都会影响 MRR 这个指标,针对每个因素我们都可以设定一个预期的指标,然后分析当前的数值与目标之间的差距,差距越大意味着可改进的空间也就越大,那么聚焦于这部分的指标可以帮助团队更高效的达成北极星指标。

假设

我对于需求的理解正如《精益产品需求的要义》一文中,作者的看法一致:

需求就是一组有待验证的假设。

敏捷开发中的需求通常有产品根据业务的发展和客户的需求提出,而在增长黑客中,需求的目的性特别强,需求可以是团队内的任何人提出来,其目的都是为了提升/降低某个具体的指标。

通常的做法是通过头脑风暴或者竞品分析来获取达成这个指标的方法,通常头脑风暴之后团队会得到几十个可能解决问题的方案,几十个方案都去尝试对于多数企业来说都是不可能承受的。那么也就意味着我们需要挑选出一些方案来进行试验。

在提出假设时,通常提出者需要评估这个假设对指标的影响(Impact)有多大,自己对此有多少信心(Confidence),以及其简单程度(Ease,时间成本的倒数),根据 1-10 来进行打分,并根据其平均分来排列优先级。

目标用户

目标用户决定了这个假设的作用范围,作用的目标人群越多,可能产生的效果就会越大。那么把目标用户设定有所有用户群不就是可以将效果最大化了吗?这就会陷入想要满足所有人需求的陷阱。

通常根据用户对产品的使用情况我们可以将用户分为:核心用户、普通用户、沉默用户。如果我们只关注转化率,那么核心用户是一个非常值得关注的群体,核心用户通常有较高的转化率,通过研究这些用户的行为,我们可以将其推广到普通用户和沉默用户。核心用户可能更容易发现产品的价值,也许是其中的某一个小功能或者细节让他们意识到产品的价值所在,那我们可以通过将这个功能做的更容易让普通用户接触到,从而提升转化率。

如何提出合理的假设

假设很简单,就是我们可以无厘头的提出各种各样的假设,但是怎么才算是合理的假设呢?依然是从数据出发。例如我们要提升用户的留存,那么问题就是是什么问题导致用户流失了呢?是因为用户体验不够好,导致某个功能特别难用所以用户流失,还是用户无法感知产品所带来的价值所以流失,或者说两个都有可能。

找出假设的前提还是要找出合理的预期。假设一般都是从猜测开始,我们猜测可能是用户体验的问题,那么透过数据分析我们可以得出用户在使用某个功能时的具体路径,然后找出每个路径中的留存率,判断是否符合预期。

如果是价值问题,那么就要去问问那些留下来的用户,是产品的那些方面使这些用户留了下来。再回过去取问那些流失的用户,看看他们是否意识到这些价值所在。

在定位中,提出来的,价值不是产品告诉用户的价值是什么,而是用户以为产品的价值是什么。也就是产品在用户脑海中的定位,他应该是一个什么样的产品。我们的产品设计是否有突出这些核心价值呢?

实施和验证假设

实施其实就是一个普通的软件的开发工程开发过程,你可能要去写用户故事,或者说要去写需求文档。除了这些开发者需要的基本信息外,还需要提前准备的就是分析报告,分析报告中包括:

整个实施的过程其实就是敏捷开发,但是我们需要设定本次冲刺的指标,已明确整个团队的方向和关注点。再产品交付上线之前,我们需要准备相关的指标,在交付之后的两周内持续追踪这个指标,每周都可以向所有人展示该指标,以帮助大家了解每次试验的成果。

当相应的功能发布上线之后,我们需要持续的追踪关键指标,并在每周的会议上所团队同步结果,并分析其原因。无论现实的结果与预期的有多少差距,这些原因可能成为新的假设的起点,通过这种不断的提出假设 -> 学习的循环,来不断的提升产品的价值,通过产品的价值来提升客户质量。


说回根本,黑客增长并非解救企业的灵丹妙药,它如何敏捷开发一样都是帮助产品能够快速适应市场的方法和工具。它可以帮助产品提升用户量,但并非使用它就一定可以提升用户量。正如书中第二章的标题「好产品是增长的根本」,如果产品本身的品质导致用户大量流失,那么前面的用户增长再强劲,最终留下来依然寥寥可数。

很多人以为增长黑客是一种市场营销的方法,这就忽略了好的产品作为增长黑客的前提。所以我们不如把增长黑客看作是提升产品价值的方法,将其与敏捷开发所提倡的高质量的、可持续的交付相结合,通过数据和假设驱动来帮助产品进化。