How to cut features without tanking revenue

Is the feature dead or dormant?

Telemetry is the starting point. You need usage data at the per-user level, not aggregate. A feature used by 1,000 users might look healthy at the aggregate level while being used zero times in the last 90 days by 980 of those users. The relevant question is: how many users would notice if this feature disappeared tomorrow? If the answer is fewer than 2% of your active user base, you have a candidate for deprecation review. Track: event count per feature per user per week. If the median is zero, the feature is dormant.

Who uses it and how much do they pay?

Usage volume is one axis. Revenue concentration is the other. A feature used by 2% of users might be used by 100% of your enterprise tier, which is your highest-revenue cohort. Before you cut anything, cross-reference the user list against revenue. If the feature is load-bearing for a revenue segment, the economics of removal are very different from a feature used by low-paying power users.

Is it load-bearing for any other feature?

Some features are infrastructure for other features. The API endpoint that serves two external integrations and three internal features is not removable the same way as an isolated UI widget. Before cutting, trace the dependency graph. What calls this feature? What does this feature call? What breaks if it is removed? This is especially important for features that were originally built as platforms for future work: the future work arrived, but the platform underneath may have accumulated undocumented dependents.

Is there a compliance or contractual commitment?

Some features exist because a contract says they must. The audit log that nobody uses may be a SOC2 requirement. The SCIM endpoint that three users have ever touched may be written into a seven-figure contract. Before removing, check: is this feature referenced in any customer contract, any regulatory commitment, or any SLA? If yes, the removal process requires legal review, not just product review.

Delete entirely

The highest-risk approach with the highest reward: the feature is gone, its maintenance cost is zero, and there is no path back. Appropriate when usage is near zero, there are no contractual dependencies, and the feature is not referenced in any user documentation users are likely to be following. The communication requirement is shorter: announce the deletion date, remove it, close the support tickets. Google Reader was deleted entirely. The announcement was made three months in advance. The service was gone on the announced date.

Hide for new users, keep for existing

Apple uses this pattern frequently. New accounts never see the feature. Existing accounts retain access until their usage drops below a threshold or until a planned end-of-life date. The advantage is that you stop accumulating new users for the feature while not triggering complaints from current users. The risk is that you are now maintaining two product configurations: one with the feature and one without. This is expensive if the feature is complex.

Deprecate with a sunset date

The most common responsible approach. Announce that the feature will be removed on a specific date (typically 60-90 days out). Provide migration guidance. Notify affected users. Close the feature to new usage while maintaining it for existing users through the sunset date. On the date, remove it. This approach requires discipline: the sunset date must be firm. Extending it signals that the feature might stay, which undermines the communication and gives users less reason to migrate.

Spin off into a separate product

Sometimes the feature is large enough and used enough that it belongs in its own product, not your product. Foursquare did this cleanly in 2014, splitting into City Guide (places) and Swarm (check-ins). The users who wanted check-ins got Swarm. The users who wanted place discovery got a cleaner City Guide. Meta has done this with limited success: Threads, WhatsApp, and Messenger are all Facebook features that became separate products. The spin-off option is only viable when the feature has genuine standalone value.

In-app notice (30 days before)

"We will be retiring [feature name] on [date]. If you are currently using this feature, here is what happens next: [alternative / export path / migration guide]. If you have questions, contact support at [address]. Thank you for using [product name]." Keep it factual, specific, and actionable. Do not be apologetic in a way that implies the decision might be reversed. Do not over-explain. If users want to understand why, provide a blog post linked from the notice.

Email sequence

Three emails: 30 days out (announcement), 7 days out (reminder with migration steps), and day-of (final notice with confirmation that the feature is now removed and a link to the alternative). The 7-day reminder is the most important: it reaches users who missed the in-app notice and gives them time to act. The day-of email is brief and practical.

Changelog entry

A changelog entry that clearly states the feature is removed, the date, and the reason (brief). This serves users who check changelogs, support teams who need to handle tickets, and future team members who wonder where the feature went. It is also a search engine signal that the feature has been deliberately retired, not abandoned.

Support macro for objections

Train your support team with a standard response for objection tickets. The macro should: acknowledge the inconvenience, explain the decision briefly (product focus, maintenance, low adoption), point to the alternative, and close without offering to escalate as a path to reversal. Every support team member should give the same answer. Inconsistency signals uncertainty, which invites escalation.

Churn exposure calculation

Before removing a feature, model the churn exposure. Identify every account that has used the feature in the last 90 days. Segment by revenue: enterprise, mid-market, SMB. Apply an estimated churn probability to each segment (enterprise: 5-15%, SMB: 15-30%, depending on how central the feature is to their workflow). Multiply usage rate by estimated churn probability by segment ARR. Sum across segments. This gives you an expected revenue at risk, which you can compare against the cost of maintaining the feature (engineering hours per quarter times fully-loaded cost).

The concentration risk check

If a single account represents more than 10% of the feature's usage and more than 5% of your ARR, the decision is not a product decision; it is a customer success decision. Contact that customer directly before making any public announcement. Understand their usage. Offer a migration path or a contractual commitment if the feature is truly critical to them. The public announcement should come after this conversation, not before.

The upgrade-path option

If the feature has genuine value to a specific segment, consider whether it belongs in a premium tier rather than being removed entirely. This allows you to stop offering it to the general population while retaining it as a paid add-on for the segment that values it. The risk is that this approach creates a two-tier product that is more complex to maintain and document. It is worth it only if the segment is large enough and willing to pay enough to justify the overhead.

Cutting something load-bearing

The most common and most damaging failure. A feature that appeared unused was in fact used by the data pipeline, the API integration, or the mobile app in a way not captured by the usage telemetry. The production system starts emitting errors. Support tickets spike. The feature has to be reinstated under pressure. Prevention: dependency mapping before any removal, not after.

Cutting without enough notice

30 days is a minimum for most features. 60-90 days is appropriate for features embedded in customer workflows. Anything less than 14 days is a policy failure. The cost of insufficient notice is not just customer complaints; it is a trust deficit that affects your next removal announcement. Users who were burned by a short notice period will resist the next removal, even if it is handled well.

Cutting and immediately releasing a paid replacement

Remove a feature that users had for free, then immediately announce that a premium version of it is available at a higher tier. This is functionally indistinguishable from a price increase, and it generates the reaction of a price increase. If you are spinning a feature into a paid tier, do it after a reasonable gap and with explicit communication that the decision is not connected to a revenue motive.

Cutting, getting complaints, and re-adding

The worst outcome. You have established that complaints work. Every future removal will generate complaints as users learn that persistence reverses the decision. If you have done the pre-flight checks properly, the complaints you receive after a removal are expected and manageable. Hold the line. Acknowledge the feedback. Do not re-add. If the feature genuinely needed to come back, the pre-flight checks failed, and the lesson is in the process, not the decision.