THE MINIMUM VIABLE PRODUCT: TWO TRUTHS AND A LIE

A key milestone for any startup is the development of its Minimum Viable Product, or MVP (as it’s often called). Often, I’m approached by entrepreneurs who want help building an MVP, only to discover that they don’t entirely know what an MVP is. And, in many cases, they’re prematurely looking for help with development. So,…

MVP

A key milestone for any startup is the development of its Minimum Viable Product, or MVP (as it’s often called). Often, I’m approached by entrepreneurs who want help building an MVP, only to discover that they don’t entirely know what an MVP is. And, in many cases, they’re prematurely looking for help with development.

So, to help learn more about the MVP, we’re going to the game, “Two Truths and a Lie”…startup style. You probably remember this game from when you were younger. So, here’s how it works. There are three statements below. Which of these statements is true and which is false? (Don’t scroll down to peek at the answers!)

  • The minimum viable product should solve a problem
  • The minimum viable product is a learning tool
  • The founding team can engineer the minimum viable product in a vacuum

The Minimum Viable Product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.

-Eric Ries, Lean Startup

Truth: The Minimum Viable Product is a Learning Tool

As Ries’ definition suggests, the Minimum Viable Product is fundamentally a learning tool. It should help you to figure out if you’re solving an important problem that customers care about, while also learning to communicate a vision that you can use as the basis for building your business.

The MVP is not intended to be a final product or release.

Truth: The Minimum Viable Product Should Solve a Problem

Still, a Minimum Viable Product is more than just a couple of wireframes or a clickable prototype. It should have some features that, taken together, attempt to solve a problem that you believe needs solving. As a learning/communications tool, you should treat the feature set as still largely hypothetical. The features shouldn’t be perfect (the feature set will likely change anyway!), but should be functional.

Lie: The Minimum Viable Product can be Built in a Vacuum

A common mistake founders make is spending a lot of time working together to build a product that they will, one day, “launch.” This is a mistake; it is virtually impossible to learn if you have the right feature set or are selling the right vision if you’re working by yourself (or by yourselves).

You should work hard to get your MVP in the hands of your ideal customers and talk to them. The goal is to get ‘validated learning’ and that can only be accomplished through customer interactions.

Ok, let’s try one more time. Which statements are true, and which is false?

  • The minimum viable product should be built quickly
  • The minimum viable product is not a prototype
  • The minimum viable product should be feature-rich

Truth: It Should be Built Quickly

One way to reduce the potential of feature creep is to get the product developed quickly. Like, within 90 days or less. Ideally, less. The sooner your product is in the hands of your target customer, the sooner you can move forward validating your assumptions and moving towards the ‘right’ feature set (e.g., the ones customers want to pay for).

Truth: You Should Prototype Often

As a learning tool, your minimum viable product is never “done.” It is the basis for building a more robust product and a more robust business and should be iterated on over time. After you interview some customers, gather the feedback, determine which seems valid, iterate, and release again.

Lie: It Needs to be Feature-rich

Your minimum viable product should not be feature-rich. In fact, it should only have the minimal number of features necessary to a) understand if you’re solving the right problem in b) the right way, and c) communicating the right vision.

As Steve Jobs famously said, “focus is about saying ‘no.'” Your minimum viable product should say “no” to everything that isn’t essential to helping you validate your learning and your market.

Getting to market is hard and the specific feature set required of your minimum viable product will vary tremendously, depending the market, the kind of product, and so forth. Still, remembering – and staying close to – these principles, will help you to make sure you’re building the right product for the right customers with the least amount of effort and risk exposure possible.

This article is adapted from my Keynote at Lansing’s Startup Weekend: Maker Edition. You can find the slides at slideshare or on LinkedIn.

Leave a Comment

Your email address will not be published.

Scroll to Top