How to Write an Experiment Brief That Actually Gets Approved

Pull up the last five experiment briefs your team submitted. For each one, check whether it includes a falsifiable hypothesis with a 'because' clause, a named primary metric with a baseline, an evidence base that cites specific data or research, and a decision protocol written before the test launched stating what would happen if it won, lost, or was inconclusive. How many of the five pass all four checks? If the answer is fewer than three, the problem is probably not effort. It is that nothing in your process enforces these elements at the point of capture.

A complete experiment brief answers seven questions.

1. What are we testing and why?

State the change and the reasoning. Include evidence, not just the request.

2. What evidence supports this?

List the specific data, research, or past experiment results.

Checkpoint: Take the experiment your team is currently planning. Can you trace it back to a specific piece of evidence? Not 'we think this is a problem' but an actual data point, research finding, or past experiment result with a date and a source?

3. What is the hypothesis?

If [change], then [measurable outcome], because [reasoning].

Checkpoint: Look at your team's experiment template right now. Does it have a dedicated field for the 'because' clause? Or is the hypothesis a single free-text box where people can write whatever they want?

4. What are we measuring?

Primary metric (one only), secondary metrics, guardrail metrics. For each, specify how it is measured, the current baseline, and the minimum detectable effect.

5. How will we run it?

Audience, traffic allocation, duration, technical implementation, risks.

6. What is the decision protocol?

What happens if the variant wins, loses, or is inconclusive? Written before launch.

Checkpoint: Of the experiments your team completed in the last quarter, how many had a decision protocol written before the test launched? Not after. Before. If the answer is 'none' or 'I don't know', then your team is designing experiments to generate data, not to inform decisions.

7. How does this connect to business objectives?

Explicit link to a current objective.

Checkpoint: Look at your current experiment backlog. What percentage of planned tests have an explicit, documented link to a current business objective? Not an implied connection. A stated one.

What Good Looks Like

A strong experiment brief reads like a case being made, not a form being filled in. If you worked through the checkpoints, you have probably noticed a pattern. The quality of each element depends less on individual discipline and more on whether your team's template and process enforce it at the point of capture.