PRD 先是说服文档, 然后才是规格书
PRD 是 Product Requirements Document 的缩写，即产品需求文档: 写清要做什么、为什么做，让工程师、设计师和相关方看到同一张图。新手最常见的误解就在这里，把 PRD 当成功能规格书，上来就填页面和按钮清单。
拿到一份只有功能清单的文档，工程师只会做两件事之一: 照单实现、遇到怪地方就来回追问，或者用自己的理解填空。哪种都会让会议变多。好的 PRD 恰恰相反，它说服读者: 这个问题是真的，这个方向是对的，范围到这里为止。被说服的工程师不会追问你的意思，而是提出更好的实现。
文档的一半是问题定义
具体写清: 谁、在什么场景下、多久遇到一次这个问题。有数据就附数字，没有就附用户访谈、客服工单这类证据。问题定义含糊的功能，在优先级会议上一旦开始被挤，就再没有守住的办法。
写问题的时候觉得证据单薄，那不是文档的问题，是规划的问题，而 PRD 恰好在上线前把它暴露了出来。不管是补证据还是换方向，成本最低的时机都在写代码之前。
写下不做什么, 会就少开了
写明刻意排除在范围外的 non-goals 一节，在谷歌工程师的设计文档里几乎是标准做法。把那些读者合理期待、但这一轮决定不做的事钉在文档里，比如: 这次搜索改进不涉及错别字纠正。
没有这一节，同样的争论会贯穿整个开发过程，每次有人问这个是不是也该支持，都得从头解释一遍。决定和理由都写在文档里，一个链接就能了结。这是阻止范围一点点膨胀的最便宜的装置。
需求要写成可验证的句子
需求句子的标准只有一条: 第三方能不能判定它做没做完。改善、让它更方便这类动词无法判定，所以那不是需求，是愿望。
成功指标要在上线前定
上线后再挑指标，挑到的一定是恰好在涨的那个。所以成功指标要在动工前写好，连目标数值和测量方式一起: 比如上线四周后购物车放弃率从 60% 降到 45% 以下算成功。
指标提前定好，上线就不是终点而是实验的起点。没达标的结果也会留下数据，告诉你哪个假设错了，下一份 PRD 的问题定义会因此更扎实。
一页纸的骨架
格式因团队而异，但要回答的问题是一样的。有了下面五节，一页纸也能顶一份 PRD。
| 小节 | 要回答的问题 |
|---|---|
| 背景与问题 | 谁在什么场景下因为什么而受阻 |
| 目标与指标 | 用哪个数字确认成功 |
| 不做什么 | 哪些事合理期待但这次不在范围内 |
| 需求 | 用可判定完成与否的句子写清做什么 |
| 待定问题 | 还没定的是什么, 由谁在什么时候定 |
一直改到上线的文档
PRD 不是写完签字就完事的文档，而是一路更新到上线的工作文档。开发中需求变了，先改文档，并记下改动日期和原因。文档和实际在做的东西一旦脱节，PRD 就成了没人打开的文件。
写完后先拿给最忙的那位工程师看，问问读到哪里卡住了。有疑问的地方就是文档的洞。把洞补上再全员共享，启动会就不再是宣讲会，而是讨论会。
常见问题
PRD 和产品策划案有什么区别?
很多时候只是叫法不同，是同一样东西。真正要区分的是页面设计稿: PRD 讲做什么、为什么做，页面设计稿讲长什么样。只靠没有为什么的设计稿开工，实现过程中的每个判断都会变成回头来问你的问题。
PRD 要写多长?
有问题、指标、范围、需求、待定问题这五样，一页也是 PRD; 缺了这五个答案，十页也不够格。页面细节、数据定义这类会写长的内容放进附录或链接文档，正文短，才会被读。
敏捷团队也需要 PRD 吗?
不是让你每个冲刺 (1-2 周的开发周期) 都写厚文档。待办清单 (backlog) 里的单个条目，用用户故事这种从用户视角写的一行需求就够了; 但横跨多个周期的功能块，需要一份承载为什么和范围的文档。没有它，谁也说不清那些故事碎片最终拼向哪里。