How to structure a case: framing and first hypotheses

Framing is the moment that decides everything. The first 10 minutes of a case interview determine with 95% probability whether you will pass or not. And I'm not talking about improving as you go. I mean it's already decided.

In my 300+ interviews as an evaluator at Bain & Company, I saw excellent candidates with numbered analyses but confused framing who were rejected. And I saw candidates who opened with impeccable framing who then made calculation errors but still passed, because they demonstrated structured thinking. That's what we're looking for.

Framing is not a ritual. It's not drawing a pretty diagram to make it look like you know. Framing is your answer to a simple but brutal question: "Do you understand the problem? Where are we going to look for the answer? Why in that direction?"

Many candidates confuse framing with "using a framework". They think that if they draw the 4 Ps of marketing or a 2x2 matrix, they're done. Wrong. Real framing is specific to the problem. It's your clear hypothesis about what's happening, built from what you heard and asked.

In this article, I'm going to show you exactly how to structure a winning framing: how to listen, what to ask, how to generate a concrete hypothesis, and how to build an issue tree that truly covers the problem. No fluff. With real examples. And with the practical exercise I used with candidates at Bain.

The Hypothesis: Having One or Not

The difference between candidates who pass and candidates who don't pass is not the complexity of the framework. It's whether they have a clear hypothesis.

I've seen two completely different scenes:

Scene 1: Without a hypothesis. The candidate opens the case, listens and says: "OK, I have questions. I need data on revenue, costs, and market structure." They sit staring at you, waiting for you to give them numbers. They have no direction. It's like entering a forest without a compass and hoping to find the exit by asking about each tree.

Scene 2: With a hypothesis. The candidate listens to the case and says: "My initial hypothesis is that the margin decline comes from costs, specifically from the variable cost structure, because the market grew 20% but profitability fell. That suggests pricing pressure or operational inefficiency. To validate this, I need to first understand the evolution of price versus volume, and then within costs, how the fixed versus variable structure is distributed." Then they draw an issue tree consistent with that hypothesis.

What's the difference? It's not in the number of frameworks they know. It's that candidate 2 has direction. They have a thesis. When you ask them, they know why they're requesting those specific data points. They're telling the interviewer: "I've processed what I heard, I have a suspicion about what's happening, and here's my plan to test or rule out that suspicion."

A weak hypothesis is vague. "It could be that costs went up or the market is saturated." That doesn't count. A strong hypothesis is concrete: "I think the problem is X because Y, and to find out I'm going to look at Z."

This is not trivial. The hypothesis is a signal of structured thinking. And that's the standard we look for in consulting. We're not looking for candidates who know 47 frameworks. We're looking for candidates who know where to look.

Listen, Ask, Confirm: The Triangle Before Framing

There is no framing without listening. Many candidates make the mistake of listening to the case passively. They wait for the interviewer to dump all the information and then they create a framework. Wrong.

The correct sequence is different: listen + clarifying questions + confirmation of understanding + pause + hypothesis + issue tree.

Step 1: Active listening. When you listen to the case, you're not just receiving information. You're searching. What data do you see? What's missing? What's contradictory? A CEO tells you "our margins fell 3 points last year even though revenue grew." Your mind should be on alert: that's unusual. There's a cause behind it. Costs, price, product mix, competition. Something.

Step 2: Clarifying questions. After listening, you must ask. Questions are not optional. They're mandatory. Why? Because they eliminate ambiguity. Questions should be specific:

• ●"When you say margins fell 3 points, is that operating margin or net margin?"
• ●"Did that decline happen across all customer segments or is there variation?"
• ●"Did the average price change? Or was it volume?"

Each question gives you a data point. But more importantly, it tells the interviewer that you're being precise. You're not assuming. You're validating.

Step 3: Confirmation of understanding. Summarize what you heard. "If I understood correctly, we're in the retail segment, with 3 product lines, and what happened is that volume grew but price fell, which explains the margin decline. Correct?" If the interviewer says "not exactly" or "there's more," they'll tell you. That way you correct before building the wrong framework.

At Bain, I saw candidates skip this step. They assumed, built a hypothesis based on what they thought they heard, and then the interviewer had to tear down the entire tree because the candidate misunderstood. That kills your confidence as an evaluator.

The Issue Tree: From Hypothesis to Structure

Once you have a clear hypothesis and confirmed understanding, you build the issue tree. This is the step where many candidates fail without knowing why.

Error #1: Using a generic framework. The candidate thinks "this is a profitability case, so I'll use the margin formula: price × volume ÷ costs." They draw that and think they're done. But that's not an issue tree for this specific case. That's a skeleton without flesh.

Error #2: Not being MECE. MECE means Mutually Exclusive, Collectively Exhaustive. That is, each branch doesn't overlap (exclusive) and together they cover the entire problem (exhaustive). If your tree has "variable costs" and "operating costs," you're overlapping. If you have "costs" but don't separate by type, you don't cover everything.

How to build a correct issue tree:

1. 1Start with the main metric. In this case: Margin = (Revenue - Costs) / Revenue. That's the root of the tree.

1. 2Break down Revenue. Did price change? Did volume change? Did product mix change? That's MECE: each element is independent, and together they explain the variation.

1. 3Break down Costs. Here's the meat. If your hypothesis is that the problem is in costs, you need to know where:

• ●Fixed Costs: Which ones scaled up? Investment? Personnel?
• ●Variable Costs: Did they change per unit produced? Material inflation? Change in mix?

1. 4Dig deeper where the insight is. If the hypothesis is "the variable cost structure shifted," then you go one level deeper: materials (20% of cost), labor (40%), overhead (40%). For each, you ask if it changed.

The issue tree is not the same for each case. It changes based on your hypothesis. If your hypothesis is "the problem is competition," the tree is different: market share, pricing power, differentiation. If the hypothesis is "operational inefficiency," the tree focuses on processes, utilization, productivity.

I'd say 70% of candidates who fail at framing make this error: they use a generic tree. You have to be specific.

How to Distinguish Memorized Framing from Thought-Out Framing

Here's where it gets interesting. When the case is standard (typical profit case: "why did profitability fall?"), it's almost impossible to know if the candidate memorized a framing or thought through it. Both sound good.

But when the case changes slightly, or when the interviewer asks you to "double-click" on a particular branch, that's when you see it.

Scene with a candidate who memorized: The interviewer says "Now, within variable costs for materials, we want you to investigate why the purchase of raw material X doubled." The candidate stares blankly. They go to their memorized tree and don't know how to adapt. They ask generic questions. They don't have a hypothesis about why it doubled. It could be scarcity, supplier change, product spec change. But the candidate doesn't get there. They just ask "what changed in price?" That's a clear sign of memorization.

Scene with a candidate who thought it through: Same scenario. The candidate says: "If raw material X doubled, that could be due to variations in the commodity market, a change in our purchase specs, or a supplier change. I'm going to assume the market didn't change because that would only affect us if it did, so it was probably a change in our demand or sourcing. Can I ask what changes happened in production volume this period?"

That candidate is thinking in real time. They're not reciting a script. They're building a new tree based on the new branch you're asking them to explore.

How to detect this as an interviewer: the level of detail in the explanation and the ability to justify why each branch exists. If the candidate says "and here I put fixed costs, here variable costs" without explaining why that covers the problem, it's memorized. If the candidate says "costs can vary by production quantity or by process efficiency, and that impacts margin because..." then they're thinking.

Timing: 3-5 Minutes, But It Depends

You have 3 to 5 minutes for framing. That sounds short. It is short. But it all depends on the interviewer.

If the interviewer is staring at you intently, hanging on your every word, you need to be quick and concise. Brief intro: "I understand the problem. My hypothesis is X because Y. To validate it, I'm going to investigate Z." Draw the tree while you talk. Done.

If the interviewer is writing or seems relaxed, you have more room. But don't abuse it. Never more than 5 minutes.

One thing I've noticed in good candidates: they don't say "I'm going to do framing now." They just do it. They listen, ask questions quickly, confirm, and present. Everything flows as a conversation, not like "now it's framing's turn."

Adjusting Your Hypothesis During the Case: When and When Not To

Here's a golden rule that almost nobody understands well: if your hypothesis is correct and you change it, you've screwed up. If it's incorrect and you adjust it, perfect. If it's incorrect and you don't adjust it, it's serious.

Scene 1: Hypothesis is correct, you change it. You started by saying "I think the problem is raw material supply shortage." You investigate and confirm it's true. But midway, the interviewer gives you a number that doesn't fit and you panic. You change hypotheses: "Oh, no, I think it's competition." That's losing confidence. The evaluator thinks: "You have a clear result and you don't trust your own analysis."

Scene 2: Hypothesis is incorrect, you adjust it. You started with a hypothesis, began investigating, and the data doesn't support it. A smart candidate stops and says: "I see my initial hypothesis doesn't validate. The numbers suggest something different. My new hypothesis is..." That's critical thinking. That's what we want. It's not "I made a mistake." It's "I updated my hypothesis with new information."

Scene 3: Hypothesis is incorrect, you don't adjust it. The worst of all. The candidate sees data that contradicts their hypothesis but keeps going as if nothing happened. They ignore or rationalize. That's denial. In consulting, that's fatal. If the data doesn't confirm your theory, you have to update it. If you don't, any conclusion will be wrong.

The difference between Scene 2 and Scene 3 is the level of rigor. At Bain, the ones who understood that passed. Those who didn't were out.

Frequently Asked Questions

Q: Should I share my hypothesis with the interviewer or just use it internally?

A: Share it. Always. Framing is communication. If you don't voice your hypothesis out loud, the interviewer doesn't know what you're thinking. And they can't validate if you're on the right track. Say something like: "My hypothesis is that..." and wait for feedback. If the interviewer says "that's incorrect" or "that's not what we're looking for," better to know now than after 20 minutes of analysis.

Q: What do I do if the interviewer's hypothesis is different from mine?

A: Sit back. Use theirs. It's not a competition. The interviewer has the map. You don't. If your hypothesis was different, you can ask why theirs is better, but then proceed with what the interviewer suggests. In real cases, the client also guides. Adaptability is critical.

Q: Is it bad if the interviewer corrects my framing midway?

A: It's not bad. It's normal. It means you're communicating clearly enough that the interviewer can give you feedback. What's bad is if you don't communicate anything and you get lost in the tree without the interviewer knowing where you are.

Q: Do I need a visually perfect issue tree or can it be messy?

A: Perfect in logic, not in aesthetics. I've seen candidates draw beautiful trees but with confusing logic, and candidates drawing squares and arrows without visual coherence but with clear thinking. The interviewer sees the logic, not the Photoshop.

Q: What if I go blank during framing?

A: Pause. Breathe. Ask more questions. Ask for time: "Give me a minute to structure this." Nobody expects you to be fast. They expect you to be right. If you need 4 minutes instead of 3, that's fine. What's not fine is talking without thinking.

Q: Does framing change if it's a strategy case versus a finance case?

A: It changes in content, not in process. The process is still the same: listen, ask, confirm, hypothesis, tree. But in a strategy case your tree focuses on segmentation, positioning, competitive advantage. In finance it focuses on cash flows, valuation, capital structure. The logic is the same. Only the tree is different.

The Practical Exercise: Build Your Framing Now

Here's a real case. This is the type of problem you hear in a Bain interview. I'm going to give it to you without framing. Your task is to frame it on your own. Then I'll show you how I'd do it.

The case: "A mid-price athletic apparel retail chain operates 150 stores in your country. Revenue grew 15% last year, but EBITDA fell 5%. The CMO is concerned. What's happening?"

Your task (20 minutes):

1. 1Write 3 clarifying questions you would ask.
2. 2Create an initial hypothesis based on what you see.
3. 3Draw an issue tree (can be text or image) that investigates that hypothesis.

Then reflect: Is my hypothesis concrete or vague? Is my tree MECE? Does each branch answer "why" for the EBITDA decline?

This is the work I do before every case. And it's the work evaluators expect you to do.

Action Plan: From Here On

1. 1Practice framing without cases. Take a business article about a company in trouble. Read the first few paragraphs. Without reading the solution, create your hypothesis. Draw your tree. Then see if your analysis matches the article's.

1. 2Record yourself doing framing. Record audio as you present a case's framing. Listen to yourself. Does it sound clear? Is your hypothesis specific? Or is it vague? Is the tree coherent?

1. 3Ask for feedback at each iteration. If you practice with friends or a mentor, after each framing ask: "Did you understand my logic? Is my hypothesis clear? Is anything missing from the tree?" That's real feedback.

1. 4Study real cases. See how other people do it. Look for solved cases from McKinsey, BCG. Work backward. What was the initial framing? What was the hypothesis? Why was that the tree?

Framing is the skill that will differentiate you the most. Not because it's complicated. It's because almost nobody masters it. Most memorize. You, on the other hand, are going to think in real time.

That's what we look for at Bain. And that's what you need.

Related Resources

To deepen your case knowledge, check out these articles:

• ●Types of cases you'll see in MBB interviews
• ●MECE Framework: the tool behind every case
• ●Issue trees: how to build the tree that solves the case
• ●Case practice: how to do practice cases without help

And don't forget to review the complete preparation plan that covers the entire path.

Next Step: Get the Book

If framing interests you, the book Crack The Frameworks goes deeper into each component with 50+ exercises designed with MBB methodology. From hypothesis to issue trees, everything with the precision you need.

Download the book: nextepmbb.com/resources