⚡

PRD开发Skill prd-development

这个技能用于指导产品经理通过结构化流程创建产品需求文档（PRD），涵盖问题框架、用户研究、解决方案定义和成功标准，确保文档清晰、全面，对齐团队和利益相关者，避免模糊性和范围蔓延。关键词包括PRD、产品需求文档、产品管理、需求分析、用户故事、成功指标、敏捷开发、产品战略。

需求分析 0 次安装 0 次浏览 更新于 3/18/2026

名称: prd-development 描述: 通过协调问题框架、用户研究综合、解决方案定义和成功标准，指导产品经理创建结构化的产品需求文档（PRD），形成一个连贯的文档。使用此方法将零散的笔记和Slack线程转换为清晰、全面的PRD，以对齐利益相关者、提供工程背景并作为真相来源——避免模糊性、范围蔓延和“构建我脑海中的东西”陷阱。

这不是瀑布式规范——它是一个活文档，捕捉战略背景、客户问题、拟议解决方案和成功标准，随着交付过程中的学习而演进。

类型: 工作流

目的

通过协调问题框架、用户研究综合、解决方案定义和成功标准，指导产品经理创建结构化的产品需求文档（PRD），形成一个连贯的文档。使用此方法将零散的笔记和Slack线程转换为清晰、全面的PRD，以对齐利益相关者、提供工程背景并作为真相来源——避免模糊性、范围蔓延和“构建我脑海中的东西”陷阱。

这不是瀑布式规范——它是一个活文档，捕捉战略背景、客户问题、拟议解决方案和成功标准，随着交付过程中的学习而演进。

关键概念

什么是PRD？

PRD（产品需求文档）是一个结构化文档，回答以下问题：

  1. 我们解决什么问题？（问题陈述）
  2. 为谁解决？（目标用户/人物角色）
  3. 为什么现在解决？（战略背景、商业案例）
  4. 我们构建什么？（解决方案概述）
  5. 如何衡量成功？（指标、成功标准）
  6. 需求是什么？（用户故事、验收标准、约束）
  7. 我们不构建什么？（超出范围）

PRD结构（标准模板）

# [功能/产品名称] PRD

## 1. 执行摘要
- 一段式概述（问题 + 解决方案 + 影响）

## 2. 问题陈述
- 谁有这个问题？
- 问题是什么？
- 为什么痛苦？
- 证据（客户引语、数据、研究）

## 3. 目标用户和人物角色
- 主要人物角色
- 次要人物角色
- 待完成工作

## 4. 战略背景
- 商业目标（OKR）
- 市场机会（TAM/SAM/SOM）
- 竞争格局
- 为什么现在？

## 5. 解决方案概述
- 高级别描述
- 用户流程或线框图
- 关键功能

## 6. 成功指标
- 主要指标（我们优化的目标）
- 次要指标
- 目标（当前 → 目标）

## 7. 用户故事和需求
- 史诗假设
- 带验收标准的用户故事
- 边缘案例、约束

## 8. 超出范围
- 我们不构建什么（及原因）

## 9. 依赖和风险
- 技术依赖
- 外部依赖（集成、合作伙伴关系）
- 风险和缓解措施

## 10. 开放问题
- 未解决的决策
- 需要发现的领域

为什么有效

  • 对齐: 确保每个人（PM、设计、工程、利益相关者）理解“为什么”
  • 背景保存: 捕捉研究和战略理由供将来参考
  • 决策记录: 记录范围内外内容及原因
  • 执行清晰性: 为用户故事和验收标准提供工程背景

反模式（这不是什么）

  • 不是详细规范: PRD框架问题和解决方案；不指定UI的每个像素
  • 不是瀑布式: PRD随学习演进；不是冻结的合同
  • 不是协作的替代品: PRD补充对话，不取代它

何时使用

  • 启动主要功能或产品计划
  • 对齐跨职能团队范围和需求
  • 为将来参考记录决策
  • 为新团队成员到项目上岗

何时不使用

  • 用于小bug修复或琐碎功能（过度工程）
  • 当问题和解决方案已清晰对齐时（只需写用户故事）
  • 用于持续发现实验（改用Lean UX Canvas）

促进真相来源

当以引导对话运行此工作流时，使用workshop-facilitation作为交互协议。

它定义：

  • 会议提醒 + 进入模式（引导式、背景转储、最佳猜测）
  • 单问题轮流，用简单语言提示
  • 进度标签（例如，背景Qx/8和评分Qx/5）
  • 中断处理和暂停/恢复行为
  • 决策点编号建议
  • 常规问题的快速选择编号响应选项（在有用时包括其他（指定））

此文件定义工作流序列和领域特定输出。如有冲突，遵循此文件的工作流逻辑。

应用

使用template.md进行完整填写结构。

此工作流在2-4天内协调8个阶段，使用多个组件和交互技能。

阶段1：执行摘要（30分钟）

目标: 为浏览者写一段式概述。

活动

1. 草拟执行摘要

  • 格式: “我们为[人物角色]构建[解决方案]以解决[问题]，这将导致[影响]。”

  • 示例:

    “我们为非技术小企业主构建引导式上岗清单以解决由于缺乏指导导致首次24小时内60%流失的问题，这将使激活率从40%提高到60%并减少流失10%。”

  • 参与者: PM

  • 持续时间: 30分钟

  • 输出: 一段式摘要

提示: 先写此（强制清晰），但最后完善（在其他部分完成后）。

阶段2：问题陈述（60分钟）

目标: 用证据框架客户问题。

活动

1. 写问题陈述

  • 使用: skills/problem-statement/SKILL.md（组件）
  • 输入: 来自skills/discovery-process/SKILL.md或skills/problem-framing-canvas/SKILL.md的发现洞察
  • 参与者: PM
  • 持续时间: 30分钟
  • 输出: 结构化问题陈述

示例问题陈述:

## 2. 问题陈述

### 谁有这个问题？
非技术小企业主（个体经营者，1-10名员工）注册我们的SaaS产品。

### 问题是什么？
60%的用户在首次24小时内放弃上岗，因为他们不知道首先做什么。他们看到没有指导的空仪表板，被选项压倒，然后离开。

### 为什么痛苦？
- **用户影响:** 浪费时间（30-60分钟试图理解产品），从未达到“顿悟时刻”，在体验价值前流失
- **商业影响:** 60%激活率 → 高流失、低LTV、差口碑

### 证据
- **访谈:** 8/10流失用户说“我不知道首先做什么”（发现访谈，2026年2月）
- **分析:** 60%的注册在24小时内完成0个操作（Mixpanel，2026年1月）
- **支持工单:** “我如何开始？”是#1支持问题（350工单/月）
- **客户引语:** “我登录，看到空仪表板，想‘现在做什么？’我放弃并回到我的电子表格。”

2. 添加支持背景（可选）

  • 客户旅程图: 如果问题跨越多个接触点
  • 使用: skills/customer-journey-mapping-workshop/SKILL.md输出
  • 待完成工作: 如果动机是关键
  • 使用: skills/jobs-to-be-done/SKILL.md输出

阶段2输出

  • 问题陈述: 谁、什么、为什么、证据
  • 支持工件: 旅程图、JTBD（如相关）

阶段3：目标用户和人物角色（30分钟）

目标: 定义您为谁构建。

活动

1. 记录人物角色

  • 使用: skills/proto-persona/SKILL.md（组件）输出
  • 参与者: PM
  • 持续时间: 30分钟
  • 格式: 包括人物角色名称、角色、目标、痛点、行为

示例:

## 3. 目标用户和人物角色

### 主要人物角色: 个体企业家Sam
- **角色:** 自由顾问、个体经营者
- **公司规模:** 1人（无IT支持）
- **技术熟练度:** 低（使用邮件、电子表格、基本SaaS）
- **目标:** 快速从软件获得价值，无需技术专长
- **痛点:** 被复杂UI压倒，没时间看教程，需要即时价值
- **当前行为:** 注册产品，尝试1天，如不立即有用则流失

### 次要人物角色: 小企业主（5-10名员工）
- **角色:** 所有者-经营者，管理团队
- **需求:** 快速上岗团队成员
- **不同于主要:** 更能容忍复杂性，愿意投资设置时间

阶段3输出

  • 主要人物角色: 详细档案
  • 次要人物角色: （如适用）

阶段4：战略背景（45分钟）

目标: 解释为什么这对业务重要以及为什么现在。

活动

1. 记录商业目标

  • 来源: 公司OKR、战略备忘录、路线图
  • 格式: 链接功能到商业结果
  • 示例:

    “此倡议支持我们的Q1 OKR：将流失从15%减少到8%。改进上岗激活直接影响保留。”

2. 估算市场机会（可选）

  • 使用: skills/tam-sam-som-calculator/SKILL.md（交互式）输出
  • 何时: 用于主要倡议、新产品、执行演示
  • 示例:

    “TAM：全球5000万小企业。SAM：500万使用SaaS工具。SOM：50万目标细分中的个体经营者。改进上岗可能解锁30%的SAM（150万潜在客户）。”

3. 记录竞争格局（可选）

  • 来源: 竞争研究、G2/Capterra评论
  • 示例:

    “竞争对手（竞争者A、B）有引导式上岗。我们的缺乏指导在退出调查中被引为流失原因。”

4. 解释“为什么现在？”

  • 理由: 为什么现在优先于此而非以后？
  • 示例:

    “流失在Q4飙升15%。上岗是#1驱动力（首次30天内60%流失）。修复此对命中保留OKR至关重要。”

阶段4输出

  • 商业目标: OKR或战略倡议
  • 市场机会: TAM/SAM/SOM（如适用）
  • 竞争背景: 竞争对手如何解决此
  • 为什么现在: 紧迫性理由

阶段5：解决方案概述（60分钟）

目标: 描述您构建什么（高级别，非详细规范）。

活动

1. 写解决方案描述

  • 格式: 高级别概述，2-3段
  • 示例:
## 5. 解决方案概述

我们构建一个**引导式上岗清单**，指导新用户在首次登录时逐步完成核心工作流。

**如何工作:**
1. 用户注册并首次登录
2. 模态出现：“让我们为您设置！完成这3步以开始。”
3. 清单显示：
   - ☐ 创建您的第一个项目
   - ☐ 邀请队友（可选）
   - ☐ 完成一个示例任务
4. 当用户完成每一步，清单用勾选更新
5. 完成后，庆祝模态：“您已设置完成！以下是下一步：”

**关键功能:**
- 最小化：仅3个核心步骤（不压倒）
- 可关闭：用户如偏好探索可跳过
- 进度跟踪：视觉进度条（1/3、2/3、3/3）
- 庆祝：完成时积极强化

2. 添加用户流程或线框图（可选）

  • 使用: 设计工具（Figma、Sketch）或手绘草图
  • 何时: 对于需要视觉解释的复杂功能
  • 输出: 嵌入PRD或链接

3. 参考故事图（可选）

  • 使用: skills/user-story-mapping-workshop/SKILL.md输出
  • 何时: 对于有多个发布切片的复杂功能
  • 输出: 链接到故事图

阶段5输出

  • 解决方案描述: 高级别概述
  • 用户流程/线框图: （如适用）
  • 故事图: （如适用）

阶段6：成功指标（30分钟）

目标: 定义如何衡量成功。

活动

1. 定义主要指标

  • 问题: 此功能必须移动的ONE指标是什么？
  • 示例: “激活率（24小时内完成首个操作的用户百分比）”
  • 目标: “从40%增加到60%”

2. 定义次要指标

  • 问题: 我们还应监控什么（但不优化）？
  • 示例:
    • 首次操作时间（从3天减少到1天）
    • 上岗清单完成率（目标：80%）
    • 支持工单量（减少“我如何开始？”工单50%）

3. 定义护栏指标

  • 问题: 什么不应变差？
  • 示例: “注册转化率（不为注册流添加摩擦）”

示例:

## 6. 成功指标

### 主要指标
**激活率**（24小时内完成首个操作的用户百分比）
- **当前:** 40%
- **目标:** 60%
- **时间线:** 启动后30天测量

### 次要指标
- **首次操作时间:** 从3天减少到1天
- **上岗清单完成率:** 80%的用户完成所有3步
- **支持工单:** 减少“我如何开始？”工单从350/月到175/月

### 护栏指标
- **注册转化率:** 维持在10%（不为注册添加摩擦）

阶段6输出

  • 主要指标: 您优化的目标
  • 次要指标: 额外成功指示器
  • 护栏指标: 不应回归的内容

阶段7：用户故事和需求（90-120分钟）

目标: 将解决方案分解为带验收标准的用户故事。

活动

1. 写史诗假设

  • 使用: skills/epic-hypothesis/SKILL.md（组件）
  • 参与者: PM
  • 持续时间: 30分钟
  • 输出: 史诗假设陈述

示例:

“我们相信为非技术用户添加引导式上岗清单将激活率从40%提高到60%，因为用户当前由于缺乏指导而流失。我们将在启动后30天通过激活率衡量成功。”

2. 分解史诗为用户故事

  • 使用: skills/epic-breakdown-advisor/SKILL.md（交互式 - 使用Richard Lawrence的9种模式）
  • 参与者: PM、设计、工程
  • 持续时间: 90分钟
  • 输出: 按模式拆分的用户故事（工作流、CRUD、业务规则等）

3. 写用户故事

  • 使用: skills/user-story/SKILL.md（组件）
  • 参与者: PM
  • 持续时间: 每故事30分钟
  • 格式: 用户故事 + 验收标准

示例用户故事:

## 7. 用户故事和需求

### 史诗假设
我们相信为非技术用户添加引导式上岗清单将激活率从40%提高到60%，因为用户当前由于缺乏指导而流失。

### 用户故事

**故事1：首次登录时显示上岗清单**
作为一个新用户，我想在首次登录时看到引导式清单，以便我知道首先做什么。

**验收标准:**
- [ ] 当用户首次登录时，带清单的模态出现
- [ ] 清单显示3步：“创建项目”、“邀请队友”、“完成任务”
- [ ] 模态可关闭（关闭按钮）
- [ ] 如关闭，清单不再出现（用户偏好保存）

**故事2：跟踪清单进度**
作为一个新用户，我想在完成清单步骤时看到我的进度，以便我感到成就感。

**验收标准:**
- [ ] 当用户完成步1，“创建项目”旁出现勾选
- [ ] 进度条更新（1/3 → 2/3 → 3/3）
- [ ] 清单跨会话持久化（如用户注销并重新登录）

**故事3：庆祝清单完成**
作为一个新用户，我想在完成清单时收到积极反馈，以便我对使用产品有信心。

**验收标准:**
- [ ] 当用户完成所有3步，庆祝模态出现
- [ ] 消息：“您已设置完成！以下是下一步：[建议的下一个动作]”
- [ ] 彩带动画（可选，最好有）

4. 记录约束和边缘案例

  • 技术约束: 平台限制、浏览器支持等
  • 边缘案例: 如果用户跳过步2怎么办？如果他们以乱序完成步怎么办？

阶段7输出

  • 史诗假设: 可测试陈述
  • 用户故事: 3-10个带验收标准的故事
  • 约束: 技术限制、边缘案例

阶段8：超出范围和依赖（30分钟）

目标: 定义您不构建什么以及您依赖什么。

活动

1. 记录超出范围

  • 格式: 明确排除的功能/请求列表
  • 理由: 为什么现在不构建？

示例:

## 8. 超出范围

**此发布中不包括:**
- **高级上岗个性化**（例如，每人角色不同清单） — 添加复杂性，先测试简单版本
- **清单中嵌入视频教程** — 资源密集，先验证清单概念
- **游戏化（徽章、积分）** — 最好有，专注于核心工作流指导

**将来考虑:**
- 移动优化上岗（当前桌面优先）

2. 记录依赖

  • 技术依赖: 平台升级、API变更所需
  • 外部依赖: 第三方集成、合作伙伴关系
  • 团队依赖: 设计交接、数据管道工作

示例:

## 9. 依赖和风险

### 依赖
- **设计:** 清单UI线框图（ETA：第1周）
- **工程:** 无技术依赖（使用现有模态框架）

### 风险和缓解措施
- **风险:** 用户立即关闭清单，从未看到它
  - **缓解:** 跟踪关闭率；如>50%，迭代消息或时机
- **风险:** 清单步骤太通用，不吸引所有人角色
  - **缓解:** 从主要人物角色（个体企业家Sam）开始，以后个性化

3. 记录开放问题

  • 未解决的决策: 需要发现或讨论的领域

示例:

## 10. 开放问题

- 清单应是强制还是可选？（决策：可选，可关闭）
- 我们应A/B测试清单vs无清单吗？（决策：是，向50%新用户展示）
- 如果用户以乱序完成步怎么办？（决策：允许任何顺序，动态更新清单）

阶段8输出

  • 超出范围: 我们不构建什么
  • 依赖: 我们开始前需要什么
  • 风险: 潜在障碍和缓解措施
  • 开放问题: 未解决的决策

完整工作流：端到端总结

第1天:
├─ 阶段1: 执行摘要 (30 分钟)
├─ 阶段2: 问题陈述 (60 分钟)
│  └─ 使用: skills/problem-statement/SKILL.md
├─ 阶段3: 目标用户和人物角色 (30 分钟)
│  └─ 使用: skills/proto-persona/SKILL.md
└─ 阶段4: 战略背景 (45 分钟)
   └─ 使用: skills/tam-sam-som-calculator/SKILL.md (可选)

第2天:
├─ 阶段5: 解决方案概述 (60 分钟)
│  └─ 使用: skills/user-story-mapping-workshop/SKILL.md (可选)
├─ 阶段6: 成功指标 (30 分钟)
└─ 阶段7: 用户故事和需求 (90-120 分钟)
   ├─ 使用: skills/epic-hypothesis/SKILL.md
   ├─ 使用: skills/epic-breakdown-advisor/SKILL.md
   └─ 使用: skills/user-story/SKILL.md

第3天:
├─ 阶段8: 超出范围和依赖 (30 分钟)
└─ 审查和完善 (60 分钟)
   └─ 读取完整PRD，抛光，获取反馈

第4天 (可选):
└─ 利益相关者审查和批准
   └─ 向利益相关者呈现PRD，整合反馈

总时间投资:

  • 快速轨道: 1.5-2天（直接功能，清晰需求）
  • 典型: 2-3天（包括发现综合、利益相关者审查）
  • 复杂: 3-4天（主要倡议，多人物角色，广泛用户故事）

示例

见examples/sample.md获取完整PRD示例。

迷你示例摘录:

## 2. 问题陈述
- 60%试用用户在首次24小时内流失
## 6. 成功指标
- 激活率: 40% → 60%

常见陷阱

陷阱1：孤立编写PRD

症状: PM独自编写PRD，向团队呈现完成的文档

后果: 无认同，团队不理解理由

修复: 与设计+工程协作阶段7（用户故事）；最终化前审查草稿PRD

陷阱2：问题陈述中无证据

症状: “我们相信用户有此问题”（无数据、无引语）

后果: 团队质疑问题是否真实

修复: 使用skills/discovery-process/SKILL.md的发现洞察；包括客户引语、分析、支持工单

陷阱3：解决方案太规定性

症状: PRD指定确切UI、像素尺寸、按钮颜色

后果: 移除设计协作，变为瀑布规范

修复: 保持阶段5高级别；让设计拥有UI细节

陷阱4：无成功指标

症状: PRD定义问题+解决方案但无指标

后果: 无法验证功能是否成功

修复: 总是在阶段6定义主要指标（您优化的目标）

陷阱5：未记录超出范围

症状: 无关于不构建什么的章节

后果: 范围蔓延，利益相关者期望未计划的功能

修复: 在阶段8明确记录超出范围

参考

相关技能（由此工作流协调）

阶段2:

  • skills/problem-statement/SKILL.md（组件）
  • skills/problem-framing-canvas/SKILL.md（交互式，用于背景）
  • skills/customer-journey-mapping-workshop/SKILL.md（交互式，可选）

阶段3:

  • skills/proto-persona/SKILL.md（组件）
  • skills/jobs-to-be-done/SKILL.md（组件，可选）

阶段4:

  • skills/tam-sam-som-calculator/SKILL.md（交互式，可选）

阶段5:

  • skills/user-story-mapping-workshop/SKILL.md（交互式，可选）

阶段7:

  • skills/epic-hypothesis/SKILL.md（组件）
  • skills/epic-breakdown-advisor/SKILL.md（交互式）
  • skills/user-story/SKILL.md（组件）

外部框架

  • Martin Eriksson, “如何编写好的PRD” (2012) — PRD结构
  • Marty Cagan, 启发 (2017) — 产品规范原则
  • Amazon, “逆向工作” (PR/FAQ格式) — PRD的替代方案

Dean的工作

  • [如Dean有PRD模板，链接此处]

技能类型: 工作流 建议文件名: prd-development.md 建议放置位置: /skills/workflows/ 依赖: 在8个阶段协调8+个组件和交互技能