用途
Working Backwards 是亚马逊的产品开发方法论。其核心洞察是：从客户问题出发，反向推导解决方案，而不是反过来。
大多数团队是正向推进：“我们有这项技术/能力/想法——能用它构建什么？”Working Backwards 则将其倒转：“客户有什么问题？理想解决方案应该是什么样？然后，我们如何构建它？”
其机制是：在构建任何东西之前，先写一份内部新闻稿和 FAQ。如果你写不出一份有说服力的新闻稿，你就没有一个有吸引力的产品。
正如 Jeff Bezos 所说：“我们把它当作一种信念——如果我们服务好客户，如果我们优先考虑客户并为他们交付，那么销售、收入和自由现金流之类的东西就会随之而来。”
何时使用
当你需要以下情况时，使用 Working Backwards：
- 在投入资源之前定义新产品或重大功能
- 评估相互竞争的产品想法，并选择要构建哪一个
- 让利益相关方就你正在构建什么以及为什么构建达成一致
- 迫使模糊的产品概念变得清晰
- 防止构建“先有方案再找问题”的解决方案
- 创建工程、设计和领导层都能围绕其团结起来的共同愿景
- 判断一个想法是否值得追求
何时不使用
- 工作是增量优化（A/B 测试、缺陷修复）
- 你正在执行一个已经定义好的产品
- 范围太小，不值得承担这套流程的开销
- 你只是在探索技术可行性（先做那个，然后再写 PR/FAQ）
模式
以下详细示例展示如何正确应用 Working Backwards。每个模式都展示一个常见错误和正确做法。
关键（这些做错，你就浪费时间了）
| 模式 | 它教什么 |
|---|---|
| solution-first-thinking | 不要从解决方案开始，再倒推一个问题 |
| missing-problem-paragraph | 如果你跳过问题，那可能根本不存在问题 |
| vague-customer-definition | “所有人”不是客户——要具体 |
| writing-pr-after-building | PR 要先写，而不是构建之后作为文档 |
| internal-jargon-in-pr | 新闻稿是给客户看的，不是给工程师看的 |
高影响
| 模式 | 它教什么 |
|---|---|
| faq-avoids-hard-questions | FAQ 必须处理让你不舒服的问题 |
| hyperbole-instead-of-specifics | 不要营销空话——使用数据和具体主张 |
| customer-quote-sounds-fake | 客户引语会揭示你是否理解这项任务 |
| too-many-features | 一份新闻稿，一个引人注目的收益 |
| no-measurable-outcome | 用数字定义成功是什么样 |
| combining-ideas | 一个想法一份 PR/FAQ——不要捆绑概念 |
中影响
| 模式 | 它教什么 |
|---|---|
| skipping-the-iteration | PR/FAQ 通过同心圆评审来改进 |
| missing-the-date | 假想的发布日期表明雄心和范围 |
| faq-too-short | 外部和内部 FAQ 服务于不同目的 |
深度阅读
仅在你需要额外细节时阅读。
- references/working-backwards-playbook.md：扩展的框架细节、检查清单和示例。
资源
书籍：
- Working Backwards，作者 Bill Carr 和 Colin Bryar——来自前亚马逊 VP 的权威指南
- The Everything Store，作者 Brad Stone——关于亚马逊文化和创新的背景
模板：
- Working Backwards PR/FAQ Template（可在 workingbackwards.com 获取）
播客：
- Bill Carr 在 Lenny's Podcast 上——深入探讨如何实施 Working Backwards
- Ian McAllister 在 Lenny's Podcast 上——该流程的实际应用
其他：
- Good to Great，作者 Jim Collins——影响了亚马逊关于飞轮和聚焦的思考
- The Lean Startup，作者 Eric Ries——验证想法的互补方法
致谢：Working Backwards 流程主要在 2004-2007 年间于亚马逊开发。关键贡献者包括 Jeff Bezos、Bill Carr、Colin Bryar、Jeff Wilke 以及许多其他人。本技能综合了 Bill Carr 和 Ian McAllister 在 Lenny's Podcast 访谈中的见解。