How to Build an MVP—and How NOT To (Lean Startup)

This article is an excerpt from the Shortform summary of "The Lean Startup" by Eric Ries. Shortform has the world's best summaries of books you should be reading.

Like this article? Sign up for a free trial here .

Figuring out how to build an MVP? Just as important as building a great MVP is figuring out how NOT to build one. Learn the key MVP strategies from Lean Startup here.

Review of Minimum Viable Products

The critical question you need to answer for your startup is: what is the MINIMUM product you can build to get reliable data on your hypothesis?

This product is termed the Minimum Viable Product (MVP) and is one of the most important concepts in Lean Startup. This is the product that is the bare minimum to test your hypothesis. Unlike normal product development, you are NOT aiming for product perfection – you’re merely trying to start learning as soon as possible.

How NOT to Build Your MVP

Note that:

The MVP is NOT the smallest product imaginable. It needs to be enough to test your hypothesis. Sometimes this can actually mean a functional product. Sometimes it can just be a web page. It really depends on your hypothesis.
The MVP is NOT an excuse to ignore all quality problems. Some quality issues really make a difference to the customer. Let’s say you build an engaging video MVP like Dropbox’s example above, but it takes 10 seconds to load. In response, users bounce away from the page without ever hearing about your product. If you ignore this error, you’ll infer the wrong conclusion – that users don’t want your product – when in fact they never learned what your product does in the first place. You need to design your MVP to make sure it reliably tests your hypothesis.
The MVP is NOT an excuse to “just launch and see what happens.” Your MVP should be tied to direct quantifiable hypotheses, like “10% of all visitors will sign up for the beta,” or “1% of all active users will pay at least $5.” If you don’t have these hypotheses set in stone, 1) you’ll design a faulty MVP that doesn’t lead to productive learning, 2) as you collect data, you’ll fall into complacence (“well, only 2% of visitors signed up, but that’s still pretty good.”)

MVP Mistake 1: You Will Almost Always Overbuild Your MVP

When you figure out how to build an MVP, you will always be tempted to overbuild. Your pride as a professional inhibits you from releasing low quality work. You envision a world where your product is commonplace, and you can’t bear to build something that’s just 2% of that final vision.

But keep this in mind: If you do not know who the customer is, you do not know what quality is.

In other words, you may spend hundreds of hours polishing a high-quality feature that no one wants. If no one wants your MVP, can you really say it’s high quality, or that it even matters?

In contrast, if you produce a barebones MVP and customers tell you something is low quality, then that’s valuable data on what you should focus on next. Your early adopters care primarily about the core of what you’re offering; without bells and whistles, a promising idea will still show great metrics.

MVP Mistake 2: Why You Will Launch Your MVP Too Late

Finally, you’re likely to launch an MVP too late because you suffer from common fallacies. Here they are, and here’s how to deal with them:

You’re afraid that a competitor will steal your idea. In reality, there are too many good ideas in the world and not enough good people or time to execute on them. As Eric suggests, just try to pitch a product manager or venture capitalist to work on your idea – it’s not going to happen. They have an abundance of ideas to work on and not enough time. You’ll more likely find early on that no customers actually want what you’re offering. Keep this in mind as you figure out how to build an MVP.
You’re afraid that you’ll lose your “first mover advantage” if you go public earlier. In reality, if you make it big, competition will come after you, no matter what. And if you aren’t able to fend them off in the long run, you’re dead anyway. (See how live streaming app Meerkat got crushed by Twitter’s Periscope, even though Meerkat had a sizable time lead. Your only long-term winning strategy is to learn faster and be better than competition, and waiting doesn’t give you any advantage.
You’re afraid that a minimally-featured product doesn’t showcase the full potential of your vision, and customers will reject the MVP when they would otherwise have loved your product. Look at it this way – if customers don’t respond well to your MVP, you can figure out why. If it’s because the MVP’s missing a critical feature that was part of your vision, you can build it in and re-test. You don’t lose much. But if you find that a core part of your vision is mistaken, your MVP will help you find out earlier. You have much to gain and less to lose.
If you do fear that a prematurely negative result will make you lose hope, you can promise ahead of time that no matter what happens in the MVP, you will not give up hope until a certain number of iterations or time point. Use this to figure out how to build an MVP.
You’re afraid of a bad reputation from a bad MVP that will cripple your brand. In reality, your MVP is unlikely to gain so much attention that this is going to matter in the long run. But if you’re worried about it, just launch the MVP under a different brand. You’ll still be able to test and learn, without any negative consequences transferring over.
You’re afraid of legal intellectual property or patent risk, since showing your product to the public can complicate patenting your idea. This is a legitimate concern for some companies, and you should consult a lawyer.

I consider the MVP the most important concept of this Lean Startup summary. You will almost always launch far later than you should have. It will be scary to put something out there that you’re not fully proud of.

But as LinkedIn founder Reid Hoffman says, “if you’re not embarrassed by the first version of your product, you’ve launched too late.”

Be bold, and savor learning. Don’t be afraid about being wrong or embarrassing yourself. You will thank yourself later after you build your MVP.

Question: What is the MVP to test your hypothesis? Write a general description. Now force yourself to simplify – what can you throw out until you get to the absolute essential minimal product needed?

How to Build an MVP—and How NOT To (Lean Startup)