When should founders stop listening to user feedback?
"Talk to users" is probably one of the most repeated pieces of startup advice.
And for good reason.
Some of our best product decisions started with a user pointing out something we had completely missed. A confusing flow, a feature that seemed obvious to us but made no sense to them, or a small problem that turned out to affect many more people than we expected.
But the more feedback you collect, the messier it gets.
One user wants more customization. Another says the product already has too many options.
One person wants a feature to be completely automatic. Someone else wants full manual control.
Some users ask for advanced functionality they would probably never actually use. Others request something tiny that quietly solves a real daily problem.
And sometimes the loudest request comes from one very engaged person, while ten quieter users behave in a completely different way.
I've started realizing that listening to users and obeying users are two very different things.
Users are usually very good at showing you where the pain is. They are not always the right people to design the solution.
At the same time, "founder vision" can easily become a convenient excuse for ignoring feedback you simply do not want to hear :)
So I keep coming back to a few questions:
How many people need to request something before it becomes meaningful?
Should feedback from an active user matter more than feedback from someone who tried the product once?
Do you trust what users say, or what their behavior shows?
How do you separate a real pattern from one persuasive person's opinion?
And when two groups want opposite things, how do you decide which direction is right for the product?
For me, the most useful feedback usually describes a problem very clearly without prescribing the exact feature. When several people struggle at the same point in different ways, that feels like a stronger signal than several people asking for the same trendy solution.
But I still find this difficult.
Have you ever ignored user feedback and later realized the users were right? Would love to know!
Or built something people repeatedly requested, only to discover that almost nobody used it?
How do you decide when to listen, when to investigate further, and when to trust your own product judgment?
Replies
One thing I'd add before "problem vs solution": is this person actually my user? The feedback that trips you up usually isn't a feature request - it's a smart-sounding opinion from someone who won't ever be your customer, and it slowly pulls you toward a product for no one. If they're not in my audience, I'll read it, but it doesn't get a vote.
@alieksia I've definitely noticed that smart, detailed feedback can feel more valuable than it actually is, especially when it comes from someone who would never use or pay for the product. at the same time, I still think outsider feedback can expose unclear positioning or confusing UX, even if it should not shape the roadmap.
How do you decide when someone is close enough to your audience to get a vote?
@andrasczeizel Agreed, and I think you've drawn the line I didn't: outsiders are good at spotting confusion, not at setting direction.
On who's close enough: I don't go just by demographics, because someone can look like a perfect fit on paper and just be curious. What earns a vote is actually having the problem - they describe the pain without prompting, or they've already tried to solve it some other way. If they have, I'll take their input on direction even if they're outside my target group.
@alieksia That's an even better filter: not "does this person look like our target user?", but "do they genuinely experience the problem?"
I really like the idea that outsiders can still earn a vote if they've already felt the pain or built a workaround around it. That feels much more reliable than demographics alone, because curiosity can look like demand from the outside. "Outsiders are good at spotting confusion, not setting direction" is definitely one of the strongest takeaways from this thread :)
@andrasczeizel Likewise - really helpful for me too, thanks :)
For me, I stop listening when feedback starts contradicting my product vision. I value patterns, not isolated opinions.
@uthappa_robb I agree that patterns should carry much more weight than isolated opinions. Product vision has to act as a filter, otherwise the roadmap slowly becomes a collection of unrelated requests.
The difficult part for me is knowing when feedback genuinely conflicts with the vision, and when it is evidence that the vision is not landing the way I expected. How do you personally tell the difference?
i think founders should stop reacting to every request and start looking for recurring pain points. For me, consistent patterns matter much more than the loudest individual voice.
@saman_baloch Exactly! One detailed request can feel urgent just because the person explains it well, but recurring pain across several users is usually a much stronger signal. I think the challenge is noticing the pattern when everyone describes the same underlying problem in completely different words. That is where feedback becomes much more useful than simply counting feature requests :)
the answer for me: stop taking user feedback as a request. keep taking it as evidence.
users tell you what they'd want. what they'd actually USE is a different question. the strongest signal is not what they ask for in a feedback form. it's what they do at 2am when they hit a wall and can't ask anyone.
"we asked and they said they wanted X" is how you build feature bloat. "we watched what they did and shipped the one thing that eliminated the workaround" is how you build a product.
@thenameisarian That's a really good way to put it: treat feedback as evidence, not as a request. Thanks for your thoughts!
The 2am point is especially true. Users often describe the solution they imagine, but the workaround usually reveals the actual problem. I've definitely seen cases where one loud feature request felt important, while repeated small behaviors pointed somewhere completely different.
The difficult part is discovering those invisible workarounds when you are not sitting next to the user. What has worked best for you there: session recordings, support conversations, analytics, or simply talking to users regularly?
The question that unlocked this for me was not how many users asked, it was how reversible the decision is. A wrong no on a feature is cheap, someone asks again next month and you still have the option. A wrong yes is expensive, because every feature you ship becomes something you maintain, explain, and cannot quietly remove without annoying the few who did adopt it. So I set the bar for adding much higher than the bar for fixing. Friction that blocks the core job gets fixed on one clear report. New scope waits until the same pull shows up on its own, more than once, from people who actually match who you are for.
On your hardest question, when two groups want opposite things, I have stopped reading that as a direction to pick. Opposite requests usually mean two different jobs are hiding under one product, and the real decision is not customization versus simplicity, it is which of those two people you are actually building for. Once that is honest, a lot of the contradictory feedback sorts itself, because half of it turns out to come from someone you were never the right tool for. The feedback was not conflicting. You just had two products in one inbox.
@asadmalik901 This might be the most useful framework in the thread so far. I had not thought about feedback through reversibility, but "a wrong no is cheap, a wrong yes is expensive" explains really well why adding scope should require much stronger evidence than fixing friction in the core experience.
And "you just had two products in one inbox" is such a good way to frame contradictory feedback. It turns the question from "which request should we follow?" into "which user are we actually building for?" That is probably the harder question, but also the one that prevents a product from slowly becoming everything for everyone.
On your question about finding the invisible workarounds, analytics has never done it for me. It shows you where people stop, never why, and you end up inventing a story to explain the drop.
What changed it was changing the question. Ask someone what they'd like you to add and you get a feature request, which is them doing your job badly. Ask them to walk you through the last time they actually did the thing, start to finish, and they narrate the workaround without noticing. The spreadsheet they keep on the side, the colleague they message to double check something, the bit they do twice because they don't trust it the first time.
The part that took me longest to see is that the workaround usually lives outside your product. It's in a notes app or a group chat or on paper. Instrumentation can't ever find that, because you're only measuring what happens inside your own walls. It only turns up if someone talks you through their whole week rather than just the ten minutes they spend in your thing.
@venkat_a2 This is such a useful distinction. analytics can show the drop, but it cannot show the spreadsheet, side chat, or manual double-check happening outside the product. and once the data ends, it is very easy to invent a confident story about why users behaved that way.
I also really like the question shift from "what should we add?" to "walk me through the last time you did this." That feels much more likely to surface the real workflow without asking the user to design the solution for you. I am definitely stealing that for future user conversations :)
@andrasczeizel Steal away. One thing that makes it work better: listen for the moment they say "and then I just..." That phrase nearly always has a workaround hiding behind it, and people skip straight past it because to them it isn't interesting, it's just what they do every day.
The other one worth adding is asking what they were doing right before they opened the product, and what they did right after they closed it. That's usually where the outside work lives, and it never comes up if you only ask about the product itself.