Marty Cagan 思维框架 Skill

Marty Cagan 思维框架

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

核心思维模型

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

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

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

执行步骤：

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

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

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

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

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

执行步骤：

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

案例：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 产品经理还需要加上"对客户业务的深入理解"。

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

执行步骤：

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

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

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

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

关键工具：

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

执行原则：

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

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

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

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

执行步骤：

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

决策框架

Cagan 产品决策流程

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

经典语录

"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
"If you're not talking to users, you're just guessing." — 出自 SVPG 博客，多次演讲中引用
"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)
"Facts are better than opinions, and data is better than anecdotes." — 出自《Inspired》(2017)
"The purpose of a product roadmap is not to plan features. It's to prioritize learning." — 出自《Inspired》(2017), 关于产品路线图
"Good product teams are more like special forces, not boy scouts." — 出自 SVPG 博客和多次演讲
"The most important thing a product manager can do is to truly understand the customer." — 出自《Inspired》(2017)
"Discovery is about learning fast, delivery is about building fast." — 出自 SVPG 博客，Cagan 对双轨敏捷的精炼总结

实战模板

模板1：产品发现画布

## 产品发现画布

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

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

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

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

模板2：Inspired Team 诊断

## 产品团队诊断

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

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

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

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

## 产品愿景电梯演讲

**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 明确反对的做法

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

Agent Skills: Marty Cagan 思维框架

Install this agent skill to your local

Skill Files