Skip to main content
MVP is one of the most misused terms in product. Teams call fully-featured v1 launches “MVPs”. They call polished demos “MVPs”. What Eric Ries actually meant in The Lean Startup was something more disciplined: the minimum you need to learn, not the minimum you need to ship 🚀

What an MVP prototype actually is

An MVP prototype is a functional - but deliberately incomplete - version of your product built to test a specific hypothesis. It does just enough to generate real signal from real users in real conditions. The key word is functional. This distinguishes it from high-fidelity prototypes, which simulate behaviour without actually doing anything. An MVP prototype produces real outcomes - it might send a real email, process a real (test) transaction, or deliver a real result. That realness is what generates honest signal.

The minimum viable part

The hardest discipline is ruthless cutting. Every feature you add beyond the core hypothesis is waste - it costs time, muddies the signal, and makes it harder to know what caused the result you got. A useful forcing question: what is the one thing a user needs to do for us to learn what we need to learn? Build only that. As Jeff Gothelf and Josh Seiden argue in Lean UX, the goal is outcomes, not output 💡

MVP vs. pretotype vs. prototype

  • Pretotyping - fake it entirely, measure intent before building anything
  • Lo-fi prototype - simulates the experience, no real functionality
  • MVP prototype - real functionality, stripped to the minimum needed to test the hypothesis
  • Full product - real functionality, built for scale and quality
Each step costs more but produces stronger signal. Choose the cheapest option that can answer your question. Lesson learned: the most common MVP mistake isn’t building too little - it’s building too much and calling it minimum. If your MVP took three months, it wasn’t minimum 👀