Back to Details

discovery-process

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Purpose

目的

Guide product managers through a complete discovery cycle—from initial problem hypothesis to validated solution—by orchestrating problem framing, customer interviews, synthesis, and experimentation skills into a structured process. Use this to systematically explore problem spaces, validate assumptions, and build confidence before committing to full development—avoiding "build it and they will come" syndrome and ensuring you're solving real customer problems.
This is not a one-time research project—it's a continuous discovery practice that runs in parallel with delivery, typically 1-2 discovery cycles per quarter.
通过将问题界定、客户访谈、信息整合与试验等技能整合成结构化流程，引导产品经理完成完整的发现周期——从最初的问题假设到验证通过的解决方案。在投入全面开发前，使用本方法系统性地探索问题领域、验证假设并建立信心，避免“先开发再等待用户”的误区，确保你解决的是真实的客户问题。
这不是一次性的研究项目，而是与交付并行的持续发现实践，通常每季度开展1-2个发现周期。

Key Concepts

核心概念

What is the Discovery Process?

什么是发现流程？

The discovery process (Teresa Torres, Marty Cagan) is a structured approach to exploring problem spaces and validating solutions before building. It consists of:
  1. Frame the Problem — Define what you're investigating and why
  2. Conduct Research — Gather qualitative and quantitative evidence
  3. Synthesize Insights — Identify patterns, pain points, and opportunities
  4. Generate Solutions — Explore multiple solution options
  5. Validate Solutions — Test assumptions through experiments
  6. Decide & Document — Commit to build, pivot, or kill
发现流程（由Teresa Torres、Marty Cagan提出）是一种在开发前探索问题领域并验证解决方案的结构化方法，包含以下步骤：
  1. 界定问题 —— 明确你要研究的内容及原因
  2. 开展调研 —— 收集定性和定量证据
  3. 整合洞见 —— 识别模式、痛点与机会
  4. 生成解决方案 —— 探索多种备选方案
  5. 验证解决方案 —— 通过试验测试假设
  6. 决策与记录 —— 确定开发、转向或终止

Why This Works

该方法的优势

  • De-risks product decisions: Tests assumptions before expensive builds
  • Customer-centric: Grounds decisions in real customer problems, not internal opinions
  • Iterative: Builds confidence progressively through small experiments
  • Fast learning: Discovers "no-go" signals early, saves wasted effort
  • 降低产品决策风险： 在高成本开发前测试假设
  • 以客户为中心： 基于真实客户问题而非内部意见做决策
  • 迭代式推进： 通过小型试验逐步建立信心
  • 快速学习： 尽早发现“不可行”信号，避免无效投入

Anti-Patterns (What This Is NOT)

反模式（本方法不适用的场景）

  • Not waterfall research: Discovery runs continuously, not once before dev
  • Not user testing: Discovery validates problems; testing validates solutions
  • Not a substitute for shipping: Discovery informs delivery, doesn't replace it
  • 不是瀑布式调研： 发现流程持续开展，而非仅在开发前进行一次
  • 不是用户测试： 发现流程验证问题，而测试验证解决方案
  • 不能替代交付： 发现流程为交付提供指导，而非取代交付

When to Use This

适用场景

  • Exploring new product/feature areas
  • Investigating retention or churn problems
  • Validating strategic initiatives before roadmap commitment
  • Continuous discovery (weekly customer touchpoints)
  • 探索新产品/功能领域
  • 研究留存或流失问题
  • 在纳入路线图前验证战略举措
  • 持续发现（每周与客户互动）

When NOT to Use This

不适用场景

  • For well-understood problems (move to execution)
  • When stakeholders have already committed to a solution (address alignment first)
  • For tactical bug fixes or technical debt (no discovery needed)
  • 针对已充分理解的问题（直接进入执行阶段）
  • 利益相关者已确定解决方案的情况（先解决共识问题）
  • 战术性bug修复或技术债务处理（无需开展发现流程）

Facilitation Source of Truth

引导执行的权威依据

When running this workflow as a guided conversation, use 
workshop-facilitation
 as the interaction protocol.
It defines:
  • session heads-up + entry mode (Guided, Context dump, Best guess)
  • one-question turns with plain-language prompts
  • progress labels (for example, Context Qx/8 and Scoring Qx/5)
  • interruption handling and pause/resume behavior
  • numbered recommendations at decision points
  • quick-select numbered response options for regular questions (include 
    Other (specify)
    when useful)
This file defines the workflow sequence and domain-specific outputs. If there is a conflict, follow this file's workflow logic.
当以引导式对话形式运行本工作流时，请使用
workshop-facilitation
作为交互协议。
该协议定义了：
  • 会话提醒与进入模式（引导式、背景信息输出、最佳猜测）
  • 采用平实语言提示的单轮提问机制
  • 进度标签（例如：背景问题x/8、评分问题x/5）
  • 中断处理与暂停/恢复机制
  • 决策点的编号建议
  • 常规问题的快速选择编号响应选项（必要时包含“其他（请说明）”）
本文件定义了工作流序列及特定领域输出。若存在冲突，请遵循本文件的工作流逻辑。

Application

应用方式

Use 
template.md
for the full fill-in structure.
This workflow orchestrates 6 phases over 2-4 weeks, using multiple component and interactive skills.
使用
template.md
获取完整的填充式结构。
本工作流在2-4周内统筹6个阶段，涉及多个组件式与交互式技能。

Phase 1: Frame the Problem (Day 1-2)

阶段1：界定问题（第1-2天）

Goal: Define what you're investigating, who's affected, and success criteria.
目标： 明确研究内容、受影响人群及成功标准。

Activities

活动

1. Run Problem Framing Canvas
  • Use: 
    skills/problem-framing-canvas/SKILL.md
    (interactive - MITRE)
  • Participants: PM, design, engineering lead
  • Duration: 120 minutes
  • Output: Problem statement + "How Might We" question
2. Create Formal Problem Statement
  • Use: 
    skills/problem-statement/SKILL.md
    (component)
  • Participants: PM
  • Duration: 30 minutes
  • Output: Structured problem statement with hypothesis
3. Define Proto-Personas (If Needed)
  • Use: 
    skills/proto-persona/SKILL.md
    (component)
  • When: If target customer segment is unclear
  • Duration: 60 minutes
  • Output: Hypothesis-driven personas
4. Map Jobs-to-be-Done (If Needed)
  • Use: 
    skills/jobs-to-be-done/SKILL.md
    (component)
  • When: If customer motivations are unclear
  • Duration: 60 minutes
  • Output: JTBD statements
1. 运行问题界定画布
  • 使用技能： 
    skills/problem-framing-canvas/SKILL.md
    （交互式 - MITRE）
  • 参与人员： 产品经理、设计师、工程负责人
  • 时长： 120分钟
  • 输出： 问题陈述 + “我们如何才能……”式提问
2. 撰写正式问题陈述
  • 使用技能： 
    skills/problem-statement/SKILL.md
    （组件式）
  • 参与人员： 产品经理
  • 时长： 30分钟
  • 输出： 带假设的结构化问题陈述
3. 定义原型用户画像（如有需要）
  • 使用技能： 
    skills/proto-persona/SKILL.md
    （组件式）
  • 适用场景： 目标客户群体不明确时
  • 时长： 60分钟
  • 输出： 基于假设的用户画像
4. 梳理用户待办任务（如有需要）
  • 使用技能： 
    skills/jobs-to-be-done/SKILL.md
    （组件式）
  • 适用场景： 客户动机不明确时
  • 时长： 60分钟
  • 输出： JTBD声明

Outputs from Phase 1

阶段1输出

  • Problem hypothesis: "We believe [persona] struggles with [problem] because [root cause], leading to [consequence]."
  • Research questions: 3-5 questions to answer through discovery
  • Success criteria: What would validate/invalidate the problem?
  • 问题假设： “我们认为[用户画像]在[问题]上存在困扰，原因是[根本原因]，导致了[后果]。”
  • 研究问题： 3-5个需通过发现流程解答的问题
  • 成功标准： 什么情况能验证/推翻该问题？

Decision Point 1: Do we have enough context to start research?

决策点1：我们是否有足够的背景信息启动调研？

If YES: Proceed to Phase 2 (Research Planning)
If NO: Gather existing data first:
  • Review support tickets, churn surveys, NPS feedback
  • Analyze product analytics (drop-off points, usage patterns)
  • Review competitor research, market trends
  • Time impact: +2-3 days
如果是： 进入阶段2（调研规划）
如果否： 先收集现有数据：
  • 查看支持工单、流失调研、NPS反馈
  • 分析产品数据（流失节点、使用模式）
  • 查看竞品调研、市场趋势
  • 时间影响： +2-3天

Phase 2: Research Planning (Day 3)

阶段2：调研规划（第3天）

Goal: Design research approach, recruit participants, prepare interview guide.
目标： 设计调研方法、招募受访者、准备访谈指南。

Activities

活动

1. Prep Discovery Interviews
  • Use: 
    skills/discovery-interview-prep/SKILL.md
    (interactive)
  • Participants: PM, design
  • Duration: 90 minutes
  • Output: Interview plan with methodology, questions, biases to avoid
2. Recruit Participants
  • Target: 5-10 customers per discovery cycle (Teresa Torres: continuous discovery = 1 interview/week)
  • Segment: Focus on personas from Phase 1
  • Recruitment channels:
    • Existing customers (email, in-app prompts)
    • Churned customers (exit interviews)
    • Cold outreach (LinkedIn, communities)
  • Incentive: $50-100 gift card or product credit
  • Duration: 2-3 days (parallel with Phase 1)
3. Schedule Interviews
  • Format: 45-60 min per interview (30-40 min conversation + buffer)
  • Timeline: Spread across 1-2 weeks
  • Recording: Get consent, record for synthesis
1. 准备发现访谈
  • 使用技能： 
    skills/discovery-interview-prep/SKILL.md
    （交互式）
  • 参与人员： 产品经理、设计师
  • 时长： 90分钟
  • 输出： 包含方法、问题、需避免偏见的访谈计划
2. 招募受访者
  • 目标： 每个发现周期招募5-10位客户（Teresa Torres提出：持续发现=每周1场访谈）
  • 细分群体： 聚焦阶段1确定的用户画像
  • 招募渠道：
    • 现有客户（邮件、应用内提示）
    • 流失客户（退出访谈）
    • 陌生触达（LinkedIn、社区）
  • 激励措施： 50-100美元礼品卡或产品积分
  • 时长： 2-3天（与阶段1并行开展）
3. 安排访谈
  • 形式： 每场访谈45-60分钟（30-40分钟对话+缓冲时间）
  • 时间安排： 分散在1-2周内
  • 录音： 获取同意后录音，用于后续整合

Outputs from Phase 2

阶段2输出

  • Interview guide: 5-7 open-ended questions (Mom Test style)
  • Participant roster: 5-10 scheduled interviews
  • Synthesis plan: How you'll capture and analyze insights
  • 访谈指南： 5-7个开放式问题（遵循Mom Test原则）
  • 受访者名单： 已安排的5-10场访谈
  • 整合计划： 如何收集与分析洞见

Phase 3: Conduct Research (Week 1-2)

阶段3：开展调研（第1-2周）

Goal: Gather qualitative evidence through customer interviews.
目标： 通过客户访谈收集定性证据。

Activities

活动

1. Conduct Discovery Interviews
  • Methodology: From 
    skills/discovery-interview-prep/SKILL.md
    (Problem validation, JTBD, switch interviews, etc.)
  • Participants: PM + optional observer (design, eng)
  • Duration: 5-10 interviews over 1-2 weeks
  • Focus areas:
    • Past behavior (not hypotheticals): "Tell me about the last time you [experienced this problem]"
    • Workarounds: "How do you currently handle this?"
    • Alternatives tried: "Have you tried other solutions? Why did you stop?"
    • Pain intensity: "How much time/money does this cost you?"
2. Take Structured Notes
  • Template:
    • Participant: [Name, role, company size]
    • Context: [When/where they experience problem]
    • Actions: [What they do, step-by-step]
    • Pain points: [Frustrations, blockers]
    • Workarounds: [Current solutions]
    • Quotes: [Verbatim customer language]
    • Insights: [Patterns, surprises]
3. Review Support Tickets & Analytics (Parallel)
  • Support tickets: Tag by theme (onboarding, feature confusion, bugs)
  • Analytics: Identify drop-off points, feature usage, cohort behavior
  • Surveys: Review NPS comments, exit surveys, feature requests
1. 开展发现访谈
  • 方法： 遵循
    skills/discovery-interview-prep/SKILL.md
    中的要求（问题验证、JTBD、转换访谈等）
  • 参与人员： 产品经理 + 可选观察员（设计师、工程师）
  • 时长： 1-2周内完成5-10场访谈
  • 聚焦方向：
    • 过往行为（而非假设）：“请告诉我你上次遇到这个问题时的情况”
    • 替代方案：“你目前是如何处理这个问题的？”
    • 尝试过的其他方案：“你试过其他解决方案吗？为什么放弃了？”
    • 痛点强度：“这个问题会花费你多少时间/金钱？”
2. 记录结构化笔记
  • 模板：
    • 受访者：[姓名、职位、公司规模]
    • 背景：[他们何时/何地遇到该问题]
    • 行为：[他们的具体操作步骤]
    • 痛点：[困扰、障碍]
    • 替代方案：[当前解决方案]
    • 引用：[客户原话]
    • 洞见：[模式、意外发现]
3. 同步查看支持工单与产品数据
  • 支持工单： 按主题标记（新用户引导、功能混淆、bug）
  • 产品数据： 识别流失节点、功能使用情况、群组行为
  • 调研： 查看NPS评论、退出调研、功能请求

Outputs from Phase 3

阶段3输出

  • Interview transcripts: Recorded sessions + detailed notes
  • Support ticket themes: Top 10 issues by frequency
  • Analytics insights: Quantitative data on behavior (e.g., "60% abandon onboarding at step 3")
  • 访谈记录： 录音会话 + 详细笔记
  • 支持工单主题： 按频率排序的前10个问题
  • 产品数据洞见： 行为相关的定量数据（例如：“60%的用户在新用户引导第3步放弃”）

Decision Point 2: Have we reached saturation?

决策点2：是否已达到数据饱和？

Saturation = same pain points emerge across 3+ interviews, no new insights
If YES (saturated after 5-7 interviews): Proceed to Phase 4 (Synthesis)
If NO (still learning new things): Schedule 3-5 more interviews
  • Time impact: +1 week
数据饱和 = 3场以上访谈中出现相同痛点，无新洞见产生
如果是（5-7场访谈后达到饱和）： 进入阶段4（洞见整合）
如果否（仍有新发现）： 额外安排3-5场访谈
  • 时间影响： +1周

Phase 4: Synthesize Insights (End of Week 2)

阶段4：整合洞见（第2周结束）

Goal: Identify patterns, prioritize pain points, map opportunities.
目标： 识别模式、优先处理痛点、梳理机会。

Activities

活动

1. Affinity Mapping (Thematic Analysis)
  • Method:
    • Write each insight/quote on sticky note
    • Group by theme (e.g., "onboarding confusion," "pricing objections," "mobile access")
    • Count frequency (how many customers mentioned each theme)
  • Participants: PM, design, optional eng
  • Duration: 90-120 minutes
  • Output: Themed clusters with frequency counts
2. Create Customer Journey Map (Optional)
  • Use: 
    skills/customer-journey-mapping-workshop/SKILL.md
    (interactive)
  • When: If pain points span multiple phases (discover, try, buy, use, support)
  • Duration: 90 minutes
  • Output: Journey map with opportunities ranked by impact
3. Prioritize Pain Points
  • Criteria:
    • Frequency: How many customers mentioned this?
    • Intensity: How painful is it? (time wasted, money lost, emotional frustration)
    • Strategic fit: Does solving this align with business goals?
  • Method: Score each pain point (1-5) on frequency, intensity, strategic fit
  • Output: Ranked list of top 3-5 pain points to address
4. Update Problem Statement
  • Use: 
    skills/problem-statement/SKILL.md
    (component)
  • Refine based on research: Did initial hypothesis hold? Adjust if needed.
  • Output: Validated problem statement
1. 亲和图法（主题分析）
  • 方法：
    • 将每个洞见/引用写在便利贴上
    • 按主题分组（例如：“新用户引导混淆”、“定价异议”、“移动端访问”）
    • 统计频率（有多少客户提到该主题）
  • 参与人员： 产品经理、设计师、可选工程师
  • 时长： 90-120分钟
  • 输出： 带频率统计的主题分组
2. 创建客户旅程地图（可选）
  • 使用技能： 
    skills/customer-journey-mapping-workshop/SKILL.md
    （交互式）
  • 适用场景： 痛点分布在多个阶段（发现、试用、购买、使用、支持）时
  • 时长： 90分钟
  • 输出： 按影响排序机会的旅程地图
3. 优先处理痛点
  • 评估标准：
    • 频率： 有多少客户提到该痛点？
    • 强度： 痛点的严重程度？（时间浪费、金钱损失、情绪困扰）
    • 战略契合度： 解决该痛点是否符合业务目标？
  • 方法： 按频率、强度、战略契合度对每个痛点打分（1-5分）
  • 输出： 排名前3-5的待解决痛点清单
4. 更新问题陈述
  • 使用技能： 
    skills/problem-statement/SKILL.md
    （组件式）
  • 基于调研结果优化： 初始假设是否成立？如有需要进行调整。
  • 输出： 经验证的问题陈述

Outputs from Phase 4

阶段4输出

  • Affinity map: Themes with frequency counts
  • Top 3-5 pain points: Prioritized by frequency × intensity × strategic fit
  • Customer quotes: 3-5 verbatim quotes per pain point
  • Validated problem statement: Refined based on evidence
  • 亲和图： 带频率统计的主题
  • 前3-5个痛点： 按频率×强度×战略契合度排序
  • 客户引用： 每个痛点对应3-5条客户原话
  • 经验证的问题陈述： 基于证据优化后的版本

Phase 5: Generate & Validate Solutions (Week 3)

阶段5：生成与验证解决方案（第3周）

Goal: Explore solution options, design experiments, validate assumptions.
目标： 探索解决方案选项、设计试验、验证假设。

Activities

活动

1. Generate Opportunity Solution Tree
  • Use: 
    skills/opportunity-solution-tree/SKILL.md
    (interactive)
  • Input: Top 3 pain points from Phase 4
  • Participants: PM, design, engineering lead
  • Duration: 90 minutes
  • Output: 3 opportunities, 3 solutions per opportunity, POC recommendation
Alternative: Use Lean UX Canvas
  • Use: 
    skills/lean-ux-canvas/SKILL.md
    (interactive)
  • When: Prefer hypothesis-driven approach over OST
  • Output: Hypotheses to test, minimal experiments
2. Design Experiments
  • For each solution: Define "What's the least work to learn the next most important thing?"
  • Experiment types:
    • Concierge test: Manually deliver solution to 10 customers, observe
    • Prototype test: Clickable mockup, usability test with 10 users
    • Landing page test: Fake door test (show feature, measure interest)
    • A/B test: Build minimal version, test with 50% of users
  • Success criteria: What metric/behavior validates hypothesis?
3. Run Experiments
  • Timeline: 1-2 weeks per experiment
  • Participants: PM + design (for prototypes), eng (for A/B tests)
  • Output: Quantitative and qualitative validation data
1. 生成机会-解决方案树（OST）
  • 使用技能： 
    skills/opportunity-solution-tree/SKILL.md
    （交互式）
  • 输入： 阶段4确定的前3个痛点
  • 参与人员： 产品经理、设计师、工程负责人
  • 时长： 90分钟
  • 输出： 3个机会点，每个机会点对应3个解决方案，以及POC建议
替代方案：使用Lean UX画布
  • 使用技能： 
    skills/lean-ux-canvas/SKILL.md
    （交互式）
  • 适用场景： 偏好基于假设的方法而非OST时
  • 输出： 待测试的假设、最小化试验方案
2. 设计试验
  • 针对每个解决方案： 定义“用最少的投入获取下一个最重要信息的方法是什么？”
  • 试验类型：
    • 礼宾式测试： 手动为10位客户提供解决方案并观察
    • 原型测试： 可点击原型，与10位用户开展可用性测试
    • 落地页测试： 假门测试（展示功能，衡量兴趣）
    • A/B测试： 开发最小可行版本，在50%用户中测试
  • 成功标准： 哪些指标/行为可验证假设？
3. 运行试验
  • 时间安排： 每个试验1-2周
  • 参与人员： 产品经理 + 设计师（负责原型）、工程师（负责A/B测试）
  • 输出： 定量与定性验证数据

Outputs from Phase 5

阶段5输出

  • Solution options: 3-9 solutions (3 per opportunity)
  • Experiment results: Did hypothesis validate or invalidate?
  • Customer feedback: Qualitative reactions to prototypes/concepts
  • 解决方案选项： 3-9个解决方案（每个机会点对应3个）
  • 试验结果： 假设是否得到验证？
  • 客户反馈： 对原型/概念的定性反应

Decision Point 3: Did experiments validate solution?

决策点3：试验是否验证了解决方案？

If YES (validated): Proceed to Phase 6 (Decide & Document)
If NO (invalidated):
  • Pivot to next solution option
  • Re-run experiments with adjusted approach
  • Time impact: +1-2 weeks
如果是（已验证）： 进入阶段6（决策与记录）
如果否（未验证）：
  • 转向下一个解决方案选项
  • 调整方法后重新运行试验
  • 时间影响： +1-2周

Phase 6: Decide & Document (End of Week 3-4)

阶段6：决策与记录（第3-4周结束）

Goal: Commit to build, document decision, communicate to stakeholders.
目标： 确定开发计划、记录决策、向利益相关者沟通。

Activities

活动

1. Make Go/No-Go Decision
  • Criteria:
    • Problem validated? (Phase 3-4)
    • Solution validated? (Phase 5)
    • Strategic fit? (aligns with business goals)
    • Feasible? (engineering capacity, technical complexity)
  • Decision:
    • GO: Move to roadmap, write epics/stories
    • PIVOT: Explore alternative solution
    • KILL: De-prioritize, not worth solving now
2. Define Epic Hypotheses (If GO)
  • Use: 
    skills/epic-hypothesis/SKILL.md
    (component)
  • Participants: PM
  • Duration: 60 minutes per epic
  • Output: Epic hypothesis statement with success criteria
3. Write PRD (If GO)
  • Use: 
    skills/prd-development/SKILL.md
    (workflow)
  • Participants: PM
  • Duration: 1-2 days
  • Output: Structured PRD with problem, solution, success metrics
4. Communicate Findings
  • Format: 30-min readout covering:
    • Problem validation (Phase 3-4 insights)
    • Solution validation (Phase 5 experiments)
    • Recommendation (GO/PIVOT/KILL)
  • Participants: Execs, product leadership, key stakeholders
  • Output: Alignment on next steps
1. 做出开发/终止决策
  • 评估标准：
    • 问题是否已验证？（阶段3-4）
    • 解决方案是否已验证？（阶段5）
    • 是否符合战略？（与业务目标一致）
    • 可行性如何？（工程资源、技术复杂度）
  • 决策：
    • 开发： 纳入路线图，撰写史诗/用户故事
    • 转向： 探索替代解决方案
    • 终止： 降低优先级，当前不值得解决
2. 定义史诗级假设（如果选择开发）
  • 使用技能： 
    skills/epic-hypothesis/SKILL.md
    （组件式）
  • 参与人员： 产品经理
  • 时长： 每个史诗60分钟
  • 输出： 带成功标准的史诗级假设陈述
3. 撰写PRD（如果选择开发）
  • 使用技能： 
    skills/prd-development/SKILL.md
    （工作流）
  • 参与人员： 产品经理
  • 时长： 1-2天
  • 输出： 包含问题、解决方案、成功指标的结构化PRD
4. 沟通研究结果
  • 形式： 30分钟汇报，涵盖：
    • 问题验证（阶段3-4的洞见）
    • 解决方案验证（阶段5的试验）
    • 建议（开发/转向/终止）
  • 参与人员： 高管、产品负责人、核心利益相关者
  • 输出： 就下一步行动达成共识

Outputs from Phase 6

阶段6输出

  • Decision: GO, PIVOT, or KILL
  • Epic hypotheses: (if GO) Testable epic statements
  • PRD: (if GO) Formal product requirements document
  • Stakeholder alignment: Exec buy-in on recommendation
  • 决策： 开发、转向或终止
  • 史诗级假设： （如果选择开发）可测试的史诗级陈述
  • PRD： （如果选择开发）正式产品需求文档
  • 利益相关者共识： 高管对建议的认可

Complete Workflow: End-to-End Summary

完整工作流：端到端总结

Week 1:
├─ Day 1-2: Frame the Problem
│  ├─ skills/problem-framing-canvas/SKILL.md (120 min)
│  ├─ skills/problem-statement/SKILL.md (30 min)
│  └─ [Optional] skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md
│
├─ Day 3: Research Planning
│  ├─ skills/discovery-interview-prep/SKILL.md (90 min)
│  ├─ Recruit participants (2-3 days)
│  └─ Schedule 5-10 interviews
│
└─ Day 4-5: Conduct Research (Start)
   └─ First 2-3 customer interviews

Week 2:
├─ Day 1-3: Conduct Research (Continue)
│  └─ Remaining customer interviews (3-7 more)
│
├─ Day 4-5: Synthesize Insights
│  ├─ Affinity mapping (120 min)
│  ├─ [Optional] skills/customer-journey-mapping-workshop/SKILL.md (90 min)
│  ├─ Prioritize pain points
│  └─ Update problem statement
│
└─ Decision: Reached saturation? (if NO, +1 week more interviews)

Week 3:
├─ Day 1-2: Generate & Validate Solutions
│  ├─ skills/opportunity-solution-tree/SKILL.md (90 min)
│  └─ Design experiments
│
├─ Day 3-5: Run Experiments
│  ├─ Concierge tests, prototypes, or A/B tests
│  └─ Gather validation data
│
└─ Decision: Validated? (if NO, pivot to next solution, +1-2 weeks)

Week 4:
└─ Decide & Document
   ├─ Make GO/NO-GO decision
   ├─ [If GO] skills/epic-hypothesis/SKILL.md (60 min per epic)
   ├─ [If GO] skills/prd-development/SKILL.md (1-2 days)
   └─ Communicate findings (30 min readout)
Total Time Investment:
  • Fast track: 3 weeks (5 interviews, 1 experiment)
  • Typical: 4 weeks (7-10 interviews, 1-2 experiments)
  • Thorough: 6-8 weeks (10+ interviews, multiple experiment rounds)
第1周：
├─ 第1-2天：界定问题
│  ├─ skills/problem-framing-canvas/SKILL.md (120分钟)
│  ├─ skills/problem-statement/SKILL.md (30分钟)
│  └─ [可选] skills/proto-persona/SKILL.md, skills/jobs-to-be-done/SKILL.md
│
├─ 第3天：调研规划
│  ├─ skills/discovery-interview-prep/SKILL.md (90分钟)
│  ├─ 招募受访者 (2-3天)
│  └─ 安排5-10场访谈
│
└─ 第4-5天：开展调研（启动）
   └─ 前2-3场客户访谈

第2周：
├─ 第1-3天：开展调研（持续）
│  └─ 剩余客户访谈（3-7场）
│
├─ 第4-5天：整合洞见
│  ├─ 亲和图法 (120分钟)
│  ├─ [可选] skills/customer-journey-mapping-workshop/SKILL.md (90分钟)
│  ├─ 优先处理痛点
│  └─ 更新问题陈述
│
└─ 决策：是否达到数据饱和？（如果未达到，+1周额外访谈）

第3周：
├─ 第1-2天：生成与验证解决方案
│  ├─ skills/opportunity-solution-tree/SKILL.md (90分钟)
│  └─ 设计试验
│
├─ 第3-5天：运行试验
│  ├─ 礼宾式测试、原型测试或A/B测试
│  └─ 收集验证数据
│
└─ 决策：是否验证通过？（如果未通过，转向下一个解决方案，+1-2周）

第4周：
└─ 决策与记录
   ├─ 做出开发/终止决策
   ├─ [如果选择开发] skills/epic-hypothesis/SKILL.md (每个史诗60分钟)
   ├─ [如果选择开发] skills/prd-development/SKILL.md (1-2天)
   └─ 沟通研究结果（30分钟汇报）
总投入时间：
  • 快速通道： 3周（5场访谈，1个试验）
  • 常规： 4周（7-10场访谈，1-2个试验）
  • 全面： 6-8周（10+场访谈，多轮试验）

Examples

示例

See 
examples/sample.md
for a full discovery process example.
Mini example excerpt:
markdown
**Problem:** Onboarding drop-off due to jargon
**Insight:** 6/10 users quit at step 3
**Decision:** Go with guided checklist experiment
请查看
examples/sample.md
获取完整的发现流程示例。
迷你示例片段：
markdown
**问题：** 因专业术语导致的新用户引导流失
**洞见：** 10位用户中有6位在第3步放弃
**决策：** 采用引导式清单试验方案

Common Pitfalls

常见陷阱

Pitfall 1: Skipping Customer Interviews

陷阱1：跳过客户访谈

Symptom: Rely only on analytics and support tickets, no qualitative research
Consequence: Miss "why" behind behavior, build wrong solutions
Fix: Always interview 5-10 customers per discovery cycle (even if you have data)
症状： 仅依赖产品数据与支持工单，不开展定性调研
后果： 无法理解行为背后的“原因”，开发错误的解决方案
解决方法： 每个发现周期务必访谈5-10位客户（即使已有数据）

Pitfall 2: Asking Leading Questions

陷阱2：提出诱导性问题

Symptom: "Would you use [feature X] if we built it?"
Consequence: Confirmation bias, customers say "yes" to be polite
Fix: Use Mom Test questions from 
skills/discovery-interview-prep/SKILL.md
(focus on past behavior)
症状： “如果我们开发[功能X]，你会使用吗？”
后果： 确认偏差，客户因礼貌而回答“是”
解决方法： 使用
skills/discovery-interview-prep/SKILL.md
中的Mom Test问题（聚焦过往行为）

Pitfall 3: Not Reaching Saturation

陷阱3：未达到数据饱和

Symptom: Interview 2-3 customers, declare discovery complete
Consequence: Small sample, not representative
Fix: Continue interviews until same patterns emerge across 3+ customers (typically 5-7 interviews minimum)
症状： 访谈2-3位客户后即宣布发现流程完成
后果： 样本量过小，不具代表性
解决方法： 持续访谈直到3场以上访谈出现相同模式（通常至少5-7场访谈）

Pitfall 4: Analysis Paralysis

陷阱4：分析瘫痪

Symptom: Spend 6 weeks synthesizing insights, never move to solutions
Consequence: No delivery, team loses momentum
Fix: Time-box discovery to 3-4 weeks; after Phase 6, move to execution
症状： 花费6周整合洞见，从未推进到解决方案阶段
后果： 无交付产出，团队失去动力
解决方法： 为发现流程设定3-4周的时间限制；阶段6结束后立即进入执行阶段

Pitfall 5: Discovery as One-Time Activity

陷阱5：将发现流程视为一次性活动

Symptom: Run discovery once before building, then stop
Consequence: Miss evolving customer needs, market changes
Fix: Continuous discovery (Teresa Torres): 1 customer interview per week, ongoing
症状： 开发前开展一次发现流程，之后不再进行
后果： 错失客户需求的变化与市场趋势
解决方法： 采用Teresa Torres提出的持续发现方法：每周开展1场客户访谈，持续进行

References

参考资料

Related Skills (Orchestrated by This Workflow)

相关技能（本工作流统筹的技能）

Phase 1:
  • skills/problem-framing-canvas/SKILL.md
    (interactive)
  • skills/problem-statement/SKILL.md
    (component)
  • skills/proto-persona/SKILL.md
    (component, optional)
  • skills/jobs-to-be-done/SKILL.md
    (component, optional)
Phase 2:
  • skills/discovery-interview-prep/SKILL.md
    (interactive)
Phase 4:
  • skills/customer-journey-mapping-workshop/SKILL.md
    (interactive, optional)
Phase 5:
  • skills/opportunity-solution-tree/SKILL.md
    (interactive)
  • skills/lean-ux-canvas/SKILL.md
    (interactive, alternative)
Phase 6:
  • skills/epic-hypothesis/SKILL.md
    (component)
  • skills/prd-development/SKILL.md
    (workflow)
阶段1：
  • skills/problem-framing-canvas/SKILL.md
    （交互式）
  • skills/problem-statement/SKILL.md
    （组件式）
  • skills/proto-persona/SKILL.md
    （组件式，可选）
  • skills/jobs-to-be-done/SKILL.md
    （组件式，可选）
阶段2：
  • skills/discovery-interview-prep/SKILL.md
    （交互式）
阶段4：
  • skills/customer-journey-mapping-workshop/SKILL.md
    （交互式，可选）
阶段5：
  • skills/opportunity-solution-tree/SKILL.md
    （交互式）
  • skills/lean-ux-canvas/SKILL.md
    （交互式，替代方案）
阶段6：
  • skills/epic-hypothesis/SKILL.md
    （组件式）
  • skills/prd-development/SKILL.md
    （工作流）

External Frameworks

外部框架

  • Teresa Torres, Continuous Discovery Habits (2021) — Weekly customer touchpoints, OST framework
  • Rob Fitzpatrick, The Mom Test (2013) — How to ask good interview questions
  • Marty Cagan, Inspired (2017) — Product discovery principles
  • Teresa Torres，《Continuous Discovery Habits》（2021）—— 每周客户互动、OST框架
  • Rob Fitzpatrick，《The Mom Test》（2013）—— 如何提出优质访谈问题
  • Marty Cagan，《Inspired》（2017）—— 产品发现原则

Dean's Work

Dean的相关成果

  • Productside Blueprint — Strategic discovery process
  • [If Dean has discovery resources, link here]
Skill type: Workflow Suggested filename: 
discovery-process.md
Suggested placement: 
/skills/workflows/
Dependencies: Orchestrates 10+ component and interactive skills across 6 phases
  • Productside Blueprint —— 战略发现流程
  • [若Dean有发现流程相关资源，请在此处添加链接]
技能类型： 工作流 建议文件名： 
discovery-process.md
建议存放路径： 
/skills/workflows/
依赖： 在6个阶段中统筹10+个组件式与交互式技能