Choice of MVP: Evaluate Your Options
Many a times MVP (Minimum Viable Product) and what definition it carries get clouded with lot of factors. To start with, let me refresh couple of aspects of what a MVP (Minimum Viable Product) may stand for:
“It is a core artifact in an iterative process of idea generation, prototyping, presentation, data collection, analysis and learning. One seeks to minimize the total time spent on iteration. The process is iterated until a desirable product/market fit is obtained, or until the product is deemed non-viable.”
Sometimes in doing above we tend to under-evaluate the cost of doing the MVP itself. Depending on what idea you are testing, there might be many things that might be involved to achieve the MVP state (first iteration)and although the software piece might be easy or less time consuming, the offset of complexity does happen somewhere else. This leads to making choices of what the MVP should look like and more than often impacts the test results as well leading to premature conclusions about the MVP.
Taking Metrics Driven Approach
After observing and executing couple of MVP led designs, I have tried to put a simple way of looking at my MVP choices while working with the stakeholders. The spirit is to make stakeholders appreciate the choices they pick and how it can impact their test results.
To making evaluation of MVP choice more effective, try to do following:
• Customer experience
• Operational Complexity
The ideal state of an MVP would be to offer best customer experience with low operational complexity. But as everybody knows ideal state only nature provides and it is impossible for humans to achieve that!
Added graph is a representational state of making quick evaluation of your MVP proposal and seeing if the units within would face high level of operational complexity to achieve MVP state.
Some reading observations that you can get if you were to look at the graph are:
• One of the biggest facts that this can help decipher is that if you are in a zone of delivering a good experience
with high complexity, then it would be better advised to go for the best experience to improve outcome analysis as customer experience is determinant of the MVP state and its future outcomes.
• The other outcome one can observe is that if high operational complexity does not bring about a notch above customer experience then rethinking the design is important
• If you get best experience on low operational complexity, then you might be operating very close to end state design and one should avoid iterating as it may lead you in over-engineering zone
Pitfalls to Avoid:
• It is very important to see that we don’t fall in trap of defining MVP without solid outcome stories. Sometimes it just extends and the scope itself defeats the word “Minimal”. One of the key metrics which one should derive from MVP is to judge confidence levels and increase trust factor for adoptions as a function of confidence index.
• MVP should not be an excuse for building a bad product. The choice which you pick from assessments determines your way forward to make it marketable. MVP is not the end state product.
• Avoid over-engineering MVP because it can lead to increased support effort (this is what I tried to reflect through operational complexity measurement).