Every feature keeps sending a bill

The bill for a feature does not arrive on launch day. On launch day the feature is new, its author remembers how it works, and the only cost anyone sees is the time it took to build. The bill comes later and keeps coming: every future change to the product has to be tested against it, support staff have to learn it, help pages have to describe it, and the code around it gets a little harder to change each time someone works nearby.

David Karp described Tumblr’s answer to this in a 2011 interview with Inc. magazine. The team watched how much each new feature was used after launch and removed the ones that did not earn their place, and for each new feature it added it tried to take an old one out. He also said that many large sites never prune at all and grow heavier each year as a result.

The reasoning holds up best for a consumer product with a small team. At that scale the scarce resource is attention, not engineering hours. A feature used by two percent of people still demands a share of every design discussion and every round of bug fixing. Removing it frees that attention for the handful of things most people came for. Tumblr’s appeal in its early years was a posting screen that asked almost nothing of the user, and keeping it that way required saying no to a long list of reasonable requests.

It helps to count features the way an accountant counts leases rather than the way a marketer counts announcements. Each one is a recurring commitment with a monthly cost, and the question before adding one is whether it will pay that cost for years, not whether it will look good in a release note.

The rule works less well in software that businesses buy. Procurement teams compare products on feature lists, and a missing row can lose the deal even if nobody at the buying company would use that feature. Office suites are the classic case. Most users touch a small part of a word processor, but each group of users touches a different part, so the full set is what sells. Cutting features there shrinks the market.

Removal also has a cost of its own. Somebody always relied on the feature that was used by only two percent, and those people tend to be the loudest and most committed users. A free product can absorb the complaints. A paid product that promised the feature in a contract often cannot.

What survives from Karp’s rule in every setting is the accounting habit. A product team that writes down the running cost of each feature, and reviews it once a year, will make better decisions than one that only counts what it has shipped. Whether the review ends with deletions depends on who is paying and what they were promised.