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 minimise the total time spent on an 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 in order to achieve the MVP state ( first iteration ) & although the software piece in itself 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.
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 there test results.
In order to making evaluation of MVP choice more effective , I 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 ! Below 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 custom
er 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
Happy evaluation !
Leave a Reply