Generate the Launch-Readiness Checklist and Comms Pack

Workflow area: Launch & GTM · Tier: Foundation · Hands-on time: ~25 minutes

Every experienced PM carries a mental launch checklist, and every launch still misses something, because the mental version is regenerated from scratch under time pressure. AI is exceptionally good at the enumeration half of this job — exhaustively listing what a launch of this shape needs — and entirely untrustworthy on the confirmation half. The recipe splits the work exactly there: the model enumerates and drafts, a named owner confirms every item, and nothing ships on an unchecked box.

When to use — and when not to

• Use it for any launch with more than one team involvedthe checklist's real job is surfacing cross-team dependencies (support, docs, legal, marketing, data) that live in nobody's backlog.
• Use it two weeks out, not two days outthe checklist's value is the lead time it creates for the items that turn out to be red.
• Use the comms-pack half for every externally visible changeeven a small feature needs the in-app note, the changelog entry, and the support macro to agree with each other.
• Skip the generated checklist for regulated or safety-critical launchespayments, health data, anything with a compliance sign-off chain. There the checklist comes from legal and compliance, and AI may only add items, never be the source.
• Skip it for dark launches and internal flagsa feature-flag flip to 2% of traffic needs pb-43's rollout plan, not a comms pack.

The recipe

1. 1.

   Assemble the launch brief. One page: what's shipping, to whom, when, the user-visible changes, the risky bits, and which teams touch it. The PRD's summary section usually is this page.

2. 2.

   Generate the checklist with owners and evidence columns. Prompt:

   Copy

   You are preparing a launch-readiness checklist. Launch brief:
   [PASTE BRIEF]
   
   Teams involved: [e.g. eng, support, docs, marketing, legal, data]
   
   Generate a checklist as a table with columns:
   ITEM | TEAM | SUGGESTED OWNER ROLE | EVIDENCE REQUIRED | STATUS
   
   Cover at minimum: support macros and escalation paths, help-docs
   updates, in-app messaging, sales/CS notification, legal and privacy
   review triggers, pricing/billing changes, analytics events live and
   verified, feature flags and rollout stages, rollback owner and
   procedure, status-page and incident comms plan, localization,
   accessibility check.
   
   For EVIDENCE REQUIRED, state what a human must link or paste to
   mark the item done (a URL, a screenshot, a named person's yes) —
   never "confirmed" without an artifact.
   
   End with a list titled "LIKELY MISSING FROM THIS BRIEF" — items
   this launch probably needs that the brief doesn't mention.
   

3. 3.

   Prune, then assign real names. The generated list will include items your launch doesn't need — delete them so the checklist stays credible. Then replace every "suggested owner role" with a person. Sample of a healthy row:

   Copy

   ITEM: Support macro for "where did my old export go?"
   TEAM: Support   OWNER: Meera K.
   EVIDENCE: link to published macro in Zendesk
   STATUS: 🔴 not started
   

   The "LIKELY MISSING" section is where the model earns its keep — read it carefully, keep what's real.

4. 4.

   Generate the comms pack from the same brief. In the same conversation:

   Copy

   Now draft the comms pack for this launch. Every factual claim must
   come from the brief — if the brief doesn't say it, don't claim it.
   Mark any claim you inferred with [VERIFY].
   
   Produce:
   1. Changelog entry (80-120 words, user-facing, no internal jargon)
   2. In-app announcement (40 words max + CTA)
   3. Customer email for affected accounts (subject + 150 words)
   4. Internal launch note for sales/CS: what changed, what to say,
      what NOT to promise, known limitations
   5. Support macro: the top 3 questions users will ask, with answers
   

5. 5.

   Route each draft to its channel owner and sweep the [VERIFY] tags. Docs owns the changelog wording, support owns the macro, marketing owns the email. Your job is consistency: the limitation admitted in the internal note must not be contradicted by the email's enthusiasm. Every [VERIFY] tag gets resolved against the actual build — the model will confidently describe behavior the brief only implied.

6. 6.

   Run the checklist standup at T-minus-one-week. Ten minutes, walk the reds and yellows only. An item without evidence linked is not done, whatever its owner remembers.

Make it yours

• Template it after the first run: your second launch shouldn't regenerate from scratch. Save the pruned checklist as your org's template in Notion, and have AI diff each new launch brief against it — "which items does this launch add or remove?"
• Tier the checklist: maintain small/medium/large variants. A copy change doesn't need legal review; a pricing change always does. Ask the model to classify the launch tier first and justify it.
• Wire the evidence column: in Notion or Linear, make the checklist a database where the evidence field is required to flip status — the process enforces what the standup used to police.

Quality check

• Every item has a named human and an evidence artifacta checklist of roles and vibes is theater; the AI suggested, a person confirmed.
• The rollback row is completeowner, trigger, procedure, and the time-to-execute someone has actually estimated. This is the row most launches leave abstract.
• Comms claims trace to the briefread the customer email against what actually shipped; the model's enthusiasm exceeds the build's reality more often than not, and all [VERIFY] tags are resolved.
• The pack agrees with itselfthe changelog, email, and support macro describe the same feature with the same limitations.
• Pruning happenedif the checklist still contains items irrelevant to this launch, owners will learn to skim it, and a skimmed checklist protects nothing.