back
loading skill details...
覆盖产品从 0 到 1 全流程的实战工具箱，「产品通关六步法」帮你把模糊想法变成可交付方案
---
name: product-workshop
description: "产品经理实战工作坊，覆盖从问题发现、用户洞察、方案设计、文档编写、开发推进到复盘迭代的完整产品生命周期。独创「产品通关六步法」框架，每个阶段提供原创工具箱、质量检查清单、实战模板和老兵笔记。当用户涉及产品规划、需求分析、PRD撰写、用户研究、方案设计、功能优先级、敏捷管理、产品复盘等场景时触发此技能。"
agent_created: true
---
# 产品工坊 — Product Workshop
> 灵感来源：PM Master Skillhub（功能范围参考，未经授权不得商业使用其中的任何内容）
>
> 本 Skill 为原创作品，所有文字、框架、模板均为独立创作。
## 一句话定位
**帮你把模糊的想法，变成可交付的产品方案。** 不是教科书，是工具箱 + 检查清单 + 实战笔记。
---
## 使用方式
当用户提出产品相关的任务时，根据任务所处的阶段，加载对应章节的流程和模板。输出时：
1. **先判断阶段**：根据用户的输入，确认当前处于六步中的哪一步
2. **选择合适的工具**：从该阶段的工具箱中挑选 1-2 个最适用的
3. **按模板输出**：使用该阶段提供的模板，为用户生成可直接使用的工作文档
4. **跑检查清单**：输出完成后，用红牌检查清单逐项核对，标出潜在问题
---
## 产品通关六步法
```
问题发现 → 用户洞察 → 方案设计 → 文档落地 → 开发推进 → 复盘迭代
(探路) (画像) (构图) (落笔) (行军) (复盘)
```
---
## 第一关：探路 — 问题发现与验证
> 守关问题：**"我们到底在解决谁的什么问题，这个问题值不值得解决？"**
>
> 通关标准：能用一句话说清楚 "为谁，解决什么痛点，带来什么价值"
### 工具箱
**A. 问题-影响矩阵**
把所有候选问题放进一个 2x2 格子：
| | 影响范围大 | 影响范围小 |
|---|----------|----------|
| **痛苦程度高** | ⭐ 立即投入 | 观察趋势 |
| **痛苦程度低** | 战略储备 | 暂时搁置 |
"痛苦程度"看三个信号：频率（多常遇到）、强度（多难受）、支付意愿（用户是否已经在花钱解决）。
**B. 5 层追问法**
用户说"我要一个 XX 功能"时，连续追问 5 个"为什么"：
1. "为什么需要这个功能？" → 得到表层原因
2. "为什么那个原因很重要？" → 发现业务上下文
3. "为什么之前没解决？" → 了解历史约束
4. "如果不解决会怎样？" → 评估真实紧迫度
5. "解决之后你的工作/生活有什么不同？" → 找到核心价值
**C. 问题信号三角**
从三个维度交叉验证一个问题的真实性：
- **行为信号**：用户在做什么？（观察到的行为 > 用户说的话）
- **情绪信号**：用户对什么感到沮丧/兴奋？（高情绪 = 真需求）
- **数据信号**：数据上有什么异常？（转化率骤降、客服工单激增等）
三角重叠区域 = 最高置信度的问题。
### 红牌检查清单
- [ ] 问题描述中是否出现了"我觉得""应该会有人""大概"等模糊词？
- [ ] 能否用数据或用户原话证明这个问题的存在？
- [ ] 这个问题影响的是大多数目标用户，还是某个大客户的特殊需求？
- [ ] 用户已经在用替代方案了吗？（有替代方案 = 有真实需求）
- [ ] 如果问题不被解决，用户会继续忍受还是流失？
### 老兵笔记
> "用户要的不是钻头，是墙上的洞"这句话只说对了一半。用户真正要的是挂上家人照片时的满足感。别停在洞，也别停在挂照片——要理解它为什么重要。
---
## 第二关：画像 — 用户与市场洞察
> 守关问题：**"谁在用？谁在用竞品？他们真正在乎什么？"**
>
> 通关标准：能画出目标用户的决策路径，知道他们从哪里来、在什么情境下需要你
### 工具箱
**A. 用户决策地图**
沿着用户的时间线画出五个关键节点：
```
触发时刻 → 信息搜寻 → 方案比较 → 决策使用 → 使用后评价
↓
┌──────┴──────┐
│ 推荐/复购 │
│ 放弃/流失 │
└─────────────┘
```
每个节点追问：
- 触发时刻：是什么事情让他开始寻找解决方案？
- 信息搜寻：他在哪里找？问谁？搜什么词？
- 方案比较：他拿什么跟什么比？按什么标准打分？
- 决策使用：什么因素让他最终选择（或放弃）？
- 使用后评价：他满意/不满意的点是什么？会跟别人怎么说？
**B. 竞品三圈定位图**
不从功能列表做竞品分析，而是画三个同心圆：
- **最内圈（直接竞品）**：解决同一个问题，面向同一群用户
- **中间圈（间接竞品）**：解决同一个问题，但方式不同或用户群不同
- **最外圈（替代方式）**：用户现在不用任何产品，怎么凑合着解决问题的？
重点关注最外圈——用户"凑合用的方案"才是最大的竞争对手。
**C. 高频场景 × 高情绪矩阵**
列出 Top 10 用户场景，按两个维度打分：
- 场景频率（1-5）：用户多常遇到这个场景？
- 情绪强度（1-5）：遇到时情绪波动多大？
取两个维度乘积最高的 3 个场景——这就是你的核心战场。
### 红牌检查清单
- [ ] 用户画像里是否包含"他们现在怎么解决"这个关键信息？
- [ ] 是否把"用户说的话"和"用户做的事"区分开了？
- [ ] 目标用户群是否足够具体？（"白领"不够，"财务部门负责月末结账的会计"够）
- [ ] 有没有找到用户"愿意付费的信号"？
- [ ] 竞品分析是否包括"用户用 Excel/微信/纸质本子凑合"这种替代方式？
### 老兵笔记
> 用户访谈里，最危险的一句话是"这个功能挺好的，我可能会用"。"可能会用"翻译过来就是"不会用"。真正有价值的需求，用户已经在用某个难受的方式在解决了。
---
## 第三关：构图 — 方案设计与策略
> 守关问题：**"在可行的方案中，哪个能以最小的代价验证最核心的假设？"**
>
> 通关标准：产出一份方案对比表 + 一张核心流程图 + 一组待验证的关键假设
### 工具箱
**A. 方案光谱**
大多数方案辩论陷入"二选一"的死胡同。展开成光谱：
```
极简方案 ←—— 当前所处 ——→ 重方案
(MVP) (大而全)
第1版只做： 完整版包括：
- 核心闭环 - 所有用户角色
- 一条主路径 - 所有异常分支
- 手动能跑就行 - 完全自动化
```
核心原则：**往左走，走通再往右加。**
**B. 价值-信度-成本三角**
给候选方案打分（每个维度 1-5 分）：
| 维度 | 判断标准 |
|------|---------|
| **用户价值 (V)** | 方案能多大程度缓解核心痛点？ |
| **验证信度 (C)** | 我们对这个方案能成功的把握有多大？有数据支撑吗？ |
| **实现成本 (E)** | 需要多少人、多少时间？依赖什么？ |
综合评分 = V × C / E，取最高的 2-3 个方案进入候选。
**C. 假设排雷表**
你的产品方案建立在多少假设上？把每条假设写下来，标上风险等级：
| 假设 | 类型 | 风险 | 验证方式 | 验证周期 |
|------|------|------|---------|---------|
| "用户愿意为此付费" | 价值假设 | 🔴高 | 假门测试 | 1 周 |
| "3 秒内能完成操作" | 可用假设 | 🟡中 | 纸质原型 | 2 天 |
| "接口能扛住 1000QPS" | 技术假设 | 🟡中 | 压测 | 3 天 |
红色假设必须在上线前验证，黄色假设需要在第一个迭代内验证。
### 红牌检查清单
- [ ] 方案设计是否从"最小闭环"开始，而不是罗列完整功能列表？
- [ ] 有没有方案比较过程，还是直接跳到了最喜欢的那一个？
- [ ] 关键假设清单写了吗？每条假设有没有验证方式？
- [ ] 有没有"如果不做什么"的明确边界？
- [ ] 核心流程是否能让一个新用户在 5 分钟内体验到价值？
### 老兵笔记
> 好方案不是你画了多少张原型图。好方案是一个假设清单——你知道哪些是对的、哪些是你猜的、猜错的时候怎么快速转弯。
---
## 第四关：落笔 — 写出能交付的文档
> 守关问题：**"另一个人拿到这份文档，能不能不来找我就能把东西做出来？"**
>
> 通关标准：开发、设计、测试三个角色分别读完文档后，各自知道要做什么
### 工具：PRD 骨架模板
```markdown
# [功能/项目名称]
## 一句话描述
[用一个完整句子说清楚：什么用户 + 做什么操作 + 得到什么结果]
## 为什么现在做
- 用户现状：[当前用户如何应对这个问题？]
- 关键数据：[支撑这个决策的一个核心数字]
- 不改的代价：[如果现在不做，会怎样？]
## 核心流程（主线）
[画 3-7 步核心流程，只画"阳光大道"，不画分岔路]
1. 用户进入 XX 页面
2. 点击 XX 按钮
3. 系统验证 XX
4. 执行 XX
5. 展示结果
## 关键分支与边界
| 场景 | 触发条件 | 系统行为 |
|------|---------|---------|
| 用户未登录 | 点击需要登录的操作 | 引导登录，保留操作意图 |
| 内容为空 | 该区域无数据 | 显示引导文案 + 行动按钮 |
| 网络异常 | 请求超时/失败 | 显示重试提示 + 本地缓存兜底 |
| ... | ... | ... |
## 验收标准
- [ ] [可观察、可测试的标准，不用"体验好""速度快"这种词]
- [ ] 用户登录后，在 XX 页面能看到 XX 内容
- [ ] 点击 XX 后，3 秒内出现结果反馈
## 埋点清单
| 埋点位置 | 事件名 | 触发时机 | 携带字段 |
|----------|--------|---------|---------|
| ... | ... | ... | ... |
## 已知风险与缓解
| 风险 | 严重程度 | 缓解措施 |
|------|---------|---------|
| ... | 🔴/🟡/🟢 | ... |
```
### 工具：用户故事切片卡
不写"作为一个 XX，我想要 XX"的模板句——用卡片搞定：
```
┌─────────────────────────────────┐
│ 故事：#04 订单列表搜索 │
│ │
│ 用户：仓库拣货员 │
│ 场景：每天要处理 200+ 订单， │
│ 需要按客户名或订单号快速定位│
│ │
│ 现在做法：Ctrl+F 在页面上搜 │
│ （单页只能显示 20 条） │
│ │
│ 验收： │
│ 1. 搜索框在订单列表顶部 │
│ 2. 输入后 500ms 内出现结果 │
│ 3. 支持订单号精确搜索 │
│ 4. 支持客户名模糊搜索 │
│ │
│ 大小：M（估 2 人天） │
│ 优先级：P0 │
└─────────────────────────────────┘
```
### 红牌检查清单
- [ ] 一个完全不了解背景的人读懂全文需要超过 10 分钟吗？
- [ ] 有没有"优化""提升""改善"这种需要译者自行脑补的动词？
- [ ] "正常情况"之外的异常分支写了几个？是否覆盖了最常见的 5 个异常？
- [ ] 验收标准是否足够具体，可以直接转换成测试用例？
- [ ] 有没有写"不做什么"？没有 scope exclusion 的 PRD 是 incomplete 的。
### 老兵笔记
> PRD 的第一个读者是开发，不是老板。别用 PPT 思维写 PRD。好的 PRD 读起来像一份"说明书"，不像一份"提案"。
---
## 第五关：行军 — 开发推进与迭代管理
> 守关问题：**"这周我们做的是最重要的事吗？有没有偏航？"**
>
> 通关标准：团队每个人知道这周要交付什么、为什么是这些、怎么判断交付成功
### 工具箱
**A. 迭代健康仪表盘**
每个迭代结束时更新：
| 指标 | 上轮 | 本轮 | 趋势 | 说明 |
|------|------|------|------|------|
| 承诺故事点 | 21 | 23 | ↗ | 信心提升 |
| 实际交付 | 19 | 21 | ↗ | 90% 达成率 |
| 新增需求数 | 3 | 7 | ↗ | 🔴 需关注 |
| Bug 产生数 | 5 | 12 | ↗ | 🔴 排查原因 |
| 团队速度 | 19 | 21 | ↗ | 稳定提升 |
**B. 决策日志**
遇到争议时记录，避免"之前谁说过的"：
| 日期 | 决策 | 背景 | 选项 | 选择理由 | 决策人 |
|------|------|------|------|---------|--------|
| 7/15 | 先做搜索不做筛选 | 资源只能二选一 | A:搜索 B:筛选 | 用户访谈中搜索频率是筛选的 4 倍 | 张三 |
**C. 站会三问升级版**
传统三问之外，加第四个问题：
- 做了什么？
- 要做什么？
- 有什么阻塞？
- **"你对今天做的东西有多大信心它是对的？"**（1-5 分）
如果有人的信心低于 3 分，站会后留下来聊 5 分钟。
### 红牌检查清单
- [ ] 当前迭代中是否混入了没有关联到任何用户故事的"顺便做的"需求？
- [ ] 有没有超过 3 天还没更新的阻塞项？
- [ ] 需求变更时有没有同步更新验收标准和测试用例？
- [ ] 上一次回顾会提出的改进项，落实了吗？
- [ ] 团队是否有"沉默的担忧"——那种没人说但大家都隐隐觉得不对的事？
### 老兵笔记
> Sprint 不是"装得越多越好"。一个好的 Sprint 计划不是把容量填满，是留 20% 的弹性和喘息空间。填满的计划不是计划，是祈祷。
---
## 第六关：复盘 — 度量与持续成长
> 守关问题：**"我们做的这个功能，到底起作用了吗？学到了什么？"**
>
> 通关标准：有数据证明功能是否达到预期效果，有结构化的经验沉淀
### 工具箱
**A. 指标树**
从北极星指标往下拆：
```
北极星指标：周活用户数
├── 新用户获取
│ ├── 渠道 A 注册转化率
│ ├── 渠道 B 注册转化率
│ └── 邀请注册数
├── 用户激活
│ ├── 首次核心操作完成率
│ └── 次日留存率
└── 用户留存
├── 第 7 天留存率
├── 第 30 天留存率
└── 流失用户召回率
```
原则：每层不超过 5 个指标，你只需要盯住"输入指标"（你能直接影响的），然后验证它们是否带动了"输出指标"（你希望看到的）。
**B. 三问复盘画布**
功能上线后 1-4 周，组织一次 30 分钟的快速复盘：
```
┌─────────────────────────────────────────┐
│ 复盘主题：[功能名称] - [上线日期] │
├─────────────────────────────────────────┤
│ │
│ Q1: 我们对用户做了什么假设？ │
│ [列出做功能时的核心假设] │
│ │
│ Q2: 数据告诉我们什么？ │
│ [对照假设，列出实际数据] │
│ - 假设 A: [验证通过/未通过] │
│ - 假设 B: [验证通过/未通过] │
│ │
│ Q3: 如果重来一次，我们会怎么不同？ │
│ [只写 3 条以内的 actionable change] │
│ 1. │
│ 2. │
│ │
│ 知识沉淀：[这条经验应该被团队记住] │
│ │
└─────────────────────────────────────────┘
```
**C. 产品知识库模板**
```markdown
## [功能名] - 复盘归档
**背景**：为什么做？（1 句话）
**核心假设**：我们赌用户会 XX
**结果数据**：
- 北极星影响：[有/无显著变化]
- 核心指标 A：[基线] → [上线后]（变化 ±X%）
- 意外发现：[上线后发现但没预料到的]
**关键复盘**：
- 做对了什么：
- 做错了什么：
- 下次怎么做：
**适用场景**：[什么类型的产品/功能可以参考这个经验]
```
### 红牌检查清单
- [ ] 上线后是否设定了明确的"看数据"的时间点（如上线后第 7 天、第 30 天）？
- [ ] 有没有区分"相关性"和"因果性"？（指标涨了不一定是你的功能导致的）
- [ ] 失败的经验有没有被记录下来，还是只庆祝了成功？
- [ ] 复盘产出的行动项有没有责任人 + 截止日期？
- [ ] 知识库是否有被团队其他人查阅的机制？
### 老兵笔记
> "数据驱动"的前提是你知道什么数据值得看。每个功能上线前至少定义 3 个指标：一个核心指标（你希望它涨的）、一个反向指标（你希望它不跌的）、一个惊喜指标（你没预料到但值得观察的）。
---
## 快速选用指南
| 用户说... | 走哪关 | 用什么工具 |
|-----------|--------|-----------|
| "我想做一个 XX 功能" | 第一关 探路 | 5 层追问法 + 问题-影响矩阵 |
| "帮我分析一下用户" | 第二关 画像 | 用户决策地图 + 高频×高情绪矩阵 |
| "你觉得做 A 还是做 B" | 第三关 构图 | 方案光谱 + 价值-信度-成本三角 |
| "帮我写个 PRD" | 第四关 落笔 | PRD 骨架模板 + 用户故事切片卡 |
| "这个迭代怎么做" | 第五关 行军 | 迭代健康仪表盘 + 决策日志 |
| "功能上线了，看看效果" | 第六关 复盘 | 三问复盘画布 + 产品知识库 |
---
## 资源索引
- `references/prd-backbone-full.md` — PRD 骨架模板的完整版，含详细的填写指南和范例
- `references/story-card-template.md` — 用户故事切片卡模板集合
- `references/retro-canvas-template.md` — 三问复盘画布模板
- `references/checklist-all.md` — 六个关卡的全部检查清单汇总
don't have the plugin yet? install it then click "run inline in claude" again.