...But what is a MVP?

I have recently read an article about the MVP and how Over the past few years that I have been working with cross functional teams, the teams have always come to a moment when the they need to define scope of a new feature and potentially the MVP which is the minimum viable product that could be released to the customer for collecting feedback

Although one of the main reasons of releasing an MVP is the learning (Build-Measure-Learn) I have found the actual definition of the MVP as a challenging topic for teams, product managers and agile coaches as facilitators of the feature kick-off meetings. I always get the question from fellow agile coaches on how can we know to what granularity an MVP should be? How should we slice it and would that even make sense?

The constant struggle between product managers focusing on shipping the MVP as soon as possible and the designers and artists who are having a hard time to stop polishing their baby and ship it out! Does that sound familiar to you too?

I think the confusion begins with the V in the word MVP! The reason is that it is such a complicated thing to know what ‘viability’ actually is! The word ‘viable’ can have several meaning depending on who you ask. From a developer’s perspective, viable might mean ‘can we build this’ and from an artist’s perceptive viable product/feature means ‘would this look nice’ but the reality is that you want to get feedback from users about whether or not they would like to pay for the product or use it on a repeatedly manner.

So, if you had to take out the ‘viable’ part in MVP what you should find in the middle there is actually the metric or the thing that you are trying to validate. For example, if you’re building a product/feature that you want people to really share it, then the MVP for you would be 'minimum shareable product'. Therefore, depending on what you’re trying to build and validate the word ‘viability’ can have different meaning. 

So the next time you struggle with defining scope of the MVP, think about what would be a reasonable amount of technical investment or polish that the team could put out there that customers don’t feel totally disappointed about the whole product.

Figure out what are the non negotiable that the team can put around an experiment to make sure that they actually allow themselves to learn and to understand what the value propositions are from the user’s perspective.

An MVP is about that how the users are going to interact with the product/feature and to make sure that they even able to get to the point where they can give the team feedback about whether or not the MVP is solving the problem.

Bringing It All Together

The next time that you find yourself stuck into an MVP scope definition discussion, ask yourself what you are trying to learn/validate by this MVP and use that as a foundation for defining what 'viable' really means to you and based on that investigate jobs-to-be-done to achieve that goal.