Peerlist, PeerPush & 10+ More
You show your MVP to a friend. They click around for a minute and say, “This is great, I’d totally use this.”
You feel good. Then nothing happens. They never sign up, never come back, and never mention it again.
That’s the problem with a lot of early feedback. It’s friendly, vague, and easy to give. The real challenge is learning how to get honest feedback on an MVP: feedback that reveals what’s confusing, what’s missing, and whether people care enough about your product to change their behavior.
This guide explains where to find people who will test your product, how to ask questions that produce useful answers, which mistakes lead to misleading feedback, and how to turn what you learn into better product decisions. It’s written for solo founders and indie hackers who don’t have a large audience or a big research budget.
What Honest MVP Feedback Actually Looks Like
Honest feedback doesn’t have to be harsh. It should reflect what someone actually experienced, what they need, and what might stop them from using your product.
Consider these two responses to an invoice reminder tool for freelancers.
Polite but not very useful:
“Cool idea! I think a lot of freelancers would like this.”
Specific and actionable:
“I tried to connect my invoicing app but couldn’t find where to do it. I gave up after two minutes. I currently chase late invoices by email, and it only becomes a problem a couple of times a year, so I’m not sure I’d pay for a separate tool.”
The second response reveals a possible onboarding problem, the user’s current alternative, and a potential pricing concern. That’s the kind of information you can act on.
Look for these signs when evaluating feedback:
- It describes behavior. What the person tried, where they got stuck, and what they did instead.
- It’s specific. It identifies a particular screen, task, or point of confusion.
- It includes objections. It explains why someone might not use or pay for your product.
- It comes from the right audience. The person actually experiences the problem you’re trying to solve.
- It leads to evidence. The person is willing to try the product, share relevant information, or take another meaningful step.
A compliment can be encouraging, but it isn’t enough to validate an idea. MVP validation means gathering evidence that people with the problem find your solution useful enough to try, use repeatedly, or pay for.
How to Get Honest Feedback on an MVP Before You Launch
Many founders wait until launch day to find out what people think. By then, they’ve already spent time building, polishing, and announcing their product.
Getting feedback earlier gives you more opportunities to fix problems before they become expensive or affect your first impression. Here’s how to approach it.
1. Test the Problem Before the Product
Before asking anyone to try your MVP, talk to people about the problem you’re solving.
Ask how they handle it today, how often it occurs, and what they’ve already tried. Listen for real experiences rather than hypothetical interest.
For example, instead of asking, “Would you use an invoice reminder tool?”, ask, “Tell me about the last time a client paid an invoice late. What did you do?”
If several people independently describe a similar problem, you’ve found a useful direction to investigate. A handful of conversations won’t prove market demand, but they can help you decide what to test next.
2. Show a Rough Version Early
You don’t need a finished product to start learning.
A clickable prototype, a landing page with a waitlist, or a short screen recording can help you discover whether your value proposition makes sense.
Show someone the product and ask them to explain what they think it does. If they misunderstand the main benefit, you may need to improve your messaging before building more features.
Early testing helps you identify confusing parts while changes are still relatively easy to make.
3. Run Small, Observed Tests
Invite five to ten relevant people to try your MVP. You can observe them in person, on a video call, or through a screen recording if they consent.
Give each person a specific task, such as, “Try to create your first invoice,” and let them attempt it without explaining every step.
Pay attention to where they hesitate, what they expect to happen, and where they get stuck. Don’t rush to help them unless they need assistance to continue.
These sessions can reveal usability problems that a survey or general feedback form might miss.
4. Look for Meaningful Commitment, Not Just Opinions
People often express interest in an idea without taking action. That’s why it’s useful to look beyond what they say.
Someone signing up, scheduling a test session, connecting relevant data, returning to use the product, or paying for early access may provide a stronger signal of interest than a casual compliment.
However, no single action proves that your MVP is validated. A signup might reflect curiosity, while a paid purchase might be influenced by a discount or personal relationship.
Look at what people do over time, alongside what they tell you.
Where to Find People Willing to Test Your MVP
If you’re wondering where to get MVP feedback, start with people who experience the problem you’re solving. You don’t need a large audience to find your first testers.
Your Existing Network
Former colleagues, past clients, professional contacts, and friends-of-friends can be useful starting points.
Focus on people who genuinely match your target audience. A supportive friend who would never use your product may not give you the insight you need.
Ask for an honest test rather than a positive opinion, and make it clear that criticism is welcome.
Niche Communities
Forums, Slack groups, Discord servers, and relevant subreddits can help you connect with people who already discuss your target problem.
For example, a tool built for freelance designers may benefit from feedback in communities where designers talk about client management, invoicing, or project workflows.
Read each community’s rules before posting. Participate genuinely, contribute something useful, and avoid turning every interaction into a promotion.
Founder Networks
Indie hacker communities and builder groups can be useful for feedback on your product positioning, onboarding, and launch page.
They’re particularly helpful when your target users are other founders. However, builders may not represent your actual customers. Feedback from fellow founders shouldn’t replace testing with the people you intend to serve.
People Already Discussing the Problem
Search X, LinkedIn, forums, and online communities for people describing the problem your product addresses.
A short, personal message explaining why you’re reaching out is more useful than sending the same generic pitch to dozens of strangers.
Mention the problem they discussed, explain what you’re testing, and ask whether they’d be open to trying it. Don’t pressure people to participate.
Users of Competing Products or Manual Solutions
People already paying for an alternative or managing the problem with spreadsheets may help you understand existing workflows.
Ask what they like about their current solution, what frustrates them, and what would make them consider switching.
Avoid asking people to share confidential information about their employer, customers, or existing software accounts.
Your Waitlist
If you’ve collected email addresses, ask a small group of subscribers whether they’d be willing to test your product or join a short feedback call.
A personal message is often a better starting point than sending a long survey to everyone at once.
Launch Communities
Product launch platforms can help you introduce your MVP to early adopters and other makers.
These communities can provide reactions to your positioning, presentation, and initial product experience. However, people browsing launch platforms may not represent your ideal customer, so use their feedback alongside interviews and observations from your target audience.
If you’re planning to launch on Peerlist, our Peerlist Launchpad guide covers practical launch tips and how to learn from feedback beyond upvotes.
How to Find Beta Testers for SaaS
If you’re trying to get beta testers for SaaS, be specific about whom you’re looking for and what you need them to test.
For example, this is more effective than a generic request:
“I’m looking for five freelance designers who send invoices every month to test an early version of an invoice reminder tool. It takes about 15 minutes, and I’d appreciate honest feedback on the setup process and whether it solves a real problem for you.”
You can offer free access, a discount, or an opportunity to influence future improvements. Explain the time commitment and the feedback you’re looking for, and make sure participants know the product is still in development.
How to Ask Questions That Produce Honest, Useful Answers
The questions you ask influence the answers you receive. “Do you like it?” invites a quick, polite response. Questions about actual past experiences usually reveal much more — a core principle popularized in The Mom Test.
Before They Use the Product
Ask questions that help you understand the problem and the current alternatives.
- How do you handle this problem today?
- When did it last happen, and what did you do?
- What have you tried that didn’t work?
- How much time or money does it usually cost you?
- What is the most frustrating part of the process?
These questions help you understand whether the problem is real, frequent, and important to the person experiencing it.
While or Immediately After They Try It
Observe what people do, then ask questions about their experience.
- What did you expect this product to do when you opened it?
- What did you try first?
- What confused you or slowed you down?
- Was there a point where you considered giving up?
- What would you change about this experience?
Try not to explain the interface before the person has had a chance to explore it. Their initial reactions may reveal problems you wouldn’t otherwise notice.
About Value and Commitment
Once someone understands the product, explore how it fits into their actual workflow.
- What would you use this for in a typical week?
- What do you currently use instead?
- What would make you consider paying for it?
- What would stop you from using it?
- Is there anything important that it doesn’t currently do?
- Who else experiences this problem?
Don’t assume that one enthusiastic answer means everyone will respond the same way. Look for patterns across relevant users.
Simple Rules for Better Feedback
Ask about the past, not just the future. “Would you use this?” encourages speculation. “When did this last happen?” asks for an actual experience.
Ask one question at a time. Give people time to think instead of rushing through a checklist.
Don’t defend your product. If someone doesn’t understand a feature, resist the urge to explain it immediately. Find out what caused the confusion.
Stay neutral. Avoid leading questions such as, “Don’t you think this would save time?”
Thank people for criticism. Make it clear that you value honest responses more than praise.
Mistakes That Lead to Biased or Misleading Feedback
Collecting feedback isn’t enough. You also need to recognize when it might be misleading.
Asking Only People Who Like You
Friends and family may genuinely want you to succeed. That can make their feedback less objective, particularly if they aren’t part of your target audience.
Include people who don’t have a personal reason to encourage you.
Asking Leading Questions
Questions such as “Don’t you think this would save time?” suggest the answer you’re hoping to hear.
Instead, ask, “How long does this task usually take you?” and let the person explain their experience.
Pitching Instead of Listening
If you spend the entire call describing features and explaining why your product is useful, you’re missing an opportunity to learn.
Let people speak. Ask follow-up questions when something is unclear, and resist the urge to turn criticism into a sales conversation.
Treating Compliments as Validation
“Nice work” is encouraging, but it doesn’t tell you whether someone needs your product.
Look for evidence such as completed tasks, repeat usage, willingness to pay, or a clear explanation of how the product solves an existing problem.
Talking to the Wrong Audience
Feedback from someone who doesn’t experience the problem may be interesting, but it shouldn’t carry the same weight as feedback from your intended users.
Prioritize people who match your target audience.
Counting Signups as Proof
A signup indicates interest, but it doesn’t necessarily mean someone has experienced value.
Track whether users complete important actions, return to the product, and continue using it. Combine those signals with direct conversations to understand what’s happening.
Building Every Requested Feature
One user’s request doesn’t automatically belong on your roadmap.
Ask why they need the feature, what they’re trying to accomplish, and whether other relevant users have the same problem. Sometimes the underlying issue can be solved more simply.
Misinterpreting Silence
If someone tries your product and never replies, don’t automatically assume they disliked it. They may be busy, distracted, or unsure what to say.
Send one polite follow-up if appropriate. You can also examine available product usage data to see whether they completed the intended task.
Using Artificial Engagement as Validation
Vote exchanges, fake reviews, and manufactured engagement can make a launch look successful without demonstrating real customer interest.
Focus on genuine conversations, authentic feedback, and behavior that helps you understand whether the product is useful.
How to Collect and Interpret Feedback After Launch
Once your product is public, feedback can arrive through several channels. Set up a simple system so you can identify recurring problems instead of losing useful information in emails and messages.
Where Post-Launch Feedback Comes From
Useful sources include:
- Comments on your launch page or product listing
- Replies to posts on X or LinkedIn
- Direct messages and emails
- Customer support questions
- Signup, activation, and retention data
- Session recordings or analytics, where appropriate
- Short in-app or email feedback questions
Each source provides a different perspective. Public comments reveal what people are willing to say openly, while private conversations may uncover more detailed concerns.
Capture Feedback in One Place
A spreadsheet or simple document is often enough.
Record the date, source, user type, feedback, and a category such as onboarding, positioning, bugs, missing features, pricing, or praise.
Whenever possible, distinguish between what the user actually said, what you observed, and your interpretation of the problem. This prevents assumptions from becoming product decisions without evidence.
Combine What People Say With What They Do
Suppose several users say your product looks useful, but very few complete onboarding.
Instead of adding new features immediately, investigate where people drop off. You might discover that account setup is confusing, a required integration is missing, or the value proposition isn’t clear.
Usage data tells you where something happens. Conversations can help explain why.
Use both to build a more complete picture.
Follow Up Personally
A short message to a new user can uncover useful context.
For example:
“Hey [Name], thanks for trying [Product]. What were you hoping to accomplish when you signed up? If anything was confusing or didn’t work as expected, I’d love to hear about it.”
Keep the message brief and make it easy for the person to reply. Not everyone will respond, but even a few thoughtful conversations can reveal improvements worth making.
How to Separate Recurring Problems From Isolated Opinions
Once you’ve collected feedback, your next challenge is deciding what deserves attention.
Look for Repeated Patterns
One person requesting a calendar integration is a request. Several relevant users struggling with the same setup step may point to a recurring problem.
Repeated feedback deserves investigation, but don’t rely on a strict numerical threshold alone. A serious security issue or a problem preventing users from completing the core task deserves attention even if only one person reports it.
Consider Who Gave the Feedback
Feedback from your intended audience should generally carry more weight than feedback from people who would never realistically use the product.
A person’s experience, needs, and use case matter as much as the number of times a suggestion appears.
Identify the Underlying Problem
Someone might say, “I need a dashboard.”
Before building one, ask what they’re trying to accomplish. They may simply want a clearer way to track progress, which could be solved with a much simpler feature.
Focus on the problem before committing to a particular solution.
Prioritize by Impact and Effort
Start with problems that prevent users from understanding the product, completing important tasks, or experiencing its main benefit.
Once those are addressed, consider improvements that affect retention, willingness to pay, and convenience.
A simple priority list can help you distinguish urgent problems from useful but nonessential ideas.
Test Changes Before Expanding Them
When you identify a recurring problem, make a focused improvement and observe whether it helps.
You don’t need a perfect experiment for every small change, but you should avoid assuming that a feature worked simply because one person liked it.
Keep track of what you changed, why you changed it, and what happened afterwards.
Templates You Can Use to Request MVP Feedback
You don’t need elaborate outreach messages. A short, personal request with a clear purpose is often enough.
Request for Pre-Launch Testers
Hi [Name], I noticed you [mentioned/work on] [problem]. I’m building a small tool that [one-line description] and looking for a few [type of person] to try an early version. It takes about 15 minutes, and I’d really value your honest take, including what’s confusing or missing. Would you be open to trying it?
Request for a Short Feedback Call
Hi [Name], thanks for trying [Product]. Would you be open to a 15-minute call this week? I’d like to hear what you expected, where you got stuck, and what you’d change. No preparation needed.
Post-Signup Email
Hi [Name], I’m [Your Name], the founder of [Product]. Thanks for signing up! What were you hoping to accomplish when you joined? If you got stuck anywhere, I’d love to hear about it and see how we can improve the experience.
Post-Launch Community Post
I just launched [Product], a [one-line description] for [specific audience]. It’s still early, and I’m looking for honest feedback on [specific aspect of the product]. What feels unclear, and what would make it more useful for you?
Follow-Up for People Who Haven’t Used the Product
Hi [Name], just checking in after your signup for [Product]. No worries if you haven’t had time to try it yet. If something put you off or stopped you from getting started, I’d appreciate hearing about it. It would help me improve the experience.
Personalize each template instead of sending identical messages to everyone. Respect people’s time and preferences, and don’t repeatedly contact someone who hasn’t responded.
A Simple MVP Feedback Loop to Repeat
You don’t need a complicated research process to improve your product. A consistent feedback loop is a good starting point:
- Talk to or observe a small group of relevant users.
- Record what they said and what they actually did.
- Identify the most important recurring problem.
- Make a focused improvement.
- Test the change with users and review the results.
Repeat this process before launch and continue afterwards. Over time, you’ll build a clearer understanding of what people need, where they struggle, and which improvements make the biggest difference.
The goal isn’t to collect the most feedback. It’s to gather the right evidence and use it to make better decisions.
From Honest Feedback to a Wider Launch
Once your MVP is ready for a wider audience, you may want to reach beyond your existing network. That’s a distribution challenge, separate from product validation. A launch can introduce your product to more people, but it won’t replace customer interviews or guarantee that those people will become users.
If you’re ready for that next step, Makerio is one optional resource for promoting launches on platforms such as Peerlist, PeerPush, Launch Llama, OpenHunts, and other launch communities through manual outreach. The $10 Launch Support package includes 80+ founder shares, an X shoutout with relevant tags, and priority support within one hour.
Launch promotion can’t guarantee feedback, customers, or product-market fit. What matters most is how you learn from the people who discover your product. Keep asking thoughtful questions, observing real behavior, and improving the things that matter to your users.
Frequently Asked Questions
How many people should test an MVP?
Start with 5–10 people who match your target audience to identify initial usability issues and common problems.
When should I collect feedback on my MVP?
Start before launch with interviews and prototype testing, then continue collecting feedback from real users after launch.
How can I promote my MVP with no audience?
Join relevant communities, contact potential users, and consider Makerio for manual launch promotion across platforms like Peerlist and PeerPush.
