Your MVP should so just 1 thing

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.

A video version of this blog post is available here.

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 stem from…

MVP is not the new beta.

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 experimentThat’s critical to understanding what an MVP is – remember that.

MVP or Not an MVP?

Use the following 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:

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 yesthis 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

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:

version of a product that allows a team to test their riskiest assumptionwith 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

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

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?

version of a product that allows a team to test their riskiest assumptionwith 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

A 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

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!

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 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.

Comments or Questions?

Please fire away!


Credit: With thanks again to Justin Wilcox of Customer Development Labs, for allowing me to re-publish his article on stuart-hall.com.

Leave a Reply