MVP: when “launching fast” is confused with not working properly
The concept of the MVP (Minimum Viable Product) has been part of the startup ecosystem’s everyday vocabulary for years. The problem is not the concept itself—which is sound and useful—but how it is being interpreted and, above all, how it is being applied.
I very often see confusion and a worrying lack of methodology around what an MVP should actually be. And this is not a minor issue, because it ends up trivialising what a startup is—or should be.
“A startup is an early-stage company that aims to solve a real problem in a better, faster, more efficient way, or by delivering greater value than existing solutions.”
A startup is not a permanent experiment without discipline; it is a company in its early stages.
Speeding up the launch does not mean skipping the groundwork
One thing is to accelerate the launch of an MVP and put it quickly in the hands of potential customers. A very different thing is to do so by skipping the entire prior analysis phase, which is both necessary and irreplaceable.
Before building anything, it is essential to understand:
- What solutions exist today.
- Which needs are truly being met and which are not.
- Whether the pain points we believe we have identified actually exist.
- How the sector works: its dynamics, its players, its inertia, and its friction points.
This is not about running endless studies or falling into analysis paralysis. It is about applying the minimum level of rigour required to avoid building on fragile—or outright false—assumptions.
Launching an MVP without understanding the context is like designing a product blindfolded and trusting that “we’ll fix it later”.
Beware of the “we must launch the MVP now” mantra
The message of “we need to launch now” has almost become a dogma. And like any dogma, when applied without judgement, it can do more harm than good.
There are countless examples of MVPs that were launched when the market did not demand—and, above all, did not value—the solution being offered. In these cases, the problem is not that the product was imperfect; it is that the proposed value did not align with the target’s real priorities.
This is where the “startup hooligans” usually appear with their catch-all argument:
“We launch it and then we pivot.”
Of course an MVP then enters an iterative process: refining features, interface, experience, and, naturally, a solid value proposition. That is exactly what it is for. What we should not normalise, however, is launching MVPs that are doomed to fail from day one, when a brief preliminary analysis phase would have surfaced very clear insights.
“We should pivot on something that already represents a solution to a specific pain point, never on something that delivers no value at all. That knowledge should have been reached in a less costly way than building a prototype.”
When someone launches an MVP that later has to be thrown away because it is not aligned with the benefits sought by their target, that is not being dynamic. It is failing to work in a methodical and rigorous way.
“Methodical and rigorous” does not mean slow or bureaucratic. It has absolutely nothing to do with that.
A very common example: B2B is not just a checkout
Let me give a real example, one I have seen more than once.
A company wanted to transform a traditional sector with a B2B sales model based on personal relationships into a pure, no-frills ecommerce model. The hypothesis was simple: digitise the purchasing process, make it faster, and remove intermediaries.
The MVP was built, and technically the ecommerce worked. The problem was something else: the target did not want that.
A well-planned on-the-ground investigation—interviews, direct observation, analysis of the real purchasing process—would have made it possible to identify very quickly that the value in that sector did not lie in an apparently simpler digital process. The value was in:
- Advice from a real expert.
- Service personalisation.
- Real-world product testing.
- Incident and issue management.
- Trust built over time.
An ecommerce could not solve any of that. Not because the technology was bad, but because the problem it was trying to solve was not the right one.
That learning arrived… after building the MVP. A valid learning, yes, but also a costly one in terms of time and money. And one that was perfectly avoidable.
Less epic narrative, more company
Perhaps it is time to abandon—if anyone still holds on to it—that romantic view of startups as a synonym for youth, joviality, and “we’ll pivot later”. That narrative often serves to mask something far more uncomfortable: a lack of rigorous work.
An MVP does not replace a working model. It does not replace analysis, market understanding, or deep knowledge of the customer. An MVP serves to validate how a target audience interacts with a solution that addresses a real, current problem, to gather feedback, and to learn.
Working fast is a virtue. Working fast without method is not. In a startup—let us not forget—we are building a company. Even if it is still incipient.
