Not a lot of product teams actively think about killing features.
I get it. The whole job feels like it's about building — shipping the next thing, hitting the roadmap, unblocking engineering. Cutting something you already shipped? That's a hard sell internally. Nobody gets promoted for making the product smaller.
But my team at Google did exactly that. And it was one of the best product decisions we made.
If you want to jump to a specific section:
What we cut at Google Maps (and why)
Google Maps had a strong culture of cutting features. Making the product simple was treated as real work, not “cleanup”. The product team was constantly evaluating what was earning its place and what wasn't.
One example: there was a "follow" feature on Maps that let you follow other people's reviews and activity. People used it. Local guides built followings around it. But when we looked at the data, it wasn't driving the outcomes that mattered for Maps.
So we cut it. (and of course there's a Reddit thread about it)
That's the thing about cutting features: it's never easy because someone always cares. But every feature you keep has a maintenance cost — the test coverage, the edge cases, the support tickets, the cognitive load on users navigating around it, and the engineering time that could go to something that actually moves the needle.
Holdout experiments: how we actually knew what to cut
One of the practices that made this possible was running holdout experiments. We'd keep a small group of users on the old version — without a feature or set of features — and compare their outcomes to the main group over time.
Meta does the same thing. Their product teams run holdouts at the start of every half. They keep a percentage of users without the new features shipped during that period, then compare at the end. Sometimes a team ships 10 features in 6 months and the holdout shows no meaningful difference. All that work added complexity without moving the needle.
This is the measurement problem most companies don't solve. They ship a feature, see some adoption, and call it a win. Nobody goes back 6 months later to ask "is this still earning its place?"
Holdouts force that question, and the answer is sometimes uncomfortable.
Slack learned this the hard way — one tiny feature, 1000s of hours
Slack founder Stewart Butterfield described how removing one tiny feature — pre-populating the reply field with the previous responder's name — consumed "thousands of person hours at minimum" just to evaluate and roll back.
That's the hidden cost of even small additions. Every feature you ship is a commitment to maintain it forever, or spend enormous energy removing it later. Slack learned that lesson early and it shaped how they thought about adding anything new.
How to bring this system to your team
Most of what I just described might sound like a "big company" practice. But honestly these principles work at any scale. Here's what you can actually start doing next week:
Audit a neglected feature. Start with one. Pick a feature your team shipped 6+ months ago. Pull the usage data. How many active users does it have? Is that number growing or declining? If less than 5-10% of your users touch it monthly, it's a candidate.
Set kill criteria before you ship your next feature. Define what "failure" looks like before launch — what usage threshold triggers a review in 90 days. Writing it down in advance makes the decision feel objective later, not political.
Run a simple holdout on your next release. You don't need Meta's infrastructure. Keep 5% of users on the old version for 30 days. Compare retention, engagement, and support ticket volume. If there's no difference, you have your answer.
Make "what should we remove?" a recurring agenda item. Add it to your monthly product review. Just asking the question changes the culture. PMs start thinking about the full lifecycle of a feature, not just the launch.
Track the compound cost. Every feature has first-order cost (building it) and second-order cost (maintaining it). But there's a third-order cost most teams miss — complexity. Going from 10 features to 11 doesn't add 10% complexity. It adds another dimension that touches testing, onboarding, documentation, and support. Start naming that cost out loud.
The hardest part (still worth it)
The hardest part about doing any of this is the culture shift it asks for.
PMs are wired to build. Engineering teams get attached to their work. Sales has promised features to prospects. Killing something means telling all of those people that the thing they invested in is going away.
But the alternative is a product that gets heavier every quarter. More surface area for bugs. More decisions for users who just want to get their job done.
The best product culture I've seen — and this is what we tried to build at Google — pushes PMs to continuously think about making the product simpler, not just bigger. That helps the org (less maintenance, more focus) and users (less confusion, faster workflows).
The stat that always gets me: 64% of all developed software features are rarely or never used. Pendo's data says it's closer to 80%. Either way, most of what we build doesn't matter.
The question is whether your team has the discipline to do something about it.
— Ishwar, Co-Founder @ ThriveAI
One of the things we built Thrive to do is help PMs spot declining feature engagement before it becomes a problem. It connects your analytics to your support data and flags when usage patterns shift — so you have data, not opinions, when it's time to make the cut. If that sounds useful, check it out.