Why Most MVPs Fail (And How to Build One That Doesn't)

The word "MVP" has been ruined

Everyone says they're building an MVP. What they usually mean is: "we're building the full product but calling it an MVP so expectations stay low."

That's not an MVP. That's a product with a PR disclaimer.

The original idea — credited to Eric Ries and the Lean Startup movement — was something sharper: the minimum viable product is the smallest thing you can build to test a specific hypothesis. Not the smallest version of your vision. A test.

The distinction sounds subtle. The consequences aren't.

Why teams get it wrong

There are two failure modes, and they're mirror images of each other.

The first is building too much. The team spends six months building features based on assumptions, ships something polished, and discovers that the core value proposition doesn't land. They've burned runway testing the wrong things.

The second is building too little. The team ships something so bare that real users can't evaluate it honestly. The signal they get back is noise. They iterate on a product no one can actually use.

Both failures come from the same root cause: not being specific enough about what you're testing.

Start with the riskiest assumption

Before you write a line of code, write this sentence:

"We believe [type of user] will [take this action] because [this is true about them or the world]. We'll know we're right if [measurable outcome]."

That belief — the thing most likely to kill your business if it's wrong — is what your MVP needs to test. Everything else is noise.

If you're building a B2B SaaS tool that automates invoice reconciliation, your riskiest assumption probably isn't "can we build the reconciliation engine." It's "do finance teams care enough about this problem to change their workflow." Test that first. With a spreadsheet if you have to.

What an MVP actually needs

Once you've identified your hypothesis, scope becomes obvious. Your MVP needs:

- Enough to let real users experience the core value
- Enough to get honest signal (not "that looks interesting" but actual behaviour)
- Nothing else

That usually means one user type, one workflow, one outcome. No dashboard. No settings page. No onboarding wizard. Definitely no dark mode.

The features you're tempted to add "while you're at it" are almost always the features that obscure your signal.

The conversation you need to have

If you're working with a dev agency or an internal team, have this conversation before the first sprint:

"What would make us stop building this? What would we need to see — or not see — to decide this isn't worth continuing?"

Most teams never ask this. They treat an MVP as a starting gun, not a decision-making tool. But the whole point is to reach a decision faster.

If you can't answer what failure looks like, you're not building an MVP. You're just building.

Ship, measure, decide

An MVP isn't a success when it ships. It's a success when it produces a decision.

Build the smallest thing that generates honest signal on your riskiest assumption. Measure actual behaviour, not reported interest. Then decide: persevere, pivot, or stop.

That's it. Everything else is product management.