The term ‘Minimum Viable Product’ is best thought of as “the smallest iteration of work you can do to validate your assumptions”. The product in MVP can be a misnomer as it’s not always a tactile object.

The product bit comes in because the average person isn’t usually very good at giving feedback on something that doesn’t exist. That’s why we create a small product for our customer to play with.

Step 1) What’s the real life reason?

Users of a product usually have a reason for using them. Take the most obvious use case and explain it from the point of view of the audience:

“As a ___ I need to ___ so I can ___”

For example,

“As someone who’s new to the MVP concept, I need to understand the core mechanics, so I can use them to make my own product”

Note the granularity and specifity of the statement. Keep it tight.

For illustration, let’s pretend we’re building an application for people who want to rent surfboards by the hour. Our sentence reads thus:

“As a newbie surfer, I want to rent a surfboard so I can see if I like surfing before I buy my own board.”

Step 2) Sally forth, whiteboards ahoy

All interactions start with a decision to interact. Let’s say users find us via a Facebook page. We’ll ask them to create an account with a few details for later on. Maybe they’ll sign up with their Facebook account?

We have limited locations for the surfboards, so we ask which location they’d like, then qualify what’s available at that location.

Sometimes there are ‘fail’ points in the system where we lose users. Maybe we could capture these users with an email notification system. We’ll worry about that later on.

Whilst this example is oversimplified, it’s important to examine every single step in the flow. It’s the ‘breaths’ between interfaces where User Experience design lives. Here’s our finished user flow:

Simple, right?

Not quite. There’s mountains of functionality hidden within these seemingly simple steps. As soon as you have user accounts you need “forgot password” pages, with reset emails. Credit card payment is always harder than it seems on the whiteboard.

Step 2) Find the important bits

We need to find what actually matters to our audience. A simple method is to put smileys and sad faces on some of the steps that are obviously fun or annoying.

Another trick identifying steps in the experience that are on brand, remembering that your brand isn’t what you say it is. It’s what people tell their friends it is. Find the unique things about your experience that are worth talking about. We’ll use little hearts for these:

Step 3) Destroy your idea

It’s difficult to butcher your own baby, but here is where we get rid of any steps that aren’t absolutely necessary for the idea to be tested. Start with the sad and difficult steps, then simplify others.

For us this includes:

  • Choosing one location, with a few simple booking times
  • A set board renting time (we’ll try an hour)
  • Payment via a simple Paypal link

Step 3) See what happens!

This simplified design could be launched in a single day and put to the test with a small audience. Complex systems like booking and payment could be managed by hand. It might be unwieldily, but it’s still much faster than building a huge system nobody ever uses.

Remember, MVPs are for testing assumptions

We need to learn if people we don’t personally know are willing to rent a board, for a set price at a set place. By measuring less stuff, we’ll get a better lock on what affects people’s decisions about our product.

The sad truth is that with the fat trimmed, the core ideas of your big crazy ideas might already exist elsewhere. Sometimes, MVPs turn out to be less exciting than the big scary bells-and-whistles version is.

The upside, however, is that if the lean version of your idea still has that visceral, exciting edge to it, you’re probably on to a good thing.


This is part four in a series about startups. Next issue we’ll look at crunching the numbers on your MVP to validate when, if and how it might make some cash money.