上一篇结尾留了一句话：写完一张用户故事卡片之后，最该问团队的不是“写得清楚吗”，而是“哪里不对”。真做下去，很快会撞上下一个问题：卡片一次只讲一件事，那围绕整件事的背景——为什么要做、做多大、不做什么、怎么算成功——放在哪里？

通常的答案是 PRD（Product Requirements Document，产品需求文档）。但这个词带给新人的困惑比答案多：有人说它是产品经理最重要的产出，有人说它早该扔了。这两种说法可以同时成立，因为它们说的不是同一件事。

这篇回答的是：问题已经想清楚了，一份 PRD 该把什么落到纸面上，什么不该由产品经理写进去，以及它和用户故事、功能清单差在哪里。

一条判据：写下来的是成品上看不出来的东西

先给判据，再给清单：

产品做出来以后，从成品本身看不出来的决定，才值得写下来；能从成品看出来的，不必重抄一遍。

文档的作用是承载会随人走、随时间蒸发的东西。功能上线三个月后，没人能从界面上读出当初是为谁解决什么问题，负责的人也早换了；这类信息只能靠文字留下。反过来，界面上明摆着的东西，写进文档只会让人多读一遍。

按这条判据过一遍：

  • 为什么做。 从成品和代码里都反推不出来。
  • 明确不做什么。 最容易蒸发，因为它在成品上完全不可见：你只能看到做了的，看不到被主动放弃的。
  • 怎么算成功，基线是多少。 界面显示不出“转化率从 40% 涨到 55%”，更显示不出 40% 是起点。
  • 边缘情况和失败路径当时怎么定的。 做出来或许能反推结果，但“为什么这样处理”通常反推不出来。

反过来，功能清单（功能做出来，界面上就写着它是什么）、技术实现方式（代码里全都有）、视觉和交互细节（原型里全都有），都不必写。

这条判据顺手解释了另一件常被搞混的事：功能清单和 PRD 不是同一种东西的长短两版，而是两种东西。

一份最小可用的 PRD 长什么样

接着上一篇那张连锁餐饮的卡片往下写。你已经确认了问题：店长每周一早上要拿上周全部门店的关键经营数据向区域经理汇报，现在得在三个页面之间来回抄。围绕这张卡片，一页纸的 PRD 大致含这几块。

问题与证据。 一段话说清谁在什么时候遇到什么麻烦，以及你怎么知道它是真的：访谈过几个店长、客服工单里有没有相关抱怨、每周实际花多少时间在这件事上。

目标与非目标。 目标是可衡量的结果，不是功能。“把周一早上的数据准备时间从大约 40 分钟降到 5 分钟以内”是目标，“做一个导出按钮”是功能。非目标是这一版明确不做的事，比如不做定时自动推送、不做移动端适配。把不做什么写下来，相当于给范围装了一道闸门：后面有人中途加需求时，你不是在说“不”，而是指回整队人早就同意过的那个决定35。

范围与验收标准。 这一版包含哪些能力，以及每一条怎么算做完。上一篇的 Given-When-Then 放在这里，另外补上失败路径：如果上周数据只入库了一半，页面显示什么？一个区域下面有 60 家门店，表格怎么处理？这些是工程和测试最需要、又最不可能替你猜的地方。

成功指标与观察窗口。 一到三个数字，带上基线和上线后观察多久。没有基线，上线之后没人能判断它到底有没有用。

依赖、风险、未决问题。 这件事依赖上周数据在周一几点前入库，最大的风险是数据延迟。还没定下来的问题要写清谁负责、什么时候给答案，否则它们会一直躺在那儿。

可以看出，这几块没有一块是在描述界面。

哪些不该由产品经理写

前面“技术实现、视觉细节不用写”背后，是一个更一般的原则：谁手里有信息，谁定这件事；PRD 只记录需要跨角色对齐的决定。

技术方案（工程侧的 tech spec）由工程定，因为他们最清楚现有系统扛不扛得住；视觉与交互由设计定；工期由团队一起估。产品经理不该替他们把这些定死，一是你真没有那个信息，二是一旦写死，本来该被讨论的地方就不再被讨论了——这和上一篇讲的“卡片写得越像功能清单，讨论结束得越早”是同一个毛病16。

那产品经理必须定的是什么？只有一小类：做什么、不做什么、先做什么、什么算成功。 这几件事没有别的角色能替你定，也没有别的文档能替你承载。

Marty Cagan 提醒过一条边界：PRD 本身不坏，坏的是用它 替代 产品探索，而不是在探索之后把细节落下来1。如果还没验证过用户会不会用、技术上做不做得出来，一份写满需求的 PRD 只是把猜测包装成了既定事实。他还说过一句很准的话：PRD 一旦真的写出来，这份文档自有一种引力，人们不太会再去质疑里面的“需求”，而是默认它们已经成立1。

它和用户故事、功能清单不是同一样东西

功能清单 是一串已经选定的方案。问题不在错，而在于它把“做什么”和“为什么做”压成一行行没有来由的条目，别人无法判断哪一条可以换、哪一条不能动。

用户故事卡片 是故意写得含糊的占位符，一次一张，用来开启对话。含糊是它的设计意图，代价是把一堆卡片堆在一起，你仍然看不到整件事的问题、边界和成功标准。

PRD 是整篇论证，卡片是其中的一节。 只留卡片、不留论证的团队，容易做出“每张票都自洽、合起来却不成形”的产品5。

判断该写哪一种，看它还能不能被否掉：还能被否掉，就写一份给决策者看的一页纸提案；决定已经做了、接下来只是要把它做对，才写 PRD。 前者回答“值不值得做”，后者回答“做成什么样才算对”4。

什么时候干脆不要写

有两种情况，完整 PRD 是负担：决定还没做的时候，还能被否掉就写详细需求，是最贵的一种确认方式——你在花时间规定一件可能根本不会发生的事4；这件事没有决策可做的时候，改一句文案、修一个 bug，一张 ticket 就够了。

篇幅也由 待定的决策数量 决定，不是由功能数量决定。单个功能一页到两页通常够；新产品、跨多个团队、涉及合规的，才需要四到十页。有个很好用的删减标准：某一段读完之后，不会改变任何人要建的东西或要测的东西，就删掉它5。

最后一句：PRD 是活文档，不是签完字就冻结的合同。冻结式的做法适合一年只有一次发布机会的团队；在持续发布的团队里，实现过程中发现了新约束，就回去改文档，并在底部记一笔改了什么25。