thinking-marty-cagan

# Marty Cagan 思维框架

> "好的产品团队就像特种部队，而不是童子军。" —— Marty Cagan

## 核心思维模型

### 1. 产品发现 vs 产品交付（Product Discovery vs Product Delivery）

**定义**：大多数产品组织失败的根源是混淆了两件事——**发现**（确定要构建什么：是否有价值、是否可用、是否可行、是否可行销）和**交付**（如何快速可靠地构建它）。这两个活动需要完全不同的思维方式、工具和流程。

**适用场景**：产品规划、团队分工、项目立项、任何"做什么"的决策。

**执行步骤**：
1. **先发现，后交付** — 不要先写需求文档再研究是否有价值。先验证，再构建
2. **发现的四个问题**：
   - **Valuable**（有价值）— 用户真的在乎吗？能解决真实痛点吗？
   - **Usable**（可用）— 用户能理解和操作吗？
   - **Feasible**（可行）— 我们的技术能力能做到吗？
   - **Viable**（可行销）— 对我们的业务来说值得做吗？（成本、定价、品牌、合规）
3. **用原型验证，不是用PPT** — 产品发现的核心工具是原型（prototype），不是需求文档
4. **交付追求速度和可靠性** — 一旦发现完成，交付追求的是持续部署、小批量、高频次
5. **两个节奏并行** — 发现团队在前方探索，交付团队在后方构建，形成"双轨敏捷"

**案例**：Cagan 在多个文章和演讲中举过这样的例子——一个团队花3个月构建了一个"完美"的功能，上线后发现没人用。如果他们在花1周做原型验证，就能提前发现这个问题。发现的花费远小于交付错误产品的代价。

### 2. Inspired 产品团队（Inspired Product Teams）

**定义**：好的产品团队不是一群接需求写代码的人（"feature team"），而是一群被赋予问题（而非解决方案）、被信任去发现最佳方案、被激励去解决真实用户问题的精英团队。关键区别：**feature team 被告知做什么，inspired team 被告知要解决什么问题**。

**适用场景**：团队组建、组织设计、产品文化转型。

**执行步骤**：
1. **给团队问题，不给解决方案** — "我们需要解决新用户留存率只有30%的问题"，而不是"做一个新手引导功能"
2. **组建跨职能团队** — 一个产品经理、一个产品设计师、2-6个工程师，作为一个单元工作
3. **给团队背景和上下文** — 分享用户洞察、商业目标、技术约束，让团队自己做决策
4. **用结果衡量，不用产出衡量** — 衡量"用户留存率提升了多少"，不是"发布了多少功能"
5. **信任但要验证** — 信任团队的专业判断，但用数据和用户测试验证结果

**案例**：Netflix、Apple、Amazon、Google 等顶级公司的产品团队都是 inspired 模型。这些公司不会给团队一份需求清单让他们照着做，而是给团队一个要解决的商业问题，让团队去发现最佳解决方案。

### 3. 产品经理的四大职责（The Four Responsibilities of a Product Manager）

**定义**：一个优秀的 B2C 产品经理需要深入掌握四个领域——**用户洞察**（deep knowledge of users/customers）、**数据敏感度**（deep knowledge of data）、**行业/市场理解**（deep knowledge of business/market）、**技术基础**（deep knowledge of technology）。B2B 产品经理还需要加上"对客户业务的深入理解"。

**适用场景**：产品经理培养、招聘评估、自我提升规划。

**执行步骤**：
1. **用户洞察** — 定期做用户访谈、可用性测试、客户拜访。"每周至少做一次用户访谈"
2. **数据敏感度** — 不只是看仪表板。要能从数据中发现异常、提出假说、验证因果
3. **行业/市场理解** — 了解竞争对手、行业趋势、商业模式、法规环境
4. **技术基础** — 不需要会写代码，但需要理解技术约束、权衡和可能性
5. **持续投资这四个维度** — 任何一个维度的薄弱都会成为产品决策的盲点

### 4. 产品发现技术工具箱（Discovery Techniques）

**定义**：产品发现不是模糊的"研究"，而是一套具体的、可操作的验证技术。Cagan 总结了超过20种发现技术，核心思想：**用最低成本、最快速度验证假设**。

**适用场景**：功能验证、新想法测试、降低产品风险。

**关键工具**：
1. **用户访谈（Customer Interviews）** — 不是问"你想要什么"，而是问"你现在怎么做这件事？最大的痛点是什么？"
2. **原型测试（Prototype Testing）** — 用高保真或低保真原型让用户"操作"，而不是看PPT
3. **一对一可用性测试** — 观察一个真实用户使用原型，记录哪里卡住了
4. **虚假门测试（Fake Door Test）** — 在产品中放一个按钮，看有多少人点击，但不真正构建功能
5. **客户信使（Customer Letter）** — 写一封来自客户的信，描述"我的生活因为你的产品如何变好了"
6. **20分钟测试** — 让一个陌生人20分钟内用你的原型完成核心任务

**执行原则**：
- 每种技术验证一种风险（价值风险、可用性风险、可行性风险、行销风险）
- 每次测试5-8个用户就够（更多用户不会带来更多洞察）
- 先测试最大风险（你最不确定的假设）

### 5. 产品愿景与产品策略（Product Vision and Strategy）

**定义**：产品愿景是"2-5年后我们的产品如何改变用户的生活"（inspirational、long-term）。产品策略是"我们如何分阶段实现愿景"（pragmatic、sequential）。大多数产品组织的问题是没有清晰的愿景，或者有愿景但没有策略。

**适用场景**：产品路线图规划、战略对齐、团队激励。

**执行步骤**：
1. **写产品愿景** — 2-5年视角，描述用户未来的体验。用"产品盒"练习：如果这个产品是一个货架上的产品盒，盒子上写什么？
2. **定义产品策略** — 按优先级排列要解决的主题（themes），每个主题1-3个季度
3. **不要把路线图当成承诺** — 路线图是方向的指南，不是交付的承诺。好的路线图是主题式的（outcome-based），不是功能式的（feature-based）
4. **愿景驱动招聘** — 用愿景吸引顶尖人才。"我要改变X"比"我要做Y功能"更能吸引优秀的人

---

## 决策框架

### Cagan 产品决策流程

```
输入：面临产品决策
  │
  ▼
1. 明确问题：
   │ 这是"做什么"的问题（发现）还是"怎么做"的问题（交付）？
   │
   ▼
2. 如果是发现类问题：
   │ 识别最大风险：
   │ - 价值风险：用户在乎吗？
   │ - 可用性风险：用户能用吗？
   │ - 可行性风险：我们能做吗？
   │ - 行销风险：对生意好吗？
   │
   ▼
3. 选择验证技术：
   │ 用最低成本验证最大风险
   │ 原型测试 > 用户访谈 > 数据分析
   │
   ▼
4. 执行验证：
   │ 5-8个用户就够
   │ 记录学到了什么，不只是"行/不行"
   │
   ▼
5. 决策：
   │ 验证通过 → 进入交付
   │ 验证不通过 → pivot 或 kill
   │ 不确定 → 换个角度继续发现
```

---

## 经典语录

1. **"The best single indicator of a great product team is how much they are learning from their users."**
   — 出自《Inspired: How to Create Tech Products Customers Love》(2017), Chapter on Product Discovery

2. **"If you're not talking to users, you're just guessing."**
   — 出自 SVPG 博客，多次演讲中引用

3. **"The old model was about minimizing risk by managing and controlling the engineers. The new model is about empowering engineers and giving them context."**
   — 出自《Empowered: Ordinary People, Extraordinary Products》(2020)

4. **"Facts are better than opinions, and data is better than anecdotes."**
   — 出自《Inspired》(2017)

5. **"The purpose of a product roadmap is not to plan features. It's to prioritize learning."**
   — 出自《Inspired》(2017), 关于产品路线图

6. **"Good product teams are more like special forces, not boy scouts."**
   — 出自 SVPG 博客和多次演讲

7. **"The most important thing a product manager can do is to truly understand the customer."**
   — 出自《Inspired》(2017)

8. **"Discovery is about learning fast, delivery is about building fast."**
   — 出自 SVPG 博客，Cagan 对双轨敏捷的精炼总结

---

## 实战模板

### 模板1：产品发现画布

```markdown
## 产品发现画布

**日期**：2026-XX-XX
**团队**：[产品经理 + 设计师 + 技术负责人]

### 要验证的假设
**我们相信**：[用户群体] 在 [场景] 下有 [痛点/需求]
**如果**我们提供 [解决方案概念]
**那么** [预期行为/结果]

### 四大风险评估
| 风险类型 | 风险等级(H/M/L) | 验证方法 | 验证结果 |
|---------|----------------|---------|---------|
| 价值（用户在乎吗？） | | 用户访谈 x 5 | |
| 可用性（用户能用吗？） | | 原型测试 x 5 | |
| 可行性（能做吗？） | | 技术spike | |
| 行销（对生意好吗？） | | 商业论证 | |

### 发现计划
- 第一周：[做什么验证]
- 第二周：[做什么验证]
- Go/No-Go 判定标准：[什么结果算通过]
```

### 模板2：Inspired Team 诊断

```markdown
## 产品团队诊断

### 1. 我们是 Feature Team 还是 Inspired Team？

| 指标 | Feature Team | Inspired Team | 我们在哪 |
|------|-------------|---------------|---------|
| 需求来源 | 上级/客户指定 | 团队自主发现 | |
| 衡量标准 | 发布了多少功能 | 解决了多少问题 | |
| 团队构成 | 只有工程师 | PM+设计+工程 | |
| 决策权 | 听命执行 | 被授权决定方案 | |
| 与用户接触 | 几乎没有 | 每周至少一次 | |

### 2. 改进计划
- [ ] 从给解决方案改为给问题
- [ ] 从衡量产出改为衡量结果
- [ ] 增加团队与真实用户的接触频率
- [ ] 建立产品发现 rituals（每周用户测试）
```

### 模板3：产品愿景电梯演讲

```markdown
## 产品愿景电梯演讲

**For** [目标用户群体]
**Who** [描述他们的核心痛点/需求]
**The** [产品名]
**Is a** [产品类别]
**That** [核心价值主张——一句话说清你做什么不同的事]
**Unlike** [主要竞品/替代方案]
**Our product** [你的独特优势]

### 2-5年愿景
"想象一个世界，[用户的体验发生了怎样的根本变化]..."

### 产品策略（分阶段）
1. **Phase 1**（本年度）：[解决什么核心问题]
2. **Phase 2**（明年）：[在此基础上扩展什么]
3. **Phase 3**（后年）：[最终达到什么状态]
```

---

## 应用场景

### 何时调用此 Skill

| 场景 | 调用哪个模型 |
|------|-------------|
| 规划新功能/新产品 | 产品发现 — 先验证四大风险再投入 |
| 团队效能低 | Inspired Team 诊断 — 检查是否在feature team模式 |
| PM不知道怎么提升 | 四大职责 — 评估自己在四个维度的强弱 |
| 产品路线图争论 | 产品愿景+策略 — 先对齐愿景，再讨论路线图 |
| 不确定想法是否值得做 | 发现技术工具箱 — 用原型/假门测试快速验证 |
| 组织转型 | 全套模型 — 从feature team转型为inspired team |

### 典型调用场景

- 产品经理拿到新需求时，先做产品发现画布验证价值
- 管理者发现团队只会执行不会思考时，用Inspired Team模型诊断
- 创业者规划产品路线图时，用愿景电梯演讲对齐全团队
- 产品组织在做"先做什么后做什么"的决策时，用策略而非共识

---

## 反模式

### Cagan 明确反对的做法

1. **❌ 用需求文档驱动开发** — "PRD 是交付文档，不是发现工具。用它来发现用户需求是本末倒置"
2. **❌ 让销售或客户直接指定功能** — "客户说的不等于客户需要的。你的工作是发现真正的需求"
3. **❌ 把产品路线图当成承诺** — "路线图是学习计划，不是交付承诺"
4. **❌ 不和用户接触就做决定** — "如果你不跟用户聊，你就是在猜"
5. **❌ 衡量产出而非结果** — "发布了多少功能"是虚荣指标。"解决了多少问题"才是真指标
6. **❌ 产品经理不懂数据** — "在好的产品团队中，PM 必须对数据有深度的直觉"
7. **❌ 共识驱动产品决策** — "不要试图让所有人都满意。要确保对的目标用户非常满意"
8. **❌ Feature Team 模式** — 把工程师当代码机器而非问题解决者

---

## 延伸阅读

- **《Inspired: How to Create Tech Products Customers Love》**(2017, 第2版) — Cagan 的核心著作，产品管理的圣经
- **《Empowered: Ordinary People, Extraordinary Products》**(2020, Cagan & Jones) — 专注于 inspired team 模型
- **SVPG Blog (svpg.com)** — Cagan 的博客，持续更新的产品思维文章
- **"Product Discovery" 系列** — SVPG 博客上的系列文章，发现技术的详细指南

---

*最后更新: 2026-04-14 | 思维蒸馏第2批*