deliver-launch-checklist

Name: deliver-launch-checklist
Author: product-on-purpose

486stars64forks

How to install deliver-launch-checklist?

product-on-purpose/pm-skills/deliver-launch-checklist

$npx -y skills add product-on-purpose/pm-skills --skill deliver-launch-checklist

Installs into the current project.

Summary

Creates a cross-functional pre-launch checklist covering engineering, design, marketing, support, legal, and operations readiness, with owners, dates, and go/no-go criteria so nothing is missed before release. Use for significant or cross-team launches, not a small single-team ch

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Launch Checklist
3
4	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.
5
6	## When to Use
7
8	- 1-2 weeks before any significant launch
9	- During launch planning kickoff meetings
10	- When coordinating cross-functional releases
11	- Before major version releases or feature rollouts
12	- After incidents to improve launch processes
13
14	## When NOT to Use
15
16	- You are validating whether to ship at all via an experiment -> use `measure-experiment-design`
17	- You need the customer-facing announcement of what shipped -> use `deliver-release-notes`
18	- The launch already happened and you want results or reflection -> use `measure-experiment-results` or `iterate-retrospective`
19	- The change is small and single-team with no cross-functional surface: a launch checklist adds ceremony without value; track it in the sprint instead
20
21	## Instructions
22
23	When asked to create a launch checklist, follow these steps:
24
25	1. Define Launch Context
26	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.
27
28	2. Gather Functional Requirements
29	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.
30
31	3. Assign Owners and Dates
32	Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
33
34	4. Identify Dependencies and Blockers
35	Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
36
37	5. Define Go/No-Go Criteria
38	Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
39
40	6. Document Rollback Plan
41	Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
42
43	7. Schedule Check-in Cadence
44	Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
45
46	## Output Format
47
48	Use the template in `references/TEMPLATE.md` to structure the output. A complete checklist fills every template section: Launch Overview; Engineering Readiness; QA & Testing; Design & UX; Marketing & Communications; Customer Support; Legal & Compliance; Operations & Infrastructure; Analytics & Monitoring; Go/No-Go Criteria; Rollback Plan; Check-in Schedule; and Open Issues.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] All functional areas are represented
55	- [ ] Every item has an owner and target date
56	- [ ] Blockers are clearly distinguished from nice-to-haves
57	- [ ] Go/No-Go criteria are specific and measurable
58	- [ ] Rollback plan is documented and tested
59	- [ ] Check-in cadence is scheduled
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type

deliver-launch-checklist

486stars64forks

View on GitHub

How to install deliver-launch-checklist?

product-on-purpose/pm-skills/deliver-launch-checklist

$npx -y skills add product-on-purpose/pm-skills --skill deliver-launch-checklist

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	<!-- PM-Skills \| https://github.com/product-on-purpose/pm-skills \| Apache 2.0 -->
2	# Launch Checklist
3
4	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.
5
6	## When to Use
7
8	- 1-2 weeks before any significant launch
9	- During launch planning kickoff meetings
10	- When coordinating cross-functional releases
11	- Before major version releases or feature rollouts
12	- After incidents to improve launch processes
13
14	## When NOT to Use
15
16	- You are validating whether to ship at all via an experiment -> use `measure-experiment-design`
17	- You need the customer-facing announcement of what shipped -> use `deliver-release-notes`
18	- The launch already happened and you want results or reflection -> use `measure-experiment-results` or `iterate-retrospective`
19	- The change is small and single-team with no cross-functional surface: a launch checklist adds ceremony without value; track it in the sprint instead
20
21	## Instructions
22
23	When asked to create a launch checklist, follow these steps:
24
25	1. Define Launch Context
26	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.
27
28	2. Gather Functional Requirements
29	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.
30
31	3. Assign Owners and Dates
32	Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.
33
34	4. Identify Dependencies and Blockers
35	Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.
36
37	5. Define Go/No-Go Criteria
38	Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?
39
40	6. Document Rollback Plan
41	Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.
42
43	7. Schedule Check-in Cadence
44	Establish when the team will review checklist progress (daily standups, T-2 days review, launch day sync).
45
46	## Output Format
47
48	Use the template in `references/TEMPLATE.md` to structure the output. A complete checklist fills every template section: Launch Overview; Engineering Readiness; QA & Testing; Design & UX; Marketing & Communications; Customer Support; Legal & Compliance; Operations & Infrastructure; Analytics & Monitoring; Go/No-Go Criteria; Rollback Plan; Check-in Schedule; and Open Issues.
49
50	## Quality Checklist
51
52	Before finalizing, verify:
53
54	- [ ] All functional areas are represented
55	- [ ] Every item has an owner and target date
56	- [ ] Blockers are clearly distinguished from nice-to-haves
57	- [ ] Go/No-Go criteria are specific and measurable
58	- [ ] Rollback plan is documented and tested
59	- [ ] Check-in cadence is scheduled
60
61	## Examples
62
63	See `references/EXAMPLE.md` for a completed example.

People who liked this also viewed

6 picks

Type