hypothesis-tree

Hypothesis Tree

Build a hypothesis tree that decomposes the client question into testable branches. This skill is a tool, not a requirement — invoke it only when structuring hypotheses genuinely helps focus the research effort.

When to Use vs. Skip

Use a hypothesis tree when:

• The client question has multiple plausible answers and research needs prioritization
• The problem has 3+ distinct dimensions (e.g., market entry involves market attractiveness, competitive dynamics, and client capabilities)
• The team risks boiling the ocean without a structured view of what to investigate

Skip the hypothesis tree when:

• The question is narrow and specific enough that direct research answers it
• The user explicitly wants to go straight to research
• The situation is better served by a simple decision framework or pros/cons analysis

Process

Step 1: Start with the Governing Hypothesis

Write a single, falsifiable statement that represents the best initial answer to the client question. This is not a guess — it is a reasoned starting position that research will confirm, modify, or disprove.

Format: "We believe [specific answer to the client question] because [initial reasoning]."

The governing hypothesis must be:

• Specific enough to be wrong (if it cannot be disproven, it is not a hypothesis)
• Actionable — if proven true, the client knows what to do
• Grounded in at least preliminary logic, not pulled from thin air

Step 2: Decompose into Branches

Break the governing hypothesis into 2-4 supporting conditions — the things that must be true for the hypothesis to hold.

Each branch must be:

• Mutually exclusive: no overlap between branches
• Collectively exhaustive: together they fully support (or disprove) the governing hypothesis
• Testable: each branch ends in a question that research can answer with evidence

Do not fetishize perfect MECE structure at the expense of speed. A pragmatic decomposition that the team can test in days beats an elegant one that takes a week to build.