# When to say no to a feature

> Every feature you add is one you maintain forever. The health of a product depends as much on what you decline to build as on what you ship.

*Source: https://www.lazlosoftwaresolution.com/resources/when-to-say-no-to-a-feature*

Adding a feature feels like progress. Every feature also has a cost that arrives later and never leaves: it has to be maintained, documented, kept working as everything around it changes, and reasoned about every time someone touches a nearby part of the system. A product's long-term health depends at least as much on what its team declined to build as on what it shipped.

Saying no well is a skill, and it is not the same as being unhelpful.

## Every feature is a permanent liability

The build cost is the small, visible part. The real cost is the years afterward — the maintenance, the interactions with every future change, the weight it adds to the product for everyone who now has to step around it. A feature used by a handful of people still slows down the work for everyone.

## Ask what problem it actually solves

Requests usually arrive as solutions: "add a button that does X." Underneath is a problem, and often the problem has a better answer than the requested feature. Understanding the problem first sometimes reveals that an existing capability already covers it, or that a smaller change solves it without the ongoing weight.

 - Who specifically needs this, and how often?

 - What do they do today without it — and is that actually painful?

 - Does it fit what the product is for, or pull it in a new direction you have not chosen?

## Consistency is worth protecting

A product where every feature was added because someone asked becomes a pile of features rather than a coherent tool. Each addition that does not fit makes the whole thing harder to understand and to use. Protecting that coherence is a legitimate reason to decline something that, in isolation, would be fine.

> The question is never just "is this feature useful." It is "is it useful enough to carry forever."

## Say no without saying "go away"

Declining a feature and dismissing the person are different acts. Explain the reasoning, acknowledge the real problem underneath, and where you can, point to how the product solves it another way. A thoughtful no keeps the relationship and the product intact. A reflexive yes eventually costs you both.
