Launch readiness. The go/no-go gate most teams skip.

The short answer. Readiness is a gate, held by someone other than the launch's biggest fan.

I'm Lauren Pearson, and most launch delays I see are not caused by the product. They are caused by a date that got locked in early, momentum that built around it, and nobody with the standing to say "not yet" once three teams were already excited and the date was on a slide deck. By the time anyone notices support has not been briefed or the pricing page still shows last quarter's numbers, it is launch morning, and fixing it in public is a worse outcome than fixing it a week earlier in private.

A launch readiness review solves this by making "are we ready" a specific, scheduled checkpoint with a named owner, rather than a feeling the launch lead has on the morning of. Every function involved confirms its own piece in writing, and the review only has two honest outputs: go, or a named reason it is a no, with what needs to happen before it can become a yes. Our guide to sequencing a product launch covers the plan itself; this is the separate, narrower check on whether the plan the teams agreed to has actually been delivered on.

How it works in practice. Six areas, each with a single accountable owner.

A readiness review works best as a short, written checklist with one name against each line, reviewed in a single meeting rather than chased over email for a week. The six areas that recur across almost every launch, regardless of product category:

• Product and QA. The feature or product works end to end in a production-like environment, not just the demo path the team has rehearsed. Known issues are listed and triaged as launch-blocking or not, rather than left as an undocumented assumption that "it's basically fine."
• Pricing and commercial terms. Final, approved, and matching across every surface it appears on, the website, the sales deck, the order form. A pricing mismatch between what marketing is advertising and what sales is quoting is one of the fastest ways to lose trust with a first customer.
• Sales and customer-facing enablement. The team taking live calls on launch day has actually been briefed, not just copied on an email thread. A one-page cheat sheet covering what's new, who it's for, and the three objections most likely to come up beats a forty-slide deck nobody reads before the first call comes in.
• Support readiness. Documentation exists for the likely questions, and the support team has a route to escalate anything the documentation does not cover. A launch that generates more tickets than support can handle in the first 48 hours does more reputational damage than a quiet, smaller rollout would have.
• Marketing assets and messaging. Final copy, approved claims, and a check that nothing promised in the launch messaging is still, in fact, a roadmap item. Overpromising in launch copy creates the support and trust problem above before a single ticket is logged.
• A rollback or containment plan. A named decision-maker and a specific trigger for pulling back, scoping down, or pausing the rollout if something goes wrong in the first hours, agreed before launch day, not improvised during it.

Each area gets one accountable name, not a team. "Marketing" confirming readiness means nothing if nobody in marketing was specifically asked and specifically answered; a named person who has personally checked the claim is what makes the readiness review worth running at all.

The checklist itself is less important than the habit of writing it down somewhere everyone involved can see the same version. A readiness list that lives in one person's head, or across six different Slack threads, cannot actually be reviewed; it can only be remembered, imperfectly, by whoever happens to be in the room. A single shared document, even a simple one, with a status and a name against each line, is the entire mechanism. The sophistication teams reach for, scoring models, automated dashboards, elaborate sign-off workflows, solves a problem most launches do not have yet. The problem most launches have is that nobody wrote the six lines down and asked each owner to confirm them in the same room at the same time.

What good looks like. A real gate, with a real "no" available.

The test of whether a readiness review is genuine or theatre is simple: has it ever actually produced a "no," or does it always rubber-stamp whatever date was already on the calendar? A review that has never once delayed a launch is not catching anything; it is a status update wearing a go/no-go label.

Good practice holds the review far enough ahead of launch day that a real "no" is still useful, one to two weeks out rather than the morning of, so a flagged gap has time to close without a public date slipping. It also separates launch-blocking issues from everything else; a readiness checklist that treats a typo in the help docs the same as a broken checkout flow loses its ability to say which gaps genuinely matter.

Readiness also needs honest handling of risk that will not fully close before the date, which is more common than teams like to admit. New product failure is often quoted at wildly inflated rates, but the better-evidenced research tells a calmer story: a peer-reviewed study in Marketing Letters, analysing 83,719 new CPG product launches across eight years and 31 US categories, found roughly a quarter of new products were no longer being bought within a year, rising to about 40% within two years, measuring failure as the permanent stop of sales. That is a meaningfully lower bar than the 80-90% figure often repeated without a source, and a reminder that launch readiness is about closing the risks you can control, not chasing an impossible zero.

The same research found failure was not spread evenly: newer SKUs launched into higher-revenue categories, and launches from smaller-share parent brands, failed more often than the average. The readiness lesson is not that a smaller or less established brand should expect to fail; it is that risk tolerance in a readiness review should scale with exposure. A launch into a crowded, high-revenue category with intense competitor attention warrants a stricter readiness bar and a more conservative rollback trigger than a quiet feature update to an existing base of loyal customers, even though both might sit on the same calendar under the same "launch" label.

A worked scenario. The one line nobody had actually checked.

A SaaS client preparing a feature launch had every box on the readiness checklist ticked a week out, product tested, support briefed, pricing confirmed. The gap surfaced only because the readiness review asked each named owner to confirm their line out loud rather than tick a shared spreadsheet silently. The marketing lead, asked directly, admitted the launch email had gone through legal review two versions ago, and a late copy change describing a capability the engineering team had actually descoped the week before had not been re-checked.

That is a small, specific example of why a readiness review needs a live conversation, not just a checklist filled in asynchronously: a tickbox gets completed against the version of reality that existed when it was first ticked, and launches move fast enough that reality changes underneath it. Catching the stale claim cost one afternoon of a copywriter's time before launch day; catching it after the email had gone to the full list would have meant a correction email and a credibility dent with exactly the customers the launch was trying to impress. This is an illustrative, generalised pattern from several launches, not a single named client result, but the mechanism, asking owners to confirm out loud rather than tick silently, holds across all of them.

Pitfalls to avoid. Where readiness reviews quietly become theatre.

Running the review too close to launch day is the most common failure. A readiness check on launch morning has no time left to produce a real "no," so it stops functioning as a gate and starts functioning as a formality everyone already expects to pass.

Letting the launch lead also own the go/no-go decision is the second. The person most invested in the date happening is structurally the wrong person to be the one weighing whether it should slip; a second, less emotionally invested signoff, a head of ops, a GM, a founder not running point on this specific launch, keeps the decision honest.

Treating every open item as equally blocking is the third, and it produces the opposite failure: a review so strict it never says yes, which teaches everyone to route around it next time. The fix is a short, pre-agreed definition of what actually blocks launch (customer-facing breakage, legal or compliance exposure, a support team that cannot cope with expected volume) versus what can ship with a known-issues list attached. Our go-to-market strategy work builds this gate into the launch plan from day one, specifically because teams that design the readiness check after the date is already public tend to design it too weak to ever use. Our companion guides on product launch mistakes and product launch metrics cover what tends to go wrong and how to measure the aftermath; this piece is about the checkpoint that sits between planning and either one.

The fourth, quieter pitfall is announcing the launch date publicly before the readiness review has actually happened. Once a date is on a customer-facing page or in a press pitch, the readiness review stops being a genuine gate and becomes a pressure test on everyone to find a way to say yes, since a public slip carries its own reputational cost separate from whatever the product gap actually is. Holding the public announcement until after the readiness checkpoint, even by a week, keeps the gate's "no" option real instead of theoretical.