Minimum Viable or Market Viable? Why MVP is just the start.
When Eric Ries coined the term ‘Minimum Viable Product’ in his book, The Lean Startup, in 2011, he described it as:
‘that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.’
The MVP is an agile construct. Focused on ‘validated learning’, it is based on the idea that the final outcome will have been shaped by real customer feedback. The ‘finished’ product is always one that has been iterated and improved, once it’s been tested with real users.
Invest less, learn more
MVP development has, in the past, been favoured by start-ups. They are the ones – with big ideas and little budgets – that need to be able to build something quickly and cheaply, to prove a model before too much money is spent. The MVP makes for a much safer investment by testing ideas with a small budget, before you make a larger outlay.
But designing and building an MVP is the first phase (or one of the initial phases) in a product’s lifecycle. It’s a springboard for constant innovation and continuous learning. The aim should always be to develop the product, continually, throughout its lifetime.
Test, learn, iterate and improve. De-risk innovation and investment.
So the MVP can only ever be the beginning of a journey. It’s about getting started with something tangible, to gather information quickly, because you value consumer reactions.
This must mean that you build an MVP with an open mind – without a clear picture of what the end product will be. You might know what phase one of your product will look like, but until you validate that version with your audience, you cannot be certain of what comes next.
Minimum Viable or Market Viable?
Over time, the meaning changed. MVP is now often short-hand for ‘the smallest thing you can build that lets you quickly make it around the build/measure/learn loop’.
It has become – for some – simply the quickest, cheapest, easiest way to take a product to market. But that’s wrong. Because businesses that believe that a project ends with an MVP, undermine the entire concept of Minimum Viable.
For example, if someone asks to build an MVP that is scalable and works across multiple platforms, what they really want is to create a sub-standard, ‘just-about-finished-product’, using the least amount of effort and resource.
There are no plans for iteration and, if market feedback is gathered, it’s just a tick in a box. User response is used to corroborate a product that has already been fully conceived. This completely contradicts what it means to be Agile.
So at CAF, we’re reclaiming the MVP.
Certainly an MVP should be viable. It must function well enough to test with real users and gather effective insight. Even at first iteration, the MVP should be a piece of working software that meets customer requirements.
But the MVP must be an early stage in a long phase of product delivery, that will first be tested with the market and then shaped accordingly. Here at CAF we call this Market Viable.
Our MVPs are not about creating something that is ‘just enough’ to get by. We create, shape and build MVPs that are fully functioning and are always tested with real users. They might be ready for use, but they will always be iterated and improved on.
These MVPs are not flimsy. Or partial. Untested or undersigned.
Those who already work in agile understand this. They know that building an MVP is just the start of any successful digital journey. Since agile development has always been about testing, learning and improving. It helps stakeholders understand what works and what doesn’t, so they can invest in the right products moving forward.
That is what the MVP is all about. Lest we ignore its heritage; at CAF we’ve complied our own manifesto…
The CAF MVP manifesto
Make your commitment to agile methodologies, live and believe in the MVP manifesto.
1. The MVP is not cheap mobile app development
2. It is not a partial product
3. The MVP is something I can test to prove there is an appetite for my idea
4. It is unlikely to have an extensive feature set or work across different platforms
5. But each component will be fully functioning, fully designed and bug free
6. It will be tested with real users
7. I must be prepared to listen to the market!
8. The MVP will always evolve according to user feedback