# Deliver launch checklist Human Guide ## What This Is For Provides a structured deliver launch checklist workflow for marketing teams, with reusable guidance and review steps. It gives the agent a clearer input/output frame for growth marketing: what context to ask for, what decisions to make, and what usable artifact to return. Use this as a human-readable version of the Deliver launch checklist agent skill. It is meant for marketers, operators, founders, and other non-coders who want the workflow without reading agent-specific implementation instructions. ## When To Use This - Use this when you need a repeatable process for deliver launch checklist. - Use this when the task needs judgment, examples, constraints, or a clear output format rather than a one-off prompt. - Use this when you want to hand an AI assistant enough context to produce a usable marketing artifact. ## When Not To Use This - Do not use this when you only need a quick factual answer. - Do not use this when the work depends on private data you cannot share with the assistant. - Do not use this as a replacement for legal, compliance, financial, or medical review. ## What You Need Before Starting - The goal or business outcome you want. - The audience, customer segment, or market context. - Any source material the assistant should respect, such as notes, briefs, examples, URLs, or brand guidance. - Constraints such as tone, length, channel, deadline, region, or approval requirements. - A clear definition of what a good final answer should look like. ## Step-By-Step Workflow 1. State the job clearly: "Use the Deliver launch checklist guide to help me with..." 2. Add context: audience, goal, offer, channel, source material, and constraints. 3. Ask the assistant to identify missing inputs before producing the final output. 4. Have the assistant follow the skill-specific guidance below. 5. Review the result against the final checklist and ask for revisions where needed. ## Skill-Specific Guidance - 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 - 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 - Gather Functional Requirements - Identify Dependencies and Blockers - [ ] All functional areas are represented ## Decision Points And Nuance The original skill emphasizes: When to Use, When NOT to Use, Instructions, Output Format, Quality Checklist, Examples, Supporting file: HISTORY.md, 2.2.0 (2026-07-04), Changes, 2.1.0 (2026-06-10). Use these questions to steer the work: - What is the intended audience or buyer? - What source material must be preserved? - What should the assistant optimize for: clarity, persuasion, accuracy, speed, creativity, or conversion? - What examples represent the desired quality bar? - What should the assistant avoid? ## Common Mistakes - 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. - Establish clear criteria for making the launch decision. What conditions must be met? Who makes the final call? - "q": "Last launch we forgot to brief the support team and it was a mess; set up the readiness tracking so that never happens again", - | Security review not yet started | Security Team | Scheduled Mar 3 | BLOCKER - must complete before launch | ## Copy-And-Paste Prompt ```text Use the Deliver launch checklist human guide. My goal: [Describe the business outcome] Audience: [Describe who this is for] Context and source material: [Paste notes, examples, links, or existing copy] Constraints: [Tone, length, channel, timeline, must-include items, must-avoid items] Before producing the final output, ask me for any missing information that would materially improve the result. ``` ## Final Checklist - [ ] The output matches the original goal. - [ ] The audience and context are reflected in the answer. - [ ] Important constraints and source material were preserved. - [ ] The assistant made the relevant decisions explicit. - [ ] The final artifact is ready to use, review, or hand to the next person. ## Source This guide was generated from the product-on-purpose/pm-skills skill entry for `deliver-launch-checklist`. ## Source Skill Notes These notes preserve the nuance from the original skill. Use them as supporting reference when the workflow above feels too generic. # 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. --- ## Supporting file: HISTORY.md # deliver-launch-checklist - Version History | Version | Date | Release | Effort | Type | Summary | |---------|------|---------|--------|------|---------| | 2.2.0 | 2026-07-04 | v2.30.0 | M-35 | minor | Rewrote the frontmatter description: added the owners/dates/go-no-go specifics, a scope boundary against small single-team changes, and the sibling deflection to `deliver-release-notes` (2026-07-04 deep audit, Batch 5). | | 2.1.0 | 2026-06-10 | v2.26.0 | F-12-batch-1 | minor | Quality convergence: When NOT to Use + output-contract enumeration (F-12 Batch 1) | | 2.0.0 | 2026-01-26 | - | - | baseline | Prior published version | ## 2.2.0 (2026-07-04) Released in [v2.30.0](../../site/src/content/docs/releases/Release_v2.30.0.md). Effort: M-35 (trust repair sweep). The 2026-07-04 deep audit named this description as generic, with none of the "When NOT to Use" section's existing boundaries (against `deliver-release-notes`, `measure-experiment-design`, and small single-team changes) surfaced up front.