The best feature is the one you didn't build
Every feature has a cost that never shows up on the roadmap. Field notes on why saying no is the most underrated product skill, and how I decide what stays out.
Every product starts simple. Then the requests arrive.
“Can it also do this?” “Would be great if it supported that.” “Competitor X has this, why don’t you?”
Each request sounds reasonable on its own. Together, they are how a clean product slowly turns into a confusing one.
Features are not free
The cost of a feature is not the time it takes to build. That is just the down payment.
The real costs keep arriving after launch:
- More to explain. Every feature makes the product harder to understand for new users.
- More to maintain. Every feature can break, and has to keep working as everything else changes.
- More to design around. Every new screen and setting makes the next decision harder.
- More to market. The message gets diluted. “It does everything” usually means “it does nothing memorably.”
None of that shows up on the roadmap. All of it shows up in the product.
Clarity is a feature
The products I love most are not the ones that do the most. They are the ones where I instantly know what they are for.
That clarity does not happen by accident. It happens because someone, many times, said no to things that would have made the product muddier.
This is a big part of how I think about building. Clarity is a feature. Often the most important one.
How I decide what stays out
I do not have a perfect system, but a few questions help:
- Does this make the core job better? If it supports the main thing the product does, it gets a serious look. If it is a side quest, it probably waits.
- How many people actually need this? One loud request is not the same as a real pattern.
- What is the problem behind the request? People ask for features. What they need is a problem solved. Sometimes the solution is simpler than what they asked for.
- Would I still want this in a year? Some ideas feel urgent this week and irrelevant next quarter.
- What would we have to stop doing? Every yes is a no to something else. Name it.
Saying no without losing people
Saying no feels risky, especially early, when every user feels precious.
What I have found is that people mostly want to feel heard, not to win every request. A clear, honest answer like “not right now, here is why” usually lands better than a vague “maybe someday.”
And sometimes saying no is the more respectful choice. A focused product serves its users better than a bloated one that tries to please everybody.
This applies outside product too
The same idea works for content, for marketing, for calendars.
A blog that covers everything is hard to follow. A marketing plan with twelve channels is hard to execute. A week with no white space is hard to think in.
Most improvement comes from subtraction. Remove the thing that does not need to be there, and the important thing becomes easier to see.
Post fourteen of writing in public. If you are wrestling with a feature request you are not sure about, email me. Sometimes it helps to explain it to someone outside the room.