30 November 2020

5 minutes read

Charles Mackay, a 19th century journalist called it ‘the Madness of Crowds’. In the 14th century dancing mania broke out across Europe (shown above). Groups of men, women and children would dance uncontrollably for hours or even days at a time for no apparent reason, only finishing when they succumbed to exhaustion. In 17th century Holland tulip mania broke out. Driven by manic investors the price of tulip bulbs spiralled upwards and then crashed. At one crazy point a particularly valuable tulip bulb cost the same amount as an elegant house in Amsterdam. In the 20th century we have seen many episodes of collective madness, from the anti-vaccine movement to the terrifyingly bonkers (and baseless) QAnon conspiracy theory. Throughout history humans have had a strange and inexplicable compulsion to follow the crowd, even when the crowd really shouldn’t be followed.

First seen in 2011, a new, potentially dangerous form of collective madness has been infecting development and product teams around the globe: MVP madness. Find out what MVP madness is, why it can be so damaging and how to stop it infecting you, and your team.

The madness begins

There can be many different reasons as to why a collective madness takes hold. Dancing mania in the 14th century might have been initially caused by contaminated food, or simply as a reaction to terrible hardships, such as the plague. The refusal of parents to allow their children to receive the MMR vaccine, even though it has been proven to be safe and effective can be traced back to a flawed and fraudulent medical study by Andrew Wakefield (who was subsequently struck off as a practising doctor).

MVP madness can be traced back to a book – the Lean Startup by Eric Ries. Promising to explain, “How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses”, the book introduced a lean startup methodology for building products and services. Having sold over a million copies, the book has become hugely influential and has helped shape the approach that many development and product teams take.

The Lean Startup book by Eric Ries

A core part of the lean startup methodology outlined within the book is the concept of an MVP, a minimum viable product. As described in the book:

“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.”

Eric Ries, Author of The Lean Startup

Even if you’re not familiar with this definition, you might have seen the popular MVP illustration shown below by Henrik Kniberg, an Agile and Lean coach.

MVP illustration by Henrik Kniberg, a Lean and Agile coach

If we’re helping our customers to get from A to B, in Henrik’s example, we start with a skateboard rather than just a wheel. This allows customers to get from A to B, even if it will take a lot of effort on their behalf and not necessarily be the best initial experience. Gradually we iterate based on learnings from customers. We move to a scooter, then a bicycle, a motor bike, before finally ending up with a gleaming sports car. Sounds great in theory doesn’t it? At each point we release something that allows us to collect the maximum learnings from our customers, with the least effort from us.

The problem is that this isn’t the approach that most teams take, and certainly not result they usually end up with. Rather than starting with a skateboard and ending up with delighted customers, cruising from A to B in their highly desirable sports car, we end up with something more like the monstrosity shown below: a Frankenstein monster of a product or service (Frankenstein was the creator in Mary Shelly’s book, not the monster).

An MVP approach can all too often result in a Frankenstein monster of a design like this

So, what’s going wrong? The problem is that teams infected with MVP madness, will blindly take an MVP approach, without the necessary know-how to do so. You see it turns out that whilst taking an MVP approach sounds easy, in reality it’s not. It’s really, really hard to get right.

MVP easy as one, two, three?

Remember Eric Ries’s definition for an 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.”

What Eric fails to mention are that there are some pretty big caveats. And when I say big, I mean BIG. As Eric acknowledges:

“Some caveats right off the bat. MVP, despite the name, is not about creating minimal products. If your goal is simply to scratch a clear itch or build something for a quick flip, you really don’t need the MVP.”

“Second, the definition’s use of the words maximum and minimum means it is decidedly not formulaic. It requires judgment to figure out, for any given context, what MVP makes sense.”

WTF! A minimal valuable product, is not about creating minimal products and what is minimum and maximum can vary widely in the first place.

What constitutes an MVP, will depend on the context, and what a team is trying to learn. An MVP, might not even be a product, it could be a prototype or an experiment. An MVP might not even be very minimal. If something minimal is not going to tell you what you want to learn from customers, then your MVP is going to need to be more like a sports car, than a skateboard. Confused yet?

When is an MVP, not an MVP?

Unsurprisingly individuals and teams struggle to understand what an MVP is, and isn’t. Three parts of the concept tend to be latched on to:

1. It should be minimal (nope).
2. It should be a working product or service (nope).
3. ‘Least effort’ allows us to do a half-arsed job (nope).

All 3 of these points are simply not true. All too often teams will ship a half-arsed minimal product, rather than an MVP. They will deliver a huge steaming turd of a product or service to their customers and justify doing so by calling it an MVP.

An MVP is not an MVP if it’s never iterated. An MVP is not an MVP if it’s so full of bugs and issues that all we learn is that customers hate buggy, and broken products and services. An MVP is not an MVP if it doesn’t delivery any value to customers.

So how can we end this collective MVP madness? We need to re-frame the MVP approach, and probably ditch the term ‘MVP’ altogether.

A better MVP approach

Death to ‘MVP’! Not the concept, but the term.

I completely agree with Henrik Kniberg (the Lean and Agile coach behind the skateboard to car sketch from earlier on) that the term ‘MVP’ sucks. It’s confusing and invariably misinterpreted. I suspect that if Eric Ries could jump in a flux capacitor equipped DeLorean and travel back in time, he’d probably choose a different term.

Rather than calling it an MVP, I’d suggest using Henrik’s preferred terminology. Start by calling it the ‘Earliest Testable Product’, then the ‘Earliest Usable Product’ and then the ‘Earliest Lovable Product’. This does a much better job of communicating the goals at each step of the approach and helps to build a better shared understanding within the team.

Earliest Testable Product > Earliest Usable Product > Earliest Lovable product by Henrik Kniberg

An MVP approach is really a hypothesis driven approach. Rather than thinking of your MVP as a product, it’s better to think of it as a learning exercise. You have a hypothesis, and your MVP / Earliest Testable Product is one way (but not the only way) to test that hypothesis.

Releasing a product into the hands of your customers is certainly not the only way to test a hypothesis. Carrying out user research sessions to evaluate mock-ups, concepts or prototypes with customers and running experiments, such as sign-up pages can be much more effective learning mechanisms.

Another potentially catastrophic error that teams frequently make is to build their products and services on the shaky foundations of their MVP. As Frederick Brooks Jr reminded us over 35 years ago in his seminal book, ‘The Mythical Man-Month’:

“In most projects, the first system built is barely usable. It may be too slow, too big, awkward to use, or all three. There is no alternative but to start again, smarting but smarter, and build a redesigned version in which these problems are solved. The discard and redesign may be done in one lump, or it may be done piece-by-piece. But all large-system experience shows that it will be done. Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time.”

Frederick Brooks Jr, The Mythical Man-Month

This is as true now, as it was when Frederick first wrote it in the 1970s. Like building a house on sand, building a product on an MVP, held together with string, sticky tape and enough product debt to sink the Titanic is never a good idea. Treat your MVP / Earliest Testable Product as a learning exercise and ditch the code once you’ve learnt enough to move forward.

Conclusion

MVP madness has infected thousands of individuals and teams across the globe. Rather than a vaccine, or wonder drug, the cure for this madness is simple: knowledge. Use your new-found knowledge to rid yourself and your team of this terrible infliction. Ditch the term ‘MVP’, along with any half-baked code once you’ve learnt enough and take the hypothesis driven approach that Eric Ries originally intended.

See also

Image credits