The minimum viable product (MVP) comes with a maximum of confusion
Startups have taught us a thing or two about product development in recent years. Particularly the idea of the minimum viable product (MVP) has made a huge impact all the way to creative agencies, product development teams, and sometimes even top level management. The basic premise of the MVP is to launch the product as quickly as possible to get as much validation of the business hypothesis as possible while minimising risks and investments, as opposed to working endlessly on what might turn out to be the wrong product. Makes sense.
Add to that the advantage of launching a product or a feature before competitors do, which is just as important for corporate organisations as it is in the world of startups.
For these good reasons, the MVP approach resonates well with people who work with products across industries and professions. It’s become something that almost goes without saying: a seductive truism of modern day product development and as a result you’ll see people nodding reassuringly when someone on the team says, “Let’s focus on the MVP here”.
However, my experience is that ever since the oftentimes misconceived idea of the MVP entered our world of product development, it’s caused a lot of confusion and sometimes ends up being its own worst enemy. The aim of this post is to highlight some of these pitfalls in the hope that being aware of them is the first step to avoid them.
When corporate organisations try to go MVP
An essential part of the MVP approach is to start a learning cycle, where the product team continuously builds, learns and measures. This is a very important assumption that needs to be in place if the MVP approach is going to work.
In essence, the MVP approach is a framework built for startups with limited funding and much to lose and it’s defined by Eric Ries, author of the Lean Startup as:
The product with just the necessary features to get money and feedback from early adopters. The minimum viable product (MVP) is often an ad on Google. Or a PowerPoint slide. Or a dialog box. Or a landing page. You can often build it in a day or a week.
But this is not how most large corporate organisations work. Like it or not, a lot of corporate organisations work in waterfalls with upfront feature specs, fully-fledged design and harsh deadlines. Also known as building a spaceship.
What often happens in these situations is that the spaceship is heavily reduced when the deadline approaches and a flawed product goes live with no budget for further iterations, or for establishing a learning cycle. Or alternatively it’s implemented in phases where the first launch happens to be whatever happened to be finished by the deadline. Both of which are also known as pissing the team off. If this is the case, sprinkling some half-baked MVP on top of that process won’t get you anywhere. On the contrary, it might give a false sense of control when essentially the entire organisationsal structure and product development processes are what need to be adjusted.
The challenge of defining what goes into the minimum experience
Most organisations have some pretty fierce internal battles. Department X has different agendas and even KPIs than department Y. Or in the same department, different people will have different ideas about what is important. For most designers this is a common experience when it comes to screen prioritisation exercises, where everyone wants their piece of the canvas (above the fold and all that). But it’s equally well known when it comes to defining what goes into the definition of the minimum viable product of for instance a corporate product redesign, or when designing a new product from scratch.
Most people working in product development are ambitious and want to create good experiences and it’s more than tempting to extend the scope to include this or that extra functionality in order to create something that cuts the mustard. Often referred to as feature creep or scope creep in agile software development circles.
In the book “Lean UX”, which you should buy and read if you’re interested in these things, Jeff Gothelf and Josh Seiden set up some practical guidelines for creating MVPs. The most important one in my view is the one about keeping your MVP on a fidelity level that justifies the amount of truthful learning you expect to derive from it. Or in other words: get early feedback using prototypes to make sure that you’re building the right thing.
In this perspective, the MVP is not so much about the product that launches, but more about experimenting and prototyping your way into a meaningful product experience. Having personally been involved in numerous projects over the years that were officially defined as “MVP projects,” but in reality took more than a year (or even more) to develop, mainly due to the mechanisms I described above, I think this definition provides a very valuable approach.
What needs to be in place though are clear measurable objectives and KPIs and a clear definition of viability, which of course depends on the business plan.
Should you aim for a minimum experience or a ❤️ loveable experience?
The MVP perspective on product development has been somewhat rightfully criticised for focusing too much on bare-bone functionality instead of focusing on creating products that users will love, which is the reason why the debate about minimum lovable products (MLP) exists.
Personally I like that perspective because it shifts the focus from simple hypothesis testing towards creating loveable experiences, which is why most of us as product designers go to work in the first place, and which is very often what customers and users are used to when using modern software and therefore might expect from your product too. One could argue that it has the same shortcomings as the minimum viable product, but where the MVP aims to test whether or not users could have a potential interest in the idea on a prototype level, the MLP is defined as:
The version of a new product that brings back the maximum amount of love from your early tribe members with the least effort.
This can be tested in a pretty cool way using the Kano model, which turns backlog prioritisation into something more than a product manager’s (or a team’s) gut feeling. As a supplement to the Kano model, Google and Digital Telepathy have provided a very tangible framework that will help you get started asking the right questions.
Is the MVP necessarily the right thing for you?
Like I mentioned in the beginning MVP is becoming a truism of modern product development. It’s used and referred to in confusing ways probably thousands of times a day, and due to its seductive no-nonsense nature, it just sounds right.
But it’s worth considering whether your team (or the client you’re working for) will be able to establish a continuous cycle for building, measuring and learning, and whether or not you’re able to define rich and measurable objectives and KPIs about the expected loveability or viability of the product you’re building. Depending on your business case you would probably want those to be both quantitative and qualitative.
If you’re working on a project that is defined as an MVP (or MLP for that matter) but none of these conditions are met, something might be quite wrong. In that case I hope that this article has provided you with some ideas on how to move forward.
Thanks to my good colleagues for great discussions on the subject and specific feedback on the article.
And thanks for reading. If you want to, feel free to follow me on twitter and to read more about ux design on my blog.
