Amazon 的产品开发方法：在写一行代码之前，先为假想中已发布的产品写一篇新闻发布稿和常见问题解答。如果你无法清晰地写出客户价值，那就不值得动手建。
大多数产品团队从一个功能想法或技术能力出发，然后向前工作——寻找理由来证明它的合理性。Amazon 的反向工作法彻底颠覆了这个顺序。
你要先写出已完成产品的发布公告——就好像它已经存在，用户已经喜爱它一样。如果你写不出一篇令人信服的新闻发布稿，你就没有一个值得构建的产品。这个方法强迫团队在投入任何资源之前，先清晰地回答：我们在为谁解决什么问题？这个问题的答案有多大价值？
这不是文字游戏，而是一种思维纪律。写新闻稿的过程会暴露所有模糊不清的假设，逼迫你提前面对那些「先建再说」方式里会被推迟的艰难决策。
反向工作法的核心产出只有两份文档。它们不是用来对外发布的，而是用来迫使内部团队把模糊的想法变成具体的、可检验的承诺。
客户会问的问题——从购买决策的角度出发
工程/运营团队会问——技术可行性与成本
核心规则：不断修改新闻稿直到它令人信服。如果你们团队开完一次会议就觉得「这稿子已经足够好了」，几乎可以肯定它还不够好。反向工作法要求 5–10 轮修改是常态——每一轮修改都在消灭一个模糊假设。
反向工作法在需要从零定义产品价值、或者对齐多方对「我们在做什么」理解时最有效。它不是日常迭代工具，而是大方向决策时的思维纪律。
Kindle 是反向工作法最经典的案例，由前亚马逊副总裁 Colin Bryar 和 Bill Carr 在《Working Backwards》一书中详细记录。2006 年，Jeff Bezos 宣布每项重大产品计划都必须从一篇新闻稿开始。Kindle 团队在硬件设计开始之前，就已经写好了他们的新闻发布稿。
"Amazon Launches Revolutionary Portable Reading Device — Kindle: Read Books, Magazines, Newspapers Wirelessly"
这个标题里的每一个词都成为了一个硬性技术或商业要求。
产品旅程
如果没有反向工作法，Kindle 团队可能会先设计出漂亮的硬件，然后在快要发布时才发现——出版商不肯授权，运营商收费太高，「任意一本书、60 秒内」的承诺根本无法兑现。反向工作法迫使他们提前 3 年面对这些问题，并系统性地解决它们。
这个方法看起来简单，但执行中有几个关键陷阱。以下是让它真正发挥作用的实践要点。
反向工作法是亚马逊独特的产品开发方法论，由杰夫·贝索斯在亚马逊内部推行，要求产品团队在开始任何开发工作前，先撰写一份面向客户的"假想新闻稿"与FAQ文档。这一实践在亚马逊内部沿用十余年后，随着2021年《反向工作法》一书的出版正式进入公众视野，成为全球产品团队理解"以终为始"产品思维的经典案例。