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
Dial
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.
ClinicFrame
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 :)
Love this question — it's something I wrestled with while building my party game (Salad Bowl Game). Here's what I learned:
For me, validation wasn't about a specific number — it was about patterns:
🔹 3+ people independently suggest the same feature without being prompted = real need
🔹 Someone actually uses it at a party (not just "cool idea, I'll try later") = product-market fit signal
🔹 They come back a second time on their own = retention validation
I think the magic number is less about quantity and more about diversity of users. 10 strangers who found you organically tell you way more than 100 friends you asked to test it.
Also: if you're the only one using your own product daily, that's actually not nothing! It means YOU have the problem you're solving. The question is whether others share that same problem.
What's been your experience with early user feedback vs. actual usage data?
minimalist phone: reduce your screentime
@youliqn Thank you for encouriging words, I think that the problem is bigger than other people think :) I can see many people complaining on social media :)
Hey Nika, Congratulations on the launch. As a former quality assurance analyst, I have always found that production bugs were always out of the box. So yes, I would prioritize getting the product tested by actual users. Also, instead of looking at the number of testers or respondents, think about the overall scope, prepare a requirement document, and test against it. Most important of all, often overlooked are severity and priority; a bug could be quite severe, but actual users testing reveals it's not a big impact. The same goes for severity. Hoping this direction helps me in my launch one day too!
minimalist phone: reduce your screentime
@sonal_waghchoure Thank you for your 2 cents :) My product is currently used by 78 people, so maybe reach my desired 100 active users until the end of August. :)
I'd rather have 20 active users who keep coming back and would be disappointed if the product disappeared than 1,000 signups who never use it again.
minimalist phone: reduce your screentime
@joiynai My goal is to have steay growth of active users, that's the reason why I grow so slowly :)
Awesome Nika! solving an issue that you have experienced in the past is a massive grower. Im doing the same at the moment! Glad there are heaps of people in the same boat as me.
minimalist phone: reduce your screentime
@riffready What is the tool you are working on? :)