MVP: Misunderstood Vision for Product

Somewhere along the way, “minimum viable product” stopped being a meaningful concept and drifted into product lore. It’s a term everyone knows and yet almost no one can define the same way. Saeed Khan went so far as to argue the term (and other Product terms) has lost so much shared meaning it’s worth retiring. This misunderstanding usually results in one of two major failure modes:

1. Asking “what’s the least we can spend to get something out the door?”
2. Gold-plating everything so that when (if!) you finally ask someone to buy it, there’s no possible objection

Pavel Samsonov recently wrote about the first of these, arguing that once it’s ‘viable enough,’ teams treat that as an excuse to stop. Permission to cut features, cut quality, and ship the cheapest thing you can still call a product. This is a symptom of a larger sickness in business that sees revenue as fixed and looks for a way to get it more cheaply. It’s very common in established businesses where momentum, structural advantages, brand, etc. are providing enough lift that they start to extract more profit simply by cutting expenses (and corners).

But real business is about solving jobs for your customers such that they are happy to pay you for the solution. Treating “minimum” as “let’s do the least” is missing the point of creating the product in the first place. The goal is to find customers, and that means solving a job for them, which means that understanding and fully accomplishing their goal is the point.

What it was supposed to mean

Which brings me to how I’d define MVP: the smallest thing you can build right now that solves at least one real job for a core group of users so well that they’ll pay for it.

One real job, not a vague pile of features. A core group of early adopters whose need is sharp enough that the value is obvious to them on day one. (I’ve benefited a lot on this topic from Ash Maurya’s lean canvas which includes explaining the unique value proposition and discovering the early adopters) And willing to pay, which is the part everyone wants to skip, because paying is the only signal you can’t fake.

That last part is where a lot of MVPs fall apart – and again, this is why misunderstanding “minimum” sells you short. People will tell you they love it. They’ll fill out the survey, clap at the demo, add it to a wishlist. None of that is the same as pulling out a credit card. I talked last week about The Red Carpet, our app with a real million-dollar prize behind it. People’s eyes would light up when they heard about it. Then they’d find out the app cost three dollars, and a remarkable number of them said the same thing: “Oh, I never pay for apps.” Attention is not demand. The only way to tell them apart is to put something in front of people that they can buy, or not.

A start, not a finish

But there’s another way to misunderstand “minimum” as well. The MVP is not the product. It’s the ticket that earns you the right to build the product.

If it works, you’re not done. You’ve got the one thing you couldn’t get any other way: real customers, paying real money, showing you with their behavior where to go next. That’s the start of the work, not the end of it. The iteration, the pivots, the experiments that grow a narrow early win into something a lot of people want, all of that begins after you launch.

That cuts against how most businesses are built to think. We’re trained to describe a business in costs, revenue, and margins. But the real measure of a business is what its customers think of it, which comes down to how well it solves the jobs they actually have. Lose sight of that and MVP collapses into what it is today: lower the cost, maximize the revenue, ship it soon. The easiest way to do all three at once is to cut features and quality, so that’s what teams do.

The opposite mistake

Stripping the product past the bone is one way to get this wrong. The opposite is just as common, and just as fatal: never shipping at all.

This is the team that wants every feature built before launch, that won’t go live until nobody could look at the product and say “but what about…” It feels responsible. It’s the more dangerous road.

For one, you rarely build anything innovative that way. Jobs-to-be-done is about an orthogonal attack: solving someone’s real job more completely by coming at it from a different direction entirely. Set out to eliminate every objection before launch and you slowly optimize yourself into a slightly different version of what already exists, because the safest way to silence an objection is to look like the thing people already accept. The interesting products live in the objections you’re willing to leave standing for now.

The bigger problem is simpler. The longer you wait to put something real in front of real people, the longer you go without knowing whether they want it at all. The perfectionist and the bargain-hunter fail for the same reason: both avoid the only thing scary enough to be useful, which is letting a customer tell you no with their wallet. You can burn a year and a fortune building the wrong thing because you couldn’t stand to ship early enough to hear it.

The better question

So when someone asks “what’s the least we can ship,” hand them a better question instead: what’s the one thing our customers would happily throw money at if we could only solve it really well?

An MVP isn’t the cheapest thing you can get out the door, and it isn’t the most complete thing you can stall on. It’s the first honest conversation you get to have with the market, the moment you stop guessing and start learning from people with skin in the game. Treat it as the finish line and you’ll either ship something nobody wants or spend forever avoiding the answer. Treat it as the starting line, and you’ve earned the right to build the rest.