The great MVP swindle: From an end in itself to a means to an end in the definition of MVP

Hardly any other term has been overused in software development in recent years as much as “MVP.” The Minimum Viable Product is sometimes hailed as a savior, sometimes cursed, and is all too often exploited to argue for and against just about anything. Technical debt is taken on just as recklessly as testing is carried out only half-heartedly: “After all, it’s just an MVP for now.”

It’s time to clear the air, take a critical look at context and use cases, and provide more clarity. That’s why this article examines different types of MVPs. The goal is to better assess which MVP serves which purpose, in order to free it from its imposed status as an end in itself.

The great MVP swindle and why taking small steps can still help

“It’s just an MVP, after all.” That’s how it sounds when it’s supposed to be “minimal” yet still “viable.” It feels like every development project I’ve been involved in over the past few years has had an MVP as its goal, and only in the rarest of cases did everyone involved share the same understanding of what that might mean. And it is precisely this shared understanding that is essential when complex software products are to be designed, implemented, and operated within a team.

An MVP often becomes a canvas for personal goals and motives

Thus, precisely because of its vague definition, the MVP becomes a wonderful canvas for all sorts of personal goals and motives. Overzealous product owners brush aside quality concerns in order to get more features implemented. Teams are more willing to take on technical debt, figuring it can be paid off later. Stakeholders and management cut budgets, after all, it’s just an MVP for now.

By the time of launch, at the latest, reality sets in: a scope that’s somehow rather excessive, but with quality issues regarding security, scalability, and usability. Add to that a handful of questionable architectural decisions, and, due to the problems described, the project is all too quickly forgotten after launch or is accepted with a shrug as an inevitable stroke of bad luck under the ever-popular motto, “Software is just complicated.”

But is that really necessary? And wouldn’t a better shared understanding of what we’re trying to achieve, and what those three little letters actually stand for, have helped us move forward in a more focused and successful way? Probably so, and not least for this reason, we’ll now provide a definition of the term and some foundational analysis to get to the bottom of the misunderstandings and misinterpretations.

3 different definitions of MVP

The “MVP to Earn” definition

Let’s start right away with the meaning of our snazzy acronym:

• Minimum (as far as that’s actually clear)
• Viable (already a bit more complicated)
• Product (should be obvious, one would think)

The concept of “minimal” seems uncontroversial. The idea is to produce something small. However, the message often doesn’t get across. It’s not the budget or the effort that should be minimal, but the product itself.

And that’s not all. The term “viability” proves to be extremely ambiguous in translation. Some valid meanings of the word are:

• Feasible
• Useful
• Feasible
• Viable
• Capable of growth

A wide range of possible meanings. What exactly this might mean in our context, and how the term is defined, becomes clearer when we look at IDEO’s still-valid and insightful definition of the intersection of characteristics that make products successful:

• Desirability: What’s the unique value proposition? Do people want this product or service? Does it make sense for them?
• Viability: Can we build a sustainable business? What conditions must be met for this business to succeed? What are the costs? How will you pay for it?
• Feasibility: Does this work? Is it functionally possible in the foreseeable future?

Interpreted in this way, “viable” primarily stands for economic viability and thus for the business/organizational dimension within the equally popular and practical triangle of power dynamics in digital product development.

According to this interpretation, the MVP should therefore be capable of achieving economic success. This definition aligns with that of Frank Robinson, the father of the term “MVP,” who posited as early as the early 2000s:

Such an MVP can be successful in the market, but in the agile tradition from which Robinson hails, it is so well prioritized and stripped down to its essentials that, in fact, only the minimum functionality necessary to ensure this success has been implemented. Simply to avoid jeopardizing market success, it should also be clear in this context that it makes little sense to make excessive compromises on quality; rather, each of the product features that made it into the scope must be of high quality in its own right.

The first generation of iPhones focused on quality and speed

The best example of this strategy, which has sometimes been very successful, is the first iPhone. Supposed core features, such as copying and pasting text or the ability for users to install additional software, were deliberately omitted at launch in order to get the product to market faster.

However, no compromises were made in terms of quality regarding user guidance, user experience, scalability, performance, etc.

In my view, for any product development aimed at rapid market entry, this strategy remains the most successful to this day: narrow the scope, highlight a few standout features, and under no circumstances compromise on quality. This lays the groundwork for a successful market entry, at least from a product development perspective.

The “MVP to learn” definition

So far, so good. The only problem is that, in addition to Robinson’s definition, which is based on IDEO’s insights into successful products, there is a second definition that, while also focused on successful products, follows a completely different strategy. Ten years after Robinson, Eric Ries describes the MVP in his book “The Lean Startup” as:

So it’s not about revenue, but about learning and generating insights about your own product idea as quickly as possible. The methods for doing this are much more diverse than pure development, because the old adage holds true: the most expensive way to test an idea is to implement it. This way, initial assumptions can be tested using landing page MVPs to see if there’s even a target audience willing to pay.

Dropbox is testing the market potential before going live

The classic example in this area is Dropbox, which, long before the product was finished, began using its landing page to collect email addresses from potential customers in order to assess the market potential for itself.

For Ries, then, it’s less about viability (i.e., economic viability) and more about identifying ways to evaluate the product idea across all three dimensions (viability, feasibility, desirability) and thereby arrive at a more informed strategy.

Above all, this requires a sound approach to data and its reliability. Only those who define, collect, and analyze questions well and accurately will arrive at genuine insights. And sometimes a product idea doesn’t need a successful landing page test; it just needs a little patience to mature.

Nevertheless, “MVPs to learn” are ideally a series of small steps on the path to the first “MVP to earn.”

The “MVP to burn” definition

All it takes is clarity among everyone involved, whether team members or stakeholders, about which goals are currently being pursued and by what method. Otherwise, we’re not building “to learn” or “to earn,” but, as Rainer Sax so aptly remarked on the sidelines of the IA Conference in Berlin, “to burn.” And that’s certainly something we’d be better off avoiding. Or we can take a cue from Henrik Kniberg, who, in a reflection on his famous illustration of skateboards, cars, and bicycles, once wrote very beautifully:

Develop a shared definition before the project begins

As a practical tip, it can be helpful to have team members and stakeholders rank the goals associated with MVPs, for example, during a kickoff meeting or a scope-definition workshop, to clarify what kind of MVP should be built. This works just as well with sticky notes as it does with remote tools like Miro or Mural.

Conclusion

With a shared understanding and clear goals, product development will go smoothly. This also increases the likelihood that MVPs will serve a purpose rather than becoming an end in themselves, and thus a meaningless business ritual. With that in mind, have fun and good luck with your next MVP development!