Failing to Identify the Minimum Viable Product

Published: 21st May 2014

Before writing this, I had a look at what other people defined as Minimum Viable Product, in some cases the example is provided as being so minimal that a product doesn’t actually do anything other than record the users interaction with the product.  Further reading showed that it meant different things to different people.  The products I work with are not viable unless they perform the key calculations, so I find this definition to be the one that makes the most sense to me (please note the original article has now gone).

A Minimum Viable Product is the smallest thing you can build that delivers customer value (and as a bonus captures some of that value back).

For nearly three and a half years I have been leading a large product rewrite of a windows application as a web application that integrates fully with another web application.  Seven months ago we started beta testing with selected clients and despite some issues that had to be fixed, the beta test went well.  Now the sales and marketing team is going to market with what they see as a very strong product that will sell well to our target audience.

So what does this have to do with Minimum Viable Product? Why do I feel that there is an element of failure when everything looks very positive?

I didn’t know we had to identify Minimum Viable Product, it was a term I was unfamiliar with and so it wasn’t identified.  The mandate from the company was that if we were going to replace the windows product, we could not sell the web product unless it had every single feature the windows product had.  It’s easy to argue that in this circumstance, Minimum Viable Product was the same as Viable Product.  I do however feel that the number of features the product had were more than what was needed to go into beta testing and that certain features we had developed were surplus to requirements at the time and were more “nice to have” than “essential”.

I do hold that we are in a good place, and I am very optimistic that the product will perform well.  However in going through this long journey I know now that there are a number of things that I would tackle differently and I do feel that if we had performed these steps that we could have gone to market sooner.

Step 1 - Customer Research

I would review our customer base and profile a number of customers based on the size and complexity of their companies.  From there I would have moved on to communicate with the customers and to profile their use cases for the product.

Step 2 - Identify Minimum Viable Product

I would review our feature list and cross check that against the use cases from the most basic customers that had been identified previously.  This would have then formed the basis for our Minimum Viable Product.

Step 3 - Identify Viable Product

I would review customer list and work out the Use Cases that fit 80% of our customers, I would then cross reference this with our feature list to create the requirements for our Viable Product which were not contained in our Minimum Viable Product

Step 4 - Identify Ideal Product

I would review all remaining use cases and cross reference them with what was left outstanding in our feature list.  Any feature which had a use case that was not in either the Viable Product or Minimum Viable Product would be added to our Ideal Product.  All remaining features that had no use case could be forgotten about until such time that a use case for them arose.

Step 5 - Iterate

I would do all of the prior steps before to be sure we had it correct.