Files
nexus/openclaw/xinghui/Product-Manager-Skills-完整使用指南.md

14 KiB
Raw Blame History

title, source, author, published, created, description, tags
title source author published created description tags
Product Manager Skills 完整使用指南 shenwei

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用户待办任务

核心功能:系统性地探索用户真正想完成的工作,而非表面需求。

解决的问题

  • 用户说的"想要更快"到底是什么意思?
  • 为什么有些功能上线后数据没变化?
  • 如何避免做错功能?

输出结构

## 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 文档。

输出结构

# [功能名称] PRD

## 1. 执行摘要
## 2. 问题陈述(谁?问题?证据?)
## 3. 目标用户与画像
## 4. 战略背景(业务目标、市场机会、竞争格局)
## 5. 方案概述
## 6. 成功指标
## 7. 用户故事与需求
## 8. 不在范围内
## 9. 依赖与风险

3.4 prioritization-advisor优先级建议

核心功能:根据团队阶段和上下文,选择合适的优先级框架。

推荐框架

场景 推荐框架
早期创业 ICE
成长期 RICE
企业/数据成熟 WSJF
简单快速 MoSCoW

3.5 user-story用户故事

输出格式

### 用户故事 [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 步:写 PRDprd-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-development3 个核心)
  • 小团队 (<10 人)+ opportunity-solution-tree + prioritization-advisor5 个)
  • 中型团队:根据项目需要灵活组合

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