Rapid Testing Cadence
Run experiments at a cadence (2-4 per week) that generates enough learning to compound, with the infrastructure to ship tests in hours not weeks.
Why
Growth learning compounds like interest: each experiment teaches something that makes the next experiment better, but only if the cadence is high enough that the learning is still fresh when the next test is designed. At 1 experiment/month, the team forgets the learning between tests and repeats patterns; at 3/week, the learning accumulates into a playbook within a quarter. The cadence requires infrastructure: a feature-flag system (ship a variant in 1h not 1d), an experiment platform (auto-split traffic, auto-compute results), and a culture of small bets (test a button color, not a full redesign). The bottleneck is rarely ideas — it is the time from idea to shipped test, which is almost always a process/infrastructure problem, not a creativity problem. Fix the pipeline and the cadence follows.
When
When the experiment framework is adopted. Build the infrastructure (flags, platform) before pushing for cadence.
How
1. Install a feature-flag system (LaunchDarkly, Statsig, or a homegrown flag table) so variants ship in 1h, not 1d 2. Build or adopt an experiment platform that auto-splits traffic, auto-computes results, and alerts on guardrail violations 3. Set a weekly cadence target: 2-4 experiments shipped per team per week; track throughput in the growth review 4. Shrink the idea-to-shipped time: template the experiment setup, pre-build common variants (headline, CTA, form length), use no-code tools 5. Favor small bets (button color, copy change, field removal) over large bets (full redesign); small bets ship in hours and teach fast 6. Run a weekly experiment planning meeting: pick 2-4 from the ICE-ranked backlog, assign owners, set ship dates for this week 7. Run a weekly experiment review: classify results, write learnings, update the playbook, pick next week's batch 8. Measure the pipeline: idea-to-shipped time, experiments/week, % won, learning/week; the bottleneck is almost always idea-to-shipped time
Example
# Rapid testing infrastructure Feature flag: LaunchDarkly (variant ships in 45 min, was 2 days) Experiment platform: Statsig (auto-split, auto-compute, guardrail alerts) Cadence target: 3 experiments/week/team # Weekly cadence (team of 3) Mon 10:00 — planning: pick 3 from ICE backlog, assign owners 1. CTA copy "Deploy now" vs "Start free" (ICE 280, @alice) 2. Remove company-name field from signup (ICE 252, @bob) 3. Add social proof to pricing page (ICE 224, @carol) Tue-Thu — ship + run (each takes 45min to set up, 3d to collect) Fri 14:00 — review: classify, write learnings, update playbook # Pipeline metrics (weekly) Idea-to-shipped: 2.1 days (was 8.3) ← infrastructure fixed this Experiments/week: 3.2 (target 3) ✓ % won: 31% (industry avg 20%) ✓ Learnings/week: 3.0 (each experiment → 1 learning) # Small bets vs large bets (this quarter) 12 small bets (copy, color, field): 4 won, avg lift +8% 2 large bets (redesign): 0 won, avg lift -2% → small bets teach faster and win more often
Common Problems
- ⚠Pushing for cadence without infrastructure; experiments take 2 days to set up, so the team ships 1/week and calls it 'rapid'.
- ⚠Running only large bets (full redesigns) that take 3 weeks to ship and teach nothing because 10 variables changed at once.
- ⚠No weekly planning/review rhythm, so experiments ship ad hoc and the cadence is whatever the loudest person demands.
- ⚠Measuring experiments shipped but not learnings generated; 5 experiments with 0 learnings is theater, not growth.
Best Practices
- ✓Install feature flags and an experiment platform first; cadence without infrastructure is aspiration, not throughput.
- ✓Favor small bets (copy, color, field) over large bets (redesign); small bets ship in hours, teach fast, and win more often.
- ✓Run a weekly planning + review rhythm; without it, cadence is ad hoc and the backlog stagnates.
- ✓Measure learnings/week, not experiments/week; the former is the output, the latter is the activity.