product-launch-checklist

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