Hypothesis Testing
Before You Build.

The most expensive engineering work is the kind that builds exactly what was specified and solves exactly the wrong problem. It happens more than product teams admit, and it happens for a predictable reason: the assumption that was never tested turned out to be wrong.

Every product decision rests on a stack of assumptions. "Users will understand this flow." "This is the main job-to-be-done." "The onboarding needs three steps." Most of these assumptions are reasonable. Some are wrong. And in a typical product development cycle, you find out which ones are wrong at the worst possible moment, after the sprint is closed, the feature is shipped, and the data comes back showing flat adoption.

What a hypothesis is (and isn't)

A hypothesis is not a hunch. It's a structured claim about user behaviour that is specific enough to be tested. The form matters: "We believe [user type] will [do this] in [this context] because [reason]. We will know this is true when [observable outcome]."

Most teams skip the last clause. Without a pre-defined success criterion, you can rationalise almost any result after the fact. "The numbers were low, but the qualitative feedback was positive." "Users struggled, but that's just because it was a prototype." Pre-defining what evidence would falsify your hypothesis is the only protection against this kind of motivated reasoning.

The 5-day Hypothesis Testing Sprint

Our structured approach to validation runs in a focused 5-day engagement. The goal is to take one high-stakes assumption, the kind that, if wrong, would materially change what you build, and get real user evidence on it before a line of production code is written.

Day 1: Assumption Mapping

We map every assumption embedded in the proposed feature or product direction. We then stack-rank by risk: what happens to the roadmap if this assumption is wrong? The highest-risk, lowest-evidence assumptions become sprint targets.

Day 2: Hypothesis Formulation & Test Design

Each target assumption is converted into a falsifiable hypothesis. We design the minimum test required to evaluate it, typically a prototype, a concierge test, or a structured interview protocol. The test is designed to surface failure, not confirm the hypothesis. Confirmation bias is the enemy of useful validation.

Day 3: Rapid Prototype Build

We build a prototype at the fidelity required to test the hypothesis, no higher. Sometimes this is a clickable Figma flow. Sometimes it's a paper sketch. Sometimes it's a landing page. The prototype's job is to create a realistic enough experience to generate genuine user reactions, not to demonstrate design polish.

Day 4: User Testing

We run moderated usability sessions with 5–8 users matching the target persona. We observe, we listen, we do not explain. The goal is to watch users encounter the prototype with fresh eyes and track where their mental model diverges from ours. Qualitative patterns emerge quickly, five users is almost always enough to identify the critical failure modes.

Day 5: Synthesis & Decision

We synthesise findings into a recommendation with three possible outcomes: Build as planned (hypothesis confirmed), Build differently (hypothesis partially confirmed, adjustment needed), or Don't build this yet (hypothesis rejected, redirect required). The client gets a written findings document and a sprint planning recommendation.

"The goal is to watch users encounter the prototype with fresh eyes and track where their mental model diverges from ours."

What this is not

A Hypothesis Testing Sprint is not a substitute for full user research. It is not a comprehensive usability study. It is not a market validation exercise. It is a targeted decision-support tool, designed to give product teams the specific evidence they need to make a high-stakes build decision with confidence rather than hope.

The calculus

A 5-day sprint costs a fraction of a single engineering sprint. If it prevents one significant build mistake, a feature that took a quarter to build and was subsequently deprioritised because users didn't want it, the ROI is not marginal. It's overwhelming. The argument for validation is almost always financial, not philosophical.

If you're about to commit engineering resources to building something that rests on untested assumptions, the question worth asking is: what would it cost to be wrong?