Path: Product Manager | Time: 15 min
<aside> 💡
TL;DR: Designing an experiment is not "set it up and let it run." You need to answer three questions before anything goes live: What am I testing? Can I actually test it? And which test design fits this situation? Get these wrong and you waste weeks.
</aside>
You have a hypothesis from F3. Now you need to turn it into an experiment that will actually produce a reliable answer.
Not everything can be A/B tested. Before designing the experiment, check:
🖼️ IMAGE PLACEHOLDER
The Experimentation Compass: decision tree starting with "Can you randomize at the individual user level?" branching into A/B test, switchback, quasi-experimental, and pre/post designs. Adapt from Experimentation Compass JPG.
| Design | When to use | Traffic needed | Duration |
|---|---|---|---|
| A/B test | User-level randomization possible, enough traffic | High (depends on MDE) | 2-4 weeks |
| A/B/n test | Compare 3+ variants simultaneously | Higher (split across variants) | 2-4 weeks |
| Switchback | Cannot randomize at user level (pricing, marketplace) | Medium | 4-8 weeks |
| Quasi-experimental | Cannot randomize at all (regulatory, infrastructure) | Varies | Varies |
As a PM, you do not need to design switchback or quasi-experimental methods yourself. But you need to know they exist, so you do not abandon testing when standard A/B is not possible.
Test duration is a function of traffic volume, MDE, baseline metric value, and number of variants. Your data scientist runs the calculation. Your job is to set the MDE: what is the smallest effect worth shipping?
A good rule of thumb: if the calculated duration is longer than 4 weeks, reconsider. Either increase the MDE, increase traffic allocation, or consider whether this is the right test to run right now.
Audience. Who sees this experiment? Define inclusion and exclusion criteria.
Traffic allocation. 50/50 gives maximum statistical power. Smaller treatment allocations (e.g., 10/90) limit risk but increase duration.