Minimum Viable Product has to be Viable

Minimum Viable Product is not a new idea and it has been around for a while now. Like any buzzword that takes of it has had it’s fair share of confusion around it and plain miss interpretations. Some people to see it as overly simplistic idea where you get started with the absolute minimum.

While it is still good idea to get the first round of feedback from colleagues, friends and family as they certainly can provide some very useful early feedback even for something as simple as a login page, but a login page is hardly a product and some way of being viable. Minimum Viable Product is not just minimum, it is VIABLE.

A steering wheel alone is not a valid car

A steering wheel alone is not a viable car

In short the idea is to do a simplified version of any given product and then put out out there in the market to start gathering all important real end user feedback. The product has only the key functionality implemented.

This makes sense not only because it saves time, but it may also lead to vastly better product. Simple product tends to be simple to use and majority of software features are never or hardly ever user. Analysis based on Pareto principle can be applied to software engineering and leaves us with a statement that says “20 percent of the features provide 80% of the value”. The features that are never used is widely considered as one of the greatest causes of waste in software engineering.

Not used features have been implemented making the code more complex than it needs to be. More code lines mean more bugs and harder and more time consuming maintenance. Bug fixing will be targeted to fixing bugs that affect features that users don’t need etc.

Scrum co-creator Jeff Sutherland also makes a point on this. He talks about value curves where he explains that after delivering 20% of the highest priority stories the value produced starts to decline and it’s time to re-prioritize to get a new value curve. Scrum methodology fits well into developing a minimum viable product.

The fundamental challenge with Minimum Viable Product is not just minimum. A login page is hardly a product, it still has to be VIABLE. This leaves us with the biggest challenge when it comes to Minimum Viable Products –  what is viable? This can very hard to define and various greatly depending on the existing market. When creating something new when the market is in virgin state something very simple can be enough. When there are already players in the given market, something viable can be a lot more complete product.

Still we history has shown that consumer tend to value good user experience over bunch of features. Just look what happened with iPhone, when it first came out, it did not have copy / paste, no multimedia messages, no 3rd party apps and hardly anything we take for granted now.

To get started we have to make assumptions about customer demand and needs. The Minimum Viable Product helps us validate these assumptions. There various ways our assumptions can be wrong:

  1. The customers don’t want given product

  2. our assumption of minimum viable is too restricted and is not useful for customers

  3. the customers would settle less than was originally thought

Only number 1 is clearly result capable of killing the business.

Harvard Business Review offers two versions of Minimum Viable Product: validating and invalidating. This post touches mostly validating minimum viable prodcut. You can read the whole article here:

Posted on 14/01/2014, in Agile, Lean, Scrum. Bookmark the permalink. Leave a comment.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: