# Launching a product: beta, launch checklist and post-launch review

Source: https://sarang.pro/product-launch-beta-checklist-review/
Author: Sarang | Published: 25 October 2026

A launch is the moment a product or feature meets the people it was built for. It is also the moment when gaps in support, billing, messaging and capacity show up all at once. Most launch problems come from things nobody owned: the help article that was never written, the price page that still shows the old plan, the support inbox that nobody was watching on launch day.

This guide breaks a launch into three parts: a beta that tests the product with real users, a checklist that covers the whole business rather than just the code, and a review afterwards that turns the launch into lessons. It is written for small teams launching a new product or a significant feature.

## What counts as a launch
Google's site reliability engineers use a broad definition in their book chapter on [reliable product launches](https://sre.google/sre-book/reliable-product-launches/): any new code that introduces an externally visible change to an application. By that measure, most teams launch something every week. Not every change needs the full process below. Save it for changes that affect many customers, alter what they pay, or need marketing and support to prepare.

## Run a beta first
The UK Government's service manual describes a useful two-step approach in its guidance on the [beta phase](https://www.gov.uk/service-manual/agile-delivery/how-the-beta-phase-works). In a private beta, you invite a limited number of people to use the service, run user research, and start collecting data against the success measures you set earlier. You also check that support staff can help users who struggle, including in ways nobody predicted. In a public beta, anyone who needs the service can use it, and the team proves it can run at scale.

For a small product team the same pattern works:

- **Pick beta users on purpose.** Choose a mix of keen early adopters and ordinary customers. Fans forgive problems that normal customers will not.
- **Set expectations.** Tell beta users what is unfinished and how to report issues.
- **Decide in advance what you are testing.** Write down the two or three questions the beta must answer, such as "can new users set up without help?"
- **Agree exit criteria.** Decide what must be true to launch widely, for example no open serious bugs and most beta users completing the main task unaided.
Feature flags make this easier. Google's chapter describes rolling changes out to a subset of users, often moving from 1% to 10% and beyond, with the ability to switch a change off quickly if it causes problems.

## The launch checklist
Google's launch reviews cover areas such as architecture and dependencies, capacity planning, failure modes, external dependencies and rollout planning. Those matter, but a small business also needs a checklist that covers the people and promises around the product. A workable version has five owners.

AreaChecksProduct and engineeringExit criteria met; rollback plan written and tested; monitoring and alerts on the key flows; capacity checked for expected trafficPricing and billingPlans, prices and tax set up correctly; test purchase made; invoices and receipts show the right detailsSupportHelp articles published; support team briefed and trained; saved replies for likely questions; someone watching the inbox on launch dayMarketingWebsite, app store listing and screenshots updated; announcement email and posts scheduled; claims checked against what the product actually doesLegal and dataTerms and privacy notice updated if anything changed; consent and cookie settings reviewed; any accessibility issues from testing fixedAdd a launch owner who has the final say on go or no-go, and a short meeting the day before to walk the list. If an item is not done, either fix it, drop it from scope or delay. Do not launch hoping someone will catch up.

## A worked illustration
An example (illustration only). A UK start-up selling a scheduling app to dental practices is launching a new online payments feature.

- **Private beta:** eight practices for four weeks, chosen to include two that are not usually early adopters. The beta questions: can a receptionist set up payments without calling support, and do patients complete payment on mobile?
- **Finding:** receptionists got stuck at the bank verification step. The team rewrote the instructions and added a progress indicator. Support calls during setup fell from most practices to one in eight.
- **Rollout:** released to 10% of practices for a week, with daily checks on payment failures, then to everyone.
- **Launch day:** help article live, support briefed, an email to all practices explaining the feature and fees, and the pricing page updated the same morning.

## The post-launch review
Two to four weeks after launch, hold a review. Its purpose is learning, not blame. Atlassian's guidance on [blameless postmortems](https://www.atlassian.com/incident-management/postmortem/blameless), written for incidents, applies just as well to launches: assume people acted in good faith with what they knew at the time, build a shared timeline of what happened before discussing causes, and assign owners to the agreed actions.

Cover four questions:

- **Did it work?** Compare the success measures you set before the beta with the actual results.
- **What did customers say?** Review support tickets, feedback and any changes in cancellations.
- **What went well in the launch itself?** Keep it for next time.
- **What went wrong or nearly went wrong?** Turn each one into a change to your checklist or process.
Jeff Patton's advice on [dual-track development](https://www.jpattonassociates.com/dual-track-development/) is short and fits here: keep measuring and learning even after you ship. A launch is the start of learning about a feature in real use, not the end of the work.

## Common mistakes
- **A beta with only fans.** They will tell you everything is great.
- **No rollback plan.** If you cannot turn it off quickly, you are betting the launch on there being no surprises.
- **Support hears about it from customers.** Brief the support team before the announcement goes out.
- **Marketing claims run ahead of the product.** Check every claim against what the feature actually does today.
- **Launching on a Friday afternoon.** Problems appear when the team is least available.
- **Skipping the review.** Without it, the same gaps appear at the next launch.

## Scaling the process up or down
For small changes, a short checklist and a flag-controlled rollout are enough. For a new product, a change to pricing, or anything that affects how customers pay or what data you hold, run the full sequence: beta, checklist, staged rollout and review. Keep your checklist in one shared place and update it after every review, so each launch is a little smoother than the last.