它是怎么回事？
亚马逊从客户倒推的方法常使用新闻稿与常见问题稿PRFAQ，让团队在开发前说明目标客户、问题、收益与疑问。它是需求澄清工具，不是编造成功宣传。
与「第一性原理」相连时，本条先处理“锁定客户”，再用“验证需求”收束；重建基础后，用客户倒推验证新组合是否服务真实需求。
本文为学习性整理，案例与实践步骤为编辑转化。
为什么会起作用？
- 01
先描述客户完成任务后的真实体验，再倒推产品与能力。新闻稿不是宣传口号，FAQ 要回应最难的问题：谁需要、为何更好、代价是什么、交付依赖什么。
- 02
对象与边界：先写清客户将得到什么，再决定要做什么。使用前要先确认“团队热衷功能清单，却无法说明客户为何需要时。”，避免把相似现象直接套入模型。
- 03
转换路径：从“锁定客户”形成客户任务，再经过“回答难题”推进到关键FAQ；中间的事实、假设和判断应分别记录。
有参考链接；引文与版本定位另行标注
原理论与本站实践模板的证据应分别理解
它从哪里来？
Working Backwards 与 PRFAQ 是亚马逊发展和使用的产品工作方法，贝索斯为重要实践关联人物。
本站依据「Working Backwards 方法」记录当前来源线索，并把历史概念转成可填写的实践流程。参考资料，所以来源归属与实际效果分开判断。
与本模型直接相关的中文要义是：先写清客户将得到什么，再决定要做什么。先描述客户完成任务后的真实体验，再倒推产品与能力。新闻稿不是宣传口号，FAQ 要回应最难的问题：谁需要、为何更好、代价是什么、交付依赖什么。 所列资料定位在「Working Backwards 方法」的“原资料或参考文章；章节与纸本页码尚未逐项核实”；当前状态为“参考资料”，因此摘要用于理解原义，不能替代引文校勘或效果验证。
查看来源 ↗一句值得带走的话
先写清客户将得到什么，再决定要做什么。
编辑提炼，非人物原话
什么时候用？
团队热衷功能清单，却无法说明客户为何需要时。
用适合这个模型的步骤，慢慢想清楚。
- 01
锁定客户
哪类客户在什么情境遇到什么阻碍？
输入：本次具体问题、当前情境与已知资料
本步产出：客户任务
客户任务中，已知事实与待核实的判断是否分开记录？
- 02
写出变化
产品让客户取得什么可观察进展？
输入：前一步的客户任务，以及本步需要补查的资料
本步产出：结果陈述
结果陈述能追溯到直接资料吗？同源转述不能当作独立证据。
- 03
回答难题
为什么现有替代方案不够，成本与风险是什么？
输入：前一步的结果陈述，以及本步需要补查的资料
本步产出：关键FAQ
关键FAQ是否使用同一时间范围、对象和口径？如果交换方案顺序，判断会改变吗？
- 04
倒推能力
交付这一体验需要哪些能力？
输入：前一步的关键FAQ，以及本步需要补查的资料
本步产出：能力清单
能力清单中，已知事实与待核实的判断是否分开记录？
- 05
验证需求
哪个客户行为能验证需求？
输入：前一步的能力清单，以及本步需要补查的资料
本步产出：验证计划
回看失效条件：漂亮新闻稿不是需求证据，客户也可能无法准确表达潜在需求。这次实践是否仍有这一风险？
把道理放回真实情景。
开发报表前，先写客户怎样用它减少对账等待，再验证数据是否足够支撑这种体验。 起草面向客户的结果说明，再用 FAQ 追问为什么现在需要、替代方案是什么、成功如何观察。若只能写功能列表而写不出客户进展，就返回问题定义。
计划学习一门工具前，先描述学会后将独立完成哪件任务。 安排一次家庭活动时先描述参与者最终希望获得的体验，再倒推时间、路线和分工，避免先定行程再让所有人迁就。 实际使用时先按“锁定客户”保存基线，再记录“验证需求”得到的结果；若结果没有改变，应回看漂亮新闻稿不是需求证据，客户也可能无法准确表达潜在需求。
也要知道它的边界。
漂亮新闻稿不是需求证据，客户也可能无法准确表达潜在需求。
反例与失效情形
写出令人兴奋的发布稿却没有验证客户的问题，仍可能开发无人使用的功能。
慢下来，把问题想清楚。
先独立作答，再让 AI 检查。每个问题是一份独立实践，可以停下来，下次继续。
正在读取私人记录…