The Best Feature Is the One You Didn't Ship

How Products Lose Focus One Reasonable Decision at a Time

You know that thing in Season 2 of Stranger Things where Will keeps seeing the Shadow Monster? At first it’s just flickers. A dark shape in the sky over Hawkins. Something deeply wrong that he can’t quite explain. He tries to tell Joyce, to tell the others, and they believe him, sort of, but nobody really understands the scale of what he’s seeing. Each vision gets worse. The thing in the sky gets bigger, closer, more unavoidable. By the time the rest of the group finally grasps what they’re dealing with, it’s already taken hold.

That’s feature bloat. Not the kind that shows up overnight. The kind that grows a little bigger after every sprint while the people building the product keep saying “it’s fine, we’ve got it under control.” They’re not wrong about any individual decision. They just can’t see the shape of the thing they’ve built.

I’ve seen this happen at every company I’ve worked at. A sales team needs something to close an account. Customer success needs a workflow to keep a client from churning. The CEO goes to a conference and comes back fired up about some capability a competitor showed off. Each ask lands on the roadmap for a perfectly good reason. Nobody’s making a bad call in isolation.

But zoom out two years, and the product has quietly become a sprawling messy monster. It does a lot of things adequately and nothing memorably. Users can’t find what they came for because it’s buried under stuff that was built for reasons they’ll never know about.

So what happened? No single bad decision. Just a long series of reasonable ones that nobody ever stepped back to evaluate together.

The “Yes” Machine

Think about the last time someone in a roadmap meeting said “we shouldn’t build that” and the room actually listened.

If you’re struggling to remember, you’re not alone. Product organizations are basically engineered to say yes. Requests show up attached to revenue, or a competitive threat, or a frustrated customer, or someone with enough authority that pushing back is a career risk. And I mean that literally. If the person asking can promote you or fire you, saying “I don’t think we should build that” stops being a design decision and starts being a political one.

The person pushing the request always has a story. “We’ll lose this account.” “Our competitor already has this.” “The board is asking about it.” Those stories are specific and urgent, and they’re hard to argue with even when you have the standing to try.

Arguing for restraint means defending something abstract. You’re essentially saying “the product will be better in six months if we don’t do this,” and good luck getting anyone excited about that.

There’s a great study from 2021 by Gabrielle Adams and her team at UVA, published in Nature, that helps explain why this keeps happening. They ran eight experiments where people were asked to improve things, everything from Lego structures to miniature golf courses, and found that people almost always reach for adding rather than subtracting. Even when removing something would have worked better. They called it “additive bias,” and it got worse when people were under time pressure or cognitive load.

That was a lab setting, not a roadmap meeting. But think about it: a product team under deadline pressure, juggling competing stakeholder demands, trying to make decisions with incomplete information about what users actually need? That’s cognitive overload as a lifestyle. If additive bias shows up when someone’s solving a puzzle under a time crunch, of course it shows up when your team is planning the next quarter.

And AI has removed what little friction was left. When building a feature used to take multiple engineers, designers and a sprint, the cost alone forced some evaluation. Now an AI coding tool can spit out a working version in a day. The barrier between “someone asked for this” and “it’s in the product” is thinner than it’s ever been. The yes machine didn’t just get louder. It got faster.

Adding features isn’t the problem by itself. Sometimes aggressive addition is exactly the right move. Slack, Notion, Figma, all of these products went through periods where they were shipping fast and it was smart. When you’re chasing competitive parity or figuring out product-market fit, restraint can actually hurt you. The problem starts when addition becomes the default and nobody’s asking what all those features are doing to the product. You can ship a lot and stay focused. You just have to actually look at the whole picture once in a while, and most teams don’t.

You Can Spot It

I can usually tell when a product’s been run on autopilot for a while. There are a ton of features and none of them feel finished. Half of it was built to close a specific deal or because a competitor had it. The rest was somebody’s passion project. And none of it was designed as a coherent whole, which you can feel the second you start poking around. The navigation has ballooned. New users land in the product and face a wall of options with no clear path to the one thing they actually need. The structure isn’t organized around what users need. It’s organized around when things got added.

Users are dropping off during onboarding because features that shipped fast to meet a deadline keep confusing people. And the design team is stuck maintaining the mess instead of improving anything meaningful. Nobody planned for the product to end up like this. Every team contributed a little, one reasonable decision at a time.

You’ve probably already seen the newest version of this too, features that exist because AI made them easy to build, not because anyone asked for them. An AI-powered summary, a smart suggestion panel, a copilot bolted onto a workflow that was working fine without one. These ship under the banner of “AI-first” strategy, and they’re usually driven less by user need than by leadership wanting to signal that the product is keeping up with the moment. It’s the same pattern wearing a new outfit. The features arrive for reasons that sound strategic, and nobody stops to ask what they’re doing to the product.

Learning to Make the Unpopular Argument

So if the system is set up to keep saying yes, what can a designer actually do about it?

The most valuable thing you can bring to a product team is the willingness to say “I don’t think we should build that.” Call me naive, but I think that’s a real superpower when it’s done right. The tricky part is that doing it right requires skills not many people have, but it can be learned. You need organizational awareness, the ability to read a room, and enough spine to hold a position when people push back. And they will push back, because you’re standing between them and the thing they want.

How hard it is depends on who’s asking. Telling a sales lead that a feature request might not be worth building is one thing. Telling the CEO their conference-inspired idea doesn’t fit the product strategy? That’s a whole different conversation. And pushing back on your own engineering partners when they’re excited about a technical challenge is tricky too, because those are the people you collaborate with every day and you don’t want to be the person who’s always killing momentum.

Nobody teaches you how to navigate this stuff.

And that CEO scenario? When the person asking outranks you by three levels, you probably aren’t going to win a head-on argument, and trying might cost you more than the feature is worth. What you can do is build the case quietly. Get your PM on your side first. Frame your concerns as questions rather than objections: “How do we make sure this doesn’t complicate onboarding?” or “Can we scope this so it doesn’t touch the core workflow?” Sometimes you redirect the energy into a smaller, less damaging version. And sometimes, honestly, you document your concerns, let it ship, and make sure the data is there to tell the story six months later when the team revisits it. Not every battle is one you fight in real time.

And it’s gotten even harder now that everyone’s role is bleeding into everyone else’s. When PMs are mocking up screens in Figma, engineers are making UX calls, and everyone has access to AI tools that can generate “good enough” design work, who exactly is supposed to be the one saying “we shouldn’t build this”? If nobody clearly owns that job, nobody does it. And the product keeps growing. That’s also the opportunity, though. The designer who steps into that gap, who says “I’ll be the one watching the whole experience,” becomes one of the most valuable people on the team.

Let the Data Make the Argument

In my experience, data makes the argument for you. Gut instinct and design principles won’t carry you very far when someone’s waving a revenue target. But usage metrics, session drop-off rates, time-on-task numbers, etc? Those change the temperature. If you want to be the person who can say no effectively, start by becoming the person who knows the numbers.

I can already hear some of you thinking: “Great, but I don’t even have access to that data.” Fair. In a lot of organizations, designers don’t have dashboard access. They don’t know SQL. They aren’t invited to the meetings where metrics get reviewed. If that’s you, getting access is step one, and it’s worth treating as a real project rather than a thing you’ll get around to. Ask your PM to add you to the analytics tool. Sit in on a metrics review and just listen. Ask engineering to pull a report for you and study it until you can ask for the next one in specific terms. You can’t argue with numbers you don’t have, so getting the numbers is the job before the job.

Of course, sometimes the designer is wrong. The feature that feels like clutter to you might be solving a real problem for users you haven’t spent enough time with. Saying no well means doing your homework first, researching before you react. The goal is to be the person who asks the right questions before the team commits, not the person who blocks everything.

Some Practical Ways to Get Started

If you’re reading this and thinking “okay, but what do I actually do on Monday,” here are some things that have worked for me and for teams I’ve been part of.

Before building, ask what happens if you don’t. But don’t just silently sit on the request for two weeks and hope it goes away, because that will get you labeled as a blocker fast. Instead, name the delay out loud. Go to your PM or the stakeholder and say something like “I want to make sure we’re building the right version of this. Can we give it two weeks to validate the assumption before we commit engineering time?” You’re framing it as diligence, which it is. Align with your PM first if you can, so you’re not the lone voice pushing back.

You’ll be surprised how often, in those two weeks, the deal closes anyway, the competitive urgency fades, or the person who was fired up about it moves on to something else. Two weeks of breathing room can save you months of maintenance on a feature nobody ends up using.

Do a feature audit on one section of your product. Just one. If you try to audit the whole thing at once you’ll lose a week and your will to live. Pull whatever usage data you can get your hands on, even basic analytics will do. Look at which features people actually use and which ones are sitting there confusing people.

But be careful with how you interpret what you find. A feature with low usage isn’t automatically dead weight. It might be buried in the nav and nobody can find it. It might be used by a small percentage of users who happen to be your highest-value accounts. You’re not building a kill list. You’re looking for patterns, features that are rarely used and generate confusion, features that overlap with each other, features where the maintenance cost clearly outweighs the value.

When you propose removing something, lead with what the team gets back. “If we sunset this feature, that frees up two sprints this quarter. Here’s what we could build instead.” People who get nervous about taking things away respond much better when they see what they gain in return.

And if you can swing it, get your team to dedicate even 10% of each sprint to simplification. When simplification has a budget, it becomes real work instead of something everyone agrees is important and never gets around to doing.

Your PM Wants Your Help

You might be thinking “isn’t this the product manager’s job?” And yeah, in theory, ruthless prioritization is exactly what PMs are supposed to do.

In practice, it depends on where you work. If you’re at a sales-led or enterprise-driven company, your PM is probably under enormous pressure to ship whatever closes deals. They’re measured on throughput. They’re caught between sales, customer success, and leadership, and saying no to any of those groups has real career consequences. If you’re at a product-led growth company where PMs are measured on retention, activation, etc, it’s a different story. Your PM might already be doing this. But even in those orgs, having a design partner who shows up with experience data is valuable.

The best PMs I’ve worked with, and I mean the ones where the collaboration actually felt like a partnership, were grateful when I showed up with a clear picture of what the product experience actually felt like for users. It gave them cover to make calls they already wanted to make but couldn’t justify on their own.

You’re not replacing your PM or telling them how to do their job. You’re just showing up with something they don’t have time to build themselves: a clear picture of what all those accumulated features are doing to the people who use the product every day. When you can walk into a prioritization meeting and say “here’s what our product feels like to a new user right now, and here’s what adding this will do to that experience,” it shifts the whole conversation.

Nobody’s going to throw a launch party for the feature you killed.

Remember Will trying to warn everyone about the Shadow Monster? He could see the threat growing when nobody else could. That’s you. You’re the one who can see the shape of the thing when everyone else is focused on individual decisions. Except instead of visions of the Upside Down, you’ve got usage data and onboarding funnels. Which, honestly, are more convincing in a roadmap meeting.

Once you get the team to see what you’re seeing, they can actually do something about it. And the product that comes out the other side? That’s the one people stick with.