All insights
ProductStrategy · 5 min read
When to say no to a feature request
Every feature has a cost that outlives the request. Saying no well is one of the highest-leverage skills in building software.
Features are easy to add and brutal to remove. Each one you ship is something to maintain, document, test, and explain forever. That’s why a thoughtful no is often more valuable than an eager yes, and far harder to give.
The request is not the need
People ask for solutions, not problems. 'Add a button here' is a proposed fix. The job is to find the underlying need, which often has a simpler answer than the feature requested, or reveals the request would solve one person’s edge case at everyone’s expense.
Questions before yes
- What problem does this actually solve, and for how many?
- What’s the cost to maintain it for the next three years?
- Does it make the common case worse to serve a rare one?
- Is there a smaller change that solves 80% of it?
Every feature you add is a feature you maintain forever. Say yes like it’s permanent, because it is.