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.
YourSitee
@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.
YourSitee
@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 :)
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.
YourSitee
@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 :)
I don't think founders should ignore feedback, they should validate it. A request becomes much more interesting when you see the same friction show up across different users.
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.
YourSitee
@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?
@andrasczeizel support conversations by a mile. every 'i cant figure out how to X' means the interface promised X but delivered Y. people describe the friction in their own language which is the actual research goldmine. session recordings second because you spot the pause before the click. that pause is where the mental model broke. surveys and analytics both miss the emotional beat of the friction.
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.
YourSitee
@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.
@andrasczeizel Thank you, that genuinely means a lot. And you landed on the harder half yourself. "Which user are we building for" is the question most roadmaps quietly avoid, because answering it honestly means choosing who you are willing to disappoint. The move that made it workable for me was to write down the user we are explicitly not building for, in as much detail as the one we are. Once that person has a name, contradictory feedback stops feeling like a tie you have to break. You can hear a request fully, respect it, and still know it is not yours to act on. Costs a little discomfort up front, saves you from the slow slide into everything for everyone that you named at the end.
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.
YourSitee
@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.