Launch Plan Template

A launch plan earns its keep in the hour when something is going wrong and nobody wants to be the one who says stop. Everything in this template is written for that hour: gates that can actually fail, a rollback someone could execute without improvising, and a named person who owns the call.

Most launch plans are optimistic project schedules. This one is closer to a pre-mortem with dates attached.

When you need one

Write a launch plan when the rollout has more than one phase, or when reverting is harder than flipping a flag. Migrations, pricing changes, anything touching payments or permissions, and any release where a bad hour is expensive all qualify.

Skip it when the feature ships to everyone at once and rollback is a toggle. That case belongs in the PRD's launch section as one or two lines — reaching for this template there is ceremony, and ceremony trains people to skim.

If you are still writing the spec, the Standard PRD template has the launch section this expands on.

The template

# [Feature] — Launch Plan
Owner: [name] · Rollback owner: [name] · Backup: [name]
Target start: [date] · Full rollout by: [date]

## What is shipping
[One paragraph. What changes for whom, and what stays the same.]

## Phases

### Phase 1 — [name, e.g. internal / 5% / one cohort]
Audience: [who exactly, and how they are selected]
Duration: [minimum time, not just "until it looks fine"]
Exit criteria:
- [Checkable condition with a number and a window]
- [Checkable condition with a number and a window]
Decision owner: [name]

### Phase 2 — [name]
[same shape]

### Phase 3 — general availability
[same shape]

## Guardrail metrics
[The numbers that would make you stop, with thresholds. Distinct from
success metrics — these are the ones that trigger a halt, not the ones
that prove it worked.]

| Metric | Normal | Halt threshold | Where it is watched |
|---|---|---|---|

## Rollback
Trigger: [what conditions force a rollback, not "if there are problems"]
Mechanism: [the actual steps, in order]
Time to revert: [measured, not estimated]
Data implications: [what happens to records created during the rollout]
Who decides: [name] · Who executes: [name]

## Readiness checklist
- [ ] Feature flag exists and has been tested in both positions
- [ ] Dashboards and alerts live before phase 1, not after
- [ ] Support briefed with a known-issues list and an escalation path
- [ ] Docs and release notes drafted
- [ ] Rollback rehearsed at least once in a non-production environment

## Comms
| Audience | What they are told | When | By whom |
|---|---|---|---|

## Post-launch review
Date: [scheduled now, not "we will find time"]
Owner: [name]

Section by section

Phases and exit criteria

The load-bearing section. A phase without a checkable exit is not a phase, it is a pause of unspecified length that ends when someone gets impatient.

Guardrail metrics

Distinct from success metrics, and frequently confused with them. Success metrics tell you the launch worked. Guardrails tell you to stop. A plan with only success metrics has no brake.

Rollback

Write this as if the person executing it has not read the rest of the document, because that is the likely case.

Readiness checklist

Post-launch review

Worked example

A weak phase gate and a strong one:

Weak. Phase 1: roll out to 10% of users. Monitor for issues. If everything looks good, proceed to phase 2.

Every term is negotiable. "Looks good" under deadline pressure means "nobody has complained loudly yet."

Strong. Phase 1: 10% of workspaces created before 1 Jun, minimum 72 hours. Exit when: p95 latency on the invite endpoint stays under 400ms, invite completion rate is within 2 points of the 61% baseline, and support logs zero P1 tickets attributable to the release. Decision owner: Dewi.

The second can fail. That is the entire difference.

Common mistakes

Success metrics doing double duty as guardrails. They measure different things. One tells you to celebrate, the other tells you to stop, and a plan with only the first has no brake.

Exit criteria that cannot fail. If no realistic outcome trips the gate, the gate is decoration.

An unrehearsed rollback. The first execution should not be the real one. Rehearse it once, somewhere safe, and record how long it took.

No named owner per phase. "The team will decide" produces a discussion at exactly the moment you needed an action.

A post-launch review with no date. Scheduled before launch or it does not happen, and the planning mistake survives into the next release.