三幕式打法的终结

过去，打造一家企业软件公司曾有一套相当直接明了的打法。

第一幕——楔子（也就是“拆分切入”）

从某个现有解决方案服务不足的功能或细分市场入手。在平台变革时期，你会从现有平台中挑出一个功能，在新的格局下将其做到好上 10 倍，并以此作为切入点。

这个细分市场必须足够大，才能迅速扩展到数千万美元的年度经常性收入，但又不能大到招致毁灭性的竞争。Statsig 起步于产品实验。Rippling 则从一款用于员工入职和离职流程编排的工具起家，等等。

1000万至5000万美元

第二幕——套件

第二幕是推出相邻产品，让你把 ARR 扩大到 1 亿美元以上。你打造的不再是单一产品，而是一整套产品。
Statsig 最初从实验产品起步，随后又加入了功能标记、会话回放、产品分析等更多功能。Rippling 则从薪资发放和人力资源工作流（入职/离职）起步，随后增加了一系列人力资源、福利和招聘相关产品，以完善面向同一买家的整体产品供给。

对于走到这一步的公司来说，这可能还需要再花上 3 到 5 年时间。随着第一款产品扩展到 5000 万美元 ARR，你开始交叉销售第 2 和第 3 款产品。到 ARR 达到 1 亿美元时，接下来的两款产品可能分别做到 1000 万美元和 100 万美元。这种套件化打法打开了通往 2 亿至 5 亿美元以上 ARR 的能力。

第三幕——平台

终局是重新捆绑。随着你积累起足够的体量和用户参与度，最终你会赢得许可，去撕掉并替换掉底层平台。这正是所有那些将其底层“记录系统”商品化的“参与系统”的基本前提。理论上，这就是你将规模扩展到 50 亿美元以上 、持久且高粘性 ARR 的方式。

打法手册的速通

我担心“三幕式”打法手册已经死了。我认为世界变化得太快了。

这种三幕式方法在潜移默化中依赖于一定的日历时间，尤其是在早期。创始人能做的毕竟有限——起初你专注于寻找产品与市场的契合点，接着建立早期的 GTM 动作，然后再扩大 GTM。之所以直到 ARR 达到 1000 万至 5000 万美元才开始第二幕，是因为你当时仍在单线程推进第一幕。

过去几年里，从 0 美元做到 1 亿美元 ARR 的公司数量之多（Cursor、Cognition、Clay、Harvey、Sierra、Baseten、Fireworks、Lovable 等），就是世界已经发生转变的证据。

已经没有时间再去精雕细琢一套按部就班的策略了。随着软件工程成本断崖式下降，完成第一幕和第二幕所需的时间也在逼近零。我认为，理性的做法就是一开始就打算尽快把所有东西都构建出来，而且大体上从起步阶段就这么干。

雄心

对我而言，这已经让我对早期投资的方式发生了相当深刻的改变。过去，我会寻找那个具有保护性的切入口——一个可以安全做到 $10M-$50M ARR 的避风港。可现在，这种切入口显得有些小打小闹。我发现自己更希望创业者们直接跳进深水区。

例如，我记得在 Anysphere（Cursor）种子轮阶段时见过他们。那时，我记得他们的计划就是直接取代 VS Code，因为它对 AI 编程来说限制太多了。在我看来，这简直太疯狂了——当时 VS Code 深受喜爱。经历了多年的 IDE 分裂局面后，VS Code 终于胜出。作为一家种子阶段的公司，你们为什么要直接去取代 VS Code？相比之下，更合理的做法似乎是先做一个扩展，然后再赢得取而代之的资格。

注——是我错了。如今，取代 VS Code 几乎都让人觉得野心还不够大。为什么要止步于此？

随着编写软件的成本降至零，我发现自己比任何时候都更看重野心。那种不讲道理、永不止息的野心。

我认为“三幕剧”式的打法已经死了。在一个快速变化的时期，依赖一个切入点显得过于保守。我的看法是，如果你真要做，那大概就该直接冲着整个版图去。