1. PRD核心价值与交付物全景
PRD（Product Requirements Document，产品需求文档）是产品经理的核心交付物，它弥合了“业务意图”与“工程实现”之间的鸿沟。本章从全景视角拆解PRD的目标用户、核心产出、常见误区以及它与BRD、MRD的本质区别，帮助你从一开始就建立正确的文档价值观。
核心交付物矩阵 — PRD不是一次性输出的“巨无霸”文档，而是一组可组装、可验证的交付物集合。本课程将围绕以下八项能力维度组织每章内容：用户场景、业务问题、用户访谈、需求拆解、方案表达、指标验证、验收标准、交付物模板。
1.1 目标用户
- 产品经理（主创）：负责编写、维护与迭代PRD，确保上下游对齐。
- 设计与交互：将需求转化为高保真原型，PRD中的用户场景、交互边界是核心输入。
- 研发工程师：基于功能描述、业务规则、验收标准进行技术方案设计与编码。
- 测试工程师：以验收标准为准绳编写测试用例，验证交付质量。
- 项目/运营团队：了解功能范围、上线指标，规划排期与运营策略。
1.2 PRD与BRD、MRD的区别
| 维度 | BRD（商业需求文档） | MRD（市场需求文档） | PRD（产品需求文档） |
|---|---|---|---|
| 读者 | 决策层、投资人 | 市场、产品团队 | 设计、研发、测试、运营 |
| 核心问题 | 为什么要做？（ROI、商业价值） | 为谁做？市场机会在哪？ | 具体怎么做？功能与规则是什么？ |
| 典型产出 | 商业画布、投资回报分析、市场规模估算 | 用户画像、痛点分析、竞品对比、MVP范围 | 功能列表、用户流程、业务规则、验收标准、数据埋点 |
| 文档颗粒度 | 宏观，1~3页 | 中观，5~10页 | 微观，10~50页（可拆分子文档） |
1.3 常见误区
- 把PRD写成“说明书” — 堆砌界面截图和文案，却忽略了业务规则、异常流程和验收标准。
- 一次写完所有细节 — 试图在需求评审前“闭环”，导致文档僵化、难以响应变更。
- 缺少指标与验证 — 只有功能描述，未定义如何衡量功能上线后的成功与否（如转化率提升、错误率降低）。
- 忽略用户场景 — 大量技术实现逻辑（如接口参数、数据库字段）替代了用户实际操作路径的描述。
- 文档与产品脱节 — PRD写完后无人更新，开发过程中的需求变更未同步到文档，导致后续维护成本飙升。
⚠ 避坑提示 — 好的PRD是“活的文档”：它应围绕用户场景组织，业务规则用表格表达，验收标准可执行可度量。不必追求完美初稿，但要保证每一次迭代都更新关键字段。
1.4 核心产出速览
PRD的交付物不是单一文件，而是一个“文档包”。每个模块对应课程后续章节的实践输出：
| 模块 | 交付物示例 | 课程章节 |
|---|---|---|
| 用户场景 | 用户旅程地图、场景卡片 | 第2、3章 |
| 业务问题 | 问题陈述、5Whys分析 | 第4章 |
| 用户访谈 | 访谈大纲、用户语录、洞察矩阵 | 第5章 |
| 需求拆解 | 用户故事拆分、功能颗粒度表 | 第6~8章 |
| 方案表达 | 流程图、业务规则表、原型注解 | 第9~12章 |
| 指标验证 | 北极星指标、数据埋点方案 | 第13~15章 |
| 验收标准 | 功能验收checklist、边界值测试例 | 第16~18章 |
| 交付物模板 | 标准PRD模板、变更记录页 | 第19~20章 |
学习建议 — 第一章帮助你建立“文档坐标系”，后续每一章都将沿着本图的节点逐一深入。建议保存本章SVG图作为课程导航地图，在学习过程中随时对照。