CaseClimbThis guide shows you how to solve a business problem the way consulting teams do: start from a best guess at the answer, then spend your time trying to prove it wrong. You will learn to write a working hypothesis, build the issue tree under it, pick the analysis that tests it fastest, and run a team meeting on the same pattern. A full worked example from a sales team runs through the middle, with the numbers checked.
Hypothesis-driven work in plain terms
A hypothesis is a sentence that states the answer you expect, written down early, before you have the evidence. You share it with the team and design the work to test it. If the evidence supports it, you go deeper. If the evidence breaks it, you replace it with a better one and carry on.
Most organisations default to gathering all the data first and letting the answer emerge. It feels rigorous. In practice it tends to produce a large deck, a long delay and a vague conclusion, because the team did not agree in advance which data mattered, and people spend their energy organising material instead of deciding.
A hypothesis gives the work a direction. Each person knows which question their analysis answers and which result would change the plan. Consultants work this way because engagements run on weeks, and most managers face the same clock. The method asks you to commit to a view before you are sure and to accept that the first view is often wrong. Being wrong on day two costs you little; discovering it on day forty costs you a quarter.
Writing a good working hypothesis
A useful working hypothesis passes three tests. It is specific enough that two people would agree on what it claims. You can test it with data you can get in days. And it could turn out to be wrong, which means you can name the result that would kill it.
- Too vague: "Our customer service needs improving." You cannot disprove it, so you cannot test it.
- Better: "Complaints rose because the new booking system adds two steps for repeat customers." You can check whether the rise sits in repeat customers and started with the system change.
- Too vague: "We need to reduce costs."
- Better: "Overtime in the two northern warehouses explains most of the rise in fulfilment cost since spring." One payroll extract proves or breaks it.
Write the hypothesis as a full sentence with a cause and a consequence, and add a scope where you can: which region, which product, since when. Then write one more line under it: "This is wrong if...". If you cannot finish that line, the hypothesis is still too soft.
Building the issue tree under the hypothesis
A single hypothesis is too big to test in one go, so you break it into the two to four statements that must all be true for it to hold. Those statements are the branches of your issue tree, and each one points to an analysis. Consulting candidates learn this as structuring a case, and the rules carry over: the branches should not overlap, and together they should cover the claim.
Test the tree by reading it from the bottom up. If all the branches came back true, you should believe the hypothesis. If any one came back false, the hypothesis should fall. If either check fails, a branch is missing or one of them is decoration.
Choosing the analysis that could prove it wrong fastest
Rank the analyses on two things: how quick each one is, and how much damage a bad result would do to the hypothesis. Start with the one that scores high on both. Many teams start instead with the analysis most likely to confirm their view and leave the cheap killer test until last.
Ask the team which single result this week would change your mind, and run that first. A one-day cut of data you already hold beats a four-week survey.
A worked example: the falling win rate
Picture a regional sales director at a software company. Over a year, her team's win rate on qualified deals fell from 32% to 24%: last year the team won 128 of 400 deals, this year 120 of 500. A low-cost competitor had entered the region in the same period, and the first team meeting reached a fast consensus: "We are losing on price." Some reps were already asking for a standing 15% discount.
She wrote it down as a working hypothesis: "Our win rate fell because the new competitor undercuts us on price in mid-market deals." Then she broke it into three sub-hypotheses that would all need to hold.
- The fall is concentrated in deals where the new competitor was present.
- Lost deals cite price as the reason more often than they did last year.
- Win rates in deals without the competitor have held steady.
She chose two analyses. The first, a split of win rate by lead source, took the CRM an afternoon and tested whether the fall was broad or sat in one kind of deal. It was the fastest way to break the whole idea: a price problem would drag down every source, so a fall confined to one source would point somewhere else. The second, a review of 40 recent lost deals using call notes and the reps' stated loss reasons, took two days and tested the first two branches together.
The first analysis broke the hypothesis. Outbound and referral deals had a win rate of 35% last year (105 wins from 300 deals) and 34% this year (85 from 250). Inbound deals from the website and marketing campaigns had a win rate of 23% last year (23 from 100) and 14% this year (35 from 250). Inbound volume had risen two and a half times after a spring campaign, and those leads converted far worse.
The arithmetic splits the 8-point fall in two. At last year's win rates, this year's mix would have produced 87.5 plus 57.5, or 145 wins from 500, a win rate of 29%. The shift towards inbound explains 3 points, and the drop in inbound quality explains the other 5. The loss review confirmed it: of the 40 lost deals, 26 ended with "no budget" or "no decision", 6 cited price, and the new competitor appeared in 9.
Her revised hypothesis read: "Our win rate fell because the spring campaign flooded reps with inbound leads that lacked budget, and reps qualified them out late, which also cut the time they spent prospecting." The fall in outbound and referral deals from 300 to 250 fitted that story. She took a three-part recommendation to the commercial director.
- Hold the proposed 15% discount: price explains a minority of losses, and a standing discount would cut margin on deals the team wins at full price.
- Add a qualification step for inbound leads, with an inside sales rep confirming budget and timeline before a deal reaches an account executive.
- Report win rate by lead source each month, so the team sees a mix shift within weeks instead of a year.
The team moved from a wrong answer to a better one in under a week, and the analysis that did the most work took an afternoon.
Running a team meeting this way
You can run a problem-solving meeting in this pattern in about an hour, and most of the value comes from making people write things down.
- Ten minutes: agree the question in one sentence, with a scope and a deadline, for example the reason win rate fell this year and the change to make by next quarter.
- Fifteen minutes: each person writes a hypothesis in silence. Read them out, pick one to test first and keep the others on a list.
- Fifteen minutes: break the chosen hypothesis into branches and write the "this is wrong if" line for each.
- Ten minutes: rank the analyses by speed and by damage, and assign the top two with a date.
- Ten minutes: set the next meeting and agree which result would make you switch hypotheses.
The silent writing step matters most. If the most senior person speaks first, the team tends to test that view alone. Written views give you alternatives when the first one breaks.
Common failure modes
Three failures account for most of the trouble managers report with this method.
- Falling in love with the first hypothesis. The team stops testing and starts defending, and you hear people explain away results instead of revising the claim. Set the "this is wrong if" line before the data arrives and hold yourself to it.
- Hypotheses too vague to test. "Engagement is low" or "the process is inefficient" can absorb any evidence. Push for a cause, a scope and a number until someone could prove the statement false.
- Analysis paralysis. The team asks for one more cut of data before it will commit. Set a decision date at the start and agree how much evidence a decision of this size needs. A reversible decision needs less proof than a reorganisation.
A fourth failure is quieter: the team tests the hypothesis well, then presents the analysis in place of the answer. Lead with the revised hypothesis and the recommendation, then show the evidence. Consultants call this answer-first, and it is the same discipline as closing a case with a recommendation.
Learning it through case practice
Reading gives your team the vocabulary; the habit comes from repetition under light time pressure, which is why consulting firms train it through cases. A case gives you an ambiguous business question, a short clock and someone who pushes back, so you practise forming a view, structuring it and revising it as new data arrives, many times in a few weeks.
Teams outside consulting can borrow the format. Run a 30-minute case at the start of a team meeting, with one person leading and one playing the client, and rotate the roles each week. Afterwards, spend five minutes on two checks: whether the first hypothesis got tested or defended, and whether the team picked the fastest killer analysis. The skills a case interview tests are the ones a manager needs here: structure, numbers, judgement and a clear answer.
Common questions
Isn't starting with a hypothesis a form of bias? It becomes one if you defend it. Used as intended, the method works against bias, because you write down in advance the result that would prove you wrong and you run that test first.
What if I have no idea what the answer is? Make your best guess anyway, from experience or from the people closest to the problem. A weak first hypothesis that breaks in two days still shows you where to look next.
How many hypotheses should a team test at once? One main hypothesis with two or three branches covers most problems. Keep the alternatives the team wrote down, and pull the next one forward when the main one breaks.
Does this work for people problems as well as numbers problems? Yes. You can test a hypothesis such as "attrition rose because new joiners in the support team lack a named mentor in their first month" with exit interview notes and joining dates.
If you want your team to build this habit through structured case practice, see how we run training for teams.
