Is being just ‘viable’ still viable?

What comes to your mind when you hear MVP?
For some, it’s “a basic version just good enough to launch.”
For others its a “big product with tons of journey”

Let me share an incident: A client once walked us through their product vision, long-term strategy, and big picture plan. Then came the discussion on milestones — and of course, the first one on the list was the MVP. Everyone eagerly discussing about being focus and fast

For over a decade, the Minimum Viable Product (MVP) has been the go-to strategy for launching products. But over time, I’ve noticed the term is often misunderstood or misused.”

Misinterpretation in Practice

In software development, after “agile,” MVP is probably the most used (or misused) term during project initiations.

On the surface, it sounds simple: “build a basic version, give it to users, learn, and iterate.” And to be honest, that’s where our discussions also went. We focused on the goal, as we should have, and started brutally prioritizing features to achieve that first milestone.

Brutal Prioritization — Misunderstood Evil

The common issue with MVP is interpreting “minimum” as simply the smallest possible set of features you can technically deliver to the end users. With this, the focus shifts to speed and just the core feature. While this seems good it is often at the expense of equally important aspects like user experience, performance or not addressing the journey provided already available with competitors

In my case, this led to three side effects:

• Negative Perception: We released the core feature but deprioritized performance thinking it will not be a major issue as it was not too different from their alternate solution. But early users perceived the product as another slow product — which then became a tough mindset to change later and which led to the second side effect
• Shallow Feedback: User interviews revolved around performance gaps and missing features, instead of validating the core value proposition.
• Tech Debt: To win the race of quickly churning out MVP, decisions were made that built up into a significant backlog of technical debt.

Learnings for MVP

Looking back, three lessons stand out:

• It might be MVP for the company but Customers expect a polished first experience. A half-baked release might hurt trust and acceptance
• While focusing on core value proposition is good but equally essential is understanding expectations and the bare minimum journey
• Technical considerations (scalability, performance, reliability) can’t be ignored. Even if not fully built, they should be consciously planned and prioritized for the future release before it becomes a mammoth of a task to even think about

Rethinking MVP

Eric Ries defined Minimum Viable Product (MVP) as “version of a new product which allows a team to collect the maximum amount of validated learning about customers with the least effort.”

The goal wasn’t to ship something half-baked. It was to maximize learning, minimize waste, and reduce risk. I realize somewhere along the way in the excitement of creating a product this intent often gets lost.

As product people, our role is to guide businesses in finding this balance — defining what “minimum” really means for their users, their industry, and their context

So, How do you define “minimum viable” in your context today?

‍