prd-development

目的

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

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

核心概念

什么是 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）

---

引导流程

以引导式对话运行此工作流时，请遵循以下交互流程：

• 先用一句话简要说明，然后提供一种开始方式：引导式（每次一个问题）、集中提供背景信息（用户一次性粘贴所有内容）或最佳猜测（仅根据主题继续）。
• 每轮用通俗语言提出一个问题；等待用户回答后再提出下一个问题。绝不一次提出多个问题。
• 为每个问题标注进度（例如，Context Qx/8 和 Scoring Qx/5）。
• 每个问题都提供带编号的选项和推荐的默认选项；适用时加入 Other (specify)。
• 妥善处理打断，并允许用户暂停后继续。
• 在决策节点，提供带编号的建议选项，而非只给出一种观点。

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

应用

使用 template.md 获取完整的填写结构。

此工作流通过多个组件技能和交互式技能，在 2-4 天内协调完成 8 个阶段。

---

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

**目标：**为快速浏览者撰写一段概述。

活动

1. 起草执行摘要

• 格式：“我们正在为[目标用户]构建[解决方案]，以解决[问题]，从而带来[影响]。”

• 示例：

  “我们正在为非技术型小企业主构建一份引导式入门清单，以解决因缺乏指导而导致 60% 的用户在最初 24 小时内流失的问题，从而将激活率从 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 的产出
• 待完成任务： 如果动机是关键因素
• 使用： 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：使用 SaaS 工具的 500 万家企业。SOM：目标细分市场中的 50 万名个体创业者。改进入门体验有望释放 SAM 的 30%（150 万潜在客户）。”

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

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

  “竞争对手（Competitor A、B）提供引导式入门体验。在退出调查中，用户将我们缺乏引导列为流失原因。”

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

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

  “第四季度流失率飙升至 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. 编写史诗假设

• 用途： 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. 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 的产出

• 史诗假设： 可测试的陈述
• 用户故事： 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 天（大型项目、多种用户画像、大量用户故事）

---

Notion MCP（可选）

完成第 8 阶段并将完整 PRD 提交到聊天中后，尝试调用 notion-query-data-sources。如果返回结果，则表示已连接 Notion——运行保存流程。如果失败或不可用，则跳过并附加提示。

如果已连接 Notion：

PRD 是持续更新、协作编写的文档——Notion 是存放它们的理想位置。保存完整 PRD，以便整个团队阅读、评论和跟踪：

1. 调用 notion-search，在工作区中查找现有的 Product Specs 或 PRDs 数据库
2. 如果找到：调用 notion-create-pages，在该数据库中创建新页面并保存 PRD，同时设置以下属性——Name、Status（选择：Draft / In Review / Approved / Shipped）、Owner（人员）、Launch Date（日期）、Epic（富文本）
3. 如果未找到：调用 notion-create-database，使用这些属性初始化 Product Specs 数据库，然后调用 notion-create-pages 保存 PRD
4. 调用 notion-get-users，将负责人姓名匹配到工作区用户，并在 Owner 属性中指定该用户
5. 对于跨 8 个阶段的修订：调用 notion-update-page 更新现有 PRD 页面，而不是创建重复页面——按 Name 匹配
6. 确认：“✅ PRD 已保存到 Notion → [页面标题]。状态：Draft。请直接在 Notion 中指定评审人。”

如果未连接：

💡 未连接 Notion — PRD 仅输出到聊天中。连接 Notion MCP connector，即可自动将 PRD 保存到共享的产品规格数据库，供团队评论和跟踪。设置方法：notion-mcp-server

---

示例

完整 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、像素尺寸和按钮颜色

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

解决方法： 第 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 的替代方案 **依赖项：**在 8 个阶段中编排 8 种以上的组件和交互式技能