product-discovery

产品探索

打造客户真正想要的产品。运用 Marty Cagan 经硅谷验证的框架，探索有价值、易用、可行且可持续的解决方案。

何时使用此技能

• 开发新产品时，验证要打造什么
• 确定功能优先级，确保解决的是真实问题
• 决定是否转型，当当前方向行不通时
• 团队达成共识，确定要解决哪些问题
• 降低风险，在投入开发资源之前
• 持续探索，保持产品与市场的契合

方法论基础

方面	详情
来源	Marty Cagan——灵感来自《Inspired》（2008、2018）和《Empowered》（2020）
核心原则	“爱上问题，而不是解决方案。最优秀的产品团队会探索客户需要什么，而不只是他们提出了什么要求。”
重要性	大多数产品失败，不是因为做得不好，而是因为解决了错误的问题。探索能确保你先做对的事，再把事情做好。

Claude 负责什么，你来决定什么

Claude 负责	你来决定
构建内容框架	最终文案
建议说服技巧	品牌调性
创建不同的草稿	选择版本
发现优化机会	发布时间
分析竞争对手的做法	战略方向

此技能的作用

1. 梳理四类风险——价值、易用性、可行性、可持续性
2. 区分探索与交付——不同的思维方式，不同的流程
3. 讲解机会评估——应该解决哪些问题
4. 培养原型设计技能——在构建之前测试想法
5. 指导客户研究——了解客户需要什么（而非想要什么）
6. 构建持续探索流程——持续学习，而非一次性研究

使用方法

评估产品机会

I'm considering building [feature/product].
Apply product discovery principles to assess this opportunity.
Context: [target customer, current state, hypothesis]

在构建之前降低风险

We're about to build [feature].
Help me identify the key risks and design tests to address them.

建立持续探索机制

I want to implement continuous discovery for my product team.
Help me design a weekly discovery rhythm.

说明

步骤 1：了解四类风险

## The Four Product Risks

Every product idea has four risks to address BEFORE building:

### 1. Value Risk
"Will customers buy/use this?"

**Questions:**
- Does this solve a real problem?
- Is the problem painful enough to pay/switch for?
- Will users actually adopt this?

**Tests:**
- Customer interviews
- Demand testing
- Fake door tests
- Concierge MVP

### 2. Usability Risk
"Can customers figure out how to use it?"

**Questions:**
- Is it intuitive?
- Can users accomplish their goals?
- What's the learning curve?

**Tests:**
- Prototype testing
- Usability studies
- Wizard of Oz tests
- A/B tests on UX

### 3. Feasibility Risk
"Can we build this?"

**Questions:**
- Do we have the technology?
- Can we do it in reasonable time?
- What are the technical dependencies?

**Tests:**
- Technical spike
- Proof of concept
- Architecture review
- Build vs. buy analysis

### 4. Viability Risk
"Should we build this?"

**Questions:**
- Does it fit our strategy?
- Can we support/maintain it?
- Is it legal/compliant?
- Does the business model work?

**Tests:**
- Business case
- Stakeholder review
- Compliance review
- Financial modeling

---

步骤 2：探索与交付

## Two Tracks: Discovery and Delivery

### Discovery (Figure out WHAT to build)

**Mindset:**
- Embrace uncertainty
- Test assumptions
- Fail fast and cheap
- Learn over deliver

**Activities:**
- Customer interviews
- Prototyping
- Experiments
- Opportunity assessment

**Outcome:**
- Validated problems
- Tested solutions
- Confidence to build
- Clear success metrics

### Delivery (BUILD it right)

**Mindset:**
- Reduce uncertainty
- Execute efficiently
- Ship quality
- Hit timelines

**Activities:**
- Engineering
- QA
- Launch prep
- Documentation

**Outcome:**
- Working software
- Happy customers
- Business impact
- Technical quality

### The Critical Point

Most teams skip discovery and jump to delivery.

**Result:**
- Build features no one wants
- Waste engineering resources
- Miss market opportunities
- Frustrated team, frustrated customers

**The ratio:**
Spend 10-20% of time on discovery to avoid wasting
80-90% of delivery time on wrong things.

---

步骤 3：机会评估

## Assessing Product Opportunities

### The Opportunity Assessment Framework

Before committing to solve a problem, answer:

**1. Is this problem worth solving?**
| Factor | Questions |
|--------|-----------|
| **Frequency** | How often does this problem occur? |
| **Intensity** | How painful is it when it happens? |
| **Willingness** | Will people pay/switch to solve it? |
| **Reach** | How many customers have this problem? |

**Scoring:**
- High frequency + High intensity = Strong opportunity
- Low frequency OR Low intensity = Weak opportunity

**2. Can we solve it effectively?**
| Factor | Questions |
|--------|-----------|
| **Capability** | Do we have the skills/tech? |
| **Fit** | Does it align with our strategy? |
| **Uniqueness** | Can we solve it better than alternatives? |
| **Sustainability** | Can we maintain competitive advantage? |

**3. Should we solve it now?**
| Factor | Questions |
|--------|-----------|
| **Urgency** | Is timing critical? |
| **Resources** | Do we have capacity? |
| **Dependencies** | What else needs to happen first? |
| **Opportunity cost** | What are we NOT doing instead? |

### Opportunity Score Card

机会：[名称]

问题评估

• 频率：[1-5]
• 强度：[1-5]
• 付费/转换意愿：[1-5]
• 市场规模：[1-5] 问题得分：[平均值]

解决方案评估

• 技术可行性：[1-5]
• 战略契合度：[1-5]
• 竞争优势：[1-5] 解决方案得分：[平均值]

时机评估

• 紧迫性：[1-5]
• 资源可用性：[1-5] 时机得分：[平均值]

总体：[问题 × 解决方案 × 时机 = X]

建议：[推进 / 暂缓 / 放弃]

---

步骤 4：探索技巧

## Core Discovery Techniques

### 1. Customer Interviews

**Purpose:** Understand problems, not validate solutions

**Structure:**
1. Context: Understand their current situation
2. Problem: Explore the pain points
3. Impact: How does it affect them?
4. Current solutions: What do they do today?
5. Ideal state: What would "solved" look like?

**Key rules:**
- Ask about past behavior, not future intentions
- Don't pitch, just listen
- Follow the emotion
- Get specific stories

**Questions:**
- "Walk me through the last time this happened..."
- "What did you do? What happened next?"
- "Why was that a problem?"
- "What would have made it better?"

### 2. Prototyping

**Purpose:** Test solutions before building

**Types:**
| Type | Fidelity | Tests | Time |
|------|----------|-------|------|
| **Paper sketch** | Low | Concepts, flow | Hours |
| **Wireframe** | Low-Med | Structure, navigation | Days |
| **Clickable prototype** | Medium | Usability, flow | Days |
| **Wizard of Oz** | High | Full experience | Weeks |

**Principle:**
Use the lowest fidelity that tests your hypothesis.
Higher fidelity = More time = More risk of attachment.

### 3. Experiments

**Purpose:** Test assumptions with real behavior

**Types:**
- **Fake door:** Button for feature that doesn't exist
- **Smoke test:** Landing page before building
- **Concierge:** Manual delivery of automated value
- **A/B test:** Compare variations with real users

**Structure:**
1. Hypothesis: "We believe [X]"
2. Test: "We will test by [Y]"
3. Metric: "We will measure [Z]"
4. Success: "[Number] indicates we should proceed"

### 4. Opportunity Solution Trees

**Purpose:** Map problem space to solution space

**Structure:**

        [预期成果]
               |
┌──────────────┼──────────────┐
|              |              |

[机会 1] [机会 2] [机会 3] | | | ┌─┴─┐ ┌─┴─┐ ┌─┴─┐ | | | | | | [方案 1] [方案 2] [方案 1] [方案 2] [方案 1] [方案 2]

- Start with business outcome
- Break into opportunities (problems to solve)
- Brainstorm solutions for each opportunity
- Test solutions, not opportunities

---

步骤 5：持续探索

## Weekly Discovery Rhythm

### The Cadence

**Monday: Prep**
- Review last week's learnings
- Prioritize this week's questions
- Schedule interviews/tests

**Tuesday-Thursday: Research**
- Customer interviews (2-3 per week minimum)
- Prototype testing
- Data analysis
- Experiment monitoring

**Friday: Synthesis**
- Consolidate learnings
- Update opportunity assessment
- Share with delivery team
- Plan next week

### The Habits

**1. Weekly customer touchpoint**
- Minimum: 2-3 customer conversations/week
- Mix: Prospects, users, churned customers

**2. Assumption tracking**
- List key assumptions
- Design tests for riskiest ones
- Document learnings

**3. Experiment backlog**
- Always have 2-3 experiments running
- Quick iterations over perfect tests

**4. Cross-functional involvement**
- Engineering in discovery
- Design in customer calls
- PM facilitates, doesn't dictate

### The Anti-Patterns

**Discovery theater:**
- Doing research but not changing decisions
- Fix: Tie discovery directly to roadmap decisions

**Big bang research:**
- Quarterly research sprints instead of continuous
- Fix: Small, frequent over large, infrequent

**Validation bias:**
- Only seeking confirmation
- Fix: Actively try to disprove hypotheses

---

示例

示例 1：探索新功能

输入：

“我们正在考虑为项目管理工具添加日历集成。如何在开发之前验证这个想法？”

输出：

探索计划：日历集成

风险评估

风险	等级	原因
价值	高	尚不清楚这是否能解决真实问题
易用性	中	日历 UI 很复杂
可行性	低	已有成熟的集成（Google、Outlook）
可持续性	低	符合产品战略

**探索重点：**价值风险（优先），然后是易用性风险

探索活动

第 1 周：了解问题

客户访谈（5-8 次）

目标：当前负责管理时效性项目的用户

问题：

1. “请带我了解一下，你现在如何为团队安排工作。”
2. “如果错过截止日期会发生什么？你如何得知？”
3. “日历在项目管理中扮演什么角色？”
4. “让项目和日历保持同步，最让你烦恼的是什么？”
5. “请举例说明上次因日历和项目脱节而错过事情的情况。”

需要留意的方面：

• 是否确实存在痛点？程度如何？
• 他们目前采用哪些变通方法？
• 这是“锦上添花”还是“必不可少”？

第 2 周：评估需求

假门测试

1. 在设置中添加“日历同步（即将推出）”按钮
2. 点击后显示：“感谢关注！欢迎加入候补名单。”
3. 跟踪：点击率、候补名单转化率

成功标准：

• 5% 的 MAU 点击按钮 = 强烈信号

• 2-5% = 中等信号
• <2% = 信号较弱

分析现有数据：

• 有多少用户在支持工单中提到“日历”？
• 用户目前连接了哪些集成？
• 使用日历工具的用户，参与度更高还是更低？

第 3 周：测试解决方案

原型测试（如果第 1-2 周显示出信号）

低保真原型展示：

1. 日历同步设置流程
2. 同步后的事件如何显示
3. 冲突解决方式

邀请 5 位用户测试：

• 他们能否在没有帮助的情况下完成设置？
• 这是否符合他们的心智模型？
• 哪些地方让人困惑？

绿野仙踪测试

针对 10 位用户：

1. 手动将他们的日历事项同步到项目中
2. 每天向他们发送摘要邮件
3. 1 周后进行访谈：这有价值吗？

决策框架

发现	决策
价值信号强烈 + 原型易用	开始构建
价值信号强烈 + 存在易用性问题	重新设计，再次测试
价值信号较弱	不予构建，暂时搁置想法
仅对部分用户有价值	考虑调整范围/细分用户

时间线

• 第 1 周：访谈 → 了解问题
• 第 2 周：假门测试 + 数据 → 验证需求
• 第 3 周：原型 → 验证解决方案
• 第 4 周：综合分析 → 决定是否构建

探索阶段总投入： 4 周，约 40 小时
对比之下，未经过探索就直接构建： 3-6 个月的工程投入

---

示例 2：持续探索的启动方案

输入：

“我是一家 B2B SaaS 初创公司的 PM。我们没有开展任何正式的探索，只是根据客户的要求或 CEO 的想法来构建产品。我该如何开始持续探索？”

输出：

持续探索启动方案

从小处着手，养成习惯

不要试图：

• 彻底重塑整个流程
• 停止所有当前开发工作
• 聘请研究团队

应该：

• 每周增加一项探索习惯
• 从自己能掌控的事情开始
• 尽快展示价值

第 1 周：养成与客户交流的习惯

行动： 安排下周进行 2 次客户通话。

交流对象：

• 1 位最近流失或降级的客户
• 1 位最近升级或参与度很高的客户

话术： “我们正在努力让 [产品] 更好地服务像你这样的用户。 希望能占用 20 分钟，了解你如何使用它，以及我们可以 改进哪些方面。这不是销售电话，只是想了解情况。”

每次通话后： 写下 3-5 条要点：

• 他们想解决什么问题？
• 哪些方面有效？哪些无效？
• 有什么让我感到意外？

第 2 周：跟踪假设

行动： 对于正在开发的每项功能，列出最重要的 3 个假设。

示例格式：

Feature: New onboarding flow
Assumptions:
1. Users don't complete onboarding because it's too long
2. Users who complete onboarding retain better
3. Users want to invite teammates during onboarding

Evidence level:
1. Assumption (no evidence)
2. Validated (we have data)
3. Assumption (no evidence)

与团队分享： “这是我们的假设。哪些假设最不确定？ 我们可以如何测试？”

第 3 周：增加访谈问题

行动： 在每次客户通话（支持、销售、客户成功）中增加一个探索问题。

问题： “你目前面临的最大挑战是什么，而我们现在还无法帮助你解决？”

收集回答： 建立共享文档/Slack 频道，供团队发布回答。

每周回顾： “我们与 8 位客户进行了交流。以下是我们听到的挑战……”

第 4 周：小型实验

行动： 开展一项小型实验。

简单的选项：

• 在应用内针对某项拟议功能开展调查
• 为功能创意设置虚假入口
• 对引导流程进行 A/B 测试

分享结果： “我们测试了 [X]。以下是我们的收获：[Y]。 这改变了我们对 [Z] 的看法。”

赢得高管支持

不要请求许可。展示价值。

4 周后，分享：

• “我们与 8 位客户交谈了。以下是我们的收获。”
• “我们开展了一项实验。结果告诉我们 [X]。”
• “这让我们避免开发一项根据数据表明客户其实并不需要的[功能]。”

推介： “我不是在请求大量的研究投入。我每周花 2-3 小时与客户交谈并开展小型测试。 这已经帮助我们更好地确定优先级。”

扩大规模

习惯建立后（4-8 周）：

1. **规范访谈节奏：**团队标准为每周 2-3 次
2. **建立机会待办列表：**我们可能会解决的问题
3. **与路线图关联：**探索研究为我们的开发方向提供依据
4. **让工程团队参与：**让工程师参与客户沟通

---

示例 3：机会评估

输入：

“我们有三个可能开发的功能：（A）AI 驱动的建议，（B）团队协作改进，（C）移动应用。我该如何评估它们的优先级？”

输出：

机会评估：功能优先级排序

机会 A：AI 驱动的建议

问题评估

因素	评分	原因
使用频率	3	每日使用场景
影响程度	2	有了更好，没有也不痛苦
付费意愿	2	市场期待 AI，但它能否带来差异化？
市场规模	4	适用于大多数用户
问题得分	2.75

解决方案评估

因素	评分	原因
可行性	3	需要机器学习专业知识，但可以实现
战略契合度	4	符合“智能产品”的愿景
竞争优势	2	其他人很容易复制
解决方案得分	3.0

主要风险：

• 价值：建议是否足够好用，值得采用？
• 可行性：我们是否拥有机器学习人才？
• 商业可行性：训练数据需求、成本

机会得分：8.25

---

机会 B：团队协作

问题评估

因素	评分	原因
使用频率	5	团队每天会用多次
影响程度	4	当前的阻碍导致用户采取变通做法
付费意愿	4	已提供团队定价层级
市场规模	3	仅适用于团队账户
问题得分	4.0

解决方案评估

因素	评分	原因
可行性	4	标准功能，已有成熟模式
战略契合度	5	直接支持增长战略
竞争优势	3	有望实现差异化，但优势不大
解决方案得分	4.0

主要风险：

• 价值：哪些具体的协作功能最重要？
• 易用性：团队功能很快就会变得复杂

机会得分：16.0

---

机会 C：移动应用

问题评估

因素	评分	原因
使用频率	3	一些用户希望使用移动端，但大多数用户使用桌面端
影响程度	4	移动端用户非常苦恼
付费意愿	2	属于用户预期，而非高级功能
市场规模	2	只有部分用户需要移动端
问题得分	2.75

解决方案评估

因素	评分	原因
可行性	2	需要投入大量精力（iOS + Android + 维护）
战略契合度	3	并非当前定位的核心
竞争优势	2	属于基本要求，而非差异化优势
解决方案得分	2.33

主要风险：

• 商业可行性：持续维护成本
• 可行性：原生开发还是跨平台开发的选择

机会得分：6.4

---

总结与建议

机会	问题	解决方案	得分	排名
团队协作	4.0	4.0	16.0	第 1 名
AI 建议	2.75	3.0	8.25	第 2 名
移动应用	2.75	2.33	6.4	第 3 名

建议：

1. 优先推进团队协作

   • 问题强度最高
   • 与战略方向契合
   • 切实可行

2. 暂缓 AI 建议

   • 先验证价值风险
   • 思考：哪些具体建议会有价值？
   • 先用简单规则测试，再考虑机器学习

3. 降低移动应用的优先级

   • 工作量大，覆盖范围有限
   • 思考：能否先采用渐进式 Web 应用？
   • 团队协作成熟后再重新评估

后续步骤：

• 围绕团队协作痛点开展 5 次访谈
• 找出 3 个最重要的具体协作问题
• 在决定全面开发前进行原型设计和测试

---

清单与模板

发现阶段启动清单

## Before Starting Discovery

### Define the Scope
□ What outcome are we trying to achieve?
□ What problem might we solve?
□ Who is the target customer?
□ What's the timeline for decision?

### Identify Assumptions
□ List top 10 assumptions about problem and solution
□ Rank by risk level (if wrong, how bad?)
□ Identify top 3 to test first

### Plan Activities
□ Customer interviews scheduled (minimum 5)
□ Data/analytics to review identified
□ Prototype or experiment designed
□ Success criteria defined

### Align Team
□ Cross-functional team identified
□ Discovery goals shared
□ Calendar blocked for activities

---

发现阶段总结模板

## Discovery Summary: [Feature/Opportunity]

### Problem Statement
[What problem are we solving? For whom?]

### Research Conducted
- [X] customer interviews
- [X] data analyses
- [X] prototype tests
- [X] experiments

### Key Findings

**What we learned about the problem:**
1.
2.
3.

**What we learned about solutions:**
1.
2.
3.

### Risk Assessment

| Risk | Level | Mitigation |
|------|-------|------------|
| Value | | |
| Usability | | |
| Feasibility | | |
| Viability | | |

### Recommendation
[Build / Don't Build / Need More Discovery]

### If Building, Success Metrics
- Metric 1:
- Metric 2:
- Metric 3:

---

技能边界

此技能擅长的方面

• 组织有说服力的内容
• 应用文案撰写框架
• 创建不同的草稿版本
• 分析竞争对手的做法

此技能无法做到的方面

• 保证转化率
• 取代品牌语气的塑造
• 了解你的特定受众
• 做出最终审批决定

参考资料

• Cagan, Marty. “Inspired: How to Create Tech Products Customers Love”（2018）
• Cagan, Marty & Jones, Chris. “Empowered”（2020）
• Torres, Teresa. “Continuous Discovery Habits”（2021）
• Silicon Valley Product Group (SVPG) 资源
• Intercom 产品管理内容

相关技能

• customer-discovery - Steve Blank 的广义框架
• mom-test - 客户访谈技巧
• lean-canvas - 商业模式验证
• shape-up - Basecamp 的开发方法
• design-sprint - Google Ventures 冲刺

---

技能元数据

• 模式：cyborg

name: product-discovery
category: product
subcategory: methodology
version: 1.0
author: MKTG Skills
source_expert: Marty Cagan
source_work: Inspired, Empowered
difficulty: intermediate
estimated_value: $10,000+ product consulting engagement
tags: [product, discovery, validation, PM, Cagan, SVPG, risk, prototyping]
created: 2026-01-25
updated: 2026-01-25