Scrolls
6 min read
On this page

Killing Features

The hardest part of product development is not building things. It is removing them. Every feature you ship becomes a liability: it needs maintenance, bug fixes, documentation, support, and compatibility with every future change. The best product teams are not the ones that build the most features — they are the ones willing to kill features that are not working.

Most teams never kill features. They accumulate them like sediment until the product is a museum of good intentions and sunk costs.

The Sunk Cost Problem

"But we spent three weeks on this" is not a reason to keep a feature nobody uses. The three weeks are gone regardless of what you do next. The question is not "was this worth building?" The question is "is this worth maintaining?"

The sunk cost calculation:
  Cost already spent: 3 engineer-weeks
  Ongoing maintenance cost: ~2 hours/week (bug fixes, edge cases,
    compatibility with new features, support tickets)
  Annualized maintenance: ~100 hours/year
  Usage: 12 users out of 5,000 (0.24%)

  Keeping this feature costs 100 hours/year to serve 12 users.
  Killing it frees 100 hours/year for features that serve thousands.

The emotional difficulty is real. Engineers feel ownership of the code they wrote. Product managers feel ownership of the features they specified. Designers feel ownership of the interfaces they designed. Killing a feature feels like saying their work was wasted. It was not wasted — it was an experiment, and the experiment produced a result: this feature does not work.

Google kills products aggressively and has been widely criticized for it (Google Reader, Google Plus, Inbox, Stadia). But the criticism misses the point: Google's willingness to kill things is part of what lets them try things. If every product launch were a permanent commitment, they would launch fewer products and learn less. The same principle applies to features, just at a smaller scale.

Track Usage Before You Need To

You cannot make informed kill decisions without data. Track feature usage from day one, not after someone asks "does anyone use this?"

Minimum usage tracking:
  For every significant feature, track:
    - Unique users per week who engage with the feature
    - Frequency of use per user
    - Trend: is usage growing, stable, or declining?

Implementation:
  Simple: Log an event when the feature is used
    logEvent('feature_used', { feature: 'advanced_filters', userId })

  Then query:
    SELECT feature, COUNT(DISTINCT user_id) as weekly_users
    FROM events
    WHERE timestamp > NOW() - INTERVAL '7 days'
    GROUP BY feature
    ORDER BY weekly_users ASC  -- lowest usage first

The features at the bottom of that list are your kill candidates.

Mixpanel, Amplitude, or PostHog can do this out of the box. If you do not want to add an analytics service, a simple events table in your database works fine.

Set Kill Criteria Before You Build

The most effective technique for overcoming the sunk cost fallacy: define what failure looks like before you write a single line of code.

Pre-build kill criteria:
  Feature: Advanced search filters
  Hypothesis: Users who can filter search results will retain better
  Success metric: 7-day retention of filter users is >20% higher
                  than non-filter users
  Minimum usage: At least 15% of active users try filters within
                 30 days of launch
  Kill trigger: If <5% of users try filters after 30 days, or if
                retention improvement is <10%, kill it
  Evaluation date: 2026-05-18 (30 days after launch)

Writing this down before you build does three things:

  1. It forces you to articulate why you believe this feature matters
  2. It gives you an objective benchmark that is not influenced by sunk costs
  3. It sets an explicit evaluation date so the decision does not get deferred forever

Spotify uses a similar approach with their "Think It, Build It, Ship It, Tweak It" framework. Every bet has a hypothesis and success criteria. If the metrics do not hit the criteria, the feature gets killed or significantly reworked, regardless of how much effort went into it.

How to Kill a Feature

Killing a feature is not just deleting code. It is a process that respects users who depend on it.

Feature kill process:
  1. Confirm the data: Is usage truly low? Are the right users
     being measured? Talk to 3-5 users who DO use it — are they
     power users whose workflow depends on it?

  2. Communicate early: If users will be affected, tell them.
     "We're removing X on [date]. Here's why. Here's the alternative."

  3. Provide a migration path: If the feature stores data, export it.
     If users have workflows built around it, suggest alternatives.

  4. Set a removal date: Not "eventually." A specific date.

  5. Remove the code: Delete it. Do not comment it out. Do not
     hide it behind a flag "just in case." Git has history.

  6. Remove the documentation, the UI elements, the API endpoints,
     and the tests. A half-removed feature is worse than a live one.

  7. Celebrate: Announce it. "We removed X, which frees up Y hours
     per month for features you actually use."

When to Kill Immediately vs Gradually

Kill immediately (no warning needed):
  - Features behind a flag that were never fully rolled out
  - Internal tools that only the team used
  - Experimental features labeled as "beta"
  - Features with literally zero usage

Kill gradually (give notice):
  - Features that some users depend on, even if usage is low
  - Features with API consumers
  - Features that store user data
  - Anything where removal would break someone's workflow

The Feature Budget

One useful constraint: set a maximum number of features your team maintains. When you want to add one, you must identify one to remove.

The feature budget approach:
  Current feature count: 25
  Budget: 25
  New feature proposed: Smart notifications

  Before building smart notifications, identify a feature to kill:
    Candidate: CSV export (used by 3 users, 1 of whom is internal)
    Action: Remove CSV export, add smart notifications
    Net feature count: 25

  This forces the team to confront maintenance costs every time
  they want to build something new.

Basecamp (37signals) practices this philosophy. They deliberately keep their product small. Features that do not earn their keep get removed. This is not about being minimalist for aesthetic reasons — it is about keeping the product maintainable and the team focused.

Fighting the Emotional Resistance

Killing features is emotionally difficult for everyone involved:

Engineer: "I spent two weeks on this."
  Response: "And now we know it doesn't work. That's valuable
  information. The code served its purpose."

Product manager: "But our roadmap said we'd ship this."
  Response: "The roadmap is a plan, not a promise. Plans change
  when we learn new information."

Designer: "I designed this interaction specifically for this flow."
  Response: "The design was excellent. The hypothesis was wrong.
  Those are different things."

Customer: "I use this feature every day."
  Response: "We hear you. Here's the alternative. If enough people
  feel this way, we'll reconsider."

Founder: "This was my idea."
  Response: "It was a good idea to test. The data says it didn't
  work for most users. Killing it frees resources for ideas that will."

The common thread: separate the quality of the work from the outcome of the experiment. Good engineers can build a feature that nobody needs. That does not make them bad engineers. It makes them part of a team that is learning.

What to Kill: The Audit

Run a feature audit quarterly:

Feature audit template:
  For each feature, answer:
    1. How many unique users per week? ___
    2. Is usage trending up, flat, or down? ___
    3. How many support tickets does it generate per month? ___
    4. How many hours of maintenance per month? ___
    5. If we removed it tomorrow, how many users would complain? ___
    6. What would we build with the freed capacity? ___

  Kill candidates:
    - Features with <1% weekly active user engagement
    - Features where maintenance hours exceed usage hours
    - Features with declining usage for 3+ consecutive months
    - Features that generate more support tickets than engagement

Instagram famously resisted feature bloat for years. While competitors added every conceivable feature, Instagram maintained a focused product. When they did add features (Stories, Reels), they were strategic bets based on clear user behavior data, not incremental additions from a backlog.

Celebrate Killing Features

If you only celebrate launches and never celebrate removals, you are training your team to accumulate and never prune. Make killing a feature a positive event:

What celebration looks like:
  - Announce it in the team channel: "We removed X. Here's what
    we learned from it. Here's what we'll build with the freed time."
  - Include it in sprint demos: "This sprint we shipped Y and
    removed Z."
  - Track "features killed" as a metric alongside "features shipped"
  - Thank the people who built the feature for the learning, not
    the feature itself

Amazon's "Working Backwards" process includes a pre-mortem: before building, imagine the feature failed. What would that look like? This makes killing features less emotional because failure was already considered as a possibility before a line of code was written.

Common Pitfalls

  • Never setting kill criteria. Without pre-defined failure conditions, every feature gets to argue for its continued existence based on anecdotes rather than data. Define success before you build.
  • Waiting too long to evaluate. A feature that has been live for a year with 0.5% usage is not "still ramping up." It failed. Kill it and move on.
  • Partial removal. Commenting out code, hiding UI elements, or disabling endpoints without removing them creates ghost features that confuse everyone. Delete the code. Git has history.
  • Listening only to vocal users. The three users who email you about a feature are not representative. Look at the data. Three vocal users out of 5,000 is 0.06% — not a reason to maintain a feature.
  • Equating removal with failure. Killing a feature is not admitting defeat. It is making a data-driven resource allocation decision. The experiment produced information. Use it.
  • Not providing a migration path. For features people do use, abruptly removing them destroys trust. Communicate the timeline, offer alternatives, and export their data.

Key Takeaways

  • Every feature is a liability. It requires maintenance, support, and compatibility with every future change. The cost of keeping a feature is ongoing; the cost of building it was one-time.
  • Set kill criteria before you build. Define what failure looks like, what the success metrics are, and when you will evaluate. This removes emotion from the kill decision.
  • Track feature usage from day one. You cannot make informed kill decisions without data. A simple events table showing unique weekly users per feature is sufficient.
  • Celebrate killing features the same way you celebrate launching them. If only launches are celebrated, the team will only accumulate.
  • Run a quarterly feature audit. Identify features with less than 1% engagement, declining usage, or high maintenance-to-value ratios. These are your kill candidates.