Delivery
Launch checklist
Everything that has to happen from two weeks out to one week after release, grouped by when it falls due, each line with a named owner and a go or no go decision on the day.
What it is
A launch checklist is the set of things that have to be true before a change reaches customers, each with a name and a date against it. It exists because launches fail in the same handful of ways every time. Support did not know, the documentation was not updated, the metric was never instrumented, or nobody agreed what would make you roll it back.
Checklists work in aviation and surgery for a reason that carries over. They do not make anyone smarter. They stop competent people skipping a step under time pressure, which is exactly the condition a launch creates.
The row that earns its place is the rollback criterion. Deciding in advance what result would make you undo the change is far easier than deciding it at nine in the evening while a number falls.
When to use it
- A release affects customers who will notice, and more than one team has to do something for it.
- Your last launch went out and support heard about it from a customer.
- You are releasing to a cohort or a segment first and the sequence needs writing down.
- A contractual or regulatory commitment depends on the change landing correctly.
What is in it
- Two weeks before
- Three days before
- Go or no go, on the day
- Launch day
- First 48 hours
- One week after
The template
Release owner [name] / Target date [date] / Blast radius [who is affected and how many] / Rollback plan [one line, and where the runbook lives]
Two weeks before
- The measure of success is written down with a baseline, a target and a read date
- Instrumentation for that measure is live in staging and verified against a known number
- Support has the release note draft and has told you which three questions they expect
- Sales and customer success know what changes for accounts already using the old behaviour
- Pricing, terms and any contractual wording are signed off if the change touches them
- Accessibility check passed, including keyboard only and screen reader paths
- Load or scale test run against the expected peak, with the result recorded
- Named customers agreed for the first cohort, and told when it is happening
Three days before
- Feature flag in place, with the off switch tested from production
- Alerts configured on the guardrail metric, routed to a person and not to a channel
- Help centre article published or scheduled
- In product messaging queued, with the audience filter checked twice
- Data migration dry run completed against a copy of production
- Rollback rehearsed by someone other than the person who wrote the change
Go or no go, on the day
Hold it as a five minute call. Each owner says go or no go in their own words, and one no go stops the release without further discussion.
| Area | Owner | Go or no go | Note |
|---|---|---|---|
| Engineering readiness | [name] | ||
| Support readiness | [name] | ||
| Data and migration | [name] | ||
| Commercial and legal | [name] |
Launch day
- Enable for the first cohort at the agreed percentage
- Watch the guardrail metric for the first hour, with a named person on it
- Confirm the success measure is recording events, not just that the feature is on
- Post the release note internally, with the rollback instruction at the top
- Ramp to the next cohort only after the hold period agreed above
First 48 hours
- Read every support ticket mentioning the change, not the summary of them
- Compare the guardrail against the same weekday last week rather than yesterday
- Decide to hold, ramp or roll back, and write down which one and why
One week after
- Read the success measure against its target and record the number
- Remove the flag if the change is staying, and delete the old path
- Note the one thing that nearly went wrong, and add it to this checklist
The last line is the one that keeps the checklist alive. A list that never changes after a release stops describing your product and becomes a ritual, so cut any line that has passed unremarked for three releases running.
Questions people ask
- Do small changes need a checklist?
- No. A change behind a flag that is already live does not, and working thirty rows for a one line fix teaches people to tick boxes without reading them. Keep it for launches customers will notice.
- Who owns the checklist?
- One named person, usually the product manager. Shared ownership means nobody notices the row that never got ticked.
- When should it be started?
- Two or three weeks before the date, so the rows that depend on other teams have time to move. A checklist opened the day before is a record rather than a plan.
- What happens to it after the launch?
- Read it in the review and change the rows that did not help. A checklist that never changes has stopped describing how you actually launch.