The hypothesis-first method for case competition teams.

Strong case teams do not wait until the end to decide what they think. They state an early answer, test it against the case pack, and change it when the facts disagree.

Why start with an answer

Many student teams approach a case by collecting everything first: reading every exhibit, building every chart, and only then asking what the recommendation should be. Under competition time limits, this often leaves the team with plenty of analysis and no clear answer an hour before presenting. The hypothesis-first method changes the order. After the first read, the team writes a provisional answer to the core question and uses the rest of the time to test it.

A hypothesis is not a guess the team is committed to. It is a working answer that makes the analysis focused. Every chart either supports it, weakens it, or is not needed. The method fits naturally with issue trees, which many teams already use, and it works for strategy, market entry, and operations cases alike.

Step one: state the hypothesis in one sentence

After the first silent read and the shared fact list, each team member writes one sentence answering the core question. Compare the sentences. If they agree, write the shared version. If they differ, choose the one the team finds most plausible and record the others as alternatives. The sentence should be specific enough to be wrong, for example: the client should enter the second market through a partnership rather than building its own channel.

Write the hypothesis at the top of the team's working document and date the time. This simple step stops the team from drifting into analysis for its own sake, because every task can be checked against the sentence.

Step two: break it into testable claims

A recommendation rests on a few claims. If the hypothesis is to enter through a partnership, the claims might be that the market is attractive enough to enter, that the client lacks the capability to build its own channel in time, and that suitable partners exist on acceptable terms. Write these as the first branches of an issue tree, phrased so that each can be supported or contradicted by evidence.

Keep the claims few and mutually distinct. Three or four is usually enough. If a claim cannot be tested with the information in the case pack or a reasonable estimate, rewrite it or note it as a risk rather than a claim.

Step three: test each claim against the case pack

Assign each claim to a team member or pair. Their job is to find the exhibits and calculations that support or weaken it, and to report back in a fixed format: the claim, the evidence for, the evidence against, and a verdict of supported, weakened, or unclear. Short, structured reports make the next team discussion fast.

Encourage testers to look actively for contrary evidence. The value of the method comes from finding weaknesses early, while there is still time to change direction. Any estimate used, such as a market sizing calculation, should show its assumptions so that teammates and judges can follow it.

Step four: revise the hypothesis on purpose

Bring the verdicts together at a fixed checkpoint, roughly at the midpoint of the time available. If all claims are supported, keep the hypothesis and move on to implementation and risks. If one is weakened, adjust the recommendation, for example by changing the entry mode or adding a condition. If several are weakened, switch to one of the recorded alternatives and test it quickly.

Record each revision with the reason. Judges often ask why a team did not choose an alternative, and a team that tested and rejected it can answer clearly. Revision is a sign of good analysis, not indecision.

From tested claims to recommendation slides

Once the hypothesis is stable, the slide structure follows directly. The opening slide states the recommendation. Each following section corresponds to one claim, with its strongest evidence. A final section covers risks, including any claim that remained unclear. This top-down structure makes the presentation easier for judges to follow and easier for presenters to remember.

Cut any chart that does not support a claim. Teams often keep slides because they took time to make. The hypothesis gives a clear test for what stays, which keeps the deck short and focused.

A short worked example

Take a practice case in which a regional coffee chain asks whether to launch a delivery service. After the first read, the team writes: the client should launch delivery in its two densest locations first, through an existing delivery platform. The claims are that demand for delivery exists among current customers, that margins remain acceptable after platform fees, and that the stores can handle extra orders at peak times.

Testers find exhibit data supporting demand, a fee calculation that weakens margins on small orders, and staffing figures that are unclear. At the checkpoint the team revises: launch delivery with a minimum order value, in two locations, and treat peak staffing as the main risk to monitor. The recommendation is now narrower, better supported, and easier to defend in Q&A.

Common mistakes in practice

The most common mistake is anchoring: refusing to revise the hypothesis when the evidence turns against it. The fixed midpoint checkpoint is the safeguard. Another is writing a hypothesis so vague that it cannot be wrong, such as the client should grow. Push for a specific choice. A third is testing claims informally in conversation without writing verdicts, which makes the checkpoint slow.

Practise the method on past cases during training, with a timer and a coach playing the role of a sceptical judge. After a few rounds, teams usually find that they reach a defensible recommendation sooner and spend the final stretch improving delivery rather than rushing analysis.