What Even Counts as MVP?

Between POC (Proof of Concept) and MVP (Minimum Viable Product), the latter is more often misunderstood. Let's find out why and what we can do about it.

The misunderstood idea of an MVP is: "Some crappy version of the product you're aiming for, cranked out quickly so we can put it out into the world to see what happens." While this definition contains kernels of truth, it also misses the mark:

Minimum Viable For What?

You can't look at something in isolation and tell whether that's an MVP or not. Without knowing what business goal you're shooting for, it's impossible to say whether what you have is both minimal and viable.

  • Is the goal to get early-stage venture capital?

  • Is the goal to land a paid pilot project with a single client (who'd become a strategic partner)?

  • Is the goal to launch to the public and immediately land paying customers?

  • Or, even earlier, is the goal to suss out whether there's even demand?

What counts as minimal and viable for those goals varies wildly. It can go from a vibe-coded user interface mock-up (with no real underlying functionality) all the way to something that's fully decked out with cloud hosting, user accounts, and credit card payments.

The same product could be vastly overbuilt (viable, but not minimal) for one business goal and woefully under-built (minimal, but not viable) for another.

So what?

Isn't this all just semantic nitpicking? Well, consider a non-technical founder with lots of domain expertise and an idea for a great product. They engage a software development team and ask them to build them an MVP, without ever clarifying what their next business milestone would be. There's real risk that the dev shop takes the running, vague, definition of MVP and builds that "crappy version of the product". But without the business context, it's not clear what can be cut without sacrificing viability and what absolutely needs to be there from day one. The product ends up in a weird state where it's overbuilt in one dimension and underbuilt in another (see the illustration)

Illustration of an MVP (hits the right level of values in dimensions x and y), underbuilt (too small in each dimension), overbuilt (too large in each dimension) and simultaneously over- and underbuilt product (too large in one dimension, too small in the other).

The one takeaway: The same thing can be an MVP or not, depending on the business context. Therefore, without that context, it's likely that the wrong thing will be built, the wrong way. The question that cuts through this: "Minimum viable for what?"

Next
Next

Do You Need a POC?