product-launch-checklist
This skill generates a tiered, role-assigned checklist for product launches covering pre-launch readiness, launch day execution, and post-launch monitoring. Use it when preparing for a product release, significant feature rollout, or major update to ensure all teams (engineering, marketing, support, product) have aligned tasks, clear ownership, and documented procedures across three phases.
git clone --depth 1 https://github.com/mohitagw15856/pm-claude-skills /tmp/product-launch-checklist && cp -r /tmp/product-launch-checklist/plugins/pm-delivery/skills/product-launch-checklist ~/.claude/skills/product-launch-checklistSKILL.md
# Product Launch Checklist Skill Never launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring. ## Required Inputs Ask the user for these if not provided: - **Launch name** and planned launch date - **Launch tier** (1 = major product launch, 2 = significant feature release, 3 = incremental update) - **Team members and their roles** (engineering lead, PM, marketing, support, etc.) - **Feature description** (what is being launched) - **Rollback capability** (can this be feature-flagged or reverted quickly?) ## How to Use This Skill Provide: - Launch name and date - Launch tier (1 = major, 2 = feature, 3 = incremental) - Team members and their roles The skill generates a tiered checklist. Tier 3 launches use only the Essentials section. Tier 2 adds Marketing & Comms. Tier 1 uses all sections. --- ## Output Format ### Launch Checklist — [Feature/Product Name] — Target Date: [Date] **Launch Tier:** [1 / 2 / 3] **Launch Owner:** [PM Name] **Engineering Lead:** [Name] **Go/No-Go Decision By:** [Date and time — typically 24 hours before launch] --- ### 🔧 PRE-LAUNCH — Engineering & Product (T-2 weeks) - [ ] Feature flag created and tested in staging - [ ] All acceptance criteria signed off by PM - [ ] Code reviewed and merged to main - [ ] QA sign-off completed (regression + new feature) - [ ] Performance testing completed (load, latency) - [ ] Security review completed (if data or auth changes) - [ ] Rollback procedure documented and tested - [ ] Monitoring and alerting configured - [ ] Error logging in place with correct severity levels - [ ] Database migrations tested on staging with production data volume ### 📢 PRE-LAUNCH — Marketing & Comms (T-1 week) - [ ] Blog post written, reviewed, and scheduled - [ ] In-app announcement or tooltip configured - [ ] Email campaign drafted and QA'd - [ ] Social media posts drafted and scheduled - [ ] Landing page or feature page live in staging - [ ] Press outreach sent (Tier 1 only) - [ ] Product Hunt / community posts prepared (Tier 1 only) ### 🎓 PRE-LAUNCH — Sales & Support (T-1 week) - [ ] Sales enablement one-pager completed - [ ] FAQ document shared with sales and support teams - [ ] Help centre articles written and published - [ ] Support team demo / training completed - [ ] Customer success team briefed on top accounts - [ ] Pricing updated (if applicable) - [ ] Contracts / ToS updated (if applicable) ### 📊 PRE-LAUNCH — Analytics (T-1 week) - [ ] Analytics events firing correctly in staging - [ ] Dashboard configured for launch metrics - [ ] Baseline metrics documented - [ ] Success criteria documented and shared with team - [ ] A/B test configured (if applicable) --- ### ✅ GO / NO-GO DECISION — T-24 hours | Criteria | Status | Owner | |---|---|---| | All critical bugs resolved | 🟢 / 🔴 | Eng Lead | | QA sign-off complete | 🟢 / 🔴 | QA | | Rollback tested | 🟢 / 🔴 | Eng Lead | | Help centre articles live | 🟢 / 🔴 | Support | | Monitoring active | 🟢 / 🔴 | Eng Lead | | PM sign-off | 🟢 / 🔴 | PM | **Go / No-Go Decision:** [GO / NO-GO] **Decision Owner:** [PM + Eng Lead jointly] --- ### 🚀 LAUNCH DAY - [ ] Feature flag enabled for [X%] of users (start low — 5–10%) - [ ] Launch confirmed in team Slack/channel - [ ] Metrics dashboard open and being monitored - [ ] Error rate checked at T+15 min, T+1 hr, T+4 hr - [ ] Blog post published / email sent - [ ] Social posts live - [ ] Support team on standby for first 4 hours - [ ] PM available and reachable all day - [ ] Feature flag expanded to 50% if T+2hr checks pass - [ ] Feature flag expanded to 100% if T+4hr checks pass --- ### 📈 POST-LAUNCH (D+7, D+30) - [ ] D+7 metrics review: adoption, errors, support tickets - [ ] D+7 customer feedback synthesised - [ ] Retrospective scheduled - [ ] Learnings documented - [ ] D+30 success metrics reviewed against targets - [ ] Feature flag removed from codebase (clean up) - [ ] Follow-up features added to backlog based on feedback --- ## Quality Checks - [ ] Launch tier confirmed before generating checklist (scope determines depth) - [ ] Go/No-Go decision has a named owner and a specific decision time - [ ] Rollback procedure is documented and tested (not just planned) - [ ] Feature flag expansion is staged (5% → 50% → 100%), not all-at-once - [ ] Post-launch retrospective is scheduled at launch time ## Anti-Patterns - [ ] Do not apply a Tier 1 checklist to an incremental update — tier the launch appropriately before generating the checklist - [ ] Do not launch on a Friday without confirmed weekend engineering coverage - [ ] Do not leave the Go/No-Go decision owner as "the team" — it must be a named individual - [ ] Do not skip the rollback plan for Tier 1 and 2 launches — know the revert time before going live - [ ] Do not close the launch without scheduling the post-launch retrospective — it must be booked at launch time, not after ## Guidelines - The Go/No-Go decision must have a named owner — "the team" is not an owner - Never launch on a Friday unless you have weekend engineering coverage - Recommend starting all launches at <10% traffic — even for simple features - Document rollback time: "We can revert this in X minutes" should be known before launch
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.