Build stuff that people will buy!

Sounds simple – doesn’t it?  And yet, years of building products (many of which no one wanted to buy) has taught me that it is incredibly difficult.  Regardless of the brilliance of the idea or the size of the market, there is no way to know, in advance, whether the product has merit in the eyes of the customer.  Basically, when you start, all you have is a hypothesis (aka a guess).

A Minimum Viable Product (MVP) helps test your hypothesis. 

I’ve been thinking a lot about MVPs lately – motivated by several conversations with first-time entrepreneurs.  This blog-post expands on some of those ideas.

What is an MVP?

As defined by Eric Ries, an MVP is… that product which has just those features (and no more) that allows you to ship a product that resonates with early adopters; some of whom will pay you money or give you feedback.

I love this definition.  Including feedback as an outcome, extends the applicability of the MVP approach to free products and internal initiatives.

So, what are some of the common misconceptions?

1. MVPs are just prototypes. NO! – they can be, but not always.  If prototypes are scaled down versions of the final product, then they are different from an MVP. An MVP must help the developer answer their product hypothesis. Suppose the success of your product is built around “People will change their standard operating procedure, because our product is faster/cheaper/ better”.  You had better test that key assumption.  A prototype, on the other hand, can just be a scaled down version of the final product.  It could include just one feature.  The whole user experience will then be pretty flat, and any feedback isn’t useful.  In such a case, the product fails the viable Again, it needs reiterating – an MVP must include all the features and functions necessary to test the core hypothesis.
2. Build what you can afford. Another common misconception is building only what the current budget or early fundraising allows.  My opinion – give the money back!  Or raise some more.  There is absolutely no point in force-fitting an MVP to the current budget.  Instead validate the product through other means – for example, an explainer video.  And if you can get actionable feedback without writing a line of code, then you’ve struck gold.  However, I am skeptical that just a landing page can provide the same quality of feedback as when users are able to touch and feel products.
3. An MVP is a “one and done”. Again, it depends on the complexity of the product and the number of hypotheses its built on.  Ideally, an MVP is fly-wheel of build-release-learn-build… Each build needs to test a hypothesis.

Building MVPs are a time-consuming and deliberate process.  Sufficient thought needs to go into deciding what gets included in the MVP.  On the back end, user data also needs to be carefully analyzed in order to recognize nuggets of insight.

The MVP will not resonate with all customers.  Being able to sift through user data to identify early adopters, and incorporate their feedback, is vital. On the other hand, the data may point to a totally different use-case for the product, and help refine product-market fit.

In every case, I am glad that I first built an MVP – even when they have failed.  Learning early that my hypothesis was wrong, saved money and more importantly, time.