1. PRD 的本质与产品经理的沟通工具
PRD 是什么
PRD（Product Requirements Document，产品需求文档）是产品经理将用户需求、业务目标转化为可执行、可验证的结构化书面说明。它不是一份“写死”的合同，而是一份动态对齐的沟通载体——让设计师、开发工程师、测试工程师、运营等所有角色在同一页面上理解“为什么做、做什么、怎么做才叫完成”。
为什么需要 PRD
在没有 PRD 或 PRD 质量低下的团队中，常见问题包括：
- 口头沟通遗漏：会议中聊过的细节，三天后各方记忆不一致。
- 需求二义性：“用户能快速搜索”在不同人眼里可能是“模糊匹配”“精确匹配”“拼音搜索”三种实现。
- 返工成本高：开发快完成了，测试发现与真实场景不符，被迫重改。
- 无法追溯决策：上线后复盘时，已经说不清当初为什么这样设计。
PRD 通过书面化、结构化、可验证的文档体系，从根本上解决这些痛点。
核心价值
| 价值维度 | 说明 |
|---|---|
| 对齐认知 | 使产品、设计、研发、测试、运营对“做什么”和“为什么做”达成一致。 |
| 减少返工 | 提前暴露逻辑漏洞、边界场景、异常流程，避免开发后才发现问题。 |
| 沉淀知识 | 成为后续迭代、新人 onboarding、跨部门协作的权威参考。 |
| 支持验收 | 提供明确的验收标准&测试用例基础，让上线决策有据可依。 |
受众与使用场景
PRD 并非给产品经理自己看的自嗨文档，它的读者和典型使用场景如下：
| 读者角色 | 使用场景 | 关注点 |
|---|---|---|
| 设计师 | 交互设计、视觉稿制作前 | 用户流程、界面元素、响应规则 |
| 研发工程师 | 技术方案设计、编码实现时 | 逻辑规则、数据定义、异常处理 |
| 测试工程师 | 编写测试用例、执行验收 | 功能清单、边界条件、预期结果 |
| 运营/市场 | 上线准备、功能推广 | 发布节奏、权限配置、数据埋点 |
| 项目经理 | 排期、进度追踪 | 依赖关系、优先级、里程碑 |
| 产品负责人/管理层 | 决策评审、资源审批 | 业务价值、投入产出、风险 |
常见误区：把 PRD 写成“功能清单+原型截图”的简单堆叠，缺少场景描述、规则细化、验收条件。真正有效的 PRD 应该让每个读者都能独立回答：“我负责的部分，什么情况下算完成？”
关键认知：PRD 不是“文档工作”的终点，而是协作的起点。优秀的产品经理在编写 PRD 时已经在心理上完成了“角色代入”——想象设计师看到这段会如何画图、研发会如何写代码、测试会如何设计用例。本章后续将逐一拆解这些角色视角下的文档要素。