The instinct to add is baked into how software teams operate. Roadmaps are lists of things to build. Sprints are measured by features shipped. Careers are advanced by launches, not removals. The entire incentive structure of product development points in one direction: more.
This is why deletion is so rare. And why, when a team actually does it well, it’s worth studying.
The Setup
In 2014, Basecamp (then still operating as 37signals) was running its project management software with a feature called “To-do due dates” baked directly into the main list view. It wasn’t a niche option. Users could assign due dates to individual to-do items, and those dates surfaced prominently across the interface. By any surface metric, it was well-used.
But the Basecamp team had a growing suspicion: well-used was not the same as useful. They noticed that due dates on granular tasks were creating a kind of anxiety theater. Users were assigning arbitrary dates to low-stakes items to make lists feel organized. Managers were using date fields to simulate accountability rather than create it. The feature was generating activity without generating progress.
More practically, the due-date machinery was complicating everything around it. Notifications, calendar syncing, the visual hierarchy of lists, the logic for what showed up as “overdue” — all of it had to account for per-item dates. The feature wasn’t just present in the interface; it was load-bearing in the codebase in ways that made every adjacent change harder.
The team’s conclusion was direct: the feature was making the product worse, and removing it would make the product better. So they removed it.
What Happened
The backlash was immediate and predictable. Users who had organized their workflows around per-item due dates felt the ground shift beneath them. The Basecamp blog, where the company has always been unusually transparent about its decisions, published a post explaining the reasoning in detail. Jason Fried and the team didn’t apologize for the removal. They explained it.
The core argument was that due dates belong on milestones and deadlines, not on every sub-task in a project. That assigning a due date to “draft introduction” or “send contractor invoice” creates false urgency and diffuses attention rather than focusing it. That a product trying to reduce workplace stress shouldn’t have a mechanism that turns every to-do list into a countdown clock.
Some users accepted this and adapted. Others left. Basecamp has always accepted that tradeoff more willingly than most companies — their whole business philosophy is built on the idea that trying to be everything to everyone produces software that is nothing to anyone. (That philosophy eventually led them to fire their most demanding customers in a more dramatic form years later.)
But here’s what’s important: the team knew they would lose users. They did it anyway. The removal wasn’t a confidence that every user would agree. It was a confidence that the product would be stronger for it.
Why It Matters
Removing a feature is categorically harder than adding one, and not for the obvious reason. The obvious reason is user anger. The deeper reason is institutional.
When a team builds a feature, they accumulate stake in it. The engineer who wrote it, the PM who shipped it, the designer who spec’d it — they all have professional identity attached to it. Removing the feature is a kind of retroactive judgment on their work. Even when everyone agrees intellectually that the removal is right, the emotional friction is real.
Then there’s the usage data problem. Almost every feature that’s been around long enough will show some usage. Someone, somewhere, is using it. Analytics dashboards make this extremely visible and make deletion feel like an attack on real people. But usage data can’t tell you whether a feature is used because it’s valuable or because it’s there. It can’t tell you what users would build their workflow around if it didn’t exist. It measures the world as it is, not the better world that a cleaner product might create.
The codebase problem is underappreciated. Features don’t exist in isolation. They integrate with authentication, they touch notification systems, they have their own database tables with foreign keys pointing at them. A feature that was added in 2011 may have become, by 2018, a structural element that dozens of other features lean against. Removing it isn’t a deletion, it’s an excavation. This is the technical debt nobody talks about: not the bad code, but the weight of features that were fine when added and have since become calcified into the architecture.
What We Can Learn
Basecamp’s due-date removal is a clean case study because the team was explicit about their reasoning and because the stakes were real but survivable. Most companies never reach this decision point cleanly. They accumulate features until the product becomes a museum of past priorities, where every item is preserved because removing anything risks somebody’s objection.
The teams that remove features well tend to share a few habits.
They treat the product as a whole, not a collection of features. A feature that would be fine in isolation might be harmful in combination with the ten other things competing for the user’s attention. The question isn’t “is this feature useful” but “does this feature make the product better or worse at its core job.”
They distinguish between loudness and size. Users who object to a removal are always more vocal than users who benefit from the cleaner product. The absence of complaints about removal isn’t indifference — it’s often relief. But relief doesn’t file support tickets.
They accept short-term churn as a cost of long-term coherence. Churn is one of the few metrics that tells an honest story about product-market fit, and teams that are afraid of any churn will never make a courageous removal decision. Some users will leave. If the product is better for it, that’s a trade worth making.
Most importantly, the teams that do this well have a clear point of view about what their product is for. Basecamp has always been unusually articulate about this — they believe most workplace software creates anxiety and complexity, and they’re trying to build something that does the opposite. That clarity is what made the due-date removal possible. Without a strongly held opinion about the product’s purpose, there’s no framework for deciding what doesn’t belong.
Adding features is easy to justify. The feature might be useful. Some users want it. It’s not that hard to build. The arguments for addition are always available.
Deletion requires something harder: the conviction that what you’re removing was a mistake in context, and the willingness to make that case to users who’ve organized their work around it. It requires, in other words, a real point of view about what software should do. That’s rarer than it sounds, and it’s why the teams that can do it tend to build products that last.
