Launch review
A launch review is the last gate between a build and its users: a structured
check that the thing is truly ready and that named people have said so on the
record. It rots into theater when it becomes a rubber stamp, a meeting where
everyone assumes someone else looked and no one holds the authority to stop the
train. The whole point is to keep "no" a real and cheap option right up to
launch.
Method
- Drive the review from a written readiness checklist. Functionality
verified, error budget healthy, monitoring and alerts wired, rollback tested,
legal and privacy cleared, support and docs ready, comms drafted. A checklist
turns "are we ready" from a vibe into items that are each done or not.
- Give every checklist item a named owner who signs. Not "engineering
approves" but a specific person per area: the on-call lead for operability,
privacy counsel for data, the support lead for readiness. A sign-off
without a name is a gap nobody owns.
- Require the rollback and kill switch to be exercised, not just
present. The most common launch-day failure is a revert path that was
written and never run. Demand evidence it worked in a realistic
environment, with the time-to-revert measured and recorded.
- Name one launch owner who holds no-go authority. A single person can halt
the launch, and the room knows who it is before the meeting starts. Diffuse
authority is how a known-broken launch ships, because stopping it felt like
someone else's call.
- Set explicit go, no-go, and conditional-go outcomes. Conditional-go names
the exact blockers and who confirms they cleared before traffic ramps. "We'll
fix it right after launch" is a no-go wearing a go's badge.
- Plan the ramp and the watch, not only the flip. Staged rollout by
percentage or region, the metrics that define healthy, the threshold that
triggers rollback, and who is watching during the window. A launch is not
done when it starts; it is done when it is stable.
Checks
- Does every checklist item carry a named owner who actually signed, not a team
label?
- Has the rollback been executed and timed, or only documented?
- Is there one person who can say no, and does the room know who it is?
Boundaries
Match the ceremony to the blast radius: a flagged internal rollout does not need
the review a public payments launch demands. This skill covers the go decision;
the deeper operational readiness of the service underneath belongs to the
production-readiness-review skill, and post-launch failures route to a
postmortem.
1---2name: launch-review3description: Run a launch review that gates a release behind a readiness checklist, named sign-offs, and a clear no-go authority. Use when a user-facing launch is about to ship and a bad release would be costly to walk back.4---56# Launch review78A launch review is the last gate between a build and its users: a structured9check that the thing is truly ready and that named people have said so on the10record. It rots into theater when it becomes a rubber stamp, a meeting where11everyone assumes someone else looked and no one holds the authority to stop the12train. The whole point is to keep "no" a real and cheap option right up to13launch.1415## Method16171. **Drive the review from a written readiness checklist.** Functionality18 verified, error budget healthy, monitoring and alerts wired, rollback tested,19 legal and privacy cleared, support and docs ready, comms drafted. A checklist20 turns "are we ready" from a vibe into items that are each done or not.212. **Give every checklist item a named owner who signs.** Not "engineering22 approves" but a specific person per area: the on-call lead for operability,23 privacy counsel for data, the support lead for readiness. A sign-off24 without a name is a gap nobody owns.253. **Require the rollback and kill switch to be exercised, not just26 present.** The most common launch-day failure is a revert path that was27 written and never run. Demand evidence it worked in a realistic28 environment, with the time-to-revert measured and recorded.294. **Name one launch owner who holds no-go authority.** A single person can halt30 the launch, and the room knows who it is before the meeting starts. Diffuse31 authority is how a known-broken launch ships, because stopping it felt like32 someone else's call.335. **Set explicit go, no-go, and conditional-go outcomes.** Conditional-go names34 the exact blockers and who confirms they cleared before traffic ramps. "We'll35 fix it right after launch" is a no-go wearing a go's badge.366. **Plan the ramp and the watch, not only the flip.** Staged rollout by37 percentage or region, the metrics that define healthy, the threshold that38 triggers rollback, and who is watching during the window. A launch is not39 done when it starts; it is done when it is stable.4041## Checks4243- Does every checklist item carry a named owner who actually signed, not a team44 label?45- Has the rollback been executed and timed, or only documented?46- Is there one person who can say no, and does the room know who it is?4748## Boundaries4950Match the ceremony to the blast radius: a flagged internal rollout does not need51the review a public payments launch demands. This skill covers the go decision;52the deeper operational readiness of the service underneath belongs to the53production-readiness-review skill, and post-launch failures route to a54postmortem.