prd-development

目的

通过统筹问题界定、用户研究综合、解决方案定义和成功标准，指导产品经理以结构化方式创建 PRD（产品需求文档），并将这些内容整合为一份完整文档。借助此工作流，将零散的笔记和 Slack 讨论串整理成清晰、全面的 PRD，使利益相关者达成一致，为工程团队提供背景信息，并作为可靠的信息源——避免歧义、范围蔓延，以及“按我脑海中的想法来构建”的陷阱。

这不是瀑布式规格说明，而是一份持续更新的文档，记录战略背景、客户问题、拟议解决方案和成功标准，并随着交付过程中的学习不断演进。

输入

最适合提供： PRD 涵盖的功能或计划。 也很有帮助： 探索笔记、问题陈述、用户研究、成功指标和约束条件——已有的内容都可以粘贴；工作流会将其放入适当阶段，并跳过已经回答的部分。

调用时提供的所有内容——技能名称后面的文字、粘贴的上下文，或附加的 ARGUMENTS: 行——都视为已提供的答案。请使用这些内容并跳过其中已涵盖的问题；不要重复询问。

手头没有任何材料？也没关系。 工作流会从定义问题开始，逐步完善内容。

调用示例： 为自助式工作区配置功能编写一份 PRD——以下是我的探索笔记和对应的 OKR。

核心概念

什么是 PRD？

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

1. 我们要解决什么问题？（问题陈述）
2. 为谁解决？（目标用户／用户画像）
3. 为什么是现在？（战略背景、商业论证）
4. 我们要构建什么？（解决方案概述）
5. 如何衡量成功？（指标、成功标准）
6. 有哪些需求？（用户故事、验收标准、约束条件）
7. 哪些内容不在构建范围内？（范围之外）

PRD 结构（标准模板）

# [Feature/Product Name] PRD

## 1. Executive Summary
- One-paragraph overview (problem + solution + impact)

## 2. Problem Statement
- Who has this problem?
- What is the problem?
- Why is it painful?
- Evidence (customer quotes, data, research)

## 3. Target Users & Personas
- Primary persona(s)
- Secondary persona(s)
- Jobs-to-be-done

## 4. Strategic Context
- Business goals (OKRs)
- Market opportunity (TAM/SAM/SOM)
- Competitive landscape
- Why now?

## 5. Solution Overview
- High-level description
- User flows or wireframes
- Key features

## 6. Success Metrics
- Primary metric (what we're optimizing for)
- Secondary metrics
- Targets (current → goal)

## 7. User Stories & Requirements
- Epic hypothesis
- User stories with acceptance criteria
- Edge cases, constraints

## 8. Out of Scope
- What we're NOT building (and why)

## 9. Dependencies & Risks
- Technical dependencies
- External dependencies (integrations, partnerships)
- Risks and mitigations

## 10. Open Questions
- Unresolved decisions
- Areas requiring discovery

为什么有效

• 达成共识： 确保所有人（PM、设计、工程、利益相关者）都理解“为什么”
• 保留背景信息： 记录研究和战略依据，供日后参考
• 决策记录： 记录哪些内容在范围内、哪些不在范围内，以及原因
• 明确执行要求： 为工程团队提供用户故事和验收标准

反模式（这不是什么）

• 不是详细规格说明： PRD 用于界定问题和解决方案；不会逐像素规定 UI
• 不是瀑布式流程： PRD 会随着学习不断演进；它不是一份冻结的合同
• 不能取代协作： PRD 是对沟通的补充，而非替代

何时使用

• 启动重要功能或产品计划时
• 让跨职能团队就范围和需求达成一致时
• 记录决策以供日后参考时
• 帮助新团队成员了解项目时

何时不使用

• 用于小型 Bug 修复或简单功能（投入过多）
• 问题和解决方案已经明确且达成一致时（直接编写用户故事即可）
• 用于持续探索实验（改用 Lean UX Canvas）

---

引导流程的事实来源

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

其中定义了：

• 会话预告和进入模式（引导式、上下文倾倒、最佳猜测）
• 每轮一个问题，并使用通俗易懂的提示
• 进度标签（例如 Context Qx/8 和 Scoring Qx/5）
• 中断处理以及暂停／恢复行为
• 在决策节点提供编号建议
• 常规问题提供编号快速选择选项（适用时包括 Other (specify)）

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

应用

使用 template.md 作为填写文档。模板包含：

• 各章节的指导模块 — 每个章节都有自己的说明、步骤、相关技能和活动，即使不使用此工作流，模板也能自行指导填写。
• 行内缺口标注 — 将每个缺口标记为 🔶 假设（合理但未经验证）或 🔵 待解决问题（未知，需要探索）。在缺口出现的位置行内标注，而不只是放在末尾。
• 跨章节推荐提示 — 完成每个章节后，“继续之前”模块会检查与前面章节的一致性，并提示下一章节需要的内容。
• 自我评估 — 第 10 节之后，诊断环节会记录最完善的章节、最薄弱的章节、最需验证的假设，以及分享 PRD 前建议采取的下一步。
• 技能交叉引用表 — 将 15 项技能映射到它们所支持的具体章节（例如，problem-framing-canvas → 第 2 节，epic-breakdown-advisor → 第 7 节）。

此工作流分为 8 个阶段，历时 2-4 天，使用多种组件技能和交互式技能。以下阶段说明引导流程；模板则用于记录产出。

---

阶段 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. Problem Statement

### Who has this problem?
Non-technical small business owners (solopreneurs, 1-10 employees) who sign up for our SaaS product.

### What is the problem?
60% of users abandon onboarding within the first 24 hours because they don't know what to do first. They see an empty dashboard with no guidance, get overwhelmed by options, and leave.

### Why is it painful?
- **User impact:** Wastes time (30-60 min trying to figure out product), never reaches "aha moment," churns before experiencing value
- **Business impact:** 60% activation rate → high churn, low LTV, poor word-of-mouth

### Evidence
- **Interviews:** 8/10 churned users said "I didn't know what to do first" (discovery interviews, Feb 2026)
- **Analytics:** 60% of signups complete 0 actions within 24 hours (Mixpanel, Jan 2026)
- **Support tickets:** "How do I get started?" is #1 support question (350 tickets/month)
- **Customer quote:** "I logged in, saw an empty dashboard, and thought 'now what?' I gave up and went back to my spreadsheet."

2. 补充背景信息（可选）

• **客户旅程图：**如果问题涉及多个触点
• 使用：skills/customer-journey-mapping-workshop/SKILL.md 的产出
• **待完成事项（Jobs-to-be-done）：**如果动机是关键因素
• 使用：skills/jobs-to-be-done/SKILL.md 的产出

阶段 2 的产出

• **问题陈述：**谁、什么、为什么、证据
• **辅助材料：**旅程图、JTBD（如适用）

---

阶段 3：目标用户与用户画像（30 分钟）

目标： 明确你要为谁构建产品。

活动

1. 记录用户画像

• 使用：skills/proto-persona/SKILL.md（组件）的产出
• 参与者： PM
• **时长：**30 分钟
• **格式：**包含用户画像名称、角色、目标、痛点、行为

示例：

## 3. Target Users & Personas

### Primary Persona: Solo Entrepreneur Sam
- **Role:** Freelance consultant, solopreneur
- **Company size:** 1 person (no IT support)
- **Tech savviness:** Low (uses email, spreadsheets, basic SaaS)
- **Goals:** Get value from software fast without technical expertise
- **Pain points:** Overwhelmed by complex UIs, no time to watch tutorials, needs immediate value
- **Current behavior:** Signs up for products, tries for 1 day, churns if not immediately useful

### Secondary Persona: Small Business Owner (5-10 employees)
- **Role:** Owner-operator, manages team
- **Needs:** Onboard team members quickly
- **Differs from primary:** More tolerant of complexity, willing to invest setup time

阶段 3 的产出

• **主要用户画像：**详细档案
• 次要用户画像：（如适用）

---

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

目标： 说明这为何对业务重要，以及为何现在要做。

活动

1. 记录业务目标

• 来源： 公司 OKR、战略备忘录、路线图
• 格式： 将功能与业务成果关联起来
• 示例：

  “此计划支持我们的 Q1 OKR：将客户流失率从 15% 降至 8%。提升新手引导激活率会直接影响客户留存。”

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

• 使用： skills/tam-sam-som-calculator/SKILL.md（交互式）输出
• 适用场景： 重大计划、新产品、高管演示
• 示例：

  “TAM：全球有 5,000 万家小型企业。SAM：其中有 500 万家使用 SaaS 工具。SOM：目标细分市场中有 50 万名个体经营者。改进新手引导或可覆盖 SAM 的 30%（150 万潜在客户）。”

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

• 来源： 竞争对手调研、G2/Capterra 评价
• 示例：

  “竞争对手（Competitor A、B）提供了引导式新手引导。退出调查中，有用户将我们缺少引导列为流失原因。”

4. 说明“为什么是现在？”

• 理由： 为什么要现在优先处理，而不是以后？
• 示例：

  “Q4 的客户流失率飙升至 15%。新手引导是首要原因（首 30 天内流失的客户中有 60% 与此有关）。解决这一问题对实现留存 OKR 至关重要。”

第 4 阶段的输出

• 业务目标： OKR 或战略计划
• 市场机会： TAM/SAM/SOM（如适用）
• 竞争背景： 竞争对手如何应对这一问题
• 为什么是现在： 紧迫性理由

---

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

目标： 描述你要构建的内容（高层次概述，而非详细规格）。

活动

1. 撰写解决方案描述

• 格式： 高层次概述，2-3 个段落
• 示例：

## 5. Solution Overview

We're building a **guided onboarding checklist** that walks new users through core workflows step-by-step when they first log in.

**How it works:**
1. User signs up and logs in for the first time
2. Modal appears: "Let's get you set up! Complete these 3 steps to get started."
3. Checklist shows:
   - ☐ Create your first project
   - ☐ Invite a teammate (optional)
   - ☐ Complete a sample task
4. As user completes each step, checklist updates with checkmarks
5. After completion, celebration modal: "You're all set! Here's what to do next."

**Key features:**
- Minimal: Only 3 core steps (not overwhelming)
- Dismissible: Users can skip if they prefer to explore
- Progress tracking: Visual progress bar (1/3, 2/3, 3/3)
- Celebration: Positive reinforcement when complete

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

• 使用： 设计工具（Figma、Sketch）或手绘草图
• 适用场景： 需要通过视觉方式说明的复杂功能
• 输出： 嵌入 PRD 或添加链接

3. 引用故事地图（可选）

• 使用： skills/user-story-mapping-workshop/SKILL.md 输出
• 适用场景： 包含多个发布切片的复杂功能
• 输出： 故事地图链接

第 5 阶段的输出

• 解决方案描述： 高层次概述
• 用户流程/线框图：（如适用）
• 故事地图：（如适用）

---

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

目标： 定义衡量成功的方式。

活动

1. 定义主要指标

• 问题： 这项功能必须推动哪一个指标？
• 示例：“激活率（24 小时内完成首次操作的用户百分比）”
• 目标：“从 40% 提高到 60%”

2. 定义次要指标

• 问题： 我们还应该监控什么（但不以此为优化目标）？
• 示例：
  • 首次操作所需时间（从 3 天缩短至 1 天）
  • 新手引导清单完成率（目标：80%）
  • 支持工单量（“如何开始？”类工单减少 50%）

3. 定义护栏指标

• 问题： 哪些指标不应变差？
• 示例：“注册转化率（不要给注册流程增加阻碍）”

示例：

## 6. Success Metrics

### Primary Metric
**Activation rate** (% of users completing first action within 24 hours)
- **Current:** 40%
- **Target:** 60%
- **Timeline:** Measure 30 days after launch

### Secondary Metrics
- **Time-to-first-action:** Reduce from 3 days to 1 day
- **Onboarding checklist completion rate:** 80% of users complete all 3 steps
- **Support tickets:** Reduce "How do I get started?" tickets from 350/month to 175/month

### Guardrail Metrics
- **Sign-up conversion rate:** Maintain at 10% (don't add friction to signup)

第 6 阶段的输出

• 主要指标： 优化目标
• 次要指标： 其他成功指标
• 护栏指标： 不应退步的指标

---

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

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

活动

1. 撰写 Epic 假设

• 使用： skills/epic-hypothesis/SKILL.md（组件）
• 参与者： PM
• 时长： 30 分钟
• 产出： Epic 假设陈述

示例：

“我们相信，为非技术用户添加引导式入门清单，可将激活率从 40% 提高到 60%，因为用户目前因缺少引导而中途流失。我们将通过产品发布 30 天后的激活率来衡量成效。”

2. 将 Epic 拆分为用户故事

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

3. 编写用户故事

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

用户故事示例：

## 7. User Stories & Requirements

### Epic Hypothesis
We believe that adding a guided onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.

### User Stories

**Story 1: Display onboarding checklist on first login**
As a new user, I want to see a guided checklist when I first log in, so I know what to do first.

**Acceptance Criteria:**
- [ ] When user logs in for the first time, modal appears with checklist
- [ ] Checklist shows 3 steps: "Create project," "Invite teammate," "Complete task"
- [ ] Modal is dismissible (close button)
- [ ] If dismissed, checklist doesn't reappear (user preference saved)

**Story 2: Track checklist progress**
As a new user, I want to see my progress as I complete checklist steps, so I feel a sense of accomplishment.

**Acceptance Criteria:**
- [ ] When user completes step 1, checkmark appears next to "Create project"
- [ ] Progress bar updates (1/3 → 2/3 → 3/3)
- [ ] Checklist persists across sessions (if user logs out and back in)

**Story 3: Celebrate checklist completion**
As a new user, I want to receive positive feedback when I complete the checklist, so I feel confident using the product.

**Acceptance Criteria:**
- [ ] When user completes all 3 steps, celebration modal appears
- [ ] Message: "You're all set! Here's what to do next: [suggested next actions]"
- [ ] Confetti animation (optional, nice-to-have)

4. 记录约束和边缘情况

• 技术约束： 平台限制、浏览器支持等
• 边缘情况： 如果用户跳过第 2 步怎么办？如果用户没有按顺序完成各步骤怎么办？

第 7 阶段的产出

• Epic 假设： 可测试的陈述
• 用户故事： 3-10 个带验收标准的故事
• 约束： 技术限制、边缘情况

---

第 8 阶段：范围外事项与依赖项（30 分钟）

目标： 明确哪些内容不会构建，以及依赖哪些事项。

活动

1. 记录范围外事项

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

示例：

## 8. Out of Scope

**Not included in this release:**
- **Advanced onboarding personalization** (e.g., different checklists per persona) — Adds complexity, test simple version first
- **Video tutorials embedded in checklist** — Resource-intensive, validate checklist concept first
- **Gamification (badges, points)** — Nice-to-have, focus on core workflow guidance

**Future consideration:**
- Mobile-optimized onboarding (desktop-first for now)

2. 记录依赖项

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

示例：

## 9. Dependencies & Risks

### Dependencies
- **Design:** Wireframes for checklist UI (ETA: Week 1)
- **Engineering:** No technical dependencies (uses existing modals framework)

### Risks & Mitigations
- **Risk:** Users dismiss checklist immediately, never see it
  - **Mitigation:** Track dismissal rate; if >50%, iterate on messaging or timing
- **Risk:** Checklist steps are too generic, don't resonate with all personas
  - **Mitigation:** Start with primary persona (Solo Entrepreneur Sam), personalize later

3. 记录待解决问题

• 未解决的决策： 需要探索或讨论的方面

示例：

## 10. Open Questions

- Should checklist be mandatory or optional? (Decision: Optional, dismissible)
- Should we A/B test checklist vs. no checklist? (Decision: Yes, show to 50% of new users)
- What happens if user completes steps out of order? (Decision: Allow any order, update checklist dynamically)

第 8 阶段的产出

• 范围外事项： 不会构建的内容
• 依赖项： 开始之前所需的事项
• 风险： 潜在阻碍及缓解措施
• 待解决问题： 未解决的决策

---

完整工作流：端到端总结

Day 1:
├─ Phase 1: Executive Summary (30 min)
├─ Phase 2: Problem Statement (60 min)
│  └─ Use: skills/problem-statement/SKILL.md
├─ Phase 3: Target Users & Personas (30 min)
│  └─ Use: skills/proto-persona/SKILL.md
└─ Phase 4: Strategic Context (45 min)
   └─ Use: skills/tam-sam-som-calculator/SKILL.md (optional)

Day 2:
├─ Phase 5: Solution Overview (60 min)
│  └─ Use: skills/user-story-mapping-workshop/SKILL.md (optional)
├─ Phase 6: Success Metrics (30 min)
└─ Phase 7: User Stories & Requirements (90-120 min)
   ├─ Use: skills/epic-hypothesis/SKILL.md
   ├─ Use: skills/epic-breakdown-advisor/SKILL.md
   └─ Use: skills/user-story/SKILL.md

Day 3:
├─ Phase 8: Out of Scope & Dependencies (30 min)
└─ Review & Refine (60 min)
   └─ Read full PRD, polish, get feedback

Day 4 (Optional):
└─ Stakeholder Review & Approval
   └─ Present PRD to stakeholders, incorporate feedback

总投入时间：

• 快速通道： 1.5-2 天（简单功能，需求明确）
• 常规： 2-3 天（包括探索总结、利益相关者评审）
• 复杂： 3-4 天（重大计划、多个用户画像、大量用户故事）

---

示例

完整 PRD 示例请参阅 examples/sample.md。

简短示例片段：

## 2. Problem Statement
- 60% of trial users drop off in first 24 hours
## 6. Success Metrics
- Activation rate: 40% → 60%

常见陷阱

陷阱 1：独自撰写 PRD

症状： PM 独自撰写 PRD，然后向团队展示完成的文档

后果： 团队缺乏认同，也不理解背后的理由

解决方法： 与设计和工程团队协作完成第 7 阶段（用户故事）；定稿前评审 PRD 草稿

---

陷阱 2：问题陈述缺乏证据

症状： “我们认为用户遇到了这个问题”（没有数据或引述）

后果： 团队质疑问题是否真实存在

解决方法： 使用 skills/discovery-process/SKILL.md 中的探索洞察；加入客户引述、分析数据和支持工单

---

陷阱 3：解决方案规定得过于具体

症状： PRD 指定了确切的 UI、像素尺寸和按钮颜色

后果： 削弱设计协作，使 PRD 变成瀑布式规格说明

解决方法： 第 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，《Inspired》（2017）——产品规格原则
• Amazon，《Working Backwards》（PR/FAQ 格式）——PRD 的替代方案

Dean 的工作

• [如果 Dean 有 PRD 模板，请在此添加链接]

---

技能类型： 工作流 建议文件名： prd-development.md 建议放置位置： /skills/workflows/ 依赖项： 在 8 个阶段中编排 8 个以上的组件技能和交互式技能