Draft an internal launch readiness check before the public release

Description

Your team is two weeks from a public launch and the question keeps coming up at standup: are we actually ready? This drafts the internal launch readiness check that puts product, engineering, support, sales, marketing, and legal on the same artifact, with explicit pass/fail conditions per row, so the go decision is not a vibe.

You are a PM running launch readiness for {{feature_or_product}}. Public launch target: {{target_date}}. Stakeholders: {{stakeholder_list}}.

## Step 1. Set the launch tier
Pick one of:
- Tier 1 (broad public launch with press, paid amplification): full readiness check
- Tier 2 (segment launch or beta graduation): trimmed readiness check, minus marketing/PR rows
- Tier 3 (silent launch or feature flag rollout): engineering and support rows only

The tier sets the expectation for which rows must be green to ship.

## Step 2. Build the readiness matrix
Each row is a function with explicit owner and pass criteria:

| Function | Owner | Pass criterion | Status (R/A/G) |
|----------|-------|----------------|----------------|
| Engineering | tech lead | All P0/P1 bugs closed; load test at 2x peak passes | |
| QA | QA lead | Regression suite passes; 5 critical user flows tested on real devices | |
| Support | support lead | Macros written; team trained; on-call rotation covers launch window | |
| Sales | sales lead | One-pager and demo script ready; first 10 deals briefed | |
| Marketing | marketing lead | Landing page live; emails scheduled; PR embargo set | |
| Legal | legal lead | T&Cs updated if needed; data privacy review signed off | |
| Analytics | analytics owner | Telemetry shipped; launch dashboard live | |
| Pricing/Billing | finance lead | Pricing live in billing system; refund policy defined | |
| Security | security lead | Threat model reviewed; pentest closed | |
| Comms | PM | Internal Slack post drafted; FAQ ready for reps | |

## Step 3. Define hard pass/fail per row
For each row, write the specific test that turns it green:
- Not "support is ready" but "5 macros are deployed and tested with two real tickets"
- Not "telemetry exists" but "the launch dashboard shows live data for the 5 key events"
- Not "sales is briefed" but "10 sales reps watched the demo and passed a 5-question quiz"

## Step 4. Schedule the dry run
T-7 days: full dry run with the readiness matrix in front of the team.
- Each owner reports status with evidence
- Reds and yellows get a specific blocker and a date
- Greens get a sanity check by a peer (no self-attestation)

T-3 days: second pass on rows that were yellow at T-7.

## Step 5. Define the go/no-go criteria
For tier 1 launches, all rows must be green at T-1 day except for at most 2 yellows that have a documented mitigation. Any red is no-go.

For tier 2/3 launches, the trimmed matrix follows the same rule on its rows.

## Step 6. Define the day-1 watchlist
What you will monitor in the first 24-72 hours:
- Error rate above baseline (engineering)
- Support ticket volume above baseline (support)
- Negative sentiment in social/community (marketing/PR)
- Any P0 or P1 incident (incident commander)
- Conversion or activation that misses target by more than 30 percent (analytics)

## Output
1. Filled readiness matrix with owners and pass criteria
2. Hard pass/fail conditions per row
3. T-7 dry run agenda with required attendees
4. Go/no-go decision template for T-1
5. Day-1 watchlist with thresholds and rollback criteria
6. The single row that is most likely to slip and the contingency plan if it does

Customize This Prompt