·

by

The case for shipping fewer features

Roadmaps almost always grow. Features are added because a large customer asked, because a competitor shipped one, because a team spent a quarter on it and cancelling felt wasteful. Very little is ever removed, and the accumulated result is a product that does a great deal and is pleasant at none of it.

Every feature bills you monthly

The cost of a feature is not the sprint it took to build. It is the documentation somebody maintains, the support conversations it generates, the tests it adds to every release, the migration it complicates in two years, and the space it occupies in an interface that other things now have to work around.

That bill arrives every month for the life of the product, and unlike the build cost, nobody ever puts it in a plan.

The usage data is usually damning

Teams that instrument their products properly tend to find the same shape: a small core used constantly, a long tail used by a few percent, and a surprising number of features that essentially nobody touches. The uncomfortable follow-up is that the long tail was not free — it was paid for with the attention that could have gone into the core.

How to actually say no

“No” is hard to say in the abstract and easy to say against a written standard. A few that work in practice:

  • Write down what the product is not. A short list of refusals settles more arguments than a roadmap does.
  • Require a removal for an addition. Not always literally, but often enough that the trade-off stays visible.
  • Ask who stops using it. If the honest answer is nobody, the feature is decoration.
  • Sunset on a schedule. Review the tail annually and retire what nobody defends.

Fewer is not smaller

This is not an argument for shipping less work. The teams that do this well are often shipping more — they are simply spending it on depth rather than breadth, on making the handful of things people do every day faster, clearer and harder to get wrong. That work rarely makes a release note, and it is almost always what customers mean when they say a product feels good.

A roadmap is a list of promises. A product is the much shorter list you kept.