What is a Minimal Viable Product?
Although first coined by Frank Robinson, the term Minimal Viable Product has been popularised by Eric Ries in his work The Lean Startup Methodology.
In it, he describes:
“A core component of Lean Startup methodology is the build-measure-learn feedback loop. The first step is figuring out the problem that needs to be solved and then developing a minimum viable product (MVP) to begin the process of learning as quickly as possible.” – Eric Ries
Just so as we’re clear, I am not casting any votes for or against Mr Ries’ methodology, that’s not what this post is about. The important point here is the concept of the build-measure-learn feedback loop, because this implies that the MVP is designed to “get something of value out there”, see what happens, learn from it and then work out how to improve things, how to move on, how to adapt to take advantage of the market, how disrupt the market more, how to do whatever your strategy says you want to do.
Do it again (That’s the “loop” in build-measure-learn feedback loop). And again. And again. Each time adjusting to take advantage of current market conditions, customer needs, changing appetites.
He goes on to say that:
“Startups exist not to make stuff, make money, or serve customers. They exist to learn how to build a sustainable business.” – Eric Ries
And for a Startup, that’s important. Critical in fact. And that’s why it’s important to get to market quickly, with a valuable product or service.
Because you want your new customers to buy what you have on offer, so that you can do the measure and the learn and then crack on with the loop. And, you don’t want anyone else to barge in on your newly carved out piece of pie. Get your customers interested, hooked and wanting more.
There are plenty examples of companies who adopted this MVP approach: Twitter, Facebook, Amazon, Airbnb, Dropbox, Spotify to name a few. There are good write-ups of these companies, and more, available on line to those who are interested.
But what about non-startups?
What about companies whose change teams are developing business software applications for their own front-line staff.
Does an MVP approach work in that case?
Or a company rolling out a bespoke policy admin system to their own internal Operational staff. Does it make sense to use MVP for them? After all, the “market” doesn’t have a choice, the Operations department will use the policy admin system provided by the internal change team. Ain’t no choice.
The answer is “Yes” and “No”.
If you already know the totality of the product you want to deploy into, say, the Operations team (because it’s an “all or none”, fixed scope product, where there is no value in deploying elements of the product separately), then the answer is “No. No point.”
If however, you’re launching an product that your customers will use online, a business portal, for example, that will grow over time then the answer is “Yes, yes, yessington, yessy, yes.”
That doesn’t mean that the poor old Operations team never gets shiney new business applications deployed as part of an MVP. The point is that MVP works best when the product being rolled out is not a fully-conceived, fixed scope, one big lump of software. Even Back Office staff may require business applications, where functionality and scope can grow over time. And in these cases, MVP is quite the thing. Very de rigueur.
There are lots of definitions of MVP, but a good working definition, averaged out, and maybe dumbed-down, could be:
“The Minimal Viable Product (MVP) is a product which is launched with enough features to satisfy early adopters, and provide feedback for future development.”
or, slightly more harsh:
“The Minimal Viable Product (MVP) is a product with the simplest possible feature set which allows it to be deployed.”
But there is danger here. It is very easy to fall into the trap of thinking you are deploying an MVP, whereas in fact you are deploying an unhealthy, paired-down, reduced value product.
Because during the initial planning and brain-storming sessions (let’s be methodology agnostic here), there is a collective feeling of wanting to promise the world.
- The Sponsors get excited because their customers are going to love it,
- The developers get excited because they’ll be using new technologies and gizmos
- The change team gets excited because they’re going to espouse Scaled Agile Framework (SAFe)
- The Executive gets excited because this is bang on strategy
- The Marketeers get excited because they can target the next Expo for launch
- Everyone gets excited.
At the end of the session, the project team goes away and works out plans, provisional costs, dependencies, resource requirements, the benefit model, the business case, the cost benefit analysis (CBA).
To hit the Expo date – which by the way has now been announced as the launch date (too cynical?) – It will cost a quidzillion dollars, require all the development teams to drop all other work, and will blow the business case over a 3 year period, up the risk and generally be too challenging to contemplate.
What to do?
Reduce scope. Oops. Now we’re moving backwards. The MVP has now become
“The collection of features we can afford, because we can’t afford to do everything else.”
This is the danger, because it turns the MVP into a budget capping tool, rather than a description of an innovative, calculated feature set designed to “get value out there quickly”, and provide a basis for continuous improvement using the build-measure-learn feedback loop.
I know many people who don’t like the concept of MVP at all, and that’s all cool and dandy.
What I’m saying is that you should aim to deploy well-conceived, value-add, meaningful products and services from the outset – whatever you like to call it.