第1章：PRD的核心价值与目标读者
任何高效的产品研发流程，都始于一份清晰、结构化且达成共识的文档。产品需求文档（PRD）不是一份简单的“需求清单”，而是连接业务目标、用户场景与技术实现的“产品蓝图”。本章将帮助你建立对PRD的正确认知，明确它的核心价值、服务对象以及交付物共识。
开篇共识：本章并非讨论具体的撰写技巧，而是先回答三个根本问题——为什么要写PRD？给谁看？最终交付什么？只有对齐这些前提，后续的章节才有实际意义。
1.1 文档定位：PRD的三层核心价值
PRD并非孤立存在的产物，它的价值体现在产品生命周期的各个环节中。我们可以将其价值归纳为三个层面：
- 统一认知（沟通层）：将产品经理脑中的“想法”翻译成团队所有角色（设计、开发、测试、运营）都能理解的“语言”。避免“我以为你懂了”的信息衰减。
- 降低返工（执行层）：通过前置的业务逻辑梳理和异常场景覆盖，将问题消灭在白纸黑字阶段，而非开发完成后才进行修补。据统计，修复需求阶段缺陷的成本仅为开发阶段的1/10。
- 提供验收依据（保障层）：一份明确的PRD是测试用例的输入，也是功能上线前的最终评判标准。它回答了“什么算做完？”和“什么算做好？”的问题。
1.2 读者画像：谁是PRD的核心受众？
作为一份“协作文档”，PRD需要服务于多角色。不同角色的关注点截然不同。理解他们的视角，是写好PRD的第一步。
| 目标读者 | 核心关注点 | 常见痛点 |
|---|---|---|
| 产品负责人/业务方 | 需求是否能解决业务问题？ROI是否合理？ | PRD过于技术化，无法判断是否与业务目标对齐。 |
| UI/UX设计师 | 用户流程是什么？异常状态如何处理？交互边界在哪？ | PRD只写了“正常流程”，缺少对空状态、加载态、错误提示的描述。 |
| 研发工程师 | 业务逻辑是否闭环？数据字段定义是否明确？接口依赖是什么？ | PRD使用了大量模糊词汇（如“稍后”、“优化体验”），导致反复沟通确认。 |
| 测试/QA | 验收标准是什么？是否可衡量？边界条件是否列出？ | PRD缺乏明确的通过/不通过指标，测试用例只能靠猜测。 |
案例：某电商后台系统的“订单导出”功能。如果PRD只写“用户可以导出订单”，而不区分“是否需要按时间筛选”、“导出格式是CSV还是Excel”、“单次导出上限是多少行”，那么开发会按最简单的方案实现，测试也无法验证导出功能的正确性。最终的结果往往是一个需要多次返工的“半成品”。
常见误区：不要把PRD写成一份“功能说明书”，罗列所有的按钮和弹窗。一份好的PRD应当让读者理解“为什么做这个功能”以及“这个功能在什么场景下解决什么问题”。
1.3 交付物共识：PRD应该长什么样？
在深入实战前，我们需要对PRD的交付物形态达成一致。PRD并非一个固定的模版，但它通常包含以下核心模块：
- 背景与目标：清晰阐述需求的来源、要解决的业务问题以及预期的核心指标（例如：提升转化率0.5%）。
- 用户场景：用故事或流程图描述用户在何种情境下使用该功能。
- 业务逻辑：用流程图或文字描述功能的详细判断逻辑和分支处理。
- 功能描述：具体的交互说明、字段定义和页面原型（或交互稿链接）。
- 验收标准：具体、可衡量的通过标准，作为开发自测和QA测试的依据。
- 不作范围：明确说明本次版本不做什么，防止需求蔓延。
以下是一个标准的PRD交付物结构清单，你可以将其作为撰写时的检查依据：
| 模块 | 描述 | 交付要求 |
|---|---|---|
| 变更记录 | 文档的版本号、修改人、修改日期、修改内容 | 每次更新都必须记录 |
| 背景与目标 | 需求的商业价值、要解决的痛点、核心指标 | 必须有可量化的预期目标 |
| 用户场景 | 使用流程图或用户故事描述 | 覆盖正常流程和至少一个异常流程 |
| 业务逻辑 | 状态机、决策表或伪代码 | 逻辑必须无歧义、无死循环 |
| 交互与视觉 | 低保真原型、高保真原型或交互演示链接 | 必须有明确的边界和状态说明 |
| 验收标准 | Given-When-Then 格式的用例 | 每条标准必须能直接通过“是/否”判定 |
| 不作范围 | 明确排除的项及其理由 | 避免后期需求被误添加 |
高效做法：在实际工作中，PRD可以是一份在线文档（如Wiki、Notion），也可以是附带了流程图和原型的PPT。关键是内容完整、逻辑闭环，而不是拘泥于某种特定格式。
为了更直观地理解PRD的定位与读者关系，请参考下方的结构图：
课程行动建议：在你开始撰写下一份PRD之前，请先花10分钟与你的核心团队成员（至少包含一位开发、一位设计、一位测试）开一个简短的“预对齐会”。在会议上，使用本章的“交付物共识”列表，明确每个人对PRD的预期。你将发现，后续的沟通效率会有显著提升。