launch-readiness · diff
git:20260729.8dd5ad0 to git:20260920.2cbc56d
1 added, 1 removed. Audit A to A.
---
name: launch-readiness
description: "Playbook for safe product launches — phased rollout strategies, beta cohort design, readiness checklists, rollback criteria, and post-launch watch periods. Used by launch-manager."
---
## Codex host binding
- Treat references to Claude slash workflows as the equivalently named Codex skill.
- Before delegating to any specialist, read the `great-pm-runtime` skill and the selected packaged role file.
- Treat "invoke", "assign", "delegate", "spawn", and source Agent-tool instructions as a required Codex `spawn_agent` call with that role and a bounded assignment.
- - Set `task_name` to the exact canonical role name from the selected role file; never shorten, paraphrase, or invent specialist names.
+ - For the spawn tool's `task_name` or `agent_name` identifier, replace canonical role-name hyphens with underscores (`query-refiner-pm` → `query_refiner_pm`). Keep canonical names unchanged in prompts, filenames, verdict logs, and user-facing output; this is an internal identifier mapping, not a role rename.
- Store every returned agent identifier. Never call a wait tool until a spawn has returned an identifier, and wait only on identifiers returned by successful spawns.
- If `spawn_agent` is unavailable or a spawn fails, report BLOCKED; do not impersonate the specialist or wait on an empty agent set.
- Resolve bundled paths from the installed GreatPM plugin root.
- Ignore Claude-only model aliases, colors, turn limits, and tool allowlists.
- Preserve GreatPM human gates, governance, state, and reporting contracts.
# 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.
- [ ] Support has the FAQ / runbook.
- [ ] Docs published for the new flow.
- [ ] Rollback procedure tested in staging.
"Feels ready" is not a checklist item.
## 4. Rollback criteria — be specific
A rollback plan that says "we'll roll back if it breaks" is not a plan.
Specific signals with thresholds:
- Error rate on the new flow > 1% over 5 minutes → rollback.
- North Star metric drops > 10% in 24h vs baseline → rollback.
- Support ticket volume > 3× normal for the affected area → rollback.
- A confirmed data-corruption incident → immediate rollback.
For each signal: who decides, how quickly, and the procedure. Test the
rollback procedure in staging before relying on it.
## 5. Post-launch watch period
Each phase has a **soak time** — how long it must be stable before advancing.
- Internal: a few days of real use.
- Beta: 1–2 weeks of normal usage.
- Canary 1%: 24–48h with no signal trip.
- Canary 10%: 2–3 days.
- Canary 50% → GA: 3–7 days.
Do not advance during a weekend or holiday unless someone is actively
watching.
## 6. Anti-patterns to avoid
- "Big bang" launches with no rollback path.
- Beta cohort with no feedback channel (it is just a small launch).
- Readiness checklists with non-testable items ("looks good", "feels right").
- Rollback "criteria" that are not specific signals.
- Advancing phases because the calendar says so, not because the signals do.
- No defined decision-maker for rollback — paralysis when it matters.
## 7. Output shape
A launch plan that shows: phased rollout with named phases and gates; beta
cohort spec; per-phase testable readiness checklists; specific rollback
criteria + procedure + decision-maker; per-phase watch period.