How many users does it take to validate a product?
When you're a first-time founder/maker, and you're the only person using your own product, you probably overlook important things. That's why you need to test the product with as many people as possible.
The problem is that time is limited. You have to decide not only how many people will test it, but also who those people should be.
Yesterday, I launched my Chrome extension for the first time publicly, and my goal is to get feedback from at least 20 testers.
People either describe their experience in writing or I watch them use the product during a call.
My testing group consists of:
Developers and UX/UI designers – people with experience who understand common patterns and expected behavior.
People who have the problem the tool solves – my potential users.
If both groups point out the same issue or suggest the same improvement, it almost always becomes a top priority in the roadmap.
What makes feedback relevant to you?
The number of testers?
The mix of respondents?
Or the way the feedback is collected?
Finding: Developers were able to give me detailed and more accurate feedback than users itself. Developers spotted many things, recommended things while user said: It's okay. :D
Replies
I've found the number matters less than the quality of the signal. Five users who match your exact target and hit a real pain point tell you more than fifty random sign-ups. What's helped me is watching for consistent, unprompted reactions to the same problem rather than polite "this is cool" feedback. Once 3-4 people describe the same frustration in their own words, that's usually a stronger validation signal than any headcount. Curious how others separate genuine pull from friendly encouragement.
minimalist phone: reduce your screentime
@harmeet_singh13 Well, but at least downloads from other people can help you in the Chrome Web Store to climb the ladder and also help with the search in Chrome.
@busmark_w_nika I would say 20 to 100 fair enough
minimalist phone: reduce your screentime
@thomas_ogun Still I am behind :D
Great insights. I completely agree that it's not just about the number of testers, but about having the right mix.
One thing I've learned is that developers are great at explaining how to improve a product, while target users reveal whether the product actually solves a real problem. Watching users interact with the product often uncovers much more than asking, "Do you like it?"
Good luck with the Chrome extension!
minimalist phone: reduce your screentime
@burak_emre_taser Thank you, Burak! :)
Yes! the number of testers is so important to me. I want to get as much feedback as I can since I'm totally bias when it comes to my own product.
minimalist phone: reduce your screentime
@andreasof how many testers did your last product have? :)
@busmark_w_nika my only product so far lol I managed to gather 11 testers.
minimalist phone: reduce your screentime
@andreasof I think it is a good start :)
20 feels like the right ballpark if you're mixing the two groups the way you described. the thing I've noticed is the developer/designer group catches usability friction fast but sometimes disagrees with itself on taste - two designers can flag opposite things as the problem. the real signal for me has always been when someone from the actual target-user group gets stuck on the exact same step a developer flagged as 'a bit awkward but fine.' that's when I stop debating and just fix it.
minimalist phone: reduce your screentime
@omri_ben_shoham1 I just need to find those right people who are open to test it :D
the 'user said its okay' problem is actually your real signal. polite = zero risk on them = zero validation. devs gave better feedback because they were staking professional credibility on the take. try asking the 5 quietest testers if theyd publicly say the extension solved x for them. willingness to be named on the outcome > anonymous 'okay' every time.
minimalist phone: reduce your screentime
@thenameisarian To be honest, in the early stage of the product I prefer a professional feecback from experts so I can customise the tool as much as possible for "ordinary" users :)
For me the number matters less than whether feedback converges. I launched a product here on PH this week and five commenters independently asked for overlapping things within two days. That convergence was the signal, so I shipped the lot in a day and told each person under their own comment. Sample of five, but five strangers agreeing beats fifty polite maybes. Your developer finding matches my experience too: people with the problem say it is fine, people who build products tell you exactly where it hurts. The fix is watching the first group use it instead of asking them, and only trusting the words of the second group.
minimalist phone: reduce your screentime
@oshylabs Yes, but the thing is becoming more difficult when I am not a developer and trying to learn things along the way, so many changes take me so much time, learning process is not easy :D
@busmark_w_nika The learning curve never fully goes away, you just get faster at the same kind of problem. What helped me was shipping small and often instead of saving up big changes. Each small change teaches you one thing and ships in an evening. The ones that eat days usually mean the scope was too big, not that you are slow. You are already doing the hard part, which is acting on what your testers actually tell you.
Nika, I would read your finding differently. It is not that users give worse feedback than developers, it is that you asked users to evaluate the product, and evaluating is a developer skill. A user is the world expert on their own problem and an amateur at judging your UI, so "it's okay" is what you get when you seat them in the wrong chair.
What worked for me: do not ask users what they think of the tool. Ask them to walk you through the last time they hit the problem it solves, before they ever open your product. The "it's okay" disappears, because now they are the expert in the room.
On the number, from running about fifty customer interviews: what matters is saturation, not headcount. You are validated when new interviews stop surprising you, which in a tight segment is often five to eight people. If you are still hearing genuinely new problems at twenty, that says your segment is too broad, not your sample too small.
minimalist phone: reduce your screentime
@clemente_lopez1 To be honest, it is difficult to get early users, but I am happy that I do not have many since the product is very very basic:D
minimalist phone: reduce your screentime
@minhnguyen3719 I am trying to get some first traction so it can nudge it a bit and get domino effect :)
I don't think there's a magic number. I usually look for when feedback starts repeating...that's a stronger signal than hitting 20 users. Also, I'd weigh target-user feedback more heavily than developer feedback. Developers are excellent at finding UX issues, but your customers are the ones who validate whether you're solving a problem they actually care about.
minimalist phone: reduce your screentime
@tarqiya_forgah That's why I wanted diversity and mix of users :)