one-pager-prd

单页 PRD

不适用场景： 详细的技术设计文档（请改用 ADR）、全面的产品战略（对于单页文档来说过于宏观）、用户研究综合分析（格式不同）、上线后复盘（请使用 postmortem 技能）。

工作流

复制此清单并跟踪进度：

One-Pager PRD Progress:
- [ ] Step 1: Gather context
- [ ] Step 2: Choose format
- [ ] Step 3: Draft one-pager
- [ ] Step 4: Validate quality
- [ ] Step 5: Review and iterate

步骤 1：收集背景信息

明确问题（用户痛点、支持数据）、拟议的解决方案（高层方法）、目标用户（用户画像、细分群体）、成功标准（目标、指标）和约束条件（技术、业务、时间线）。典型问题类型请参阅常见模式。

步骤 2：选择格式

对于需要快速审批的简单功能 → 使用 resources/template.md 中的单页格式（1 页，项目符号）。对于需要详细需求的复杂功能/产品 → 使用 resources/template.md 中的完整 PRD 格式（1-2 页）。对于撰写指导和结构 → 阅读 resources/methodology.md，了解问题界定、指标定义和范围制定技巧。

步骤 3：起草单页文档

创建 one-pager-prd.md，包含：问题陈述（用户痛点 + 为什么是现在）、解决方案概述（我们要构建什么）、用户画像和使用场景、带量化指标的目标、范围内的流程和范围外的事项、约束条件和假设、待解决的开放问题。保持简洁——单页文档为 1 页，PRD 为 1-2 页。

步骤 4：验证质量

使用 resources/evaluators/rubric_one_pager_prd.json 进行自我评估。检查：问题具体且以用户为中心、解决方案清晰但不过于详细、指标可衡量且设有目标、范围合理且边界明确、已说明约束条件、已识别开放问题。最低标准：平均分 ≥ 3.5。

步骤 5：评审并迭代

与利益相关者（PM、设计、工程、业务）分享。收集他们对问题界定、解决方案方法、范围边界和成功指标的反馈。根据意见迭代。在进入详细设计/开发之前，获得明确签核。

常见模式

按问题类型分类

用户痛点（最常见）：

• 模式： 用户无法执行 X，导致 Y 方面的不便
• 示例：“用户无法通过多个筛选条件搜索，找一项内容要点 10 多次”
• 验证方式： 用户访谈、支持工单、显示用户采用变通方法的分析数据

竞争差距：

• 模式： 竞争对手有某项功能，而我们没有，导致用户流失
• 示例：“竞争对手提供批量操作。20% 的流失用户提到了这一点”
• 验证方式： 用户流失分析、竞争分析、输赢访谈

战略机遇：

• 模式： 市场变化为新能力创造了机会
• 示例：“远程办公激增 → 需要异步协作功能”
• 验证方式： 市场研究、早期客户兴趣、趋势分析

技术债务/可扩展性：

• 模式： 当前系统无法扩展，阻碍增长
• 示例：“用户超过 100K 时数据库查询会超时。增长受到阻碍。”
• 验证方式： 性能指标、系统容量分析

按解决方案复杂度分类

简单功能（数周）：

• 需求明确，范围较小
• 示例：添加导出为 CSV 的按钮
• 单页文档： 问题、解决方案（1 句话）、指标、约束条件

中等规模功能（数月）：

• 多个用户流程，具有一定复杂度
• 示例：带通知的评论系统
• PRD： 详细流程、边缘情况、分阶段规划（MVP 与 v2）

大型项目（数个季度）：

• 跨职能、具有战略意义
• 示例：推出移动应用
• 多页 PRD： 拆分为多个阶段，每个阶段各有一份单页文档

按用户细分

B2B SaaS：

• 重点强调：投资回报率、管理控制、安全性、集成
• 指标：采用率、价值实现时间、NPS

B2C 消费者：

• 重点强调：愉悦体验、易用性、病毒式传播潜力
• 指标：日活跃用户数、留存曲线、推荐量

企业：

• 重点强调：合规性、定制化、支持
• 指标：对交易规模的影响、部署成功率、企业 NPS

内部工具：

• 重点强调：效率提升、团队采用情况
• 指标：节省的时间、任务完成率、员工满意度

护栏

问题：

• 具体而不含糊： ❌“用户想要更好的搜索”→ ✓“用户在搜索失败 3 次后放弃搜索（占会话的 30%）”
• 以用户为中心： 关注用户痛点，而非内部目标（“我们想提高参与度”是目标，不是问题）
• 经过验证： 引用数据（分析结果、访谈、支持工单），而非假设

解决方案：

• 高层次，不要规定过细： 描述做什么，而非怎么做。为设计和工程留出发挥空间。
• 可证伪： 足够清晰，让利益相关者能够提出异议或建议替代方案
• 范围适当： 不要在单页文档中设计 UI。“筛选面板”，而非“带复选框多选功能的下拉菜单”

指标：

• 可衡量： 必须可量化。❌“改善 UX”→ ✓“将完成任务的时间从 5 分钟缩短到 2 分钟”
• 领先指标 + 滞后指标： 两者都要包含（领先指标：采用率；滞后指标：对收入的影响）
• 基线 + 目标： 当前状态 + 目标。“将 NPS 从 40 提高到 55”

范围：

• 边界清晰： 明确说明包含和排除的内容
• MVP 与未来： 将必需项与锦上添花项分开
• 用户流程： 描述关键的理想路径和边缘情况

约束：

• 切合实际： 正视技术债务、依赖项和时间限制
• 权衡： 明确说明我们愿意牺牲什么（速度与质量、功能与简洁性）

警示信号：

• 为了解决方案而寻找问题（因为技术很酷而开发，而非出于用户需求）
• 指标含糊（没有基线、目标或时间范围）
• 范围蔓延（所有内容都是“必需项”）
• 未提及约束（不切实际的乐观）
• 没有待解决的问题（尚未深入思考）

快速参考

资源：

• resources/template.md - 单页文档和 PRD 模板，附带各部分的编写指导
• resources/methodology.md - 问题框定技巧、指标树、范围优先级排序、清晰写作
• resources/evaluators/rubric_one_pager_prd.json - 质量标准

输出： one-pager-prd.md，包含问题、解决方案、用户、目标/指标、范围、限制条件和待解问题

成功标准：

• 问题具体，并经过验证（数据/研究）
• 解决方案是清晰的高层方案（说明做什么，而不是怎么做）
• 指标可衡量，包含基线和目标
• 范围的包含项和排除项界限明确
• 已说明限制条件
• 已识别待解问题
• 已获得利益相关者签字确认
• 评分 ≥ 3.5

快速决策：

• 简单功能，需要快速审批？ → 单页文档（1 页，使用项目符号）
• 复杂功能，需要详细交接？ → 完整 PRD（1-2 页）
• 包含多个阶段？ → 每个阶段单独编写一份单页文档
• 战略性计划？ → 从单页文档开始，必要时扩展为多页文档

常见错误：

1. 问题过于含糊（“改善体验”）
2. 解决方案过于详细（指定 UI 组件）
3. 没有指标，或指标无法衡量
4. 范围蔓延（没有“范围外”部分）
5. 忽视限制条件（时间安排不切实际）
6. 没有验证（依据的是假设，而非数据）
7. 为自己而写，而非为利益相关者而写

关键见解： 简洁能迫使你表达清楚。如果无法在 1-2 页内讲清楚，说明你还没有想透。单页文档既是沟通工具，也是思考工具。

格式提示：

• 使用项目符号，而非段落（便于快速浏览）
• 先讲问题（先证明提出解决方案的合理性）
• 尽可能量化一切（数字优于形容词）
• 明确范围边界（避免误解）
• 提出待解问题（表明你经过了深入思考）

面向不同利益相关者进行调整：

• 面向高管： 强调业务影响、指标和资源需求
• 面向工程团队： 技术限制、依赖关系、分阶段安排
• 面向设计团队： 用户流程、用户画像、成功标准
• 面向销售/市场团队： 竞争定位、客户价值、发布时间