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 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 customCaptureer 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

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

WordPress.com Logo

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

Facebook photo

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

Connecting to %s

About Me

Over 20 years of experience developing software to support multi-million dollar revenue scale and leading global engineering teams. Hands-on leadership in building and mentoring software engineering teams. I love History as a subject and also run regularly long distances to keep myself functional.

Newsletter

%d bloggers like this: