Decision-making & prioritisation
Issue Trees & MECE
A method for disaggregating a governing question into branches that are mutually exclusive and collectively exhaustive, so a team can size the branches, prioritise the few that could swing the answer, and test them with explicit hypotheses instead of boiling the ocean.
Also known as Logic trees, Hypothesis trees, MECE problem structuring. First set out by McKinsey & Company problem-solving practice; MECE coined by Barbara Minto in 1999; the primary source is cited in full below.
Where this is contested
Issue trees have no single author or founding text. They grew out of McKinsey problem-solving practice, MECE is credited to Barbara Minto's work at the firm between 1963 and 1973, and the method was only publicly codified decades later by former consultants, first by Rasiel in 1999 and most fully by Conn and McLean in 2019.
- Format
- Mapping
- Level
- Business unit · Product · Team
- Best for
- Structure the problem · Prioritise
- Decision stage
- Diagnose · Explore options
- Difficulty
- Intermediate
- Time to apply
- An hour to draft and prune a first tree; days to weeks to test the priority branches properly.
Plate · The model
The components
Define the governing question
The single question the tree exists to answer, framed tightly enough that you will know when it has been answered.
Signals of strength
Names a metric, a magnitude and a deadline · A named decision-maker would act on the answer · One question, not several welded together
Break it down MECE
The disaggregation of the question into branches with no overlaps and no gaps, using one consistent logic per layer.
Signals of strength
No item could sit in two branches at once · The branches sum back to the whole question · Each layer uses a single logic of division · More than one candidate cut was tried before settling
Prioritise the branches
The judgement about where the answer is likely to live, made by sizing branches before deep analysis and parking the rest.
Signals of strength
Branches are sized, at least roughly, before analysis starts · Low-value branches are explicitly parked with reasons · Effort follows the branches that could swing the answer
Test with hypotheses
The conversion of priority branches into falsifiable hypotheses with analyses designed to disprove them.
Signals of strength
Each priority branch carries a stated day-one hypothesis · Analyses are designed to disprove, not to decorate · The tree is redrawn when evidence kills a branch
When it earns its keep
- The problem is broad, ambiguous or multi-causal and the team needs a shared structure before anyone starts analysing.
- Work must be divided across several people without overlap or gaps, which is exactly what a MECE decomposition guarantees.
- There is pressure to jump straight to a favoured solution, and you want the discipline of laying out the whole solution space first.
- You will later have to show your working, to a board, a bank or a regulator, and the tree provides the audit trail from question to answer.
And when it doesn't
- The problem is well understood and the fix is known. Building a tree to reach an obvious answer is theatre.
- The system is genuinely complex, with strong interactions between parts. Decomposition assumes branches can be analysed separately and summed; where feedback loops dominate, use systems approaches or Cynefin to classify the situation first.
- The task is generative rather than analytical. MECE discipline applied too early narrows creative work before it has produced options.
- You can test the whole question directly with available data. A cheap experiment beats an elegant decomposition.
How to run it
Before starting, gather the inputs the analysis depends on:
- A precisely worded governing question, with a metric, a magnitude and a timeframe, that a named decision-maker would act on.
- A candidate logic for cleaving the problem: an arithmetic identity (profit equals price times volume minus cost), a process, or a segmentation.
- Access to the data and the people needed to size branches roughly before deep analysis begins.
- Agreed criteria for prioritising branches, usually the size of the prize and your ability to influence it.
- 1
Define the governing question
Turn the vague concern into one answerable question with a metric, a threshold and a deadline. 'Why are margins falling?' is a topic; 'How do we return EBITDA margin to 4% within 18 months without losing more than 5% of revenue?' is a question a tree can answer. Most weak trees fail here, before a single branch is drawn.
- 2
Break it down MECE
Choose a cleaving logic and split the question into branches that do not overlap and together cover everything. Arithmetic cleaves (revenue minus cost) are the most reliably MECE; process and conceptual cleaves need checking. Keep one logic per layer, and go only two or three layers deep before pausing. Being MECE is necessary; it is not the same as being insightful, so try more than one cut.
- 3
Prioritise the branches
Size each branch, even roughly, before analysing any of them. The tree is a prioritisation device: most of the answer usually sits in two or three branches, and the rest should be explicitly parked with a note saying why. A tree where every branch gets equal effort is a work plan for boiling the ocean.
- 4
Test with hypotheses
For each priority branch, state a falsifiable hypothesis (the 'day-one answer') and design the analysis that would disprove it. This is the hypothesis-driven discipline Rasiel describes: you are trying to kill the hypothesis quickly, and the tree tells you which evidence would do it.
- 5
Iterate and synthesise
Redraw the tree as evidence kills or confirms branches, then work back up it to assemble the answer to the governing question. Check interactions between branches before summing them; a saving in one branch that creates a cost in another is exactly what decomposition hides.
Reading the result
A one-page structure of the problem: the governing question at the trunk, a MECE set of branches with rough sizings, a marked set of priority branches, and a hypothesis with a killer analysis for each. Behind it, an evidence-based answer that can be traced back through the tree.
- Read the trunk first: if the governing question is woolly, nothing downstream can be trusted.
- Check the cleave before the content. An overlap or a gap at layer one silently corrupts every conclusion below it.
- Look at where the effort went. A good tree shows most analysis concentrated in a few sized branches and the rest deliberately parked.
- Treat the summed answer with suspicion until cross-branch interactions have been checked.
A worked example
A frozen-food wholesaler works out where its margin went
A UK frozen-food wholesaler supplying fish-and-chip shops, care-home caterers and independent restaurants has seen EBITDA margin fall from 4.1% to 2.3% in two years on flat revenue. Ahead of a bank facility review, the managing director wants a defensible account of the decline and a recovery plan, and runs the question through an issue tree with her finance director and two depot managers.
- Define the governing question
- First draft was 'Why are we less profitable?'. Reworked to 'How do we return EBITDA margin to at least 4% within 18 months without losing more than 5% of revenue?'. The revenue guard-rail matters: the bank will not accept a margin fix that shrinks the business it is lending against.
- Break it down MECE
- Cleaved arithmetically: margin change equals gross-margin change minus change in cost to serve. Gross margin splits into price realisation, product mix and buying cost; cost to serve into delivery logistics, cold storage and shrinkage. One boundary rule agreed up front: driver-granted discounts sit under price realisation, not logistics, so nothing is counted twice.
- Prioritise the branches
- Rough sizing from management accounts: buying cost broadly flat against index, mix stable, delivery cost up 0.2 points. Two branches carry the damage: price realisation down 1.2 points and cold-storage cost up 0.8 points since a fixed energy tariff expired. Logistics and shrinkage parked with a one-line rationale each.
- Test with hypotheses
- H1: unauthorised discounting by delivery drivers is eroding realised price. Tested against invoices for 200 accounts; confirmed, with discounts clustering on routes where drivers hold pricing latitude. H2: cold-storage cost is a utilisation problem as much as a tariff problem. Site data shows one of three depots at 40% utilisation; consolidation modelled. A third hypothesis, that shrinkage had worsened, was tested and killed: wastage sits at the industry norm.
The read. The tree converted 'margins are bleeding' into two named, sized problems: discount control worth roughly 1 point of margin, and cold-store consolidation worth around 0.8. Before recommending closure of the underused depot, the team checked the interaction the arithmetic cleave had hidden: closing it lengthens delivery routes and hands back about 0.2 points. The recovery case still clears 4%, and the bank got an answer with its working attached.
Pitfalls
- Confusing MECE with insightful. Sorting customers alphabetically is perfectly MECE and perfectly useless; the cut must isolate things you can act on.
- Building the tree to justify an answer already chosen. The hypothesis discipline only works if analyses are designed to disprove.
- Going equally deep everywhere. A tree that is not pruned by sizing is a plan for exhaustive, slow analysis.
- Summing branches as if they were independent when the underlying system has interactions between them.
- Treating the first tree as final. Good teams redraw the tree several times as evidence comes in.
What the critics say
Decomposition has limits that the method rarely advertises. Ackoff argued that analysis taking systems apart destroys exactly the properties that matter, because a system's performance is the product of interactions between parts, which separate branches cannot capture.
Ackoff, R. L. (1979) 'The Future of Operational Research is Past', Journal of the Operational Research Society, 30(2), pp. 93-104.
The hypothesis-driven overlay invites confirmation bias: a day-one answer anchors the team, and the well-documented tendency to seek confirming evidence means the 'killer analysis' is often designed more gently than the method assumes.
Nickerson, R. S. (1998) 'Confirmation Bias: A Ubiquitous Phenomenon in Many Guises', Review of General Psychology, 2(2), pp. 175-220.
Being MECE does not determine which decomposition to use. Chevallier notes that any problem admits many MECE structures, most of them unhelpful, and that the method offers little guidance on choosing the insightful cut, which is where the real skill lies.
Chevallier, A. (2016) Strategic Thinking in Complex Problem Solving. Oxford: Oxford University Press.
Sources and further reading
- Rasiel, E. M. (1999) The McKinsey Way. New York: McGraw-Hill.
- Conn, C. and McLean, R. (2019) Bulletproof Problem Solving: The One Skill That Changes Everything. Hoboken: Wiley. ↗
- Minto, B. (1996) The Minto Pyramid Principle: Logic in Writing, Thinking and Problem Solving. London: Minto International. ↗
- McKinsey & Company (2019) 'Barbara Minto: MECE: I invented it, so I get to say how to pronounce it', McKinsey Alumni News. ↗