Launch Readiness Checklist

Deciding whether a product or feature is ready to launch is a cross-functional question, not an engineering one. Asked "are we ready to launch?", the base model tends to return a flat activity list — finish QA, write the blog post, update the help docs, tell the team — with everything at one altitude, no function that owns each item, no way to tell a launch-stopper from a nice-to-have, and no actual decision at the end. It also reliably forgets the quiet functions: whether the launch is instrumented enough to know if it worked, whether legal has cleared it, and whether there is a way back.

This skill checks readiness across six functions, each as an explicit gate, and returns a single GO / NO-GO with the blocking gate named.

When to Activate

Activate when the user asks:

• Are we ready to launch this / ship this to customers?
• Give me a launch-readiness checklist for this release.
• Run a go/no-go before we announce.
• What do we still need before we can go live?
• Is this feature ready for GA / general availability?

The Six Gates

Assess all six. Each gate is READY, NOT READY (with the specific gap), or N/A (with the reason it does not apply to this launch). Two rules govern how you read the plan:

• Silence is NOT READY, not N/A. A gate the launch plan never mentions is failing, not absent — the launch has no instrumentation until someone says it does. Only mark a gate N/A when there is a real reason it does not apply (no legal surface, nothing customer-visible for support to handle), and say the reason.
• Every gate names an owner. "Ready" with no one accountable is not ready. If the plan does not say who owns a gate, that gate is NOT READY on ownership alone.

1. Engineering — the thing works and can ship

The feature is built, tested, and has a deploy plan. Functionality complete, QA/acceptance passed, performance and error budgets acceptable under expected load, and a concrete plan to get it to production. This gate is about whether it works and can be deployed — the safety of the deploy mechanics themselves (staging, dark launch, canary) is a separate, deeper check. NOT READY if: known launch-blocking bugs are open, load/scale is untested for the expected traffic, or there is no deploy plan.

2. Analytics / Instrumentation — you can tell if it worked

There is a defined success metric and the events to measure it are actually firing before launch, not promised for after. You cannot judge a launch you cannot see. NOT READY if: no success metric is named, the tracking is "we'll add it next sprint," or the dashboard to read the result does not exist. This is the gate the base model omits most often — treat its absence as a hard finding.

3. Support / Customer success — the front line is prepared

The people who will hear from confused or unhappy customers are ready before customers arrive: help docs or release notes published, canned responses / macros for the likely questions, support staffed for the volume, and an escalation path to engineering. NOT READY if: support has not been told the launch is happening, or there is nothing for them to point customers at.

4. Legal / Compliance — it is cleared to ship

Anything with legal surface has sign-off: privacy review for new data collection, terms-of-service or contract changes, regulatory or accessibility requirements, and required disclosures. NOT READY if: the launch changes what data you collect or what you promise users and no one has cleared it. N/A only when the launch genuinely has no legal surface — say so explicitly rather than skipping the gate.

5. Marketing / Comms — the message is ready and coordinated

The announcement, the assets, and the audience are prepared and timed to the actual go-live — not just "we'll tweet about it." Internal teams (sales, support, execs) know before customers do. NOT READY if: sales will find out from customers, or the announcement is scheduled before the feature is actually on. For a silent / no-announcement launch, mark N/A with that as the reason.

6. Rollback — there is a way back

There is a defined, rehearsed way to take the launch back if it goes wrong — a flag to turn it off, a documented reversal, and a named threshold that triggers pulling it. "We'd figure it out" is NOT READY. This is distinct from the engineering deploy's revert path: it is the product decision to un-launch, and who makes the call.

Launch-blocking vs. fast-follow

Not every gap stops a launch. Separate the two:

• Launch-blocking: a NOT READY here is an automatic NO-GO. Engineering (it doesn't work), Legal (not cleared to ship), and Rollback (no way back) are always launch-blocking — shipping a broken, non-compliant, or irreversible launch is never acceptable.
• Fast-follow: a gap that can be closed within a named, short window after launch with an owner and a date — e.g. a help-doc polish or a secondary metric. A fast-follow with no owner or no date is not a fast-follow; it is NOT READY.

The verdict

End with a single decision, not a summary:

• GO only when every launch-blocking gate is READY and every remaining gap is an owned, dated fast-follow.
• NO-GO if any launch-blocking gate is NOT READY, or any gate's gap has no owner. Name the specific gate(s) that block. Do not soften a NO-GO into "mostly ready."

Report the six gates as a compact status list (gate → verdict → the gap or owner), then the GO / NO-GO line with the blocker named. Do not invent a blocker for a gate the plan has already satisfied, and do not approve a launch just because the engineering work is done — a launch is ready when every function is, not when the code is.