Complete firstAARRR bottleneck
The funnel bottleneck is identified with data (Acquisition, Activation, Retention, Referral, or Revenue).
Without: Without an identified bottleneck, experiments land on locations with no leverage and ROI stays low.
RunsheetMarketing
Growth Experiment
ComplexityMedium
Time1-2 Wochen
Participants1-6
FormatWorkshop + async
MaturityEstablished
01
Prerequisite
What needs to be finished first
Complete firstICE scoring
A hypothesis backlog scored by Impact, Confidence, and Ease is available so prioritization is clear.
Without: Without prioritization, favorite ideas run instead of the strongest hypotheses, and learning rate drops.
02
Preparation
What needs to be ready before start
Materials
Experiment card template (hypothesis, goal metric, setup, duration, sample size, owner, learning goal), hypothesis backlog (Notion, Trello, or Linear), tracking system, Slack channel for updates.
People / roles
One growth owner; engineer for implementation (including no-code setup if needed); data analyst for evaluation; marketing or content representative for reach experiments; reviewer for cards.
Pre-read
Bottleneck stage and baseline; current knowledge around the hypothesis; available channels; budget per experiment; legal constraints (GDPR, advertising).
Time needed
1-2 weeks per experiment, up to three in parallel
Setup
Fix the card format. Weekly cadence for kick-off, mid-check, and review. Kanban board with columns Backlog, Ready, Running, Evaluation, Done. Definition of done: lessons learned documented.
03
Core question
The one question this method answers
What is the smallest intervention at the bottleneck that produces an interpretable learning result for the hypothesis within one week?
04
Flow
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Hypothesis and card | 60 min | Write the hypothesis in the format "If we do X, then Y happens because Z." Add goal metric, secondary metric, minimum effect, sample size, duration, owner, and learning goal to the card. | If the hypothesis contains six sub-changes, it is no longer an experiment but a project. Reduce to one change, otherwise no learning occurs. |
2Phase 2: Build or fake | 1-5 days | Choose the minimal implementation: feature flag, landing-page variant, manual Wizard of Oz test, or email sequence. Select the fastest setup that still allows learning. | If implementation takes more than five days, the experiment is too large. Consider a spike or fake door in front to test the hypothesis more cheaply. |
3Phase 3: Run it | 1-3 weeks | Run the experiment live. Perform a daily health check (tracking active, no crashes, no support spike). Avoid mid-check decisions on the goal metric before sample size is reached. | A health check is not evaluation. Someone who checks the goal metric daily creates peek bias. Separate strictly: health is whether it works technically; evaluation is whether it works. |
4Phase 4: Evaluate | 1 day | Validate results against goal and counter metrics. Decide: Double Down (scale), Iterate (adjust variant), or Kill (hypothesis rejected). Document lessons learned. | A Kill decision is also valuable. The key point is what we know now that we did not know before. Without a learning entry, the experiment is wasted. |
5Phase 5: Next hypothesis | 30 min | Store lessons in the knowledge base. Update hypothesis backlog: increase confidence for validated assumptions, reduce it for rejected assumptions. Plan next experiment. | Backlog updates are the bridge to better learning. If lessons do not feed into later confidence scoring, the organization learns almost nothing per quarter. |
05
Artifact
What comes out at the end
Form
Experiment card containing all setup fields plus results, decision, lessons learned, and implementation links. Quarterly aggregated view: running and completed experiments, win rate, learning gains by funnel bottleneck.
Versioning / ownership
Track per experiment ID, date, and bottleneck tag. Store lessons learned in the knowledge base, not in archived cards. Quarterly recap includes win rate, key learning, and follow-up hypotheses.
Tool alternatives
- Notion or Confluence database with card template
- Trello or Linear with custom fields
- GrowthHackers Projects or Mooncamp
- Airtable with win-rate and throughput reports
experiment-plan-markdown.md
Short plan for hypothesis, test design, success criteria, and decision.
Experiment Plan
Hypothesis
We believe that ...
Target audience
Who are we testing for?
Test design
What exactly will participants or users do?
Success criterion
We count the test as positive if ...
Risks and limits
What can the test not prove?
Decision afterward
If positive: ... If negative: ...
Owner and date
...
06
Example output
Concrete filled scenario, fictional example
growth-experiment-beispiel.md
Concrete filled scenario, fictional example
Growth Experiment EXP-2026-019 - Personalization for onboarding email sequence
Bottleneck: Activation (AARRR stage), baseline 6.8%.
Hypothesis: If the onboarding email sequence is tailored to one of three use cases in the first three emails (daily booking vs. monthly subscription), then activation increases from 6.8% to 8.5% in seven days because users find the right workflow faster.
Setup: Two sequences (Use Case A, Use Case B) instead of one generic sequence. Distribution based on onboarding response. Implemented in Customer.io.
Sample: 1,800 new users (900 generic vs. 900 use-case-specific).
Duration: 14 days (weeks 18-19).
Results
- Activation: Generic 6.9%, Use-Case 9.1%, delta +2.2pp, p=0.008.
- Mail 1 open rate: Generic 41%, Use-Case 53%.
- Counter metric (unsubscribe): 1.1% vs. 1.0%, no effect.
Decision: Double Down. Use-case sequence becomes standard from 25.05. Next hypothesis: test additional use-case segments (team coworking).
Lessons learned: Personalization works for Activation even without behavioral data once use case is captured during onboarding. Confidence that "use case is captured" is now 8/10.
07
Pitfalls
Recognize symptoms and steer against them
Trap
Experiment becomes a project
Symptom
Setup takes six weeks and multiple variables change simultaneously.
What to do
Reduce to one variable. If that is not possible, split into sub-experiments. Two small tests in sequence are better than one large experiment without learning.
Trap
Favorite idea over hypothesis ranking
Symptom
Experiments are driven by gut feeling, and ICE scoring is bypassed.
What to do
Enforce ranking with ICE or RICE. Top three hypotheses move forward, all others wait. Exceptions only with documented justification.
Trap
Health check is mixed with evaluation
Symptom
Team watches goal metric daily and decision pressure appears before sample size is reached.
What to do
Split dashboard into health (tracking, crashes, sample progress) and evaluation (blocked until sample period ends). Set tool configuration to enforce discipline.
Trap
Lessons stay on the card
Symptom
After three months, an experiment runs again that was already tested before, and nobody remembers it.
What to do
Maintain a separate, searchable knowledge base with tags per bottleneck. Before each new experiment, search for similar hypotheses.
Trap
Missing counter metric
Symptom
Acquisition increases, but Activation or retention drops undetected.
What to do
Use at least one lagging counter metric per experiment. Decision rule: no Double Down if a significant counter metric worsens, even if the primary metric is positive.
08
Stop criteria
Done signals checkable in under a minute
Baseline volume is insufficient for minimum sample size in four weeks.
Bottleneck is not identified, making experiments blind guesses.
Hypotheses are not prioritized, and the backlog becomes a wish list.
Counter metrics are missing or not tracked.
Lessons learned are not documented, so the organization does not learn across experiments.
No named owner per experiment, making accountability diffuse.
More than three experiments run at the same funnel stage simultaneously, causing uncontrolled interference.
Finished the runsheet?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.