When to use it
When a feature is nearly done and the release is imminent — but your head is full of code and it's easy to forget analytics, copy, support and rollback. The role: a PM running the launch. The result: a go-to-market checklist broken out by area, with an owner and a criticality flag, plus a release-day plan and success metrics.
The prompt (copy and paste)
You are a product manager who ships features without surprises. Build a launch checklist.
FEATURE: "<FILL IN: what it is and who it's for>". SCOPE: <everyone at once / a percentage / beta>. TEAM: <what I have: solo / dev, support, marketing>.
LAUNCH GOAL: "<what counts as success>".
Return a checklist by section, each with concrete items (phrase every ✅ as a verifiable action), an owner (or "me") and criticality (blocker / nice to have):
1. Product readiness (tests, edge cases, feature flag / rollback path, performance, accessibility).
2. Analytics and metrics (which events to track, how we'll know it worked or failed, dashboard).
3. Communication and marketing (announcement, in-product copy / new-feature onboarding, posts, email, release notes).
4. Support and documentation (FAQ, answers to the common questions, how-to).
5. Risks and plan B (what could break, how to roll back, who to warn).
6. Release-day plan (the sequence, who's watching, the monitoring window).
7. Post-release (what to watch in the first 24-72 hours, when we decide "keep / roll back / iterate").
Flag the blockers — we don't ship without them. Scale the checklist to the scope and the team (don't bloat it for a solo dev).
Filled-in example
Feature: "subscription billing instead of one-off payment" in a SaaS. Scope: beta, 10% of users. Team: me plus one developer. Goal: confirm people can subscribe without failures and conversion doesn't drop.
What the AI should return: Product — [blocker] happy path and payment-failure path tested, [blocker] a feature flag for a fast kill switch, handling of recurring charges; Analytics — "payment started/succeeded/failed" events, a conversion dashboard, an alert on rising errors; Communication — an explainer screen about the subscription, release notes; Support — an FAQ on "how do I cancel", a canned reply to "why is it a subscription now"; Risks — payment provider goes down → fall back to one-off, who to notify; Release day — ship to 10%, watch for 2 hours; Post-release — watch conversion and errors for 72 hours, then a go/no-go call.
Variations
- A big launch. "This is a major public release — beef up the marketing, PR and load-testing sections."
- Engineering only. "Give me an engineering pre-launch checklist: tests, flags, rollback, monitoring, load."
- Retro. After the launch: "using this checklist, review what we did well and what we missed."
Pro tips
- A rollback path (feature flag) and metric tracking are almost always blockers: without them you can neither tell that something broke nor switch it off quickly. Don't ship without them.
- Decide the "keep / roll back / iterate" criteria and the observation window BEFORE the release, not in a panic afterwards — post-launch emotions are a bad time to set thresholds.
- Right-size the list: a bloated 60-item checklist won't get done on a solo project. Ask for the blockers to be isolated and trim the rest to fit the team you actually have.