447 lines
13 KiB
Markdown
447 lines
13 KiB
Markdown
# Product Manager Skills 完整使用指南
|
||
|
||
> 作者：沈盟 (程序员猫舍)
|
||
> 来源：Telegra.ph
|
||
> 发布时间：2026年3月27日
|
||
> 链接：https://telegra.ph/Product-Manager-Skills-%E5%AE%8C%E6%95%B4%E4%BD%BF%E7%94%A8%E6%8C%87%E5%8D%97-03-26
|
||
|
||
---
|
||
|
||
## 1. 总体概述
|
||
|
||
### 1.1 什么是 Product Manager Skills？
|
||
|
||
这是一套**产品管理框架的数字化封装**，包含 46 个独立但相互关联的技能（Skill），每个技能对应产品管理工作中的一个具体环节。
|
||
|
||
**核心理念**：
|
||
> 用户不是买产品，而是"雇佣"产品来完成某项工作（Jobs-To-Be-Done）。
|
||
|
||
**设计目标**：
|
||
- 📚 将经典产品管理方法论（JTBD、OST、精益 UX 等）转化为可执行的 AI 工作流
|
||
- 🔗 打通产品发现→定义→交付→验证的完整链条
|
||
- 🎯 避免"功能工厂"陷阱，确保团队解决正确的问题
|
||
|
||
### 1.2 与 JTBD 的关系
|
||
|
||
JTBD (Jobs-To-Be-Done) 是这套技能体系的**核心思想基础**：
|
||
|
||
```
|
||
JTBD 理论 → 理解用户"雇佣"产品完成的工作
|
||
↓
|
||
产品发现 → 搞清楚用户真正的需求是什么
|
||
↓
|
||
产品定义 → 决定做什么来解决这些需求
|
||
↓
|
||
产品交付 → 把解决方案做出来
|
||
↓
|
||
产品验证 → 检查是否真的解决了问题
|
||
```
|
||
|
||
这 46 个技能就是沿着这个链条展开的**工具箱**。
|
||
|
||
### 1.3 技能分类总览
|
||
|
||
46 个技能分为 5 大类：
|
||
- 📊 用户研究类 (5 个)
|
||
- 📈 市场分析类 (6 个)
|
||
- 🎯 产品定义类 (8 个)
|
||
- 📝 文档输出类 (6 个)
|
||
- 📋 战略规划类 (7 个)
|
||
- 🎓 高阶能力类 (14 个)
|
||
|
||
---
|
||
|
||
## 2. 技能全景图
|
||
|
||
### 2.1 产品管理工作流地图
|
||
|
||
```
|
||
阶段 1: 产品发现 (Discovery)
|
||
目标：搞清楚用户是谁？问题是什么？值不值得做？
|
||
─────────────────────────────────────────────
|
||
proto-persona → jobs-to-be-done → customer-journey-map
|
||
初步画像 用户待办 用户旅程
|
||
|
||
↓ ↓ ↓
|
||
|
||
company-research → discovery-interview → tam-sam-som-calculator
|
||
竞品调研 访谈准备 市场规模
|
||
```
|
||
|
||
```
|
||
阶段 2: 产品定义 (Definition)
|
||
目标：搞清楚做什么？不做什么？优先级？
|
||
─────────────────────────────────────────────
|
||
problem-framing → opportunity-solution-tree → prioritization-advisor
|
||
问题画布 机会方案树 优先级建议
|
||
|
||
↓ ↓ ↓
|
||
|
||
positioning-statement → epic-hypothesis → user-story-mapping
|
||
定位陈述 史诗假设 故事地图
|
||
```
|
||
|
||
```
|
||
阶段 3: 产品交付 (Delivery)
|
||
目标：怎么写文档？怎么拆任务？怎么验收？
|
||
─────────────────────────────────────────────
|
||
prd-development → user-story → storyboard
|
||
需求文档 用户故事 故事板
|
||
|
||
↓ ↓ ↓
|
||
|
||
press-release → epic-breakdown → lean-ux-canvas
|
||
新闻稿 史诗拆分 精益 UX
|
||
```
|
||
|
||
```
|
||
阶段 4: 产品验证 (Validation)
|
||
目标：做得怎么样？要不要调整？下一步？
|
||
─────────────────────────────────────────────
|
||
business-health-diagnostic → feature-investment-advisor → roadmap-planning
|
||
业务诊断 投资建议 路线图规划
|
||
```
|
||
|
||
---
|
||
|
||
## 3. 核心技能详解
|
||
|
||
### 3.1 jobs-to-be-done（用户待办任务）
|
||
|
||
**核心功能**：系统性地探索用户真正想完成的工作，而非表面需求。
|
||
|
||
**解决的问题**：
|
||
- 用户说的"想要更快"到底是什么意思？
|
||
- 为什么有些功能上线后数据没变化？
|
||
- 如何避免做错功能？
|
||
|
||
**输出结构**：
|
||
```markdown
|
||
## Jobs-to-be-Done 分析
|
||
|
||
### 1. Customer Jobs（用户想完成的事）
|
||
#### Functional Jobs（功能层面）
|
||
#### Social Jobs（社会层面）
|
||
#### Emotional Jobs（情感层面）
|
||
|
||
### 2. Pains（痛苦）
|
||
#### Challenges（障碍）
|
||
#### Costliness（代价）
|
||
#### Common Mistakes（常见错误）
|
||
#### Unresolved Problems（未解决问题）
|
||
|
||
### 3. Gains（收益）
|
||
#### Expectations（期待）
|
||
#### Savings（节省）
|
||
#### Adoption Factors（采用因素）
|
||
#### Life Improvement（生活改善）
|
||
```
|
||
|
||
**使用示例**：
|
||
- 场景：老板说"用户想要更快的开票速度"
|
||
- 调用 jobs-to-be-done 后发现：
|
||
- 表面需求："更快开票"
|
||
- 真实 JTBD："从完工到收款的整个流程别耽误"
|
||
- 真正机会：自动催款 + 收款跟踪，而不是"一键开票"按钮
|
||
|
||
---
|
||
|
||
### 3.2 opportunity-solution-tree（机会方案树）
|
||
|
||
**核心功能**：从模糊的需求到结构化的探索，避免"功能工厂"陷阱。
|
||
|
||
**解决的问题**：
|
||
- 老板/客户直接说"我要这个功能"怎么办？
|
||
- 如何确保团队在解决问题，而不是盲目堆功能？
|
||
- 如何系统性地探索多种解决方案？
|
||
|
||
**输出结构**：
|
||
```
|
||
期望结果 (Outcome)
|
||
│
|
||
├── 机会 1 (问题/需求)
|
||
│ ├── 方案 1 (实验)
|
||
│ └── 方案 2 (实验)
|
||
│
|
||
├── 机会 2 (问题/需求)
|
||
│ ├── 方案 1 (A/B测试)
|
||
│ └── 方案 2 (可用性测试)
|
||
│
|
||
└── 机会 3 (问题/需求)
|
||
└── ...
|
||
```
|
||
|
||
---
|
||
|
||
### 3.3 prd-development（产品需求文档）
|
||
|
||
**核心功能**：将发现阶段的洞察转化为工程可执行的 PRD 文档。
|
||
|
||
**输出结构**：
|
||
```markdown
|
||
# [功能名称] PRD
|
||
|
||
## 1. 执行摘要
|
||
## 2. 问题陈述（谁？问题？证据？）
|
||
## 3. 目标用户与画像
|
||
## 4. 战略背景（业务目标、市场机会、竞争格局）
|
||
## 5. 方案概述
|
||
## 6. 成功指标
|
||
## 7. 用户故事与需求
|
||
## 8. 不在范围内
|
||
## 9. 依赖与风险
|
||
```
|
||
|
||
---
|
||
|
||
### 3.4 prioritization-advisor（优先级建议）
|
||
|
||
**核心功能**：根据团队阶段和上下文，选择合适的优先级框架。
|
||
|
||
**推荐框架**：
|
||
| 场景 | 推荐框架 |
|
||
|------|----------|
|
||
| 早期创业 | ICE |
|
||
| 成长期 | RICE |
|
||
| 企业/数据成熟 | WSJF |
|
||
| 简单快速 | MoSCoW |
|
||
|
||
---
|
||
|
||
### 3.5 user-story（用户故事）
|
||
|
||
**输出格式**：
|
||
```markdown
|
||
### 用户故事 [ID]
|
||
|
||
#### 用例（Mike Cohn 格式）
|
||
- **作为** [用户角色]
|
||
- **我想要** [执行的动作]
|
||
- **以便于** [期望的结果/价值]
|
||
|
||
#### 验收标准（Gherkin 格式）
|
||
- **场景**: [场景描述]
|
||
- **给定**: [前提条件]
|
||
- **当**: [触发事件]
|
||
- **那么**: [期望结果]
|
||
```
|
||
|
||
---
|
||
|
||
## 4. 技能协作工作流
|
||
|
||
### 4.1 标准产品开发生命周期
|
||
|
||
```
|
||
阶段 1: 发现 (Discovery)
|
||
1. proto-persona → 定义目标用户
|
||
2. jobs-to-be-done → 发现真实需求
|
||
3. customer-journey-map → 绘制旅程
|
||
4. tam-sam-som-calculator → 评估市场
|
||
5. discovery-interview → 用户访谈
|
||
|
||
产出：用户洞察文档 + 机会评估报告
|
||
|
||
阶段 2: 定义 (Definition)
|
||
6. problem-framing-canvas → 定义问题
|
||
7. opportunity-solution-tree → 探索方案
|
||
8. prioritization-advisor → 选择框架并排序
|
||
9. positioning-statement → 产品定位
|
||
|
||
产出：优先级排序 + 产品定位文档
|
||
|
||
阶段 3: 交付 (Delivery)
|
||
10. prd-development → 写 PRD
|
||
11. user-story-mapping → 故事地图
|
||
12. user-story → 写用户故事
|
||
13. storyboard → 画故事板
|
||
14. press-release → 写新闻稿
|
||
|
||
产出：PRD + 用户故事 + 故事板
|
||
|
||
阶段 4: 验证 (Validation)
|
||
15. business-health-diagnostic → 上线后评估
|
||
16. feature-investment-advisor → 决定下一步
|
||
17. roadmap-planning → 更新路线图
|
||
|
||
产出：健康度报告 + 更新后的路线图
|
||
```
|
||
|
||
### 4.2 技能调用依赖关系
|
||
|
||
```
|
||
jobs-to-be-done
|
||
↓
|
||
problem-framing-canvas
|
||
↓
|
||
opportunity-solution-tree
|
||
↓
|
||
prioritization-advisor
|
||
↓
|
||
prd-development
|
||
↓
|
||
user-story-mapping
|
||
↓
|
||
user-story
|
||
↓
|
||
storyboard
|
||
```
|
||
|
||
### 4.3 常见协作模式
|
||
|
||
| 模式 | 适用场景 | 技能链 |
|
||
|------|----------|--------|
|
||
| A: 新功能开发 | 完整流程 | proto-persona → jobs-to-be-done → OST → prioritization → PRD → user-story → storyboard |
|
||
| B: 体验优化 | 聚焦旅程 | customer-journey-map → problem-framing → user-story-mapping → user-story → PRD |
|
||
| C: 快速验证 | MVP 路线 | problem-framing → OST → lean-ux-canvas → press-release → user-story |
|
||
| D: 季度规划 | 战略视角 | business-health-diagnostic → product-strategy-session → altitude-horizon → roadmap |
|
||
|
||
---
|
||
|
||
## 5. 完整案例演示
|
||
|
||
### 案例背景
|
||
- **公司**：一款面向自由职业者的在线发票 SaaS
|
||
- **问题**：用户流失率高，老板要求"提升用户体验"
|
||
- **角色**：产品经理
|
||
|
||
### 第 1 步：理解用户（jobs-to-be-done）
|
||
|
||
**输入**：
|
||
- 产品类型：在线发票工具
|
||
- 目标用户：自由职业者（设计师、开发者、顾问）
|
||
- 表面问题："用户说开票太麻烦"
|
||
|
||
**关键洞察**：
|
||
> 用户说的"开票麻烦"，真实意思是"从完工到收款的整个流程太折腾"。真正的机会是**自动催款 + 收款跟踪**。
|
||
|
||
### 第 2 步：探索方案（opportunity-solution-tree）
|
||
|
||
**期望结果**：提升用户留存率 20%
|
||
|
||
**机会探索**：
|
||
- 机会 1：用户忘记催款 → 方案：自动提醒
|
||
- 机会 2：客户弄丢发票 → 方案：自助查询
|
||
- 机会 3：对账麻烦 → 方案：自动对账
|
||
|
||
### 第 3 步：确定优先级（prioritization-advisor）
|
||
|
||
**推荐框架**：RICE
|
||
|
||
**评分结果**：
|
||
1. 自动催款提醒 RICE = 45
|
||
2. 发票自助查询 RICE = 32
|
||
3. 自动对账 RICE = 28
|
||
|
||
### 第 4 步：写 PRD（prd-development）
|
||
|
||
产出完整的 PRD 文档，包含执行摘要、问题陈述、目标用户、成功指标、用户故事等。
|
||
|
||
### 第 5-7 步：拆故事 → 画故事板 → 验证结果
|
||
|
||
最终成果：
|
||
- 收款周期缩短 36%
|
||
- 续费率提升 18%
|
||
- 用户满意度显著提升
|
||
|
||
---
|
||
|
||
## 6. 使用手册
|
||
|
||
### 6.1 安装与配置
|
||
|
||
- **位置**：~/.openclaw/workspace/skills/
|
||
- **技能数量**：46 个
|
||
- **占用空间**：约 2MB
|
||
|
||
### 6.2 如何调用技能
|
||
|
||
在 OpenClaw 会话中：
|
||
- **方式 1**：直接提及技能名
|
||
- "帮我用 jobs-to-be-done 分析一下发票工具的用户需求"
|
||
- **方式 2**：描述任务，AI 自动匹配
|
||
- **方式 3**：使用技能前缀
|
||
- "/skills prd-development 我要写一个 PRD"
|
||
|
||
### 6.3 新手入门路径
|
||
|
||
**第 1 周：掌握核心 5 技能**
|
||
- Day 1-2: jobs-to-be-done（理解用户）
|
||
- Day 3-4: user-story（拆分需求）
|
||
- Day 5: prd-development（写文档）
|
||
- Day 6: prioritization-advisor（排优先级）
|
||
- Day 7: 复习 + 实战练习
|
||
|
||
**第 2 周：扩展技能栈**
|
||
- Day 8-9: opportunity-solution-tree
|
||
- Day 10-11: customer-journey-map
|
||
- Day 12: problem-framing-canvas
|
||
- Day 13: user-story-mapping
|
||
- Day 14: 完整项目实战
|
||
|
||
### 6.4 最佳实践
|
||
|
||
**✅ 应该做的**：
|
||
1. **先理解问题，再跳方案** - 先用 jobs-to-be-done，再用 opportunity-solution-tree，避免直接写 PRD
|
||
2. **文档是活的，不是交付物** - PRD、用户故事都是"活文档"，随着认知更新而更新
|
||
3. **技能是框架，不是答案** - 技能帮你结构化思考，真正的答案来自用户调研和数据
|
||
4. **组合使用，效果最佳** - 单个技能有用，组合使用威力更大
|
||
|
||
**❌ 应该避免的**：
|
||
1. 跳过发现阶段 - 错误：直接写 PRD；正确：先做 JTBD 分析
|
||
2. 把技能当 checklist - 错误：机械地填充模板；正确：理解背后的思考框架
|
||
3. 一次性用所有技能 - 错误：每个项目都用 46 个技能；正确：根据项目阶段选择
|
||
4. 忽视验证环节 - 错误：功能上线就结束；正确：用 business-health-diagnostic 验证
|
||
|
||
---
|
||
|
||
## 7. 常见问题
|
||
|
||
**Q1: 这些技能适合什么类型的产品？**
|
||
- ✅ SaaS 产品（B2B/B2C）
|
||
- ✅ 互联网产品（App、Web）
|
||
- ✅ 数字化转型项目
|
||
- ⚠️ 硬件产品（部分技能适用，需调整）
|
||
- ❌ 纯内容产品（如博客、视频）
|
||
|
||
**Q2: 小团队/个人开发者需要用这么多技能吗？**
|
||
不需要全部。建议：
|
||
- **个人开发者**：jobs-to-be-done + user-story + prd-development（3 个核心）
|
||
- **小团队 (<10 人)**：+ opportunity-solution-tree + prioritization-advisor（5 个）
|
||
- **中型团队**：根据项目需要灵活组合
|
||
|
||
**Q3: 技能和敏捷开发是什么关系？**
|
||
互补关系：
|
||
```
|
||
产品技能 敏捷开发
|
||
─────────────────────────────
|
||
发现需求 → 产品 Backlog
|
||
写 PRD → Sprint 规划
|
||
用户故事 → 迭代开发
|
||
验证结果 → Sprint 回顾
|
||
```
|
||
|
||
**Q4: 技能输出的文档可以直接用吗？**
|
||
可以，但建议：技能输出的是**框架和初稿**，需要结合具体业务填充细节，和团队 review 后定稿。
|
||
|
||
**Q5: 如何评估这些技能的效果？**
|
||
看三个指标：
|
||
- **需求准确性**：上线后是否解决了真实问题？
|
||
- **团队效率**：沟通成本是否降低？
|
||
- **业务结果**：核心指标是否提升？
|
||
|
||
**Q6: 技能会更新吗？**
|
||
是的。技能来源于：
|
||
- 经典产品管理理论（JTBD、OST 等）
|
||
- 最新实践（AI 产品、上下文工程等）
|
||
- 社区反馈
|
||
|
||
**Q7: 可以和 OpenClaw 的其他功能结合吗？**
|
||
可以！例如：
|
||
- 用 `searxng` 做竞品调研 → 输入 `company-research`
|
||
- 用 `browser` 抓取用户反馈 → 输入 `jobs-to-be-done`
|
||
- 用 `message` 推送 PRD 给团队 → `prd-development` 输出后
|
||
|
||
---
|
||
|
||
> 来源：由"微信搬运工"搬运（点击进入：https://t.me/wxbyg） |