Airbnb 从气垫床到上市，外面最爱讲的是创始人神话、设计信仰、估值曲线。

Lenny Rachitsky 讲的是另一套。

2012 年，他创办的 Localmind 被 Airbnb 收购，自己以工程师身份进去，后来成为早期产品经理之一；七年里做过供给增长、转化、行程质量、社区等。2019 年离开后，他写下《What Seven Years at Airbnb Taught Me About Building a Business》——本想理清自己学到了什么，却意外成了 Lenny’s Newsletter 的起点。Fast Company 后来写过：那篇「七件事」打开了订阅飞轮，他如今把产品、增长与职业建议写成一份在 Substack 上极头部的商业通讯。

这篇不是名人传记，也不教你复制 Airbnb。

Lenny 做的，是把规模化经验压缩成普通团队可以执行的工作顺序：不断缩小问题空间——先把问题钉死，再定义理想终点，最后集中资源只打一条线。

三步分别回答三件最常见的事：我们到底在解决什么？做到什么才算真正解决？那么多事情，到底先做什么——或者说，什么先不要做。

第一步：不是更努力解题，而是先把问题缩小

外面容易抄的是口号：强文化、疯狂目标、「做互联网没见过的东西」。Joe Gebbia 曾对设计师说 Build something the internet has never seen before——Lenny 初听也懵。口号可以鼓舞，却不告诉你周一早上该砍哪张工单。

Lenny 在七年复盘里写得很绝：对齐问题陈述，是解决问题时最重要的单一步骤。问题含糊的简单项目可以空转几周；问题钉死的复杂项目反而顺。

普通人能抄的，不是 Airbnb 的 one-pager 长什么样，而是承认：多数团队的假勤奋，来自问题太大。 「我们要增长」「我们要提升质量」听起来正确，细到不可执行——每个方向都能分到一点人，于是处处点火、处处灭。

他接管供给增长时，小队散在很长的漏斗上，局部有赢，形不成动量；行程质量团队也一样。Airbnb 早期真正厉害的地方，不是每个团队都很努力，而是他们不断把「我们要增长」这种大问题，压缩成「这一季到底解决哪个具体问题」：供给侧拆成推荐、自然量、效果广告等专队；质量侧一季只死磕一个点（如房东响应率、评价率），找到大机会再加码。

问题缩小之后，还不代表知道该怎么做。

它只决定了：你不该再假装所有漏斗段同等重要。下一步才是——终点画在哪里。

第二步：别在现状里优化，先定义理想状态

问题钉死后，最容易的错是立刻开工：在现有流程上抠按钮、改文案、做 2% 的 A/B。

Lenny 描述的 Airbnb 习惯更接近 Amazon 的 working backward：先想象完美用户体验，再倒推缺口。Snow White 故事板把行程写成有起承转合的故事，标出情绪节点——用理想旅程找战略缺口，而不是用现状清单找优化项。

硬例子是 Instant Book。预订曾经步数多，还要等房东审批；当时即时预订占比大约只有 5%。团队没有把几个月耗在漏斗每一环的微优化上，而是退后一步问：

如果我们不接受今天的限制，完美的预订体验到底应该是什么？

答案几乎毫无疑问——客人能立刻订下房子，不必干等。
于是「真正的解决」被定义成跃迁，而不是把等待审批的流程打磨得更顺滑一点。

一开始这像不可能：说服房东开放即时预订太难。长期方向清楚后，资源才有资格押上去：先在纸上画出理想流程、写一篇「若成真会怎么宣布」的样稿；把缺口拆成「能不能」与「愿不愿」；内部恐惧「即时会伤体验」时，先用数据快速检验。几年里，市场被改造成绝大多数预订可即时完成。

第一步和第二步在这里接上：

先把问题定义清楚；
再不被现有系统绑架，直接定义终点。

可一旦理想状态确定，现实里一定会出现一大堆阻力——房东不愿开、内部怕伤质量、工程量大。这时候决定成败的，就不是想法本身，而是资源到底往哪里集中、哪些路公开宣布不走。

第三步：确定了终点，就砍掉其他路

Focus 在这里不是独立鸡汤，而是前两步的结果。

如果这一季真正的问题是房东响应率，团队就不能同时负责搜索、支付、推荐、留存——问题已经缩小，再铺开等于把第一步作废。
如果理想体验是「绝大多数房子都能即时预订」，资源就必须集中解决房东为什么不愿意开 Instant Book，而不是继续优化预订按钮颜色——终点已经拉远，再微调旧漏斗等于把第二步作废。

Lenny 写过：专队、清晰 mandate、尽量自给自足的跨职能小组；目标 ideally 就一两个，反馈要快。组织设计本身被他当成产品——结构错了，个人再努力也出不了动量。产品侧同样：他见过的最大客端转化提升，很多来自让用户少想一件事——新标签打开列表、拉长登录会话、支付流去掉多余链接。对内少分心，对外少打扰，是同一种「砍」。

增长写作里的赛车框架是同一逻辑的外延：长期靠少数自持续引擎；早期别同时押所有引擎。主引擎没定之前，到处喷硝基只会吵。

第三步因此很具体：问题与终点都写清之后，公开列出本季不做什么——不加人铺全漏斗，不给每个方向都「意思一下」。

钉问题 → 定义理想 → 集中资源。
或更有文章感一点：先决定解决什么，再决定做到什么程度，最后决定什么不要做。

带走的不是三个技巧，是缩小问题空间的方法

离开 Airbnb 后，Lenny 没有靠内部八卦维持影响力。他靠把可执行顺序写清楚。通讯能做大，说明市场饿的不是又一个 Airbnb 传奇，而是周一早上能改日程的句子。

Lenny 从 Airbnb 带走的，最终不是三个并列技巧，而是一套缩小问题空间的方法。

先把问题缩小，才知道该解决什么；
再把终点拉远，才知道真正应该做到什么；
最后把资源收回来，才有可能真的做到。

普通团队最容易犯的错，恰恰反过来：一上来就做功能，然后不断优化，再给每个方向都安排一点人。看起来一直在推进，实际上从来没有真正回答过——我们这一阶段，到底只需要赢什么？

Airbnb 的规模你抄不走。

但这套「缩小问题 → 定义终点 → 集中资源」的工作顺序，可以从明天开始抄。