What a minimum viable product really means and what it doesn't

Building a digital product has never been more accessible. The tools are better, the barriers are lower, and teams can move faster than ever. But interestingly, the success rates haven’t really followed that same curve.

A huge number of products still fail, and not because the tech wasn’t good enough or the team didn’t deliver. More often than not, they fail because they were built on assumptions that were never properly tested.

There’s a stat that gets referenced a lot in product circles, that around 42% of startups fail because there’s no real market need for what they’ve built.

When you stop and think about that, it’s not really a development problem, it’s a validation problem. And that’s exactly the gap an MVP is meant to fill. It gives you a way to pause before you go all in. To be able to step back and ask, “Are we solving something that actually matters?” and more importantly, “Can we prove it?”

At its simplest, an MVP is the smallest version of your product that gives you real insight into your users. It moves you beyond guessing or assuming and into something far more concrete. And that’s the part that often gets lost.

Because when people hear “minimum,” they tend to focus on what they can remove. Fewer features, less time, reduced scope: it becomes a question of efficiency. When in reality, that’s only half the picture. The other half is “viable.” And viable doesn’t mean “it works.” It means “it delivers value.”

So you’re not just stripping things back, you’re shaping something very intentionally around a specific question you need answering. It might be:

• Will people use this?
• Does this solve the problem we think it does?
• Do they understand it without explanation?
• Would they choose this over what they do today?

An MVP is how you turn those questions into something tangible.

One of the easiest traps to fall into is treating an MVP like an unfinished version of a product. You’ll sometimes hear things like, “It’s just the MVP, we’ll polish it later.” But from a user’s point of view, there’s no such thing as “just an MVP.”

They’re not thinking about your roadmap or your future iterations. They’re experiencing what’s in front of them, right now, and in that moment, it either clicks or it falls flat. There’s no roadmap context, no future features, just the experience in front of them.

That’s why a good MVP still needs to feel coherent. It should do one thing, but it should do that one thing properly. A helpful way to think about it is this:

• You’re not building part of a bigger experience.
• You’re building a smaller, complete experience.

Something that stands on its own, even if it’s focused on a very specific use case.

This is usually where the disconnect shows up, because even teams that understand the theory can drift when it comes to execution.

One of the most common approaches is to take a full product idea and try to scale it down. “We’ll launch with these three features, then add the rest later.” On the surface, that sounds sensible, but it often means you’re still working towards the same assumptions - just more slowly.

A true MVP doesn’t start with the full picture and trim it back, it starts with the uncertainty and builds around it. And sometimes that leads to something that looks very different to the original idea, which that’s a good thing.

Speed gets talked about a lot with MVPs, and yes, they should help you move faster, but ultimately, speed without direction doesn’t really get you anywhere useful. If you launch something quickly but you’re not clear on what you’re testing, you don’t get meaningful insight, you just get noise.

Downloads go up, people click around, maybe you see a bit of engagement, but without context, it’s hard to know what any of it actually means.

This one can feel counterintuitive, especially for businesses used to thinking long-term from the outset. But an MVP doesn’t need to be future-proof. It doesn’t need perfect architecture, or fully optimised performance, or a roadmap that stretches two years ahead. It needs to answer a question, and that’s it.

Once you have that answer, then you can make better decisions about how to scale, what to invest in, and where to go next.

If you strip everything back, this is what an MVP is really about: understanding.

Not certainty or perfection, but a stronger signal of what’s worth pursuing and what isn’t. And that’s where the real value sits.

There’s another stat that often comes up that around 70% of digital transformation projects fail to meet their objectives. Again, it’s rarely because teams can’t build, it’s because they’re building the wrong things or solving the wrong problems. An MVP is one of the simplest ways to reduce that risk.

Even with the right intentions, there are a few patterns that crop up again and again, you might recognise some of these.

Sometimes the scope starts small, but gradually expands. A feature gets added here, another one there. Each one feels justified in isolation, but collectively they shift the focus away from the original question.

Other times, the MVP is built without a clearly defined hypothesis. There’s a general sense of what the team wants to explore, but nothing concrete enough to measure against. So when it launches, the feedback is open to interpretation.

And then there are moments where the data does come back clearly… but it’s uncomfortable. Engagement is low, users drop off quickly, the value isn’t landing. Instead of stepping back, the instinct is to push forward. Add more, tweak more, try to “fix” it.

But at that point, the MVP has already done its job, it’s told you something important. The challenge is being willing to listen.

There isn’t a single template for a good MVP, it’s going to look different depending on what you’re trying to learn. But there are a few signals that you’re on the right track, such as:

• You have a clear idea of the assumption you’re testing
• You’ve designed something specifically to test it
• When users interact with it, you’re able to draw meaningful conclusions from what happens next

Not vague impressions or surface-level metrics, but something you can confidently act on. Because that’s the thing an MVP should leave you with. Not just something you’ve built, but something you understand better than you did before.

It’s easy to treat an MVP as a phase. Something you do at the beginning, before moving on to the “real” product. But the teams that get the most value from it tend to carry that thinking all the way through.

They keep testing, challenging assumptions, and finding smarter ways to reduce risk over time. Building a product is about making better decisions, more consistently, over time.

And that’s exactly what a well-thought-out MVP helps you do.

If you're serious about building the right product, not just building quickly, it starts with asking better questions. That’s where we come in.