DevOps is all about fast and frequent deployments, measuring value and continual improvement. I’m sure you have heard about reducing batch sizes in order to decrease lead time, increase deployment frequency and improve stability and quality. Well, focusing on the minimum viable product is one way to reduce batch sizes and enable more frequent deployments.
What is meant by Minimum Viable Product (MVP)?
A product which is delivered with just enough features/capabilities to satisfy a subset of users and validate a business use case. Once the product is released, the subset of users will provide feedback which will drive the direction and delivery of subsequent features (or halt development if the product does not appear to have viable business value). Products generally follow an iterative deployment model, and the product evolves through multiple deployments before the product is seen as ‘complete’.
Why is Minimum Viable Product such a powerful idea?
- There is less upfront investment required.
Being able to deliver a product to real users without high upfront resource and system cost can often make the difference between being able to release a product and not! Where there is a low budget, creating a minimum viable product may be the only way you can deliver to real users.
- You get fast feedback!
By releasing a working product to test you get real feedback from real users. This enables you (and them) to learn how they actually use the product rather than how you think it will be used or the capabilities discussed during requirements gathering. This is super valuable. You will also get hands-on experience from the activities required to deploy and run your product and may notice something which hadn’t been considered before.
- It will help maintain momentum in your project.
When developers have their work used by real users and they get real feedback on it, it is very satisfying and motivating. Similarly, from the users perspective, being able to use a new product quickly and have a visible impact on the direction of the product is rewarding for the users and they will have renewed buy-in in the product.
- You can check the business viability of the entire solution.
The purpose of Minimum Viable Product is to test business viability. It means we are able to validate what we are delivering. Is the product what we need? Does it deliver what we hoped it would? Will it solve their problem? Is it fit for purpose? How does it need to evolve? If we don’t do this business validation, we risk investing a lot of time and effort in a solution which may not satisfy the business need.
- You can confirm (or reject) your hypothesis of the most important features to the user.
Real experience will inform your understanding of which features are really critical to users and therefore which features should get maximum focus during UX design and testing.
- It gives you a better understanding of the product compared to spending more time on upfront design.
Spending time on product design is important of course, but no matter how detailed the design is, it is never possible to think of every user scenario at the design stage. You will be able to make better decisions about your product based on real world feedback and your understanding of how the product actually functions, compared to more thorough design and how you imagine your product will function. This helps greatly when planning future development work on your product, giving you much more confidence when designing and estimating enhancements.
7. You can evolve your product over time to achieve a better end product.
Delivering a product to a set of users and getting feedback enables you to change and evolve the product design based on your experience of building and running it.
- It is easier to spot features which are NOT required.
During the requirements gathering phase, lots of product features / ideas will inevitably come up (“Wouldn’t it be nice if…”, “How about we build something which can…”, etc.). It can be hard to get to the bottom of which features are mandatory and which ones are nice to have. We may end up over-engineering the solution and delivering things which aren’t really needed by the client or won’t add much value. By delivering an MVP quickly, both the project team and the users have got a much better foundation on which to decide which features are actually necessary in future iterations of release. Needless to say, the smaller, simpler, and less dependent the product is, the less development, testing, documenting, handover, deployment and maintenance is required.
- You can validate the root cause of a perceived issue.
You may identify that something (which has previously been considered a problem), isn’t actually a problem which needs addressing. For example, perhaps the previous consensus was that a particular feature needs to be rewritten in X language (e.g. moved off mainframe), the MVP will give you the opportunity to validate the real root cause of this issue.
- Batch sizes will be smaller, and you can deploy more frequently.
Delivering a smaller (lighter) product will enable you to make more frequent deployments as there are fewer moving parts. This aligns with reducing batch sizes allowing an iterative approach to product delivery, in line with DevOps principles.
- Enable a culture of continual learning and improvement.
Following the MVP approach encourages a culture of experimentation and therefore learning for the whole team. This will result in better employee engagement, improved skills and ultimately better business outcomes.
- Increased job satisfaction.
There are few things more motivating for a developer than seeing your hard efforts quickly rewarded with real users using your product and gaining value from it.
From reading the long list above, you may start to think that adopting the minimum viable product approach will solve all your problems! But this isn’t completely true.
Here are a few things you should bear in mind to ensure the MVP approach works for you:
- The scope of the MVP needs to be such that is enables you to assess the business viability of the product. If the product has too few features or poor UX and users do not use it, then it does not serve the purpose of the MVP.
- Make sure you consider the product end goal when choosing the technology and architecture solutions. Otherwise you may get to the point where you cannot iteratively deliver the features required without redesigning part of your system.
- Receiving feedback on the product and evolving the product needs to be seen as an expected part of the project delivery and planned for accordingly. If no further changes are made to the MVP, then it is just a product, not a minimum viable product!
- If your system does not utilise deploy and release automation, or if you are not able to use consistent, available environments you may find that the cost of release is quite high. In this scenario, multiple iterative releases (as required for an MVP) may result in high costs and overheads, reducing the value of smaller batch sizes.
- If your product does not pass the business viability check, you should abandon the project. This means the effort spent on this MVP will not result in any business value. However, you may have saved yourself the effort of building and delivering the full solution before coming to the conclusion that this product is not useful.
Overall there are many ways in which an MVP approach can be beneficial for you and your business, however it is not a magic bullet. I suggest you take each scenario on a case by case basis and find what works for your project.
I hope that seeing your project objectives through the lens of the MVP approach will give you an alternative perspective and help you to find more ways of delivering quick wins for your project. Good luck!
Bronwyn Davies
Latest posts by Bronwyn Davies (see all)
- Winner! Unicom Most Innovative Project 2023 - 27th February 2023
- Sandhata Gini – Our internal chatbot - 1st February 2023
- Goodbye 2022 - 19th December 2022