---

name: "PM Master" title: "产品经理综合技能" summary: "整合需求分析、PRD撰写、产品策略、用户研究、优先级排序、敏捷执行等全栈产品管理能力" description: > 需求分析、PRD编写、产品需求文档、详细设计、BRD、MRD、PRD模板、用户故事、用户访谈、需求挖掘、痛点分析、功能设计、KANO模型、Y模型、5W1H、优先级排序、需求池管理、写过需求、写PRD、做需求分析、产品设计、产品策略、SWOT分析、波特五力、PESTLE、安索夫矩阵、商业模式画布、价值主张、产品愿景、OKR制定、Sprint规划、回顾会、发布说明、干系人管理、竞品分析、市场调研、用户研究、机会解决方案树、指标看板、测试场景、头脑风暴、假设验证 read_when:

• 用户需要进行需求分析或撰写需求文档
• 用户要求生成PRD（产品需求文档）
• 用户需要详细设计文档（DDD）
• 用户需要产品策略分析
• 用户需要用户访谈设计
• 用户需要优先级排序
• 用户需要Sprint规划
• 用户需要OKR制定
• 用户需要市场分析或竞品分析
• 用户需要头脑风暴创意
• 用户需要假设验证
• 任何涉及产品管理全流程的场景

---

产品经理综合技能 - PM Master

本技能整合了来自 Dean Peters、Teresa Torres、Marty Cagan 等产品大师的40+种方法论框架， 覆盖从产品战略、需求分析、用户研究、PRD撰写、优先级排序到敏捷执行的全流程。

---

技能概览

---

一、需求分析方法论

1.1 核心分析方法

KANO模型 - 需求分类

Y模型 - 深层挖掘

用户需求 (What) → 目标动机 (Why) → 人性本质 → 产品方案 (How)
     ↑                              ↑                   ↓
     ←──── 验证核心假设 ←───────────────────────────────

• 用户提出的是解决方案（Y的上端）
• 需要深挖背后的真实动机（Y的下端）
• 再重构更优方案

5W1H分析法

• Who：谁用？（多角色、权限控制）
• Where：什么环境下用？（移动端/PC、网络环境）
• When：什么时候用？（高频/低频）
• Why：为什么要做？（解决什么痛点）
• What：具体做什么？（功能本体）
• How：如何实现？（前端交互、后端逻辑）

JTBD需求挖掘（功能/社交/情感三层）

1.2 伪需求识别

"人们其实不想买一个四分之一英寸的钻头，他们只想要一个四分之一英寸的洞！"

识别伪需求的关键：

1. 追问"为什么"：用户说"想要一匹更快的马"，真实需求是"更快的交通工具"
2. 观察用户行为：不仅听用户说什么，更要看用户怎么做
3. 验证普遍性：是个别用户的需求还是群体需求
4. 小范围测试：通过MVP或灰度发布验证

1.3 需求分析输出模板

【需求分析摘要】

**核心业务目标**：...
**用户角色矩阵**：
| 角色 | 核心诉求 | 痛点 |
|------|---------|------|
| ... | ... | ... |

**关键功能域拆解**：
- 功能域A：...
- 功能域B：...

**需求优先级（KANO）**：
- 基础型：...
- 期望型：...
- 兴奋型：...

**待澄清风险/模糊点**：
- ...

---

二、产品策略框架

2.1 产品策略画布（9模块）

2.2 SWOT分析

战略应用：

• 进攻（Build）：优势 + 机会
• 防御（Defend）：劣势 + 威胁
• 转型（Pivot）：探索改变竞争格局的机会

2.3 波特五力模型

2.4 PESTLE分析

2.5 安索夫矩阵

2.6 商业模式画布（BMC）

2.7 精益画布

---

三、用户研究与访谈

3.1 用户访谈脚本设计

开场白（2-3分钟）

• 介绍自己和访谈目的（学习，不是销售）
• 设定预期："没有对错之分，我们只是希望从您的经历中学习。"
• 征得录音许可（如适用）

破冰阶段（5分钟）

• "请介绍一下您的工作职责，以及典型的一天是什么样的。"
• 目标：建立信任，理解受访者背景

核心探索：JTBD（15-20分钟）

当前情境与行为（过去时态）：

• "请带我回顾一下您上次[事情]的经过。"
• "您用了哪些工具或方法？"
• "花了多长时间？有哪些人参与？"

痛点与挫败感：

• "那个过程中最难的地方是什么？"
• "如果有一根魔法棒，您希望改变什么？"

期望产出：

• "对您来说，这个领域'做得好'是什么样子？"

支付意愿：

• "您目前在这上面花了多少时间/金钱？"

追问技巧

• "能再说详细一点吗？" — 展开任何话题
• "为什么？" — 深挖根本原因
• "能举个具体例子吗？" — 从观点转向事实
• "接下来发生了什么？" — 顺着故事追问

老妈测试原则

• 询问他们的生活，而非你的想法
• 询问过去的事，而非未来
• 少说多听 — 80/20分配
• 访谈过程中绝不推销
• 关注强烈情绪 — 它们代表真实痛点

3.2 访谈记录模板

**日期**：[访谈日期]
**参与者**：[姓名和职位]
**背景**：[受访者背景]

**当前解决方案**：[他们目前使用什么]

**满意的地方**：
- [JTBD、期望产出、重要性及满意度]

**不满的地方**：
- [JTBD、期望产出、重要性及满意度]

**核心洞察**：
- [意外发现或值得关注的引用]

**行动项**：
- [日期、负责人、行动内容]

---

四、PRD文档结构

4.1 完整PRD模板（8大模块）

# [项目名称] 产品需求文档

## 1. 文档概览
| 项目 | 内容 |
|------|------|
| 版本号 | V1.0.0 |
| 状态 | [草稿/评审中/已生效] |
| 创建日期 | YYYY-MM-DD |
| 作者 | [姓名] |
| 审核人 | [姓名] |

## 2. 修订记录
| 版本 | 日期 | 修改人 | 修改内容 |
|------|------|--------|----------|

## 3. 背景与目标
- **业务背景**：为什么要做这个项目？
- **产品目标**（SMART）：
  - 具体、可量化、有时限
  - 如："将注册转化率提升至50%"
- **用户画像**：涉及的角色及核心诉求

## 4. 范围定义
### 4.1 包含范围 (In Scope)
- [明确要实现的功能]

### 4.2 不包含范围 (Out of Scope)
- [明确不做的内容]

### 4.3 MVP边界
- **Must**：必须交付的最小闭环
- **Should**：可做但不影响闭环的增强项
- **Could**：可选加分项

## 5. 价值主张
针对每个目标细分市场：
- **现状（What before）**：客户当前的处境
- **解决方案（How）**：产品如何解决问题
- **改变后（What after）**：改善后的结果
- **替代方案（Alternatives）**：客户今天用什么

## 6. 用户故事
| 角色 | 动作 | 价值 | 验收标准 |
|------|------|------|----------|
| [用户A] | [操作] | [收益] | 1. 界面...<br>2. 数据校验... |

## 7. 详细功能说明
### 7.1 [模块名称]
- **功能描述**：一句话说明
- **前置条件**：需先完成什么
- **主流程**：
  1. 用户点击...
  2. 系统校验...
  3. 执行动作...
- **异常流程**：
  - 网络超时：...
  - 无权限：...
- **后置条件**：操作后的系统状态

## 8. 非功能需求
- **性能**：响应时间 ≤ 200ms，支持 1000 QPS
- **安全**：敏感数据加密，防越权
- **兼容**：iOS 14+ / Android 10+
- **可靠**：99.9% 可用性

## 9. 数据埋点
| 埋点位置 | 事件ID | 触发条件 | 上报字段 |
|----------|--------|----------|----------|
| 详情页 | click_buy | 点击购买 | goods_id, price |

## 10. 风险评估
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|----------|
| ... | ... | ... | ... |

4.2 PRD撰写要点

1. 量化表述：避免"大概""可能""尽量"
   • 错误："页面加载尽量快"
   • 正确："3G网络下商品详情页加载时间≤2秒"
2. 逻辑闭环：每个正向操作都要有逆向逃生通道
3. 边界穷尽：考虑所有异常情况
4. 图文并茂：优先使用流程图、UML图

---

五、详细设计文档（DDD）

# [模块名称] 详细设计说明书

## 1. 设计概述
[用技术语言描述本模块要解决的问题]

## 2. 模块结构与依赖
- **入口层**：Controller / API Endpoint
- **业务逻辑层**：Service 职责划分
- **数据持久层**：DAO/Repository

## 3. 核心逻辑流程图

```mermaid
graph TD
    A[用户请求] --> B{权限校验}
    B -->|通过| C[参数校验]
    B -->|失败| F[返回403]
    C --> D[业务处理]
    D --> E[数据持久化]
    E --> G[返回结果]

4. 接口定义

4.1 [接口名称]

• 请求方式：POST
• 请求路径：/api/v1/xxx
• 请求参数：...
• 响应参数：...
• 错误码：...

5. 数据模型

5.1 数据库表设计

5.2 缓存设计

• 缓存Key：xxx:{id}
• TTL：3600s
• 更新策略：Cache Aside

6. 异常处理

---

## 六、用户故事编写

### 6.1 用户故事模板

标题：[功能名称]

描述：作为 [用户角色]，我想要 [操作]，以便 [收益]。

设计：[设计文件链接]

验收标准：

1. [清晰、可测试的标准]
2. [可观察的行为]
3. [系统正确验证]
4. [边界情况处理]

### 6.2 INVEST标准

| 标准 | 说明 |
|------|------|
| **I**ndependent | 独立，不依赖其他故事 |
| **N**egotiable | 可协商，非固定规格 |
| **V**aluable | 对用户有价值 |
| **E**stimable | 可估算工作量 |
| **S**mall | 规模适中 |
| **T**estable | 可测试验收 |

### 6.3 用户故事示例

**标题**：最近浏览区域

**描述**：作为在线购物者，我想要在商品详情页看到「最近浏览」区域，以便轻松回顾我曾考虑过的商品。

**验收标准**：
1. 对于浏览过至少1件商品的用户，「最近浏览」区域显示在商品详情页底部
2. 对于本次会话访问第一件商品的用户，该区域不显示
3. 当前商品被排除在展示列表之外
4. 区域显示商品图片、标题和价格
5. 每张卡片标注浏览时间（如"5分钟前"）
6. 点击卡片跳转至对应商品详情页

---

## 七、测试场景设计

### 7.1 测试场景模板

测试场景：[场景名称]

测试目标：[验证什么]

初始条件：

• [系统状态]
• [所需数据]
• [用户设置]

测试步骤：

1. [操作1] → [预期结果1]
2. [操作2] → [预期结果2]
3. [操作3] → [预期结果3]

预期结果：

• [可观察结果1]
• [可观察结果2]

### 7.2 测试场景示例

**测试场景**：在商品详情页查看最近浏览的商品

**测试目标**：验证「最近浏览」区域正确显示，排除当前商品

**初始条件**：
- 用户已登录
- 用户本次会话浏览过至少2件商品

**测试步骤**：
1. 进入任意商品详情页 → 「最近浏览」区域应出现
2. 滚动至页面底部 → 验证商品卡片显示
3. 检查当前商品 → 不在最近浏览列表中
4. 点击商品卡片 → 跳转至对应详情页

---

## 八、优先级评估框架

### 8.1 框架选择决策树

产品处于什么阶段？ ├── 早期/PMF探索期 → ICE（轻量快速） ├── 成长期/有用户数据 → RICE（数据驱动） ├── 功能分类需求 → Kano Model └── 敏捷开发团队 → MoSCoW / Value-Effort矩阵

### 8.2 机会评分（Dan Olsen）

机会评分 = 重要性 × (1 − 满意度)

- 归一化至0-1范围
- 高重要性 + 低满意度 = 最高机会
- 在"重要性 vs 满意度"图上，左上象限是黄金区域

### 8.3 ICE评分法

| 维度 | 说明 | 计算 |
|------|------|------|
| **I**mpact | 影响力 | 机会评分 × 客户数量 |
| **C**onfidence | 置信度 | 我们有多确定？(1-10) |
| **E**ase | 简易度 | 实施难度 (1-10) |

**ICE得分 = I × C × E**

### 8.4 RICE评分法

| 维度 | 说明 |
|------|------|
| **R**each | 触达范围（受影响用户数） |
| **I**mpact | 影响力 |
| **C**onfidence | 置信度 (0-100%) |
| **E**ffort | 工作量（人月） |

**RICE得分 = (R × I × C) / E**

### 8.5 MoSCoW法则

| 类别 | 含义 | 比例 |
|------|------|------|
| **Must** | 必须有 | 60% |
| **Should** | 应该有 | 20% |
| **Could** | 可以有 | 15% |
| **Won't** | 本次不做 | 5% |

### 8.6 9大框架对比

| 框架 | 适用场景 | 核心特点 |
|------|---------|---------|
| 艾森豪威尔矩阵 | 个人任务 | 紧急 vs 重要 |
| 影响力 vs 工作量 | 快速分类 | 2×2矩阵 |
| 风险 vs 回报 | 计划评估 | 考虑不确定性 |
| **机会评分** | 客户问题 | **推荐** |
| Kano模型 | 理解期望 | 需求分类 |
| 加权决策矩阵 | 多因素决策 | 标准赋权 |
| **ICE** | 快速排序 | **推荐** |
| **RICE** | 规模化分析 | 增加触达范围 |
| MoSCoW | 需求范围 | 敏捷友好 |

---

## 九、风险识别与分析

### 9.1 预死亡分析（Pre-Mortem）

> 被研究证明能提升30%问题发现率

#### 三类风险分类

| 类型 | 定义 | 处理 |
|------|------|------|
| **老虎（Tigers）** | 真实问题，可能让项目脱轨 | 必须采取行动 |
| **纸老虎（Paper Tigers）** | 被夸大的担忧 | 记录以对齐干系人 |
| **大象（Elephants）** | 未被说出的隐忧 | 值得深入调查 |

#### 紧迫程度分级

| 级别 | 含义 | 示例 |
|------|------|------|
| **发布阻断** | 发布前必须解决 | 核心功能损坏 |
| **快速跟进** | 发布后30天内解决 | 性能问题 |
| **持续跟踪** | 监控，必要时解决 | 边界情况 |

### 9.2 假设验证四维度

| 维度 | 问题 |
|------|------|
| **价值（Value）** | 能为客户创造价值吗？ |
| **可用性（Usability）** | 用户能弄清楚如何使用吗？ |
| **商业可行性（Viability）** | 市场、销售、财务能支持吗？ |
| **技术可行性（Feasibility）** | 能用现有技术构建吗？ |

---

## 十、产品探索工具

### 10.1 机会解决方案树（OST）

                ┌─────────────┐
                │ 期望产出    │
                │（北极星指标）│
                └──────┬──────┘
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
     ┌────────┐   ┌────────┐   ┌────────┐
     │ 机会1  │   │ 机会2  │   │ 机会3  │
     │(痛点)  │   │(痛点)  │   │(痛点)  │
     └───┬────┘   └────────┘   └────────┘
         │
┌────────┼────────┐
▼        ▼        ▼

┌──────┐ ┌──────┐ ┌──────┐ │方案1 │ │方案2 │ │方案3 │ └──┬───┘ └──────┘ └──────┘ │ ▼ ┌────────┐ │ 实验 │ └────────┘

**核心原则**：
- 一次聚焦一个产出
- 机会，不是功能
- 比较与对比（每个机会3+方案）
- 探索不是线性的

### 10.2 产品铁三角

> 产品经理 + 设计师 + 工程师共同参与探索

- "最好的创意往往来自工程师"
- 每周更新OST
- 实验失败时循环回来

---

## 十一、OKR与目标管理

### 11.1 OKR模板

目标：让新用户享受轻松愉快的引导体验

关键成果：

• KR1：引导调研CSAT评分 >= 75%
• KR2：66%以上的用户在两天内完成引导
• KR3：平均首次价值实现时间(TTV) <= 20分钟

### 11.2 OKR vs KPI vs 北极星指标

| 概念 | 说明 |
|------|------|
| **OKR** | 鼓舞人心的目标 + 可衡量的关键成果 |
| **KPI** | 长期跟踪的核心量化指标 |
| **北极星指标** | 单一、以客户为中心、成功领先指标 |

**关系**：关键成果可以是KPI；OKR的KR可以表达北极星指标的变化

---

## 十二、Sprint规划与管理

### 12.1 Sprint规划流程

1. 估算团队容量

   • 成员数量 × 可用时间
   • 历史速率（3个Sprint平均）
   • 预留15-20%缓冲

2. 评审并选取故事

   • 从优先级列表取用
   • 验证"就绪定义"
   • 达到容量上限停止

3. 映射依赖关系

   • 识别外部依赖
   • 合理排序
   • 标注关键路径

4. 创建Sprint计划

### 12.2 Sprint计划模板

Sprint目标：[一句话描述成功的样子] 时长：[2周] 团队容量：[X故事点] 已承诺：[Y故事点] 缓冲：[剩余容量]

故事列表：

1. [故事] — [故事点] — [负责人] — [依赖项] ...

风险：

• [风险] → [缓解措施]

### 12.3 Sprint回顾格式

#### 格式A — Start/Stop/Continue
- **开始**：我们应该开始做什么？
- **停止**：我们应该停止做什么？
- **继续**：哪些做得好，应该保持？

#### 格式B — 4Ls
- **Liked**：团队喜欢什么？
- **Learned**：获得了哪些新知识？
- **Lacked**：缺少了什么？
- **Longed For**：希望拥有什么？

#### 格式C — 帆船模型
- **风（推进力）**：什么在驱动我们前进？
- **锚（阻力）**：什么在拖慢我们？
- **礁石（风险）**：前方有哪些危险？
- **岛屿（目标）**：我们想要到达哪里？

---

## 十三、干系人管理

### 13.1 权力×利益方格

| | 高关注度 | 低关注度 |
|--|---------|---------|
| **高权力** | **重点管理**<br>定期一对一<br>参与决策 | **保持满意**<br>定期更新<br>仅上报关键问题 |
| **低权力** | **及时告知**<br>定期状态更新<br>收集反馈 | **持续监控**<br>轻量级更新<br>按需响应 |

### 13.2 沟通计划模板

| 干系人 | 角色 | 权力 | 关注度 | 策略 | 频率 | 渠道 |
|--------|------|------|--------|------|------|------|
| ... | ... | ... | ... | ... | ... | ... |

---

## 十四、数据指标体系

### 14.1 北极星指标框架

北极星指标（North Star） ├── 输入指标（3-5个） │ ├── 输入指标1 │ └── 输入指标2 ├── 健康指标 │ ├── 延迟 │ ├── 错误率 │ └── NPS └── 业务指标 ├── MRR ├── CAC ├── LTV └── 流失率

### 14.2 好指标的4个标准

1. **易理解** — 形成共同语言
2. **可比较** — 随时间变化
3. **是比率** — 比绝对数字更具洞察力
4. **能改变行为** — "如果一个指标不会改变你的行为，它就是一个糟糕的指标"

### 14.3 AARRR海盗指标

| 阶段 | 指标 | 说明 |
|------|------|------|
| **A**cquisition | 获取 | 用户如何发现你？ |
| **A**ctivation | 激活 | 用户第一次体验好吗？ |
| **R**etention | 留存 | 用户会回来吗？ |
| **R**eferral | 推荐 | 用户会推荐别人吗？ |
| **R**evenue | 收入 | 你如何盈利？ |

### 14.4 指标看板定义模板

| 指标 | 定义 | 数据来源 | 可视化 | 目标值 | 告警阈值 |
|------|------|----------|--------|--------|----------|
| [名称] | [精确计算] | [出处] | [类型] | [目标] | [条件] |

---

## 十五、定价策略

### 15.1 定价模型选择

| 模型 | 最适合 | 示例 |
|------|--------|------|
| 统一费率 | 简单产品 | Basecamp |
| 按席位 | 协作工具 | Slack、Figma |
| 按用量 | 基础设施、API | AWS、Twilio |
| 分级定价 | 有明显细分 | 多数SaaS |
| 免费增值 | 有网络效应 | Spotify、Notion |
| 价值定价 | 高影响力企业 | Salesforce |

### 15.2 分层定价设计

**锚定定价**：让最受欢迎的套餐看起来是显而易见的最优选择

---

## 十六、发布说明

### 16.1 发布说明模板

```markdown
# [产品名称] — [版本 / 日期]

## 新功能
- **[功能名称]**：[1-2句话描述及重要性]

## 改进
- **[改进方向]**：[什么变得更好了]

## 缺陷修复
- 修复了 [用户语言描述的问题]

## 破坏性变更（如有）
- **需要操作**：[用户需要做什么]

16.2 撰写原则

• 以用户收益为先，而非技术变更
• 使用通俗语言，避免行话
• 每个条目1-3句话
• 技术描述 → 用户版本示例：
  • "实现Redis缓存层" → "仪表板加载速度提升最高3倍"

---

十七、会议与文档管理

17.1 会议摘要模板

## 会议摘要

**日期与时间**：[日期和时间]
**参与者**：[姓名和角色]
**主题**：[简短标题]

**摘要**
- **要点1**：[关键讨论]
- **要点2**：[关键讨论]

**行动项**
| 截止日期 | 负责人 | 行动内容 |
|---------|-------|---------|
| [日期] | [姓名] | [内容] |

**已做决策**
- [决策1]
- [决策2]

**待解问题**
- [问题1]

---

十八、一页纸速查模板

一页纸PRD

【Goal】______（可量化的核心目标）
【Why】______（用户痛点+业务价值）
【Scope】
- Must：______
- Should：______
- Not now：______
【User Story】
- As a [角色], I want [功能], so that [价值]
【Key Flow】
______（核心流程，3-5步）
【Acceptance Criteria】
1. ______
2. ______
3. ______
【Metrics】
- 业务指标：______
- 技术指标：______
【Risks】
- ______：应对措施______

---

十九、常见错误与避坑

---

二十、与其他技能的关系

• investigation-first：用于调查阶段，占有第一手材料
• practice-cognition：用于验证阶段，检验假设和方案
• contradiction-analysis：用于识别需求中的核心矛盾
• overall-planning：用于多需求并行时的整体规划
• mass-line：用于收集多方意见，整合成可执行方案

---

延伸阅读资源

• 《Inspired》— Marty Cagan
• 《Continuous Discovery Habits》— Teresa Torres
• 《The Lean Product Playbook》— Dan Olsen
• 《Jobs to be Done》— Anthony Ulwick
• 《创新者的窘境》— Clayton Christensen
• 《Radical Focus》— Christina Wodtke（OKR）
• 《商业模式新生代》— Alexander Osterwalder

---

踩坑经验

（以下由AI在实际调用中自动积累）