launch-readiness
The launch-readiness skill systematically evaluates product and feature readiness across product, engineering, marketing, support, sales, and analytics functions, then delivers a documented Go, Conditional Go, or No-Go recommendation. Use this skill when preparing any product launch or major feature release to identify blockers with assigned owners and deadlines, surface risks requiring mitigation, and confirm that rollback plans are tested and viable before shipping.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/launch-readiness && cp -r /tmp/launch-readiness/plugins/pm-delivery/skills/launch-readiness ~/.claude/skills/launch-readinessSKILL.md
# Launch Readiness Skill Ensure nothing falls through the cracks before launch by systematically checking readiness across every function — and producing a clear, evidenced go/no-go recommendation. ## Required Inputs Ask the user for these if not provided: - **Launch name and target date** - **Launch tier** (Tier 1 = major launch / Tier 2 = significant feature / Tier 3 = incremental update) - **Completed checklist items or self-assessment** (even partial is fine — we'll surface gaps) - **Team and role names** (to assign owners to blockers) ## Readiness Checklist by Function ### Product & Engineering - [ ] Feature complete against launch spec - [ ] Performance benchmarks met - [ ] Accessibility standards checked - [ ] Edge cases documented and handled - [ ] Rollback plan defined and tested ### Marketing & Comms - [ ] Launch messaging approved - [ ] Blog post / press release drafted - [ ] Social content prepared - [ ] Email campaigns scheduled - [ ] Landing page live and tested ### Support & Success - [ ] Support team trained on new feature - [ ] FAQ and help docs published - [ ] Escalation path defined for launch issues - [ ] Customer success briefed (if enterprise) ### Sales & Partnerships - [ ] Sales enablement materials ready - [ ] Pricing confirmed and communicated - [ ] Partner comms sent (if applicable) ### Data & Analytics - [ ] Tracking events implemented and verified - [ ] Launch metrics dashboard live - [ ] Baseline metrics captured pre-launch ## Process 1. Review provided launch brief and checklist responses 2. Flag any incomplete items as blockers (must fix) or risks (monitor) 3. Assess overall readiness and produce go/no-go recommendation with rationale 4. If no-go, specify exactly what must be completed and by when 5. **Validate** — Confirm every blocker has a named owner and resolution deadline, and that the rollback plan is tested (not just documented) ## Output Structure ### Launch Readiness Assessment: [Feature/Product Name] **Launch Date:** [date] **Launch Tier:** [1 / 2 / 3] **Overall Status:** ✅ Go / ⚠️ Conditional Go / 🛑 No-Go **Blockers (must resolve before launch):** - [item + owner + resolution required by] **Risks (monitor closely):** - [item + mitigation plan] **Ready Areas:** - [function]: ✅ Ready **Recommendation:** [Clear go/no-go with rationale — 3-5 sentences] ## Quality Checks - [ ] Every blocker has a specific owner (not "the team") and a deadline - [ ] Rollback plan is explicitly tested, not just written - [ ] Analytics events are verified in staging, not just implemented - [ ] Go/No-Go decision has a named decision-maker and a cut-off time - [ ] At least one post-launch monitoring check is scheduled (e.g., T+2hr, T+24hr) ## Anti-Patterns - [ ] Do not mark a function as "Ready" without evidence — green status must be backed by a completed checklist item, not an assumption - [ ] Do not issue a Conditional Go without specifying exactly what conditions must be met and by when — vague conditions are not conditions - [ ] Do not treat the rollback plan as complete unless it has been tested in staging, not just documented - [ ] Do not assign blockers to "the team" — every blocker must have a single named owner or it will not be resolved before launch - [ ] Do not skip the analytics verification step — unverified tracking events mean the launch will be invisible and cannot be evaluated
Conduct a structured ethical review of an AI or ML feature, model, or product. Use when preparing to deploy an AI system, assessing algorithmic risk, auditing a model for bias, or producing a responsible AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with a risk tier score, pre-deployment checklist, and prioritised mitigations.
Structure AI and ML product decisions with the rigour of any product decision. Use when building AI-powered features, evaluating LLM integrations, designing AI products, or assessing AI readiness. Produces a complete AI product canvas covering problem definition, model approach, data requirements, evaluation framework, UX design, responsible AI checklist, and launch monitoring plan.
Transform feature briefs into structured design briefs that give designers the context they need before opening Figma. Use when asked to write a design brief, create a design handoff, brief a designer on a new feature, or translate a PRD into design requirements. Produces a brief with user goal, emotional context, success criteria, constraints, edge cases, and out-of-scope boundaries.
Design statistically rigorous A/B tests and interpret experiment results. Use when asked to design an experiment, run an A/B test, calculate sample size, interpret test results, or assess whether an experiment was successful. Produces a complete experiment design with hypothesis, sample size, run time, success criteria, and risk flags — or a results interpretation with ship/iterate/kill recommendation.
Synthesises user signals from multiple research sources into a unified, weighted insight brief. Use when you have data from interviews, support tickets, NPS verbatims, app reviews, or sales calls and need to reconcile contradictions, surface the underlying need behind requests, or answer 'what are users really telling us'. Produces ranked insights with confidence ratings, source weighting rationale, divergent signal analysis by user segment, and a research gap identification section.
Structure a product data analysis, metric deep-dive, funnel analysis, or cohort study. Use when asked to analyse product metrics, investigate a drop in conversion, explain a data change to stakeholders, or find the root cause of a metric movement. Produces a structured analysis with question, root cause, confidence level, and recommended action.
Interpret product metrics against goals and surface actionable signals. Use when asked to analyse product health, review key metrics, investigate a performance issue, produce a health report, or assess product-market fit signals. Produces a structured health report with RAG status, trend analysis, root cause hypotheses, and prioritised actions.
Structure a retention analysis, churn investigation, or engagement deep-dive for any product team. Use when asked to analyse user retention, investigate churn, measure DAU/MAU, or build a retention improvement plan. Produces a retention snapshot with root cause hypotheses, aha-moment correlation, and prioritised interventions.