Before a major launch reaches customers, define what "launched" means in numbers, test what breaks if adoption comes in far above or far below plan, and confirm that pricing, support, sales, and the rollback switch are settled before the date. Paste the launch plan, the success measures, capacity and load test results, the pricing and packaging decision, support and sales readiness notes, and the rollback plan into one request. Instruct Pingpong to mark what is settled and what is still open, run the high and low adoption cases, and flag any owner who is missing. Review your written answers in a second round.
This page is for chief executives, product and revenue leaders, and directors deciding whether a product, major feature, or new offering is ready for customers. Executive starting points live under Pingpong for executives.
Define launched
"Available to all customers" describes a release. A launch definition says what should be true at a set date: paying customers, active use, quality measures, support volume. Without one, nobody can tell at day 90 whether the launch worked.
Run three adoption cases
At plan. Walk through the first week with the numbers you expect. Who answers the first tickets, and who in engineering do they reach?
At ten times plan. Find the first thing that breaks: system capacity, support queues, billing, onboarding staff. Decide now whether you would throttle, queue, or roll out in waves.
At a tenth of plan. Set the date and the number at which you review the launch, and decide who makes the call. Low adoption with no review date tends to drift for quarters.
Settle these before the date
- Pricing and packaging frozen, with one version in every sales deck and on the website.
- Sales and customer success trained, including what to say about known limits.
- A named owner for Day 1 support and an escalation path to engineering.
- A rollback trigger and a switch that works per customer.
- Sign-off from each owner, in writing, at a readiness meeting before launch.
A worked example
This example is illustrative and does not describe a customer. A 500-person HR software company plans to launch a payroll anomaly detection add-on to all 6,000 customers at its annual conference in three weeks. The plan defines success as "available to all customers."
The chief product officer pastes the launch plan, beta results, load test results, the pricing decision, the support training schedule, and the sales deck.
A useful pass finds no measurable goal for the launch. The add-on's price is approved, but which plans include it is still under debate, and the sales deck exists in two versions. Four of 30 support agents have been trained, and no engineer is on call for launch day. Load tests covered 5% of customers turning the feature on at once. If 30% enable it during a payroll week, the processing queue would fall behind, and false alerts would arrive during payroll runs, when customers are least patient. The feature cannot be turned off for one customer without turning it off for all. Customer success does not know which beta customers reported problems.
The low case has no answer either. If fewer than 2% of customers adopt within 60 days, the plan sets no review.
The revised plan keeps the conference announcement but rolls out in waves of 1,000 customers a week, scheduled around payroll peaks. Launch is defined as 300 paying customers and a false alert rate under 3% at day 90. Packaging is frozen ten days before the conference, with one sales deck. A per-customer off switch is built before the first wave. All 30 agents are trained, an engineer is on call for the first two weeks, and customer success contacts every beta customer that reported a problem. If paying customers are below 150 at day 60, the executive team reviews the launch. Each owner signs off at a readiness meeting one week before the conference.
For the announcement wording itself, see war-game a press release before the announcement goes out.
A request you can copy
Below are our launch plan, success measures, capacity test results, the pricing and packaging decision, support and sales readiness notes, and the rollback plan. Mark each item settled or open. Check whether "launched" is defined in measurable terms. Run the launch at plan, at ten times plan, and at a tenth of plan, and name what breaks first in each case. Flag missing owners, missing review dates, and any rollback step that cannot work per customer. Stop there so we can answer in writing, then review our answers.
How Pingpong runs the review
The web review app sends your request through several models in order. Each later model receives the original request and every earlier answer, with instructions to assess the work so far. For the steps inside the app, see running your first review.
What a model can't review
A model does not run your systems or talk to your customers. It can check the plan you paste for gaps, but load testing, beta feedback, and the final go or no-go belong to your team and, for launches that matter to the company, the board.
When the launch goes to the board, see war-game a decision before the board meeting. More guides live under work decisions before you commit.