1. PRD 结构拆解：常见模块、作用与阅读顺序
一份高质量的 PRD 不是功能的堆砌，而是“问题-方案-验证”逻辑链的书面载体。它需要让不同角色的读者（产品、设计、开发、测试、运营）在最短时间内找到自己所需的信息，并理解“为什么做”以及“怎么做”。
1.1 PRD 的常见模块
标准的 PRD 通常包含以下 8 个核心模块，它们共同构成了从洞察到交付的完整闭环：
| 模块名称 | 核心作用 | 关键内容 |
|---|---|---|
| 1. 背景与目标 | 回答“为什么做”，统一团队认知 | 业务背景、用户痛点、市场机会、OKR/KPI 对齐 |
| 2. 用户场景 | 描述“谁在什么情况下用”，构建共情 | 用户画像、使用场景（时间/地点/设备）、情绪曲线 |
| 3. 业务问题 | 定义“当前有什么阻碍”，锁定真因 | 用户访谈结论、竞品分析差异、数据埋点暴露的流失点 |
| 4. 需求拆解 | 将模糊需求转化为可执行粒度 | 用户故事（Epic/Story/Task）、功能列表、优先级矩阵 |
| 5. 方案表达 | 说明“怎么做”，达成设计与开发共识 | 流程图、界面线框图、逻辑规则、异常处理 |
| 6. 指标验证 | 衡量“是否成功”，数据驱动决策 | 北极星指标、A/B 测试方案、数据埋点清单 |
| 7. 验收标准 | 定义“做完的标准”，消除理解偏差 | Given/When/Then 格式、边界条件、错误状态 |
| 8. 交付物模板 | 提供可直接使用的文档骨架 | PRD 模板、原型标注规范、评审检查清单 |
核心认知：PRD 的第一个读者不是开发，而是产品经理自己。当你写下面向用户的场景和面向业务的指标时，你已经在驱动方案的正确性。不要把 PRD 看作记录，而要看作推理过程。
1.2 各模块的阅读顺序
PRD 的阅读顺序不是线性的，不同角色会根据自身需要选择不同的进入口。以下是推荐的两种典型阅读路径：
- 预期读者（战略决策层）： 从“背景与目标”开始，快速判断该需求是否与当前业务方向一致；接着直接跳到“指标验证”，评估风险与收益；最后阅读“用户场景”以建立同理心。
- 执行读者（产品/设计/开发）： 从“用户场景”和“业务问题”入手，理解需求产生的土壤；然后重点阅读“需求拆解”与“方案表达”，确认功能逻辑与交互细节；最后依据“验收标准”进行自测。
给新人的建议： 当你刚开始撰写 PRD 时，很容易先写功能细节。请强制自己先完成“背景与目标”和“用户场景”两个模块。一旦你对“谁在什么场景下遇到什么问题”有明确的画面感，后续的拆解和方案会自然涌现。
1.3 PRD 结构与阅读顺序图
下图展示了 PRD 模块之间的逻辑依赖关系，以及典型读者的跳读路径。蓝色路径适合战略层，红色路径适合执行层。
常见陷阱： PRD 不是一次性写死的文档。在需求评审、设计评审、甚至开发过程中，你可能会发现新的用户场景或遗漏的业务问题。此时不需要重写整份文档，而是通过版本记录和变更说明，对“业务问题”或“方案表达”等对应模块进行增量更新。