第2章：PRD编写前置条件——需求来源确认、业务目标对齐、用户画像准备、数据基础核查
适用场景
- PRD启动前：产品经理完成首次需求收集后，正式撰写PRD前必须执行的四项基础核查。
- 需求评审会前：团队（PM、开发、测试、设计）在需求澄清环节需确认前置条件已满足。
- 跨部门协作：涉及多个业务方、数据平台或外部系统的需求，必须逐项验证前置条件。
前置条件（本章的输入条件）
- 已完成至少一轮需求收集（用户访谈、市场调研、内部反馈）。
- 拥有初步的产品愿景或业务提案。
- 团队已确认PRD负责人（通常为产品经理）。
操作步骤
步骤一：需求来源确认
- 识别来源渠道：列出所有提出需求的角色/系统（如客户投诉系统、销售CRM、竞品分析报告、用户访谈记录、内部效率优化建议）。
- 记录原始信息：对每一条需求记录：提出人、时间、原始描述、紧急程度。
- 归类与过滤：将需求按“功能需求”“非功能需求”“体验优化”“数据需求”分类，剔除已过时或重复项。
- 确认优先级：与业务方初步沟通，标记P0/P1/P2。
步骤二：业务目标对齐
- 明确核心目标：从需求中提炼出2~3个可量化的业务目标（如“提升订单转化率3%”“降低客服电话量20%”）。
- 对齐干系人：与产品负责人、业务总监、技术负责人逐一确认目标是否一致。
- 建立目标树：将业务目标分解为产品功能指标（如用户留存率、任务完成时间）。
- 记录冲突：如果多方目标矛盾（如“增加功能 vs 降低开发成本”），标记并进入异常处理流程。
步骤三：用户画像准备
- 识别目标用户群：至少定义主要用户（Primary Persona）和次要用户（Secondary Persona）。
- 收集画像要素：年龄、职业、使用场景、痛点、技术熟练度、常用设备。
- 验证画像真实性：通过已有用户数据（如GA、CRM）或小范围调研确认画像比例。
- 确保可追溯：为每个画像记录数据来源（如“用户访谈-客户A”“后台行为日志”）。
步骤四：数据基础核查
- 检查数据源可用性：确认所需埋点、数据仓库表、第三方API是否存在且可访问。
- 评估数据质量：抽样检查字段完整率、异常值、时间范围。
- 确认数据权限：与数据安全团队确认当前角色是否有权限使用这些数据。
- 记录数据依赖：如需要新埋点或建表，提前进入排期。
案例：某电商项目PRD启动前，数据核查发现用户行为数据因老旧SDK导致50%字段缺失。团队立即启动SDK升级，PRD撰写推迟1周，避免了上线后无法验证指标的风险。
最佳实践：使用统一的“PRD前置条件检查清单”模板（见下节记录材料），每个步骤完成后打勾并签名，避免口头确认。建议在JIRA中创建子任务跟踪每项检查。
输入输出物
| 输入物 | 来源 | 输出物 |
|---|---|---|
| 原始需求列表（原始文档/访谈记录） | 需求收集阶段 | 需求来源核查表（含来源、分类、优先级） |
| 业务提案/OKR/项目章程 | 公司战略层 | 业务目标对齐记录（含目标分解、签字确认） |
| 用户调研数据/市场报告 | 用户研究团队 | 用户画像卡片（含Primary/Secondary Persona） |
| 数据字典/数据权限文档/埋点清单 | 数据平台/后端 | 数据基础核查报告（含数据可用性、质量、权限状态） |
责任边界
- 产品经理（PM）：主导所有四项核查的发起与汇总，对输出物完整性负责。
- 业务方（业务负责人）：提供原始需求背景、确认业务目标、审核用户画像真实性。
- 数据分析师/数据工程师：配合数据基础核查，提供数据源概况、质量评估、权限现状。
- 技术负责人：评估数据依赖的实现难度，参与目标可行性判断。
- 设计团队：接收用户画像卡片，为后续体验设计提供输入。
记录材料
建议使用以下文档模板（可在公司Wiki或项目管理工具中建立）:
# PRD前置条件检查清单
## 项目名称：________________ 日期：________________
## 负责人：________________
### 1. 需求来源确认
- [ ] 已列出所有需求来源渠道
- [ ] 已按分类排序并标记优先级
- [ ] 已与业务方初步确认紧急度
备注：________________
### 2. 业务目标对齐
- [ ] 核心目标已量化（如：UV转化率提升X%）
- [ ] 已与技术/产品负责人双方签字
- [ ] 冲突已登记并升级
备注：________________
### 3. 用户画像准备
- [ ] 主要画像（Primary Persona）已定义
- [ ] 次要画像（Secondary Persona）已定义
- [ ] 画像数据来源可追溯
备注：________________
### 4. 数据基础核查
- [ ] 数据源可用性已确认
- [ ] 数据质量抽样通过（缺失率<5%）
- [ ] 数据权限已获批准
备注：________________异常处理
| 异常场景 | 处理流程 | 责任方 |
|---|---|---|
| 需求来源不明（无法追溯原始提出人） | 标记为“待确认”，暂停PRD编写，由PM发起2次澄清会议；若2天内无结果，升级至产品总监。 | PM |
| 业务目标冲突（多个干系人要求不同） | 组织目标对齐工作坊，使用KANO模型评分；无法达成一致时按最高业务价值决策。 | PM + 业务负责人 |
| 用户画像缺失数据（无用户调研基础） | 紧急启动“最小可行画像”方法：用后台数据和客服记录快速构建假设画像，并在后续迭代中验证。 | PM + 用户研究员 |
| 数据源不可用/权限未开通 | 评估替代数据源可行性；若必须原数据，创建数据依赖工单，PRD增加“风险&降级”章节，明确延迟影响。 | PM + 数据工程师 |
注意：异常处理不完成不能进入PRD正文撰写。每一项异常都必须有明确的“已处置/标记延期/升级”状态，并记录在检查清单备注栏。团队应将异常处理耗时纳入项目排期。
验收标准
- 需求来源确认表涵盖≥80%的原始需求，且每个需求均有可追溯的来源渠道。
- 业务目标对齐记录包含量化指标及干系人签字（或邮件确认）。
- 用户画像卡片至少包含一个Primary Persona（含姓名、年龄、角色、痛点、使用场景），并附数据来源说明。
- 数据基础核查报告给出明确结论：可用/不可用（附理由），且所有数据权限已审批通过。
- 所有异常处理项均有状态记录（已关闭/已延期/已升级）。