Skip to content
Product Lifecycle Templates

Launch Coordination Checklist

beta  ·  Family standing-standards  ·  Phase undefined  ·  Sizes lean, full  ·  ~4,650 tokens

The standing list a team consults before it ships an externally visible change, so that readiness does not depend on who happens to be asking the questions. Grouped checks paired with an owner and a go/no-go gate, plus a rollout, a rollback trigger, and a review trigger decided before the launch rather than argued during it.

The short card. Why the document is shaped this way, and the argument behind every rule here, is in launch-coordination-checklist_companion.md. A fully worked instance is launch-coordination-checklist_example.md.

When to use

Section titled “When to use”
  • You are about to ship a change that is externally visible, and you want readiness to depend on the checklist, not on which engineer happens to be asking the questions that day.
  • More than one launch will consult this same list. It is a standing instrument, reused launch after launch, the same way one Google Launch Coordination Engineer ran 350 launches through one checklist over 3.5 years, not a document invented fresh for this one launch.
  • You want the conditions that block a launch, and the condition that reverses it, settled before the launch rather than argued while it is happening.
  • The launch reaches past one team, support, documentation, or a public announcement, and you need to name who is prepared before those audiences learn about it.
  • You are not sure yet what counts as a launch for your team, or whether every launch needs the same amount of scrutiny. Scope and Launch Classes exists to answer exactly that.

When NOT to use

Section titled “When NOT to use”
  • The change is small and stays inside one team. The paired pm-skills skill for this type names the failure mode directly: “a launch checklist adds ceremony without value; track it in the sprint instead.” If nothing here would change what you check, you are paying ceremony for no readiness gain.
  • You are responding to a situation that has already happened, not preparing for one that has not. A checklist is linear: it verifies known, named prerequisites before a decision point. A runbook has to encode branching judgment instead, what to check first, what to avoid, when to branch, and when to escalate. If the document you are writing needs that kind of branching, write a runbook.
  • You want a standing quality bar every unit of work is judged against, not a readiness gate for one external launch. That is a definition of done, an agreed-upon set of items that must be completed before a project or user story can be considered complete. A definition of done is necessary but not sufficient input to a launch; it is not a substitute for this document, and this document is not a substitute for it.
  • You need a dated, per-launch execution document with owners and target dates for one specific release. That is what applying this standing checklist produces, not the checklist itself. If your team already tracks that per-launch work in an issue tracker, owners, deadlines, and status per task, adding a second, parallel document duplicates what the tracker already shows rather than adding readiness.
  • You only need to draft the customer-facing announcement of what shipped. That belongs in a release notes document. This checklist tracks that the right people saw the announcement before it went out, it does not draft it.

Pick a variant

Section titled “Pick a variant”

Lean (five sections) is the default: Scope and Launch Classes, Readiness Checks, Rollout and Rollback, Go/No-Go Criteria, Review Trigger. It keeps the engineering-readiness core intact and carries the launch’s decision-maker inside Go/No-Go Criteria rather than giving roles their own section. The type’s own origin, Google’s launch checklist, is engineering-only, and a small launch needs to know who decides more than it needs a roster.

Full (seven sections) adds Roles and Decision Authority and Launch Communications. Both additions are cross-functional rather than engineering-internal. Move to full when at least one of these is true:

  • more than one role could plausibly make the go/no-go call, so naming a single decision authority in writing, separate from Go/No-Go Criteria, is worth its own section;
  • the launch reaches support, documentation, or a public announcement, not just engineering, so someone needs to be told what to prepare before the public is;
  • the launch is regulated or cross-functional enough that legal, compliance, or marketing stakeholders need a named place in the document rather than an assumption that someone told them.

Every lean heading appears in full unchanged, in the same order. Growing from lean to full is additive; you never reorder or rename a section you already filled in. The one content change that travels with the move: Go/No-Go Criteria stops naming the decision-maker itself once Roles and Decision Authority exists to carry that role.

Quality rubric (self-grade)

Section titled “Quality rubric (self-grade)”

Score each 0, 1 or 2. Full below 10 out of 14 ships a checklist that a launch can clear while still carrying the exact kind of gap a 2012 trading-system deployment failure exposed: no named second reviewer, no rollback trigger decided in advance, or a go/no-go call nobody in particular owns. Lean is scored on five of these rows only (see the scope table below), and below 7 of 10 a lean checklist can still clear a launch with no rollback trigger decided in advance, or with a go/no-go call nobody in particular owns.

# Criterion 0 1 2
1 Launch class criteria No classes named, or every launch this team has ever logged lands in the same one Classes are named, but the criterion for landing in one is a feeling, “standard launch,” nobody else could check Each class has a criterion a second person could apply without asking the author, and names which sections of this checklist that class actually requires
2 Named decision authority (full) No decision-maker named, or a channel or distribution list stands in for one A role is named, but no other reviewer is required in writing before that role’s call A specific role is named as the one who calls go or no-go, and a separate reviewer is required in writing, so no single unreviewed person can approve the launch alone
3 Actual-status evidence Rows carry a question and nothing else, or the evidence field just says “done” or “complete” Some rows name what evidence answers the question and who owns it; others stop at a bare status word Every row names what actually answers the question, who owns answering it, and the specific failure the check exists to catch
4 Advance communications (full) Section missing, or it only describes the public announcement An audience is named, but not what they are told before the launch, or the timing is “at launch” Support and documentation are told what they need before the launch, with a stated timing, and the customer-facing announcement is explicitly pointed at release notes instead
5 Measurable rollback trigger No trigger stated, or “roll back if it looks bad” A trigger is named, but as a description rather than a number, or no one is named who can pull it without asking A specific, measurable threshold is stated, and a named role can pull it without further approval
6 Owned, expiring exceptions Criteria are pass or fail only, with no way to record an accepted exception Exceptions can be recorded, but absent or delayed evidence is treated the same as a pass, or an exception carries no expiry Absent evidence is explicitly not counted as a pass, and every accepted exception names who owns it and when it expires
7 Event-based review trigger Only a calendar cadence, or nothing at all An event is named, but with no owner, or no stated next action A specific event is paired with a named owner, whose first move is to investigate which check should have caught it, before deciding whether the fix is a new line item

Which rows apply to what.

Document Rows Maximum Score against
full all 7 14 10
lean 1, 3, 5, 6, 7 10 7

Rows 2 and 4 are scored only against full. Lean ships neither Roles and Decision Authority nor Launch Communications, it folds the decision-maker into Go/No-Go Criteria instead, so grading it on those two rows would penalise the choice of variant rather than the quality of the document.

The test behind every cell above: could someone satisfy it without improving the document? A row that counted readiness-check rows, named audiences, or listed classes would reward padding. Every cell instead asks whether a specific piece of evidence exists, and whether a second person, not the author, could check it without asking who wrote the document.

Named anti-patterns (the usual wrecks)

Section titled “Named anti-patterns (the usual wrecks)”
  1. No named second reviewer. A 2012 trading-system deployment failure shipped because no written procedure required a second technician to review the deployment, so nobody caught that old code had not been removed from one of the servers. Roles and Decision Authority exists to make that requirement explicit rather than assumed.
  2. No rollback trigger decided in advance. The same incident’s emergency response made things worse because there was no kill switch decided ahead of time. A trigger argued for the first time during an incident is functionally the same as having no trigger at all.
  3. Unbounded checklist growth. Left uncurated, a checklist can grow to the point that Google’s own history records: at one point, adding a new question to its launch checklist required approval from a vice president just to control the list’s size.
  4. A per-incident append loop. Adding a new checklist line item for every incident that goes wrong, with no check on whether the mechanism actually failed, produces a checklist so large nobody can trace a given line back to the reason it exists. The fix is to ask which specific check should have caught the incident, not whether an incident happened at all.
  5. A response that says “done” instead of the actual status. Aviation checklist design exists precisely against this failure: a completed item’s response should portray its actual current status or value, not a bare confirmation that something was attempted.
  6. Treating an absent or delayed piece of evidence as a pass. Missing evidence is not the same thing as a satisfied check. A criterion with no evidence yet is unknown, and unknown is not the same as green.
  7. An executive override with no owner. A deadline silently replacing a hard gate, with nobody named as the one who accepted that tradeoff, is the specific failure Go/No-Go Criteria’s exception field exists to prevent.
  8. Readiness treated as permanent once granted. A service, or a launch, that was ready three months ago might no longer be ready. Readiness is version-bound: a change to the product, the environment, or a dependency can invalidate an earlier answer without anyone updating the record.

Pairing with your process

Section titled “Pairing with your process”

This bundle ships in the standing-standards family alongside definition-of-done, definition-of-ready and runbook. All four are agreed once and consulted repeatedly rather than authored per occasion, but they answer different questions: a definition of done is a standard a team is judged against, a definition of ready is the agreement on when a backlog item can be pulled into a sprint, a runbook is a procedure executed once a known situation has already happened, and this checklist is consulted at the moment of a launch decision that has not happened yet. Keep the boundaries where they belong: this document does not certify that a unit of work is finished, and it does not tell a responder what to type once something has gone wrong. Where your team already runs the paired pm-skills deliver-launch-checklist skill for one specific release, this standing list is what that per-launch document draws its Go/No-Go Criteria and Rollback Plan from; update this file when the checklist itself needs to change, not every time a launch happens.

The artifacts

Section titled “The artifacts”

launch-coordination-checklist_template-lean.md · ~4,650 tokens

---
title: "{{checklist_title}}"
team_or_product: "{{team_or_product}}"
owner: "{{owner}}"
status: "{{status}}"
last_updated: "{{date}}"
doc_type: launch-coordination-checklist
size: lean
source_template: launch-coordination-checklist
source_template_version: 0.1.0
---


<!--
LEAN LAUNCH COORDINATION CHECKLIST. The engineering-readiness core: what counts as a launch, the checks a
launch must clear, how it is staged and reversed, what blocks it, and what would make this checklist wrong.
Five sections, because a small launch needs the readiness discipline without a roster of named roles or a
communications plan. To add Roles and Decision Authority and Launch Communications, see
launch-coordination-checklist_template-full.md; ADD sections, never rename or reorder the ones below,
because the full variant is a strict superset of this one. One content difference travels with growing into
full: Go/No-Go Criteria below names the decision-maker directly; the full variant moves that naming into its
own Roles and Decision Authority section instead.


THIS CHECKLIST IS STANDING; WHAT YOU PRODUCE BY APPLYING IT IS NOT. The instrument you are filling in belongs
to a team and is reused launch after launch, the same way one Google Launch Coordination Engineer "ran 350
launches through the LCE Checklist" in 3.5 years. A single completed run of this checklist against one
specific launch is a per-launch record of applying the standing list, not a second kind of document. Update
this file when the checklist itself needs to change, not every time a launch happens. See
launch-coordination-checklist_companion.md section 1 and section 6.


LENGTH IS A DESIGN CONSTRAINT, NOT AN ACCIDENT. Google's own history records what happens when a checklist
grows unmanaged: "In an effort to curb its growth, at one point, adding new questions to Google's launch
checklist required approval from a vice president." Separately, aviation human-factors research on flight-
deck checklists found that "as the list of items grows, there may be a higher probability of overlooking any
given item". Both are named here as the discipline they come from, SRE practice and aviation design research,
because neither transfers automatically to software launches; a check earns its place by the failure it
prevents, and a check nobody can justify comes out. See launch-coordination-checklist_companion.md section 3
(Anatomy > Readiness Checks) and section 6.


THE READINESS CHECKS SECTION IS BUILT FROM CATEGORIES FOUND ACROSS SEVERAL SOURCES, NOT FROM GOOGLE'S OWN
APPENDIX. Google's Launch Coordination Checklist, the type's named origin, is licensed CC BY-NC-ND 4.0 with
no derivatives, so this template does not adapt its items or reproduce its structure. See
launch-coordination-checklist_companion.md section 2.


WHAT THIS CHECKLIST IS, AND IS NOT
It is the standing list a team consults before shipping an externally visible change, so readiness does not
depend on who happens to be asking the questions. It is NOT a per-launch to-do list invented fresh each time
(that is the record produced by applying it), NOT a runbook (a runbook responds to a situation that has
already happened and must encode branching judgment; this checklist prepares for an event that has not
happened yet), and NOT a definition of done (that is a standing, per-unit-of-work engineering quality gate,
necessary but not sufficient input to a full launch). See launch-coordination-checklist_companion.md
section 8.


HOW TO FILL THIS IN
1. Read the comment under each heading: WHAT it wants, WHY it matters (with a pointer into
   launch-coordination-checklist_companion.md), guiding questions to ASK, a GOOD and a WEAK example, and the
   TRAP to avoid. For tables, PRIORITY explains the ordering rule and ROW HINT says what a good row contains.
2. Replace each {{placeholder}} with your content. Fill Scope and Launch Classes and Readiness Checks first;
   the rest depends on knowing what class of launch you are governing and what it must clear.
3. If a section does not apply to every launch class you named, say so inside that section rather than
   deleting the section; "N/A for Tier 3 launches, which skip this checklist entirely" is a legitimate,
   honest answer.
4. Before you ship it: self-grade against launch-coordination-checklist_guide.md, then DELETE every HTML
   comment. They are guidance, not content.
-->


# {{checklist_title}}


## Scope and Launch Classes


<!-- WHAT  What counts as a launch for this team, the classes of launch that exist, and which sections of
           this checklist each class actually requires, including whether the smallest class needs this
           checklist at all.
     WHY   Google's own working definition of the event this checklist governs is a useful default: "Google
           defines a launch as any new code that introduces an externally visible change to an application."
           Google's own history also tiers by risk rather than exempting by carve-out: low-risk launches
           "were faced with an almost trivial checklist, while higher-risk launches underwent the full gamut
           of checks and balances." Separately, by one point roughly a third of reviews were considered low
           risk. This section absorbs what an exemption section would otherwise carry, because exemption in
           the sources this bundle's research read is a property of the launch's class, not a standalone
           carve-out. Deep dive: launch-coordination-checklist_companion.md section 3 (Anatomy > Scope and
           Launch Classes) and section 6.
     ASK   What counts as a launch for this team? Follow Google's definition above if nothing narrower fits.
           What classes of launch exist, and what makes a launch fall into each one? Which sections of this
           checklist does each class actually require, and does the smallest class need this checklist at
           all?
     PRIORITY  Order classes from the one that requires the most of this checklist to the one that requires
           the least, so a reader scanning top to bottom sees the more demanding classes first.
     ROW HINT  A good row names a criterion someone else could check without asking the author who wrote it,
           and names required sections by their actual heading. A weak row has no distinguishing criterion,
           or lists sections as "everything" or "as needed."
     GOOD  | Tier 1 (new externally visible surface, or any change touching payment processing) | All
           sections in full |
     WEAK  | Standard launch | The usual checks | (no criterion anyone could check, and "the usual" names
           nothing)
     TRAP  If every launch your team has ever logged ends up in the same class, the class boundary is not
           doing any work and should be redrawn or dropped. -->


{{launch_definition}}


| Launch Class | Qualifying Criteria | Sections Required |
|---|---|---|
| {{launch_class}} | {{launch_class_criteria}} | {{launch_class_sections}} |


## Readiness Checks


<!-- WHAT  The checks a launch of this class must clear, grouped by area, each carrying the question, what
           actually answers it, the role that owns answering it, and why the check exists.
     WHY   Google's own unit for a checklist item is a question paired with an action, and its rule for
           which questions belong on the list at all is explicit: "Every question's importance must be
           substantiated, ideally by a previous launch disaster. Every instruction must be concrete,
           practical, and reasonable for developers to accomplish." What a completed check should say comes
           from the aviation human-factors literature on flight-deck checklists: "the response should always
           portray the actual status or the value of the item", not a bare "done." The WHO Surgical Safety
           Checklist's own design rule points the same way: "Every item on the Checklist must be linked to a
           specific, unambiguous action." This section's categories are built from structures found across
           several sources, never adapted from Google's own licensed appendix. Deep dive:
           launch-coordination-checklist_companion.md section 3 (Anatomy > Readiness Checks) and section 2.
     ASK   For each check: what is the question? What evidence actually answers it? Who owns answering it?
           Why is this check here, ideally pointing at a specific past failure it would have caught? If you
           cannot answer that last question, is this check earning its place?
     PRIORITY  Group areas in the order a reader would actually need them (dependencies and architecture
           before monitoring and rollout, for instance), and within an area, order checks by which would
           block the launch outright if unanswered.
     ROW HINT  A good row's "why" names the actual failure the check exists to prevent, not a generic reason
           like "best practice." A weak row has a plausible question with no evidence field and no owner,
           which makes it unanswerable by anyone but its author.
     GOOD  | Rollback capability | Can this change be reverted without a new deploy? | Feature flag exists
           and was toggled off in staging within the current release cycle | Feature owner | A prior release
           shipped with no flag and needed a full redeploy to revert |
     WEAK  | Rollback | Is it revertible? | Owner: Engineering. Status: Done. | (no name, and "done" is not
           an actual status)
     TRAP  Writing "done" instead of the item's current, actual status, or writing a check with a plausible
           question and no named owner. -->


| Area | Question | What Answers It | Owner | Why This Check Exists |
|---|---|---|---|---|
| {{readiness_area}} | {{readiness_question}} | {{readiness_evidence}} | {{readiness_owner}} | {{readiness_justification}} |


## Rollout and Rollback


<!-- WHAT  How the launch is staged, and the specific condition that reverses it, decided before the launch
           rather than argued during it.
     WHY   Google's own practice treats staged rollout as the default, not the exception: "Almost all
           updates to Google's services proceed gradually, according to a defined process, with appropriate
           verification steps interspersed." The same source adds, "Very few launches at Google are of the
           'push-button' variety". Where a staged rollout fails validation, the reversal is pre-decided: "If
           the change doesn't pass the validation period, it's automatically rolled back." A launch-day
           framework built around the same idea states the discipline directly: "Predeclare Rollback and
           Stop Triggers", with the instruction "Do not debate a clear hard trigger while impact grows.
           Abort first, then investigate". What happens without one is recorded in a real incident, where
           the emergency response itself made things worse: "As it turns out there was no kill switch". Deep
           dive: launch-coordination-checklist_companion.md section 3 (Anatomy > Rollout and Rollback) and
           section 7.
     ASK   How is this launch staged, all at once or gradually with verification steps between stages? What
           specific, measurable condition triggers a rollback, stated as a threshold you can check rather
           than a feeling that something is wrong? Who is authorized to pull it?
     PRIORITY  List the hardest, most automatic triggers first, the ones that should fire without a human
           deciding, then the triggers that require judgment.
     ROW HINT  A good row states a specific, measurable threshold and names who can act on it without further
           approval. A weak row is a feeling with no named authority.
     GOOD  | Error rate exceeds 2 percent of requests for 5 consecutive minutes on the launch dashboard |
           On-call engineer, no approval required |
     WEAK  | Roll back if things look bad | Whoever notices | (no threshold, no named authority)
     TRAP  A rollback trigger debated for the first time during an incident is functionally the same as
           having no trigger at all. A real incident's own retrospective conclusion on the risk of shipping
           without one: "Deployments need to be automated and repeatable and as free from potential human
           error as possible". -->


{{rollout_stages}}


| Rollback Trigger | Evidence Threshold | Authorized To Pull It |
|---|---|---|
| {{rollback_trigger}} | {{rollback_evidence}} | {{rollback_authority}} |


## Go/No-Go Criteria


<!-- WHAT  What blocks this launch outright, decided in advance, the current evaluation state of each
           criterion, how an accepted exception is recorded, and who makes the go/no-go call. This variant
           carries the decision-maker here directly rather than in a separate roles section, which is a
           reasonable compression once a launch is small enough not to need a named roster.
     WHY   The clearest sourced model for this section states four possible readings of a check rather than
           a binary pass or fail: "green: evidence is within the predeclared safe range; yellow: an accepted
           deviation requires explicit risk ownership; red: a hard gate failed; unknown: evidence is absent,
           delayed, or untrustworthy", with the explicit warning that "Unknown is not green." The same
           source states the rule for a missing prerequisite: "Either the prerequisite is met, an authorized
           time-bounded exception exists, or the decision is no-go", and names the anti-pattern this rule
           exists to prevent: "Executive override without ownership: a deadline silently replaces a hard
           gate." Where an exception is accepted, the instruction is to record it: "Record yellow-state
           acceptance, expiry, and decision authority." The decision-maker itself is named directly here
           because this variant has no separate roles section: the same source states "makes the go/no-go
           call for the current risk tier", with the instruction to "Name roles rather than inviting a large
           distribution list". Deep dive: launch-coordination-checklist_companion.md section 3 (Anatomy >
           Go/No-Go Criteria) and section 7.
     ASK   Who makes the go/no-go call for this launch, named by role rather than a distribution list? What
           conditions block this launch outright if unmet? For each one, what is the current state, green,
           yellow, red, or unknown, and what evidence supports that state? Where a deviation is accepted
           rather than blocking, who owns that acceptance and when does it expire?
     PRIORITY  List the criteria that would block the launch outright before the ones that could be waived
           with an accepted exception, so a reader sees the hard stops first.
     ROW HINT  A good row's evidence field names something a second person could go check themselves. A weak
           row's state is asserted with no evidence anyone else could verify.
     GOOD  | Load test against payment processing | Green | Load test run at 2x expected peak traffic,
           results attached | Platform lead |
     WEAK  | Load testing | Mostly fine | (no state, no evidence, no owner)
     TRAP  Treating an absent or delayed piece of evidence as a pass; "Unknown is not green." A deadline
           silently replacing a hard gate, with nobody owning that decision, is the named failure this
           section exists to prevent. -->


{{decision_maker}}


| Criterion | State | Evidence | Owner |
|---|---|---|---|
| {{gate_criterion}} | {{gate_state}} | {{gate_evidence}} | {{gate_owner}} |


{{exception_handling}}


## Review Trigger


<!-- WHAT  The event that would make this checklist wrong, and the named person or role expected to notice
           it. Not a calendar date alone.
     WHY   Google's own curation practice sets a floor, "Once or twice a year a team member reviews the
           entire checklist to identify obsolete items", and the same source records what happens when
           curation is neglected in the other direction: "In an effort to curb its growth, at one point,
           adding new questions to Google's launch checklist required approval from a vice president." A
           practitioner account of readiness-review practice warns against treating every incident as an
           automatic new line item: "With every incident that went awry, we would add a line item to our
           PRR process. Definitely do not do that, because you end up with this PRR process that's just
           monstrous and you cannot understand the underlying mechanisms." No structural source this
           bundle's research read publishes a section with this name or job; it is required directly by this
           family's contract, and this bundle labels it as its own contribution the way its sibling bundles
           in the same family label theirs. Deep dive: launch-coordination-checklist_companion.md section 3
           (Anatomy > Review Trigger) and section 6.
     ASK   What event would make this checklist wrong: a new failure class, a platform migration, a repeated
           near miss? Who owns noticing it? When an incident does prompt a look at this checklist, which
           specific mechanism failed, not merely that something went wrong, and is the fix a new check or
           something else?
     PRIORITY  Pair every date-based cadence with at least one event-based trigger. An event with no named
           owner is not a trigger, it is a hope.
     ROW HINT  A good row names a specific event, a named owner, and what they do about it: investigate
           which mechanism failed before deciding whether the fix is a new check. A weak row names only a
           calendar date.
     GOOD  | Two Tier 1 launches in one quarter needed an unplanned rollback for the same class of failure |
           Launch coordination lead | Investigate which existing check should have caught it before adding a
           new line item |
     WEAK  | Review this checklist annually | Team | Update if needed |
     TRAP  Adding a new checklist item for every incident without first asking which mechanism failed.
           Unmanaged, that growth is exactly what once required a vice president's approval to control. -->


| Event That Would Make This Wrong | Owner Who Notices | What They Do About It |
|---|---|---|
| {{review_event}} | {{review_owner}} | {{review_action}} |

Provenance

Section titled “Provenance”

The reasoning, the history and every source, in the repository:

  • Companion - the long-form argument: why these sections, where the sources disagree, and what the bundle refuses to claim
  • History - what changed in this bundle, and when
  • Research log - every source consulted, with what each one actually supports
  • Catalog metadata - the machine-readable record this page is generated from

Catalog record: 7 sections across 1 format(s), methodology SRE, typically owned by Launch Coordinator / SRE.