product-launch-checklist
$
npx mdskill add mohitagw15856/pm-claude-skills/product-launch-checklistNever launch without checking everything. Generate a complete, role-assigned checklist covering pre-launch readiness, launch day execution, and post-launch monitoring.
SKILL.md
.github/skills/product-launch-checklistView on GitHub ↗
--- name: product-launch-checklist description: "Generate a comprehensive pre-launch, launch day, and post-launch checklist for any product release. Use when preparing for a product launch, feature release, or major update. Produces a role-assigned, tiered checklist covering engineering readiness, marketing and comms, support, and post-launch monitoring." --- # 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. ## 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 ## 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
More from mohitagw15856/pm-claude-skills
- 360-feedback-templateDesign a 360-degree feedback survey or write a structured 360 feedback report. Use when asked to build a 360 feedback process, write 360 feedback for a colleague, design a feedback survey, or produce a feedback report. Produces either a complete survey instrument with rating scales and open-ended questions, or a structured narrative feedback report with themes, strengths, and development areas.
- ab-test-plannerDesign statistically rigorous A/B tests for product features, UI changes, onboarding flows, and pricing experiments. Use when asked to set up an experiment, design an A/B test, calculate sample size, or interpret test results. Produces a complete test plan with hypothesis, variant definitions, sample size, duration estimate, guardrail metrics, and a results interpretation guide.
- accessibility-auditGenerate a WCAG 2.2 accessibility audit checklist and remediation suggestions for any UI or design. Use when asked to audit for accessibility, check WCAG compliance, review a design for a11y issues, or create an accessibility remediation plan. Produces a prioritised checklist with pass/fail assessments and specific fixes.
- account-planBuild a structured account plan for any key customer or target account. Use when asked to create an account plan, key account strategy, strategic account review, or territory plan. Produces a complete account plan with relationship map, growth opportunities, risks, and 90-day action plan.
- aeo-optimizerOptimize an article for Answer Engine Optimization (AEO) — restructuring content so AI engines like ChatGPT, Perplexity, and Claude can extract, quote, and cite it. Rewrites headings as questions, drops 50-80 word answer capsules, audits paragraph length, and flags trust signals. Use when asked to AEO-optimize, make content AI-readable, improve AI citation chances, or adapt an article for answer engines.
- ai-ethics-reviewConduct an ethical review of an AI or ML feature, model, or product. Use when asked to run an AI ethics review, assess AI risks, audit a model for bias, or produce an AI impact assessment. Produces a structured ethics review covering fairness, transparency, privacy, safety, accountability, and societal impact with prioritised mitigations.
- ai-product-canvasStructure 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.
- ambiguity-resolverStructure vague opportunities and unclear briefs into actionable one-page problem statements. Use when asked to clarify a vague brief, frame an undefined problem, make sense of an unclear opportunity, or when the user says 'we need to figure out what to do about X' or 'I've been asked to look into Y'. Produces a structured problem brief with reframed questions, scoped boundaries, and a minimum viable research plan.
- api-docs-writerWrite clear, developer-facing API documentation. Use when asked to document an API endpoint, write API reference docs, create a developer guide, or turn a raw spec/Postman collection into documentation. Produces endpoint documentation with descriptions, parameters, request/response examples, and error codes.
- api-versioning-strategyWrite an API versioning strategy document for a service or API platform. Use when asked to define versioning policy, plan API deprecation, classify breaking changes, or document version lifecycle. Produces a complete versioning strategy with breaking-change classification table, deprecation timeline, migration guide template, and client communication template.