Because of the title, many people are confused about Minimal Viable Product.
This isn’t the same as just getting by. For example, if a new internal project is underway, the organization was already “getting by” previously. But the new MVP project provides essential coverage to meet a need without expensive “gold plating.” If funding ran out and MVP was achieved, you would have a working product in the market or for your internal client and would be doing much better than before. Additional features may be developed beyond MVP, but those are done after the product is viable. So, just because MVP is achieved does not mean the project will stop, just that it could and still be usable.
That is an important threshold to cross in product development.
MVP is an important technique for Avoiding Waste. When a potential capability or feature is added to the solution, one of the first things we should ask is whether this is necessary for a product to be viable.
And by viable, that means that it meets the minimum requirements for the early adopters of the solution.
Again, it isn’t that non MVP features will never get done. Just that the MVP features will come first. In other words, it avoids waste by giving priority to what is necessary.
In defining the MVP, it is important to address the following.
First, identify who needs or wants this solution. Then from that group, identify the early adopters.
Next, identify what needs to happen for the goal to be met and how you can verify that has been met.
Thirdly, as the solution goes along, actually measure the results to verify the intended need is being met by the minimum solution.
Finally, Define the requirements for each feature of the MVP solution.
One interesting thing about MVP is how this focuses on early adopters. If you do not satisfy them, you do not have a product.
Another aspect is this is not a static state – MVP can change over time. As new features are identified, it becomes important to understand whether these are to become part of the MVP or whether they should be delayed for later – risking their exclusion from the product if there is not enough value.
That determination is how waste is avoided with this technique.
The context is Product Management or Refinement and the Audience is both Internal Teams and External Stakeholders.
Strengths and Limitations
Some of the things to be aware of for MVP Using are how it can be used to avoid unneeded or unwanted robust features.
Also, it’s important to realize the amount of research required to identify what is important for early adopters, and that sometimes features may be a best guess. And if the solution is simple, going through all this might be overkill.