1. PRD的本质：业务目标是第一驱动力
PRD（Product Requirements Document）不是功能的堆砌，而是业务目标的显式化。任何功能需求都必须回答“为什么做”以及“做成什么样才算成功”。业务目标决定需求优先级、方案取舍和验收标准。
1.1 常见误区：PRD = 功能清单
许多初级产品经理把PRD写成“功能列表”，例如“用户可点击按钮、可查看列表、可导出Excel”。这种文档忽略了业务场景和用户价值，导致开发完成后发现没有解决实际问题。
| 对比维度 | 功能清单型PRD | 业务目标驱动型PRD |
|---|---|---|
| 出发点 | “要加什么功能” | “要达成什么业务效果” |
| 需求来源 | 竞品抄袭或老板指令 | 用户访谈与数据分析 |
| 方案表达 | 罗列交互细节 | 描述业务场景与流转 |
| 成功标准 | 功能开发完成 | 业务指标达成（如转化率提升） |
| 变更处理 | 容易蔓延 | 围绕目标收敛 |
1.2 业务目标驱动的PRD框架
一个完整的PRD应当从业务目标出发，依次经历用户场景定义、业务问题分析、用户访谈验证、需求拆解、方案表达、指标设定、验收标准制定，最终形成可交付的文档模板。下图展示了这一驱动关系：
核心观点：PRD的每一部分都必须能回溯到业务目标。如果某个功能无法用“为了达成XX业务目标”来解释，就需要重新审视它的必要性。
1.3 文档的阅读对象与使用场景
PRD不是写给一个人看的。不同角色在不同阶段使用PRD的方式不同：
- 产品经理：作为需求记录与决策依据，用于内部评审和版本规划。
- 设计师：从PRD中提取用户场景与交互约束，指导界面设计。
- 开发工程师：关注功能逻辑、接口定义、状态流转与边界条件。
- 测试工程师：依据验收标准编写测试用例，验证功能是否满足业务目标。
- 运营/业务方：确认需求是否匹配实际业务诉求，提供反馈。
因此，PRD必须在结构上清晰区分“业务目标→场景→需求→方案→验收”的层次，让每种读者能快速找到自己关心的内容。
思考题：你现在的PRD是否从业务目标开始？尝试将你最近一份PRD中所有功能点都标上对应的业务目标，看看有多少功能是“孤儿需求”。