The Importance of Minimum Viable Product
Minimum viable product (or MVP) is a term that is thrown around a lot in enterprise software development, but not everyone is clear about what it means. Or specifically, what it should mean. It’s a source of significant debate, but this is my take.
What is a minimum viable product?
The minimum viable version of a product is the first version with sufficient features to satisfy the stakeholders and implement the product’s essential functionality. The ‘minimum’ part of MVP will vary heavily, dependant on the aim of the project and the expectations of the people involved.
Here are a few simple examples to demonstrate the concept.
In the real world, it is far more common to see additional features beyond what is stated in these examples.
What a minimum viable product is not?
Most importantly, a minimum viable product is not the same as an incomplete product. The MVP should be considered to be a complete version of the software. It could be said to be the first version, that does not contain all the features that may be introduced in later developments. However, it is important not to see the MVP as a test, trial of ideas, or proof of concept. An MVP software product should be produced with the same quality and processes as any other development.
An MVP should also not be an initial sales mechanism, in my opinion. It should be the first step in a project’s real development. An MVP should not be created to show off what can be done or made in place of a proof of concept, prior to a project’s initial scope being agreed to by all involved. An impressive, completed minimum viable product can, however, be proof of a development team’s ability to produce a high-quality software system.
Why is the minimum viable product concept important?
Developing a minimum viable product first can have many advantages.
- Getting early feedback — It is very important, especially when developing a system for a client, that feedback is received as soon as possible during a system’s development life-cycle. Developing a large system immediately, rather than a phased development starting with an MVP, can be a disadvantage. It can result in insufficient or poor quality feedback, due to a much larger feature set requiring testing — both internally and by the client. A lack of early feedback can result in incorrect assumptions and wasted time later in the project’s development.
- Minimising development costs — Starting with a minimum viable product naturally reduces development costs. Focusing on the features that are most important to the client can help get an impressive product developed, without expending excessive effort on unnecessary bells and whistles.
- Prioritising simplicity — Software systems can become incredibly complex, even seemingly small ideas. Focusing first of an MVP version emphasises simplicity and forces design and development that prioritises ongoing simplicity and future proofing, which will be beneficial if a project expands to have further phases of development in the future.
- Mitigating feature creep — Having a well-defined MVP as part of the original development agreement with the client can help manage expectations. If a client is aware of the features they will be receiving in the MVP, and are aware that expansion is possible in later development, it is likely to mitigate to the tendency to request a small new feature here and there.
