What Is an MVP and How Do You Plan One?

Johannes Gutenberg began printing the Bible in 1452. It was an enormous job: 42 lines per page, in two volumes. The project was so expensive that he had to borrow from Johann Fust, a Mainz moneylender, first 800 guilders and then another 800.

But in the same workshop, before the big book was finished, much smaller jobs were being printed too. In 1454 and 1455 thousands of indulgences came off the press for the Church. They were single-sheet documents; several thousand copies were printed across seven separate editions. Historians count them among the jobs that made the new press money.

The Bible was finished in 1455; around 180 copies were printed. That same year Fust sued for what he was owed, which with interest came to 2,026 guilders. The court ruled in Fust's favour and control of the Bible workshop passed to him. The inventor of the printing press lost his workshop before he could reap the commercial rewards of his greatest work.

First the indulgences, then the Bible

Gutenberg's story is an old version of the question founders argue about most today: while you build the big vision, when do you put out the small, useful thing that keeps you alive?

Today that small thing is called an MVP: a minimum viable product. In a 2019 talk to founders, Michael Seibel, a partner at Y Combinator, defined the MVP as the first, laughably simple thing you can give to the first users you're targeting. It has one purpose: to see whether you can deliver any value to those people at all.

Seibel's examples dispel the myth that "everything was perfect from the start". The first version of Airbnb in 2008 had no payment system; guest and host handed over the money in person. You couldn't see where the home was on a map. When Twitch started out as Justin.tv, it had a single channel: the life of one of its founders, Justin. There was no gaming. Stripe's first name was /dev/payments; it had no bank deal either, and the founders went to customers' offices and did the integration with their own hands.

How do you plan an MVP?

Talk first, then build

You don't need years of research, but don't start without talking to a few users. Best of all is if you have the problem yourself: you'll be the first to know whether the product works. Don't ask users for features; ask them to describe the problem. How often do they have it, how much does it bother them, and would they pay for a solution?

Hold the problem tightly, the solution loosely

Seibel's advice is clear: hold tightly to the problem you're solving and to your customer, but hold the solution you're building loosely. The "complete product" in your head may not be what the customer wants. An MVP is nothing more than a starting point to iterate on.

Measure in weeks, not months

For most startups an MVP should be out in a few weeks. Sometimes you don't even need software: a landing page and a spreadsheet will do. Cut the functionality down to your first users' most urgent problem; leave the rest for later.

Set a deadline, write it down, cut

Set a deadline for launch, say three weeks. Keep only what can be done in that time on your list. Always write the list down; a plan that isn't written down changes without you noticing, and three weeks turn into three months. If after a week you can see you won't make it, cut the unimportant things first and, if you have to, the important ones too. The real goal is to get something out into the world; once it's out, momentum comes on its own.

Don't overrate "launch" day

How many people remember the first day of Google, Facebook or Twitter? According to Seibel, your real launch is the day you find your first customer. Put the big, press-grabbing launch off until later and bring the first user forward.

The heavy MVP exception

In regulated fields such as insurance and banking, or in deep tech such as rockets or drugs, you won't ship a product in a few weeks. Even then you can start with a simple website explaining what you do; it gives the people you talk to somewhere to go back and look.

Don't fall in love with your MVP

If the product isn't useful to your first users, looking for new users for it is an easy escape. But what's broken is usually neither the users nor the problem; it's the solution itself. Keep the users and the problem, fix the solution. The first version is only the first step on a long road.

Prototype: the first strike

"Prototype", the MVP's older relative, comes from the Greek "prōtotypon": "prōtos" means first, and "typos" means a blow, a notch, the mark left by a strike. At its root is "typtein", the verb to strike.

Centuries later the same "typos" found its way to the heart of the printing press. From the early 1700s, the English word "type" also came to mean the small printing block with a raised letter on its face. So the letters Gutenberg cast and the moment an idea first touches the world come from the same word.

A prototype is an idea's first mark. It doesn't have to be perfect; it just has to touch the world once. Your product's first mark is the one it leaves in a real user's hands. Not in a pitch deck.

Final word

Voltaire opens his poem "La Bégueule" by recalling an Italian proverb:

"A wise Italian says in his writings: the best is the enemy of the good."

So what is the "Bible" you're waiting to finish? And what is the smallest page you could give a real person this week?

This article draws on Michael Seibel's talk "How to plan an MVP" in the Y Combinator Startup Library. For the other side of starting a business, take a look at the Startup Graveyard too.