You Keep Using That Word—“MVP”…

I hate the word MVP. (For those less familiar with startup jargon, MVP stands for Minimum Viable Product.) Like many ideas that start out useful, the term MVP is often misunderstood. Before I get to that, though, let me attempt to summarize what an MVP is.

Frank Robinson coined the term MVP, and Eric Ries popularized it—in large part through his book, The Lean Startup. Essentially, an MVP is the simplest version of a deployable product. By releasing early, you’re able to assess product/market fit. Doing so helps you minimize the risks of over-building in isolation. Put differently: an MVP helps you avoid making something people don’t want.

You might look upon an MVP like a mid-stage prototype. In releasing one, you’re able to test your idea and learn from real users. This allows you to work with fewer resources, and reduce build time. Most importantly, this feedback helps inform your next steps.

This iterative build approach is sound. The cold voice of real-world feedback tempers your, possibly manic, aspirations. Most go too easy on their ideas, at the outset. An MVP represents a sort of reality check that resets your bearings.

Many who hear the term MVP, don’t read past the headline. They see an MVP as a thing, and not part of an ongoing process. In turn, they treat it like a binary test that definitively tells whether to proceed or move on to something else.

The problem with turning an MVP into a sort of go/no-go, is that such tests generate a lot of false negatives. So, even viable ideas—that aren’t well executed—are dropped, instead of retooled. Such a mindset is in direct conflict with the underlying principles of lean thinking.

Nevertheless, countless makers treat MVPs like lottery tickets. They look at these with unrealistic expectations, and forget them when they don’t “win.” This is akin to a child expecting her first drawing to be on par with a Michelangelo—and quitting when it isn’t.

Let me save you the surprise: your MVP will not live up to your expectations. In all but the rarest of instances, MVPs are a disappointment. Sometimes this indicates that you completely misread the market. More likely, though, is that your execution isn’t quite right. This is OK—because you released an MVP.

Like the drawing I mentioned, there’s little holding you back from erasing bits and making corrections. You can examine what’s not working, and where there’s confusion. Heck, you can even grab a new sheet of paper and start over.

An MVP is a single iteration. Its release marks a crucial point in your testing and data collection—but it’s not make or break. Your MVP affords you an opportunity to learn, correct, and improve. This leads to a new iteration. You can release these updates within hours of launching—and you will produce many more after this. Negative feedback isn’t an excuse to quit—even though many treat it so.

Yet, this notion of hitting a home run on the first try persists. A whole generation of startup founders is drunk on the fantasy of an afternoon project that turns into a unicorn. So, they pump out one sloppy project after another—and they abandon these products with equally little consideration.

I don’t believe in miracles. When it comes to your startup/creation, neither should you. So, what do you believe in if you aren’t banking your future on a stroke of good luck? How about work? Sure, the idea of an overnight success makes for great publicity. Scratch the surface of most, though, and you see that these breakthroughs mostly happen after years of toil.

Maybe I’m leading you astray. I don’t have a billion dollar exit to my name, so what do I know? Maybe you should move to the Valley and get a few million in venture capital funding. Perhaps you should build a placeholder site for every idea you have—and quickly move to the next if you don’t immediately strike gold. Who knows? You could be the one who has a great idea, just by reading TechCrunch articles all day long.

I’m of a different mindset. I think you first determine a meaningful pursuit (like: I want to help others learn from one another). Then, you define a small way to do this, and work to produce a decent version of your idea. Once it releases, you talk to people and find out what doesn’t work—and you fix these problems.

Throughout this process, you remember your end goal. You also remain dispassionate about the individual implementations. None of this is personal. You are not a failure if one version doesn’t perform. You just return to your workbench and make another. You also avoid panicking over ups and downs. The events of a single day are rarely ever that big of a deal, in the long run. So, keep going.

This is what it takes to build something good.

Sign up to receive new articles by email: