第1章 B端PRD迭代全景与课程目标
1.1 理解PRD迭代全景
B端产品需求文档（PRD）不是一次性交付的静态文件，而是在产品全生命周期中持续演进的动态资产。PRD迭代的本质是需求验证—方案调整—共识对齐的循环过程。缺乏全景视角的团队，往往陷入以下困境：
- 需求版本散落各处，评审时无从追溯决策依据；
- 角色职责模糊，PRD流转效率低、返工频繁；
- 交付物清单不统一，验收时才发现关键信息缺失。
本章从迭代节奏、核心角色、交付物清单、案例背景四个维度构建PRD迭代全景，为后续章节的实战拆解奠定框架基础。
1.2 迭代节奏：PRD的三种时间刻度
B端产品的PRD迭代通常遵循三级节奏，对应不同粒度的需求响应周期：
| 节奏层级 | 周期 | 典型活动 | 产出物 |
|---|---|---|---|
| 双周迭代 | 2周 | 需求澄清、UI走查、Bug修复PRD补丁 | PRD补丁说明、交互备注 |
| 月度里程碑 | 1个月 | 版本PRD评审、技术预审、验收标准对齐 | 版本PRD、验收用例、变更日志 |
| 季度规划 | 3个月 | 业务目标拆解、模块级PRD重构、干系人汇报 | 规划PRD、需求路线图、KPI基线 |
实践建议：对于尚未建立迭代节奏的团队，建议先固定月度里程碑，再逐步压缩至双周。节奏的稳定性比速度更重要。
1.3 核心角色：五方协作模型
PRD迭代不是产品经理的独角戏，完整的协作网络包含五类角色，每一方在迭代中的职责和参与深度不同：
- 产品经理（PM） — PRD的第一责任人，负责需求挖掘、方案设计、变更管理。
- 开发工程师（Dev） — 提供技术可行性反馈，参与PRD技术预审，确认实现方案。
- 测试工程师（QA） — 从验收视角补充边界场景，输出验收用例并与PRD绑定。
- 业务方/客户代表（Biz） — 输入真实业务场景，参与需求评审，确认价值优先级。
- 运营/实施团队（Ops） — 反馈上线后使用数据，驱动下一轮迭代的需求修正。
关键原则：每一轮PRD迭代必须至少包含“PM—Dev—QA”三角对齐；里程碑级迭代必须包含Biz和Ops的正式评审。
1.4 交付物清单：PRD迭代的六大件
标准化的交付物是迭代质量的可视化保障。下表列出B端PRD迭代中必须维护的六类交付物及其核心字段：
| 序号 | 交付物 | 核心内容 | 更新频率 |
|---|---|---|---|
| 1 | PRD正文 | 用户场景、业务规则、字段定义、异常流程 | 每版迭代更新 |
| 2 | 交互原型 | 页面流程、组件状态、错误提示、空态设计 | 随PRD同步更新 |
| 3 | 需求列表 | 需求ID、优先级、状态、版本归属、变更记录 | 持续维护 |
| 4 | 验收用例 | 正向用例、异常用例、边界值、环境描述 | 每版迭代新增 |
| 5 | 版本规划 | 版本范围、里程碑时间、依赖关系、风险登记 | 每季度刷新 |
| 6 | 变更日志 | 变更日期、变更人、变更摘要、影响范围 | 每次变更记录 |
1.5 课程案例背景：某SaaS平台CRM模块改造
本课程所有章节的实战内容均围绕一个统一的案例展开——某SaaS企业销售管理平台（CRM模块）的二期改造项目。该项目处于产品成长期，已有一期基础功能，二期需解决以下核心痛点：
- 线索流转缺乏自动化规则，销售手动分配效率低；
- 客户详情页字段过多、层级混乱，用户操作路径长；
- 商机阶段无标准化定义，管理层无法准确预测营收；
- 报表数据源不一致，运营团队需跨系统手工整合。
注意：本课程不要求学员具备CRM行业经验。案例中的业务场景、用户角色、数据逻辑均经过脱敏和泛化处理，重点在于展示PRD迭代的通用方法，而非特定行业知识。
本章要点回顾：
- PRD迭代存在三种节奏刻度（双周、月度、季度），对应不同粒度的需求管理；
- 五方协作模型（PM、Dev、QA、Biz、Ops）是迭代质量的组织保障；
- 六类交付物构成标准化迭代产出基线，缺一不可；
- 本课程以CRM模块改造为统一案例，所有章节均基于同一业务上下文展开。