Perfection is finally attained not when there is no longer anything to add, but when there is no longer anything to take away.

Antoine de St. Exupery

I remember launching a new filtering feature a Google within the AdSense product. At the time, we had hundreds of thousands of website publishers using our user-interface to accomplish many tasks. They might download reports of their revenue from running AdSense ads, configure ads to match their website’s style, and indicate their preferences for the content of the ads to be shown on their site.

Unfortunately, the feature we launched interested less than 2% of the current user base. A few weeks after the launch, I wondered to myself whether we should pull the feature. On one hand, a few hundred users benefited from our hard work.

On the other hand, we had introduced new complexity for the other hundreds of thousands of users. In addition, we had broadened the product and engineering surface area for testing and subsequent product design. In some way, we were introducing product debt.

Product debt is different than technical debt, a word that elicits shudders from engineers. Technical debt means having to go back and rewrite significant amounts of code because they weren’t built to scale or were written in an esoteric language. Creating is much more fun than rewriting or refactoring.

Product debt encompasses the collections of features that work well, but are used by tiny fractions of the user population. They introduce all kinds of complexity downstream. You can imagine when an publisher wants to filter advertisements that can destroy many different ways: they can filter by language, geography, keywords, demographics, platform.

Each of those filters has to be considered in combination with the others, creating an explosive combinatorial effect. A new filtering type that benefits only a small fraction of the population must be considered for every subsequent change in other filters or each incremental filter.

Designers have to invent new ways to communicate the complexity. Quality assurance teams must design rubrics to test everything is working properly. And product managers designing new features have more intricacies. Last and most importantly, users have to use the product with increasing complications.

In retail, there’s a concept called carrying cost, which includes all the costs to store inventory. It includes costs like the warehouse, the staff, the shipping, and depreciation of the merchandise. Carrying costs underscore the idea that more product isn’t always better, because there are costs associated with more.

And startups, there is an analogous idea of a product carrying cost. Each product and engineering organization must decide what product carrying costs they are willing to bear explicitly. What fraction of users must use a feature for it to remain? Or what fraction of revenue-generating users or total revenue?

Removing the features that don’t meet that criteria ensure product development organizations can move more quickly, reduce their product debt, and deliver to their users a more perfect experience, in which nothing else can be taken away.