BoardroomIQ logoBoardroomIQ
Curriculum · 0/40Contents

Structuring & Communication · Lesson 3

Hypothesis-driven problem solving

You're previewing this lesson for free. It joins your tracked path once you pass Foundations's capstone.

Intuition

A detective doesn't dust every surface in the city for fingerprints. They form a theory — "the butler did it" — and then go looking for the one piece of evidence that would confirm or destroy it. Hypothesis-driven problem solving is the same move: instead of analyzing everything, you commit to a likely answer early and aim your limited time at testing it.

This is what separates a consultant from a data dump. Anyone can list ten things to look at. A consultant says which one probably matters and why.

Framework

  • State a hypothesis early. "My leading hypothesis is that the profit drop is a cost problem, specifically rising logistics."
  • Make it testable. A good hypothesis names the data that would prove it right or wrong.
  • Test, then update. Go to the branch, get the number, and say what it means. Confirmed → go deeper. Killed → pivot, out loud.
  • Stay disciplined, not stubborn. Hold your view confidently but drop it the instant evidence says otherwise.

Worked Example

A retailer's margins are shrinking. Weak approach: "Let me look at revenue, costs, competition, pricing, and the market." Strong approach: "Margins, not revenue, are the issue — so my hypothesis is that costs rose faster than price. Within costs, I'd bet on input prices given recent commodity moves. Can I see cost of goods over the last three years?" If COGS is flat, you say so and pivot to price erosion. You've spent your minutes like a detective, not a vacuum cleaner.

Pitfalls

  • Refusing to commit — "I'd need to see all the data" reads as no point of view.
  • Clinging to a dead hypothesis after the data killed it.
  • A hypothesis so vague ("something is wrong with the business") that no data could test it.