How often do you evaluate the tools that served you well in the past but maybe are not the ones that you should use anymore? I had one of these moments in the past weeks when I started to think about minimal viable products (MVP).

I am not really sure who was the first one talking about and introducing the term MVP, to me it is something that has always been there as a framework that every product person should have in their toolbox. To me the MVP has been for many years the quintessential agile mindset: get something out of the door fast, keep the scope down, use the time constraint to really get stakeholders on board on what *needs* to be there, and then ship it. And learn as fast as you can.

I could see two really great benefits of the framework:

having some constraints (in time) forces you to understand what really needs to be in place to validate your hypothesis
getting the product faster to market will cut your learning time

Both things are extremely valuable for keeping development costs low, and de-risking product development.

I used the term and concept of MVP for years, I even crusaded for it, to actually get something out of the door faster. MVP served me well, yet lately, I started to really question my darling.

Why you might ask.

It is mainly because I am not sure anymore that if our aim is to validate the hypothesis and derisk development, the answer should be the MVP. Additionally many times I have seen the MVP used to create half-optimal products, that are then left out in the wild, with no extra iterations on them. Creating not learnings, but bad experiences for many users.

We do an MVP, we get it out, and then we focus on something else. Seen that? I did, many times, and I am not sure that that is the type of product development we should encourage. The MVP has a real chance at succeeding only in companies that are truly committed to working on multiple iterations of the same thing. Or if we ship something that really solves a problem from the start. This should really be what the framework is about, but I do not see it applied in real life very often. This is why I now question it and wonder: what are we building when we build MVPs?

What are we building when we use the term MVP?

If you are not ashamed, you shipped too late, or?

As the product craft is evolving, and users are more and more used to digital products, what I started to wonder is how much an MVP can really answer your questions. One example that kicked off my thoughts is personalization. I have been recently talking with product leaders in my networks, and listening to podcasts around it, and one common red thread that everyone highlights is that you need to be surgical at personalization, as the cost of getting it wrong is quite high.

Let me give you an example of what I mean.

Let’s imagine we work in a product team at Spotify. And we are in a parallel world, where our journey with personalized music has not started yet, but we see it as a big opportunity and want to give it a shot. Imagine us starting to explore that opportunity by creating an MVP where we get some signals from what you listened to, we know it is not ideal, but we believe we need to get our product in front of the users to get the answer we need, and we optimize for time to market instead of working further with adding extra elements to the MVP.

The most likely scenario is that most people, used to advanced personalization in other products, will either get upset because we didn’t really get what they like quite right and/or not click on those songs at all. If that is the case, what can we learn from our hypothetical MVP?

Can we say that users are not interested in personalization or we would most likely say that we need to invest more in the product to validate the opportunity? And what are the risks of getting this first version out, will the user ignore the content the second time as they got burned the first?

This hypothetical case is an example of how the MVP doesn’t really serve its purpose. And shipping a product that you were ashamed of, served neither you nor the users. In other words - optimizing for time to market using the way you know to do that (MVP) put you into a trap. If you add to the picture that many times MVPs are shipped and then left, the situation doesn’t become brighter.

I started to really think about the two parts at stake here: getting feedback early at the cost of a hacky experience or getting the product right, with a bigger upfront investment and at the cost of go-to-market. Or in other words, how can you get feedback from the users fast, de-risk your development, and get a solid product out there?

Balancing value delivery and time to market

I think the core of my questioning of the MVP is that I believe there are other and better ways of de-risking development.

To validate your assumption you can use continuous discovery
To get feedback on solutions there are qualitative interviews, prototypes, smoke tests, and many more tools

The real value of the MVP might lie in those use cases where you really have to ship something to see the full effect of it. But even then, I think that the product community should take responsibility for the experiences it creates and shift the focus toward the concept of minimum lovable products.

To me, the MLP is a product that can stand on its legs, even if you need to abandon it because company priorities demand so. It really solves a problem and creates value for a subset of users, it can become better (for those users or for others) by iterating on it, but is solid.

The MLP is created for a smaller audience, following the idea of an atomic network and it might not have an impact on product metrics as a first version could, but it is a more sustainable way of developing. And if you feel that you cannot deliver that first MLP with the prerequisite you have at this point, maybe you should question if you should be building something at all. Or try to make your investment case clear, and create the time you need to deliver the experience you want to your users.

So in short, please think twice next time you are evaluating building an MVP. Here are some questions to guide you:

Are there any other ways to get answers to the questions I have that do not require building an MVP?
If not and I decide to build - Is the product that I am building solving a real problem for at least a subset of users and could be left in its form?
If not, do I have the commitment to be able to iterate on it until it is in a stable phase?
If not, should I really invest your time and energy in building it? Or what do I need to do to get the investment needed?

Let’s build together better products, and not cut corners at the cost of our users.