| name | launch-plan |
| description | Builds a go-to-market launch plan for a feature or product, scaled to a launch tier. Use when someone asks to "plan the launch", build a "go-to-market plan" or "GTM for the new feature", needs a "launch checklist for X", or asks "how should we launch this". Produces audience, messaging, channels, a pre/launch/post timeline with owners, assets, success metrics, and a launch-day runbook. |
| tier | campaign |
| time | 2-8 weeks |
| inputs | the launch date, the segment, and the readiness gaps |
| outputs | projects/<project>/launch-plan.md |
Launch Plan
A launch is a cross-functional event, not a ship date. This skill turns "we're shipping X" into a coordinated plan: the right tier of effort, a clear message, the channels that fit, a timeline with owners, the assets you need, the metrics that define success, and a runbook for launch day. Scale everything to impact — not every launch deserves a press release.
Grounded in: Crossing the Chasm — Geoffrey Moore: tier the launch and target the segment that cares most.
Go deeper (The Product Channel): The Beginner's Guide to a Product Launch
When to use this
- A feature or product is about to ship and needs a coordinated rollout
- Marketing, sales, support, and eng need a single source of truth for who does what, when
- You need a launch checklist with owners and dates, not just a vibe
- You want to right-size effort: avoid over-launching a minor change or under-launching a flagship
Pick the launch tier first
Decide impact before anything else — it sets the ceiling for every section below.
- T1 (major) — new product, flagship feature, repositioning. Full GTM: all channels, exec involvement, sales enablement, press/analyst, coordinated timeline, dry run.
- T2 (standard) — notable feature, meaningful expansion. Targeted comms on key channels (blog, email, in-app, social), light sales/support enablement, single owner per task.
- T3 (minor) — incremental improvement, fast-follow, fix. Changelog entry + in-app note + maybe one social post. No campaign.
Boundary heuristic (apply top-down, first match wins): new product / repositioning / press-worthy → T1; touches a core surface OR moves a top company metric → at least T2; no new user behavior, only a fix or polish → T3.
Scale audience, channels, timeline, assets, and metrics to the tier. When unsure, default down a tier — you can always amplify a winner.
Before you start (gather these)
- What's launching + why it matters — the one-line value to the user
- Target audience / segment — who this is for (all users? a plan tier? a persona?)
- The date — hard date or target window, and what's gating it
- Cross-functional partners — named owners in PM, marketing, sales, support, eng
- Success metric — the one number that says this worked
Ask for anything missing before drafting — don't invent a date, an owner, or a metric.
Process
Ask before you plan. Ask 2-4 sharp questions first: "What date is real, and what's driving it?" · "Which segment is this launch for — and who is it explicitly not for?" · "What has to be true for us to launch at all?" · "What's the one thing that would make us delay?" A launch plan built on an assumed date and an assumed audience is a checklist, not a plan. Where workspace/strategy/ already answers these, open with an Assumptions block.
- Set the tier. Classify T1/T2/T3 by impact and state why. This caps scope.
- Define audience + core message + proof. Who it's for, the single core message (problem → what changed → why they should care), and the proof (data, demo, customer quote, before/after).
- Choose channels. Pick only channels that fit the tier and reach the audience: changelog, in-app, email, blog, social, docs, sales deck, webinar, press/analyst, community. Don't default to "all."
- Build the timeline (pre / launch / post) with a checklist and owners. Every task gets an owner and a date. Pre-launch: enablement, assets, QA, staged rollout. Launch day: flip the switch, publish, monitor. Post-launch: follow-up comms, metric review, retro.
- List assets needed. Each asset (copy, screenshots, demo, FAQ, sales one-pager, support macros) gets an owner and a due date that lands before launch day.
- Set success metrics + a rollback/abort trigger. Define the target number, the window to hit it, and the explicit condition under which you pause, roll back, or abort.
- Write a launch-day runbook. Hour-by-hour (or step-by-step) sequence: who flips what, in what order, who's watching which dashboard, who comms internally, and the go/no-go checkpoint.
Output template
Copy-paste and fill in.
# Launch Plan: <name>
## Launch summary
- What: <one line on what's shipping>
- Why it matters: <value to the user>
- Tier: <T1 / T2 / T3> — <one line on why>
- Why this tier (evidence): <which boundary rule it hit + the fact behind it — e.g. "moves activation, a top metric" — not a hand-wave>
- Date: <date or window>
## Audience & message
- Audience / segment: <who>
- Core message: <problem → what changed → why they care>
- Proof: <data / demo / quote / before-after>
## Channels
- <channel> — <what goes out, owner>
- <channel> — <what goes out, owner>
- Not doing (and why): <channels deliberately reserved for a higher tier — e.g. "no press/analyst, this is T2">
## Timeline & checklist
### Pre-launch
| Task | Owner | When | Status |
|------|-------|------|--------|
| <task> | <name> | <date> | <todo/doing/done> |
### Launch day
| Task | Owner | When | Status |
|------|-------|------|--------|
| <task> | <name> | <time> | <todo/doing/done> |
### Post-launch
| Task | Owner | When | Status |
|------|-------|------|--------|
| <task> | <name> | <date> | <todo/doing/done> |
## Assets needed
| Asset | Owner | Due |
|-------|-------|-----|
| <asset> | <name> | <date> |
## Success metrics
- Primary: <metric> — target <number> by <date>
- Secondary: <metric(s)>
- What failure looks like: <the number/signal that means it flopped — define the abort thresholds HERE, once; the rollback trigger below references them>
## Launch-day runbook
> The "Launch day" table above is the checklist (what must happen); this runbook is the executable, cold-at-6am sequence derived from it (the exact order, who flips what, who watches what). For T3 — and optionally T2 — the runbook replaces the launch-day table; don't maintain both.
1. <time> — <who> does <what> (go/no-go checkpoint: <condition>)
2. <time> — <who> publishes <channel>
3. <time> — <who> monitors <dashboard/metric>
4. Internal comms: <who> posts in <channel> when <milestone>
## Risks & rollback trigger
- Risk: <risk> → Mitigation: <plan>
- Rollback / abort trigger: if the failure threshold above ("What failure looks like") is hit by <time>, then <pause/roll back/abort> — owner <name>. (Define the number once above; reference it here, don't restate it.)
Avoid (anti-patterns)
- Treating every launch as T1 — over-launching minor changes burns audience goodwill and team effort, and makes the next big launch land softer
- No owner on launch tasks — "the team" owns nothing; every row needs one name
- Shipping with no success metric or no rollback plan — you won't know if it worked and won't know when to pull back
- Marketing / support / sales finding out at launch — surprise launches mean unanswered tickets, off-message reps, and no enablement
- Assets due "by launch" — they need to land days earlier so reps and support can absorb them
Tips
- Write the core message in one sentence first. If you can't, the launch isn't ready.
- Pull support and sales in during pre-launch, not launch day — they're your front line.
- Stage the rollout (internal → beta → % → all) for T1/T2 so the rollback trigger is cheap to pull.
- The runbook is for the person who isn't you. Make it executable cold, at 6am, by whoever's on point.
- Schedule the post-launch retro before launch day — otherwise it never happens.
