Killing Features: The Hardest Job of an Early-Stage CTO

Every startup I advise has too many features. Not too many for the users — too many for the team to maintain. Features that were built for a sales demo that happened once. Features that were a bet on a market that did not materialize. Features that a customer demanded in a negotiation and nobody else uses. Each one carries a maintenance cost: bugs to fix, edge cases to handle, code that has to be migrated when the stack evolves. The aggregate weight slows the team down in ways that are invisible until someone does the audit.

Killing features is the job nobody wants. The founder worries about losing the three customers who use it. The product manager worries about the backlash. The engineers worry about the migration. So the features stay, the maintenance burden grows, and the team moves slower every quarter.

This article is the sunset playbook I use to cut features without breaking things — how to identify the candidates, how to measure the true cost, how to communicate the removal, and how to execute without losing customers.

Finding the candidates

The first step is measuring usage. Most startups do not know which features are actually used. The audit is straightforward: instrument every feature with usage tracking (or query your existing analytics), and run it for 30 days. The output is a list of features sorted by monthly active users.

The candidates for removal share a few characteristics. Low usage — fewer than 5% of active users touched it in the last 30 days. High maintenance cost — it generates a disproportionate number of bug reports, support tickets, or engineering hours. Misalignment — it does not serve the product's current target customer. Complexity tax — it adds branching logic, edge cases, or configuration options that complicate the product for everyone.

A feature that is low usage but low maintenance can often stay — it is not hurting anything. A feature that is low usage and high maintenance is the priority target.

Measuring the true cost

The obvious cost of a feature is the engineering hours spent on maintenance. The hidden costs are larger. Cognitive load — every feature the team has to consider when making changes slows the velocity of every other change. Testing surface — every feature that exists needs to be tested on every release, even if nobody uses it. Onboarding overhead — every feature that exists needs to be explained to new engineers, new support staff, and new customers. Opportunity cost — every hour spent maintaining a dead feature is an hour not spent building something users want.

I ask teams to estimate the fully loaded cost of each candidate: engineering hours per month, support tickets per month, the portion of test suite time it consumes, and the number of times it was mentioned in code reviews or architecture discussions in the last quarter. The numbers are usually surprising — a feature that "costs nothing" often costs 5–10 hours per month across the team.

The communication playbook

The communication is where most teams fail. The playbook:

Announce early. Give users 60–90 days notice before removal. For features with paying customers, 90 days minimum.

Explain why. "We are removing Feature X so we can focus on Feature Y, which serves 10x more of our customers." The explanation should be honest and forward-looking. Do not blame the feature or the users who chose it.

Offer an alternative. If possible, point users to another way to accomplish what the feature did. If the feature was an internal reporting tool, suggest an export they can use with their own BI tool.

Offer a migration path. If the feature stored data, provide an export. Users should be able to get their data out before the feature disappears. This is table stakes.

Accept the feedback. Some users will be unhappy. Listen, acknowledge, and hold the line unless the feedback reveals that your usage data was wrong and the feature is more important than you measured.

The technical execution

Phase 1: Feature flag off. Do not delete the code. Toggle the feature off for new users first, then existing users. This is reversible if the usage data was wrong.

Phase 2: Monitor. Watch support tickets, churn, and NPS for 30 days after the toggle. If the impact is within acceptable bounds, proceed. If churn spikes, reconsider.

Phase 3: Remove the UI. Remove the feature from the product interface. The code can remain temporarily.

Phase 4: Remove the code. Delete the feature code, the tests, the database tables (after backing up data), and the configuration. This is the step that actually reclaims the maintenance cost. A feature that is hidden but still in the codebase is still a maintenance burden.

Phase 5: Clean the docs. Remove the feature from documentation, help articles, marketing pages, and onboarding flows.

Counterpoint: some features are strategic, not popular

Not every low-usage feature should die. Some features exist because they are table stakes for a specific customer segment — enterprise customers expect audit logs even if 95% of users never look at them. Some features are strategic differentiators that attract customers who would otherwise choose a competitor. And some features are newly launched and have not yet had time to find their audience.

The judgment call is whether the feature is low-usage because nobody needs it or low-usage because it serves a small but valuable segment. The audit data tells you the first answer. Talking to sales and customer success tells you the second.

Your next step

This week, pull your feature usage data. Identify the three features with the lowest usage and the highest maintenance cost. For each one, estimate the fully loaded monthly cost (engineering hours + support tickets + testing time). If the total exceeds a meaningful percentage of your team's capacity, you have a sunset candidate.

Where I come in

Feature audits and sunset planning are a standard part of my product-engineering alignment work. I help teams measure the true cost, make the cut/keep decision, and execute the sunset without losing customers. Book a call if your feature set is growing faster than your team and you need a structured approach to pruning.