working-backwards

逆向工作法

什么是逆向工作法

逆向工作法是 Amazon 的产品开发方法论。其核心理念是：从客户问题出发，反向推导解决方案，而不是反过来。

大多数团队采用正向思路：“我们有这项技术／能力／想法——能用它做什么？”逆向工作法则反过来：“客户有什么问题？理想的解决方案应该是什么样？接下来，我们如何实现它？”

具体做法是：在着手构建任何东西之前，先撰写一份内部新闻稿和常见问题解答（FAQ）。如果你无法写出一份有说服力的新闻稿，就说明你的产品还不够有说服力。

正如 Jeff Bezos 所说：“我们把这一点视为坚定的信念——只要我们为客户提供优质服务、将客户放在首位并为他们创造价值，销售额、收入和自由现金流等指标自然会随之增长。”

适用场景

在以下情况下，使用逆向工作法：

• 在投入资源之前，定义新产品或重要功能
• 评估相互竞争的产品构想，并选择要开发的方案
• 让利益相关方达成共识，明确要开发什么以及为什么
• 厘清模糊的产品构想
• 避免为了寻找问题而构建解决方案
• 建立共同愿景，让工程、设计和管理团队都能围绕它协同
• 判断一个想法是否值得推进

不适用场景

• 工作属于渐进式优化（A/B 测试、修复 Bug）
• 你正在执行已定义好的产品计划
• 范围太小，不值得承担相应开销
• 你只是在探索技术可行性（先完成这一步，再撰写 PR/FAQ）

模式

详细示例展示如何正确应用逆向工作法。每种模式都会指出一种常见错误，并展示正确做法。

关键模式（搞错这些，你的时间就白费了）

模式	说明
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：更详尽的框架说明、检查清单和示例。

资源

书籍：

• Bill Carr 和 Colin Bryar 著《Working Backwards》——前 Amazon 副总裁撰写的权威指南
• Brad Stone 著《The Everything Store》——了解 Amazon 文化与创新的背景资料

模板：

• Working Backwards PR/FAQ 模板（可在 workingbackwards.com 获取）

播客：

• Bill Carr 做客 Lenny's Podcast——深入探讨如何实施 Working Backwards
• Ian McAllister 做客 Lenny's Podcast——流程的实际应用

其他：

• Jim Collins 著《Good to Great》——影响了 Amazon 对飞轮效应和专注的思考
• Eric Ries 著《The Lean Startup》——验证创意的互补方法

---

致谢：Working Backwards 流程由 Amazon 开发，主要是在 2004-2007 年间。主要贡献者包括 Jeff Bezos、Bill Carr、Colin Bryar、Jeff Wilke 等人。本技能总结了 Bill Carr 和 Ian McAllister 在 Lenny's Podcast 访谈中的见解。