We need to kill more features

I think we need to kill more features. We carry too much in our products because it's already there, even when we can no longer explain why it deserves the time, attention, and complexity it adds.

We want to experiment more and take on new bets, but we keep asking the same team to carry everything from the previous ones. Customers have more to navigate, support has more to explain, and every new change has more existing behavior to account for. Over time, that leaves us with a bloated product and less room to try something else.

For those of us working in product, removing features should be part of how we make that room. We should look at what we already have, decide what still earns its place, and act on the things that don’t. AI making it cheaper to build makes this more important, as we can add new obligations faster than we retire old ones.

If we want to take more bets, we need to get comfortable ending some of the ones we're still carrying.

What are we still paying for?

A feature can take very little active development and still affect the rest of the product. It remains in the navigation, shows up in support conversations, and needs to keep working when we change something around it.

Imagine a reporting feature that few customers use. It has its own filters, scheduled emails, and an export format. A change to the underlying data now needs to account for those reports. Support needs to understand why an export looks different from the dashboard. Someone has to decide whether a new capability should appear in the reports too.

It may still be worth all of that. But “we already built it” tells us nothing about whether it is.

When deciding what to keep, I'd look at:

• Customer effort: Does it help people do something important, or add more choices and confusion?
• Maintenance: What needs testing, updating, or protecting every time something else changes?
• Support and operations: What questions, exceptions, and manual work does it create?
• Attention: How often does the team return to it, and what gets postponed as a result?

Product bloat is easy to discuss as a cluttered interface. I think the less visible part is how much old behavior we carry into every new decision. Hiding a feature from the menu might tidy the screen while leaving most of that work in place.

Define what would make us kill it

I think kill criteria deserve a place alongside acceptance and success criteria. When we agree to try something, we should also agree on what would make us stop carrying it:

• Acceptance criteria: What needs to be true before we release it?
• Success criteria: What outcome would justify continuing or investing more?
• Kill criteria: What evidence would make us end the experiment or remove the feature?

Before launch, I'd want us to agree on who the feature is for, what change we expect to see, how long we need to observe it, and when we'll make a decision. Someone also needs to own that review. Otherwise, a launch date can be firm while the date for deciding whether it worked never arrives.

For the reporting example, we might expect customers to use the reports to complete a recurring task without asking support for help. We should give the intended customers a fair chance to discover the feature and go through that task. If it still needs more manual help than the approach it replaced, that's a reason to reconsider it.

Missing the success target should start a decision. Perhaps customers couldn't find the feature, or one part of the experience stopped them from getting value. A further attempt can make sense when we can explain what we're changing and why. We should also agree on what would make us stop after that attempt.

I think the problem is how easily “give it more time” can become the answer without anything changing about the premise. When we've given it a fair attempt and the reason to keep it still doesn't hold up, we should follow through on removing it.

We can apply the same thinking to features that have been live for years. What value do they provide today, what does keeping them cost, and would we choose to keep supporting them if we were making that decision now? We don't need to wait for another launch to start.

Be clear about what deserves to stay

I'd be careful about turning this into a rule that every feature below a usage threshold gets deleted. Something used once a year can matter a lot when that moment comes. A feature serving a small group may be essential to the reason those customers use the product.

We need to understand what people rely on, what would happen if it disappeared, and whether there's a simpler way to meet that need. Usage is part of that conversation. So are the value it provides, the commitments we've made, and the cost of continuing to support it.

Those are concrete reasons to keep a feature. I think we should be able to name them when we decide it stays, just as we should be able to explain why another feature goes.

Removing it is product work too

Customers may have built workflows around something we now want to remove. Calling it an experiment doesn't undo the time they spent setting it up or the expectations we created.

We need to work through the exit with the same care:

• Who depends on it, and what will they do instead?
• What notice, migration help, or access to their data will they need?
• Which promises do we need to honour?
• What work can we actually retire once customers have moved?

There may be a period where keeping it is necessary while we help people move. That cost belongs in the decision too. Once we choose to remove it, the transition needs an owner and a plan so the decision turns into actual work we can retire.

I also think we should recognise the work involved in removing a feature properly. If we celebrate launches but treat removal as an admission that someone got it wrong, we make it harder for people to recommend it. A team that learns something didn't justify its place and acts on that learning has done useful product work.

Can we bring it back later?

Removing a feature doesn't have to mean abandoning the idea forever. We might only realise after launch that it needs something else to work well.

Suppose those reports depend on data customers currently have to enter manually. We learn that the effort of keeping the data current makes the reports too difficult to use. An integration released later could change that premise.

If that happens, we can revisit the idea, test it again, and double down if the evidence supports it. It might return in a simpler form, become part of another workflow, or be spun off into something of its own.

We can keep what we learned and the conditions for another attempt without keeping the feature live while we wait.

I'd record why we stopped, who found value in it, and what would need to change for another attempt to make sense. “The integration now exists” gives us something concrete to investigate. “Maybe people will want it someday” gives us very little.

Bringing it back still takes work, and the new premise needs testing. But we can go again with a better understanding of what the idea needs.

Making room for more bets

I think we should make removing features a regular part of product work. When we plan what comes next, we should also decide what we can stop supporting and make time to remove it properly.

That gives experimentation a more realistic cost. We can take a bet, learn from it, and end it when it doesn't justify staying. We can also return to an idea when the conditions improve, without carrying it through all the time in between.

A leaner product gives customers less unnecessary work and gives the team more attention to put into the things that matter. That's what I want us to get back by killing more features.

Which features in your product are still there because nobody has made a decision about them? Do you define what would make you stop as clearly as you define success?

And what have you removed that you would try again if the right premise changed?