Launch Plan

---
name: launch-plan
description: Plan a release or go-to-market — when asked how to launch a feature/product, announce a version, run a campaign, or "what should we do for the launch". Produces a dated plan with owners and channels.
description_ru: Спланировать релиз или выход на рынок — когда спрашивают, как запустить фичу или продукт, анонсировать версию, провести кампанию, «что делаем на запуск». Даёт план с датами, ответственными и каналами.
triggers: запуск продукта, запуск фичи, план запуска, лонч, launch, релиз, release, go to market, gtm, вывод на рынок, кампания, campaign, анонс, announcement
---

# Launch plan

## 1. Define the launch
- **What** ships, in one sentence a user understands.
- **Tier**: silent (changelog only) / standard (blog + email + social) / major (campaign, press, partners). Most releases are not major — matching the tier to reality saves the audience's attention for when it matters.
- **Goal**: one number this launch should move (signups, activations, upgrades), plus the current baseline. No baseline means no way to judge it.
- **Date**, and what must be true to hold it.

## 2. Check readiness before promotion
Nothing goes out until: the feature works for a new user with no hand-holding, docs exist, pricing/limits are decided, support knows what to answer, and there is a rollback. A launch that drives traffic to a broken first-run is worse than no launch.

## 3. Sequence the audience
Order by risk, narrowest first: internal → existing power users / beta → all customers → public. Each stage has a stop condition — what you would have to see to pause.

## 4. Assets per channel
For each channel you actually use, list the asset and its one job:
- Changelog / release notes — what changed, for existing users.
- Docs page — how to use it.
- Email — to the segment who asked for it; one CTA.
- Blog / announcement — the why and the outcome, with a screenshot or demo.
- Social — one hook per post, spread over days, not one blast.
- In-app — where a user meets the feature at the moment it is useful.
- Community / forums / partners — only where you already have standing.

Skip any channel you have no audience on. Three well-made assets beat nine placeholders.

## 5. Timeline
Work backwards from the date: T-7 assets drafted and reviewed, T-3 docs and support ready, T-1 staged and dry-run, T-0 ship then publish in a fixed order, T+1 monitor and answer, T+7 measure against the goal and write down what happened.

Assign a name to each item. An item without an owner does not happen.

## 6. Risks
List the three most likely failures (load, a broken flow, a pricing objection, silence) and the response to each.

## What not to do
- Do not launch on a Friday or into a holiday.
- Do not announce what is not fully rolled out.
- Do not measure "impressions" as success when the goal was activations.
- Do not skip the retro — the plan's value is mostly in the next one.

## Answer format
A table: date → item → channel → owner → status. Then goal + baseline, the readiness checklist, and the risks with responses. Keep it to one page.