Before you remove a feature from a product that continues, find out who uses it weighted by revenue, where the company has promised it, what replaces it, and how you would turn it back on for a key account. Paste usage data by account, the maintenance and support cost, contract and order form mentions, the replacement plan, and the draft announcement into one request. Instruct Pingpong to test whether the usage figure hides a small group of important customers, to list every place the feature is promised, and to check the removal sequence for a rollback step. Review your written answers in a second round. Counsel owns contract language about included features.
This page is for chief executives, product leaders, and executive teams deciding whether to cut a capability that costs more to keep than it seems to return. Executive starting points live under Pingpong for executives.
Look past the usage average
"Three percent of accounts use it" can mean three percent of revenue or a fifth of it. Break usage down by account size, plan, and renewal date. Ask what those accounts do with the feature and whether the replacement covers that job.
Find every place it is promised
Features get promised in more places than the product page. Check order forms and contracts, sales decks and demo scripts, help articles, public API documentation, partner integrations, and security or compliance questionnaires. Any of these can turn a quiet removal into a dispute.
Remove it in order
- Close the gaps in the replacement that matter to heavy users.
- Stop selling the feature: update decks, demos, and documentation.
- Tell the largest dependent accounts directly, before any public notice.
- Give in-product notice with a date and a link to the replacement.
- Turn the feature off behind a switch that can restore it per account.
- Delete the code only after the rollback window passes without problems.
A worked example
This example is illustrative and does not describe a customer. A 250-person project management software company wants to remove its legacy custom report builder. About 420 of its 14,000 accounts use it. It takes two engineers full time to maintain, and its slow queries generate 12% of support tickets. The product team plans to remove it in the next release, with a line in the release notes pointing to the newer dashboards.
The chief product officer pastes usage by account with revenue, the maintenance and ticket data, a list of order forms mentioning reporting, the dashboard roadmap, and the draft release note.
A useful pass finds that the 420 accounts produce 19% of recurring revenue, because most are enterprise customers. Nine enterprise order forms list "custom reporting" by name, a question for counsel. About 60% of the heavy users schedule reports for email delivery, which the dashboards cannot do. The sales team still demonstrates the report builder to prospects. Several partner integrations call the report endpoints in the public API. The plan has no way to restore the feature if a large account breaks.
The revised plan adds scheduled email delivery to dashboards before anything is announced. Sales removes the report builder from demos immediately. Account managers call the 40 largest dependent accounts, then all users get 90 days of in-product notice. The API endpoints stay available, read-only, for six months, with notice to partners. On the removal date, the feature is switched off with the ability to restore it per account for 30 days. Counsel reviews the nine order forms before the announcement. The two engineers move to dashboard work once the switch is off, and the executive team reviews ticket volume and renewal risk among affected accounts at 30 and 90 days.
If you are retiring the whole product, see check the gates before you sunset a product.
A request you can copy
Below are usage data by account with revenue, the cost to maintain and support a feature we want to remove, every contract or document mention we have found, the replacement plan, and the draft announcement. Show whether usage is concentrated in high-value accounts. List places the feature is promised that we may have missed. Check whether the replacement covers what heavy users do. Review the removal sequence for direct notice to key accounts and a rollback step. 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 sees only the usage data and documents you provide. It cannot see how customers rely on the feature in their own workflows, or what account managers have promised in conversation. Counsel owns contract obligations, and you own the decision.
When the decision goes to the board, see war-game a decision before the board meeting. More guides live under work decisions before you commit.