Logic Tree: How to Break Down Complex Problems and Find the True Root Cause

What is a Logic Tree is an analytical tool used to decompose a complex problem into its individual components. Each component (branch) within a well constructed Logic Tree should add up to the root problem. This means there are no extra elements and no missing elements. All the individual components on the same level of the Logic Tree are Mutually Exclusive. This means that there is no overlap between the branches. Each branch has clearly defined boundaries and no factors can be found within more than one branch.

This can be thought of as a jigsaw puzzle. Each piece fits into a specific place on the puzzle. There are no overlaps between the pieces. All the pieces are Mutually Exclusive. However, when all the pieces are fitted together they make the complete puzzle.

Whilst the Logic Tree technique was popularised by consultancy firm McKinsey & Company (often referred to as the MECE principle – Mutually Exclusive, Collectively Exhaustive), it can be applied to many areas. Within practice you will notice the following 4 types of Logic Tree; Hypothesis Tree, Issue Tree, How-To Tree and Decision Tree. Whilst the names and structure may vary slightly depending on your textbook, the definition remains the same. Within every industry you will be using a Logic Tree to either decompose a problem (Diagnostic Tree) or solve a problem (Solution Tree).

---

Diagnostic Trees vs. Solution Trees: Mapping the Four Forms to Real Work

To avoid getting lost in consulting jargon, you can group the four classic variations of a logic tree directly into the two functional roles they perform when you sit down to work:

Breakdown Dimension	Diagnostic Tree (Decomposing the Problem)	Solution Tree (Solving the Problem)
Core Objective	Break Down the Problem: Dig vertically into why a symptom is happening.	Solve the Problem: Map out how to fix a confirmed issue step by step.
Included Tree Forms	Issue Tree, Hypothesis Tree (Why Tree)	How-To Tree, Decision Tree
When to Use It	You face a complex challenge, and the true root cause is still unclear.	The root cause is already clearly defined, and you need concrete execution steps.
Required Sequence	Step 1 (Must Come First): Isolate the real problem before taking action.	Step 2 (Must Come Second): Build targeted actions around the verified root cause.
Cost of Misuse	Stopping here leaves you with an analysis on paper but no operational fix.	Fatal Misalignment: You end up solving a different problem than the one actually occurring.

---

How a Logic Tree Progresses Layer by Layer: Turning Answers into New Questions

No matter what version you create, a logic tree will always go into more layers below. It is normally standard to consider that for any given problem/question in the current layer of the logic tree, the very next layer will provide the answer to that problem. Then, the third layer will take that answer and present it as a new problem.

This recursive layer progression governs both core tree types:

1. Cause & Hypothesis Trees (“Why” Trees) — Phenomenon → Cause → New Phenomenon: In a Why Tree, your first layer starts with an observable phenomenon (unwanted symptom or failure). Your second layer will give you the answer to this phenomenon, stating what caused it. To get to your third layer, you take this answer and use it as a new phenomenon (“Why did this cause happen?”). You continue asking this question and using your new discovered cause as your phenomenon until you find an actionable root cause.
2. Problem Solving Trees (“How” Trees) — Problem → Answer → New Sub-problem: In a How-To Tree, your current layer states what your problem or objective is. Your next layer will give you the answer to this problem (your strategy). Then you take this answer and use it as a new sub-problem (“How specifically do we execute this answer?”). You then break down what you need to do to achieve this answer into concrete execution steps.

By using a logic tree you force yourself to take every answer provided at Layer $N$ and use it as your question for Layer $N+1$.

Why Sequence Matters: Always Run a Diagnostic Tree Before a Solution Tree

Both diagnostic and solution trees apply to complicated and complex challenges (see what is a complex problem here)—whether breaking down fixed components in complicated systems or mapping hypotheses to probe in complex ones (though they cannot solve value-conflicted wicked problems). Whether you need to use either of these two logic trees ultimately depends on whether there is an obvious solution. If it is obvious, then no need to use a tree. However, if there are complex variables at play, you will need to use a tree.

If you do have a complex challenge to solve:

You will utilise a diagnosis tree as you will not be clear what the issue is.

You will utilise a solution tree once you have a clear definition of the issue.

You can utilise both trees within the same project, it is often beneficial to do so. When the root cause is unclear, start with a diagnostic tree before developing a solution tree. Once the underlying cause has been verified, use a solution tree to translate your findings into actionable steps.

The Dangers of Skipping Diagnosis: Why Did the Plant Die?

If you skip the diagnosis tree and start with the solution tree you will often end up with the problem that you are solving being different to the actual problem.

For example, let’s say we had the problem: “Why did my plant wither and die?” as our root problem.

We may start our diagnosis tree and solution tree with the same root problem. However, if we skip the diagnosis phase and head straight to brainstorming solutions we may end up with the problem being ‘Lack of water’ as our problem. We may then implement automated drip lines or water the soil twice a day. However, in reality the issue may be ‘Not fertilising in time’. As we didn’t isolate the root cause, we have a brilliantly structured solution tree that solves the wrong problem.

However, if we follow the correct order and utilise both trees:

Diagnosis Tree (Phenomenon to Cause): You start off with the phenomenon ‘The plant died’. You identify the mutually exclusive causes (Water, Fertiliser, Temperature, Pests). You test this in reality and realise the root cause is “I did not fertilize the plant on schedule.”

Solution Tree (Problem to Answer to New Problem): Having identified the root cause ‘Not fertilising in time’ we now have a clear problem. The next level down will give us the answer “Establish a strict daily fertilizing trigger.” Taking this as our New Problem we identify how we can guarantee we trigger this at the same time every day. Our solution will be to set up an alarm every day at a specific time to add a set amount of fertiliser.

How I Use Logic Trees in Practice: Deep Experience vs. Unfamiliar Domains

Every example logic tree in any consulting guide will be perfectly balanced, symmetric and detailed with every possible branch explored to 4/5 levels.

However, in my workflow, my trees depend on whether I’m using it in a domain I have lots of experience in or if I’m in an area I have no familiarity with.

1. When I Have Domain Experience: The Asymmetric, Single-Long-Branch Tree

When I’m using my own logic tree in my own field (one I have years of experience with), I won’t explore every possibility.

As such my tree will never be fully balanced. Instead it will have one long branch which has been explored to 5/6 levels. Whereas all the other branches will only be explored to 2/3 levels.

The tree will appear unbalanced because the long branch shows the most relevance. The reason being that the observable symptoms, constraints and failure patterns I’m looking at fit together well on this particular branch, meaning it is the most impactful cause. Whereas the short branches will have very little relevance.

How do I know if a branch has a high or low relevance without exploring every node? Due to my previous experience, I will know that some mechanisms or failure points have been created, debugged or broken by me. Therefore I know that these branches are dead ends and can’t be relevant due to the current scenario. I know for a fact they can’t happen, therefore there is no point in spending brain power expanding them.

2. When I Have Zero Experience: Borrowing Knowledge and Pruning via Practice

When I’m faced with a challenging problem in an area I have no experience in.

When I don’t have any intuition for the system in question, all the branches will seem equally like the real cause. I will follow the process below.

I’ll look up any related issues to discover all the knowledge in the domain. This means I can utilise other people’s hard learned experience to expand my tree. However, unless someone else online has fallen into the same trap(s) as me, with the exact same environmental conditions, I won’t always find the root cause.

This knowledge will then be combined with my own practice to give me real experience. This will involve some experimentation to eliminate non root causes. This is essential when I’m faced with a Complex Problem (see What Is a Complex Problem?). This is when the problem seems to be like a knotted ball of yarn, spanning multiple branches. This means I need to experiment and eliminate non root causes. When multiple variables from different branches are pulling on each other, I can’t just look it up. I need to create some small experiments to see which issues are impacting my issue, and how much.

Case Study: Diagnosing the Dying Plant as a Beginner

Let’s go back to the Dying Plant example. There could be multiple branches to this problem. Water levels, fertilising, temperature, pests and pH.

Expanding With Others’ Experience: If I have no knowledge of botany at all, the quickest way for me to expand my tree would be to look up “common reasons houseplants die”. This means I can utilise other peoples previous experience to quickly expand my tree. This saves me months of guessing!

Eliminating Non Root Causes With Sampling: If I have absolutely no external experience and nothing comes up in my search, then I will need to create my own experience through practice. Let’s say my first plant dies. I’ll come up with the hypothesis that it died because I didn’t fertilise it on time. Next time I raise a plant, I’ll definitely fertilise it on time. However, one morning my second plant dies. Now I have two examples of this happening in real life. I can compare what I did with my first plant to what I did with my second plant. This means I can eliminate fertilizer as the only cause.

Using others’ experience (search and domain knowledge) will expand your logic tree. This will save you a lot of guess work. Using your own practice (experimentation and sampling) will help you expand your tree deeply. This will help you eliminate red herrings until you’re left with the true root cause.

Frequently Asked Questions (FAQ)

How does one layer of a logic tree connect to the next layer down?

In a standard logic tree, when the current layer states a problem or question, the layer immediately below it provides the direct answer to that problem; the following layer then takes that second layer’s answer and treats it as a new problem to be answered. This mechanism primarily drives How-To Trees (Solution Trees) and Why Trees (Hypothesis/Cause Trees)—where an upper layer represents an observable phenomenon, the next layer identifies its cause, and the layer below that treats that cause as a brand-new phenomenon to keep digging for deeper causes.

Do I need to map out every single branch of a logic tree completely?

No. If you have strong domain knowledge and hands-on experience in the field, listing every theoretical branch wastes energy. In practice, an experienced practitioner’s logic tree usually features one single longest branch—representing the path of highest relevance to the current symptoms—while other low-relevance branches are pruned after just two or three layers because past experience immediately rules them out.

Should I use a diagnostic tree or a solution tree first?

Always start with a diagnostic tree when the underlying cause of a complex problem is unclear, and only move to a solution tree after the root cause is verified. Jumping straight to a solution tree without prior diagnosis risks solving a symptom (like watering a plant that is actually dying from a lack of fertilizer) rather than the true problem—a trap that disciplined problem formulation is designed to prevent.