Minimum Valuable Product

Rethinking MVP: Why 'Valuable' Beats 'Viable' Every Time

May 19, 2025 · Product · 6 min read

Minimum Valuable Product

I have sat through a lot of MVP demos. Most of them work. The login works, the dashboard loads, the happy path is happy. And somewhere around the third screen, you can feel the real verdict forming in the room: nothing is broken, and nobody here would use this tomorrow.

The founder did everything the playbook asked. Built small, shipped fast, kept scope tight. The product is viable in every sense of the word. And that is exactly the problem.

Where MVP Actually Came From

The history is worth getting right, because almost everyone gets it wrong - including the version of me who first told this story.

Frank Robinson coined “Minimum Viable Product” in 2001, years before the lean movement made it gospel. His definition was sharper than the one that survived: the MVP is the right-sized product - “big enough to cause adoption, satisfaction and sales, but not so big as to be bloated and risky.” Notice the words. Adoption. Satisfaction. Sales. Robinson’s MVP was never an apology - it was a product customers actually wanted, kept deliberately small.

Steve Blank and Eric Ries later popularized the term, and Ries gave it the definition most of us can recite from memory: the version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.

Both definitions are useful. But somewhere between 2001 and today, the word that stuck was viable - and the products that word produces are the ones I keep watching in demo rooms.

I plead guilty to my part in this. I have over-used the following image more times than I can count when working with entrepreneurs.

MVP diagram

What “Viable” Quietly Optimizes For

Ask what “viable” actually means and the answer is: can this thing survive? It’s the question you ask about a houseplant in winter. Pure existence.

Look at who that question serves. Is it technically feasible for us to build? Can we make money from it? Will our stakeholders be satisfied? Every one of those questions points inward. Not one of them mentions the person the product is supposedly for.

That inward pull explains the apologetic half-products. Teams hit their own definition of viable - it runs, it’s sound, it might even bill - and ship something users have no reason to care about. When CB Insights ran its post-mortem of failed startups, the most common cause of death wasn’t technology or cash. It was no market need: 42%. Nearly half of those products were viable. Nobody was waiting for them.

Viable asks whether the product can survive. Valuable asks whether anyone will care that it exists.

The One-Word Correction

Ash Maurya - the author of Running Lean and Scaling Lean, and the creator of the Lean Canvas - has been making this correction explicitly. In his words:

“An MVP (Minimum Valuable Product) is about nailing your UVP (Unique Value Proposition) with the smallest possible solution. Where ‘valuable’ isn’t limited to viability but also addresses desirability, feasibility, and other non-negotiable x-factors critical to your mission, vision, and values.”

The swap looks cosmetic. It isn’t. Say “valuable” and you cannot avoid the next question: valuable to whom? The sentence physically refuses to stay company-centric. “Will this work?” becomes “Will this matter?” “Can we build it?” becomes “Should we build it?”

And in a strange way, the correction brings MVP back to what Robinson meant in 2001. Adoption, satisfaction, sales - those were always measures of value delivered to someone else.

What This Looks Like When It Works

The classic example is Zappos. In 1999, Nick Swinmurn walked into local shoe stores, photographed the inventory, posted the photos online, and bought each pair at retail when an order came in. As an operation it was barely viable - no inventory, no margins, no scale. As a test of value it was perfect: will people buy shoes they cannot try on? They would. Everything else came later.

My favorite example is closer to home. M-Pesa was not the most technically viable payments product of its era - it ran on SMS and USSD, on cheap phones, in a market the banking industry had written off. But it answered a question millions of people were already asking: how do I send money home, today, safely? It nailed value on infrastructure everyone else considered beneath them, and it became the reference point for mobile money worldwide.

The pattern in both: value first, viability engineered afterward, in service of the value.

The Honest Reckoning

The swap is not free, and I won’t pretend it is.

“Valuable” is harder to measure than “viable.” Viability has dashboards - uptime, unit costs, runway. Value hides in whether someone changes their behavior for you, and that signal is slow, qualitative, and easy to self-deceive about.

The word can also become a hiding place. I have seen founders polish “value” for months as a respectable excuse not to ship. Robinson’s minimum still carries half the weight: a valuable product you never released teaches you exactly nothing.

And viability still matters - just not first. A product people love but that bleeds money on every transaction dies too, only with better reviews. The order of operations is the point: start with value, then work backward to viability. Not the reverse.

One more thing has changed since 2001: building is no longer the hard part. AI-assisted development has made “viable” almost free - a working product is now a weekend, not a year. Which means viability has stopped being a filter at all. The only test left standing is whether what you built matters to someone.

Three Letters, One Question

The acronym is not going anywhere. What those letters expand to in your head is yours to choose.

So the next time you scope a first version, try the swap and see what it does to your roadmap. Not “what is the least we can ship that survives?” but “what is the smallest thing someone would genuinely miss if we took it away?”

I keep asking founders that second question in demo rooms. The ones who can answer it never have to apologize for what’s on the screen.