An MVP Is A Test, Not A Product.

Judging by posts I’ve seen lately, it’s time to talk about MVPs—the so-called “Minimum Viable Product.” There’s a lot of misunderstanding of the notion. People take the acronym too literally. There are two definitions of MVP. The earlier one was coined by Frank Robinson, and aligns with what people often think (that the MVP is a product), but the more useful definition is the one Eric Ries describes in his book “Lean Startup.” I think of Ries’ MVP as:

The minimum thing that tests the
Viability of a
Product idea.

It is not version 1.0 of your product. It’s not a product at all, in fact. It’s a test. If the test passes, the idea is viable, and it might make sense to build v1.0. The whole point is to not waste time building something nobody wants.

Notice that my definition didn’t say “the minimum thing you can build” because the ideal MVP doesn’t require any building at all. The MVP for DoorDash was pizza delivery, which tested the viability of home food delivery. No coding required. A second MVP might test online ordering with a single-page site featuring a minimal menu for a single restaurant. The MVP wouldn’t process any orders—it would just forward them to a human, who would handle everything else. Again, the idea is to test the viability of a product idea, NOT to build a product. The MVP is a precursor to building. Only after those two tests (MVPs) gave you satisfactory results would you consider building something real.

MVPs must be very small. They go together in a day or two, maybe a couple of weeks on the outside. They often have zero niceties (like a slick UI or even a database under the covers). In one of his online talks, Ries suggests that you come up with the smallest possible set of features. Then cut that in half, then cut it in half again, then cut it in half one more time. Put in terms of testing theory: test only one thing at a time.

The next issue is quality, and there are two schools of thought. One is that you want to get the MVP into your potential customers’ hands as quickly as possible, so using Vibe coding or sloppy manual coding to create a throwaway MVP is fine. The key concept in that last sentence is “throwaway,” though. This approach effectively bets that the idea will fail, so you want to expend the least effort.

The second school looks at the MVP as the core of a walking skeleton (the beginning of an iterative development process). Here, you’re betting that the idea will work. Given that the MVP will be at the core of a real system, it must be high-quality. The feature set is very minimal, so the MVP still comes together very quickly, but the code is real, production-quality code. My experience is that high-quality code goes together faster than low-quality code, so the quality actually helps with speed.

These two approaches cannot coexist. It’s a disaster in the making to use a low-quality MVP as the core of a walking skeleton. You’ll never overcome the corruption of the putrid core.

Two related concepts are worth mentioning.

A prototype is a test that answers the question: “Does this design actually work the way we think it does?” You can prototype any aspect of a design, from the UX to the database. Prototypes come in two main flavors.

A low-fidelity prototype is something like a simple whiteboard sketch of a proposed UI. It goes together in seconds and is meant to help with quick decisions.

A high-fidelity prototype is a fully functional model that usually tests the behavior of some part of the program under load or in some real-world usage scenario. It can’t do that if it isn’t full-on production-quality code. Usually, high-fidelity prototypes are massaged over several iterations until they work as expected, and then are inserted into the main body of the code.

Neither of these prototype flavors is an MVP. A prototype tests a design. An MVP determines if a product is worth building. Those are entirely different things, even if they have a superficial similarity.

The other related idea is proof of concept (PoC). You use PoCs very early in the design process to prove that some aspect of the design will work. Typically, they’re used before you get to the prototyping stage and don't look anything at all like the finished product. For example, if you’re worried about database performance, you might kludge together a simple program that does nothing but dump data into the database and pull it back out to make sure the database can keep up with worst-case load. The concept is similar to the notion of a "spike" in Scrum. A PoC is neither an MVC nor a prototype. It’s just testing whether a design decision that’s still under consideration will work out.

So, I’m a huge fan of the (Ries-style) MVP approach. The best way to get a product to your customer sooner is to not waste time building features they don’t want. The MVP helps with that.