Blog Layout
An Introduction to Minimum Viable Product in Software Development
Rich Cullen • February 10, 2020
The suggestion of a Minimum Viable Product (MVP) approach may raise concerns amongst stakeholders, particularly where they are not fully aware of the concept or have experienced bad results previously. When managed effectively however and with a clear understanding across the team then great value can be found.
What is MVP? (And What it's Not)
In its simplest form MVP is an approach intended to deliver working software at the earliest opportunity. One of the main purposes of this is to encourage learning and then to refactor the software to benefit from these learnings. The use of the word "minimum" can be a little misleading and imply that a lot of potentially great stuff is being left out. This isn't the intention, development does not halt once an initial limited release of the fuller vision has been delivered. Rather what is trying to be accomplished is identification of the earliest possible opportunity that the software can reach a usable state where feedback can be gathered, for subsequent stages to build upon.
Early Delivery and Learning
I've been involved directly in software development for a good while and have seen projects go well and not-so-well. Sometimes failures are hard to avoid but I've also seen projects that were ultimately successful through sheer will and an overwhelming desire to not reach a point of failure. Looking at common issues amongst these, I could highlight: -
- A delivery date months (or even years) past the targeted release;
- Mounting frustration between vendor and customer over costs or agreed functionality;
- End-users rejecting the software;
- Overwhelming support issues or emergency changes required by the development team upon release;
Often the common denominator amongst these can be attributed to a product launch that is not just ambitious but encompasses elements that are either not essential to the user or where iterative learning has not been carried out. It can be easy to get caught up in the grandeur of all-conquering product design - the excitement that is generated through innovation is a powerful motivator for a team. However, targeting a complete "finished" product without trialing can increase the risk of failure or at least make it likely that significant change will need to be made to the product post-deployment.
MVP can help mitigate these risks by getting the product to the users as early as possible, basing subsequent decisions on real data. Value from the software is returned quickly; initially in terms of feedback and in later, fuller releases, financial return. Issues (and new ideas) can be discussed openly and resolved before compounding into greater challenges and features that were considered essential during the early days of planning may not be required at all, saving money.
To MVP and Beyond - A Journey to Happy
It can take significant time for a software product to mature; numerous iterations of the feature sets. Taking the time to comprehend this and embrace an iterative development process can help reduce frustration amongst stakeholders where this was not the expectation.
Possibly the leap of faith is to accept that the first few releases will almost undoubtably not make the customer (be it end-user, business owner etc) happy. The main intention here is simply to gather feedback for later releases: -
| Release 1 | Release 2 | Release 3 | Release 4 | Release 5 (And Beyond) |
|---|---|---|---|---|
| Early version of the product, focusing on feedback. It meets the users' needs but is not close to being finished. | Initial feedback has been taken and reworked into the product. Users can do things a little faster and with a fuller feature set. | Most features are working reasonably well though further refinements are being identified as well as the opportunity to drop some requirements not actually needed | At this point we are likely around the point which stakeholders envisiaged as the complete version. | Moving beyond initial expectations, adding new functionality to increase engagement. |
As a final take-away, it's worth noting that the principles of MVP can work just as well for simpler software projects as they can for large scale roll-outs. A smaller set of requirements does not necessarily mean that all assumptions made at the outset will be correct, no matter how obvious they may seem.
Let's Talk
If you feel I may be able to assist your organisation, please contact me and we can talk through your requirements.
Get in Touch