There are different kinds of MVPs: it all depends on the context

The Minimum Viable Product (MVP) is the first truly usable version of the product you’re building. Of course, this version will evolve over time based on user feedback, sometimes even pivoting radically, but that doesn’t change the fact that this version must be genuinely useful and usable. By this I mean that people will be able to use your app to accomplish tasks (a Job To Be Done) that they couldn’t do before, or couldn’t do as well, and that these people will be willing to pay for it. The goal of the MVP is therefore to acquire your first paying users.

To clear up this point, let’s remember that an MVP is not a PoC (Proof of Concept): a PoC aims to answer a specific question, whether marketing- or technical-related. It’s cobbled together with duct tape, often just simple mockups, and ends up in the trash once it’s served its purpose. In contrast, the MVP lays the foundations of your product, the technical foundation upon which you’ll build and iterate going forward. This is the paradox of the MVP: although it’s minimal from a functional standpoint, it’s maximal from a technical standpoint, as your primary focus must be on minimizing technical debt.

In my experience, these definitions are a source of numerous disputes. One reason for this is that the MVP retains an experimental aspect: you’re seeking the elusive Product-Market Fit; nothing is guaranteed, and it’s likely that you’ll have to adapt significantly, or perhaps even abandon that idea you thought was so good. The MVP therefore remains an experiment, but one that’s in production (at some point, you have to take the plunge), quantitative (the numbers will have the final say), and one that you’ve “de-risked” as much as possible: the various PoCs you conducted beforehand were designed to increase the likelihood that your MVP would immediately find its market.

But if the MVP sparks so much debate, it’s also because it leads to very different outcomes. As is often the case, it all depends on the context: if you’re creating a new market, your product should be able to attract users even with few features, since no one else is offering those features. If, on the other hand, you’re entering an existing market, your goal will be to outperform all the established players, that is, to do everything they already do and more, or do it better. You’ll therefore need to convince users to switch to you even though the competing service they’re currently using works just fine. Oh, sure, that service has its flaws, but over time users have adapted to it, so switching, even to a better service, comes at a cost. In other words, your service has to be significantly better, and likely closer to the concept of a Minimum Lovable Product. And that quickly adds up to millions of euros…

An example is worth a thousand words: in the 1960s, when the first ATMs appeared, they only allowed very limited transactions, for example, a single withdrawal of $25, a fixed amount. At the time, it was either that or standing in line at a teller window, so the perceived value was significant. In 2025, if you were considering such a service, it would be difficult to offer anything less than the exact choice of denominations, for example, €250 = 5 × €50 rather than €250 = €200 + €50 (a classic algorithm that minimizes the number of bills). Well, personally, I’d also ask you for a solution that lets me avoid touching that disgusting screen, which is bound to give me some disease that hasn’t even been identified yet, or a way to withdraw exactly the €8.80 my butcher asks for, since he doesn’t accept card payments under €10…

But the real question in 2025 would be whether such a service even makes sense, given the trend toward phasing out cash in favor of payment cards (to combat fraud, money laundering, and terrorist financing). So perhaps you should conduct a PoC first and foremost. That’s right 😊

If you feel the need to clarify the concepts of PoC, Walking Skeleton, MVP, MLP, and perhaps more broadly to revisit the fundamentals of Agile, my “Agile with a Hammer” training course is for you!