Bounce screenshot

What is an MVP?

Minimum Viable Products (MVPs) are tricky:

  • How “minimal” should yours be?
  • What does “viable” mean?
  • How do you keep it simple, without ruining your reputation?

MVPs only need to only do one thing. To understand that one thing, you want to understand the definition of MVP.

MVP is the new Beta?

Remember when “betas” were a thing – as in, “we’re working on our beta version”, “we just launched our private beta”, etc.?

In the last few years, that term has been replaced with “MVP” – “we’re working on our MVP”, “we just launched our MVP”, etc.

This is where the confusion around MVPs stems from…

MVP is *not* the new beta Click To Tweet

The original definition of MVP from Frank Robinson is:

A version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

In other words, your MVP is the version of your product with the highest ROI when you optimize for “validated learning.”

So how do you optimize for validated learning?

Test your “Riskiest Assumption”

For your business model to be successful, there are a number of assumptions that need to be true:

  • Customers know they have a problem
  • They want your help solving it
  • They will pay you to solve it
  • You can solve it
  • etc.

All of your assumptions can be prioritized in terms of “riskiness” where the assumptions that are most critical to the success of your startup, and/or are least likely to be true, are considered more “risky” than the other assumptions.

For example, “you can solve your customers’ problems” is critical to your startup’s success, but it’s very likely to be true (humans are natural problem solvers and since you’re a human, I’m confident you can solve your customers’ problems). On the other hand, “customers will pay you to solve the problem” is not only critical to your success, it’s also (unfortunately) less likely to be true – so you would consider that assumption more “risky” than the former.

Once you order your assumptions by their “riskiness”, to build an MVP, you build the simplest version of your product, that tests your riskiest assumption.

In other words, an MVP is:

A version of a product that allows a team to collect a maximum amount of validated learning of customers test their riskiest assumption with the least effort.

Notice how this definition changes the focus of an MVP from building a product, to running an experiment. That’s critical to understanding what an MVP is – remember that.

MVP or Not an MVP?

Use the examples to test whether you understand what an MVP is…

Example 1: Explainer video

Dropbox famously gauged demand for their product via a demo video that, thanks to some video editing, demonstrated functionality they hadn’t built yet.

What do you think? MVP or not an MVP?

Let’s look at the definition again:

A version of a product that allows a team to test their riskiest assumption with the least effort.

Does a demo video of functionality that doesn’t exist represent a:

  1. Version of a product that
  2. Tests the team’s riskiest assumption with the
  3. Least effort?

If Dropbox’s riskiest assumption was “people want a new service to sync/share files” and if it took less effort to edit video than it did to write code for the functionality that didn’t exist, then yes, this is an MVP!

As long as the riskiest assumption is being tested with the least effort, it’s an MVP.

If instead they’d built a simple version of their product (i.e. a pilot, a beta, etc.) and measured how many people used it everyday, the wouldn’t have been testing their riskiest assumption, and they wouldn’t have done it with the least amount of effort.

Example 2 – PowerPoint Demo

PowerPoint Slides

Let’s say you are going into a pitch meeting with a customer using a slide deck with mockups of your software. You’re not going to demo any functionality at all, you’re just going to talk about the problems you’ll solve while showing them some pictures, what do you think, MVP or not an MVP?

Recall the definition of MVP:

A version of a product that allows a team to test their riskiest assumption with the least effort.

As long as you’re testing the riskiest assumption during that meeting (e.g. “customers will pay us to solve this problem”) with the least effort (a slide deck is less effort than even making a video), it’s an MVP.

Keep in mind that a slide deck is just like a video – minus fancy transitions. If a video meets your team’s criteria for an MVP, a slide deck might too – especially in B2B scenarios.

If on the other hand you went into that meeting hoping the customer would create an account on your platform and try it during the meeting – you’d be testing the wrong assumption, and you’d have done so with far more effort than a simple slide deck. A working prototype wouldn’t be an MVP.

Example 3 – Landing Page

Landing Page

If you imagine a landing page is just like a PowerPoint deck that you scroll through instead of click through, then you can already tell, a landing page can be an MVP as well.

Again, you want to use the least amount of effort to test your riskiest assumption – as long as you’re doing that, you’re building an MVP.

Anything more than that, and you’re getting closer to a “beta” product, than an experiment.

Example 4 – Facebook Advertisement

Facebook Ad

If you capture the essence of a landing page in a FB ad, with a title, image, description etc., then…what do you think: MVP or not an MVP?

What was that definition again?

A version of a product that allows a team to test their riskiest assumption with the least effort.

So really, as long as you’re testing the riskiest assumption with the least amount of effort…you get the picture.

If we go back to the Dropbox example we can even see that depending on their riskiest assumption, they too could have used a Facebook ad to test this out.

If their riskiest assumption was, say, “people have problems syncing/sharing files” the Dropbox team may have been able to test that with a Facebook ad!

Example 5 – Simple App

Bounce screenshotA friend and I gave ourselves 24 hours to build a proof-of-concept app that would help people get to their appointments on time. It had basic GPS, traffic and calendar integration, rudimentary UI, and we only built it for Android.

It got written-up Forbes and as a result, we were able to collect the email addresses of 3,000 people who wanted the iPhone version.

What do you think? MVP or not an MVP?

To know the answer, we have to look where we always look…our riskiest assumption.

If our riskiest assumption was genuinely, “We can build the app”, then it would have been an MVP. The truth is though, our riskiest assumption was, “People will pay for this app” and there was no way for us to test that with this app.

So, no, despite the app being simple, newsworthy, and popular…it wasn’t an MVP.

If it doesn't test the riskiest assumption call it a beta/pilot/POC - just don't call it an MVP Click To Tweet

What’s your Riskiest Assumption?

Now that you know what your MVP needs to do, you just need to figure out your riskiest assumption so you can build one.

Good news! My post next week will tell you your riskiest assumption and the best MVP is to test it! Subscribe to get it in your inbox.

To Recap

  • MVP is not the new beta
  • Definition of MVP = (Say it with me…) The simplest version of a product that tests your riskiest assumption.
  • Before you build an MVP, you have to know your riskiest assumption.

Want More MVP Help?

This is the first of a four part-series on MVPs:

  1. (This one) What is an MVP?
  2. What Kind of MVP Should you Build?
  3. My 8 Favorite Tools for Building MVPs
  4. I’ll Fix your MVP: Send me your MVP and I’ll tell you what, if anything, to tweak to make it perfect.

Stay tuned for those.

Bonus: Want me to Review your MVP?

Leave a comment below with a link to your landing page MVP and if it provides a good lesson for others to learn from, I’ll post a video review of what you’re doing well, and what you might consider changing.

The videos will be public so you and the rest of the Customer Development Labs community will learn from them which this is an ideal opportunity for startups who are:

  1. Confident in their landing page MVPs and want other startups to see it or
  2. Not confident in their landing page MVPs and want help fixing it.
  1. Great post, Justin. The lean purist in me always gets bothered when people throw around MVP. I’m glad you applied some more structure behind it and gave a few examples; having a consistent working language is important in my opinion.

    I have an experiment going on that I believe is serving as an MVP:
    Want to use it as an example?
    I’m mainly testing that 1) people will sign up for/give me a phone call and then 2) purchase one of the smart home packages listed on the site. Going directly to step 2) would obviously be great but I’m fairly early so talking to people about it would provide a lot of learning.
    I can fulfill the solution manually no problem.

    Let me know how you’d like to move forward!

  2. Good stuff Justin. Far too little practical information out there about Lean Startup. Thanks for creating something helpful.

  3. Hello : great post. Our MVP is written in french (as address the french market at now), but you can access a english translated version via Google translated, and it’s quite accurate :

    We will get happy to get your advices.

  4. As you always seem to do – straightforward advice that can be put into action right away.

  5. Great post. I like the risk-driven approach explained. One detail only: the “P” in “MVP” does not seem to be appropriate for these artifacts. A PPT is not a product.

    Mauricio Palma

    1. Thanks Mauricio. Note the definition says a “version” of a product which, IMO, includes PowerPoint presentation. Perhaps I should emphasize that more.

      When founders fixate on an MVP being a functional product, they greatly under-value the principle. I highly encourage folks not to fixate on the literal meaning of the acronym – practicing the principle on the deeper level will lead to far more benefit.

      1. Justin. I agree. I just think that a PPT is not a product because it does not deliver any value to the customer, but can be great for validating your assumptions in some cases. It is a tool for the entrepreneur. So the P of “MVP” is somewhat confusing.

        1. “So the P of “MVP” is somewhat confusing.”

          Couldn’t have said it better myself. :)

  6. Great post. The examples help to ground what an MVP actually is. I also like the revised definition of MVP: The simplest version of a product that tests your riskiest assumption. Viewing a business model through the perspective of risk is one of the most helpful skills I’ve learned when deciding on what to focus on when building a business.

  7. The concept I’m working on is a choose-your-own-adventure version of what Charity Water does. I’m running what I think is an MVP to test the biggest risk, which is that we can convert traffic to paying donors at a cost effective price.

  8. One of the best posts I’ve read on MVP to date, and one that I’ll be referencing for a long time to come. Having launched several businesses under the premise that MVP = Beta it has cost me a lot of time and money over the years. Am about to endeavour on a new passion project and would love your thoughts if what I have is the MVP (Proving that entrepreneurial fathers want what I can offer).
    Hope to hear from you!

  9. Justin,
    Great treatment of MVP. You outline some important, practical ways to validate using a version of the product.

    FYI: I’d like to clarify Frank’s MVP. I worked with Frank for six years when we first developed the Marjet Valudation process for our consultancy and I have kept in touch with him.

    The original MVP (and the way we both still use it) is as the definition of the actual product that customers will buy. The minimum effort refers to the development effort…smaller product (i.e., fewer features) means less time and effort, but viable means can solve the problem well enough to be worth purchasing.

    You are spot on that the product could be on paper, but the feature set, etc. is defined. The point of the MVP was to get a product in users’ hands ASAP, because real users with actual product feedback was better than reaction to thinking about using it.

    And using it in meetings while still on paper or in beta form was to develop relationships with real prospective customers while still exhibiting clear limits to what would be delivered.

    One way we made these clear was to have a Limitations slide and to show a product roadmap showing V2 and V3 features to figure out whether our V2 feature needs to be V 1

  10. Excellent post. You’ve made the distinctionbetween beta and MVP crystal clear.

  11. Awesome post Justin! :)

    I am currently working on the following MVP (I think?) –

    The pain I am trying to solve is that many of us tend to overestimate what we can accomplish within a day. Which is frustrating and stressful, since we constantly miss our daily goals.

    Flocus could help us create more realistic schedules and become more productive. My riskiest assumption is that people would pay for Flocus / my way of solving that problem.

    What do you think?

  12. Great Justin! I have followed customerdevlab and found all these posts and videos pretty interesting. What I would to highlight, is the way you share your experience… such a great lesson! Congrats!

    Diego Bitencourt

    Onda Forecast

  13. Great post Justin. The penny has dropped for me…I was promoting my website which is being developed currently as a beta… which I guess it is. Your simple yet effective concept makes me really re-think things. I wanted something tangible to take to B2B customers so they could have something tangible against which to decide to pay for… I also have a pitch deck which I was going to use in the interim… I’m thinking now that the pitch deck with some mockups may just do the trick and gives me confidence to use it alone at least for now rather than waiting 12 weeks for the site to be developed.

    1. That’s really inspiring to hear Shaun. Thanks for sharing. Please, keep me posted!