MVP Framework

/ Product Market Fit / By

Despite (or maybe because) of it’s widespread use, the concept and beauty of the MVP are often misunderstood and misused. That’s a shame because it’s a powerful concept every startup should understand.

The startup MVP framework

It’s safe to say that everybody who works with a startup has heard about the minimum viable product (MVP) before.  

The term has become a synonym for an early product version that can be kind of bad, just for us to release something to the market and get feedback fast.

While that definition is not entirely wrong, it fails to capture the full potential of the concept coined by Eric Ries in his “lean startup” methodology.

An MPV is more of a process than a product (blame the naming). A process that can help you learn about what product the market wants and save you from wasting time and money on something nobody wants.

Or as Eric Ries himself explains:

 “Whatever the assumption is that we are trying to test, what is the most efficient way to get to the validation we need to say whether it is true or not”.  – That’s the MVP.

The best founders are conscious of the assumptions they make. Instead of blindly following them, they test them fast and adjust when needed.

Using an MVP is the best way to test your assumptions fast and cheap. With this framework, you have a guide that will help you find the right MVP for your situation.

Step 1: Write down your assumptions

Assumptions are the ideas and beliefs that guide our decisions about the product we build, the market we target, and the business model we choose.

The first step is to list all your assumptions. Don’t just do this mentally; write them down one by one.

Your list should not only include assumptions about your solution. You probably already have assumptions about the technology you will use or the ideal customer you want to target.

A picture of UberCabs first website

Let’s make this more practical by using Uber as a real-life example.

In 2009, Travis Kalanick and Garrett Camp were in Paris for a conference when they got into an argument with their taxi driver.

Travis got so upset that he told the driver to pull over and let them out in the middle of a late-night snowstorm.

This moment, being stranded somewhere in Paris without a taxi nearby convinced them to find a solution to the problem of not having taxis available when needed.

But they were still a long way from inventing Uber as we know it today.

Garret’s first assumption was that they could best solve the problem by buying a fleet of cars and making them available on demand. (Assumption 1)

On the other hand, Travis assumed that a peer-to-peer network connecting drivers and customers directly would be the better solution. (Assumption 2)

Step 2: Seven-step breakdown of each assumption

You now have a list that includes everything that will guide your decision about what product (and company) you will build.

Next, find the fastest and cheapest way to test your assumptions. In other words, you need to find your MVP(s).  

There are a few useful “types of MVP” that might appear in a Google search. Examples are Piecemeal-MVP, Concierge MVP, and Single-feature MVP.

Those “templates” are not wrong, but they might keep you from finding an even faster and cheaper way to test your specific assumptions.

So instead, break down how you can test each assumption. Start with the best way to test (that would give you the most feedback) and work your way to the worst option (that still gives you a little bit of feedback).

You can use the following seven steps as a template:

  1. What finished product do I have to build to test the assumption?
  2. Can I use existing solutions to imitate the product?
  3. Can I remove unneeded features from the finished product?
  4. Can I imitate certain features from the finished product?
  5. Can I imitate (do manually) everything the finished product would do?
  6. Can I only test the message of what the finished product would do?
  7. Can I validate my assumption by looking at other company’s products?  

Let’s go back to Uber and break down one of their assumptions with these seven steps.

Travis and Garrett had two main assumptions about how to solve the problem of taxis not always being available when needed.

We’ll use Travi’s peer-to-peer idea as an example.

What finished product do I have to build to test the assumption?

An app and web platform that allows taxi drivers to offer their services and customers to book rides on their phones in real-time.

Can I use existing solutions to imitate the product?

Back in 2009, the options for this type of MVP were limited. But today, one could simply create a WhatsApp group with taxi providers and early users. People can send their GPS locations, and the first taxi to respond gets the ride.

Can I remove unneeded features from the finished product?

Could they have built the web platform faster and cheaper by stripping it from every feature that was not absolutely necessary to test the assumption?

People could call the nearest ride instead of offering an automated pickup; payments could be made in cash.

Can I imitate certain features from the finished product?

Instead of automatically matching the closest rider/customer, clicking the “pickup” button could have signaled the founders to manually call taxi providers and find the nearest ride.

Can I imitate (do manually) everything the finished product would do?

Travis and Garrett could have given their phone number to early users and told them to call them whenever they needed a ride.

With every call, the founders could have manually found and sent out the closest and cheapest taxi.

Can I only test the message of what the finished product would do?

Instead of building or offering anything, could they have gotten useful feedback on their assumption by just telling people about the benefits of the potential product?

The typical way this is done today is to set up a landing page and have people sign up for a waiting list.

Can I validate my assumption by looking at other company’s products? 

Could the two founders have saved themselves any validation work by looking at existing companies and products that validated the same assumption?

Step 3: Chose the right type of MVP

There is no one right MVP choice for any given situation. Choosing which option to take is always going to be a judgment call.

Just because the lower options on the list are easier and cheaper doesn’t mean they are always the right choices.

If you can build a cheap product that generates value within one or two weeks, don’t waste your time on a landing page. Build it and get actual user feedback.

Likewise, if you are an industry expert and deeply understand the problem and market, you might take more risks and start with a more substantial MVP.

But if you don’t have much insight yet (and many startups don’t), a low-effort MVP is probably the right choice.

Even if something like a landing page doesn’t provide detailed feedback, it can be enough to decide whether the assumption is worth testing more or if you are on the wrong track. 

Back to Uber, neither Travis nor Garrett had any experience in the taxi industry.

Before they wrote a single line of code, they called up different providers and asked if they would like to offer their service on a third-party platform. That’s number 6 on the list, testing the message.  

This did not give them real insight into what those providers would think of their platform. But it was enough to find out whether there was any interest at all in such a digital solution.

On the consumer side, they started with the last point on the list. Instead of trying to validate the assumption themselves, they looked for other online platforms that already brokered transportation services (and weather people used them).

Step 4: Analyze, adjust, move on

Analyze your results and decide if they validate your assumptions. But don’t wait for 100% validation. That will only make you wait around for too long.

Aim for just enough validation to be confident enough to put more time and money into the process.

Your next step depends on your situation. Maybe you want to test a different assumption with a separate MVP. Or perhaps you build a more substantial MVP that gets you close to your envisioned product.

Use the principles connected to MVPs to create a learning process that helps you get to product-market fit faster.

If your initial MVP disproved your assumption, you have three options. You can adjust your MVP, adjust your assumption, or scrap the assumption altogether.  

Especially with “low-fidelity” MVPs (such as a landing page), it can be hard to know what went wrong since you don’t get much detailed feedback.

Consider all angles you could adjust, such as your target group, message, channel, technology, etc.

Travis and Garrett at Uber felt like their initial assumption was validated when three out of ten taxi providers said they would use their platform and when they realized that people already use other online services to book transportation.

Their next step was a basic version of their App that they tested on friends and family who wanted to book high-end transportation in San Francisco.

Sources