Product Launch Brief Template
Every function reported ready. The tracker found a quote template nobody had built, so nothing shipping that day could have been sold.
Free download · No account needed
A go/no-go meeting collects six colours against six private definitions of ready, and the colours agree far more often than the underlying state does. So the criteria come first here, before the date is committed, and one rule decides what is admissible: somebody other than the owner has to be able to settle it by looking at an artifact. "Support is trained" is not a criterion. "Every tier-1 agent has resolved one simulated ticket end to end" is, because the answer is a count.
Google's reliability team reached the same shape from the operations side. Their launch process runs on a checklist of questions with an action item behind each rather than a list of tasks. A question has an answer somebody can produce. Twenty-three criteria across six functions for a tier 1 launch, thirteen of them blocking. Each one names the artifact that settles it, the person who can waive it, and what the function claimed before anybody checked.
In the worked launch, nineteen were met, three were unmet and all three were blocking. One was a four-hour change to the quote template that no name on the checklist owned, which meant nothing shipping that week could be quoted. The release side of the same cadence is the release notes pack, the risks that need a quarter go to the roadmap pack, and the decision itself gets recorded in the decision record pack.
What is in the pack
Readiness Tracker
One row per criterion with the artifact that settles it, what was actually found, whether it blocks the date, who waived it and when, and what the function claimed before anybody checked.
Readiness Criteria
The definitions per tier, the admissibility test, and the four criteria that fail on every launch for structural reasons: agent training, unowned cross-function work, load testing, and success instrumentation.
Launch Checklist by Function
The task view keyed to the criteria, with due dates relative to launch and unowned rows left visibly unowned rather than assigned to a team name.
Risk Register
No likelihood times impact. Who finds out first and how late, which is answerable and which maps straight onto whether the mitigation is a detector, a capacity plan or an alert.
Launch Brief
One page so six functions describe the same launch the same way, including what is not shipping, who it is not for, and what the go/no-go actually found against what was reported.
Positioning Input and Support Enablement Note
The handoff product owes marketing, with verbatim customer language and the claims this launch cannot support, plus the note the agent picking up ticket one actually reads.
How it works
- 1
Set the tier
From reach and reversibility, on day one. One checklist for every launch gets gamed, and a tier that drifts down in launch week is how criteria get escaped.
- 2
Write checkable criteria
Every claim of the form X is ready becomes the artifact that would prove it, with the person who can waive it named up front.
- 3
Verify, do not ask
Each criterion gets checked against its artifact. The finding is recorded as a count with its denominator, not as a colour.
- 4
Read the count
How many blocking criteria are unmet is the launch decision. Everything else in the meeting is context.
Frequently asked questions
What do I send it?
The spec or PRD, the current delivery status, whatever go-to-market plan exists, and the date somebody already promised. A date and an idea is enough to start. If it came out of a beta, send the exit memo too, because its known gaps are what this brief carries.
How is this different from a launch checklist?
A checklist tracks tasks, and a task marked done is not the same claim as a criterion met. Look at an actual launch checklist: every line is a question. The quote template task had no owner, so nothing was overdue. The criterion asked whether a quote could be generated, and the answer was no.
Why keep a record of what each function claimed?
Because over three or four launches it tells you whose green means green, and that is the most useful thing this space produces. It is not about honesty. Six leads answering six different private definitions of ready will report six greens every time.
What if a criterion cannot be met before the date?
Then the count of unmet blocking criteria is not zero, and the decision is a new date or a recorded waiver with a name, a date and a revisit date. In the worked launch the total unmet work was under a week, so the date moved six days rather than shipping on waivers.
Does it write the launch campaign?
No, and the boundary is deliberate. Product hands over a positioning input with verbatim customer language, the entitlement counts, what is not shipping and the claims this launch cannot support. Marketing owns everything downstream. The criterion is that the input was signed off, not that the copy is good.
Why not score risks by likelihood and impact?
Because nobody scores them honestly and a register full of medium-medium rows has never changed a decision. Who finds out first and how late is answerable, and it maps onto the fix: weeks late and the customer finds out needs a detector, same day needs capacity.
We launch every two weeks. Is this too heavy?
That is what the tiers are for. Tier 3 is four criteria and no meeting; tier 2 is eleven across three functions. Only a launch that changes entitlement, needs a migration, or gets announced publicly runs the full set. Release cadence itself is the release notes pack.
Find out what your green actually means
Send the spec, the status and the date somebody promised. The first thing back is how many of your readiness claims can be checked at all.
Check my launch