这是一个面向公司层面的规划框架，核心理念来自 Brian Chesky 的一句话：“我们想要一个上千人工作的公司，但它看起来像只有十个人做出来的。”该框架要求整个公司围绕一份滚动更新的两年路线图运作，从而让工程、设计和市场在大型统一发布上完美同步。
用途
- 当公司频繁交付但客户没有感知时使用；
- 当工程与市场节奏不同步时使用；
- 当各团队路线图碎片化、缺少连贯叙事时使用；
- 当需要创造有新闻价值的发布时刻时使用。
核心原则
- 滚动两年视角：维护一份看向两年后的路线图，每六个月更新一次。近端时间范围固定，远端保持灵活。
- 指标服从日历：承诺具体发布日期（例如夏季和冬季发布）。这会倒逼范围决策，避免无休止的优化循环。
- 发布即剧集：把产品发布当作电视剧集或书本章节。将功能打包成连贯叙事，让市场团队能够真正去推广。
- 完全可见：所有项目都必须出现在中央路线图上（小型基础设施除外）。如果不在表上，它就不存在。
使用方式 第一步：定义发布节奏——选择固定的发布窗口（例如五月和十一月），并从发布日期倒推工作。 第二步：建立单一事实来源——全公司只有一份路线图文档，所有举措都必须归入发布剧集。 第三步：把功能打包成叙事——将相关功能归入“章节”，为每次发布创建市场故事。 第四步：强制可见性——不允许“影子路线图”或旁支项目，定期举行跨职能同步会议。
适用场景 适用于需要把大量分散的功能升级整合为几次重大、可宣传的发布时刻的公司，尤其是工程、设计、市场需要高度协同的大型组织。资料中的现实案例是 Airbnb 的“冬季发布”和“夏季发布”节奏，它们把数百项升级（例如 Guest Favorites 和新的 Host Tab）打包成一个有新闻价值的时刻。
限制与常见错误 常见错误包括：允许团队保留消耗资源的“影子路线图”或旁支项目；持续发布小更新却没有连贯的市场叙事；为速度指标而非客户影响做优化。除此之外，关于具体实施工具、团队规模要求、成本或更多限制，资料暂未提供。