需要从问题假设到验证方案系统做产品发现时，用完整…

当团队需要结构化走过问题框定、客户访谈、洞察综合与实验验证，以在投入完整开发前确认在解决真实客户问题时使用。

适用场景

解决思路

1. 将 discovery 作为持续实践，与 delivery 并行，通常每季度运行 1-2 个 discovery cycles，而不是一次性研究项目。
2. 若作为引导式对话运行，使用 skills/workshop-facilitation/SKILL.md 作为交互协议，定义 session heads-up、entry mode（Guided、Context dump、Best guess）、单问题回合、进度标签、打断处理与暂停/恢复、决策点编号建议、快速选择编号选项；若与本文件冲突，以本文件工作流逻辑为准。
3. 使用 invocation 中已提供的文本、粘贴的上下文或追加的 ARGUMENTS: 行作为已给答案，跳过其覆盖的问题，不重复询问；若空手开始，也从问题框定开始帮助构建问题假设。
4. 使用 template.md 作为完整填写结构，并整体编排 6 个阶段、2-4 周，调用多个 component 与 interactive skills。
5. Phase 1：运行 Problem Framing Canvas——使用 skills/problem-framing-canvas/SKILL.md（interactive - MITRE），参与者 PM、design、engineering lead，120 分钟，输出问题陈述 + How Might We 问题。
6. Phase 1：创建正式问题陈述——使用 skills/problem-statement/SKILL.md（component），参与者 PM，30 分钟，输出带假设的结构化问题陈述。
7. Phase 1：必要时定义 Proto-Personas——使用 skills/proto-persona/SKILL.md（component），当目标客户细分不清晰时，60 分钟，输出假设驱动的 personas。
8. Phase 1：必要时映射 Jobs-to-be-Done——使用 skills/jobs-to-be-done/SKILL.md（component），当客户动机不清晰时，60 分钟，输出 JTBD 陈述。
9. Phase 1 输出：问题假设公式 We believe [persona] struggles with [problem] because [root cause], leading to [consequence].；3-5 个研究问题；成功标准（什么会验证/推翻问题）。
10. Decision Point 1：判断是否有足够上下文开始研究；若是，进入 Phase 2；若否，先收集现有数据：审查 support tickets、churn surveys、NPS feedback；分析产品 analytics（drop-off points、usage patterns）；审查 competitor research、market trends；时间影响 +2-3 天。
11. Phase 2：准备 Discovery Interviews——使用 skills/discovery-interview-prep/SKILL.md（interactive），参与者 PM、design，90 分钟，输出包含 methodology、questions、biases to avoid 的访谈计划。
12. Phase 2：招募参与者——每个 discovery cycle 目标 5-10 名客户（Teresa Torres：continuous discovery = 1 interview/week）；聚焦 Phase 1 的 personas；渠道包括 existing customers（email、in-app prompts）、churned customers（exit interviews）、cold outreach（LinkedIn、communities）；激励 $50-100 gift card 或 product credit；持续 2-3 天，与 Phase 1 并行。
13. Phase 2：安排访谈——每场 45-60 分钟（30-40 分钟对话 + buffer）；时间线分散在 1-2 周；获取 consent，录音用于 synthesis。
14. Phase 2 输出：5-7 个开放式问题的 interview guide（Mom Test style）；5-10 场已安排的访谈 participant roster；synthesis plan（如何捕获和分析洞察）。
15. Phase 3：进行 Discovery Interviews——方法来自 skills/discovery-interview-prep/SKILL.md（Problem validation、JTBD、switch interviews 等）；参与者 PM + 可选 observer（design、eng）；1-2 周内 5-10 场访谈；聚焦：过去行为（非假设），问 Tell me about the last time you [experienced this problem]；workarounds，问 How do you currently handle this?；尝试过的 alternatives，问 Have you tried other solutions? Why did you stop?；pain intensity，问 How much time/money does this cost you?。
16. Phase 3：做结构化笔记——模板包含 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]。
17. Phase 3：并行审查 Support Tickets & Analytics——support tickets 按主题打标签（onboarding、feature confusion、bugs）；analytics 识别 drop-off points、feature usage、cohort behavior；surveys 审查 NPS comments、exit surveys、feature requests。
18. Phase 3 输出：访谈 transcripts（录音 + 详细笔记）；support ticket themes（按频率 top 10 issues）；analytics insights（行为量化数据，例如 60% abandon onboarding at step 3）。
19. Decision Point 2：判断是否达到饱和；饱和 = 同样的 pain points 在 3+ 场访谈中出现，且无新洞察；若是（5-7 场后饱和），进入 Phase 4；若否（仍在学新东西），再安排 3-5 场访谈；时间影响 +1 周。
20. Phase 4：进行 Affinity Mapping（Thematic Analysis）——将每个 insight/quote 写在 sticky note；按主题分组（例如 onboarding confusion、pricing objections、mobile access）；统计频率（多少客户提到每个主题）；参与者 PM、design、可选 eng；90-120 分钟；输出带频率计数的主题聚类。
21. Phase 4：必要时创建 Customer Journey Map——使用 skills/customer-journey-mapping-workshop/SKILL.md（interactive）；当 pain points 横跨多个阶段（discover、try、buy、use、support）；90 分钟；输出按 impact 排序机会的 journey map。
22. Phase 4：优先级排序 Pain Points——标准 frequency（多少客户提到）、intensity（多痛：浪费时间、损失金钱、情绪挫败）、strategic fit（是否对齐业务目标）；方法：对每个 pain point 在 frequency、intensity、strategic fit 上打 1-5 分；输出 top 3-5 pain points 排名列表。
23. Phase 4：更新 Problem Statement——使用 skills/problem-statement/SKILL.md（component）；根据研究细化：初始假设是否成立？需要则调整；输出 validated problem statement。
24. Phase 4 输出：affinity map（带频率计数的主题）；top 3-5 pain points（按 frequency × intensity × strategic fit 排序）；每个 pain point 3-5 条 customer quotes；validated problem statement。
25. Phase 5：生成 Opportunity Solution Tree——使用 skills/opportunity-solution-tree/SKILL.md（interactive）；输入 Phase 4 的 top 3 pain points；参与者 PM、design、engineering lead；90 分钟；输出 3 个 opportunities、每个 opportunity 3 个 solutions、POC 建议。
26. Phase 5 替代方案：使用 Lean UX Canvas——使用 skills/lean-ux-canvas/SKILL.md（interactive）；当偏好 hypothesis-driven 方法而非 OST；输出要测试的 hypotheses、minimal experiments。
27. Phase 5：设计 Experiments——对每个 solution 定义 What's the least work to learn the next most important thing?；实验类型：Concierge test（手动向 10 名客户交付 solution 并观察）；Prototype test（clickable mockup，10 名用户 usability test）；Landing page test（fake door test，展示 feature，测量兴趣）；A/B test（构建最小版本，对 50% 用户测试）；定义 success criteria（哪个 metric/behavior 验证 hypothesis）。
28. Phase 5：运行 Experiments——每个实验 1-2 周；参与者 PM + design（用于 prototypes）、eng（用于 A/B tests）；输出 quantitative 和 qualitative validation data。
29. Phase 5 输出：solution options（3-9 个 solutions，每个 opportunity 3 个）；experiment results（hypothesis 验证或推翻）；customer feedback（对 prototypes/concepts 的定性反应）。
30. Decision Point 3：判断 experiments 是否验证 solution；若是，进入 Phase 6；若否，pivot 到下一个 solution option，用调整后的方法重跑 experiments；时间影响 +1-2 周。
31. Phase 6：做 Go/No-Go 决策——标准 problem validated?（Phase 3-4）、solution validated?（Phase 5）、strategic fit?（对齐业务目标）、feasible?（engineering capacity、technical complexity）；决策：GO（移入 roadmap，写 epics/stories）、PIVOT（探索替代 solution）、KILL（降低优先级，目前不值得解决）。
32. Phase 6：若 GO，定义 Epic Hypotheses——使用 skills/epic-hypothesis/SKILL.md（component）；参与者 PM；每个 epic 60 分钟；输出带 success criteria 的 epic hypothesis statement。
33. Phase 6：若 GO，写 PRD——使用 skills/prd-development/SKILL.md（workflow）；参与者 PM；1-2 天；输出包含 problem、solution、success metrics 的结构化 PRD。
34. Phase 6：沟通发现——30 分钟 readout，覆盖 problem validation（Phase 3-4 insights）、solution validation（Phase 5 experiments）、recommendation（GO/PIVOT/KILL）；参与者 execs、product leadership、key stakeholders；输出对 next steps 的 alignment。
35. Phase 6 输出：decision（GO、PIVOT 或 KILL）；epic hypotheses（若 GO）；PRD（若 GO）；stakeholder alignment（exec 对 recommendation 的 buy-in）。
36. 按完整 4 周工作流排期：Week1 Day1-2 Frame Problem（problem-framing-canvas 120 min、problem-statement 30 min、可选 proto-persona、jobs-to-be-done）；Day3 Research Planning（discovery-interview-prep 90 min、招募 2-3 天、安排 5-10 场访谈）；Day4-5 Conduct Research 开始（前 2-3 场访谈）。Week2 Day1-3 继续访谈（剩余 3-7 场）；Day4-5 Synthesize（affinity mapping 120 min、可选 customer-journey-mapping-workshop 90 min、排序 pain points、更新 problem statement）；决策 saturation（若否，+1 周更多访谈）。Week3 Day1-2 Generate & Validate Solutions（opportunity-solution-tree 90 min、设计 experiments）；Day3-5 运行 experiments（concierge tests、prototypes 或 A/B tests、收集 validation data）；决策 validated（若否，pivot 下一个 solution，+1-2 周）。Week4 Decide & Document（GO/NO-GO、若 GO 用 epic-hypothesis 每个 epic 60 min、若 GO 用 prd-development 1-2 天、沟通 findings 30 min readout）。总时间投资：fast track 3 周（5 场访谈、1 个实验）；typical 4 周（7-10 场访谈、1-2 个实验）；thorough 6-8 周（10+ 场访谈、多轮实验）。
37. 避免跳过客户访谈：不要只依赖 analytics 和 support tickets；每个 discovery cycle 始终访谈 5-10 名客户（即使已有数据）。
38. 避免问引导性问题：不要问 Would you use [feature X] if we built it?；使用 skills/discovery-interview-prep/SKILL.md 中的 Mom Test 问题，聚焦过去行为。
39. 避免未达到饱和：不要访谈 2-3 名客户就宣布 discovery 完成；持续访谈直到相同模式在 3+ 名客户中出现（通常最少 5-7 场访谈）。
40. 避免分析瘫痪：不要花 6 周综合洞察而不进入 solutions；将 discovery 时间限制在 3-4 周，Phase 6 后进入执行。
41. 避免把 discovery 当一次性活动：不要构建前跑一次就停止；采用 continuous discovery（Teresa Torres）：每周 1 次客户访谈，持续进行。
42. 不要把 discovery 当作 waterfall research、user testing 或 shipping 的替代：它持续运行、验证问题，并为 delivery 提供信息。

适用边界 · 注意事项

• 对于已经充分理解的问题，直接进入执行。
• 当 stakeholders 已经承诺某个解决方案时，先解决对齐问题。
• 对于战术性 bug 修复或技术债，不需要 discovery。