第1章：产品经理的核心职责与PRD定位
1.1 产品经理的核心职责：从模糊到清晰
产品经理的职责并非撰写文档，而是通过文档驱动决策。在需求全生命周期中，产品经理承担以下关键角色：
- 问题发现者——识别用户场景中的真实痛点与业务机会。
- 需求翻译官——将非结构化的用户反馈转化为可执行的功能描述。
- 方案设计师——协同设计、研发完成原型与交互方案。
- 价值守门员——确保每个功能产出可量化的业务指标。
- 交付推进者——贯穿开发、测试、验收全流程。
核心观点：PRD 是产品经理输出“确定性”的关键载体。没有 PRD，团队之间的认知偏差会随项目复杂度指数级放大。
职责与阶段匹配关系如下表所示：
| 职责阶段 | 核心动作 | 产出物 | 对应 PRD 章节 |
|---|---|---|---|
| 洞察 | 用户访谈、竞品分析 | 用户场景列表 | 用户场景与业务问题 |
| 拆解 | 需求优先级排序 | 功能拆解树 | 需求拆解 |
| 表达 | 原型设计、逻辑说明 | Figma 原型 + 标注 | 方案表达 |
| 验证 | 指标定义、验收测试 | 验收标准清单 | 指标验证与验收标准 |
1.2 PRD 对产品全生命周期的价值
PRD 的价值覆盖产品从概念期到运营期的完整链条，具体体现在四个关键节点：
- 立项决策期：提供需求来源与业务价值判断依据，避免资源浪费。
- 设计开发期：作为设计与开发的唯一参考标准，降低沟通成本。
- 测试验收期：验收标准直接来源于 PRD 定义，减少需求回溯。
- 迭代复盘期：历史 PRD 版本是需求变更与效果评估的原始档案。
经验提示：许多团队在开发中期出现“需求蔓延”，根源往往是 PRD 缺乏对“不做什么”的边界定义。建议在 PRD 中增加“非目标范围”小节。
1.3 PRD 与原型的关系
PRD 与原型是 “说明书与可视化样机” 的关系。原型直观展示界面布局与交互路径，而 PRD 则解释原型背后的业务逻辑、异常状态、数据规则和验收标准。
两者最佳的结合方式是原型嵌入 PRD 或 PRD 直接标注原型链接。正确的关系不是替代，而是互补：
- PRD 无原型 → 开发对视觉效果和交互细节理解偏差。
- 原型无 PRD → 边界条件、空状态、错误提示缺乏定义。
- PRD + 原型强关联 → 团队在评审时一次性对齐所有维度。
1.4 PRD 的受众与阅读场景
PRD 不是写给产品经理自己看的，而是服务于五个关键受众，每个受众的阅读场景和关注点截然不同：
| 受众 | 阅读场景 | 关注重点 | PRD 章节配合 |
|---|---|---|---|
| 设计师 | 评审前快速浏览交互逻辑 | 用户流程、页面元素、状态变化 | 方案表达（原型嵌入） |
| 研发工程师 | 开发时逐条对应编码 | 数据字段、API 定义、边界条件 | 需求拆解（功能列表） |
| 测试人员 | 编写测试用例时核对 | 验收标准、异常情况、性能要求 | 验收标准（Checklist） |
| 业务/运营方 | 确认需求是否满足业务目标 | 业务价值定义、指标预期 | 指标验证（KPI 定义） |
| 项目经理/主管 | 排期与进度跟踪 | 功能范围、依赖关系、里程碑 | 交付物模板（时间线） |
常见误区：许多产品经理在 PRD 中只写功能清单，忽略“非功能需求”和“边界条件”。当受众（尤其是测试和研发）按照 PRD 理解系统时，缺失的部分就会在该受众的独自假设中产生差异，最终导致返工。