How to Validate an MVP Before Building More

Validation means testing your assumptions against the behaviour and reactions of real users, instead of relying on signals that feel encouraging but carry little information.

Signals that are easy to mistake for evidence:

• Compliments on the idea or the design
• Support from friends, family, and colleagues
• Upvotes, likes, and launch-day traffic
• Your own conviction about the problem
• Vanity metrics such as signups that never return

It is also worth being clear about what validation is not. It does not prove a startup will succeed, and it does not remove risk. It reduces the chance that you spend the next quarter building on an assumption nobody ever checked.

Most early products carry a stack of untested assumptions. The useful ones are usually specific:

• Does the problem actually matter to the people you built this for?
• Do users understand what the product does within the first minute?
• Can they figure out how to use it without you explaining it?
• Does it deliver value they can describe in their own words?
• Would the intended user realistically use it again?
• Where does friction, hesitation, or confusion appear?
• What would need to change before you build more on top of it?

You do not need to answer all of these at once. Pick the assumption whose failure would cost you the most, and start there.

Before you ask anyone for feedback, write down what you are trying to find out. A vague goal produces vague answers.

Compare "I want feedback on my app" with "I want to know whether a first-time user can reach the core action without help, and whether they see any reason to come back." The second one tells you what to ask, what to watch, and how to recognise an answer.

Keep the questions neutral. If you ask whether a feature is useful, you will mostly hear yes. Ask what the person was trying to do, what happened, and what they expected instead.

Feedback quality depends heavily on who is giving it. Someone who has the problem you are solving reacts differently from someone who simply finds the idea interesting. Both can be useful, but only the first tells you much about demand.

Early-stage founders usually recruit reviewers through a mix of:

• Communities where your intended users already spend time
• Your existing network and past colleagues
• Direct outreach to people who described the problem publicly
• Newsletters, groups, and audiences adjacent to your space
• A public feedback link you can share anywhere

Be honest with yourself about who responds. A reviewer who is enthusiastic but outside your target group is worth listening to, and worth labelling as such.

"What do you think?" is the most common question and one of the least useful. It puts the burden of structure on the reviewer, and every person answers a slightly different question. You end up with a pile of impressions that cannot be compared.

Asking everyone the same set of questions makes patterns visible. Categories that tend to work well:

• Overall product experience
• Usefulness: did it help with something real?
• Clarity: was the purpose obvious?
• Friction: where did things slow down or break?
• Willingness to use it again
• Open comments, in the reviewer's own words

Keep a place for free-text answers. Structure makes feedback comparable; open comments are where the surprises live.

Not every criticism is a reason to change the product, and not every compliment is evidence that you should keep going. Interpretation is part of the work.

What tends to be worth acting on:

• Problems several reviewers hit independently
• The same point of confusion appearing again and again
• A value that different people describe in similar terms
• Patterns concentrated among your target users specifically
• Contradictions between groups, which usually mean you are serving two audiences

A single enthusiastic reviewer and a single harsh one deserve the same treatment: note it, look for whether anyone else said something similar, and let the pattern decide. Roadmaps built on the loudest recent comment tend to drift.

Validation is only finished when it produces a decision. Reasonable outcomes:

• Continue building the current direction with more confidence
• Fix or rework a specific part that repeatedly caused friction
• Change how you describe the product, if the value was misunderstood
• Test a different assumption that turned out to be the riskier one
• Pause, if the evidence is genuinely unclear
• Pivot, if the problem does not seem to matter to the people you targeted

Collecting feedback indefinitely feels productive and rarely is. The goal is a better next decision, not a larger archive of opinions.

Most early feedback arrives spread across Reddit threads, Discord servers, Slack groups, email replies, DMs, and social posts. Those channels are genuinely valuable: they are where you find people in the first place, and abandoning them would be a mistake.

The difficulty is comparison. Each comment answers a different implicit question, sits in a different context, and lives in a different inbox. Three weeks later you cannot tell whether four people mentioned the same confusion or whether you remember one person vividly.

Running responses through a consistent review flow does not replace those channels. It gives the feedback they generate a single shape, so patterns become countable instead of remembered.

Other builders give sharp, fast, and often technically astute feedback. That does not automatically make it validation.

The distinction is simple: a builder who genuinely has the problem you are solving is a target user, and their review counts as target-user feedback. A builder who is not your target user can still point out confusing flows, missing steps, and unclear positioning. That is useful community feedback, and it is worth keeping separate when you look at whether demand exists.

1. Define the assumption you need to test.
2. Put the MVP in front of people who resemble your intended user.
3. Collect structured feedback so responses can be compared.
4. Look for patterns rather than individual reactions.
5. Decide what to change, continue, or stop.
6. Repeat with the next assumption that carries real risk.

VerifiFlo is one way to run the collection and comparison parts of this process. In practice it looks like this:

• Create a project for the MVP you want feedback on.
• Share a public feedback link anywhere you find reviewers.
• Let people try the product themselves.
• Collect structured reviews where everyone answers the same questions.
• Review signals such as Product Experience alongside written comments.
• Use what you learn to decide what to build next.

There is also a community layer: builders can find other builders' products through Explore & Review and leave feedback themselves. Reviews from people who say they would actually use the product are treated as target-user feedback; the rest is kept separate as community feedback.

None of this guarantees an outcome. A tool can make feedback easier to gather and compare; it cannot tell you that a product will work. The judgment stays with you. If that process fits how you want to work, you can validate your MVP with structured feedback using VerifiFlo.

• I know which assumption I am testing.
• I have put the product in front of relevant users.
• I am collecting feedback consistently, not ad hoc.
• I can tell target-user feedback apart from general community feedback.
• I am looking for patterns rather than isolated opinions.
• I have identified what needs to change.
• I have made a decision about the next build step.