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:

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

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

3. Assign Owners and Dates Every checklist item needs an owner and a target completion date. Ownership creates accountability; dates enable tracking.

4. Identify Dependencies and Blockers Flag items that block other work or are blocked by external factors. Surface these early so teams can unblock.

5. Define Go/No-Go Criteria Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call?

6. Document Rollback Plan Every launch should have a rollback strategy. Document how to revert if critical issues emerge post-launch.

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

deliver-launch-checklist - Version History

2.1.0 (2026-06-10)

Quality-convergence minor (F-12 Batch 1): added a "When NOT to Use" section with boundary pointers to neighboring skills, and the Output Format now enumerates the template sections a complete artifact fills. No template or example changes.

2.0.0 (2026-01-26)

Baseline row for the prior published version; see git history for its changes.

Launch Checklist: TaskFlow Mobile v3.0

Launch Overview

Key Stakeholders

Engineering Readiness

QA & Testing

Design & UX

Marketing & Communications

Customer Support

Legal & Compliance

Operations & Infrastructure

Analytics & Monitoring

Go/No-Go Criteria

Must Have (Blockers)

• [x] All P0 bugs resolved
• [x] Security review complete (BLOCKED - scheduled Mar 3-5)
• [x] Performance benchmarks met
• [x] UAT sign-off from 10+ stakeholders (8/12 complete)
• [ ] On-call rotation confirmed for launch week
• [x] Rollback plan tested

Should Have

• [x] Marketing materials ready
• [ ] App store listing updated with new screenshots
• [x] Support team training complete

Nice to Have

• [ ] Launch blog post published same day
• [ ] Social media campaign live at launch

Rollback Plan

Trigger Conditions

• Crash rate >2% (baseline: 0.3%)
• Error rate >5% on any critical API
• Major functionality broken (login, task creation, sync)
• Security vulnerability discovered

Rollback Steps

1. Disable feature flags (recurring_tasks_enabled, new_nav_enabled) 2. If flag disable insufficient: Push App Store emergency update reverting to v2.9 3. Communicate to users via in-app banner and email 4. Post incident channel update (#launch-v3-war-room)

Rollback Owner

David Park - david@taskflow.io - +1-555-0123

Rollback Time Estimate

• Feature flag disable: <5 minutes
• App store rollback: 24-48 hours (Apple review)

Check-in Schedule

Open Issues

Launch Checklist: [Launch Name]

Launch Overview

Key Stakeholders

Engineering Readiness

QA & Testing

Design & UX

Marketing & Communications

Customer Support

Legal & Compliance

Operations & Infrastructure

Analytics & Monitoring

Go/No-Go Criteria

Must Have (Blockers)

<!-- Items that MUST be complete to launch -->

• [ ] [Blocker 1]
• [ ] [Blocker 2]
• [ ] [Blocker 3]

Should Have

<!-- Items we strongly prefer but can launch without -->

• [ ] [Should-have 1]
• [ ] [Should-have 2]

Nice to Have

<!-- Items we'd like but won't delay launch -->

• [ ] [Nice-to-have 1]
• [ ] [Nice-to-have 2]

Rollback Plan

Trigger Conditions

<!-- When would we roll back? -->

• [Condition 1]
• [Condition 2]

Rollback Steps

1. [Step 1] 2. [Step 2] 3. [Step 3]

Rollback Owner

[Name] - [Contact]

Rollback Time Estimate

[Duration]

Check-in Schedule

Open Issues

<!-- Unresolved items that could affect launch -->