The Most Dangerous Feature Request Is the One That Sounds Reasonable
Some feature requests are easy to reject.
“Can you rebuild the entire product for my very specific workflow?”
Probably not.
But the dangerous ones are usually much more reasonable.
“Could you add one more filter?”
“Can we have another user role?”
“It would be useful if this sent a notification.”
Nothing sounds wrong with any of those.
And that’s exactly the problem.
A feature request is not the same thing as a product decision
When a user asks for something, they’re usually describing a solution.
But the useful part is often hidden underneath it.
Someone asks for:
“Export to Excel.”
Maybe what they actually need is:
“I have to send this report to my manager every Friday.”
Someone asks for:
“More notification settings.”
Maybe the real problem is:
“I keep missing the one event that actually matters.”
Someone asks for:
“Another dashboard.”
Maybe they’re really saying:
“I can’t quickly understand whether things are going well.”
If you immediately build the requested feature, you might solve the suggestion without solving the problem.
One request can feel much bigger than it is
Early-stage products make this especially difficult.
You might only have a handful of users.
One person asks for something very confidently.
They explain exactly how it should work.
Suddenly it feels important.
But confidence isn’t frequency.
And frequency isn’t always importance either.
Three users asking for a feature can still be less meaningful than ten users silently struggling with the same workflow.
That’s why I’m starting to care more about patterns than individual requests.
I like asking one extra question
Before turning feedback into a roadmap item, I think there’s a useful question:
“What were you trying to do when you realized you needed this?”
That changes the conversation.
Instead of:
“I need bulk editing.”
you might hear:
“Every Monday I update the same field for 80 customers.”
Now you understand the job.
And maybe bulk editing is the right solution.
Or maybe automation is.
Or maybe the field shouldn’t need to be updated manually at all.
The feature request gives you a direction.
The context tells you whether it’s the right direction.
AI makes this problem more interesting
This is something I’ve been thinking about while working around built.new.
AI has made adding features dramatically cheaper.
That’s useful.
But it also removes some of the natural friction that used to force prioritization.
If a request takes three weeks to build, you ask a lot of questions first.
If AI can generate it in twenty minutes, the temptation becomes:
“Why not just add it?”
But implementation cost isn’t the only cost.
Every new feature creates:
- another state
- another decision
- another thing to test
- another thing users need to understand
- another thing that can break later
The feature might be cheap to generate.
The product complexity isn’t.
Maybe AI should help interpret feedback too
Most AI product tools focus heavily on execution.
Generate this.
Change that.
Add this screen.
Connect this API.
But there’s another interesting problem:
Should this request become a feature at all?
Imagine an AI system seeing ten pieces of feedback and helping identify:
- which requests describe the same underlying problem
- which ones are one-off preferences
- which workflow is creating repeated friction
- which request conflicts with the product’s core use case
- which problem could be solved without adding another feature
That feels much more valuable than blindly converting every request into code.
Feedback should create questions before it creates features
I’m trying to think about feedback more like this:
request → context → pattern → decision → build
instead of:
request → build
It’s slower by one step.
But that one step might save a lot of unnecessary product later.
Because users are often very good at telling you where something hurts.
They’re not always responsible for designing the solution.
That part is still the product decision.
So I’m curious:
What’s a feature your users asked for that you eventually realized they didn’t actually need?
Top comments (1)
"Confidence isn't frequency" is a line worth pinning above the backlog.
One cheap habit that fits your request → context → pattern flow: log every request in the user's own words, with the answer to your "what were you trying to do" question next to it, and don't give it a feature name until three entries share the same context. "Export to Excel" three times can turn out to be three different jobs. "I send this to my manager every Friday" three times is one.
On AI making features cheap, there's also a cost that shows up late: every feature the AI adds is more code and more states it has to take into account on the next change, so each cheap feature makes the following ones a little slower and riskier. A gate that helps is a delete test: if we removed this in a month, who would notice? If you can't name them, it waits.
Do you plan for built.new to push back on requests like that itself, or leave that judgement with the user?