Back to Details

hypothesis-tree

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Hypothesis Tree - Structured Problem Decomposition

Hypothesis Tree - 结构化问题拆解

A Hypothesis Tree is a structured approach to breaking down complex questions into testable hypotheses. Originally from management consulting (McKinsey), it ensures MECE (Mutually Exclusive, Collectively Exhaustive) coverage of a problem space.
Hypothesis Tree是一种将复杂问题拆解为可验证假设的结构化方法。它起源于管理咨询行业（如麦肯锡），确保对问题域的MECE（Mutually Exclusive, Collectively Exhaustive）覆盖。

When to Use This Skill

何时使用该方法

  • Validating new product or feature ideas
  • Investigating why metrics are underperforming
  • Planning user research or experiments
  • Breaking down ambiguous strategic questions
  • Prioritizing what to test first
  • Communicating analysis structure to stakeholders
  • 验证新产品或功能想法
  • 调查指标表现不佳的原因
  • 规划用户研究或实验
  • 拆解模糊的战略问题
  • 优先确定测试顺序
  • 向利益相关者传达分析框架

Core Concepts

核心概念

Structure of a Hypothesis Tree

Hypothesis Tree的结构

                    Main Question
                    "Why is X happening?"
                          |
          +---------------+---------------+
          |               |               |
     Hypothesis A    Hypothesis B    Hypothesis C
          |               |               |
       +--+--+         +--+--+         +--+--+
       |     |         |     |         |     |
     Sub-   Sub-     Sub-   Sub-     Sub-   Sub-
     hyp    hyp      hyp    hyp      hyp    hyp
                    Main Question
                    "Why is X happening?"
                          |
          +---------------+---------------+
          |               |               |
     Hypothesis A    Hypothesis B    Hypothesis C
          |               |               |
       +--+--+         +--+--+         +--+--+
       |     |         |     |         |     |
     Sub-   Sub-     Sub-   Sub-     Sub-   Sub-
     hyp    hyp      hyp    hyp      hyp    hyp

MECE Principle

MECE原则

Mutually Exclusive: No overlap between branches Collectively Exhaustive: All possibilities covered
Good MECE:                    Bad (not MECE):
+----------------+            +----------------+
| New users      |            | Mobile users   | <- Overlap
|----------------|            |----------------|
| Returning      |            | New users      | <- Overlap
| users          |            |----------------|
+----------------+            | Some users     | <- Vague
                              +----------------+
Mutually Exclusive: No overlap between branches Collectively Exhaustive: All possibilities covered
Good MECE:                    Bad (not MECE):
+----------------+            +----------------+
| New users      |            | Mobile users   | <- Overlap
|----------------|            |----------------|
| Returning      |            | New users      | <- Overlap
| users          |            |----------------|
+----------------+            | Some users     | <- Vague
                              +----------------+

Hypothesis Format

假设的格式

Strong hypotheses are:
ElementDescriptionExample
SpecificClear, measurable"Checkout abandonment is >70% on mobile"
TestableCan be proven/disprovenNot "users don't like it"
FalsifiableCould be wrongHas clear failure criteria
ActionableLeads to decisionIf true → do X, if false → do Y
强有力的假设需满足：
要素描述示例
Specific清晰、可衡量"Checkout abandonment is >70% on mobile"
Testable可被证实或证伪避免使用"用户不喜欢它"这类表述
Falsifiable存在被推翻的可能有明确的失败判定标准
Actionable能引导决策如果成立→执行X，如果不成立→执行Y

Analysis Framework

分析框架

Step 1: Frame the Question

步骤1：明确问题

Convert vague concerns into structured questions:
VagueStructured
"Growth is slow""Why is our MoM user growth <5%?"
"Users aren't engaged""Why is D7 retention below 20%?"
"Feature isn't working""Why is feature X adoption <10%?"
将模糊的担忧转化为结构化问题：
模糊表述结构化问题
"增长缓慢""Why is our MoM user growth <5%?"
"用户参与度低""Why is D7 retention below 20%?"
"功能无法正常使用""Why is feature X adoption <10%?"

Step 2: Generate First-Level Hypotheses

步骤2：生成一级假设

Brainstorm potential explanations, then organize MECE:
Question: "Why is signup conversion <30%?"

Level 1 Hypotheses:
├── Awareness: Users don't understand the value proposition
├── Ability: The signup process is too difficult
├── Motivation: The perceived benefit isn't worth the effort
└── Technical: Bugs/errors prevent completion
头脑风暴潜在原因，然后按照MECE原则整理：
Question: "Why is signup conversion <30%?"

Level 1 Hypotheses:
├── Awareness: Users don't understand the value proposition
├── Ability: The signup process is too difficult
├── Motivation: The perceived benefit isn't worth the effort
└── Technical: Bugs/errors prevent completion

Step 3: Decompose to Testable Level

步骤3：拆解至可验证层级

Keep breaking down until hypotheses are directly testable:
Ability: The signup process is too difficult
├── Too many fields required
├── Password requirements unclear
├── Form validation confusing
└── Mobile experience broken
持续拆解，直到假设可直接验证：
Ability: The signup process is too difficult
├── Too many fields required
├── Password requirements unclear
├── Form validation confusing
└── Mobile experience broken

Step 4: Prioritize and Test

步骤4：优先级排序与测试

HypothesisEvidence AvailableTest EffortImpact if True
[Hyp 1][None/Some/Strong][L/M/H][L/M/H]
[Hyp 2][None/Some/Strong][L/M/H][L/M/H]
Priority = High Impact + Low Effort + Little Existing Evidence
假设现有证据测试成本成立后的影响
[Hyp 1][None/Some/Strong][L/M/H][L/M/H]
[Hyp 2][None/Some/Strong][L/M/H][L/M/H]
优先级 = 高影响 + 低成本 + 现有证据少

Output Template

输出模板

markdown
undefined
markdown
undefined

Hypothesis Tree Analysis

Hypothesis Tree Analysis

Central Question: [Clear, specific question] Date: [Date] Owner: [Name]
Central Question: [Clear, specific question] Date: [Date] Owner: [Name]

Hypothesis Tree Structure

Hypothesis Tree Structure

[Main Question] ├── H1: [First major hypothesis] │ ├── H1.1: [Sub-hypothesis] │ └── H1.2: [Sub-hypothesis] ├── H2: [Second major hypothesis] │ ├── H2.1: [Sub-hypothesis] │ └── H2.2: [Sub-hypothesis] └── H3: [Third major hypothesis] └── H3.1: [Sub-hypothesis]
[Main Question] ├── H1: [First major hypothesis] │ ├── H1.1: [Sub-hypothesis] │ └── H1.2: [Sub-hypothesis] ├── H2: [Second major hypothesis] │ ├── H2.1: [Sub-hypothesis] │ └── H2.2: [Sub-hypothesis] └── H3: [Third major hypothesis] └── H3.1: [Sub-hypothesis]

Prioritized Testing Plan

Prioritized Testing Plan

PriorityHypothesisTest MethodTimelineOwner
1[H1.2][Method][Time][Who]
2[H2.1][Method][Time][Who]
PriorityHypothesisTest MethodTimelineOwner
1[H1.2][Method][Time][Who]
2[H2.1][Method][Time][Who]

Current Evidence Summary

Current Evidence Summary

HypothesisStatusEvidence
[H1][Confirmed/Rejected/Testing][Summary]
undefined
HypothesisStatusEvidence
[H1][Confirmed/Rejected/Testing][Summary]
undefined

Real-World Examples

实际案例

Example 1: Low Feature Adoption

案例1：功能使用率低

Question: "Why is our new reporting feature only used by 8% of users?"
Low Feature Adoption
├── Awareness
│   ├── Users don't know it exists
│   └── Announcement wasn't clear
├── Value
│   ├── Feature doesn't solve their problem
│   └── Existing workarounds are "good enough"
├── Ability
│   ├── Feature is hard to find
│   └── Feature is hard to use
└── Timing
    └── Users don't need reports frequently
Question: "Why is our new reporting feature only used by 8% of users?"
Low Feature Adoption
├── Awareness
│   ├── Users don't know it exists
│   └── Announcement wasn't clear
├── Value
│   ├── Feature doesn't solve their problem
│   └── Existing workarounds are "good enough"
├── Ability
│   ├── Feature is hard to find
│   └── Feature is hard to use
└── Timing
    └── Users don't need reports frequently

Example 2: Churn Investigation

案例2：用户流失率上升调查

Question: "Why did monthly churn increase from 5% to 8%?"
Increased Churn
├── Product Changes
│   ├── Recent feature change caused issues
│   └── Performance degradation
├── Market Changes
│   ├── Competitor launched better alternative
│   └── Economic conditions changed
├── Customer Mix
│   ├── Acquired lower-quality leads
│   └── Channel mix shifted
└── Service Issues
    └── Support quality declined
Question: "Why did monthly churn increase from 5% to 8%?"
Increased Churn
├── Product Changes
│   ├── Recent feature change caused issues
│   └── Performance degradation
├── Market Changes
│   ├── Competitor launched better alternative
│   └── Economic conditions changed
├── Customer Mix
│   ├── Acquired lower-quality leads
│   └── Channel mix shifted
└── Service Issues
    └── Support quality declined

Best Practices

最佳实践

Do

建议做法

  • Start with clear, specific question
  • Check MECE at each level
  • Get to testable hypotheses quickly (3 levels usually enough)
  • Update tree as evidence comes in
  • Share tree with stakeholders for alignment
  • 从清晰、具体的问题入手
  • 在每个层级检查MECE原则
  • 快速拆解至可验证的假设（通常3层足够）
  • 根据新证据更新Hypothesis Tree
  • 与利益相关者共享Hypothesis Tree以达成共识

Avoid

避免事项

  • Overlapping hypotheses (not mutually exclusive)
  • Hypotheses that can't be tested
  • Going too deep without testing
  • Confirmation bias (seeking to prove favorite hypothesis)
  • 假设重叠（不满足相互独立）
  • 无法验证的假设
  • 未进行测试就过度拆解
  • 确认偏差（仅寻找支持偏好假设的证据）

Integration with Other Methods

与其他方法的结合

MethodCombined Use
Five WhysGo deep on confirmed hypotheses
Jobs-to-be-DoneFrame hypotheses around user jobs
Fogg Behavior ModelStructure behavioral hypotheses
方法结合方式
Five Whys针对已证实的假设深入挖掘
Jobs-to-be-Done围绕用户需求构建假设
Fogg Behavior Model构建行为相关的假设框架

Resources

参考资源