The Problem-Solving Power: How Business Leaders Can Use Issue Trees to Drive Results
The issue tree is the most portable technique in management consulting and the one most often taught badly. Described superficially it sounds obvious: break a big problem into smaller ones. Applied superficially it produces an impressive diagram, several weeks of analysis, and a conclusion the team already suspected.
The difference between the two outcomes comes down to a handful of craft decisions: which kind of tree you are building, how each branch is split, and how quickly you are willing to kill branches without analysing them. This article covers those.
Two kinds of tree, and why mixing them fails
Before drawing anything, decide which question is being answered.
A diagnostic tree answers why something is happening. Its branches are causes. Why has gross margin fallen four points?
A lever tree answers what could be done. Its branches are actions. How could we recover four points of gross margin?
These decompose differently and cannot share a diagram. The most common failure in practice is starting diagnostic, getting to the third level, and drifting into actions because actions feel more productive. The result explains nothing and evaluates nothing.
Finish the diagnosis. Then build a second tree for the response, rooted in what the first one found.
Split arithmetically wherever you can
This is the single technique that most improves the quality of a tree, and it is absent from most descriptions of the method.
A branch can be split two ways. Categorically, into named groups: by region, by product line, by customer segment. Or arithmetically, so the children combine mathematically into the parent.
Profit is revenue minus cost. Revenue is volume times price. Volume is traffic times conversion rate. Cost is fixed plus variable. Customers are new plus retained. Retention is one minus churn.
Arithmetic splits are better for two reasons, and both are practical rather than aesthetic.
They are mutually exclusive and collectively exhaustive by construction. Nobody needs to argue about whether the branches overlap, because they provably combine back into the parent. Categorical splits are MECE only by assertion, and the assertion is frequently wrong.
They carry numbers. Every node has a value, which means every branch can be sized before it is analysed. That capability is what makes the next section possible.
The working rule: split arithmetically whenever the numbers allow it, and fall back to categorical splits only where they do not.
Size before you analyse
Here the standard advice is not merely incomplete but actively harmful. Leave no stone unturned produces a complete tree, six weeks of analysis and a description of the business rather than an answer.
The practitioner's sequence is different.
Build the tree. A few hours, not a few days. It will be imperfect and that is acceptable, because its purpose is to locate the analysis rather than to be the analysis.
Size every branch roughly. Back of an envelope, order of magnitude. For each branch ask a single question: could this alone account for the gap being explained?
Eliminate. Most branches cannot. A four-point margin decline is not explained by a cost line worth 0.3 points of revenue, however unsatisfactory that line is in other respects. Close those branches on the estimate and record why.
Go deep on one or two. Full analysis only on branches large enough to matter.
Most branches should be closed on an estimate rather than an analysis. Teams find this uncomfortable, because closing a branch without studying it feels like cutting corners. It is the opposite: it is what makes the remaining work worth doing.
A worked example
Gross margin has fallen from 62% to 58% over four quarters. The board wants to know why.
Margin is price minus unit cost, over price, so the first split is arithmetic and unarguable: realised price and unit cost.
Realised price splits into list price, discounting and mix, because realised price is list price less discount, averaged across a mix of products. Unit cost splits into input cost, volume efficiency and, again, mix.
Now size, before analysing anything. List price has not changed: zero. Input costs are up roughly three per cent on a cost base that is 38% of revenue, so around one point of margin. Volume is flat, so efficiency contributes little. That leaves discounting and mix to account for roughly three points.
Ten minutes of arithmetic has eliminated three of five branches and located the problem in two. The analysis that follows is narrow and answerable: what happened to average discount, and what happened to product mix, quarter by quarter.
Had the team analysed all five branches properly, the answer would have been the same and it would have arrived a month later.
How deep to go
Three or four levels is normal. The stopping rule is not depth but actionability.
Stop when a branch names something a specific person could investigate or change this month. Discounting has increased in the enterprise segment is not yet actionable. Deals above 100,000 are being approved at an average discount of 34% against a policy of 20% is: it has an owner, a number, and an obvious next question.
If a leaf still reads as a category, add a level. If it is specific enough to assign, further decomposition is procrastination.
MECE, and its limits
Mutually exclusive, collectively exhaustive is the right discipline and it is applied too religiously.
Arithmetic splits achieve it cleanly. Categorical splits often cannot: causes in a real business interact, and a tree that insists on perfect exclusivity between causal branches will invent artificial categories to satisfy the rule.
The workable standard is to be strict about exhaustiveness and pragmatic about exclusivity. A missing branch hides the answer, which is fatal. Overlapping branches cost duplicated effort, which is merely wasteful. Where two branches genuinely interact, note the interaction rather than pretending it away.
The failure modes
Symptoms instead of causes. Customers are unhappy is an observation. Onboarding takes eleven days against a promised three is a cause. Trees made of symptoms restate the problem in more boxes.
Actions in a diagnostic tree. Covered above, and worth checking for explicitly, because the drift is gradual.
Trees built backwards from a conclusion. Recognisable by shape: one branch developed to four levels and the rest to one. The author knew the answer and built scaffolding around it. Worth watching for in your own work more than in other people's.
Depth as substitute for progress. Adding levels feels like work and delays the moment of having to say something.
No numbers. A tree with no quantification cannot be pruned, so every branch stays open and the analysis expands to fill the available time.
Where it comes from
The technique developed in management consulting through the 1960s and 1970s and is most closely associated with McKinsey, where Barbara Minto formalised the underlying logic in the Pyramid Principle. The same structure appears elsewhere under other names: fault trees in reliability engineering, driver trees in financial planning, root cause analysis in operations.
The shared idea is old and sound. A problem too large to hold in one piece becomes tractable when broken into parts that can be assessed independently, provided the parts genuinely reassemble into the whole.
When not to use it
Genuinely novel problems. Decomposition requires some prior view of the problem's structure. Where none exists, the tree imposes a shape the analyst brought with them, and the neatness is misleading.
Political and interpersonal problems. The tree will produce accurate branches that nobody acts on, because the obstacle is not analytical. Structure applied to a will problem produces a well-documented stalemate.
Decisions needed within hours. The method costs time. Sometimes the improvement in decision quality is not worth the delay, and knowing that is part of using it well.
Introducing it to a team
Teach it on a live problem rather than in the abstract, and build the first tree together in one room. The argument that happens while placing branches is where most of the learning sits, and it disappears if one person drafts the tree and circulates it.
Insist on two habits from the start: split arithmetically wherever the numbers allow, and size every branch before analysing any of them. A team that adopts the diagram without those two habits will produce elaborate trees and reach the conclusions it would have reached anyway, more slowly.
The point
An issue tree is a device for locating analysis, not a substitute for it. Decide whether you are diagnosing or choosing. Split arithmetically wherever the numbers allow, because that makes the tree both provably complete and quantifiable. Size every branch before analysing any of them, and close most of them on an estimate. Stop at actionability rather than at some target depth.
Done that way it takes an afternoon and points at the right question. Done the other way it takes six weeks and produces a very thorough map of a business everyone already worked at.
At go:lofty we use structured problem solving as part of diagnostic work, on the principle that most of the value comes from finding the right question rather than from exhausting the wrong one.
