Hypothesis Driven Cases: One Number That Kills a Branch

Four firms publish a hypothesis driven sequence

Accenture's case workbook at accenture.com sets out six steps: Listen to case, Clarify problem, Decompose problem, State hypotheses, Test hypotheses, Summarize findings. Two of six. The same document corrects a myth in passing, stating that the interviewer "expects you to be effective with the knowledge you have and make hypotheses based on sound common sense".

L.E.K. makes it step five of seven, at lek.com. Its gloss is short: "Share your thought process as information is revealed." That places the hypothesis in the middle of the case rather than at the front, and it ties the hypothesis to incoming data.

Deloitte's practice tool at usrecruiting.deloitte.com folds it into Strategic framing: "Develop a logical structure and identify assumptions; take notes while the scenario is being read to help you structure your thoughts and think through how you'd like to respond". Its tips page adds a hypothesis to the structure explicitly in its list of eight.

Simon-Kucher names it among the things a case lets you show, writing that a business case interview lets you "demonstrate how you structure complex problems, develop hypotheses, analyze information, and communicate your thinking".

Four firms, four positions, and all four put the hypothesis after some structure exists. None of them puts it first. That order matters, and it is the opposite of the advice to open a case with a guess.

The hypothesis driven sentence a Kearney analyst gives for free

One published line supplies the grammar. A business analyst in Kearney's Chicago office, on her employer's careers blog read through a text proxy at kearney.com, writes: "Another way to be a forward thinker is to bring reasoning to your questions. Start with "I suspect ____ therefore _____.""

That is a named consultant describing her own practice, published by her employer. It is a source for what she does rather than a firm rule, and we label it that way.

The form does something specific. It attaches a reason to a request, which turns a question into a test. Compare the two versions of the same request.

1. Without it. Can I see the cost data? The interviewer now has to guess what you would do with it.
2. With it. I suspect input cost rose, therefore I would like the cost of goods rate for each year. The request is now falsifiable, and the interviewer knows what an answer would settle.

The second version also protects you. If the data comes back flat, you have not been wrong about anything, because you named a suspicion and tested it. A candidate who asked for cost data with no stated reason and then moved on looks like they were fishing.

Deloitte's tips page carries a warning that bounds this. It states: "Ask questions, but don't use them as a crutch. While it's important to ask clarifying questions, avoid relying on them too heavily. We're interested in how you connect the dots when solving the problem." A question with a hypothesis attached is doing the connecting out loud, which is the thing being asked for.

A hypothesis that a single figure can kill

Here is the move that separates a hypothesis from a guess. Design the request so that one number eliminates one explanation.

The situation, with stated assumptions. A manufacturer's revenue has been flat at 120 million dollars for two years. Operating profit fell from 9.6 million dollars to 7.2 million.

First, measure the fall properly. The drop is 2.4 million dollars, which is 25.0 percent of the 9.6 million starting profit. Expressed against revenue it is 2.4 over 120, so exactly two percentage points. Recomputed by hand on 30 September 2026: 9.6 minus 7.2 is 2.4; 2.4 over 9.6 is 0.25; 2.4 over 120 is 0.02.

Say both numbers and say which base each is on. Two points of revenue and 25 percent of profit are the same event measured two ways, and confusing them is the error this site corrected on another page in September 2026.

Two candidate explanations. Either the cost of goods rate rose, or operating expense rose. Revenue is flat, so those are the only two places 2.4 million dollars can come from.

The discriminating request. Give me the gross margin rate for each year.

Check the first row. Cost of goods at 62 percent of 120 million is 74.4 million; at 64 percent it is 76.8 million. The difference is 2.4 million dollars, which accounts for the entire fall. Verified by hand: 120 times 0.62 is 74.4, and 120 times 0.64 is 76.8.

One request, three possible answers, and in two of the three a whole branch closes. That is what a testable hypothesis buys, and it is why the request is worth more than the structure it came from.

Stating a hypothesis in a case interview without committing to it

The fear that stops candidates from stating hypotheses is being wrong out loud. Two published instructions resolve it.

L.E.K.'s step five asks you to share your thought process as information is revealed, which frames the hypothesis as provisional by construction. And its step six asks you to commit while showing "flexibility and a willingness to rethink in the face of new data". So the published sequence has you state a hypothesis, then explicitly permits revision.

Three forms that state a hypothesis at different strengths, all defensible.

1. Directional. I suspect the problem is on the cost side, because revenue is flat. Commits to a half of the business.
2. Ranked. I would look at cost of goods before operating expense, because input prices moved in this period. Commits to an order.
3. Quantified. If the gross margin rate fell two points, that accounts for the entire 2.4 million. Commits to a magnitude, and is the strongest of the three.

The third form is the one that reads as a consultant. It says what would have to be true, which is testable, and it does not claim to know whether it is.

What does not work is a hypothesis with no consequence attached. Saying I think it is a cost problem and then structuring the whole business anyway tells the interviewer the hypothesis was decoration. Accenture's own sequence puts Test hypotheses immediately after State hypotheses for exactly that reason.

The instruction that changes with the seat you want

One page in our corpus asks for different things at different levels, and it is the only one that does.

Deloitte's Australian careers page at deloitte.com publishes two extra tips. For analyst and consultant levels: ensure you can apply commercial awareness with a basic understanding of revenue, profit, market share, customers, competitors and stakeholders. For senior analyst and consultant levels and above: "Suggest data you need to prove/disprove any hypothesis you develop to support your recommendations."

Read the two together. At the junior level the firm wants the concepts. At the senior level it wants the test design. The hypothesis is present in both, and what changes is whether you are expected to name the data that would settle it.

The same page states the general standard: "It's not so much the answer but the process you use to get there. We're looking to understand how you reached your conclusions, rather than the solution itself."

Our reading, and we label it ours: the discriminating request is the senior behavior, and it is available to a junior candidate at no cost. Nothing in the format stops an undergraduate from saying which number would kill their own hypothesis. It is the cheapest way in the whole exercise to sound like someone who has done the job.

Where a hypothesis earns Depth 20

These weights are ours. They come from the grading code in src/lib/grading, and no consulting firm in our corpus publishes a marking scheme.

Drilling the test in a hypothesis driven case

Practice usually improves the guess. The test is the part that is worth drilling, because it is the part that is scored.

1. Take any prompt and write two candidate explanations. Exactly two, so a single number can separate them.
2. Write the one request that separates them. Then write what each possible answer would kill. If no answer kills anything, the request is wrong.
3. Say it in the I suspect therefore form. Out loud, ten times, on ten prompts. It should become the default shape of a question.
4. Quantify the hypothesis before you test it. What would the rate have to move by to account for the whole gap? That is one division and it makes the test sharp.
5. Practice the null result. Have your partner tell you the data came back flat. Then state what that closes and where you go next.
6. Do one case where you name the data you would need but cannot have. That is the senior-level instruction Deloitte publishes, and it is the habit that survives into the job.

Our structure drill scores Coverage, Separation, Depth and Concision separately and names the first correction, and the issue tree examples show branches broken down to the level where a test becomes possible. Both are free and neither needs an account. Neither one can tell you whether your two candidate explanations are the two a partner would have picked, which is the judgment being hired for.

For the opening that has to exist before a hypothesis can, see the case interview opening statement. For reading the figure that settles the test, see reading case exhibits. For what happens when the data contradicts you, see handling pushback.