亞馬遜 PR/FAQ：開發前，先檢驗產品承諾

前亞馬遜高層 Colin Bryar 與 Bill Carr 將 Working Backwards 描述為先明確期望的顧客體驗，再決定開發甚麼。他們的回顧把此方法與2004年以來的主要項目聯繫起來，並提到2005年數碼媒體及網絡服務業務中的探索。核心文件結合擬寫的新聞稿，以及顧客和交付可行性的問題。^[1]

作者描述的是反覆討論、未解問題和修訂，而非一次推介便獲批准。^[1] 在另一篇亞馬遜訪談中，Jeff Wilke 表示，批准新產品資源前會先看一份紮實的 PR/FAQ，再先為小團隊提供資源。^[2] 這些是管理實踐的敘述，並非財務效果的對照實驗。

資料不能證明所有項目都遵循完全相同的次序、文件前沒有任何探索程式碼，或這種格式本身促成 Kindle 與 AWS 成功。規劃文件中的假想顧客引語只是設想的結果，不是真實評價，不能當成已觀察到的顧客證據。^[1]

分析與借鑑

精美的發布稿同樣可能掩蓋未知。我們建議為每項擬定收益配上所依賴的假設、驗證方法與失敗條件，分開評估需求、交付可行性及可持續成本。收益聽來吸引，不代表產品在技術或經濟上可行。寫作應揭露缺口，而非製造信心。

分析與借鑑

1. 明確一類顧客、現有替代方案及其問題。
2. 寫下一項具體的擬定收益，不虛構使用量、評價或效能。
3. 列出實現收益的必要條件：行為、技術、服務能力與成本。
4. 為每項假設記錄現有證據、下一項測試、負責人和決策門檻。
5. 證據與設想矛盾時修改、測試或停止，並保留被否定的版本與原因。這是我們的應用框架，並非複製亞馬遜內部範本。