产品工坊 — 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，取最高的 2-3 个方案进入候选。

C. 假设排雷表

你的产品方案建立在多少假设上？把每条假设写下来，标上风险等级：

红色假设必须在上线前验证，黄色假设需要在第一个迭代内验证。

红牌检查清单

• [ ] 方案设计是否从"最小闭环"开始，而不是罗列完整功能列表？
• [ ] 有没有方案比较过程，还是直接跳到了最喜欢的那一个？
• [ ] 关键假设清单写了吗？每条假设有没有验证方式？
• [ ] 有没有"如果不做什么"的明确边界？
• [ ] 核心流程是否能让一个新用户在 5 分钟内体验到价值？

老兵笔记

> 好方案不是你画了多少张原型图。好方案是一个假设清单——你知道哪些是对的、哪些是你猜的、猜错的时候怎么快速转弯。

第四关：落笔 — 写出能交付的文档

> 守关问题："另一个人拿到这份文档，能不能不来找我就能把东西做出来？"
>
> 通关标准：开发、设计、测试三个角色分别读完文档后，各自知道要做什么

工具：PRD 骨架模板

# [功能/项目名称]

## 一句话描述
[用一个完整句子说清楚：什么用户 + 做什么操作 + 得到什么结果]

## 为什么现在做
- 用户现状：[当前用户如何应对这个问题？]
- 关键数据：[支撑这个决策的一个核心数字]
- 不改的代价：[如果现在不做，会怎样？]

## 核心流程（主线）
[画 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. 迭代健康仪表盘

每个迭代结束时更新：

B. 决策日志

遇到争议时记录，避免"之前谁说过的"：

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. 产品知识库模板

## [功能名] - 复盘归档

**背景**：为什么做？（1 句话）
**核心假设**：我们赌用户会 XX
**结果数据**：
- 北极星影响：[有/无显著变化]
- 核心指标 A：[基线] → [上线后]（变化 ±X%）
- 意外发现：[上线后发现但没预料到的]
**关键复盘**：
- 做对了什么：
- 做错了什么：
- 下次怎么做：
**适用场景**：[什么类型的产品/功能可以参考这个经验]

红牌检查清单

• [ ] 上线后是否设定了明确的"看数据"的时间点（如上线后第 7 天、第 30 天）？
• [ ] 有没有区分"相关性"和"因果性"？（指标涨了不一定是你的功能导致的）
• [ ] 失败的经验有没有被记录下来，还是只庆祝了成功？
• [ ] 复盘产出的行动项有没有责任人 + 截止日期？
• [ ] 知识库是否有被团队其他人查阅的机制？

老兵笔记

> "数据驱动"的前提是你知道什么数据值得看。每个功能上线前至少定义 3 个指标：一个核心指标（你希望它涨的）、一个反向指标（你希望它不跌的）、一个惊喜指标（你没预料到但值得观察的）。

快速选用指南

资源索引

• references/prd-backbone-full.md — PRD 骨架模板的完整版，含详细的填写指南和范例
• references/story-card-template.md — 用户故事切片卡模板集合
• references/retro-canvas-template.md — 三问复盘画布模板
• references/checklist-all.md — 六个关卡的全部检查清单汇总