Turning a research finding into a hypothesis you can test

Research produces findings. A finding is a statement about your customers that the evidence supports, for example that people reach the basket and abandon it because the delivery cost only appears at the end. That’s useful, but you can’t run it as a test yet. It tells you there’s a problem without telling you what to change or how you’ll know the change worked. The step in between is the hypothesis, and a lot of research stalls right there.

Getting from one to the other is deliberately mechanical. Take the finding and put it through the if-then-because shape. If we show delivery cost on the product page, then basket completion will rise, because the sticker shock is happening late and people feel misled. The if is the change, the then is the metric you’ll watch, and the because is the mechanism, your claim about why the change should move the number. You need all three. The because is the one people most often leave out, since it commits you to a claim you could be wrong about.

What separates a hypothesis from a finding is falsifiability. A finding can be true and still go nowhere. A hypothesis has to be specific enough that a result could contradict it. No result could prove “improve the checkout” wrong. If completion rises, the checkout improved. If it falls, something masked it. If it’s flat, run it longer. Because nothing can contradict it, it can’t teach you anything. A usable hypothesis names a single change, a single metric and a mechanism, so afterwards you can look at the because and say plainly whether it held up.

There’s a trap on the other side too, where the insight gets used as a licence. Research shows people find the delivery options confusing, so someone declares we should redesign the whole product page. That is four changes resting on one insight. A finding supports a specific claim and not much beyond it. If the change you want is bigger than the insight that justified it, you’re reverse-engineering again, working back from what you already wanted to build.

So go in a straight line: the finding, then the if-then-because, then the sentence that would prove it wrong, and only then the test. If you skip the last two steps, the research ends up as an anecdote and the backlog goes back to being a list of things people would like to try.

Put it to work

Take one finding from your research and write it as an if-then-because statement. Then write the sentence that would prove it wrong. If you cannot, it is not ready.

Your answer

Show the worked example

There is no right answer. Write yours first, then compare.

Sources

1. CXL, From Insight to Hypothesis