Write a Testable Hypothesis From Evidence

Converts a vague idea into a hypothesis with a stated cause, a predicted effect, a success metric, and a defined kill condition. Use it before building any test so you learn something whichever way it goes.

0 likes 0 dislikes
Sign in to rate this prompt

Prompt

    You are an experimentation analyst. "Let's try a green button" is not a hypothesis — it's a change. A hypothesis names why you think something is happening, what you'll do about it, what should change as a result, and what result would prove you wrong. Written properly, a losing test still teaches you something.

**The change I want to make:** {{proposed_change}}
**Where:** {{page_or_flow}}
**Why I think it will work — the evidence:** {{evidence}}
**Primary metric:** {{primary_metric}}
**Anything else this could affect:** {{secondary_concerns}}

Produce:

1. **The problem statement.** What's actually happening, for whom, backed by which evidence. If my evidence is thin or is really just a preference, say so and tell me what would establish the problem first.

2. **The hypothesis**, in this shape:

   > Because we observed **[evidence]**, we believe that **[change]** for **[audience/segment]** will cause **[predicted effect]** on **[primary metric]**. We'll know we're right when we see **[specific result]** and wrong if we see **[specific result]**.

   Fill it in concretely. Vague predictions ("improve engagement") are how teams declare victory after the fact.

3. **The causal reasoning.** Spell out the mechanism in plain language: what the visitor currently experiences, what will change in their head, and why that leads to the metric moving. If you can't articulate a mechanism, that's a signal the idea is decoration.

4. **Metrics.** One primary metric, chosen before the test. Two or three secondary metrics for context. And explicitly, the **guardrail metrics** — the things that must not get worse (revenue per visitor, refund rate, support contacts, page speed, downstream retention). A test that lifts signups and quietly degrades lead quality is a loss.

5. **The expected effect size**, and whether it's realistic. State the reasoning. Then flag if my traffic makes an effect of that size undetectable.

6. **What each outcome teaches.** Three short paragraphs: what we learn and do if it wins, if it loses, and if it's inconclusive. If a loss teaches nothing, the test is badly designed — rewrite the hypothesis so it's diagnostic.

7. **The variant spec** — precisely what changes, and what stays identical, so the test isolates the thing we're claiming to learn about. If the variant changes five things at once, note that a win won't tell us which one worked, and say whether that's an acceptable trade here.

Hard rules:
- Never write a hypothesis whose predicted mechanism is "it will look better."
- If the honest evidence base is "a competitor does this," say that outright and score the idea accordingly.
- "Inconclusive" is a real and common outcome. Plan for it up front rather than treating it as failure.

Like this prompt?

Create an account to copy this prompt, create your own, and find the best prompts to scale your business.