Back to Details

continuous-discovery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Continuous Discovery Habits

持续发现习惯

When This Skill Activates

本技能的适用场景

Claude uses this skill when:
  • Setting up discovery processes
  • Planning weekly user research
  • Creating opportunity solution trees
  • Testing assumptions
  • Building product trio workflows
  • Prioritizing discovery activities
当Claude遇到以下场景时会启用本技能：
  • 构建发现流程
  • 规划每周用户研究
  • 创建机会解决方案树（Opportunity Solution Trees）
  • 验证假设
  • 搭建产品三人组（Product Trio）工作流
  • 优先安排发现活动

Core Frameworks

核心框架

1. Continuous Discovery Habits (Source: Teresa Torres)

1. 持续发现习惯（来源：Teresa Torres）

The Core Principle:
"At a minimum, weekly touchpoints with customers by the team building the product, where they conduct small research activities in pursuit of a desired outcome."
The Three Pillars:
  1. Weekly customer contact by the product trio (PM, designer, engineer)
  2. Opportunity solution trees to visualize discovery
  3. Assumption testing before building
Use when: Establishing discovery processes or improving product decisions
核心原则：
"至少，构建产品的团队每周要与用户进行沟通，开展小型研究活动以达成预期成果。"
三大支柱：
  1. 每周用户沟通：由产品三人组（PM、设计师、工程师）执行
  2. 机会解决方案树：可视化呈现发现过程
  3. 假设验证：在开发前完成验证
适用场景： 构建发现流程或优化产品决策时

2. The Product Trio

2. 产品三人组（Product Trio）

The Team:
  • Product Manager: Ensures business viability
  • Designer: Ensures usability and desirability
  • Engineer: Ensures feasibility
Why Together:
"When a designer, engineer, and PM collaborate on discovery, you get better decisions faster. Each brings a unique lens."
How:
  • All three participate in customer interviews
  • All three analyze research together
  • All three generate solutions together
  • All three test assumptions together
团队构成：
  • Product Manager（PM）：确保业务可行性
  • Designer（设计师）：确保可用性与吸引力
  • Engineer（工程师）：确保技术可行性
为何协同工作：
"当设计师、工程师和产品经理协同开展发现工作时，能更快做出更优决策。每个人都能带来独特视角。"
协作方式：
  • 三人共同参与用户访谈
  • 三人共同分析研究结果
  • 三人共同生成解决方案
  • 三人共同验证假设

3. Opportunity Solution Trees

3. 机会解决方案树（Opportunity Solution Trees）

The Structure:
Outcome (top)
    ↓
Opportunities (customer needs/pain points)
    ↓
Solutions (possible ways to address)
    ↓
Assumptions (what needs to be true)
    ↓
Experiments (how to test)
Use when: Need to visualize the path from outcome to solution
Example:
Outcome: Increase retention to 80%
    ↓
Opportunity: Users forget to use the product
    ↓
Solution: Daily email reminder
    ↓
Assumption: Users check email daily
    ↓
Experiment: Survey 20 users about email habits
结构：
Outcome (top)
    ↓
Opportunities (customer needs/pain points)
    ↓
Solutions (possible ways to address)
    ↓
Assumptions (what needs to be true)
    ↓
Experiments (how to test)
适用场景： 需要可视化从成果到解决方案的路径时
示例：
Outcome: Increase retention to 80%
    ↓
Opportunity: Users forget to use the product
    ↓
Solution: Daily email reminder
    ↓
Assumption: Users check email daily
    ↓
Experiment: Survey 20 users about email habits

4. Interview Snapshot

4. 访谈快照

The One-Pager: After each interview, create a snapshot capturing:
  • Date & Participant: Who and when
  • Key Insights: 3-5 main takeaways
  • Opportunities: Customer needs/pain points discovered
  • Quotes: Verbatim customer language
  • Next Steps: What to test or explore next
Why: Keeps learning accessible to the whole team
单页文档： 每次访谈后，创建一份快照记录以下内容：
  • 日期与受访者： 访谈对象及时间
  • 核心洞察： 3-5个主要结论
  • 机会点： 发现的用户需求或痛点
  • 引用： 用户的原话
  • 下一步行动： 后续要测试或探索的内容
作用： 让整个团队都能获取访谈所得的信息

5. Assumption Testing

5. 假设验证

The Progression:
Story → Assumptions → Tests → Evidence
Question to Ask:
"What needs to be true for this solution to work?"
Test Types (by risk/cost):
  1. One-question surveys (lowest risk)
  2. Customer interviews
  3. Prototypes/mockups
  4. Concierge tests (manual behind-the-scenes)
  5. Wizard of Oz (fake the feature)
  6. Live data tests (build and measure)
Rule: Test highest-risk assumptions first with lowest-cost method
流程：
Story → Assumptions → Tests → Evidence
要问的问题：
"要让这个解决方案奏效，哪些前提必须成立？"
测试类型（按风险/成本划分）：
  1. 单问题调研（风险最低）
  2. 用户访谈
  3. 原型/线框图测试
  4. 礼宾式测试（后台手动操作）
  5. 绿野仙踪测试（模拟功能）
  6. 实时数据测试（开发后测量）
原则： 先用最低成本的方法测试最高风险的假设

Decision Trees

决策树

Should I Build This Feature?

我应该开发这个功能吗？

Do we have a clear outcome?
├─ No → Define outcome first
└─ Yes → Have we interviewed 6+ customers?
    ├─ No → Do discovery first
    └─ Yes → Have we identified opportunities?
        ├─ No → Map opportunities
        └─ Yes → Have we tested key assumptions?
            ├─ No → Test assumptions first
            └─ Yes → Build it!
我们有明确的成果目标吗？
├─ 否 → 先定义成果目标
└─ 是 → 我们是否访谈了6名以上用户？
    ├─ 否 → 先开展发现工作
    └─ 是 → 我们是否已识别机会点？
        ├─ 否 → 梳理机会点
        └─ 是 → 我们是否已验证关键假设？
            ├─ 否 → 先验证假设
            └─ 是 → 开发！

How Should I Test This Assumption?

我应该如何验证这个假设？

What's the risk if we're wrong?
├─ Low risk → Build and ship (reversible)
└─ High risk → How much does testing cost?
    ├─ Low cost → Interview 5 users
    ├─ Medium cost → Prototype test
    └─ High cost → Still cheaper than building wrong thing
如果我们错了，风险有多大？
├─ 低风险 → 开发并发布（可回滚）
└─ 高风险 → 测试成本有多高？
    ├─ 低成本 → 访谈5名用户
    ├─ 中等成本 → 原型测试
    └─ 高成本 → 仍比开发错误的功能更划算

Action Templates

行动模板

Template: Weekly Discovery Plan

模板：每周发现计划

markdown
undefined
markdown
undefined

Weekly Discovery Plan - Week of [Date]

每周发现计划 - [日期]

Outcome We're Pursuing

我们追求的成果

[e.g., Increase activation rate to 50%]
[例如：将激活率提升至50%]

This Week's Focus

本周重点

Opportunity: [Which pain point are we exploring?] Solution: [Which solution are we considering?] Key Assumption: [What needs to be true?]
机会点： [我们正在探索哪个痛点？] 解决方案： [我们正在考虑哪个方案？] 核心假设： [哪些前提必须成立？]

Discovery Activities (Minimum 1 per week)

发现活动（每周至少1项）

Monday-Wednesday: Research

周一至周三：研究

  • Interview 1: [Participant profile] - [PM/Designer/Engineer attending]
  • Interview 2: [Participant profile] - [PM/Designer/Engineer attending]
  • Interview 3: [Participant profile] - [PM/Designer/Engineer attending]
  • 访谈1：[受访者画像] - [参与的PM/设计师/工程师]
  • 访谈2：[受访者画像] - [参与的PM/设计师/工程师]
  • 访谈3：[受访者画像] - [参与的PM/设计师/工程师]

Thursday: Synthesis

周四：总结

  • Product trio synthesis session (30 min)
  • Create/update interview snapshots
  • Update opportunity solution tree
  • Identify new assumptions to test
  • 产品三人组总结会议（30分钟）
  • 创建/更新访谈快照
  • 更新机会解决方案树
  • 识别新的待验证假设

Friday: Planning

周五：规划

  • Review evidence collected
  • Decide: build, test more, or pivot?
  • Plan next week's discovery activities
  • 回顾收集到的证据
  • 决策：开发、进一步测试或调整方向
  • 规划下周的发现活动

Interview Snapshots

访谈快照

[Link to snapshots folder]
[快照文件夹链接]

Opportunity Solution Tree

机会解决方案树

[Link to latest tree]

---
[最新版本链接]

---

Template: Interview Snapshot

模板：访谈快照

markdown
undefined
markdown
undefined

Interview Snapshot - [Date]

访谈快照 - [日期]

Participant

受访者

  • Name/ID: [Anonymized if needed]
  • Role: [Job title/persona]
  • Context: [Relevant background]
  • 姓名/ID： [必要时匿名]
  • 角色： [职位/用户画像]
  • 背景： [相关经历]

Interview Focus

访谈重点

[What we were trying to learn]
[我们想要了解的内容]

Key Insights

核心洞察

  1. [First major insight]
  2. [Second major insight]
  3. [Third major insight]
  1. [第一个主要洞察]
  2. [第二个主要洞察]
  3. [第三个主要洞察]

Opportunities Discovered

发现的机会点

  • 📍 [Pain point or unmet need #1]
  • 📍 [Pain point or unmet need #2]
  • 📍 [Pain point or unmet need #3]
  • 📍 [痛点或未被满足的需求1]
  • 📍 [痛点或未被满足的需求2]
  • 📍 [痛点或未被满足的需求3]

Memorable Quotes

难忘引用

"[Exact customer words that capture key point]"
"[Another powerful quote]"
"[能体现核心观点的用户原话]"
"[另一句有力的引用]"

Updated Assumptions

更新后的假设

  • ✅ Validated: [What we confirmed]
  • ❌ Invalidated: [What we disproved]
  • ❓ New: [New assumptions to test]
  • ✅ 已验证：[我们确认的内容]
  • ❌ 未验证：[我们推翻的内容]
  • ❓ 新假设：[待验证的新假设]

Next Steps

下一步行动

  • [Specific action based on learning]
  • [Another action]
  • [基于洞察的具体行动]
  • [另一项行动]

Attending

参与人员

  • [PM name]
  • [Designer name]
  • [Engineer name]

---
  • [PM姓名]
  • [设计师姓名]
  • [工程师姓名]

---

Template: Opportunity Solution Tree

模板：机会解决方案树

markdown
undefined
markdown
undefined

Opportunity Solution Tree - [Product/Feature Name]

机会解决方案树 - [产品/功能名称]

Outcome

成果

🎯 [Business outcome we're driving] [Specific, measurable, time-bound]
🎯 [我们要达成的业务成果] [具体、可衡量、有时限]

Opportunities (Customer Needs/Pain Points)

机会点（用户需求/痛点）

Opportunity 1: [Customer problem]

机会点1：[用户问题]

Evidence: [3-5 customer interviews, usage data, etc.] Impact: [How big is this problem?]
证据： [3-5次用户访谈、使用数据等] 影响： 这个问题的严重程度如何？

Solutions Being Considered:

正在考虑的解决方案：

  1. [Solution A]
    • Assumptions:
      • Assumption 1
      • Assumption 2
    • Tests: [How we'll validate]
    • Status: [Testing/Building/Shipped]
  2. [Solution B]
    • Assumptions:
      • Assumption 1
      • Assumption 2
    • Tests: [How we'll validate]
    • Status: [Testing/Building/Shipped]
  1. [方案A]
    • 假设：
      • 假设1
      • 假设2
    • 测试方式：[我们将如何验证]
    • 状态：[测试中/开发中/已发布]
  2. [方案B]
    • 假设：
      • 假设1
      • 假设2
    • 测试方式：[我们将如何验证]
    • 状态：[测试中/开发中/已发布]

Opportunity 2: [Another customer problem]

机会点2：[另一个用户问题]

Evidence: [3-5 customer interviews, usage data, etc.] Impact: [How big is this problem?]
[Continue for each opportunity...]
证据： [3-5次用户访谈、使用数据等] 影响： 这个问题的严重程度如何？
[继续添加每个机会点...]

Decision Log

决策日志

  • [Date]: Chose Solution A for Opportunity 1 because [evidence]
  • [Date]: Decided to test Assumption X before building
  • [Date]: Pivoted from Solution B to Solution C based on [learning]

---
  • [日期]： 选择机会点1的方案A，原因是[证据]
  • [日期]： 决定在开发前先验证假设X
  • [日期]： 根据[洞察]从方案B调整为方案C

---

Template: Assumption Test Plan

模板：假设验证计划

markdown
undefined
markdown
undefined

Assumption Test Plan - [Feature/Solution Name]

假设验证计划 - [功能/方案名称]

Solution Statement

方案说明

[Brief description of what we're considering building]
[我们考虑开发的内容的简要描述]

Key Assumptions

核心假设

Assumption 1: [High Risk]

假设1：[高风险]

Statement: [What needs to be true] If wrong: [What's the impact?] Confidence: [Low/Medium/High]
Test Method: [Interview/Survey/Prototype/etc.] Success Criteria: [What would validate this?] Timeline: [When we'll test] Owner: [Who's running the test]
陈述： [哪些前提必须成立] 如果错误： [影响是什么？] 信心程度： [低/中/高]
测试方法： [访谈/调研/原型等] 成功标准： [什么情况能验证该假设] 时间线： [我们将在何时测试] 负责人： [执行测试的人员]

Assumption 2: [Medium Risk]

假设2：[中风险]

Statement: [What needs to be true] If wrong: [What's the impact?] Confidence: [Low/Medium/High]
Test Method: [Interview/Survey/Prototype/etc.] Success Criteria: [What would validate this?] Timeline: [When we'll test] Owner: [Who's running the test]
陈述： [哪些前提必须成立] 如果错误： [影响是什么？] 信心程度： [低/中/高]
测试方法： [访谈/调研/原型等] 成功标准： [什么情况能验证该假设] 时间线： [我们将在何时测试] 负责人： [执行测试的人员]

Test Results

测试结果

Assumption 1 Results

假设1结果

Date Tested: [Date] Method Used: [What we did] Sample Size: [How many participants]
Findings:
  • [Key finding 1]
  • [Key finding 2]
  • [Key finding 3]
Decision: ✅ Validated / ❌ Invalidated / ❓ Needs more testing Next Steps: [What we'll do based on results]
测试日期： [日期] 使用方法： [我们采取的行动] 样本量： [受访者数量]
发现：
  • [核心发现1]
  • [核心发现2]
  • [核心发现3]
决策： ✅ 已验证 / ❌ 未验证 / ❓ 需要更多测试 下一步行动： [基于结果的行动]

Assumption 2 Results

假设2结果

[Same structure as above]

---
[与上述结构相同]

---

Quick Reference

快速参考

📅 Weekly Discovery Cadence

📅 每周发现节奏

Every Week Minimum:
  • 3-5 customer touchpoints (interviews, observation, etc.)
  • Product trio participates together
  • Create interview snapshots
  • Update opportunity solution tree
  • Test at least 1 assumption
Every Month:
  • Review all evidence collected
  • Update outcomes if needed
  • Celebrate learning (not just building)
每周至少完成：
  • 3-5次用户接触（访谈、观察等）
  • 产品三人组共同参与
  • 创建访谈快照
  • 更新机会解决方案树
  • 至少验证1个假设
每月完成：
  • 回顾所有收集到的证据
  • 必要时更新成果目标
  • 庆祝洞察成果（而非仅庆祝开发成果）

🎯 Discovery vs Delivery Balance

🎯 发现与交付的平衡

Good Discovery Practice:
  • ✅ Discovery happens weekly (not just quarterly)
  • ✅ Product trio does discovery together
  • ✅ Small tests before big builds
  • ✅ Evidence-based decisions
  • ✅ Comfortable saying "we learned that won't work"
Signs of Insufficient Discovery:
  • ❌ Only talking to customers after shipping
  • ❌ PM does all research alone
  • ❌ Building first, validating later
  • ❌ Opinion-based decisions
  • ❌ Fear of "wasting time" on research
良好的发现实践：
  • ✅ 每周开展发现工作（而非仅每季度）
  • ✅ 产品三人组共同开展发现工作
  • ✅ 大型开发前先进行小型测试
  • ✅ 基于证据做决策
  • ✅ 坦然接受“我们发现这个方案不可行”
发现不足的迹象：
  • ❌ 仅在发布后才与用户沟通
  • ❌ 仅由PM独自开展所有研究
  • ❌ 先开发后验证
  • ❌ 基于观点做决策
  • ❌ 害怕“在研究上浪费时间”

🌳 Opportunity Solution Tree Checklist

🌳 机会解决方案树检查清单

Before Creating:
  • Clear outcome defined
  • Conducted 6+ customer interviews
  • Identified multiple opportunities
When Building Tree:
  • Start with ONE outcome (top)
  • Map opportunities (not solutions)
  • Generate multiple solutions per opportunity
  • List assumptions for each solution
  • Plan tests for assumptions
Using the Tree:
  • Update weekly with new learning
  • Share with stakeholders
  • Use to explain why you're building what
  • Reference when prioritizing work
创建前：
  • 已明确成果目标
  • 已开展6次以上用户访谈
  • 已识别多个机会点
构建树时：
  • 从一个成果目标开始（顶部）
  • 梳理机会点（而非解决方案）
  • 为每个机会点生成多个解决方案
  • 列出每个方案的假设
  • 规划假设的测试方式
使用树时：
  • 每周根据新洞察更新
  • 与利益相关者共享
  • 用于解释开发内容的原因
  • 用于优先安排工作

🧪 Assumption Testing Hierarchy

🧪 假设验证优先级

Test in This Order:
  1. Desirability - Do customers want this?
  2. Usability - Can they use it?
  3. Feasibility - Can we build it?
  4. Viability - Should we build it?
Use Cheapest Test First:
Interview < Survey < Prototype < Concierge < Build
按以下顺序测试：
  1. 吸引力 - 用户想要这个吗？
  2. 可用性 - 用户能使用吗？
  3. 可行性 - 我们能开发吗？
  4. ** viability（商业可行性）** - 我们应该开发吗？
先用最便宜的测试方法：
访谈 < 调研 < 原型 < 礼宾式测试 < 开发

Real-World Examples

实际案例

Example: Spotify's Discovery Process

案例：Spotify的发现流程

Outcome: Increase music discovery engagement
Opportunity: Users don't know what to listen to
  • Evidence: Interviews showed decision fatigue
  • Solution considered: Algorithmic playlists
  • Assumption: Users trust algorithmic recommendations
  • Test: Created Discover Weekly, measured engagement
  • Result: Massive success, became core feature
Key Learning: They tested the algorithm assumption before building fancy UX
成果目标： 提升音乐发现参与度
机会点： 用户不知道该听什么
  • 证据：访谈显示用户存在决策疲劳
  • 考虑的解决方案：算法推荐歌单
  • 假设：用户信任算法推荐
  • 测试：创建Discover Weekly，测量参与度
  • 结果：大获成功，成为核心功能
核心洞察： 他们在开发复杂的用户体验之前先验证了算法相关假设

Example: Netflix's Continue Watching

案例：Netflix的“继续观看”功能

Outcome: Reduce time to content consumption
Opportunity: Users forget what they were watching
  • Evidence: Drop-off analysis + customer interviews
  • Solution: "Continue Watching" row
  • Assumption: Users want to resume (not restart)
  • Test: A/B test with 5% of users
  • Result: Validated, rolled to 100%
Key Learning: Small test before full build saved months of work
成果目标： 减少内容消费的准备时间
机会点： 用户忘记之前看到哪里
  • 证据：流失分析+用户访谈
  • 解决方案：“继续观看”栏目
  • 假设：用户想要继续观看（而非重新开始）
  • 测试：对5%用户进行A/B测试
  • 结果：验证有效，推广至100%用户
核心洞察： 开发前的小型测试节省了数月的工作

Common Pitfalls

常见陷阱

❌ Discovery Theater

❌ 发现表演

Problem: Doing research but not changing decisions Solution: Explicitly decide what you'll do if assumptions are wrong
问题： 开展了研究但未改变决策 解决方案： 明确假设错误时的应对方案

❌ Outsourcing Discovery

❌ 外包发现工作

Problem: PM does research, then "throws it over the wall" Solution: Product trio interviews together
问题： PM独自完成所有研究，然后“甩锅”给团队 解决方案： 产品三人组共同参与访谈

❌ Building Multiple Solutions at Once

❌ 同时开发多个解决方案

Problem: Spreading resources too thin Solution: Test assumptions first, build one at a time
问题： 资源过于分散 解决方案： 先验证假设，再逐个开发

❌ Skipping Discovery "To Move Fast"

❌ 跳过发现“以求快速推进”

Problem: Building wrong thing is slowest path Solution: Small tests are faster than big rebuilds
问题： 开发错误的功能是最慢的路径 解决方案： 小型测试比大型重构更快

❌ Only Talking to Happy Customers

❌ 仅与满意的用户沟通

Problem: Missing problems and churn reasons Solution: Interview across the spectrum (new, power, churned users)
问题： 忽略了问题和流失原因 解决方案： 访谈全类型用户（新用户、核心用户、流失用户）

Key Quotes

核心引用

Teresa Torres on Weekly Contact:
"If you're not talking to customers every week, you're not doing continuous discovery."
On Product Trios:
"The best product decisions come from diverse perspectives. A PM, designer, and engineer will see different things in the same customer interview."
On Opportunity Solution Trees:
"The tree makes your thinking visible. It shows how you got from an outcome to a solution, which builds stakeholder trust."
On Assumption Testing:
"Don't ask customers what to build. Test assumptions about what will work."
On Discovery vs Delivery:
"Discovery and delivery should happen continuously. Discovery doesn't end when you start building."
Teresa Torres谈每周沟通：
"如果你每周不与用户沟通，就不是在做持续发现。"
谈产品三人组：
"最佳产品决策来自多元化视角。PM、设计师和工程师在同一场用户访谈中会看到不同的内容。"
谈机会解决方案树：
"这棵树让你的思考可视化。它展示了你从成果目标到解决方案的推导过程，能建立利益相关者的信任。"
谈假设验证：
"不要问用户想要什么。要验证关于方案可行性的假设。"
谈发现与交付：
"发现与交付应持续进行。发现工作不会在开发开始时就结束。"

Related Skills

相关技能

Use together with:
  • user-feedback-system - For ongoing feedback collection
  • jtbd-building - For understanding customer motivations
  • exp-driven-dev - For testing assumptions with data
  • metrics-frameworks - For defining outcomes
  • strategic-build - For deciding what's worth discovering
Comes before:
  • zero-to-launch - Discover before building
  • design-first-dev - Design based on discovery
Comes after:
  • strategy-frameworks - Define strategy, then discover how
可搭配使用：
  • user-feedback-system - 用于持续收集反馈
  • jtbd-building - 用于理解用户动机
  • exp-driven-dev - 用于基于数据验证假设
  • metrics-frameworks - 用于定义成果目标
  • strategic-build - 用于决定值得探索的方向
前置技能：
  • zero-to-launch - 先发现后开发
  • design-first-dev - 基于发现成果进行设计
后置技能：
  • strategy-frameworks - 先定义战略，再探索实施路径

Quick Start Guide

快速入门指南

Week 1: Set Up Discovery Process

第1周：搭建发现流程

  1. Form product trio (PM, designer, engineer)
  2. Define one clear outcome to pursue
  3. Schedule first 3 customer interviews
  4. Create interview snapshot template
  1. 组建产品三人组（PM、设计师、工程师）
  2. 定义一个明确的成果目标
  3. 安排前3次用户访谈
  4. 创建访谈快照模板

Week 2: Start Discovery Habit

第2周：启动发现习惯

  1. Conduct 3 interviews together
  2. Create interview snapshots
  3. Begin opportunity solution tree
  4. Identify opportunities from interviews
  1. 共同开展3次访谈
  2. 创建访谈快照
  3. 开始构建机会解决方案树
  4. 从访谈中识别机会点

Week 3: Map Solutions

第3周：梳理解决方案

  1. Generate 3+ solutions per opportunity
  2. List assumptions for each solution
  3. Prioritize which assumptions to test
  4. Plan assumption tests
  1. 为每个机会点生成3个以上解决方案
  2. 列出每个方案的假设
  3. 优先安排待验证的假设
  4. 规划假设验证计划

Week 4: Test Assumptions

第4周：验证假设

  1. Run first assumption tests
  2. Update opportunity solution tree
  3. Decide: build, test more, or pivot
  4. Make discovery routine sustainable
Remember: Continuous discovery isn't a phase. It's a habit. The product trio that talks to customers weekly makes better product decisions.
Guest: Teresa Torres
Book: Continuous Discovery Habits (2021)
Website: producttalk.org
Known for: Opportunity Solution Trees, Product Trios, Weekly Touchpoints
  1. 开展首次假设验证
  2. 更新机会解决方案树
  3. 决策：开发、进一步测试或调整方向
  4. 让发现工作成为可持续的常规流程
记住： 持续发现不是一个阶段，而是一种习惯。每周与用户沟通的产品三人组能做出更优的产品决策。
嘉宾： Teresa Torres
书籍： 《Continuous Discovery Habits》（2021）
网站： producttalk.org
专长： 机会解决方案树、产品三人组、每周用户接触