原章：Working Backwards — Start with the Desired Customer Experience
2004 年，Bill Carr 被安排去建立 Amazon 的數位媒體事業。他一開始自然地把這件事理解成「再開一個新品類」：先研究市場、做商業分析，再把既有零售能力延伸到音樂、書籍與影片。但 Jeff Bezos 一次又一次把團隊拉回一個更基本的問題：顧客最後到底會看到什麼、感受到什麼？
Bill 的團隊先帶概念去開會，Jeff 問：「mock-ups 在哪裡？」團隊補了草圖後，仍然無法回答真正的顧客體驗；之後又試過試算表與投影片，也沒有讓討論變得更清楚。作者把這一段描寫成一連串「試了、失敗、再調整」的過程，而不是某一天突然發明出 Working Backwards。
團隊逐漸發現，最有效的方式是把產品想像成已經完成，先寫一份對外新聞稿，描述顧客會遇到的問題、產品會帶來什麼改變、為什麼值得使用。Kindle 成為最早真正用這種方式發展的重要產品之一。
之後新聞稿又加上 FAQ，形成 PR／FAQ。外部 FAQ 從顧客角度回答使用、價格與體驗；內部 FAQ 則逼團隊回答市場規模、單位經濟、損益、技術可行性、依賴關係、營運與法律問題。
| 故事節點 | 原本的做法 | 遇到的問題 | 逆向工作法的轉變 |
|---|---|---|---|
| 數位媒體初期 | 先研究公司能做什麼 | 提案仍然模糊，顧客體驗說不清楚 | 先描述顧客真正會得到什麼 |
| Mock-up 階段 | 用畫面把概念具象化 | 半成熟畫面仍可能掩蓋產品邏輯 | 用完整敘事逼迫團隊建立因果 |
| 新聞稿 | 從公司能力往前推產品 | 容易做出「我們做得到」但顧客不需要的東西 | 把產品想成已推出，再倒推要解決的問題 |
| PR／FAQ | 好點子先投入開發 | 真正的限制常在後期才出現 | 先把市場、經濟、依賴與可行性問題逼到前面 |
傳統產品開發很容易從公司現有技能開始：「我們會做什麼？可以把它賣給誰？」Working Backwards 故意把順序反過來：如果顧客問題真的值得解決，我們願不願意為它建立今天還沒有的能力？
這個順序也讓很多點子更早死掉。作者明確指出，在他們任職期間，多數 PR／FAQ 最後都沒有變成正式產品。這不是流程失敗，反而是流程的功能之一。
Amazon 要求團隊在投入大量工程資源以前，先回答幾個不舒服的問題：誰真的有這個問題？市場夠大嗎？顧客為什麼會改變行為？價格與成本是否成立？有哪些外部依賴？最難的技術問題是什麼？
PR／FAQ 逐漸成為 Amazon 發展新產品的重要機制，而且它不是「寫完就交差」的文件。作者特別提醒，這是一份活文件，會隨著研究、反駁與新資訊不斷修改。
真正的創新不是先證明自己的點子很棒，而是先讓點子接受最嚴格的顧客與現實檢驗。Working Backwards 的價值不只在「生出產品」，也在讓不值得做的產品更早被停止。