River
Y CombinatorBacked by Y Combinator
Log InStart Free

Free template

Product Launch Plan Template

Seven Word documents and four CSV sheets for checking every launch claim against what shipped, tracking open blockers and scheduling irreversible steps last.

Edit with AIDownload (.docx + .csv)

Free download · No account needed

What you get

Pack of 11 files: 7 documents, 4 spreadsheets

Product Launch Plan Template
  • Claim Mapping MethodDocument
  • Reversibility SequenceDocument
  • Launch BriefDocument
  • MessagingDocument
  • Comms PlanDocument
  • Enablement NoteDocument
  • Launch RetroDocument
  • Claim to Requirement MapSpreadsheet
  • Launch CalendarSpreadsheet
  • Readiness TrackerSpreadsheet
  • Asset ChecklistSpreadsheet
RiverProduct Launch Plan Template

Claim to Requirement Map

Eleven claims, nine requirements, one scope cut

Ashwell Systems  ·  Rental Fleet 4.0  ·  status re-pulled at T-4, after the week 10 cut

ClaimReqStatusVerdictSurfaces
Inspect a unit with no signal at allR1CompleteClear3
Mark the damage on the photograph itselfR2CompleteClear3
The renter signs on the deviceR3CompleteClear3
Damage costs priced before the renter drives offR4Cut at T-10Blocked4
An end to disputed damage invoicesR4 R9Cut, partialBlocked3
The report reaches the renter before they leaveR6Email onlyNarrow3
Conflicts resolve themselves on reconnectR5CompleteClear2
Every inspection in the fleet in one viewR7CompleteClear3
Scan the unit and the record loadsR8CompleteClear2
Charges post straight to the ledgerR9Read onlyBlocked2
Cuts inspection time in halfnoneNo requirementUnsourced4
11 claims across 7 surfaces6 complete, 2 partial, 1 cut6 clear, 1 narrow, 3 blocked, 1 unsourced32

Four bad claims are thirteen sentences

The three blocked claims and the unsourced one appear thirteen times across six of the seven surfaces. Counting claims makes this a morning. Counting instances makes it a two-day job with six owners, which is the truth.

The gap that produced all of it

Messaging last edited on the Wednesday of week 8. Scope cut on the Monday of week 10. Twelve days in which finished-looking copy was wrong and no review cycle would have caught it, because the review happened in week 9.

One surface was clean: the in-app notice, four claims, all clear. It was written in week 10 by an engineer looking at the running build.

Page 1 of 1292 words

How to write a product launch plan

A product launch plan is the shared document that coordinates one release across product, marketing, sales and support. It sets out what ships, what each team will say about it, who owns each task and the order things go out. A good one ties every marketing claim to a requirement that shipped, measures readiness by open blockers, and schedules the steps you can undo before the ones you can't.

Treat the launch copy as the riskiest part of the plan. It is usually written while the scope is still changing, and rereading finished copy is nobody's job.

A team meets around laptops at a round table in a glass-walled office at night
When a meeting like this changes the scope, reread the launch copy. Photo: Mario Gogh on Unsplash

Start the launch plan from what ships

Open with a one-page launch brief: the release, the ship date, one launch owner and where the requirements live. Then list every requirement with an ID, one sentence on what it does, its status and the date that status was last true.

Use three statuses. Complete means it shipped as written, partial means it shipped narrower (say how), and cut means it isn't in this release. If nothing is written down yet, start with a product requirements document.

Expect the copy to promise more than ships. In 2006, Amazon's Werner Vogels described how the company starts product definition by writing the press release and FAQ it will need at launch1. That works for deciding what to build. But copy drafted that early describes the plan, not the product that ships.

Compare two dates

Note when the messaging was last edited and when the scope last changed. If the scope changed later, some of your copy hasn't been reread since it stopped being true.

Tie every claim to a requirement

Read every surface that carries copy: the email, pricing page, sales deck, blog post, press release and in-app notice. Pull out each sentence that says what the product does. Record each claim once, list every surface it appears on, and attach the requirement it rests on.

Four verdicts for a launch claim

VerdictWhat it meansWhat to do
ClearShipped as widely as the claim readsPublish it
NarrowShipped, but narrower than the claim impliesRewrite it to say exactly what shipped
BlockedThe requirement was cut or deferredReplace it on every surface now
UnsourcedNo requirement or measurement backs itMeasure it or cut it

Then count instances, not claims. In the template's worked example, four unsupported claims appeared 13 times across six surfaces, so the fix was 13 sentences with six owners rather than four quick edits.

ExampleFixing a narrow claim and a blocked oneAn illustrative example from this template's worked launch. The company and product are made up.

Narrow. Before: "The report reaches the renter before they leave." After: "The inspection report is emailed to the renter the moment the inspection closes."

Blocked. Before: "Damage costs priced before the renter drives off." After: "Damage is captured, marked and timestamped at handover, so the charge is built from evidence."

  • Narrow, not deleted. The text message path didn't ship, so the rewrite names the channel. It is also the stronger sentence.
  • Say what it does now. The replacement describes what shipped and makes no promise about a future release.

Numbers need a measurement

In the US, the FTC says advertisers must have proof before the ad runs2, for implied claims as well as stated ones. A line like "cuts inspection time in half" needs a measurement, its date and its conditions. Ask a lawyer to review any claim that compares you with a competitor.

Measure readiness in open blockers

List everything that must be true before launch, from every team, with an owner and a status. Then test each open item with two questions: what breaks if it stays open, and who notices first? An item that can't answer both is a task, not a blocker. Label everything a blocker and the go/no-go comes down to opinion.

People will ask for percent complete, so report it, but let the blocker count set the date. In the template's example, the launch sat at 88% complete with two open blockers. Support had no answer about a cut feature, and the sales deck still demoed one that never shipped.

Order the calendar by what you can take back

A first-draft calendar follows the order work gets finished, with the launch email at 9 a.m. on launch day. Google's SRE book notes that very few of Google's launches are "push-button"3 releases to the whole world at once. Run the reversible steps first: they surface problems while there's still time to fix them.

How easily launch activities come back

ActivityHow you take it backThe catch
In-app notice behind a feature flagTurn the flag offOnly if you tested the off switch
Pricing page or blog postPublish an editSearch results may lag
Sales deckReissue the fileOld copies stay on laptops
Store listing text and screenshotsSubmit the changeIt waits for the store's review
Google Play staged rolloutHalt itUsers who have the update keep it
App Store phased releasePause it, for up to 30 daysAnyone can still download it manually
Email, wire release or analyst briefingSend a correctionThe original stays out

Apple's App Store Connect help says a phased release runs over seven days4, starting with 1% of users who have automatic updates on. It also notes that anyone can download the update manually at any time.

So a day-one email announcing the feature turns the phased release into a full one for everyone who acts on it. Hold the email until enough people have the update: with 20,000 iOS users on automatic updates, about 200 have it on day one and about 4,000 on day five.

On Google Play, a staged rollout's percentage won't increase automatically5, and you can't remove countries once it starts. Give every increase a named owner and settle the country list first. If the store listing must change, Google recommends doing it after the rollout reaches 100%.

Put irreversible steps last, behind every reversible one and every blocker they depend on. If a blocker is still open, leave that row undated rather than guessing.

Brief sales and support before you announce

Write a one-page enablement note a rep can read once before a call. Lead with what the product does, in the approved claims word for word. Then cover what it doesn't do, with an honest answer for each, and the two or three questions the cuts will raise.

Tell reps never to name a future release: "coming soon" ends up in the prospect's notes as a promise. If you withdraw a deck, tell the team rather than quietly swapping the file. Stale claims linger on sales material, so check your competitive battlecards against the same claim list.

Before the first irreversible send

  • Every claim on every surface has a requirement and a verdict
  • No blocked or unsourced claim is live anywhere
  • Every number in the copy has a measurement, a date and its conditions
  • Requirement status was rechecked in the last few days
  • Every open blocker is closed, with the evidence recorded
  • Each rollout increase has an owner and a date
  • Sales and support can answer the questions the cuts raise

Close it out with a retro

Hold the retro while details are fresh, and write it from the claim and readiness lists rather than from memory. Start with the numbers: claims caught, sentences changed, blockers open at the go/no-go, and the days between the last copy edit and the last scope change.

Google's SRE book says a blameless postmortem6 focuses on contributing causes without indicting any individual or team. Turn each lesson into a process change, such as writing one surface in the final week from the running product.

The template at the top of this page has a file for each of these steps, filled in for a worked launch. For the announcement itself, the press release writer drafts the release, and the release notes template covers the changelog.

How to use this template

Use the files as they are, or open them in River. With Edit with AI, River asks for your requirements, with the current status of each, and whatever launch copy already exists. It traces every claim to a requirement and tells you which claims have none and where they appear. After that, it helps order the calendar so the steps you can't undo go last.

  1. Download it or open it in River

    Get the seven Word documents and four CSV sheets free, or open the template in River to work on it with AI.

  2. Gather requirements and copy

    List each requirement as complete, partial or cut, with a date, and gather every piece of launch copy you have.

  3. Map claims and fix them

    Give each claim a requirement and a verdict, or let River do it, then rewrite narrow claims and replace blocked ones.

  4. Sequence, brief and launch

    Order the calendar by what you can take back, close open blockers, and give sales and support the enablement note.

What's in the template

Readiness counted in open blockers, a calendar ordered by reversibility, and the note the reps actually readThe Readiness Tracker, the Launch Calendar with reversibility classes, and the Enablement Note.
Product Launch Plan Template
RiverReadiness

Readiness Tracker

Thirty-four items. Every open one names what breaks and who notices first.

ItemDescriptionBlockerWhat breaks if it stays openWho notices first
B12Support macro for the question “where is the cost estimate”YesSupport tells customers pricing is coming and names no releaseSupport, within one shift of the email
B27Ledger write-back removed from the sales deckYesA rep demos a capability that does not existThe prospect, live on the call
B32Webinar abstract still carries the unsourced time savingNoAn unmeasured claim publishes; the surface is not live yetRegistrants, from day 6
B33Blog post header imageNoThe post looks unfinishedReaders
B30Named owner recorded for every Play rollout increaseClosedThe rollout sits at 10 percent indefinitelyNobody: it simply never ramps
B23Launch email send moved to day 5 and the schedule lockedClosedThe phased release is defeated by manual downloadsMobile lead, watching the ramp
At the go/no-goCountReads as
Items closed30 of 3488 percent complete
Open blockers2the number that set the date
Open non-blockers2tasks, not blockers

Eighty-eight percent was the number quoted in the status meeting. Two was the number that decided when the irreversible rows could be dated. Both blockers closed on day 3, which is why the email went on day 5.

An item is a blocker only if it can answer both questions. If the honest answer to “what breaks” is that something looks untidy, it is a task. A list where everything is a blocker is a list where nothing is, and the go/no-go becomes a vote.

Who-notices-first is the field that closes items. Two of the thirty-four answered “nobody, ever” and were deleted rather than done.

RiverCalendar

Launch Calendar

Nine activity classes ordered by recoverability, not by readiness. 18,400 iOS installs, 22,700 Android.

DayActivityOwnerReversibilityHow it is taken back
1In-app notice on, both platformsProductMinutesFlag off
1Pricing page paragraph publishedWebMinutesPublish an edit
1Phased release opens at 1 percent  184 devicesMobile leadPausablePause up to 30 days; manual downloads continue
1Play staged rollout at 10 percent  2,270 devicesMobile leadHaltableHalt; users who have the build keep it
2Blog post liveContentMinutesEdit or unpublish; URL may persist in search
2Sales deck reissued as 4.0-c, announced out loudEnablementFile onlyNew file; laptop copies cannot be recalled
3Play rollout raised to 50 percent  11,350 devicesMobile leadHaltableHalt the release
3App Store listing text and screenshots submittedMobile leadAfter reviewResubmit metadata and wait
5Launch email  41,300 contacts, 12,600 app usersLifecycleIrreversibleA correction, never an undo
6Wire press releaseCommunicationsIrreversibleSyndicated within the hour, stays syndicated

Three things moved during the sequencing pass. The email went from day 1 to day 5, the seventh day of the phase, where it reaches 100 percent, or 18,400 iOS devices, rather than 184. The wire release went behind the in-app notice, so the first people to hear about a feature can go and look at it. The store metadata went from day 1 to day 3, because a review queue is not a schedule you own.

The ramp cell needs a name in it. A staged rollout percentage does not rise on its own, so day 3 at 50 percent was a hope until somebody's name went in the cell on day 2.

An irreversible row that depends on an open blocker stays undated. That is the correct output, and it beats a date everybody privately expects to slip.

RiverEnablement

Enablement Note

For 14 reps, 3 solution consultants and the support team. Read once, quickly, before a call.

Say this

The inspection report is emailed to the renter the moment the inspection closes. Say emailed. Do not say delivered, texted, or reaches them: the message path in the requirement did not ship.

What it does not do, and what to say instead

Asked aboutThe plain answerThen say
Pricing the damageNot in 4.0. The rate card estimate was cut.Damage is captured, marked and timestamped at handover, so the charge is built from evidence rather than memory
Posting to the ledgerRead only. Billing still actions the charge.The inspection is matched to the open rental agreement, ready for billing
How much faster it isNo published figure exists.The instrumentation went in with 4.0 and the comparison is being run across 50 inspections

Never name a future release. “Coming soon” from a rep becomes a commitment in the prospect's notes, and the next conversation starts from it.

The thing most likely to get someone into trouble

Three sentences were live on the deck and the pricing page as recently as day 1 and are now false: damage priced at handover, an end to disputed invoices, and charges posting straight to the ledger. All three read well. If a slide in front of you says any of them, you have an old file.

Deck 4.0-a and 4.0-b are withdrawn. The reissue was announced out loud in the sales channel, because a file drop does not reach a laptop.

  • Launch BriefThe release, ship date, owner, requirement status, readiness at the go/no-go and the definition of done.
  • Claim Mapping MethodHow to break copy into claims, attach requirements, read the four verdicts and count instances.
  • Reversibility SequenceHow to rank launch activities by how easily each comes back, including app store rollouts.
  • MessagingEvery claim with its requirement and verdict, with struck-through originals kept above their replacements.
  • Comms PlanThe day-by-day sequence, each surface's audience and size, and the reason for every date that moved.
  • Enablement NoteWhat sales and support should say, what the release doesn't do, and the questions to expect.
  • Launch RetroWhat the numbers said, what went wrong, what went right and what changes next time.
  • Claim to Requirement Map sheetEach claim once, with its requirement, status, verdict, surfaces, instance count and replacement.
  • Launch Calendar sheetEvery activity with its day, owner, reversibility, how it's taken back and what it depends on.
  • Readiness Tracker sheetEvery launch item with its owner and status, whether it blocks, what breaks and who notices first.
  • Asset Checklist sheetEach surface with its owner, audience, size, claims carried, edits needed and go-live day.

Common questions

What should a product launch plan include?

A product launch plan should cover six things: a launch brief, messaging, a readiness list, a calendar, an enablement note for sales and support, and a retro. The brief names what ships, the date and one owner. The messaging ties every claim to a requirement that shipped, and the readiness list tracks owners and open blockers.

Who should own a product launch plan?

Often a product marketing manager, though at a small company it may be the product manager or a founder. What matters is one named launch owner who runs the go/no-go. Every surface and rollout step also needs its own owner, so a blocked claim or a ramp increase reaches a person, not a shared document.

What is a go/no-go decision for a launch?

A go/no-go decision is the checkpoint before launch where the launch owner decides whether to proceed, especially with the steps you can't undo, such as the announcement email. Base it on open blockers, the items where you can name what breaks and who notices first. Report percent complete if people want it, but don't let it set the date.

Is a launch plan the same as a go-to-market plan?

No. A go-to-market plan sets the strategy: who you sell to, how you position and price the product, and which channels you use. A launch plan executes one release within it: what ships, what each surface says, who owns each task and the order things go out. This template covers the launch plan and takes the strategy as given.

Is this product launch plan template free?

Yes. Download the seven Word documents and four CSV sheets with no signup. They come filled in with one worked launch at a fictional company, so you can see how each file works before you replace it with your own. Edit with AI opens the same template in River.

What does Edit with AI do?

It opens the template in a free River workspace. River asks for your requirements and each one's status, your launch copy, who owns each surface and when the copy was last edited. It maps every claim, then tells you how many have no requirement behind them and how many surfaces carry them. If you have little written down, it starts from the requirements alone.

Sources

  1. All Things Distributed. “Working Backwards.” allthingsdistributed.com (opens in a new tab)

  2. FTC. “Advertising FAQ's: A Guide for Small Business.” ftc.gov (opens in a new tab)

  3. Google SRE. “Reliable Product Launches at Scale.” sre.google (opens in a new tab)

  4. Apple Developer. “Release a version update in phases.” developer.apple.com (opens in a new tab)

  5. Google Play Console Help. “Release app updates with staged rollouts.” support.google.com (opens in a new tab)

  6. Google SRE. “Blameless Postmortem for System Resilience.” sre.google (opens in a new tab)

Written by

Chandler Supple

Co-founder & CEO, River

Chandler has spent the last six years working in AI, building tools for millions of users and Fortune 100 companies. In 2025, he co-founded River to build a new kind of operating system for AI agents.

LinkedInGitHubX

Reviewed by

Brian Joseff, Co-founder, River

LinkedInX

Related tools and templates

More free templates