Launch checklists and runbooks

Treat the launch checklist as a go/no-go gate owned by the DRI (project execution). Skip rows only with a written reason. If monitoring, rollback or support readiness is red, do not launch. A delayed launch is recoverable. A launch that pages the company and confuses customers is a reputation tax.

Launches fail socially more often than technically. Marketing needs a freeze date for screenshots. Sales needs to stop promising half-built demos. Support needs 48 hours with a staging build before customers arrive.

Product and engineering

• Feature complete against the PRD non-goals; known limitations listed in release notes.
• Feature flag / percentage rollout configured; kill switch tested.
• Rollback plan: flag off, previous build, or data-migration reverse path — named owner, estimated time to safe state.
• Dashboards for errors, latency, and the launch success metrics; alert thresholds set.
• Load / abuse expectations if launch traffic spikes.
• Accessibility and mobile smoke pass if those surfaces matter for the segment.

Docs, enablement, GTM and legal

• Help center article or changelog with screenshots that match the final UI.
• In-app empty states and first-use cues (activation).
• Sales one-pager and demo script rehearsed with 2–3 reps (T2/T1).
• Support macros, escalation path, and known-issues doc.
• Positioning agreed with marketing. Blog, email, social or press only if the tier warrants it — assets freeze against final UI.
• Pricing, packaging and entitlements correct in billing (pricing).
• Legal / privacy / security review when the launch touches data, AI outputs or contracts.

Coordinating the people

• One launch brief (half a page): what ships, who it is for, tier, date, success metrics, owners for eng / PMM / sales / support.
• Weekly launch sync from T-3 weeks (T2/T1) until T+1 week — 20 minutes, blockers only.
• Launch day channel with the DRI, on-call eng, support lead and PMM.
• Embargo rules for T1: who can tweet, when the blog goes live, how to handle press.

Engineers' job is not to write the blog post. It is to surface constraints early ("the flag cannot go to 100% until the backfill finishes Saturday") and to refuse fake dates.

Launch day runbook

Write a one-page run-of-show for T2/T1. Timezone it explicitly.

T-24h  Final go/no-go; freeze marketing screenshots
T-2h   DRI + on-call in channel; dashboards pinned
T-0    Flag to 100% OR announce URL goes live (pick one order)
T+15m  Check error rate, activation counter, support queue
T+2h   First status to stakeholders (green/yellow/red + one sentence)
T+24h  Decide: stay the course, hotfix, or rollback narrative

Enable first, announce later. The reverse produces screenshots of 404s.

Common mistakes

• Launching with a red row. Delay. Do not hope.
• Screenshot drift. Marketing froze on staging UI. Freeze assets after UI lock.
• Rollback theater. A kill switch nobody tested in staging is not a plan.

Check yourself

Support macros are missing on launch morning. Do you ship? No. Support readiness is a go/no-go row. A delayed launch is cheaper than a pile-on.

Should T-0 flip the flag and the blog at the same second? Prefer enable first, announce later. Pick one order and write it on the runbook.

Key takeaways

• The checklist is a gate: monitoring, rollback and support must be green.
• One brief, a short weekly sync, and a launch-day channel beat a long meeting culture.
• Write a timed runbook. Freeze screenshots after UI lock. Rehearse flag-off.

Further learning

Next, decide what "worked" means in measuring launches.