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. ## Proposes Actions Once the checklist is approved, it can be *executed*: hand the items to [`action-runner`](../action-runner/SKILL.md), which previews them (dry-run, risk-rated), runs only what you approve via the connected action MCP (GitHub/Linear/Slack), and records what was done back to the brain. Typical: **open an issue per checklist item** in the named repo/project (🟡), and **post the launch summary to Slack** (🔴 — approved individually). This skill proposes; action-runner gates and runs — never silently. ## 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
Design 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.
Decode a 401k or workplace retirement plan — the real cost of its funds, the match's fine print, vesting math, and the plan features worth using or avoiding. Use when someone asks 'is my 401k any good', 'decode my 401k plan', 'which funds should I look at', or 'what fees am I paying'. Produces a fee decode in dollars-over-time, match and vesting math, a fund-lineup triage by cost, and the questions for HR or the plan administrator.
Design 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.
Analyse a finished A/B test and write the readout — the result, whether it's statistically and practically significant, what it means, and the ship/no-ship call. Use when asked to analyse experiment results, write an A/B test readout, interpret test data, or decide whether to ship a variant. Produces a clear verdict with the lift and confidence, segment cuts, the risks (peeking, novelty, sample), and a recommendation. Distinct from planning a test — this reads results.
Generate 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.
Plan a trip that actually works with a disability or access need — confirm real accessibility (not just 'accessible' labels), book the assistance in advance, plan for equipment and medication, and build in the contingencies for when access breaks down. Use when someone says 'plan an accessible trip', 'travelling with a wheelchair/disability', 'book assistance for my flight', or 'will this hotel actually work for me'. Produces an access-verified itinerary, an assistance-booking checklist, an equipment/medication plan, and contingency scripts. Verify specifics with providers.
Request a reasonable accommodation at work or in education — frame it around the barrier and the adjustment (not your diagnosis), cite the right process, and navigate the back-and-forth constructively. Use when someone says 'I need a workplace accommodation', 'request reasonable adjustments', 'ADA/Equality Act accommodation', or 'how do I ask for accommodations for my disability/condition'. Produces the request letter, a barriers-and-adjustments map, disclosure guidance, and a plan for the interactive process. Not legal advice — routes to the formal process and to advocacy where needed.
Build 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.