name: deliver-launch-checklist
description: Creates a comprehensive pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness. Use before releasing features, products, or major updates to ensure nothing is missed.
phase: deliver
version: "2.0.0"
updated: 2026-01-26
license: Apache-2.0
metadata:
category: coordination
frameworks: [triple-diamond, lean-startup, design-thinking]
author: product-on-purpose
Launch Checklist
A launch checklist is a comprehensive verification document that ensures all functions are ready before releasing a feature or product. It coordinates across engineering, QA, design, marketing, support, legal, and operations to prevent launch-day surprises. Good launch checklists surface blockers early and create shared accountability for launch readiness.
When to Use
- 1-2 weeks before any significant launch
- During launch planning kickoff meetings
- When coordinating cross-functional releases
- Before major version releases or feature rollouts
- After incidents to improve launch processes
Instructions
When asked to create a launch checklist, follow these steps:
Define Launch Context
Document what is launching, when, and who the key stakeholders are. Establish the launch tier (major release, minor feature, experiment) as this affects checklist scope.
Gather Functional Requirements
For each function (engineering, QA, marketing, etc.), identify what must be complete, verified, or in place before launch. Distinguish between blockers (must-have) and nice-to-haves.
Assign Owners and Dates
Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
Identify Dependencies and Blockers
Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
Define Go/No-Go Criteria
Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
Document Rollback Plan
Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
Schedule Check-in Cadence
Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
Output Format
Use the template in references/TEMPLATE.md to structure the output.
Quality Checklist
Before finalizing, verify:
Examples
See references/EXAMPLE.md for a completed example.
1---2name: deliver-launch-checklist3description: <!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->4---5
6<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->
7---
8name: deliver-launch-checklist
9description: Creates a comprehensive pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness. Use before releasing features, products, or major updates to ensure nothing is missed.
10phase: deliver
11version: "2.0.0"
12updated: 2026-01-26
13license: Apache-2.0
14metadata:
15 category: coordination
16 frameworks: [triple-diamond, lean-startup, design-thinking]
17 author: product-on-purpose
18---
19# Launch Checklist
20
21A launch checklist is a comprehensive verification document that ensures all functions are ready before releasing a feature or product. It coordinates across engineering, QA, design, marketing, support, legal, and operations to prevent launch-day surprises. Good launch checklists surface blockers early and create shared accountability for launch readiness.
22
23## When to Use
24
25- 1-2 weeks before any significant launch
26- During launch planning kickoff meetings
27- When coordinating cross-functional releases
28- Before major version releases or feature rollouts
29- After incidents to improve launch processes
30
31## Instructions
32
33When asked to create a launch checklist, follow these steps:
34
351. **Define Launch Context**
36 Document what is launching, when, and who the key stakeholders are. Establish the launch tier (major release, minor feature, experiment) as this affects checklist scope.
37
382. **Gather Functional Requirements**
39 For each function (engineering, QA, marketing, etc.), identify what must be complete, verified, or in place before launch. Distinguish between blockers (must-have) and nice-to-haves.
40
413. **Assign Owners and Dates**
42 Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
43
444. **Identify Dependencies and Blockers**
45 Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
46
475. **Define Go/No-Go Criteria**
48 Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
49
506. **Document Rollback Plan**
51 Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
52
537. **Schedule Check-in Cadence**
54 Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
55
56## Output Format
57
58Use the template in `references/TEMPLATE.md` to structure the output.
59
60## Quality Checklist
61
62Before finalizing, verify:
63
64- [ ] All functional areas are represented
65- [ ] Every item has an owner and target date
66- [ ] Blockers are clearly distinguished from nice-to-haves
67- [ ] Go/No-Go criteria are specific and measurable
68- [ ] Rollback plan is documented and tested
69- [ ] Check-in cadence is scheduled
70
71## Examples
72
73See `references/EXAMPLE.md` for a completed example.
majiayu000