Deliver Launch Checklist

<!-- PM-Skills | https://github.com/product-on-purpose/pm-skills | Apache 2.0 -->

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

When NOT to Use

• You are validating whether to ship at all via an experiment -> use measure-experiment-design
• You need the customer-facing announcement of what shipped -> use deliver-release-notes
• The launch already happened and you want results or reflection -> use measure-experiment-results or iterate-retrospective
• 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

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. 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.

Quality Checklist

Before finalizing, verify:

• [ ] All functional areas are represented
• [ ] Every item has an owner and target date
• [ ] Blockers are clearly distinguished from nice-to-haves
• [ ] Go/No-Go criteria are specific and measurable
• [ ] Rollback plan is documented and tested
• [ ] Check-in cadence is scheduled

Examples

See references/EXAMPLE.md for a completed example.