What’s the secret to nailing every case interview? Is it learning the so-called frameworks? Nuh-uh.
Actually, that secret lies in an under-appreciated, yet extremely powerful problem-solving tool behind every real consulting project. It’s called the “issue tree”, also known as “logic tree” or “hypothesis tree” – and this article will teach you how to master it.
Before you read
With this article being a “deep-dive” into a fundamental concept in case interview, it is strongly advised that you attain a basic understanding of the subject, which can be acquired through our beginner’s guide article right here:
Additionally, two concepts essential to the issue tree – the MECE principle and consulting frameworks – are only briefly covered in this article; if you want to truly master the issue tree, once you’ve finished this guide, follow-up with two dedicated articles on the related concepts:
Issue tree in consulting problem-solving – The fundamentals
What is an issue tree?
An issue tree is a pyramidal breakdown of one problem into multiple levels of subsets, called “branches”. Issue tree can be presented vertically (top-to-bottom), or horizontally (left-to-right). The use of an issue tree systematically isolates the root causes and ensures impactful solutions to the given problem.
How do you use an issue tree?
The issue tree is most well-known in the field of management consulting, where consultants use it within the “hypothesis-driven problem-solving approach”, which consists of repeatedly hypothesizing the location of the root causes within each branch and testing that hypothesis with data. Once all branches are covered and root causes found, impactful solutions can be delivered.
With those basics in mind, it is clear that the issue tree is only part of the process used in case interviews or consulting projects. As such, the issue tree must be learned within the larger context of consulting problem-solving.
That problem-solving process is strict and highly-structured with seven concepts: Problem, Root Cause, Issue Tree, MECE, Hypothesis, Data, and Solution. This is also the backbone of problem-solving in my Case Interview End-to-End Secrets Program – a package of comprehensive case interview training materials.
Problem
Every problem-solving process must start with a well-defined problem. A problem becomes “well-defined” when it’s attached with an objective. We’ll be working with business problems later; for now, I’ll be using a simple everyday problem to illustrate the principles:
Root cause
To ensure any solution to the problem is long-lasting, consultants always look for the root cause.
Problems are often the last, visible part in a long chain of causes and consequences. Consultants must identify the very start of that chain – the root cause – and promptly deal with it to ensure that the problem is gone for good.
The diagram above, however, is too simplistic. Real problems often can have multiple root causes – that’s where our hero – the Issue Tree – comes to the rescue.
Back when I was having that cockroach problem, I bought some bug spray and dealt with any of those little creatures straying into my apartment. As you may have imagined, it wasn’t very effective, so I set out to find the source of the problem.
Issue tree
An issue tree ensures that all root causes are identified in a structured manner.
This “tree” breaks the problem down to contributing factors, called “branches”; each branch is in turn broken down into contributing sub-factors or sub-branches. This process is repeated through many levels until the root causes are isolated and identified.
For a branch to be included in the issue tree, there must be a possibility that it leads to the problem (otherwise, your problem-solving efforts will be wasted on the irrelevant).
When dealing with the cockroaches, I deducted that the source must be
from either “inside” or “outside” the apartment. Each of these branches is in turn segmented based on the layout of the apartment and the premise.
To ensure that all possibilities are covered in the issue tree in a neatly organized fashion, consultants use a principle called “MECE”.
MECE
For an issue tree to work properly, it must be MECE– which stands for “Mutually Exclusive, Collectively Exhaustive”:
- Mutual exclusivity: there’s no overlap between the branches.
- Collective exhaustivity: all branches together cover every possibility, i.e there’s no gap.
This is a standard that all management consultants swear by, and together with the issue tree, it is almost a signature of the industry.
In my example, I ensured MECE-ness by using the inherently non-overlapping segments of the apartment building, as well as adding an “Other Places” sub-branch
for the less-relevant locations, such as inside other apartments.
Hypothesis
After we’ve developed a few branches for our issue tree, it’s time to begin testing, by making an educated guess on which branch is the most likely to contain a root cause. This process is called “hypothesizing”; put another way, it is a proposal that one factor leads to the problem.
Hypotheses must adhere to the three following criteria:
- It must follow the issue tree – you cannot hypothesize on anything outside the tree (I cannot hypothesize that the cockroaches come from “inside the walls” because there is no such branch in my issue tree).
- It must be top-down – you must always start with the first level of the issue tree (for example, my first hypothesis must be “The cockroaches come from inside the apartment”).
- It must be based on existing information – if your information suggests that the root cause is in branch A, you cannot hypothesize that the root cause comes from branch B (as I often saw the cockroaches near the door, coming into the apartment, I hypothesize “The cockroaches come from outside”).
Once a hypothesis is confirmed as true (i.e the root cause is inside that branch), move down the branch with a lower-level hypothesis; otherwise, eliminate that branch and move sideways to another one on the same level.
Repeat this process until the whole issue tree is covered and all root causes are identified.
Data
A hypothesis must always be tested with data.
Data usually yield more insights with benchmarks – reference points for comparison. The two most common kinds of benchmarks in consulting are historical (past figures from the same entity) and competitor (figures from similar entities, in the same timeframe).
Using “competitor benchmark” to test if the cockroaches come from outside,
I asked my neighbors if they also had the same problem.
Most of them said “yes”, confirming my first hypothesis.
Solution
After the analyzing process, it’s time to deliver actionable solutions.
The solutions must attack all the root causes to ensure long-lasting impact – if even one root cause remains untouched, the problem will persist.
Remember to deliver your solution is a structured fashion, by organizing them in neat and meaningful categories; most of the time, solutions are segmented into long-term and short-term.
How did I solve my cockroach problem? After identifying a nasty site of infestation at one corner of the courtyard, our “short-term” solution was to use pesticides, while the “long-term” one was to clean up the pile of garbage that was sitting there for a whole year, as well as tidying my apartment.
Ladies and gentlemen, that’s how a former consultant got rid of cockroaches.
/filters:quality(75)//case_thumb/1669783363736_case_interview_end_to_end_secrets_program.png)
“Which-Tree” and “How-Tree” – The advanced variants
In the previous section, we’ve discussed the most basic variant of the issue tree – the “Why-Tree”. It’s used in problem-solution cases, where the central logic is to find the root cause, i.e answering the “why” question.
However, in consulting projects and case interviews, there are two other common types of cases – the “Should I Do A or B” and the “How to do C”. We’ll be exploring the logic of each type and how their issue trees differ from the problem-solution issue tree we’ve discussed.
Both of these “advanced” cases are discussed extensively in my Case Interview End-to-End Secrets Program – in case videos as well as the Business Intuition exercises.
“Which-Tree” – Should I do A or B?
The most logical approach to these cases is to evaluate each option on one same set of criteria.
The resulting issue tree, therefore, is effectively a decision-making table combining two separate issue trees – one for the options, and the other for evaluating criteria. For any option or criterion to be included in the issue tree, it must be relevant to the decision-maker.
Additionally, the issue tree (or trees) in “Should I Do A or B” cases only contains one level. This allows you to focus on the most suitable options (by filtering out the less relevant), ensuring a top-down, efficient decision-making process.
Let’s say I’m going to buy a new laptop, so I draw issue trees to help with the decision. Notice how, in the “criteria tree” on the left, I do not include “battery capacity” as a branch – I always bring the charger with me, so that criterion is not relevant.
“How-Tree” – How to do C?
“How to Do C” cases require you to brainstorm (in a top-down manner) on the possible courses of action to reach an objective.
As such, the issue tree for these cases is action-oriented, with branches representing ideas, steps, or aspects of the work.
Again, as with the two previous types of issue trees, for an idea/step/work aspect to be included as a branch, it must be relevant to the task.
A restaurant business wishing to increase its profitability may look into the following ideas:
MECE – The principle consultants swear by
One of the foremost concerns when constructing an issue tree is whether it is MECE or not. To answer that question, you need to know all the basic and “advanced” rules of the MECE principle, and we’ll be discussing those rules in this section.
For a more comprehensive guide on the rules of MECE – including its potential drawbacks – check out this comprehensive guide on the MECE principle right here.
Basic Rule #1: Mutually Exclusive
Every branch and sub-branch in an issue tree must be cleanly separated from others on their level – in other words, there must be “no overlap” between any branches within the tree.
Adherence to this rule ensures that there will be no duplicated efforts, leading to maximum efficiency in problem-solving. It also allows the consultant to isolate the root cause more easily (otherwise, one root cause may manifest in multiple branches, making it harder to pinpoint).
For example, a car manufacturer trying to find out the cause of its decreasing unit sales may use the cleanly-separated product segments: high-end, mid-range, and entry-level. A non-ME segmentation, in this case, is “high-end” and “cars”.
Basic Rule #2: Collectively Exhaustive
The branches and sub-branches in an issue tree must cover all possible factors – in other words, there must be no gap in the tree.
This second rule ensures that all root causes can be identified so that the problem will be solved with maximum effectiveness. On a side note, if one factor is not related to the problem, it is not included.
If the aforementioned car manufacturer omits any of the three product segments in its analysis, it may also ignore one or a few root causes, leading to ineffective problem-solving. On the other hand, even if it produces race cars to compete in motorsports, these race cars should not be included in the issue tree because they do not contribute to unit sales.
Advanced Rule #1: Parallel Items
In a MECE segmentation, every item must be parallel, i.e on the same logical level.
“High-end”, “mid-range”, and “entry-level” are three parallel and MECE branches. However, if we replace the first two with “High-and-mid-range”, the whole issue tree becomes non-parallel and non-MECE, because the new branch is one level higher than the remaining “entry-level” branch.
Advanced Rule #2: Orderly List
A MECE segmentation should arrange the items in a logical order.
The three branches in our example issue tree can be arranged in two opposing orders: “low-mid-high” or “high-mid-low”. It should never be “mid-low-high” because this arrangement is illogical and counter-intuitive.
Advanced Rule #3: The Magic “Rule of Three”
The ideal number of branches on any level of the issue tree is three – the most intuitive number to the human mind.
Three items are often enough to yield significant insights, while still being easy to analyze and follow; segmentations into 2 or 4 items are also common. 5 is acceptable in some cases, but anything more than that should be avoided; and of course, we can’t have only 1 item, because it’s pointless.
The manufacturer in the example may have 12 product lines distributed across the segments; however, having 12 branches in the issue tree is counter-intuitive and counter-productive, so we use the much more manageable 3 segments.
Advanced Rule #4: No Interlinking Items
There should be minimal to no connections between the branches of the issue tree.
If the branches are interlinked, one root-cause may manifest itself in multiple symptoms across the tree, creating unnecessary confusion in the problem-solving process.
Consulting frameworks – Templates for issue trees
What are consulting frameworks?
In management consulting and case interview context, frameworks are convenient templates you can use to break down business problems, i.e draw issue trees.
Convenient as they are, however, consulting frameworks should only be treated as general guidelines to be used flexibly, and never as hard-and-fast rules. In actual consulting projects as well as case interviews, frameworks usually require a lot of customizations to become useful.
For this article, I’ll go through only the basics. You should check out this article on Case Interview Frameworks, where I analyzed much deeper about the use as well as the advantages and disadvantages of each common framework.
Five common consulting frameworks in case interviews
These are the five most common frameworks in business cases:
- Profitability Framework: This is the first framework to master for every prospective consultant. In case interviews, it’s used to mathematically break down a profit problem based on revenue and cost.
- Business Situation Framework: Or the “3C & P” framework. This one is the most versatile, usable in nearly every case (as long as you know how to customize it). Learn it well and you won’t be disappointed. This framework analyzes the business situation based on 4 aspects – Company, Customer, Competitor, and Product.
- McKinsey M&A Framework: I call it as such because it’s mostly used by McKinsey consultants in M&A projects. In my opinion, this is by far the best M&A framework. This framework assesses the feasibility of an M&A based on three dimensions: the stand-alone values of each company (core values, strengths, weaknesses, etc.), their synergy (whether the two combined will be better than the sum of its parts), and other factors – such as legal or cultural issues.
- 4P/7P Marketing Mix: This is the most popular framework to structure a marketing strategy. The traditional 4P variant breaks down that strategy using four elements – Product, Price, Place, Promotion; this variant is mostly used for tangible goods. The service-oriented 7P adds three other Ps – People, Process, and Physical Evidence. The use of this framework, however, is restricted to marketing cases only.
- Porter’s Five Forces Model: This model is the most common industry framework. Porter’s model analyzes the industry surrounding the business based on five “forces” – Competitor, Suppliers, Customers, New Entrants, and Substitute Products – as well as how each force interacts with the business.
Five mini-frameworks – The universal problem-solving templates
Less well-known, but much more versatile than the aforementioned frameworks, are what I call “mini-frameworks”. These are often used as adjuncts to their larger, more business-oriented cousins, or as building blocks in fully customized frameworks/issue trees.
- External vs Internal: This is a quick and easy way to segment information about an entity. The “Internal” branch concerns what’s inside or intrinsic of that entity, while the “External” branch deals with what’s outside or extrinsic.
- Qualitative vs Quantitative: This mini-framework is mostly used in evaluations or reasoning to ensure that all criteria/factors are accounted for in a MECE fashion.
- Costs vs Benefits: This is a basic and universal decision-making framework. If the benefits outweigh the costs, go along with that decision; if the costs are greater, spend your money elsewhere.
- 2×2 Matrix: The 2×2 Matrix is a decision-making tool where options are examined using two criteria, each of which forms an axis of the matrix. A popular variant in case interviews is the Growth-Share matrix from BCG.
- SWOT: This mini-framework examines a company’s positioning within the industry context. However, it’s rarely used in real case interviews, due to its generic nature.
Exercise
We’ve had daily-life examples as well as framework-fit business cases. Now it’s time to practice with something… less conventional.
The Megapolis City Council is looking to solve a major problem in the city’s traffic: for the last decade, the number of traffic accidents has been rising steadily – the Council wants to at least halt this rise. Which factors would you look at in tackling this problem?
The issue tree for this case cannot be drawn using ready-made frameworks. Nonetheless, it’s possible to construct a suitable issue tree based on the logic of External-vs-Internal and Qualitative-vs-Quantitative mini-frameworks.
Remember the rules: be MECE, top-down, and structured.