Experimentation

You have a goal - raise activation - and five ideas for how to get there. The designer wants a cleaner onboarding, the PM wants a checklist, someone swears a welcome video is the answer. Everyone's confident, nobody's sure, and in most teams the idea that ships is the one argued loudest. Experimentation replaces that with something better: you let real users vote with their behavior.

Learn on the move: press play and turn your commute, walk or drive into time that grows your design career.

Listen to the full Experimentation course on DesignPath
Share
Share

The third principle of growth design was "run experiments deliberately." This module is that principle in full. The move is always the same three beats - turn a goal into a testable bet, run it safely, and read the result honestly - and each is easy to get wrong in a way that quietly wastes months.

One boundary up front: this is experimentation as a growth practice - how to form a hypothesis, run it, and decide what to do. The statistical craft underneath - sample sizes, significance, clean test setup - lives in the Research domain's A-B Testing and Experimentation. We'll lean on it, not repeat it.

Hypotheses - Turning Goals Into Testable Bets

"We should make onboarding better." It sounds like a plan, but you can't test it - there's no way for it to be wrong, which means there's no way for it to teach you anything. A hypothesis is what fixes that: it turns the wish into a bet reality can settle. Everything downstream - the test, the read, the decision - depends on getting this sentence right.

The Shape of a Good Hypothesis

The reliable format has three parts:

We believe [this change] will [this effect on this metric] because [this reason].

For example: "We believe adding a progress bar to onboarding will raise step-3 completion from 45% to 60% because users abandon when they can't see how much is left."

Each part earns its place. The change is one specific thing you'll do. The effect names a metric and a direction and, ideally, a number - that's what makes the bet falsifiable. The because is your reasoning, and it's the part people skip; without it, a losing test teaches you nothing, but a stated belief that turns out wrong updates how you think.

Anchor It to a Funnel Stage

A hypothesis floating free of the funnel is hard to judge. Tie it to a stage - this is an activation bet, that's a referral bet - so you know exactly which metric it's supposed to move and can ignore the noise everywhere else. It's the first growth principle, "think in funnels," applied to your bets.

One Change at a Time

The discipline that makes results readable: change one variable. If you redesign the screen, reword the button, and add a video all at once and activation rises, you've learned that something worked but not what - and you can't repeat it. One change per hypothesis keeps cause and effect legible.

Prioritize Before You Run

You'll always have more hypotheses than time. Rank them the same way you'd rank any backlog - by likely impact, your confidence, and the effort to run them - and test the strongest first. It's the exact RICE-style thinking from Prioritization, pointed at experiments instead of features.

Pro tip: If you can't state the metric your hypothesis moves, you don't have a hypothesis yet - you have a preference. Stop and find the number before you build anything.

Where AI Helps

Prompt: "Here's my growth goal and funnel stage: [describe]. Write five hypotheses in 'we believe [change] will [effect on metric] because [reason]' form. For each, name the single metric it moves and flag any that secretly change more than one variable."

AI drafts and pressure-tests the hypotheses; you supply the reasoning and the numbers.It's quick at generating well-formed bets and catching multi-variable sneaks, but the because - your real theory of why users behave this way - and the target numbers come from your knowledge of the product, so those are yours.

Found this useful? Pass it on.
Share