MVP validation strategy: what to test and in what order

Most teams start in the wrong place. They build an MVP, put it live, and then check whether people actually want it. By that point, they've spent months on assumptions they never challenged.

A solid MVP validation strategy flips that around. Start with one question: which assumption, if wrong, makes the entire idea worthless? That's the one you test first. Not last.

At Livewall, we work regularly with organisations building digital products from scratch. Loyalty platforms, community applications, campaign tools. The pattern we see repeatedly: teams that validate early build better products. Not because they're smarter, but because they learn which directions to rule out before investing heavily in one.

The three categories of assumption

Every MVP rests on assumptions across three levels:

Desirability — Do people actually want this? Are we solving a problem they genuinely have?

Feasibility — Can we deliver this technically and operationally, in the way it needs to work?

Viability — Does the business model hold? Can we sustain this commercially?

Most teams test desirability last, even though it's the assumption that fails most often. Always test desirability first. Only once you know people want it does it make sense to invest in the rest.

Step 1: validate the problem before the solution

Before you design a single screen, you need to know whether the problem you're solving is real and large enough to matter. This sounds obvious, but teams skip it constantly because they've already fallen in love with their solution.

Ten to fifteen conversations with potential users is enough. Not surveys. Not multiple choice. Ask about behaviour, not opinions. 'Tell me about the last time you ran into this problem' yields far more than 'Would you use this product?'

If you can't find a consistent behavioural pattern connected to the problem you're solving, stop. Or sharpen your problem definition. Pivoting your solution later is always more expensive than adjusting direction now.

Step 2: test the value proposition before the interface

Once you know the problem exists, test whether people want your specific approach. Still without building anything.

A landing page with a clear call-to-action works well here. Drive traffic to it. Measure who signs up or clicks through. The point isn't to get approval, it's to observe behavioural intent. There's a significant gap between 'sounds interesting' and 'I want this now'.

In our KLM Scalable Growth Case, the core question wasn't 'can we build this?' but 'which part of this system delivers the most value for the least production effort?' That question required validating usage assumptions before technical ones. The order shaped everything that followed.

Step 3: test the critical user path before the edge cases

You now have an MVP in progress. What do you test first? The critical user path. That's the sequence of steps a user needs to take to experience the core value of your product.

Everything outside that, the settings, the welcome email, the help button, is an edge case. Edge cases come later. The critical path comes first.

For Sportvisunie, the critical path was easy to define: an angler needs to be able to share a catch with their community within thirty seconds. That flow was tested first. The rest of the platform followed only once that core action worked well.

Step 4: test with real users before you scale

Many teams go live with a rolled-out version and then check whether the KPIs hold up. But 'going live' is not the same as 'validating'. Validation happens with a small group of real users in a controlled environment, before you scale.

Five users thinking out loud while using your product will give you more actionable insight than a thousand analytics sessions. Watch what they do, not what they say. Observe where they stop. That's where your friction lives.

What not to do: test everything at once

The biggest trap in MVP validation is teams wanting to test too many assumptions simultaneously. They build a 'quick' version that's actually fairly complete, put it live, and then try to figure out why it did or didn't work.

If three things change at once, you can't know which one made the difference. Isolate your variables. Test one assumption at a time, or as few as possible.

This requires discipline. It also requires you to write down, before the experiment, what you're testing, what success looks like, and where the threshold is that determines whether you continue or change direction. Without those criteria up front, you'll always find a reason to keep going after the fact.

The mindset: disproving, not proving

The goal of validation is not to be right. It's to find out as quickly as possible when you're wrong.

This is an uncomfortable mindset, especially when you've already invested energy into an idea. But the teams that build good products fastest are the ones least attached to their first hypothesis.

At Livewall, when working on MVP development, we ask a simple question at the start of every project: what would make us decide not to build this? If no one can answer it, we're not ready to start.