亚马逊在写代码之前先写新闻稿，以构建客户想要的产品

到2000年代初，亚马逊用标准的公司工具包评估新产品创意：市场规模、SWOT分析、竞争对比和财务预测。这些文件都是为内部评审写的——它们向高管和财务部门证明商业案例，而不是向客户证明——亚马逊不断批准那些满足所有内部检查项、但推出后仍是平庸产品、解决不了任何实际客户问题的项目，因为审批过程中没有任何环节迫使人们具体说明客户实际上会体验到什么。

自然的解决办法是在同样的前瞻性规划文件中增加一个'客户利益'部分，与市场规模和损益表并列。贝索斯更进一步：他不是描述产品计划并附上客户摘要，而是让团队在存在任何规格、路线图或人头需求之前，先写出成品、成功产品的外部公告——即记者真正会读到的新闻稿——然后从这个公告倒推，理解需要什么事情成真才能实现它。

颠倒顺序：先写对外新闻稿，这样之后每个决策都必须对照一个已经被告知产品可行的客户来证明自己。

新闻稿不能躲在术语或预测后面，能及早暴露薄弱的价值主张。

从公告倒推迫使最难的客户问题首先得到回答。

领导层对PR/FAQ的审查在投入工程资源之前就淘汰了糟糕的想法。

在构建之前，先写成品的外部公告；如果你不能诚实写出来，就不要构建。

PR/FAQ成为Kindle和AWS等重大发布的门槛，贝索斯和杰西在2006年发布前花了超过一年时间打磨。‘逆向工作法’从亚马逊内部实践传播为广泛教授的产品管理方法论，前亚马逊高管科林·布里亚尔和比尔·卡尔公开记录后，PR/FAQ格式现在被电子商务以外许多公司的产品团队用作在工程开始前推动以客户为先思考的强制功能。