The launch checklist
Everything that has to be true before a feature goes to everyone, with a name and a date on every line.
The week before a feature that's been in flags or beta goes to 100 percent.
- 1
Engineering readiness
Confirms the thing works at full scale, not just for the slice it's been running for.
What it asksWhat has to be true about performance, error rates, and infrastructure before 100 percent, and who confirms it?
Filled inError rate on the bank-linking endpoint stays under 0.5 percent at 10x current flag traffic in a load test. Dev confirms by Thursday 3pm, two days before the Saturday flip.
How it goes wrongTesting at flag scale and assuming it holds at full scale. The flag ran fine at 10 percent because the database connection pool wasn't the bottleneck yet, and nobody finds that out until launch day.
- 2
Support readiness
Makes sure the team fielding tickets on day one already knows what changed and what the known issues are.
What it asksWhat does support need to know before this ships, and has someone actually walked them through it?
Filled inPriya's team gets a 20 minute walkthrough of the new bank search on Wednesday, plus three canned responses drafted from the beta's actual tickets. Priya confirms her team is ready by Friday noon.
How it goes wrongDropping a release notes doc in Slack the morning of launch and calling it support readiness. Nobody reads it, and the first ticket becomes a fire drill instead of a known answer.
- 3
Data and monitoring
Confirms someone will notice if it's broken, and how fast.
What it asksWhat dashboard shows this is working, who's watching it in the first 48 hours, and what number triggers a page?
Filled inAna's dashboard tracks bank-linking success rate and search latency in real time. Ana watches it directly for the first 4 hours after the Saturday flip, then Dev is on call. A drop below 90 percent success for more than 15 minutes pages Dev.
How it goes wrongBuilding the dashboard but nobody is assigned to watch it in the critical first hours, so a regression that started at 9am is discovered at 9am the next day.
- 4
Comms and rollback
Decides in advance who says what if it goes wrong, and how fast the thing can be turned off.
What it asksWho can pull the flag, how long does that take, and who tells the team if it happens?
Filled inDev can kill the flag in under 2 minutes from the dashboard. If it's pulled, Maya posts in the all-hands channel within the hour so support isn't blindsided by a feature that silently disappeared.
How it goes wrongThe flag can technically be reverted, but only by one engineer who's on holiday launch week. The rollback plan exists on paper and nowhere else.
Take the whole thing
# Launch checklist: [feature] ## Engineering readiness - [ ] Item ............................ Owner: ....... Date: ....... - [ ] Item ............................ Owner: ....... Date: ....... ## Support readiness - [ ] Item ............................ Owner: ....... Date: ....... - [ ] Item ............................ Owner: ....... Date: ....... ## Data and monitoring - [ ] Dashboard live and checked ....... Owner: ....... Date: ....... - [ ] Alert threshold set .............. Owner: ....... Date: ....... ## Comms and rollback - [ ] Rollback tested, time to revert: ....... - [ ] Who is told if it's pulled: ....... Launch date: Full rollout percentage target:
The PRD that survives contact with engineering
One page. Four sections engineers actually read before they start arguing about scope.
The signal log
One row per quote. A structured way to hold raw feedback without losing the exact words.
The opportunity tree, on one page
Outcome, opportunity, solution, experiment. The map from what you're chasing down to what you're testing this week.