Mehdibargach Launch Checklist Generator
Generate a complete, product-specific launch checklist from a product or feature description. Covers pre-launch, launch day, and post-launch — with owners, timing, and blocking dependencies.
Process
- Read the product or feature description.
- Identify the type of launch (new product, major feature, minor update, beta) to calibrate checklist depth.
- Generate a checklist tailored to this specific product — not a generic template.
- Flag blocking items versus nice-to-have items.
- Include timing (T-2 weeks, T-1 week, Launch day, T+1 day, T+1 week).
- Save the output to a file in the current working directory as
launch-checklist-[product-name].md.
Output Format
Launch Overview
- Product/Feature: [name]
- Target launch date: [date or TBD]
- Launch type: New product / Major feature / Minor update / Beta
- Target audience: [specific]
Pre-Launch (T-2 weeks to T-1 day)
Each item format: - [ ] [Specific item] — **Owner:** [role] — **Blocking:** Yes/No — **Due:** [timing]
Internal Readiness
Generate 4-6 items specific to this product covering: engineering sign-off, QA, performance testing (if applicable), rollout strategy, and rollback plan. Only include items relevant to the launch type.
Documentation & Support
Generate 3-5 items specific to this product covering: user-facing docs, support team enablement, and internal knowledge base. Tailor to the product's support model.
Communications Prep
Generate 3-5 items specific to this product covering: release notes, announcements (channels depend on product), and sales/CS enablement. Only include channels relevant to this product's audience.
Launch Day (T-0)
Rollout
Generate 3-5 items covering: deployment, verification, monitoring, and on-call. Tailor to the product's deployment model (staged rollout, feature flag, big bang, etc.).
Communications
Generate 3-5 items covering: publishing announcements and notifying internal teams. Only include channels relevant to this product.
Monitoring
Generate 3-4 items covering: error rates, performance, user-reported issues, and support volume. Reference specific metrics from the product description.
Post-Launch (T+1 day to T+2 weeks)
First 24 Hours
Generate 3-4 items covering: monitoring review, support triage, initial feedback, and rollout expansion decision.
First Week
Generate 4-5 items covering: metrics tracking against targets, feedback review, bug triage, full rollout, and retrospective.
First Two Weeks
Generate 3-4 items covering: stakeholder metrics review, fast-follow prioritization, roadmap updates, and launch documentation.
Stakeholder Checklist
| Stakeholder | What they need to know | By when | Owner | Status |
|---|---|---|---|---|
| [Engineering lead] | [Specific info] | [Date] | [Who tells them] | [ ] |
| [Support team] | [Specific info] | [Date] | [Who tells them] | [ ] |
| [Sales team] | [Specific info] | [Date] | [Who tells them] | [ ] |
| [Executive sponsor] | [Specific info] | [Date] | [Who tells them] | [ ] |
| [Marketing] | [Specific info] | [Date] | [Who tells them] | [ ] |
Rules
- Be specific to the product. "Prepare marketing materials" is generic. "Draft announcement email highlighting [specific feature benefit] for [specific audience]" is specific.
- Every item must have a clear owner role (not necessarily a name, but a role).
- Clearly mark what is BLOCKING launch versus nice-to-have. A launch should not be held for non-blocking items.
- Include timing relative to launch date (T-2w, T-1w, T-1d, T-0, T+1d, T+1w).
- Adapt the depth to the launch type. A minor bug fix does not need a full GTM checklist. A new product does.
- The stakeholder checklist must include specific information per stakeholder, not just "inform them."
- If the product description is too vague to generate specific checklist items, list what information is needed first.