experiment-design git:20261019.be4abccA

Immutable. This exact content never changes and is served at /api/v1/blob/4140c6c30f0248cc.

---
name: experiment-design
description: >
  Design product experiments to test hypotheses. Use when the user says "run an experiment",
  "A/B test this", "build-measure-learn", "validate this assumption", "test this hypothesis",
  "we don't know if this will work", "minimum viable test", "lean experiment",
  or wants to reduce risk before fully building a feature
  - even if they don't explicitly say "experiment". For sample sizes, power calculations and
  significance testing, use ab-test-design instead.
---

## Overview

Based on **The Lean Startup** by Eric Ries. The core insight: startups (and product teams) don't fail from lack of execution - they fail from executing on the wrong plan. The build-measure-learn loop is how you find the right plan faster. Every feature is a hypothesis. Every release is an experiment. Validated learning - not shipped features - is the unit of progress.

## Workflow

### Step 1: State the hypothesis
Format: "We believe [action/feature] will cause [user behavior change], resulting in [metric change], because [assumption]."

Example: "We believe adding a progress bar to onboarding will cause more users to complete setup, resulting in a 15% increase in activation rate, because users abandon when they can't see how much is left."

The "because" is critical - it forces you to name the assumption you're testing.

### Step 2: Identify the riskiest assumption
Most hypotheses have multiple assumptions embedded. Find the one that, if wrong, makes the whole hypothesis collapse.

List assumptions - rank by risk - test the riskiest one first.

### Step 3: Design the minimum viable test
What's the cheapest, fastest way to test the riskiest assumption?

Ries's ladder of experiment types (least to most expensive):
1. **Customer interview** - ask 5 users if the problem exists
2. **Fake door / 404 test** - show the feature, measure click rate before building
3. **Concierge MVP** - do the job manually for a few users
4. **Wizard of Oz** - appear automated, run manually behind the scenes
5. **A/B test** - build both versions, split traffic
6. **Full release** - ship to everyone

Start as low on the ladder as possible. Only move up when the cheaper test is insufficient.

### Step 4: Define success criteria before running
Set the threshold before you see results. This prevents moving the goalposts.

"We will consider this experiment successful if [metric] changes by [amount] within [time period] with [sample size]."

### Step 5: Calculate required sample size
For A/B tests: use a significance calculator. Undersized tests produce false results.
- Minimum detectable effect: what's the smallest change that matters?
- Baseline conversion rate: what's the current rate?
- Statistical significance: 95% standard (p < 0.05)

### Step 6: Run the experiment and measure
- Don't peek at results early (peeking inflates false positives)
- Measure the primary metric and guard metrics
- Document what you observe, not what you expected

### Step 7: Extract validated learning
Whatever the result:
- **Confirmed** - assumption was right, proceed with confidence
- **Refuted** - assumption was wrong, pivot or kill
- **Inconclusive** - sample too small or test too short, iterate

Ries: a failed experiment that teaches you something is more valuable than a successful one that teaches you nothing.

## Anti-Patterns

**1. HiPPO-driven decisions instead of experiments**
Bad: "The CEO thinks we should add X, so we're adding X."
Good: "The CEO thinks X will increase retention. Let's run a 2-week experiment with 10% of users."

**2. Moving the goalposts**
Bad: Setting a 20% lift as success, seeing 8%, calling it a win anyway.
Good: Success criteria set before the experiment runs. Results are binary: met or not met.

**3. Testing too many variables at once**
Bad: Redesigning the entire onboarding and A/B testing it.
Good: Change one variable per experiment. Otherwise you can't attribute the result.

**4. Skipping the concierge step**
Bad: Building a full automated feature to test an unvalidated assumption.
Good: Do it manually for 10 users first. If the manual version doesn't work, the automated one won't either.

## Quality Checklist

- [ ] Hypothesis follows "We believe X will cause Y because Z" format
- [ ] Riskiest assumption identified explicitly
- [ ] Minimum viable test chosen (as low on the ladder as possible)
- [ ] Success criteria defined before running
- [ ] Sample size calculated for quantitative tests
- [ ] Guard metrics defined (what must not get worse)
- [ ] Validated learning documented regardless of outcome