Much has been written about Minimum Viable Product (MVP) and I have to say it was quite revolutionary when it has first proposed. For those who don’t know it, MVP is a principle that says we should build the minimum amount of product that allows us to get in front of customers and get feedback. Feedback gives us data that we can use to make decisions about continuing or killing a project.
At the time it came out MVP gave credibility to the emerging world of the Agile & Lean movements partly because it got mixed up with the “Fail Fast” mantra. Maybe they are so similar they can be counted as the same but in practice MVP can end up being a very expensive technique, very far from fail fast or fail cheap.
I can tell you that many of the Business folks with whom I interact hate MVP. It’s seen as a bad compromise. It’s usually the minimum work that IT will do for their business colleagues before the resources are whisked off somewhere else.
Most people in the Agile world that I talk to report the same problem. Haydn also relates to it having had business-side clients who insist that there is no scope for minimum anything to go in front of customers. Business leaders want IT to put the best efforts on the line not something that falls short. Minimum is the finished item.
In these environments the letters MVP could usefully be replaced by a term we were all familiar with before – the “prototype”.
But more problematic is the issue of compromises that cost time and money and leave people with a sense of failure.
Product owners can feel short-changed with MVP. Therefore, it should come as no surprise that they stuff their product specifications with all the bells & whistles they believe are needed to bring the product alive and this defeats the objective of MVP.
The Customer feedback loop becomes elongated rather than shortened and the Test & Learn phase is almost bypassed.
So has MVP become too big? Is it now the new Waterfall? Or is it at least taking us back to Waterfall-like practices such as over-specification and long build times?
MVP is certainly much better than the previous worst of “Waterfall” when we spent an inordinate amount of time building something that could fail at some distant point in the future.
The idea that we can test a minimum set of product features and then continue working on the product, assuming that there is interest from customers, is very useful. It allows us to avoid planning too far into the future and, if properly implemented, let’s us pivot early.
New product development v continuous innovation
However, there is an additional problem. Today, the chances are we will be working on multiple strands of innovation simultaneously in a continuous flow of invention and development leading to continuous delivery and feedback.
This is quite different from building a new product, service or platform as a startup – the initial domain of MVP. We are not building out entirely new products for a non-existing customer base that we somehow have to discover. We have a customer base, we are attracting new customers all the time, and we need a variety of strategies for on-boarding them, expanding sales and reducing churn.
Inserting an MVP into this process can create the downward spiral I have just referred to. In its place we need to think that maybe we will be hypothesising a raft of new features and we have somehow to find a way to sequence these so that we can be making decisions regularly about the ones that are working and more importantly the ones that are delivering disproportionally more value.
You have probably heard of the Pareto Principle or the 80/20 rule. In Lean software development this translates into 80% of the value comes from 20% of the features. So the quicker you can deliver those features, the quicker you earn the value.
In FLOW, we are obsessed with delivering customer value at pace and delivering it incrementally. The smaller the better. And this lends itself nicely to microservices.
Hence we came up with the term Minimum Sustainable Delivery. MSD is the point at which you can start to measure customer value. And with MSD there is some extra magic. The first 20% of features are super valuable. They are what deliver 80% of the total value and therefore they are the ones you need to get into the delivery system first. These are gold and can help you determine quite quickly if your product is a dog or dynamite.
Think of it like this. Your product has 100 features. Each feature should be created as small as possible, sometimes with just a few lines of code.
In fact, my team calls it the Minimum Viable Feature and you can read all about that concept in Haydn’s forthcoming article called “The Most Important Techniques in Process Innovation – Keeping it Fluid”.
The principle Haydn covers in that article is how to socialise the granular detail of new projects so that you really can hypothesise fairly, which features are going to create value and you can get those into the system to test your hypothesis.
Each feature is delivered live to production as soon as it’s built via your continuous delivery pipeline created through your DevOps capability.
Of course, the first few features can’t be switched to “live” until enough of them are delivered, so that they can be assembled into something meaningful.
Once that happens, let’s say for argument’s sake after 5 or 6 are created, you can switch on the MSD and start measuring the value. This could be in terms of A/B tests, visitors, contact form clicks, traction for a cross-sell, and the usual stuff of a Test & Learn culture.
If the value starts to wane, you could stop building and pivot quickly to a new set of alternative features or go to an enhanced feature-set to see how that performs. Or indeed you could just kill the product idea completely and move onto another product development project.
The benefits of MSD
I guess that the MSD technique could actually complement MVP and perhaps make it more powerful. But what’s even more powerful for me is that idea came from the continuous improvement mantra of FLOW.
One of my teams used a retrospective session (post product delivery) to try and understand why their product had taken so long to build and why it had failed. If they had found out earlier that there was going to be no customer interest, they could have pivoted more quickly.
They had also created a whole heap of new infrastructure and defined the ultimate in terms of architecture to sustain their new feature-set, using resources that could have been better deployed elsewhere.
People often don’t realise that in an existing product family with an existing customer base there is often still a need to add to infrastructure to help new features play out live. Until we are fully migrated to microservices, that will continue to be the case so with an MVP it’s possible to create the following stack of downsides:
● Over-specified product caused by internal mismatch in understanding, expectations and resource transparency.
● Long build times and elongated time to customer-feedback.
● Wasted infrastructure build without knowing whether a product will be successful or not.
● Lost opportunity because you miss the critical pivot-points.
All that is why I’m a big fan of evolutionary architecture or architecture delivered at the last possible moment of commit.
Which reminds me of my recent visit to the European Parliament in Brussels where I provided some guidance for their FinTech think-tank team who are working on creating regulatory sandboxes for startups to test their products before having to comply with the complex rules of the world of Financial Services.
This is an environment whereby MSD will flourish if of course you also get the all-important social interaction right.
Anyway, the essential ingredients for adopting the MSD type of thinking/philosophy are contained in our book FLOW and watch out, because the pace at which you receive customer feedback with FLOW can be quite exhilarating and demand an even greater degree of adaptability!
You can get a copy of our book by clicking on this link