2. PRD输入规范总览:输入来源、用户需求场景、业务目标、技术约束、数据来源
适用场景
本规范适用于产品经理在编写PRD之前,系统收集并整理所有必要的输入信息,确保PRD内容完整、可追溯、可评审。具体场景包括:
- 新产品立项或重大版本迭代启动阶段
- 跨部门协作项目需要统一输入口径
- 研发团队要求提供明确的业务目标和数据支撑
- 技术选型存在约束条件时(如现有架构、合规要求)
前置条件
- 已完成初步用户研究或市场调研,获得原始需求清单
- 业务方已明确项目核心目标和预期收益
- 技术团队已确认当前系统架构与关键技术限制
- 数据团队可提供可用的数据源清单与访问方式
操作步骤
- 识别输入来源:列出所有可获取输入的渠道(用户反馈、竞品分析、业务方提案、战略规划、法规标准、技术可行性报告等)。
- 提取用户需求场景:从用户旅程图中提炼高频痛点、功能触发条件、使用环境与角色关系。
- 定义业务目标:用SMART原则将业务方诉求转化为可量化的指标(如DAU提升10%、转化率提高5%)。
- 梳理技术约束:包括现有系统兼容性、性能上限、第三方依赖、安全合规、团队技术储备等。
- 明确数据来源:指定所需数据的字段、粒度、更新频率、获取方式(API、离线表、实时流)。
- 组织并校验输入:将以上输入整理为结构化的“输入检查表”,并提交给上下游团队确认其完整性和准确性。
输入输出物
| 输入物 | 产出物 | 格式要求 |
|---|---|---|
| 用户研究原始记录、业务方需求文档、竞品分析报告 | 输入来源清单 | Excel/飞书表格(含来源、类型、可信度) |
| 用户旅程图、用例列表 | 用户需求场景卡片 | 结构化文档(场景编号、触发条件、角色、预期行为) |
| 业务KPI文档、项目商业论证 | 业务目标树 | 思维导图或表格(目标→指标→基线值) |
| 技术架构图、依赖服务列表、合规要求 | 技术约束矩阵 | 表格(约束类型、影响范围、应对方案) |
| 数据字典、数据仓库接口说明、第三方数据协议 | 数据来源映射表 | 结构化列表(字段、源表、更新周期) |
责任边界
- 产品经理:主导输入收集、组织、校验,确保信息可追溯
- 业务方:提供真实可量化的业务目标,确认场景优先级
- 技术负责人:给出准确的技术约束和可行性评估
- 数据负责人:确认数据来源可用性,提供数据质量说明
记录材料
每次完成输入收集后,需保存以下记录:
- 输入来源清单(含版本号与更新时间戳)
- 各输入项的评审签字确认(邮件或协作平台审批记录)
- 变更日志:若后续增删输入项,需注明原因与批准人
异常处理
常见异常及应对:
- 输入来源缺失:若无法获取某类输入(如竞品数据),需在输入清单中标记为“待补充”并在PRD中注明不确定性影响。
- 业务目标矛盾:组织跨团队对齐会,使用“目标优先级矩阵”裁定,并将矛盾点作为风险项记录。
- 技术约束不明确:要求技术团队出具“技术约束分析报告”,若涉及重大风险须暂停PRD编写,先做技术预研。
- 数据来源不可用:与数据团队协商临时数据方案,并在PRD中增加“数据源依赖说明”章节。
验收标准
以下六项全部满足即为验收通过:
- 输入来源清单覆盖不少于5个独立渠道
- 用户需求场景描述包含角色、触发条件、预期行为三个要素
- 业务目标均为可量化的SMART指标,并有基线值与目标值
- 技术约束矩阵包含性能、兼容性、安全、第三方依赖四个维度
- 数据来源映射表中每个字段均注明来源系统、更新频率和可信度
- 所有输入均通过相关方确认(邮件/审批/会议纪要)
实战提醒:在首次应用本规范时,建议产品经理先用1-2周的时间收集并校验输入,避免匆忙进入PRD写作导致后续大量返工。每个输入项都应有明确的负责人和截止时间,建议使用共享文档进行版本管理。