Your MVP Failed. It May Not Have Refuted Your Idea.

What this solves for you: the moment your MVP's data comes back flat and the room is ready to kill the idea, this piece gives you one question that separates a real refutation from a false negative — so a death report that never tested the hypothesis doesn't get to kill it.

The claim: when an MVP dies, what got killed is often not your hypothesis — it's the mechanism you amputated while stripping the feature down. This kind of death has a name: a false negative. It's deadlier than a real failure, because it leaves you without a shred of doubt.

The limits: the judgment rests on one practitioner's recollection, years after the fact, of running growth at Duolingo. That's experience, not a controlled experiment. It doesn't prove that bigger prototypes are better, and it ships with no copiable mechanism checklist — every experiment's list has to be written fresh.

A Death Report for a Badge: Duolingo's Minimum-Version Experiment

Duolingo wanted badges early. Someone ran the numbers internally: a real badge system would take a serious investment, so the idea sat untouched. Then came the thrifty workaround — a minimum version. Every new user gets one badge the moment they sign up. Just to test the water.

The data came back flat. No effect.

From there, the lean startup script runs itself: tested it, no effect, kill it, move on. The team moved on for the next eight months or so and never looked back. After all — we let the data do the talking.

Years later, the person who ran growth at Duolingo in that era retold the story in an interview. The unflattering part came first: more than half of their A/B tests never showed an effect in the first place. Then came the detail that actually stings. The register-and-receive badge was built on a hypothesis — users care about achievement, want to collect, want to show off. And the minimum version carried none of the three:

The hypothesis and the experiment never met. Only when the team later added personal use and a mechanism that actually worked did the growth show up.

So the death report from back then may never have killed the badge. What it killed was a hypothesis that was never tested.

Does the scene look familiar? Swap in your own product and it holds just as well. Before the feature cuts, nobody writes down a single sentence: "What mechanism is this experiment supposed to test?" After the data flatlines, nobody asks: "Did we happen to delete the very thing we were testing?" The retrospective reviews the conclusion. Nobody ever reviews the cut.

MVP Never Meant This

In 2009, Eric Ries defined the MVP as the version of a product that lets a team "collect the maximum amount of validated learning about customers with the least effort." Afraid of being misread, he added, in the same post: "MVP, despite the name, is not about creating minimal products." And further down: deciding what the MVP actually is, in any concrete situation, "requires judgment."

Judgment of what? Of which cut is safe to make — and which one removes the mechanism you meant to test.

Seventeen years on, the word has drifted. "Least" survived the journey; "maximum learning" fell off the truck. It degenerated into a feature-cutting contest, where the more ruthlessly you cut, the leaner you are, and whatever scrap is left standing gets called an MVP.

"Minimum" governs the investment. It says nothing about what you're allowed to cut.

Shell and Engine: Every Hypothesis Has Two Layers

Every hypothesis has two layers: the shell, and the engine.

Cutting the shell first to save cost is perfectly sound engineering. The trouble starts because nobody wrote down "here is the mechanism this experiment tests" before the knife came out. So the knife never stops, and somewhere in the middle of the trim, the engine ends up on the chopping block too.

The badge-at-signup was a car with no engine, road-tested on the question "can this car drive?" Of course it couldn't. The whole world already knew that answer; no experiment needed to announce it.

That's the false negative: the experiment died, but your hypothesis isn't what died.

And here is exactly where the poison is. A real failure makes you doubt the idea — and doubt is the doorway learning walks through. A false negative hands you a professional-looking death report: there's data, there's a test cycle, there's a conclusion. Take that report and kill a hypothesis that might have been right, and you won't feel a flicker of doubt.

A real failure makes you doubt yourself. A false negative leaves you without any doubt at all. The first one forces you to learn. The second one closes the door on learning for you.

The Other Half of the Ledger: How Figma Slides Earned the Word "Trust"

There's a second account from the same body of research. I'm not setting it here as replicated evidence. It's a mirror.

Figma was building Slides, its presentation product. A demo thrown together in a one-week hackathon drew a hot reception inside the company. The feature comparison table drawn up against competitors had Figma's column green across the board — and the project still didn't get a green light. What moved it was weeks of user interviews: pain points, solutions, and evidence lined up in one column; the tradeoffs between what designers want and what non-designers want; even the corners the team itself wasn't sure about — all of it laid on the table. Only then did trust start to build. In the speaker's telling, Slides didn't even make the company's top three priorities at first. It had to earn "permission to explore" first, then a trial at the sales kickoff, and only then, five months later, the launch.

Notice what kind of material this is. It is not "mechanism deleted, false negative follows." It's the other half of the same story: a mechanism has to be sayable out loud, and its evidence has to survive being put on the table, before an experiment deserves to be trusted. And don't over-read this into "Slides was validated a success." The speaker gave no retention numbers and no revenue numbers.

Set the two accounts side by side and they point at one move: before you place the bet, spell out "what mechanism am I testing." Spelling it out is the precondition for cutting features — not the cleanup after the failure.

The MVP Failed. Don't Rush to Pivot. Three Moves.

One. Before you cut, write one sentence: "What mechanism does this experiment test?" If the sentence won't come, the hypothesis isn't clear yet — and every cut you make from that state is the wrong cut.

Two. After you cut, audit every cut. Did it remove shell — the badge's visual styling and interface presentation? Or did it remove engine — the behavioral mechanism this experiment is meant to test? If achievement, collection, and display are the mechanism under test, they cannot be cut as decoration. Shell can be simplified. The mechanism under test must stay. Cutting the engine doesn't save cost; it saves you the experiment's eligibility to conclude anything.

Three. After the failure, file the report into one of three drawers:

Never take a false-negative report and use it to kill a sound idea.

When This Method Stops Working

Three cases, stated up front.

First, it stands on one practitioner's recollection years later — experience, not a controlled experiment. Change the product, change the audience, and "achievement, collection, display" may not be the engine anymore. The mechanism list has to be rewritten for every experiment. There is nothing to copy.

Second, when a full experiment costs more than you can pay, cutting the engine may not be a mistake — it may be budget reality. Even then, the report must be filed as "insufficient signal." Don't let it circulate through the company wearing the label "idea disproved."

Third — and this matters — this is not a permit for people who refuse to cut anything. Ries said maximum learning "with the least effort." What you economize on is spending unrelated to the test. Stripping the shell clean and keeping only the engine is the advanced move in this craft. And nothing here argues that bigger prototypes are better; where "big" gets big and where it gets expensive is a separate ledger.

Next retrospective, someone projects that downward curve onto the screen and the room goes quiet. Before anyone asks "so, is the idea any good?", ask the other question first:

"Of everything we deleted — was one of those things the engine?"

What got refuted usually isn't your idea. It's your cutting.

A word on where I'm standing while I say all this. I'm Uncle J — eighteen years in HR, which is where I learned that most verdicts go wrong not because the person failed, but because nobody checked what the evidence had actually tested. These days I run a one-person AI org, and my own experiments get held to the same discipline: the mechanism gets written down before anything gets cut.

One more boundary, said plainly: the three-way taxonomy governs how you file a failure. It does not govern the cut that happens before the filing. And the mechanism list has no template — a copied one counts as not written. This piece lives in Product Philosophy; the rest of the judgment calls and case ledgers in this line keep unrolling in the site's article stream. Related reading: The Experiment Won. So Why Didn't the Company?.

Sources and Caveats