Lately everyone’s trying to fix or replace the concept of MVP (minimum viable product) in Agile software development, but MVP ain’t broke, and doesn’t need fixing.
For anyone who’s forgotten, here’s Eric Ries’ definition of MVP: “the minimum viable product is that version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”
Sounds like a reasonable basis on which to start some real iteration, yes? Turns out people have a bunch of problems with this idea – most of which are terrible reasons to shy away from an MVP. I’m not saying every initiative needs to start with an MVP, just that the most common anti-MVP arguments don’t really make the case. Here are the ones I keep running into:
“An MVP won’t delight our customers. What we need is a Minimum Loveable Product!” The concern is that an MVP is going to be so awful that it permanently harms your brand. I hope we can agree that any product that bad is unviable and shouldn’t be released.
Ries makes it clear that there’s wiggle room in his concept of “minimum viability”. You should adapt it to your specific circumstances, so long as you accept the basic goal: something that’s going to give you meaningful customer feedback – not necessarily delighting customers, but not driving them away.
If you’re still worried about disappointing your customers, in many cases you can recruit customer surrogates. Got some staff who have no involvement with your project but might use the end-product? There’s your first batch of customers for the MVP.
You may be thinking “I don’t accept the basic goal of the MVP – I want to learn as much as I can about my customers up front, then put a lot of effort into getting the design of my product just right before they see the first version”. If so, you’re prioritising following a plan over responding to change (feedback), i.e. choosing waterfall over Agile.
Often you’ll hear arguments against MVP along the lines of “Best in market always beats first to market”. People will tell you that going to market with an incomplete product is simply begging for competitors to look at what you’ve produced and leapfrog you with an even better version.
If you’ve released an MVP and they haven’t, then you’ve got all the user analytics, you’ve got all the feedback, and you can release a better version in two weeks or less! Then another, and another, ad infinitum. If your competitor can leapfrog you while you’re sprinting down the road, I’m sorry, they’re just a better frog, and no amount of head-start will save you.
But what if you can’t release a new version in two weeks? What if it’ll take at-least four just to complete QA, and another four to plan and schedule the deployment? Best case of three months end-to-end for a new version? Welcome to the wonderful world of water-Agile-fall – it’s more fun than waterfall, but you’re probably not going to realise more than a tenth of the potential of Agile, and MVP isn’t a great idea for you.
RATs and Mice
The Riskiest Assumption Test is an excellent tool, and it’s something you can start doing long before you put an MVP in front of customers. Some of your riskiest assumptions can be things like “legacy system X can do the thing” – there’s no need to put something in front of customers to test that.
The problem I have with Higham’s article is that it gets hung up on the dictionary definition of “product” then comes up with a definition of MVP that is completely different from Ries’ definition, and decides that RAT is a better name for it than MVP, when really they’re two different concepts. To be perhaps overly reductive, the RAT is about testing known unknowns of any kind, whereas the MVP is about uncovering the unknown unknowns specific to customers’ interactions with your product. Both are valuable, and neither obsoletes the other.
Another article getting hung up on dictionary definitions specific to the author’s context suggests that MVP should mean “something that makes profit”. But again, that completely ignores Ries’ definition. By all means, come up with your own term that is useful in your context, but it doesn’t help anyone to try to redefine an existing term – all it does is muddy the waters around both ideas and make it more difficult for them to cut through in the marketplace of ideas.
Perhaps the words Minimum Viable Product don’t perfectly match Ries’ definition of the term, but ultimately MVP is just the marketing headline; it’s Ries’ definition that makes it a useful concept. You might as well argue that chocolate bar manufacturers rebrand “Fun Size” bars as “Disappointment Size” in order to be more literally correct.
Lastly, there are the people who will use any of the arguments above and more besides to justify why, although they’re supportive of the MVP, their role in particular must be excepted so they can perform the requisite weeks or months of design that will make the MVP a success.
Put another way, they’re saying “I define my role by the ability to perform up-front design, and to find the right solution before users ever see the product – if we’re just going to follow analytics and feedback, doesn’t that make my role obsolete?” It does not, but it does substantially change the role. Analytics and feedback tell you how people are getting on with your product, but nothing about what to do next. Design is still necessary, but instead of happening in a big chunk at the start, it needs to happen a little at a time, taking on feedback, and iterating.
If that sounds a lot like what developers do in Agile delivery, it’s no accident. You can think of MVP as a way of saying that you’re doing Agile right from the start, and across all disciplines, rather than water-Agile-fall.
In Agile, people need to let go of the idea that they’re near-infallible experts who can know all the details of a product before a single line of code is written. Instead they need to work on a small part at a time and constantly re-ask “Is this right? How could it be better?” It can be a scary change to go through, but it needs to happen if you want to make Agile succeed in your organisation.