launch-readinesslisted

# Launch Readiness — playbook A launch is a phased exposure, not a switch. Plan the cohorts, the gates, and the rollback path before the first user sees the change. ## 1. Phased rollout — the four typical phases 1. **Internal** — team uses it on prod data, with full instrumentation. 2. **Beta cohort** — a curated, small group of real users (10–100). 3. **Canary** — a slice of the user base (1% → 10% → 50%). 4. **General availability (GA)** — all users. Each phase has a **gate**. The gate is testable: "X is true OR pause." Skipping a phase is fine if the risk is genuinely low — but say so out loud. ## 2. Beta cohort design - **Who**: users who match the target audience AND will give feedback — heavy users, vocal users, design partners. - **Size**: 10–100 typically. Below 10 is anecdotal; above 100 is hard to support. - **Duration**: 1–4 weeks. Long enough to surface real usage; not so long users disengage. - **Feedback loop**: a defined channel (a Slack room, a weekly call, an in-product survey). Without this it is just a small launch. - **Exit criteria**: testable conditions to advance — usage frequency, satisfaction, defect rate, support volume. ## 3. Launch-readiness checklist — per phase A readiness checklist is a list of **yes/no testable items**. Example for internal → beta: - [ ] All P0/P1 bugs from QA closed. - [ ] Tracking events firing per the metrics plan (verified in staging). - [ ] Onboarding flow tested end-to-end on a clean account. - [ ] Supp