continuous-discovery-habits
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseContinuous Discovery Habits
持续发现习惯
A structured, repeatable approach to product discovery that helps teams make better product decisions through weekly customer touchpoints, opportunity mapping, and rapid assumption testing. Based on Teresa Torres' "Continuous Discovery Habits."
这是一套结构化、可重复的产品发现方法，通过每周客户接触、机会映射和快速假设测试，帮助团队做出更优的产品决策。该方法基于Teresa Torres所著的《持续发现习惯》。
Core Principle
核心原则
Good product teams don't debate opinions — they test assumptions. The goal of discovery is not to validate ideas, but to discover opportunities and find the best path to a desired outcome. Discovery is not a phase; it is a continuous, weekly habit embedded into how teams work.
The foundation: most product teams skip discovery entirely, jumping from a business outcome directly to a solution. The Opportunity Solution Tree (OST) provides the missing structure — it forces teams to explore the problem space before committing to solutions, and to compare multiple solutions against clear criteria before building anything.
优秀的产品团队不会争论观点——他们会测试假设。 发现的目标不是验证想法，而是发掘机会，并找到实现期望结果的最佳路径。发现不是一个阶段，而是嵌入团队工作流程的持续性每周习惯。
核心基础：大多数产品团队会完全跳过发现环节，直接从业务结果跳到解决方案。机会解决方案树（OST）填补了这一空白——它迫使团队在投入解决方案前先探索问题空间，并在开发任何功能前，根据明确标准对比多个解决方案。
Scoring
评分标准
Goal: 10/10. When reviewing product discovery work, rate it 0-10:
| Score | Description |
|---|---|
| 0-2 | No discovery. Team builds what stakeholders request or what feels right. No customer contact. |
| 3-4 | Sporadic discovery. Occasional user research, but not connected to decisions. Ideas come from inside the building. |
| 5-6 | Some structure. Team talks to customers but lacks a systematic way to prioritize opportunities or test assumptions. |
| 7-8 | Strong discovery. OST exists, weekly customer touchpoints, assumption testing before building. |
| 9-10 | Exceptional. Full OST discipline, compare-and-contrast experiments, story-based interviews, and the whole team participates in discovery weekly. |
目标：10/10。 评估产品发现工作时，按0-10分打分：
| 分数 | 描述 |
|---|---|
| 0-2 | 未开展发现工作。团队按利益相关者要求或主观判断开发功能，未接触客户。 |
| 3-4 | 偶尔开展发现工作。进行过零星的用户研究，但未与决策挂钩。想法均来自内部。 |
| 5-6 | 具备一定结构。团队会与客户沟通，但缺乏系统化的机会优先级排序或假设测试方法。 |
| 7-8 | 发现工作完善。已建立OST，保持每周客户接触，在开发前进行假设测试。 |
| 9-10 | 发现工作卓越。严格遵循OST规范，开展对比实验，采用故事式访谈，且整个团队每周参与发现工作。 |
The Opportunity Solution Tree (OST)
机会解决方案树（OST）
The core visual framework connecting business outcomes to solutions through opportunities:
Desired Outcome
(metric to move)
│
┌─────────┼─────────┐
▼ ▼ ▼
Opportunity Opportunity Opportunity
(unmet need) (pain point) (desire)
│ │
┌─┴─┐ ┌─┴─┐
▼ ▼ ▼ ▼
Sol. Sol. Sol. Sol.
│ │
▼ ▼
Assumption Assumption
Tests TestsRules for a good OST:
- One desired outcome at the top — the metric the team is trying to move
- Opportunities are customer needs, pain points, or desires — never solutions
- Solutions address specific opportunities — each solution maps to at least one opportunity
- Assumption tests validate the riskiest assumptions before building
- The tree is a living document, updated weekly
连接业务结果与解决方案的核心可视化框架，中间以机会为桥梁：
Desired Outcome
(metric to move)
│
┌─────────┼─────────┐
▼ ▼ ▼
Opportunity Opportunity Opportunity
(unmet need) (pain point) (desire)
│ │
┌─┴─┐ ┌─┴─┐
▼ ▼ ▼ ▼
Sol. Sol. Sol. Sol.
│ │
▼ ▼
Assumption Assumption
Tests Tests构建优质OST的规则：
- 顶部仅有一个期望结果——团队试图影响的指标
- 机会指客户的需求、痛点或期望——绝不是解决方案
- 解决方案针对特定机会——每个解决方案至少映射到一个机会
- 假设测试在开发前验证风险最高的假设
- 该树是动态文档，每周更新
Premortem Check
事前验尸检查
Before committing to a solution branch on the OST, run a premortem: imagine the solution has shipped and failed completely. Ask "What went wrong?" and have every member of the product trio independently write down failure causes. Cluster the answers — recurring themes reveal the assumptions that are most likely to be fatal.
How to run it:
| Step | Action |
|---|---|
| 1. Set the scene | "It's six months from now. We shipped this solution and it failed. Walk me through what happened." |
| 2. Write independently | Each person writes 3-5 failure reasons before discussing — avoids anchoring bias |
| 3. Cluster themes | Group similar failures; the clusters with the most entries are your highest-risk assumptions |
| 4. Map to assumption types | Assign each cluster to desirability, viability, feasibility, or usability |
| 5. Prioritize the tree | Branches whose premortem reveals high-risk untested assumptions should be tested before branches with lower risk profiles |
When to use it: After generating solution candidates (step 4 below) but before selecting which to test first. A 20-minute premortem is the cheapest way to surface the assumption most likely to kill the solution — before any engineering time is spent.
在OST上确定解决方案分支前，开展事前验尸：假设该解决方案已上线但完全失败，询问“哪里出了问题？”，让产品三人组的每位成员独立写下失败原因。将答案归类——重复出现的主题揭示了最可能致命的假设。
操作步骤：
| 步骤 | 行动 |
|---|---|
| 1. 设置场景 | “六个月后，我们上线了这个解决方案但失败了。告诉我发生了什么。” |
| 2. 独立撰写 | 每个人先写下3-5个失败原因再讨论——避免锚定偏差 |
| 3. 归类主题 | 将相似失败原因分组；条目最多的类别即为最高风险假设 |
| 4. 映射假设类型 | 将每个类别归类为吸引力、可行性、可实现性或易用性 |
| 5. 优先级排序 | 事前验尸揭示高风险未测试假设的分支，应比低风险分支优先测试 |
适用时机： 生成候选解决方案后（见下文步骤4），但在选择优先测试方案前。20分钟的事前验尸是在投入工程资源前，找出最可能导致解决方案失败的假设的最经济方式。
The Seven Habits
七个习惯
1. Setting the Desired Outcome
1. 设定期望结果
Core concept: A product trio (PM, designer, engineer) needs a single, clear outcome to optimize for. This outcome should be a measurable business or product metric that the team can directly influence.
Why it works: Without a clear outcome, teams optimize for output (ship features) instead of impact. A well-chosen outcome gives the team autonomy to find the best path while staying aligned with business goals.
Key insights:
- Outcomes should be lagging indicators of customer value (retention, activation, task success rate), not business vanity metrics (revenue alone)
- Teams need the authority to choose their own path to the outcome
- "Increase revenue" is too broad; "Increase 30-day retention for new users from 40% to 55%" is actionable
- Product outcomes (what customers do) lead to business outcomes (what the company gets)
Product applications:
| Context | Application | Example |
|---|---|---|
| Quarterly planning | Assign outcomes, not features, to teams | "Improve onboarding completion rate" instead of "Build new onboarding flow" |
| OKR setting | Use product outcomes as key results | KR: "Increase 7-day activation from 30% to 45%" |
| Roadmap review | Check if planned work connects to outcomes | If a feature doesn't map to an outcome, question why it's being built |
Ethical boundary: Never manipulate outcomes to justify pre-decided solutions. The outcome must come before the solution, not be reverse-engineered to support it.
See: references/desired-outcomes.md
核心概念： Product trio（PM、设计师、工程师）需要一个清晰、单一的优化目标。该结果应是团队可直接影响的可衡量业务或产品指标。
为何有效： 没有清晰结果，团队会以输出（发布功能）而非影响为优化目标。选择恰当的结果能让团队在保持与业务目标一致的同时，自主寻找最佳路径。
关键见解：
- 结果应是客户价值的滞后指标（留存率、激活率、任务成功率），而非业务虚荣指标（仅收入）
- 团队需要自主选择实现结果路径的权限
- “增加收入”过于宽泛；“将新用户30天留存率从40%提升至55%”才具可操作性
- 产品结果（客户行为）推动业务结果（公司收益）
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 季度规划 | 为团队分配结果而非功能 | “提升入职完成率”而非“构建新入职流程” |
| OKR设定 | 将产品结果作为关键结果 | KR：“将7天激活率从30%提升至45%” |
| 路线图评审 | 检查规划工作是否与结果挂钩 | 如果某功能未映射到结果，需质疑开发理由 |
伦理边界： 绝不能为了证明预先确定的解决方案而操纵结果。结果必须先于解决方案，而非反向推导以支持方案。
参考：references/desired-outcomes.md
2. Discovering Opportunities
2. 发掘机会
Core concept: Opportunities are unmet customer needs, pain points, and desires discovered through continuous customer interviews. They live in the middle layer of the OST, between the outcome and solutions.
Why it works: Most teams jump from outcome to solution. The opportunity layer forces teams to understand the problem space first. Multiple opportunities exist for any outcome; choosing the right one to address is a strategic decision.
Key insights:
- Opportunities come from customer stories, not from asking "what do you want?"
- Use story-based interviews: "Tell me about the last time you [did the thing]"
- Extract opportunities from stories — pain points, workarounds, unmet needs
- Organize opportunities in a hierarchy (parent opportunities break into sub-opportunities)
- Prioritize by frequency, intensity, and alignment with the desired outcome
The Interview Snapshot:
| Field | Content |
|---|---|
| Quick facts | Date, participant, context |
| Key moments | 3-5 notable quotes or behaviors from the interview |
| Opportunities | Unmet needs or pain points identified |
| Insights | Patterns or surprises worth noting |
Product applications:
| Context | Application | Example |
|---|---|---|
| Weekly interviews | Extract opportunities from each interview | "Users struggle to find where they left off after a break" |
| Opportunity prioritization | Score by frequency + severity + outcome alignment | High frequency + high severity + directly tied to retention = top priority |
| Stakeholder alignment | Share the opportunity tree, not just ideas | "We found 3 major opportunities. Here's why we're addressing this one first." |
Copy patterns:
- Frame features around the opportunity they solve: "Never lose your place — pick up exactly where you left off"
- Use customer language from interviews, not internal jargon
Ethical boundary: Never cherry-pick interview quotes to support a preferred solution. Report all opportunities honestly, even if they challenge existing plans.
See: references/opportunity-discovery.md
核心概念： 机会是通过持续客户访谈发现的未满足客户需求、痛点和期望。它们位于OST的中间层，介于结果与解决方案之间。
为何有效： 大多数团队直接从结果跳到解决方案。机会层迫使团队先理解问题空间。任何结果都对应多个机会，选择合适的机会进行解决是战略决策。
关键见解：
- 机会来自客户故事，而非直接询问“你想要什么？”
- 采用故事式访谈：“告诉我你上次[做某事]的经历”
- 从故事中提取机会——痛点、变通方法、未满足需求
- 按层级组织机会（父机会可拆分为子机会）
- 按频率、强度和与期望结果的对齐度排序
访谈快照：
| 字段 | 内容 |
|---|---|
| 基本信息 | 日期、受访者、场景 |
| 关键时刻 | 访谈中3-5个值得注意的引述或行为 |
| 机会 | 识别出的未满足需求或痛点 |
| 见解 | 值得关注的模式或意外发现 |
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 每周访谈 | 从每次访谈中提取机会 | “用户在休息后难以找到上次的进度位置” |
| 机会优先级排序 | 按频率+严重程度+结果对齐度打分 | 高频率+高严重程度+直接关联留存率 = 最高优先级 |
| 利益相关者对齐 | 分享机会树而非仅想法 | “我们发现了3个主要机会，以下是我们优先解决这个机会的原因。” |
文案模式：
- 围绕功能解决的机会进行表述：“永不丢失进度——从上次中断处继续”
- 使用访谈中的客户语言，而非内部行话
伦理边界： 绝不能挑选访谈引述来支持偏好的解决方案。如实报告所有机会，即使它们挑战现有计划。
参考：references/opportunity-discovery.md
3. Experience Mapping
3. 体验映射
Core concept: Current-state experience maps capture how customers accomplish a goal today, step by step, revealing pain points and unmet needs that become opportunities on the OST.
Why it works: Teams often assume they understand the customer's current experience, but mapping it collaboratively from interview data reveals gaps, workarounds, and emotions that are invisible from the inside. The map generates opportunities you would never brainstorm from a conference room.
Key insights:
- Map the current state, not a future ideal — you need to understand reality first
- Include actions, thoughts, and feelings at each step
- Build maps collaboratively with the full product trio
- Use interview data as the source, not assumptions
- Journey maps (your product's touchpoints) differ from experience maps (the customer's full experience regardless of your product)
- Pain points and moments of high emotion on the map become opportunities on the OST
Product applications:
| Context | Application | Example |
|---|---|---|
| New problem space | Map the end-to-end experience before designing anything | Map how a small business owner handles invoicing today, from creating to chasing payment |
| Churn analysis | Map the experience of users who churned to find failure points | Discover that users abandon onboarding at step 4 because they need data they don't have handy |
| Cross-functional alignment | Build the map together so engineering, design, and product share one view | Three-hour collaborative session produces a shared reference artifact |
Ethical boundary: Experience maps must reflect real customer experiences from interviews, not the team's projection of what they imagine customers feel.
See: references/experience-mapping.md
核心概念： 当前状态体验图记录客户如今完成目标的一步步流程，揭示痛点和未满足需求，这些将成为OST上的机会。
为何有效： 团队常认为自己了解客户的当前体验，但基于访谈数据协作绘制体验图，能揭示从内部视角无法看到的差距、变通方法和情绪。该图能产生仅在会议室头脑风暴无法想到的机会。
关键见解：
- 绘制当前状态而非未来理想状态——首先需要了解现实
- 包含每个步骤的行动、想法和感受
- 与整个产品三人组协作绘制
- 以访谈数据为来源，而非假设
- 旅程图（产品触点）与体验图（客户全程体验，无论是否涉及产品）不同
- 体验图中的痛点和高情绪时刻会成为OST上的机会
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 新问题领域 | 在设计任何内容前绘制端到端体验 | 绘制小企业主如今处理发票的流程，从创建到催收 |
| 流失分析 | 绘制流失用户的体验以找出失败点 | 发现用户因缺少手边数据而在入职步骤4放弃 |
| 跨职能对齐 | 共同绘制地图，让工程、设计和产品团队共享同一视角 | 三小时协作会议产出共享参考工件 |
伦理边界： 体验图必须反映访谈中的真实客户体验，而非团队想象的客户感受。
参考：references/experience-mapping.md
4. Generating and Evaluating Solutions
4. 生成与评估解决方案
Core concept: For each target opportunity, generate multiple solutions (at least 3) and compare them. Never go with the first idea. Use compare-and-contrast thinking to find creative combinations.
Why it works: The first idea is rarely the best. By forcing multiple options, teams escape anchoring bias and find solutions that are simpler, cheaper, or more effective than the obvious choice.
Key insights:
- Generate at least 3 solutions per opportunity
- Mix solution types: product changes, process changes, service changes, content changes
- Use "How Might We" (HMW) framing to generate ideas: "How might we help users pick up where they left off?"
- Evaluate solutions against effort, impact, and assumption risk
- Combine elements from different solutions — the best solution is often a hybrid
Product applications:
| Context | Application | Example |
|---|---|---|
| Ideation | Generate 3+ solutions for top opportunity | For "users lose their place": (1) auto-save with resume, (2) activity timeline, (3) daily digest email |
| Evaluation | Compare on effort/impact/risk | Auto-save: low effort, high impact, low risk → start here |
| Design review | Check that solutions map to opportunities | "Which opportunity does this feature address? Is it the top-priority one?" |
Copy patterns:
- "We explored [N] approaches before choosing the one that best addresses [opportunity]"
- "Instead of building the obvious solution, we tested [alternatives] and found [insight]"
- "This solution combines the best of [approach A] and [approach B]"
Ethical boundary: Never pre-select a solution and reverse-engineer the comparison to justify it. Compare-and-contrast must be genuine — if the process always picks the first idea, it's theater.
See: references/solution-generation.md
核心概念： 针对每个目标机会，生成多个解决方案（至少3个）并进行对比。绝不要选择第一个想法。采用对比思维寻找创意组合。
为何有效： 第一个想法很少是最佳方案。通过强制生成多个选项，团队能摆脱锚定偏差，找到比明显选择更简单、更便宜或更有效的解决方案。
关键见解：
- 每个机会至少生成3个解决方案
- 混合解决方案类型：产品变更、流程变更、服务变更、内容变更
- 使用“How Might We”（HMW）框架生成想法：“我们如何帮助用户从上次中断处继续？”
- 按投入、影响和假设风险评估解决方案
- 结合不同解决方案的元素——最佳方案通常是混合体
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 头脑风暴 | 为最高优先级机会生成3+个解决方案 | 针对“用户丢失进度”：(1) 自动保存并恢复，(2) 活动时间线，(3) 每日摘要邮件 |
| 评估 | 按投入/影响/风险对比 | 自动保存：低投入、高影响、低风险 → 优先开始 |
| 设计评审 | 检查解决方案是否映射到机会 | “该功能解决哪个机会？是否是最高优先级机会？” |
文案模式：
- “我们探索了[N]种方法后，选择了最能解决[机会]的方案”
- “我们没有构建明显的解决方案，而是测试了[替代方案]并发现了[见解]”
- “该方案结合了[方法A]和[方法B]的优势”
伦理边界： 绝不要预先选择解决方案并反向推导对比结果来证明其合理性。对比必须真实——如果流程总是选择第一个想法，那只是形式主义。
参考：references/solution-generation.md
5. Prioritizing Opportunities
5. 机会优先级排序
Core concept: Use structured methods to compare opportunities against each other rather than evaluating them in isolation. Assess opportunity size, market factors, company factors, and customer factors to find the highest-leverage bets.
Why it works: Teams default to prioritizing by loudest stakeholder voice, recency bias (whatever the last customer said), or gut feel. Structured comparison forces explicit tradeoff discussions and surfaces disagreements that would otherwise go unspoken until implementation is underway.
Key insights:
- Compare opportunities head-to-head rather than scoring them independently — relative comparison produces better decisions
- Consider opportunity sizing: how many customers are affected, how often, how severely
- Assess alignment with company strategy and team capabilities
- Factor in what you already know — opportunities with more supporting evidence are less risky to pursue
- Avoid analysis paralysis: the goal is to make a good-enough decision quickly, then learn fast
- Revisit prioritization as you learn — new evidence may shift the ranking
Product applications:
| Context | Application | Example |
|---|---|---|
| Quarterly planning | Rank the top 5-7 opportunities from the OST to decide team focus | Compare "users struggle to find content" vs. "users can't collaborate in real time" using structured criteria |
| Sprint planning | Choose which opportunity to tackle this iteration based on current evidence | Pick the opportunity where you have the most interview evidence and a testable solution |
| Portfolio decisions | Distribute team effort across opportunities by risk and potential impact | 60% on high-confidence opportunity, 30% on medium, 10% on exploratory |
Ethical boundary: Prioritization frameworks should surface real customer needs, not be gamed to justify features that serve business metrics at the expense of user value.
See: references/prioritization-methods.md
核心概念： 使用结构化方法对比机会，而非单独评估。评估机会规模、市场因素、公司因素和客户因素，找到最高杠杆的赌注。
为何有效： 团队默认按利益相关者的声音大小、近期偏差（最近客户所说内容）或直觉排序。结构化对比迫使团队明确权衡讨论，否则分歧会在实施阶段才显现。
关键见解：
- 面对面对比机会而非单独打分——相对对比能产生更好决策
- 考虑机会规模：受影响客户数量、发生频率、严重程度
- 评估与公司战略和团队能力的对齐度
- 考虑已知信息——有更多支持证据的机会风险更低
- 避免分析瘫痪：目标是快速做出足够好的决策，然后快速学习
- 随着学习深入重新审视优先级——新证据可能改变排名
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 季度规划 | 从OST中排名前5-7的机会确定团队重点 | 使用结构化标准对比“用户难以找到内容”与“用户无法实时协作” |
| 冲刺规划 | 根据当前证据选择本次迭代要解决的机会 | 选择有最多访谈证据且可测试解决方案的机会 |
| 组合决策 | 按风险和潜在影响分配团队精力 | 60%投入高信心机会，30%投入中等机会，10%投入探索性机会 |
伦理边界： 优先级框架应揭示真实客户需求，而非被操纵以证明牺牲用户价值的功能合理性。
参考：references/prioritization-methods.md
6. Assumption Mapping and Testing
6. 假设映射与测试
Core concept: Every solution is built on assumptions. Before building, identify the riskiest assumptions and test them with the smallest possible experiment. Map assumptions across four categories: desirability, viability, feasibility, and usability.
Why it works: Building is the most expensive way to test an idea. Most solutions fail because of one or two wrong assumptions. Finding those early saves weeks or months of wasted work.
Assumption categories:
| Category | Question | Example test |
|---|---|---|
| Desirability | Will customers want this? | Show a prototype, measure interest |
| Viability | Will this work for the business? | Model unit economics |
| Feasibility | Can we build this? | Technical spike or proof of concept |
| Usability | Can customers use this? | Unmoderated usability test |
The Assumption Testing Ladder:
| Level | Method | Speed | Confidence |
|---|---|---|---|
| 1 | One-question survey | Hours | Low |
| 2 | Fake door / smoke test | Days | Medium |
| 3 | Prototype test (unmoderated) | Days | Medium-High |
| 4 | Concierge / Wizard of Oz | Weeks | High |
| 5 | Live product experiment (A/B) | Weeks | Highest |
Key insights:
- Test the riskiest assumption first — the one that, if wrong, kills the whole idea
- Use the smallest experiment that will give you confidence
- "Will customers use it?" is almost always riskier than "Can we build it?"
- Set success criteria before running the test — don't rationalize results after
- Use the premortem output (see OST section) to identify which assumptions to map first
Product applications:
| Context | Application | Example |
|---|---|---|
| Before sprint planning | List top 3 assumptions for any committed work | "We assume users will notice the new button" → test with a 5-second test |
| After ideation | Pick the riskiest assumption from the winning solution | Desirability risk: "Do users actually care about resuming?" → survey + prototype |
| Retrospective | Review which assumptions were validated vs. invalidated | Track learning velocity: assumptions tested per week |
Copy patterns:
- "Before building, we tested our riskiest assumption: [assumption]. Here's what we found."
- "We set a success threshold of [X] before running the experiment — the result was [Y]"
- "This experiment disproved our assumption that [belief], saving us [time/money] in wasted development"
Ethical boundary: Design experiments to learn, not to confirm. If you're only running tests that validate your idea, you're doing it wrong.
See: references/assumption-testing.md
核心概念： 每个解决方案都基于假设。在开发前，识别风险最高的假设，用最小的实验进行测试。将假设分为四类：吸引力、可行性、可实现性和易用性。
为何有效： 开发是测试想法最昂贵的方式。大多数解决方案失败是因为一两个错误假设。尽早发现这些假设能节省数周或数月的无效工作。
假设类别：
| 类别 | 问题 | 测试示例 |
|---|---|---|
| 吸引力 | 客户会想要这个吗？ | 展示原型，衡量兴趣 |
| 可行性 | 这对业务可行吗？ | 建模单位经济效益 |
| 可实现性 | 我们能构建这个吗？ | 技术探索或概念验证 |
| 易用性 | 客户能使用这个吗？ | 无主持可用性测试 |
假设测试阶梯：
| 层级 | 方法 | 速度 | 可信度 |
|---|---|---|---|
| 1 | 单问题调查 | 数小时 | 低 |
| 2 | 假门/烟雾测试 | 数天 | 中 |
| 3 | 原型测试（无主持） | 数天 | 中-高 |
| 4 | 礼宾/绿野仙踪 | 数周 | 高 |
| 5 | 实时产品实验（A/B测试） | 数周 | 最高 |
关键见解：
- 优先测试风险最高的假设——如果该假设错误，整个想法都会失败
- 使用能带来可信度的最小实验
- “客户会使用它吗？”几乎总是比“我们能构建它吗？”风险更高
- 在运行测试前设定成功标准——不要事后合理化结果
- 利用OST部分的事前验尸输出确定首先映射哪些假设
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 冲刺规划前 | 列出所有已承诺工作的前3个假设 | “我们假设用户会注意到新按钮” → 用5秒测试验证 |
| 头脑风暴后 | 从胜出解决方案中挑选风险最高的假设 | 吸引力风险：“用户真的关心继续进度吗？” → 调查+原型 |
| 回顾会议 | 回顾哪些假设被验证或推翻 | 跟踪学习速度：每周测试的假设数量 |
文案模式：
- “在开发前，我们测试了风险最高的假设：[假设]。以下是我们的发现。”
- “我们在运行实验前设定了成功阈值[X]——结果为[Y]”
- “该实验推翻了我们[信念]的假设，为我们节省了[时间/资金]的无效开发”
伦理边界： 设计实验是为了学习，而非确认。如果仅运行验证自己想法的测试，那就是错误的做法。
参考：references/assumption-testing.md
7. Building the Habit
7. 建立习惯
Core concept: Continuous discovery only works if it becomes a sustainable weekly habit for the product trio. This requires automating recruitment, creating lightweight rituals, and embedding discovery into the existing workflow rather than treating it as extra work.
Why it works: Most teams do a burst of research at the start of a project and then stop. Continuous discovery requires structural support: automated participant recruitment, standing interview slots, shared synthesis artifacts, and team norms that make discovery non-negotiable. The habit compounds — teams that maintain it for months develop deep customer intuition that transforms every decision.
Key insights:
- The product trio (PM, designer, engineer) should participate together — not just the PM
- Automate recruitment: in-app intercepts, customer advisory panels, or scheduling tools that fill slots automatically
- Block recurring calendar time — discovery that depends on "finding time" will never happen
- Keep synthesis lightweight: fill in the snapshot immediately after the interview, not days later
- Start small: one interview per week is enough to build the habit; scale from there
- Connect discovery to delivery: insights should flow into the OST and from there into sprint planning
Product applications:
| Context | Application | Example |
|---|---|---|
| Team kickoff | Establish the weekly cadence in the first week of a new team or initiative | Set up automated recruitment, block Thursday afternoons, create snapshot template |
| Scaling discovery | Expand from one interview per week to three as the habit solidifies | Add a second slot on Tuesday for churned-user interviews and a Friday slot for prospect interviews |
| Manager support | Leaders protect discovery time and ask for evidence in planning discussions | "What did you learn from interviews this week?" becomes a standing question in 1:1s |
Ethical boundary: Respect participant time. Keep interviews to 30 minutes, compensate fairly, and never use discovery interviews as a disguised sales pitch.
核心概念： 持续发现只有在成为Product trio可持续的每周习惯时才有效。这需要自动化招募、创建轻量化流程，并将发现嵌入现有工作流程，而非视为额外工作。
为何有效： 大多数团队在项目开始时进行一轮研究后就停止了。持续发现需要结构性支持：自动化参与者招募、固定访谈时间、共享合成工件，以及让发现成为非 negotiable的团队规范。习惯会产生复利效应——坚持数月的团队会培养出深厚的客户直觉，改变每个决策。
关键见解：
- Product trio（PM、设计师、工程师）应共同参与——而非仅PM参与
- 自动化招募：应用内拦截、客户咨询小组或自动填充时段的调度工具
- 预留固定日历时间——依赖“找时间”的发现工作永远不会开展
- 轻量化合成：访谈后立即填写快照，而非数天后
- 从小处着手：每周一次访谈足以建立习惯；逐步扩展
- 连接发现与交付：见解应流入OST，再进入冲刺规划
产品应用：
| 场景 | 应用方式 | 示例 |
|---|---|---|
| 团队启动 | 在新团队或新举措的第一周建立每周节奏 | 设置自动化招募，预留周四下午时间，创建快照模板 |
| 扩展发现工作 | 习惯稳固后从每周一次访谈扩展到三次 | 增加周二时段访谈流失用户，周五时段访谈潜在客户 |
| 管理者支持 | 领导者保护发现时间，并在规划讨论中要求提供证据 | “本周访谈你学到了什么？”成为一对一会议的固定问题 |
伦理边界： 尊重参与者时间。访谈控制在30分钟内，给予合理补偿，绝不要将发现访谈伪装成销售推介。
Common Mistakes
常见错误
| Mistake | Why It Fails | Fix |
|---|---|---|
| Skipping opportunities, jumping to solutions | You might build the right solution to the wrong problem | Always fill the opportunity layer before ideating solutions |
| Interviewing only when "doing research" | Discovery becomes a phase, not a habit | Schedule 1+ customer interview per week, every week |
| Only the PM talks to customers | Designer and engineer miss context; insights lost in translation | The full product trio interviews together |
| Asking customers what they want | Customers describe solutions, not jobs or needs | Ask about past behavior: "Tell me about the last time..." |
| Testing only desirability | Ignores feasibility, viability, and usability risks | Map assumptions across all four categories |
| One solution per opportunity | First idea bias; no basis for comparison | Generate at least 3 solutions, then compare |
| No success criteria before testing | You'll rationalize any result as positive | Define "we'll proceed if X" before running the test |
| Skipping the premortem | Hidden fatal assumptions go undetected until shipping | Run a 20-minute premortem before committing to any solution branch |
| Scoring opportunities in isolation | No tradeoff discussion; everything looks important | Compare opportunities head-to-head with structured criteria |
| Doing a burst of interviews then stopping | No compounding learning; team reverts to guessing | Automate recruitment and block recurring calendar time |
| 错误 | 为何失败 | 修复方法 |
|---|---|---|
| 跳过机会，直接跳到解决方案 | 可能为错误问题构建正确解决方案 | 在构思解决方案前，始终先填充机会层 |
| 仅在“做研究”时访谈客户 | 发现成为阶段而非习惯 | 每周至少安排一次客户访谈 |
| 仅PM与客户沟通 | 设计师和工程师缺少上下文，见解在传递中丢失 | 整个产品三人组共同参与访谈 |
| 询问客户想要什么 | 客户描述的是解决方案，而非任务或需求 | 询问过去行为：“告诉我你上次……的经历” |
| 仅测试吸引力 | 忽略可行性、可实现性和易用性风险 | 将假设映射到所有四个类别 |
| 每个机会仅一个解决方案 | 首因偏差；无对比基础 | 至少生成3个解决方案，然后对比 |
| 测试前无成功标准 | 会将任何结果合理化视为积极结果 | 在运行测试前定义“如果X则推进” |
| 跳过事前验尸 | 隐藏的致命假设直到上线才被发现 | 在确定任何解决方案分支前，进行20分钟事前验尸 |
| 单独评估机会 | 无权衡讨论；所有内容看起来都重要 | 使用结构化标准面对面对比机会 |
| 进行一轮访谈后停止 | 无复利学习；团队回归猜测 | 自动化招募并预留固定日历时间 |
Quick Diagnostic
快速诊断
| Question | If No | Action |
|---|---|---|
| Do you have a clear desired outcome (metric)? | Team is output-driven | Define a product outcome with the leadership team |
| Did you talk to a customer this week? | Discovery is a phase, not a habit | Schedule a weekly recurring interview slot |
| Does the full trio participate in interviews? | Insights are filtered through one person | Invite designer and engineer to the next interview |
| Do you have an opportunity solution tree? | No structure connecting outcomes to solutions | Build one in 30 minutes with the product trio |
| Did you run a premortem before committing to a solution? | Hidden risks are untested | Run a 20-minute premortem and map the failure themes to assumptions |
| Did you consider 3+ solutions? | First-idea bias | Run a 15-minute HMW brainstorm |
| Are you comparing opportunities, not just listing them? | Prioritization is driven by opinion, not evidence | Run a structured head-to-head comparison on your top 5 opportunities |
| Did you test your riskiest assumption before building? | Building is your test (expensive) | Pick one assumption and design a 1-day experiment |
| Can you trace a shipped feature back to a customer opportunity? | Delivery is disconnected from discovery | Connect backlog items to opportunity nodes on the OST |
| Do you have interview snapshots the whole team can see? | Knowledge is trapped in one person's head | Create a shared snapshot board and fill it after each interview |
| 问题 | 如果回答否 | 行动 |
|---|---|---|
| 你有清晰的期望结果（指标）吗？ | 团队以输出为驱动 | 与领导团队定义产品结果 |
| 本周你与客户沟通了吗？ | 发现是阶段而非习惯 | 安排每周固定访谈时段 |
| 整个三人组都参与访谈了吗？ | 见解经一人过滤 | 邀请设计师和工程师参加下次访谈 |
| 你有机会解决方案树吗？ | 无连接结果与解决方案的结构 | 与产品三人组用30分钟构建一个 |
| 在确定解决方案前，你进行了事前验尸吗？ | 隐藏风险未被测试 | 进行20分钟事前验尸，并将失败主题映射到假设 |
| 你考虑了3+个解决方案吗？ | 首因偏差 | 进行15分钟HMW头脑风暴 |
| 你在对比机会，而非仅列出吗？ | 优先级由观点而非证据驱动 | 对前5个机会进行结构化面对面对比 |
| 在开发前，你测试了风险最高的假设吗？ | 开发是你的测试（昂贵） | 挑选一个假设，设计1天实验 |
| 你能将已发布功能追溯到客户机会吗？ | 交付与发现脱节 | 将待办事项连接到OST上的机会节点 |
| 整个团队都能看到访谈快照吗？ | 知识仅掌握在一人手中 | 创建共享快照板，每次访谈后填写 |
Reference Files
参考文件
- Desired Outcomes Guide — How to set product outcomes vs. business outcomes, outcome anti-patterns, and examples of well-written outcomes across different product stages
- Opportunity Discovery — Story-based interview techniques, opportunity extraction, interview snapshot templates, and opportunity hierarchy construction
- Experience Mapping — Current-state experience maps, identifying pain points, collaborative mapping exercises
- Solution Generation — How Might We techniques, compare-and-contrast evaluation, solution combination strategies, and avoiding first-idea bias
- Prioritization Methods — Opportunity scoring, compare-and-contrast, using data, avoiding analysis paralysis
- Assumption Testing — Assumption mapping across desirability/viability/feasibility/usability, experiment design templates, the testing ladder in detail, and success criteria frameworks
- Desired Outcomes Guide — 如何设定产品结果与业务结果，结果反模式，以及不同产品阶段的优秀结果示例
- Opportunity Discovery — 故事式访谈技巧，机会提取，访谈快照模板，以及机会层级构建
- Experience Mapping — 当前状态体验图，识别痛点，协作映射练习
- Solution Generation — How Might We技巧，对比评估，解决方案组合策略，以及避免首因偏差
- Prioritization Methods — 机会打分，对比，数据使用，避免分析瘫痪
- Assumption Testing — 假设在吸引力/可行性/可实现性/易用性的映射，实验设计模板，详细测试阶梯，以及成功标准框架
Further Reading
延伸阅读
About the Author
关于作者
Teresa Torres is a product discovery coach who has worked with hundreds of product teams at companies like Netflix, Microsoft, and Spotify. She created the Opportunity Solution Tree framework and advocates for weekly customer touchpoints as a core product team habit.
Teresa Torres是产品发现教练，曾与Netflix、Microsoft和Spotify等数百家公司的产品团队合作。她创建了机会解决方案树框架，并倡导将每周客户接触作为产品团队的核心习惯。