Working Backwards 的实践 - PR/FAQ 的写法与 Amazon 式产品开发流程
解析 Amazon 创造的 Working Backwards 流程的详细内容、PR/FAQ 文档的结构与写法、与 6-Pager 的使用区分以及引入自身项目的方法。
什么是 Working Backwards
Working Backwards 是 Amazon 在 2000 年代初期确立的产品开发流程。不以技术或商业便利为起点，而是首先定义理想的客户体验，从那里逆推明确应该构建什么。在 Jeff Bezos 的领导下，作为即使规模扩大也不降低创新质量的机制而诞生。这个流程的核心是名为 PR/FAQ 的文档。在写一行代码之前，先写产品完成时要发布的新闻稿和预想 FAQ，验证对客户是否真正有价值。
PR/FAQ 的结构与写法
PR（新闻稿）由 6 个要素构成。(1) 标题：用一句话表达对客户的价值。(2) 副标题：补充目标客户和主要收益。(3) 问题段落：具体描述客户当前面临的课题。(4) 解决方案段落：说明该产品如何解决该课题。(5) 客户之声：描述虚构客户的推荐评论，从客户视角表达价值。(6) 开始使用方法：展示客户立即开始的具体行动。FAQ 由外部 FAQ 和内部 FAQ 两部分构成。外部 FAQ 是客户视角的问题（使用方法、定价、限制、与现有服务的区别），内部 FAQ 是技术实现、成本、时间表、风险等内部关注事项。
叙事文化与 6-Pager 的使用区分
在 Amazon，会议中不使用 PowerPoint，而使用叙事（文章）形式的文档。项目符号式的幻灯片容易隐藏逻辑跳跃和模糊性，而用文章书写时作者可以深化思考，读者可以准确评估逻辑的一致性。会议开头设置所有参与者默读文档的时间，在所有人拥有相同信息的状态下开始讨论。PR/FAQ 和 6-Pager 用途不同。PR/FAQ 用于新产品或服务的提案，是验证尚不存在事物价值的文档。6-Pager 用于现有课题分析、战略提案、年度计划等，是理解现状和决定方针的文档。
在 AWS 服务中的应用案例
AWS 的许多主要服务都经历了 Working Backwards 流程开发。例如 S3 是从「开发者通过一个 API 就能使用可扩展存储」的客户体验逆推设计的。Lambda 诞生于「想要完全不管理服务器就能执行代码」的客户声音。这个流程不仅适用于新服务，也适用于现有服务的功能添加。将客户提出的需求以 PR/FAQ 形式整理并在团队内审查，在开发前判断是否真正对客户有价值。PR/FAQ 缺乏说服力的提案，无论技术上多么有趣都不会被批准。
引入自身项目
Working Backwards 不是 Amazon 特有的，任何组织都可以引入。第一步是为下一个要开发的功能或服务写 PR/FAQ。如果无法用一句话在标题中概括客户价值，该项目的目的可能不明确。如果无法在问题段落中具体描述客户课题，说明客户理解不足。如果无法在 FAQ 中回答技术可行性或成本，说明检讨不充分。写 PR/FAQ 本身就成为左右项目成败的重要思考过程。
总结
Working Backwards 是从客户体验逆推设计产品的 Amazon 式开发流程。通过 PR/FAQ 以新闻稿形式将假设文档化，在叙事文化中通过深入讨论打磨创意。将应用于 AWS 服务开发的方法引入自身项目，实现以客户为中心的产品开发。