# Issue trees and MECE: breaking a messy problem into parts you can solve Source: https://sarang.pro/issue-trees-and-mece/ Author: Sarang | Published: 25 October 2026 Most business problems arrive as one worried sentence. Sales are down. Churn is up. The new product isn't working. You can't analyse a sentence like that directly. You have to break it into smaller questions, each of which you can answer with data or a conversation. An issue tree is the tool consultants use to do this. Paired with a sorting rule called MECE, it turns a vague problem into a list of specific questions and shows you where to look first. This guide explains both, walks through building a tree, and lists the mistakes that make one useless. ## What an issue tree is An issue tree, also called a logic tree, is a diagram that breaks a question into its parts. The main question sits on the left. Each branch to the right splits it into smaller sub-questions, and those split again, until every end point is something you can check. The same structure goes by many names, including why trees, how trees, hypothesis trees and issue maps. The label matters less than the job. Arnaud Chevallier, whose rules for building trees are summarised on [Wikipedia's issue tree page](https://en.wikipedia.org/wiki/Issue_tree), puts it simply: "Call your tree what you want it to do." Charles Conn, a former McKinsey partner and co-author of *Bulletproof Problem Solving*, describes taking a problem apart into logical pieces as the only way to get a team working on it. He adds that the way you split a problem "often gives you an insight into the answer to the problem quite quickly." ## MECE: the rule that keeps a tree honest MECE stands for mutually exclusive, collectively exhaustive. Barbara Minto developed the idea at McKinsey in the late 1960s, and it underpins her Pyramid Principle for structuring business writing. - Mutually exclusive: the branches don't overlap, so each possible cause belongs to one branch only. - Collectively exhaustive: the branches together cover every possibility, so nothing falls through a gap. Grouping people by birth year is MECE, because everyone has exactly one. Grouping people by nationality isn't. Some people hold two nationalities, which is an overlap, and some hold none, which is a gap. Overlaps cause double counting and leave two people analysing the same thing. Gaps are worse. The real cause can sit in the branch nobody drew. ## Diagnostic trees and solution trees Chevallier separates trees into two kinds, and mixing them up causes a lot of muddle. A diagnostic tree starts with a "why" question, such as "Why are online sales down?" Its branches list possible root causes. You use it when you don't yet know what is wrong. A solution tree starts with a "how" question, such as "How could we grow online sales next year?" Its branches list options. You use it once you understand the problem and need to choose what to do about it. Keep each tree to one kind of question all the way down. If a branch saying "fewer visitors" (a cause) sits next to one saying "run a sale" (an action), the tree has lost track of what it is asking. ## How to build an issue tree in six steps - Write the question as one sentence. Make it specific about what, where and compared with when. "Why did online revenue fall in the third quarter compared with the second?" is far easier to work with than "Why are sales bad?" - Choose the first split carefully. The first level does most of the work, so look for a split that is MECE by construction. Formulas are ideal: revenue is price times volume, and profit is revenue minus cost. Conn's own example is a profit tree that splits revenue into price and quantity and costs into fixed and variable. - Split each branch again. Keep going until each end point is a question you can answer with a specific piece of data or a short interview. - Test every level against MECE. For each set of branches, ask whether one cause could sit in two places, and whether any cause fits nowhere. A small "other" branch is acceptable at lower levels, as long as someone looks inside it. - Try a second cut. Conn recommends trying two or three different ways of splitting a problem before you settle. Splitting sales by channel may hide what splitting by customer type would reveal. - Prioritise the branches. Conn suggests asking how much each lever matters to the outcome, then favouring levers that are both large and within your control. Mark the two or three branches to investigate first. ## An example (illustration only): why are online sales down? Take a small online homeware shop, invented for this example. Revenue fell last quarter compared with the quarter before. Here is a first draft of a diagnostic tree. Top question: why did online revenue fall last quarter compared with the previous quarter? Online revenue equals visitors multiplied by conversion rate multiplied by average order value. That gives a first level that is MECE by construction, because revenue can't change unless at least one of the three changes. - Fewer visitors? Which source fell: organic search, paid ads, email, social or direct? - Within that source, did fewer new people arrive, or did past customers return less often? - Lower conversion rate? Did the site slow down or break on some devices or browsers? - Were best-selling products out of stock? - Did prices or delivery charges change? - Lower average order value? Did the mix of products shift towards cheaper items? - Did discounts get deeper? - Did fewer customers buy more than one item? The lower levels are a starting list of likely causes. They are less tidy than the first level, which is normal. Before using the tree, check the fall is real. A change in analytics tracking, or in how refunds are recorded, can create a drop that never happened in the business. That check sits outside the tree because it questions the data. The first pass of data usually closes most branches quickly. If visitors and order value are flat and conversion fell, two of the three branches are closed in an afternoon, and the team can spend its time on site speed, stock and pricing. ## Common mistakes - Starting with a vague question. "How do we fix marketing?" produces a vague tree. - Mixing why and how. Build the diagnostic tree first, confirm the cause, then build a solution tree for it. - Overlapping branches. Putting "marketing" and "social media" side by side double counts, because social media is part of marketing. - Leaving gaps. If you split customers into new and returning, decide where a lapsed customer who comes back after two years belongs. - Splitting in ways that teach nothing. Chevallier's rules ask for a breakdown that gives real insight. Splitting products alphabetically is MECE and tells you nothing. - Going too deep. A tree with sixty end points becomes a to-do list nobody finishes. Stop when an end point is answerable, and prune branches the first data rules out. - Treating MECE as sacred. Critics note that forcing strict mutual exclusivity can be "unnecessarily limiting", and that some redundancy is occasionally useful. Use MECE as a check on your thinking rather than a rule that outranks common sense. ## Using issue trees outside consulting Founders can sketch a diagnostic tree in a weekly review whenever a key number moves. Analysts can put one at the top of a report so readers see which questions were checked and which weren't. Consulting interviewers often expect candidates to structure case answers this way, especially market-sizing questions where you estimate a quantity such as a company's revenue. A tree also makes delegation easier. Each branch can go to one person, and because the branches don't overlap, two people won't spend the week answering the same question.