---
name: bezos-style-pr-faq
description: 在動手開發之前，為產品、功能或服務起草或審閱一份內部的逆向工作法 PR/FAQ：一頁從客戶角度寫的新聞稿、一份回答客戶與內部難題的 FAQ、一次「那又怎樣？」（so what）測試，以及一份會讓它做不成的問題清單。依據的是傑夫·貝佐斯（Jeff Bezos）在亞馬遜致股東信中公開說明的逆向工作（working backwards）思維，以及亞馬遜介紹的 PR/FAQ 格式。有人提出產品點子、功能提案或新服務，想要一份 PR/FAQ、逆向工作文件、未來的新聞稿，或想在團隊開工前判斷這個點子值不值得做時使用。
---

# 貝佐斯式逆向工作法 PR/FAQ

以下是傑夫·貝佐斯在亞馬遜致股東信中公開說明的原則（2008 年的信談從客戶需求逆向工作，2016 年的信談抗拒代理指標），再加上亞馬遜在 2024 年致股東信（安迪·賈西執筆）中介紹的 PR/FAQ 格式，以及亞馬遜官網刊出的 Colin Bryar 與 Bill Carr 合著《Working Backwards》（繁中版《亞馬遜逆向工作法》）節錄。本技能與傑夫·貝佐斯及其公司沒有任何關聯，也未獲其認可或背書。這個技能把一個點子寫成開發前的內部新聞稿與 FAQ，或審閱一份現成的草稿，並直接指出這個點子在哪裡過不了「那又怎樣？」測試。

## 基本規則

- 不要把所列來源以外的引言或觀點歸給傑夫·貝佐斯。
- 不要扮演、模仿傑夫·貝佐斯，也不要用他的口吻寫作；只用下面的原則檢視使用者的資料。
- 這是內部的思考文件，不是發給記者的新聞稿。要對媒體發布的新聞稿，請用 press-release-draft。
- 絕不捏造客戶證據、價格、日期或數字。使用者沒提供的內容一律寫成 [待確認：…]。
- 出處要分清楚：2008 年和 2016 年的信是貝佐斯寫的；PR/FAQ 的篇幅上限和審閱做法出自 Bryar 與 Carr 的節錄；「開始寫程式之前」（before we start coding）的做法和 FAQ 難題清單出自 2024 年的信。
- 點子過不了「那又怎樣？」測試，就直說。一份最後建議「先不要做」的 PR/FAQ 是好結果。

## 原則

1. **從客戶需求往回推，而不是從自己的能力往前推。** 貝佐斯把「從客戶需求逆向工作」和「從能力出發」的做法對照：後者問的是，公司憑已經擅長的事還能做什麼。只靠從能力出發，公司永遠不會被逼著去培養新能力；逆向工作則常常會。來源：2008 年致股東信（Kindle 的例子）。
2. **開發之前先寫新聞稿和 FAQ。** 亞馬遜在開始為一項服務或功能寫程式之前，會先寫新聞稿和 FAQ。新聞稿檢驗這個提案對客戶來說是否夠出色；FAQ 逼人面對難題。來源：亞馬遜 2024 年致股東信，「Working backwards documents」一節。
3. **新聞稿要撐得過「那又怎樣？」。** 審閱 PR 的主管常會問「那又怎樣？」（so what?）。如果新聞稿描述的東西沒有比客戶現有的選擇明顯更好（更快、更簡單、更便宜），也沒有讓客戶體驗出現質的躍升，那就不值得做。來源：亞馬遜官網上的 Bryar 與 Carr 節錄。
4. **FAQ 要講清楚客戶體驗和成本。** FAQ 寫出客戶體驗的細節，並冷靜評估這個產品做起來有多貴、多難。2024 年的信列出問題的類型：哪些客戶會用、他們最喜歡什麼、最失望的是什麼、上線範圍為什麼畫在這裡、為什麼比現有替代方案好、定價怎麼想、架構為什麼這樣選。來源：Bryar 與 Carr 節錄；2024 年致股東信。
5. **刻意寫短。** 新聞稿只有幾段，一定不超過一頁；FAQ 五頁以內。篇幅上限是逼人提煉思考的機制，不是用來報告所有做過的工作。來源：Bryar 與 Carr 節錄。
6. **靠閱讀來審閱、反覆修改，並預期多數不會上線。** 審閱時，大家先默讀文件；職位最高的人通常最後發言。草稿要改很多輪。大多數 PR/FAQ 永遠不會變成產品，作者認為這是優點：它把開發資源留給最好的點子。來源：Bryar 與 Carr 節錄。
7. **別讓問卷代替客戶。** 貝佐斯提醒，市場調查和問卷可能變成客戶的代理指標。產品負責人必須了解客戶、有願景、熱愛自己的產品；調查再用來找出盲點。來源：2016 年致股東信，「Resist Proxies」一節。

## 適用情境

- 一個產品點子、功能、新服務或內部工具即將拿到人力或預算。
- 團隊對自己做得出來的東西很興奮，卻沒人寫下它是給誰用的。
- 想把幾個點子放在同一頁上比較，再挑一個。
- 審閱別人寫的 PR/FAQ。
- 不適用於發給記者的新聞稿（用 press-release-draft）、不適用於在既有選項之間做決定（用 decision-memo），也不適用於完整的需求文件（PR/FAQ 通過後用 prd-from-notes）。

## 需要準備

- 用幾句話說明這個點子，以及它是給誰的。
- 這些客戶現在用什麼代替，哪裡讓他們困擾。
- 手上的任何證據：訪談、客服工單、使用資料、丟掉的案子。
- 已知的限制：預算、團隊、截止日期、相依項目、法規。
- 大致的價格或商業模式（如果有）。

## 步驟

1. **寫出客戶和需求（原則 1）。** 一句話：客戶是誰、有什麼需求，使用者有客戶原話就用原話。如果點子是從團隊已經擅長的事出發，而不是從客戶出發，就直說，先找出客戶需求，或標成 [待確認：是哪個客戶提出這個需求]。
2. **寫標題和副標題。** 標題寫出產品名稱，以及客戶那邊會有什麼改變。副標題用一句話說明是給誰的、主要好處是什麼。不用內部術語。
3. **寫新聞稿內文（原則 2、5）。** 不超過一頁：客戶感受到的問題、解決方案、從客戶角度看怎麼用、一句虛構的公司發言人引言和一句虛構的客戶引言（都標明是示意，絕不用真人），以及怎麼開始使用。使用者沒提供的日期和價格保留為 [待確認：…]。
4. **做「那又怎樣？」測試（原則 3）。** 和客戶現在用的東西比。它是否明顯更快、更簡單或更便宜，或帶來質的躍升？用一行寫出答案。如果答案是否，就停在這裡，在寫 FAQ 之前先把這點講出來。
5. **寫客戶 FAQ（原則 4）。** 客戶會問的問題：要花多少錢、和替代方案差在哪、有什麼做不到、他們的資料會怎樣、怎麼停用。
6. **寫內部 FAQ（原則 4）。** 回答 2024 年那封信的問題，或標成 [待確認]：哪些客戶、他們最喜歡什麼、什麼會讓他們失望、上線範圍為什麼畫在這裡、為什麼比替代方案好、定價、架構選擇。再補上成本、團隊、時程、相依項目和風險最高的假設。
7. **列出會讓它做不成的問題（原則 6）。** FAQ 挖出來的未解問題，每一項都寫上什麼能解決（更多時間、一個合作夥伴、更便宜的技術、更小的第一版），或註明目前無法解決。
8. **檢查證據（原則 7）。** 每一則關於客戶想要什麼的說法，都註明證據。如果唯一的證據是問卷平均值，寫出還缺哪些對客戶的直接了解。
9. **準備審閱。** 建議先讀後評：審閱者先默讀，再提意見，職位最高的人最後說。註明版本號；預期還會有更多版草稿。

## 輸出格式

```markdown
# PR/FAQ：[產品名稱]（第 [n] 版草稿，[日期]）
以下是傑夫·貝佐斯公開說明的原則。本文件與傑夫·貝佐斯及其公司沒有任何關聯，也未獲其認可或背書。內部文件，不對外發布。

## 新聞稿
**[標題]**
*[副標題：給誰用、主要好處]*

[城市]，[待確認：上線日期]——[第 1 段：推出什麼、給誰用]

[第 2 段：客戶感受到的問題]

[第 3 段：解決方案，以及從客戶角度看怎麼用]

「[示意引言]，」[虛構的發言人，職稱] 說。

「[示意引言]，」[虛構的客戶，身分] 說。

[怎麼開始使用，已知的話寫價格]

## 「那又怎樣？」測試
客戶現在用的：[替代方案] · 好在哪裡：[更快／更簡單／更便宜／質的躍升，附證據] · 結論：通過／尚未通過

## 客戶 FAQ
**問：[問題]**
答：[回答]

## 內部 FAQ
**問：哪些客戶會最先使用？**
答：
**問：他們最喜歡什麼？最失望的是什麼？**
答：
**問：上線範圍為什麼畫在這裡？**
答：
**問：為什麼比現有替代方案好？**
答：
**問：定價該怎麼想？**
答：
**問：為什麼做這些架構選擇？**
答：
**問：要花多少錢、誰來做、要多久？**
答：
**問：風險最高的假設是什麼？**
答：

## 會讓它做不成的問題
| 問題 | 什麼能解決 | 現在能解決嗎？ |
|---|---|---|

## 客戶相關說法背後的證據
| 說法 | 證據 | 缺口 |
|---|---|---|

## 審閱安排
先默讀；職位最高的人最後發言。下一版草稿：[日期]。

## 使用的原則
[編號，附來源]
```

## 範例

**輸入：**「我們是一家專做餐廳帳務的小型記帳事務所。我們寫了一支腳本，能從電子郵件讀取供應商的發票。點子：把它做成 App 來賣，讓餐廳老闆每週看到每道菜的食材成本。老闆們說，他們要到月底才從我們這裡知道食材成本。40 家客戶裡有 6 家在問卷中說『應該會』付費。還沒定價。」

**輸出（節錄）：**

```markdown
以下是傑夫·貝佐斯公開說明的原則。本文件與傑夫·貝佐斯及其公司沒有任何關聯，也未獲其認可或背書。內部文件，不對外發布。

## 新聞稿
**「盤算」讓餐廳老闆看到每道菜這週花了多少成本**
*給要到月底才知道食材成本的獨立餐廳*

[城市]，[待確認：上線日期]——「盤算」會在供應商發票透過電子郵件寄到時自動讀取，每週一顯示菜單上每道菜上週的製作成本。

現在，老闆們一個月才從記帳士那裡看到一次食材成本，那時供應商漲價已經是好幾週前的事了……

「[關於當週就看到漲價的示意引言]，」[虛構的創辦人，盤算] 說。

## 「那又怎樣？」測試
客戶現在用的：記帳士的月底報表 · 好在哪裡：從每月變成每週，從總數變成每道菜 [待確認：老闆會根據每週數字採取行動嗎？] · 結論：如果老闆會根據每週資料調整菜單或進貨，就通過；目前還沒有證據

## 內部 FAQ
**問：哪些客戶會最先使用？**
答：我們現有的餐廳客戶，他們本來就把發票寄給我們。[待確認：有幾家把每道菜的食譜寫下來了]
**問：最失望的是什麼？**
答：沒有書面食譜的菜，在有人輸入食譜之前算不出單道菜的成本。
**問：定價該怎麼想？**
答：[待確認：價格] 問卷（40 家裡 6 家說「應該會」）只是代理指標；去和這 6 家聊聊，如果有了每週成本，他們會不再做哪些事。

## 會讓它做不成的問題
| 問題 | 什麼能解決 | 現在能解決嗎？ |
|---|---|---|
| 大多數客戶沒有每道菜的食譜 | 先從每家餐廳最暢銷的幾道菜開始，和老闆一起輸入 | 能，但要手動 |
| 腳本是寫給我們自己員工用的，不是給老闆用的 | 做 App 之前，先寄一封更簡單的每週電子郵件 | 能 |
```

## 寄出前檢查

- [ ] 輸出裡有出處說明和無關聯聲明，並標明為內部文件。
- [ ] 先寫出客戶和需求，再寫產品。
- [ ] 新聞稿不超過一頁，沒有內部術語。
- [ ] 新聞稿裡的引言都標明是示意，而且只來自虛構人物。
- [ ] 「那又怎樣？」測試有結論，「尚未通過」的結論直接寫明。
- [ ] 內部 FAQ 回答了 2024 年那封信的問題，或標成 [待確認]。
- [ ] 沒有捏造價格、日期或客戶數量。
- [ ] 關於客戶的說法都附上證據；只靠問卷的說法已標出。

## 常見錯誤

- 新聞稿寫技術（發票怎麼解析），而不是寫客戶那邊有什麼改變。
- 把 PR/FAQ 當成上線公告，跳過內部 FAQ，而難題正好在那裡。
- 文件冗長、附錄一大堆，迴避決定什麼才重要。
- 把問卷百分比當成客戶想要的證明。
- 把沒通過的 PR/FAQ 當成白做工。