Logic tree
Break a broad question into explicit branches so you can examine its parts and decide what to investigate next.
Use a logic tree when a question has several parts that need to be organized. A tree used to break down a problem is often called an issue tree. Keep a tree about causes separate from one about possible solutions.
One clear question, a basis for dividing it into branches, and evidence or open questions for each branch.
A structured investigation with defined branches, visible gaps, and specific checks for the next level of detail.
How to use it
- Write one clear question at the root.
- Choose a consistent way to divide the question into branches.
- Check branches at the same level for overlap and comparable detail.
- Break down a branch where doing so leads to a useful investigation. Attach evidence and unresolved questions.
- Choose a next check based on the evidence and the importance of the branch.
Keep its limits in mind
The shape of a tree does not establish causation or completeness. Check for overlap, missing branches, and changes in the question being answered.
Organizing an investigation into late orders
A fictional store promised to dispatch 100 orders in a week. Twenty missed their promised date. Each late order is assigned to its first recorded blocker, so the counts below assign each order once.
On a small screen, scroll across the diagram to read it.
Stock confirmation: 8 orders — inspect stock records and lookup timing.
Address clarification: 5 orders — inspect address fields and customer messages.
Order cutoff: 4 orders — compare page wording and timestamps.
Carrier pickup: 3 orders — inspect handover records and the carrier notice.
Next step: Stock confirmation affects the most orders in this case, making it a possible starting point. Urgency and impact may justify choosing another branch first.
When to stop adding branches
Use a logic tree when a question has several parts and the team needs an investigation structure. Write the parent question so that every child can answer part of it. “Where do new users stop before activation?” is different from “Why did activation decline?” A state breakdown can locate a gap without explaining why people entered that state.
Do not use the tree to manufacture certainty. Stop if the top question mixes diagnosis with a preferred solution, such as “How do we fix activation by adding reminders?” Stop if sibling counts overlap and you cannot say how a record is assigned. Stop if a branch is merely a department name with no observable question attached. In each case, repair the question or classification before creating more detail.
A clean drawing can still omit an important path. For counted branches, write a rule that another analyst could apply and retain an unknown category when source records cannot be classified. For qualitative branches, explain what each includes and excludes without pretending the list is exhaustive. Investigating a small branch may be justified by urgency or severe impact; the largest count is not automatically the first priority.
Distinguish decomposition from explanation
Select the method by the uncertainty that remains. A tree may identify a useful next question, but it should not be presented as a causal model simply because its arrows point downward.
| Method | Question | Required discipline |
|---|---|---|
| Logic tree | What parts should we investigate? | Consistent sibling rules and explicit gaps |
| KPI tree | How do defined measures combine? | A valid equation, shared units and compatible windows |
| 5 Whys | What explains this specific incident branch? | Evidence for each successive link |
| Customer journey map | What happens across a user’s experience? | A defined user scope and observations separate from guesses |
Worked case: locate an activation gap without naming a cause
This is a separate fictional product case, not the late-order diagram above. W0 and W1 are two different cohorts, each containing 120 eligible new accounts. Each has a complete seven-day observation window. Activation means creating a workspace and completing a first saved task within that window. Eligibility and event definitions are unchanged; all records in this invented packet can be classified. These assumptions must be checked in real data.
The source ledger assigns each account once to its final state at day seven: account not verified; verified but no workspace; workspace created but no first saved task; or activated. The states are mutually exclusive under the stated sequence. They are not separate counts of page visits or clicks. W0 has 12, 12, 24 and 72 accounts respectively. W1 has 24, 18, 24 and 54. Both totals are 120.
The first investigation tree asks where the end-of-window state distribution differs. W0 activation is 72/120 = 60%; W1 is 54/120 = 45%. That is a fall of 15 percentage points, or 25% relative to the W0 rate. It is not a 15% relative fall. Because these are different cohorts, the branch differences are not individual people moving backward through a funnel.
| Final state at day seven | W0 / W1 accounts | W1 minus W0; next check |
|---|---|---|
| Not verified | 12 / 24 | +12; inspect delivery and verification records, without assuming failure |
| Verified, no workspace | 12 / 18 | +6; inspect entry paths and recorded errors |
| Workspace, no first saved task | 24 / 24 | 0; compare experiences before declaring this path unchanged |
| Activated | 72 / 54 | −18; confirms the outcome gap, not its explanation |
| Total eligible accounts | 120 / 120 | 0; check eligibility and window completeness before interpreting |
From branch differences to a reviewable investigation
The provisional conclusion is that the extra 18 non-activated accounts are accounted for arithmetically by 12 more unverified accounts and six more verified accounts without a workspace. This does not establish that email delivery or workspace design caused the decline. Channel mix, different needs or measurement defects could affect where accounts appear. The unchanged count of 24 also does not prove that the underlying experiences were identical.
Propose checking event completeness first, then comparing verification sequences and workspace entry records. Retain cohort membership, event definitions and observation endpoints in the investigation sheet. If later evidence shows duplicate accounts or incomplete windows, rebuild the counts rather than keeping a convenient tree. Do not attach a remedy such as “send more reminders” to a branch before examining the actual obstacle and applicable consent.
In the review meeting, give each leaf a question, source to inspect, proposed owner and review condition. The owner and date require actual agreement. Append confirmed findings, contradictory records and unresolved cases separately. If one event pattern becomes specific enough, investigate it with 5 Whys; if user accounts reveal a confusing sequence, map that journey. The tree has done its job when it directs an observable next check, even if the ultimate explanation remains open.
Check your work
- All branches answer the same parent question.
- Categories and their counts use an explicit classification rule.
- Cause branches and proposed actions are not mixed together.
- Leaf nodes lead to observable checks or clearly identified unknowns.
Put the framework to work
Copy the outline and add your question, evidence, and open questions.
Read a practical guide →Practice with an example
Trace the scope of explanations through fictional late orders, retain unexplained cases, and leave with evidence status and a next investigation step.
The cause is unclear. What should you check first? →