Fix the dates before you pick any test
Put four dates in the calendar for the whole year. Week one is for choosing and launching. Weeks two and three are for running. Week four is for closing and writing up. Add a 30-minute review on the last working day of the month.
The calendar matters more than the tests. A mediocre test closed on time teaches you more than a brilliant one that drifts for ten weeks. If a date moves, move the test, not the date.
Pick tests from the backlog by capacity
Open the ranked list you built in Building your backlog. Take the top item and work down. Stop when you run out of capacity, not when you run out of enthusiasm.
For a small team, two to four live tests at a time is a sensible ceiling. They must not touch the same page, audience or email list, or you cannot tell which change caused which result. Pick at least one cheap, fast test so the month always produces a result.
Run a pre-flight check on launch day
Every test passes the same checklist before it goes live. If one box is empty, it does not launch.
- The hypothesis is written, as set out in Creating strong hypotheses.
- The success threshold is a number, written down before launch.
- The run length or sample size is fixed in advance.
- Tracking has been tested with a real click or form submission.
- One named person owns the test.
The mechanics of building the test live in Setting up experiments. Tools such as VWO or Google Analytics do the measuring, but the checklist is yours.
Keep a one-line record for every live test
Check for breakage once a week, nothing else
In weeks two and three, look at each test once, on a fixed day. You are checking that it is working, not whether it is winning. Is traffic splitting roughly as planned? Is the conversion event still firing? Did anything else change on the page?
Do not read the result and do not stop a test because it looks good. Early numbers are noisy and a test stopped on a lucky day is a false win.
Close every test on its end date
On the end date, stop the test and analyse it using the method in Analysing and acting on results. Then make exactly one decision: ship it, kill it, or extend it once with a new end date.
Extending is allowed only when the sample was too small and you can say why. A second extension is a sign you are hoping, not testing.
Write the learning in five lines
Fill in the log row and add a short note: what you expected, what happened, the decision, what you now believe about your buyers, and the next test it suggests. Five lines is enough.
An inconclusive result still goes in the log. "No measurable effect at this sample size" is a result, and it stops someone running the same test next quarter. Feed the notes into Compound learnings across experiments.
Hold a 30-minute monthly review
On the last working day, go through three questions. What did we close? What did we learn? What goes live next month? Pull the next tests from the backlog in the same meeting, so week one starts with a launch, not a debate.
If you have not re-scored the backlog this quarter, schedule it using Reprioritise backlog by impact and effort.
Common mistakes
- Launching more tests than you can keep apart.
- Changing the page, the offer or the audience while a test is running.
- Closing early because the number looks good.
- Skipping the write-up in a busy month, which is the month it matters most.
- Letting a lost test count as a failure, so people stop proposing bold ideas.
How you know it works
You close at least two tests every month, whatever the outcome. Every closed test has a decision and a five-line note. Nobody can say "I think we tried that once". After three cycles, your backlog contains ideas that reference earlier results, and your first-week launches take under an hour because the checklist is routine.
