In 2012, the project management tool Basecamp (then called 37signals) made a decision that the industry considered reckless: they removed features from their product. Not added. Removed. The team eliminated capabilities that customers used, that competitors offered, and that the sales team requested daily.
Revenue grew. Customer satisfaction improved. The product became easier to sell, easier to support, and easier to develop. The lesson was counterintuitive but consistent with a principle that most businesses learn too late: every feature you add carries a tax that compounds over time.
The Hidden Cost of Features
When a product team estimates the cost of a new feature, they typically calculate development time and deployment resources. This is the visible cost — and it represents roughly 20% of the true cost over the feature's lifetime.
The remaining 80% is the strategy tax: the ongoing costs of maintaining, supporting, testing, documenting, and working around the feature for as long as it exists in the product.
Maintenance cost: every feature must be updated when the platform changes, tested against new releases, and patched when bugs appear. A product with 50 features does not require 50 times the maintenance of a product with 1 feature — it requires something closer to 50 squared, because features interact with each other in ways that multiply complexity exponentially.
Support cost: every feature generates support tickets. Some features generate more tickets than they solve problems, because the feature's existence creates confusion about when and how to use it. The support team must understand every feature, document every feature, and troubleshoot every feature — regardless of how many customers actually use it.
Opportunity cost: every engineer maintaining an existing feature is an engineer not building the next important thing. The feature backlog grows. The roadmap slows. The product falls behind competitors not because the team is less talented, but because the team is spending an increasing percentage of its time maintaining what exists rather than building what's needed.
Why Businesses Keep Adding
The incentive structure in most organizations rewards addition and punishes subtraction. Product managers are promoted for launching features, not for removing them. Sales teams request features because a prospect mentioned needing one. Leadership measures progress by output — and output is measured in features shipped, not features declined.
The result is a one-way ratchet. Features go in. Features never come out. Over time, the product becomes a museum of every customer request, competitive response, and internal idea that was ever approved. The product does not become better. It becomes bigger — which is a different thing entirely.
The most insidious version of this dynamic is the "just one more feature" logic. Each individual feature, evaluated in isolation, appears to offer positive value. The development cost is manageable. The customer request is real. The competitive gap is visible. Saying yes feels rational.
But saying yes 200 times over five years produces a product that no one can fully understand, no team can fully support, and no customer can fully navigate. The individual decisions were rational. The aggregate outcome is a mess.
The Discipline of No
The most successful product companies are distinguished not by what they build but by what they refuse to build.
Apple's product line is famously narrow. The company's most senior executives have publicly described their primary contribution as saying no to thousands of ideas that were individually good but collectively dilutive. The discipline is organizational: every feature request must clear a threshold not just of value but of strategic coherence. Does this feature make the product simpler? Does it serve the core use case? Does it justify the permanent tax it imposes?
Warren Buffett's investment philosophy applies identically to product strategy: "The difference between successful people and really successful people is that really successful people say no to almost everything." The really successful products say no to almost every feature.
Applying the Principle
Start with an audit. List every feature in your product. For each one, answer three questions: How many customers use this weekly? What would happen if we removed it? What is the annual cost — development, support, testing, documentation — of keeping it?
The answers will be uncomfortable. Features that took months to build are used by 3% of customers. Features that generate the most support tickets deliver the least revenue. Features that were added to win a specific deal three years ago are still being maintained for a client who has since churned.
The audit produces a hit list — the features whose costs exceed their value. Removing them is not easy. Customers will complain. Sales will object. The team will resist. But the product that emerges — simpler, faster, more focused — will be stronger than the product that preceded it.
Every feature is a commitment. Every commitment has a cost. And every cost compounds over time. The businesses that understand this grow by focus, not by accumulation — and focus, unlike features, never becomes a liability.
