Before you announce the end of a product customers already pay for, check each readiness gate: revenue at risk, contractual notice, the migration destination, support through the end date, consistent messages for customers and investors, and a plan for walking back the date if migration stalls. Paste the sunset plan, customer and revenue counts, a contract summary from counsel, migration test results, support staffing, and draft customer and investor messages into one request. Instruct Pingpong to mark each gate ready or not ready, with the evidence, and to flag numbers that differ between documents. Review your written answers in a second round. Counsel owns notice and contract obligations.
This page is for chief executives, product and customer leaders, and directors retiring a shipped product, edition, or major plan. Executive starting points live under Pingpong for executives.
The gates
Revenue at risk. Ready when you know how many customers and how much recurring revenue sit on the product, and have a realistic retention estimate. Not ready when the estimate is a hope.
Contractual notice. Ready when counsel has confirmed the longest notice period and any commitments that outlast the end date. Not ready when the date was chosen before anyone read the contracts.
Migration destination. Ready when the replacement does what the largest and most demanding customers need, and the migration has been tested on their data. Not ready when key capabilities are still on the roadmap.
Support through the end date. Ready when the people who know the old product stay staffed until the last customer moves. Not ready when the plan reassigns them at announcement.
One set of numbers. Ready when the customer letter, the investor update, and the board plan describe the same timeline and retention estimate. Not ready when each audience hears a different version.
Plan the walk-back before you announce
Sunsets slip when migration runs into problems. Decide in advance what triggers an extension, who decides it, and which customers it covers. An extension planned as a contingency reads as care. One improvised after complaints reads as a plan that was never ready.
A worked example
This example is illustrative and does not describe a customer. A 350-person analytics software company plans to retire its on-premises edition in favor of its cloud product. The edition has 140 customers and $11 million of the company's $60 million in recurring revenue. The draft plan announces in 30 days, with support ending nine months later.
The chief executive pastes the plan, the customer list with revenue, counsel's contract summary, migration test results, the support roster, the customer letter, and the investor update.
A useful pass marks most gates not ready. Counsel's summary shows 38 contracts with 12-month notice clauses, so the nine-month date conflicts with them. Twenty-two customers, mostly in regulated industries, require a data residency option the cloud product will not have until next quarter. The migration tool worked for five test customers but failed on the largest data sets. The staffing plan moves six of the nine engineers who support the edition to cloud work at announcement. The investor update projects 90% retention, while the finance plan assumes 75%. The customer letter promises a "seamless migration," which the test results do not support. Nothing describes what happens if migration falls behind.
The revised plan waits to announce until the residency option is in beta. The end date moves to 15 months after notice, covering the longest notice clause, and customers migrate in groups, starting with the smallest. All nine engineers stay on the edition through month 12. The investor update and board plan both use 75% retention, putting about $2.75 million of recurring revenue at risk. The customer letter lists the steps, the dates, and the support available. If the residency option or the migration tool for large data sets slips more than 60 days, the end date for affected customers extends automatically, a rule the board approves in advance.
If the work you want to stop never reached customers, see test the evidence before you kill the project.
A request you can copy
Below are our plan to retire a shipped product, customer and revenue counts, counsel's contract summary, migration test results, support staffing, and draft customer and investor messages. Mark each gate ready or not ready with the evidence: revenue at risk, contractual notice, migration destination, support through the end date, and consistent numbers across audiences. Flag any figure or date that differs between documents. Check whether we have a walk-back plan. Mark contract questions for counsel. 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 know how your customers will react, what competitors will offer them, or what each contract says beyond the summary you provide. Counsel owns notice obligations, and you and the board own the decision.
When the plan goes to the board, see war-game a decision before the board meeting. More guides live under work decisions before you commit.