---
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
**问：哪些客户会最先用？**
答：
**问：他们最喜欢什么？最失望的是什么？**
答：
**问：为什么上线范围划在这里？**
答：
**问：为什么比现有替代方案好？**
答：
**问：定价该怎么考虑？**
答：
**问：为什么做这些架构选择？**
答：
**问：要花多少钱、谁来做、要多久？**
答：
**问：风险最大的假设是什么？**
答：

## 会让它做不成的问题
| 问题 | 怎样能解决 | 现在能解决吗？ |
|---|---|---|

## 客户相关说法背后的证据
| 说法 | 证据 | 缺口 |
|---|---|---|

## 评审安排
先默读；职位最高的人最后发言。下一稿时间：[日期]。

## 使用的原则
[编号，附来源]
```

## 示例

**输入：**“我们是一家给餐馆做账的小型代账公司。我们写了一个脚本，能从邮件里读取供应商发票。想法：把它做成应用卖出去，让餐馆老板每周看到每道菜的食材成本。老板们说，他们只有到月底才从我们这里知道食材成本。40 家客户里有 6 家在问卷里说‘可能’会付费。还没定价。”

**输出（节选）：**

```markdown
以下是杰夫·贝索斯公开阐述的原则。本文与杰夫·贝索斯及其公司无关联，也未获得其认可或背书。内部文档，不对外发布。

## 新闻稿
**盘算：让餐馆老板看到这周每道菜花了多少成本**
*面向只能到月底才知道食材成本的独立餐馆*

[城市]，[待确认：上线日期]——盘算在供应商发票通过邮件送达时自动读取，每周一显示菜单上每道菜上周的制作成本。

现在，老板们一个月才从代账会计那里看到一次食材成本，那时供应商涨价已经过去好几周了……

“[关于当周就看到涨价的示意引语]，”[虚构的创始人，盘算] 说。

## “那又怎样？”测试
客户现在用的：代账会计的月末报告 · 更好在于：从每月变成每周，从总数变成按菜计算 [待确认：老板会根据每周数字采取行动吗？] · 结论：如果老板会根据每周数据调整菜单或进货，就通过；目前还没有证据

## 内部 FAQ
**问：哪些客户会最先用？**
答：我们现有的餐馆客户，他们已经把发票发给我们了。[待确认：有多少家把每道菜的配方写下来了]
**问：最失望的是什么？**
答：没有书面配方的菜，在有人录入配方之前算不出单菜成本。
**问：定价该怎么考虑？**
答：[待确认：价格] 问卷（40 家里 6 家说“可能”）只是替代指标；去和这 6 家谈谈，如果有了每周成本，他们会停止做哪些事。

## 会让它做不成的问题
| 问题 | 怎样能解决 | 现在能解决吗？ |
|---|---|---|
| 大多数客户没有单菜配方 | 先从每家餐馆卖得最好的几道菜开始，和老板一起录入 | 能，但要手工做 |
| 脚本是给我们自己的员工写的，不是给老板用的 | 在做应用之前，先发一封更简单的每周邮件 | 能 |
```

## 发送前检查

- [ ] 输出里有出处说明和无关联声明，并标明为内部文档。
- [ ] 先写明客户和需求，再写产品。
- [ ] 新闻稿不超过一页，没有内部术语。
- [ ] 新闻稿里的引语都标明为示意，且只来自虚构人物。
- [ ] “那又怎样？”测试有结论，“暂未通过”的结论直接写明。
- [ ] 内部 FAQ 回答了 2024 年那封信里的问题，或标为 [待确认]。
- [ ] 没有编造价格、日期或客户数量。
- [ ] 关于客户的说法都附了证据；只靠问卷的说法已标出。

## 常见错误

- 新闻稿写技术（发票怎么解析），而不是写客户那边有什么改变。
- 把 PR/FAQ 当成上线公告，跳过内部 FAQ，而难题恰恰在那里。
- 文档冗长、附录一堆，回避决定什么才重要。
- 把问卷百分比当成客户想要的证据。
- 把没获批准的 PR/FAQ 当成白费功夫。