Notes and Extracts on the concept of an MVP, Minimum Viable Product adopted more broadly in business.
Minimum Viable Product – MVP
The Minimum Viable Product, MVP, is a popular agile concept that is hard to pin down to a single definition, it can be used in many contexts and scenarios, it may not be a tangible product, but it does deliver something of value, whether to the developer or the customer, and not just financial value.
The concept helps to identify and scope the minimum viable solution that can initially prove and later deliver the benefits required to achieve a viable and valuable solution.
How can we gain the maximum value, with the least amount of effort, quickly, so we can get a working solution out there and test our idea!
A key point is this is not a Minimum Product, it’s a Minimum VIABLE Product. A key component of an MVP is that while it is Minimal it is also Viable. The definition of viable is dependant on what you are aiming to achieve, validate, prove, provide by way of a solution to a problem. It may be a smoke and mirrors mirage of a working solution, it may only exist for a short space of time, it may not be viable to scale, it may not do a lot of things, but it does the Minimum needed to viably deliver what it is we are trying to achieve, whether that’s delivering a working product, or just proving that its worth building and people want it.
An MVP is not a cheaper or diluted version of the final product it is a representation of it either in whole or in part that delivers value or represents the tangible activity or solution in some way.
Principles:
Eric Ries talks about MVP’s in his book Lean Start Up, as a way of testing out your hypothesis for your business. Creating something tangible that can be tested for feedback to establish if the customer actually wants the product, and will engage with it. Real world testing, even if its a smoke and mirrors product, for example a website that looks automated, but initially backend processing is managed manually. A MVP may or may not be sustainable, but often an MVP can serve a purpose without having to over-engineer the solution.
Rather than try to do everything an agile approach is to look at what the minimum viable product might be so that a relatively small amount of work can be undertaken that can then be reviewed and improved upon.
The ideal early MVP is able to showcase and test the solution without doing a lot of work so that the concept can be tested and proven before further resource and cost is committed. The MVP should validate if it provides a better solution that the current alternative and will be an attractive and viable option.
This concept can be used to test ideas and as an ongoing approach to developing solutions, the benefit of using an MVP approach throughout development is that time and resources are retained to allow for staged development which allows the scope to change. By delivering value early it also means that a return may be gained much earlier in the development cycle which can be reinvested into additional time and resources for further development.
We develop a slice of our solution and run sprints of work. We release our work in progress often for feedback and testing, so that we can learn, improve and refine our offering.
A Minimum Viable Product helps to learn more about the scenario and identify whether a particular approach or solution is worthwhile and should be developed further, or not. It’s a great way to test your ideas at the start and validate any assumptions you might have and verify information provided on which you are making decisions.
Early on when a goal or a solution is identified that we have little or no experience of, early learning is a key action to finding the best approach as fast and as efficiently as possible. An MVP approach helps to reduce the risk associated by validating and testing assumptions, value and expectations. At this stage the MVP is purely a representation of the final solution that can be tested to validate the concept and the value it could deliver. By creating a Minimum Viable Product tests can be carried out to identify if the chosen option is the best choice and if amendments need to be made.
Agile provides a framework to act and learn fast whether initial concepts and ideas are the right and best thing to progress. Early MVPs provide an opportunity to find out more about the environment and inform our future actions and decisions. The MVP will help to understand which elements of the solution are of the highest value and which are less important.
By creating an early representation of the solution and releasing it as an MVP, feedback can be gathered that informs decision making in the next stage of development and improvement. An MVP may take a number of forms; it could be a part of the solution or a representation of the solution.
Often what is thought to be the best option may have unexpected outcomes or consequences when tried, testing and trialling early can help to identify these and make changes to remove or mitigate the risks identified.
The concept of an MVP builds on the ideals of continuous delivery and feedback where the definition of the MVP can be repeated to establish the next batch of activity.
By using the initial MVP to record early performance metrics we can validate and revise our scope and estimations for how long a solution may take and how much resource is needed and establish early improvements to processes and methods.
Minimum Viable Products enable:
The concept of an MVP can be used in many ways and in various contexts when planning and developing new ideas for growth and improvement.
3 contexts in which the approach of a Minimum Valuable Proposition can be used are:
Using a test driven approach to solutions development, the minimum viable product is a representation of the solution to be delivered that will test the assumed or proposed value and provide an insight into whether the solution will fulfil needs and is an attractive proposition.
An Minimum Viable Product is different to a prototype as typically this is created before the solution has been developed. The MVP tests should help to define what the initial solution will include and what value it will deliver.
The objective of a Minimum Viable Product is to gain feedback and deliver some value early that can be measured to see if it is attractive and meets needs. The MVP at this stage may not be scalable, for example the MVP may be quite clunky or time consuming to undertake but it is shared with a limited volume.
In tech and innovation solutions are often new, different and an alternative option to the norm. Normal gap analysis and research of trends or statistics may not provide the validation needed. Agile development tests a minimum viable solution early with customer to gain real world feedback.
Our customers may not be aware our solution exists, or know its a viable option. In order to be sure our solution is viable we need to test early and observe behaviour to establish whether it is viable.
During a series of programmes supporting start up businesses to adopt agile approaches to develop their ideas, we coined the phrase ‘Wizard of Oz’ testing, when explaining the concept of Minimum Viable Product.
To the customer (Dorothy and her friends) it appears that the Wizard is a magical, great and powerful Wizard! But soon its revealed that behind the wizard, and the curtain is just a man.
This is a great example of how we can use ‘smoke and mirrors’ to give our users and customer the impression they are experiencing the full solution online, but in fact there is a lot of manual handling going on behind the scenes.
We used this tactic to test an automated service, but initially the work was completed manually. When it was clear enough users wanted the feature the work was completed to automate it. The initial solution wasn’t viable to scale or maintain, but it was viable to validate the solution was wanted enough to justify the investment to build and automate the solution.
There is a story told to me that I have often recited about using MVP to validate a market.
Often a business might decide to sell a product, get that product into stock and then market and sell the product. But if there is no demand for the product then the business is left with stock they cannot shift unless they discount it in some way.
Two colleagues wanted to start a business together. They had identified through keyword research that there was a high demand for the phrases rocking horses and parrot cages.
Rather than trusting the data at face value, they took an agile approach to validating whether these search volumes would correlate to sales.
Initially they set up test adverts for Parrot Cages and Rocking Horses to test click through rate.
They then set up landing pages to test types of parrot cages and rocking horses, and which would get click throughs.
They then set up a shopping cart to see if users would add to their carts
They then set up check out to see if users would complete the purchase.
At the end of the test they ordered a container load of parrot cages, but no rocking horses.
The tests had shown that clients would purchase the parrot cages but not the rocking horses.
Both gained click throughs, but only one generated sales.
Perhaps due to the different nature of the products, toy versus pet cage, the market status, the cost, health and safety, or other customer drivers, emotional or rational decision points.
A good example of using Wizard of Oz testing to validate a business idea and product selection.
I met a great team who had received funding to develop a prototype of a new piece of recycling equipment, a large bench with various functions. A brilliant innovation. I was introducing agile to them and we were discussing the process of new product development and the concept of MVPs and iterative development and test driven development.
The team had hit a big issue that upon testing of the bench at the end of the project. A foot pedal had been flagged as a crush hazard and that had caused knock on effects to the design of the bench. Not identifying the issue until so late in the project meant the change was proving challenging and costly, financially as well as in time.
If the team had taken a more agile approach and included key testing earlier on in the project this hazard would likely have been identified sooner, at much less cost and disruption to the development process.
If we test things early and they fail we can change them easily, if we wait and delay, then they become harder and more costly to fix. When we are building things for the first time there will be unknowns, and there will be learning, so when we do learn, we do so in the sense of ”Failing Forward Fast”!
Another team I worked with required an environmental building certification before their completed products could be used. The certification can only be completed once the product is on site and ready for use. Products are customised and so it was proving difficult to ensure that products passed the certification process.
The team adopted the idea of MVP, how could they use this to help achieve a better pass rate of certification for their products. They also considered what the Pareto was – what was the 20% that would give them 80% of the value.
The initial idea was to become certified to undertake the surveys themselves but this was too big and costly an option. The solution they decided on was one of the team undertook basic training for the certification, this gave them the knowledge they needed to understand how and why the certification was completed, without the cost or time involved in a full certification.
They spent time learning about the survey and the certification process, and used this to inform product development in the design stages of the project. This meant they could test much earlier in the product development process against the environmental certification, and ensure they were considering and including best practice to both ensure their product passed first time, and also to improve the sustainability and reduce the environmental impact of their products too.
Including environmental improvements early in the design phase was far easier and cost effective than considering them later in the process, or making changes later on when the product was on site, and so this made it more viable for the business to improve their product and reduce its environmental impact, as well as making delivery of the product run more smoothly.
A quick and simple way to solve a problem is to look for small options that can quickly mitigate the impact of a problem or improve an existing process by identifying simple changes. This is especially useful for improving workflows and processes and systems in the short term that have become inefficient or ineffective. In this context the MVP works to remove some of the friction or issues that are related to the problem to be solved by implementing small valuable changes.
The change works to reduce the impact of the problem and work with current solutions looking for minor changes that can improve the situation immediately. These changes may be an interim solution or may prove to be a permanent solution.
Often when a solution is scoped there are more features and options identified than there is time and resource to complete. A key aim of agile is to deliver a solution that takes the optimum approach to delivering a solution that is fit for purpose and satisfies needs enough to be a viable solution for adoption.
20% of the effort, produces 80% of the value
What 20% of activities, and 20% of resources can deliver 80% of the value?
If we use the Pareto Principle we would look for the 20% of the solution that will deliver 80% of the value.
Vilfredo Pareto was an Italian economist who noted the 80/20 correlation in 1896. He showed that 80% of the land in Italy was owned by 20% of the population. There is also a story that he observed 20% of the Pea plants in his allotment produced 80% of the Pea harvest. This is certainly true of the Black Current bushes in my garden!
The MVP solution would be the first release of the solution that would be usable and deliver value, with the use of continuous improvement and delivery to develop, maintain and improve the solution further.
The Minimum viable solution is not just all the must have actions, just because something is an essential must have doesn’t mean it has to be actioned first.
We can use planning and prioritisation tools such as complexity, sizing, importance, urgency, to inform our decisions on what elements our MVP may include. You can use the canvas combined with these tools to help identify your MVP. Agile Planning Guide – Estimation & Prioritisation
A new library requires system training on lending books but time available for this is limited. On the first week the team need to know how to lend out books and receive them back. Since books are loaned for 1 week the team don’t need to know how to deal with overdue books and related fines until the 8th day when the first books lent are due to expire.
In this library example the MVP would be to train the team on lending and receiving books initially, while training for overdue books can be provided the following week when there is more time available for further training.
Developing an MVP is a great way to test out an option to gauge feedback on whether it is viable and should be persevered, or whether we should pivot and explore alternative options instead.
This is a photo from a New York park during the pandemic, where social distancing was in place. In the park they have used an innovative quick and simple idea of painting socially distanced circles for their visitors. This is a quick, easy and viable solution to the challenge of enforcing social distancing in the park.
Consider your current work, projects, activities, goals, outcomes.
Consider what the final solution/outcome will look like?
Consider what a Minimum Viable solution and outcome might look like?
What is the 20% that will deliver the most value, the 80%?
This lesson contains Extracts from Being Agile in Business
Agile Manifesto 2.0 – Adapted – a small incremental improvement
Retrospective Sailing Game : Step by Step Guide, Video & Examples
Agile Estimation Games : Cup of Tea
