3 Ways To Design An Effective MVP

Steve Blank and Eric Ries describe the minimum viable product (MVP) as an initial product version, with just enough features to satisfy your early customers and teaches you what they want.

It’s the cupcake version of your grand product cake.

Here are three perspectives, to help you design an effective MVP.

For context, I’ll illustrate my points using three popular unicorns – AirBnB, Stripe, and Uber.

#1 Restrict Users:

Initially, the AirBnB founders targeted only a handful of designers, who were attending an SXSW design conference in San Francisco. Three designers, who were strangers from different parts of the world, stayed at Joe and Brian’s apartment for a few nights.

AirBnB founders initially rented out three airbeds to three designers, from different parts of the world, who couldn’t find any hotel rooms, while attending an SWSX conference in San Fransisco.

Why? Because the MVP solved a problem. It helped designers stay near the conference when all other conveniently located hotels were booked out.

When Stripe set out to create a developer-friendly way to process online payments, their first version in Sep 2011 was restricted to only their friends.

Similarly, Uber’s initial MVP was an app and a car driving around San Francisco. The founders and their friends used that car when needed.

These massively successful startups with scalable business models started off by restricting users. Why? Because it was the fastest way for them to understand what their ideal users wanted.

So, how can you restrict your MVP users? How can you build something quickly to attract the smallest subset of desperate users?

Because, if you aren’t able to find that small subset of desperate users, then maybe it is time to revisit the problem…

#2 Restrict Features:

AirBnB did not get paid automatically, via their website, for a very long time. The founders would make calls or personally collect the fees themselves from the listed house owners.

Stripe did not have bank deals when they started. They might have even failed if they started by wanting a bank deal in the first place. Instead, the founders found a way to process payments without a bank deal. They probably processed the initial transactions themselves, manually.

Stripe didn’t have bank deals when they started out. So the founders must have processed the initial payments in a hacky – startupy way.

Uber did not have an app that the public could use. In mid-2010, they only had a PHP website and a car. The founders primarily used the car. If their friends wanted to ride the car, they had to email Travis and ask him for an access code.

Initially, Uber didn’t have an app. For someone to use the car, they had to email Travis and ask him for an access code. Yet, more users wanted to ride a chauffeur-driven car in San Fransisco.

In spite of these limitations, in all our three examples, users grew at an exponential rate. Why and what can we learn from this? Two things.

First, when you restrict features, you have to do a good chunk of the work manually, yourself. This is a golden opportunity that allows you to better understand your customers need and to find more efficient workflows to solve their problems. Please make use of this. Why would you not?

And second, this helps you figure out your extreme use cases. Think about it. Why would three designers pay some strangers to sleep in their living room, on their airbeds? Or why would someone go through the trouble of emailing someone and waiting for an access code to get a cab? Maybe, because they don’t want to travel 40 km a day to attend a conference. Or maybe, because they are stuck without transportation late at night.

These are your ideal users with extreme use cases. And they won’t mind taking the extra trouble to use your product. Because their other options are even worse. Nothing is more valuable than this.

Remember, when you figure out your extreme users, you begin to have a viable business.

#3 Restrict Usefulness:

This one is quite counter-intuitive, isn’t it? I mean, why would you restrict being useful? Especially when your goal is to create a useful product.

Because you’re optimizing for learning about what your users want by investing the least amount of time, effort, and money.

The initial AirBnB MVP was useful only until the conference lasted.
The initial Stripe MVP was useful only to the tech-savvy friends of the founders.
And the initial Uber MVP was useful only to the founders and their friends, only when they were in San Francisco.

Yet, by restricting usefulness, our three MVP examples won loyal customers who validated the need for their solution.

By restricting users, features and usefulness, you can design an effective MVP that teaches you the most about what your ideal users want.

Let me put this to you differently. You can always make your product more useful with time. After all, it is only a matter of engineering things together. But it is unlikely that your users will start needing your solution more desperately as time goes by. So, figure out your desperate users first.

In fact, it will only become harder, to change course as time goes by, and pick a better problem. The time, money, and effort that you invested already will only make this even harder. So, you’ll want to validate your problem as early as humanly possible.

Given a choice between validating a real pressing problem and building something massively useful quickly, I hope that you prioritize validating your problem, with as little investment as possible.

This is the single most useful thing you could take away from this article.

I would love to hear your perspectives on designing an MVP. Have a question or an idea? Leave it as a comment below.

Also, if you are an early-stage technology startup and are looking to raise investments from a bunch of seasoned entrepreneurs, let us know. We want to hear from you. You can learn more about us here.

Note: I ghostwrote this piece for Marat, an early-stage investor & Managing Partner at Good News Ventures. Originally this appeared here.