Build a clean way to investigate a messy business problem: objective first, useful buckets, MECE enough, and a clear first move.
Read time
9 min
Chapter
01
Level
Core toolkit
What you'll take away
Use the client objective to decide what structure the case needs.
Build a practical issue tree with specific, useful buckets.
Make your structure MECE enough and choose a first path.
In Your first 3 days pack, you saw the shape of a case. Structuring is the first real muscle underneath it, and it is the one interviewers watch most closely because it is the closest thing to watching you think.
One bit of good news before we start: structuring is not a talent you either have or you do not. It is a habit. Right now it might feel like staring at a wall. By the end of this chapter, you will have a repeatable way to find the first foothold, every time.
A quick note before we dive in
In a real case you actually clarify the question before you structure it. That is the next chapter. But structuring is the heart of the whole interview, so we are starting here.
The intuition
When you hear the case question, your first job is not to know the answer.
Your first job is to build a clean way to find it.
That is all a structure really is: a map for investigating a messy problem. Imagine a meal-kit company is considering entering the corporate lunch market. You do not yet know whether employees want it, whether companies will pay for it, whether delivery operations can handle it, or whether the economics work. You are handed a situation with missing information and asked, in effect, where would you even start? Your structure is your answer.
The question underneath every structure
If I had to solve this for a real client tomorrow, what would I need to understand first?
And here is why it helps you, not just the interviewer: a good structure gives you somewhere to stand. Instead of drowning in the whole problem at once, you break it into a few pieces you can actually pick up and examine. The fear shrinks because the problem finally has edges.
Why it matters
The interviewer is not just collecting your buckets. They are reading the shape of your thinking.
Can you tell what matters from what does not? Can you bring order to ambiguity? Can you build a plan that answers this client's question, not a generic one? That is why a memorized framework feels hollow the moment it leaves your mouth. It might sound polished, but it does not prove you understood the problem in front of you. A structure you build live, on your feet, does.
Your structure also becomes the roadmap you roughly follow through the case. It anchors your first analysis, shapes your early hypothesis, helps you decide what data to ask for, and gives you a clean way to explain why you are moving from one branch to the next.
The five traits that land
Tied to the objective.
Easy to follow.
Broad enough to cover the real drivers.
Specific enough to be useful.
Clear about where you would start.
The core moves
1. Start with the objective: a structure without one is just a list.
Before you build anything, make sure you know what the client is actually trying to decide. Grow profit? Enter a market? Cut costs? Win back customers? Understand why something changed?
The objective decides the structure. "Should we enter this market?" needs a map of whether the market is attractive, whether the client can win, what entry would cost, and what the risks are. "Why did profits fall?" needs a map that splits revenue from costs. Same candidate, same skill, different question, different map. Get this wrong and everything downstream is aimed at the wrong target.
2. Break the problem into a few buckets.
Most structures have three to five big areas worth investigating. For our coffee chain, the first layer is simple, and it helps to picture it as a tree, with the question at the top branching into the areas that could answer it.
Issue treeCoffee-chain profitability issue tree
Case questionWhy did profit fall 15%?
Revenue
Are we making less money from customers?
price / AOV
traffic / volume
product mix
store / region / channel
competitor / seasonality
Costs
Are we spending more to operate?
Fixed cost
rent / leases
salaried managers
insurance
Variable cost
ingredients
hourly labor
packaging / delivery
This is the real UI version of the scratch-paper issue tree: one question, a few clean branches, then the specific checks inside each branch.
Notice that store, region, channel, competitors, and seasonality are not a separate top-level branch here. They are ways to segment revenue or costs once you know which side deserves attention. Under costs, fixed cost and variable cost are the cleaner second-layer branches; specific line items sit inside those.
Same skill, different question, different first layer. You are not memorizing these structures; you are noticing how the map changes with the case type.
Issue treeMarket-entry sample structure
Case questionShould we enter corporate lunch?
Market demand
Is there enough real need?
office size
order frequency
willingness to pay
budget owner
Right to win
Can we serve this better than alternatives?
differentiation
sales access
brand fit
competitor response
Economics
Will the model make money?
price
food cost
delivery cost
customer acquisition
Execution risk
Can we launch reliably?
kitchen capacity
delivery timing
service quality
pilot plan
For a market-entry case, the first layer is not revenue versus costs. It is whether the market is attractive, whether the client can win, whether the economics work, and whether the launch is feasible.
Issue treeSubscriber-loss sample structure
Case questionWhy are app subscribers falling?
New sign-ups
Are fewer people joining?
traffic
conversion
channel mix
offer quality
Reactivations
Are fewer lapsed users returning?
winback campaigns
seasonality
product changes
pricing
Cancellations
Are more users leaving?
tenure
usage level
plan type
competitor switching
For a subscriber-loss case, the first layer can be a subscriber bridge: new sign-ups plus reactivations minus cancellations. That keeps acquisition and retention from getting mixed together.
That picture is what people mean when they say "issue tree." You do not have to physically draw it, though jotting it down on your scratch paper genuinely helps. You just have to talk through it cleanly. And do not agonize over landing the perfect number of branches. Agonize over whether each branch earns its place.
3. Make the buckets specific: "market" is not a structure.
Weak candidates name broad categories. Strong candidates say what they would actually look at inside each one. The contrast is not vague versus fancy. It is vague versus case-specific: a useful structure fits the exact question, keeps the first layer clean, and tells the interviewer where you would start.
Example 1A meal-kit company is considering corporate lunch delivery. Should it enter?
Vague structure
I would look at the market, customers, competitors, and company.
Case-specific useful structure
Since the client is deciding whether to enter corporate lunch, I would structure this around three questions: is there enough recurring demand from offices, can our meal-kit model serve the lunch occasion better than alternatives, and would the economics work after sales, kitchen capacity, and delivery costs. I would start with employer and employee demand by office size, because if recurring demand is thin, the rest of the launch will not matter.
Example 2A coffee chain's profits dropped 15% last quarter. What happened?
Vague structure
I would look at revenue, costs, customers, competitors, marketing, and operations.
Case-specific useful structure
Since profit fell, I would keep the first layer clean: revenue versus costs. On revenue, I would separate traffic, average ticket, and product mix, then cut that by store, region, and channel to see where the decline is concentrated. On costs, I would separate fixed costs like rent and salaries from variable costs like ingredients and hourly labor. I would start with revenue versus costs because that tells us whether to chase demand or cost pressure first.
Example 3A fitness app is losing subscribers. How should it respond?
Vague structure
I would look at users, product, pricing, competitors, and marketing.
Case-specific useful structure
Since the app is losing subscribers, I would first build a subscriber bridge: new sign-ups, reactivations, and cancellations. For new sign-ups, I would look at acquisition volume and conversion by channel. For reactivations, I would check whether lapsed users are coming back. For cancellations, I would cut churn by tenure, plan type, and usage level, then test the reasons people leave. I would start with the subscriber bridge because it tells us whether this is mainly an acquisition, reactivation, or retention problem.
Specificity is the whole difference between a label and a tool.
4. Make it MECE enough to be useful.
Slow down here
This is one of the moves interviewers watch most closely.
MECE means your structure should do two things:
Mutually exclusive: each bucket has its own job. The same issue should not show up everywhere.
Collectively exhaustive: together, your buckets cover the important parts of the problem, with no major area left out.
In plain English: no messy overlap, no obvious missing piece. Most non-MECE structures fail in one of four common ways.
Example case for this section
A regional grocery chain piloted same-day grocery delivery in one city. It is now considering expanding delivery into three new cities. Should it expand?
Not MECE typeOverlapping buckets
Example
I would look at whether customers in the new cities want grocery delivery, which household segments care most about convenience, whether busy families would use it, and how often customers would order.
Why it fails
This sounds practical, but the buckets overlap. Customer demand, convenience needs, busy families, and order frequency all belong inside the same demand branch.
Not MECE typeMissing a major branch
Example
I would size demand in the three cities, identify the highest-value customer segments, compare competitor delivery apps, and decide which marketing channels would drive adoption.
Why it fails
This is mostly market-facing. It says nothing about whether stores can pick, pack, and deliver orders reliably or whether each order makes money.
Not MECE typeMixed levels
Example
I would look at market attractiveness, whether we have enough pickers and drivers, the delivery fee per order, performance in City A, and whether refrigerated items can be handled safely.
Why it fails
These are different levels of the tree. Market attractiveness is first-layer, pickers and refrigerated items are operations details, delivery fees are unit economics, and City A is a segment.
Not MECE typeMixed logic
Example
I would look at suburban families, Instacart and DoorDash, delivery speed, labor scheduling, subscription pricing, and whether customers prefer organic produce.
Why it fails
This mixes a customer segment, competitors, value proposition, operations, pricing model, and product preference. The interviewer cannot tell what sorting rule you are using.
You do not need perfect MECE. Real business problems are messy. The goal is clean enough to guide the analysis. If two buckets might overlap, say a quick word on what lives where.
A simple test
If I found a new piece of information, would I know where to put it? If yes, your structure is probably clear enough.
5. Close your structure by saying where you would start, and why.
This comes at the end of your structure. After you have stated the objective, laid out the main branches, and named the useful sub-drivers, do not just stop. Add one closing sentence that tells the interviewer where you would start and why:
I would start by comparing revenue and costs, because that tells us fast whether this is a demand problem or a cost problem.
That is judgment. You are not waiting to be steered. You are closing the structure with a clear first move.
What weak looks like
Weak structure · list wearing a structure's clothes
AI
Prompt
A coffee chain's profits dropped 15% last quarter. What happened, and what should they do?
YOU
Weak answer
I would look at revenue, costs, customers, competitors, operations, marketing, and maybe the economy.
Why it falls flat
It sounds memorized. The buckets overlap. It never says what is inside each one, never picks a starting point, and never connects to this specific 15% drop.
What strong looks like
Strong structure · same prompt, cleaner thinking
AI
Prompt
A coffee chain's profits dropped 15% last quarter. What happened, and what should they do?
YOU
Strong answer
Since the goal is to understand why profits fell and what to do about it, I would start by splitting the problem into revenue and costs. On revenue, I would check whether the drop came from fewer customers, lower average order value, pricing, or product mix. On costs, I would look at the big categories: ingredients, labor, rent, and any one-time costs. I would also compare performance by store, region, and channel to see whether this is broad or concentrated. I would begin with revenue versus costs, because that quickly tells us which side of the profit equation is driving the decline. If that sounds reasonable, I would start there.
Objective-led, specific, distinct buckets, and a clear first move.
Same prompt, completely different impression. It starts from the objective, names real sub-drivers, keeps the buckets distinct, segments to locate the problem, and commits to a first move. It sounds like a person, not a framework robot.
Common traps
The usual ways structures go wrong
Forcing a famous framework onto a case it does not fit.
Creating too many buckets.
Hiding behind vague labels like "market" or "company."
Letting buckets overlap without defining them.
Forgetting the client's actual question.
Building a beautiful map but never choosing a road.
Reaching for impressive when useful was the assignment.
Practice structuring in CaseLab
CaseLab's structuring drills are a live, voice-interactive version of the exact opening move you just learned. You hear a short case question, speak your structure out loud like you would in a real case interview, then review feedback on whether your answer gives the interviewer a useful map to follow.
What the drill checks
Whether your first layer fits the case question.
Whether the buckets are MECE enough to guide the analysis.
Whether your sub-drivers are specific instead of generic labels.
Whether you close with a clear first move and why.
The point is repeated reps. You practice turning ambiguity into a useful structure, get feedback on what was clear or fuzzy, then make the next opening sharper.
Structuring drills
Try a CaseLab structuring drill
Start with a fresh case question, build the structure out loud, and use the feedback to sharpen your next rep.