Launch readiness

Launch readiness

Invocation: user only.

Launches are where projects go to die. Not because the product is bad — because three different functions each thought the other was handling support/legal/comms/ops. This skill walks the cross-functional matrix, identifies who's ready and who's not, and produces a go/no-go call with evidence.

The matrix

For any non-trivial launch, the following functions all have readiness work. Not all apply to every launch; skip the ones that don't and note why.

Function	What they own before launch
Product / PM	PRD finalized; metrics dashboard ready; success criteria agreed
Engineering	Code merged, deployed, feature-flagged if applicable; rollback plan tested; monitoring + alerts live
Design	Final UI shipped, asset kit for marketing, any brand review complete
Marketing	Launch narrative, channels, collateral, embargo coordination, external comms scheduled
Support / Success	Docs live, team trained on the feature, escalation runbook, anticipated question list
Legal / Compliance	Terms updated if needed, privacy impact reviewed, any regional restrictions documented
Sales / CS	Enablement delivered, customer comms plan for material changes, expansion talking points
Ops / Finance	Pricing in billing system, metering/usage tracking live, revenue recognition sorted
Data	Analytics instrumented, KPI dashboard built, experiment setup if staged rollout

Workflow

1. Scope the launch

From $ARGUMENTS, identify:

• Launch name and one-line description
• Target date
• Launch tier — major (public announce, press, external marketing) / minor (customer comms only) / silent (infra or back-end change, no external signal)

Tier determines which functions are actually in scope. A silent infra launch skips marketing/sales/support-training but keeps monitoring + rollback. A major launch keeps everything.

2. Identify function owners

For each in-scope function, identify the specific person owning that function's readiness. Not "the marketing team" — a name. If the owner isn't obvious, ask the user.

If an in-scope function has no owner, flag that as the top blocker. Unowned functions are how launches fail.

3. Gather status per function

In parallel:

• Notion: each function's launch readiness page or checklist if they have one; the launch hub page if one exists
• Slack: launch channel, function-specific channels, messages mentioning the launch name in the last 14 days
• Calendar: planned launch prep meetings, any that got cancelled
• Gmail: threads with external parties (PR, partners, legal counsel, payment providers)
• Risk log: launch-related risks

For each function, determine:

• Ready — specific evidence that their work is done
• In flight — work is happening, on track for date
• At risk — work is happening but target date is questionable
• Not started — hasn't begun, or owner can't confirm they will begin in time
• N/A — out of scope for this launch tier (noted with why)

4. Identify hard blockers

A hard blocker is something that makes the launch date impossible unless resolved. Typically:

• Legal / compliance review not started on a launch that needs it
• Engineering rollback plan not tested (or not even designed)
• Support documentation not live on a customer-facing launch
• Billing/pricing not configured on a monetized launch
• A critical dependency from a different team (likely surfaced by /role-pgm:dependency-map)

Each hard blocker needs an owner and a resolve-by date. If the resolve-by is after the launch date, the launch date is wrong.

5. Launch-day plan

Separately from readiness, walk through the launch day itself:

• T-day-before: final checks, final approvals, go/no-go call
• T-0 (launch): which flip is thrown, by whom, at what time. Monitoring on. Who's watching.
• T+0 to T+2hr: active monitoring window. Who's on, in what channel, for what signals.
• T+24hr: first review — initial signal, early issues, early wins. Who writes the update.
• T+1 week: full post-launch metrics review. Who owns. Where it lives.

If any of these slots don't have an owner + plan, add them to the blockers list.

6. Output — the go/no-go report

# Launch readiness — <launch name> — target <date>

**Tier:** <major | minor | silent>
**Recommendation:** 🟢 GO | 🟡 GO WITH CAVEATS | 🔴 NO-GO

**One-line justification:** <why this is the recommendation>

## Status by function

| Function | Owner | Status | Evidence / concern |
| --- | --- | --- | --- |
| Product | <person> | ✅ Ready | PRD finalized, dashboard live |
| Engineering | <person> | 🟡 In flight | Rollback plan drafted, not yet tested — target test date <x> |
| Design | <person> | ✅ Ready | |
| Marketing | <person> | 🔴 At risk | Launch narrative not drafted; 5 days to launch |
| Support | <person> | 🟡 In flight | Docs drafting, training scheduled for <date> |
| Legal | <person> | N/A | Non-material change, no legal review required |
| ... | | | |

## Hard blockers
1. <blocker> — owner: <person> — resolve by: <date, which must be before launch>
2. ...

## Soft risks (won't block, worth managing)
- <risk> — what happens if it doesn't land — mitigation

## Unowned work (TOP PRIORITY TO FIX)
- <function or task> — no current owner. Assign before anything else.

## Launch-day plan
- **T-day-before (date):** <checks, approvals, go/no-go call — who, when>
- **T-0:** <flip, by whom, at what time. Monitoring responsible: <person>.>
- **T+0 to T+2hr:** <active monitoring. Channel: #<channel>. On-call: <person>.>
- **T+24hr:** <first review — owner, destination>
- **T+1 week:** <full metrics review — owner, destination>

## Recommendation
<Restate the go/no-go with 1-2 sentences of reasoning. If 🟡 or 🔴, specify what would change it.>

7. Publish

Show the report. Common edits:

• Status corrections (owner knows more than the system reflects)
• Added or dropped blockers
• Soft risks reclassified

On approval:

• Save to Notion under the launch hub
• Post TL;DR to the launch Slack channel with a link to the full doc
• Offer to /role-pgm:nudge-owner on specific blocker owners if escalation is warranted

Don't

• Don't green-light a launch with a hard blocker unresolved. 🟢 means every blocker has a confirmed path to resolution before date.
• Don't skip the launch-day plan. Readiness without a day-of plan is where teams show up launch morning asking "so… what do we do first?"
• Don't assume "silent" launches need zero readiness. They still need monitoring, rollback, and a metrics review.
• Don't ship this report without confirming function owners. Any row where "owner" is TBD is a row where the launch is fragile.
• Don't turn this into a status meeting. The report is async — consumers read, owners update their rows before the next check-in.