Issue Tree Example: Turn One Big Question into Work You Can Assign

A big question lands on your team: why is this number going the wrong way? Within a day, everyone is busy. One person compares prices. Another reads complaint logs. A third phones a few customers. Nothing connects, some work is done twice, and when the manager asks "what exactly are we testing?", nobody has a clean answer.

An issue tree fixes that. It breaks one question into smaller questions until each one is small enough to answer with a single analysis or a single data source. Then you can assign owners, track progress and say precisely what is still open.

How does an issue tree work?

An issue tree is a hierarchy of questions. The root is the question the tree must answer. The branches are sub-questions. The leaves are questions specific enough to answer directly.

Logic trees have been a working habit in consulting and operations for decades; no single author owns them. They rely on the MECE discipline: at every level the branches must not overlap and, together, must cover the parent question. If you need a refresher, start with our MECE examples.

There are two kinds:

• A diagnostic tree answers "why?" and looks for causes.
• A solution tree answers "how?" and generates options.

You usually build the diagnostic tree first. Understand the cause before you design the fix.

Why every node should be a question

"Pricing" is a topic. "Did our prices rise faster than the main competitor's on the products customers buy most?" is a question someone can answer. Topics invite endless digging; questions can be closed. A useful rule of thumb from practice: two to five branches per node, three or four levels deep.

An issue tree example

A fictional regional gym chain has seen more members cancel this year than last. The root question is diagnostic:

Why did member cancellations rise this year compared with last year?

• 1. Did we lose members we could have kept?
  • 1.1 Did the membership offer become less attractive?
    • 1.1.1 Did our fees rise relative to nearby gyms?
    • 1.1.2 Did contract terms, such as notice periods, change?
  • 1.2 Did the member experience get worse?
    • 1.2.1 Did class availability at peak hours fall?
    • 1.2.2 Did equipment downtime increase?
    • 1.2.3 Did complaint response times get longer?
• 2. Did more members leave for reasons outside our control?
  • 2.1 Did more members move away or change jobs?
  • 2.2 Did a new type of competitor open nearby?

The first split, controllable versus not controllable, was chosen because it separates the actions the chain can take from the ones it cannot. That is the test for a good first split: each branch should lead to a different owner, a different analysis or a different decision.

Next, each leaf gets a data source, an owner and a rough effort in days. "Did class availability at peak hours fall?" goes to the operations lead, answered from booking records. "Did contract terms change?" goes to finance, answered from the contract archive. If finance confirms nothing changed, that leaf closes as answered. Ruling a cause out is real progress, and it leaves the active plan.

Once the diagnostic leaves come back, the solution tree follows with a "how might we" root, and its branches will be options rather than causes.

How to build an issue tree in eight steps

1. Write the key question on top and the root under it. For a diagnostic tree, the root names the outcome, the population, the period and the direction of change.
2. Choose the first-level split carefully. It is the most important decision in the tree. Try a few candidates before building downward.
3. Write level-two sub-questions. For each branch, ask what would have to be true for it to explain the outcome, and turn that into a question.
4. Keep going until every leaf is answerable. The answerability test: someone who knows the data can say yes or no, or give a number, within a few days.
5. MECE-check every level. You should be able to explain why any two branches are different, and no plausible explanation should fall outside the set.
6. Mark each leaf with a data source and an effort. The tree now contains your analysis plan.
7. Prune with the so-what test. If the answer to a leaf would not change the recommendation either way, remove it or mark it as monitored.
8. Assign one owner and a status to each leaf: to do, in progress, answered. Review it weekly.

Where issue trees go wrong

• Topics instead of questions. The tree looks tidy but tests nothing. Rewrite every node as a question.
• A first split that does not discriminate. "Internal versus external" is common, but only useful if it sends people down different paths.
• Leaves that are still projects, or a tree that is far too deep. "Analyze customer behavior" is not a leaf. A tree fourteen levels deep is not read by anyone. Apply the answerability and so-what tests at every leaf.
• Building it alone. A perfect tree drawn in isolation gets rejected by the people who own the data. Build it with them and assign owners before the meeting ends.

Limits

A tree assumes the problem splits into fairly independent parts. When causes feed each other, for example late deliveries that create billing disputes that distract the account team, a tree can hide the loop. Pair it with a process map or a fishbone diagram. And if one report can answer the question, run the report; do not build eight analyses to feel rigorous. Treat the tree as a living document and redraw it as facts arrive.

Go further

Issue trees are Chapter 4 of The Problem-Solving Toolkit, with a printable Issue Tree Workbook that tracks each node's owner, data source, effort and status. It builds directly on the framing chapters. Read Chapter 1 for free, see how to open the work with an SCQA, or read our guide to the Frame, Find, Decide, Deliver method.