Launch Readiness
Drive a cross-functional readiness review that ends in a clear Go / No-Go / Go-with-conditions recommendation.
When to use
- Approaching a release and you need to confirm every function is ready.
- Preparing a go/no-go meeting or sign-off doc.
Inputs to gather
- What's launching, the target date/window, and the rollout plan (e.g., %-based, regions, GA vs. beta).
- Status by function; known open issues and their severity.
- Success metrics and the rollback/kill-switch plan.
Process — review each readiness area
For each area, capture status (🟢/🟡/🔴), owner, evidence/notes, and blocking?:
- Product/Scope — acceptance criteria met; scope cuts agreed.
- Engineering — code complete, feature-flagged, perf/scale checked, on-call ready.
- Quality — test pass, critical bugs triaged to zero, edge cases covered.
- Design/UX — final review, accessibility, edge/empty/error states.
- Docs & Support — help content, runbooks, support team briefed.
- Go-to-market — comms, release notes (
release-notes), pricing/packaging if relevant.
- Legal/Privacy/Compliance — reviews and approvals where required.
- Data/Analytics — instrumentation live; success metrics measurable.
- Rollout & rollback — staged plan, monitoring/alerts, tested rollback, named decision owner.
Decision
- Go — all critical areas green.
- Go with conditions — minor ambers with named owners + dates; list the conditions.
- No-Go — any red in a blocking area; state what must close and the re-review date.
Output format
A readiness table (area · status · owner · notes · blocking?) followed by the recommendation, the conditions/blockers, and the rollback plan. State the decision owner and the go/no-go meeting time.
1---2name: launch-readiness3description: Run a go/no-go launch-readiness review for a product or feature release across all functions (product, eng, QA, design, docs, support, marketing, legal, ops). Use when the user says "launch readiness", "go/no-go", "are we ready to ship/launch", "release checklist", or needs a cross-functional sign-off before shipping.4---56# Launch Readiness78Drive a cross-functional readiness review that ends in a clear **Go / No-Go / Go-with-conditions** recommendation.910## When to use11- Approaching a release and you need to confirm every function is ready.12- Preparing a go/no-go meeting or sign-off doc.1314## Inputs to gather15- What's launching, the target date/window, and the rollout plan (e.g., %-based, regions, GA vs. beta).16- Status by function; known open issues and their severity.17- Success metrics and the rollback/kill-switch plan.1819## Process — review each readiness area20For each area, capture **status (🟢/🟡/🔴), owner, evidence/notes, and blocking?**:211. **Product/Scope** — acceptance criteria met; scope cuts agreed.222. **Engineering** — code complete, feature-flagged, perf/scale checked, on-call ready.233. **Quality** — test pass, critical bugs triaged to zero, edge cases covered.244. **Design/UX** — final review, accessibility, edge/empty/error states.255. **Docs & Support** — help content, runbooks, support team briefed.266. **Go-to-market** — comms, release notes (`release-notes`), pricing/packaging if relevant.277. **Legal/Privacy/Compliance** — reviews and approvals where required.288. **Data/Analytics** — instrumentation live; success metrics measurable.299. **Rollout & rollback** — staged plan, monitoring/alerts, tested rollback, named decision owner.3031## Decision32- **Go** — all critical areas green.33- **Go with conditions** — minor ambers with named owners + dates; list the conditions.34- **No-Go** — any red in a blocking area; state what must close and the re-review date.3536## Output format37A readiness table (area · status · owner · notes · blocking?) followed by the **recommendation**, the **conditions/blockers**, and the **rollback plan**. State the decision owner and the go/no-go meeting time.
janellecipriano