What an MVP really is (and what it isn't)

Overview

In the introduction you saw the result of a well-designed MVP —a fixed recommendations table that costs 10% of the full engine and tests the same assumption—, but you haven't yet seen the precise definition of what turns it into a real MVP and not simply "something small and cheap". This lesson closes that gap: an MVP isn't defined by its size or its cost. It's defined by three conditions at once, and if it's missing even one, no matter how small it is, it isn't an MVP —it's something else, with a different name—.

The three conditions are: (1) it explicitly declares which assumption it's testing —not "let's see what happens", but a concrete sentence that can turn out to be false—; (2) it measures real behavior from real people, not a stated opinion about what they'd say they would do; and (3) it costs a small fraction of building the full bet. A candidate that meets all three is an MVP. A candidate that meets only one or two, no matter how fashionable the word "MVP" is in the meeting where it was proposed, is not.

How this connects to the module. The introduction showed you compareApproaches's arithmetic —effort and moment of evidence—; this lesson gives you the criterion for deciding, before calculating that arithmetic, whether the plan you're calling "mvp" actually is one. Without this lesson, it's easy to put anything cheap on the mvp side of the comparison and celebrate the low effortRatio, without having verified that cheap thing actually tests anything.

An analogy: the recipe's spoonful, not a different dish

You already used this image in the introduction: tasting a spoonful of the new recipe, with the same proportions, before cooking for 50. It's worth looking at it more carefully, because this lesson's exact definition comes from it.

Imagine three different ways of "testing" the recipe before Saturday:

1. You ask your partner whether they think the recipe will be liked, without cooking anything. It's cheap, it's fast, but you didn't test the recipe —you tested an opinion about a recipe nobody has tried yet—.
2. You cook two servings of a different, easier dish —plain rice, because you had the ingredients on hand— and decide that, if it turns out well, the original recipe will too. You cooked something real, but not the recipe you care about: you learned nothing about the new recipe's salt, acid, or cook time.
3. You cook two servings of the new recipe, with exactly the same proportions, and you taste them yourself before serving on Saturday.

Only the third is a real spoonful. The first is an opinion poll disguised as a test. The second is a real test, but of the wrong recipe. The correct MVP is always the third: something real, of the bet you actually care about, at the smallest scale that makes it cheap.

Worked example: isRealMVP, three candidates for Mercado's checkout

Mercado's team has three different proposals, each called "MVP" by whoever proposed it, to test whether simplifying checkout to 3 steps moves conversion before rebuilding the whole flow (fullEffort: 30 person-days for the fully redesigned checkout). Let's build a checker that applies the three conditions to each one:

// isRealMVP checks three conditions at once: that it declares an explicit
// assumption, that it measures real behavior (not just opinion), and that
// it is cheap compared to building everything. All three at once, not just
// one -- that is the lesson's point.
function isRealMVP(candidate, fullEffort) {
  const effortShare = Math.round((candidate.effort / fullEffort) * 100);
  const cheapEnough = effortShare <= 50;
  const passes = candidate.statesAssumption && candidate.measuresRealBehavior && cheapEnough;
  const reasons = [];
  if (!candidate.statesAssumption) reasons.push('does not declare an explicit assumption');
  if (!candidate.measuresRealBehavior) reasons.push('measures opinion, not real behavior');
  if (!cheapEnough) reasons.push('costs almost the same as building everything (' + effortShare + '% of the full effort)');
  return {
    name: candidate.name,
    effortShare,
    isRealMVP: passes,
    verdict: passes ? 'is a real MVP' : 'is NOT a real MVP: ' + reasons.join('; '),
  };
}

const fullEffort = 30; // build the entire new checkout, with visual redesign

const candidates = [
  {
    name: 'Full checkout, just without dark mode or animations',
    effort: 27,
    statesAssumption: false,
    measuresRealBehavior: true,
  },
  {
    name: 'Buyer survey: would you simplify checkout to 3 steps?',
    effort: 1,
    statesAssumption: true,
    measuresRealBehavior: false,
  },
  {
    name: 'Simplified 3-step checkout, active for 10% of real traffic, no saved card',
    effort: 6,
    statesAssumption: true,
    measuresRealBehavior: true,
  },
];

console.log("=== isRealMVP: three candidates for Mercado's checkout ===\n");
candidates.forEach((c) => {
  const r = isRealMVP(c, fullEffort);
  console.log('"' + r.name + '"');
  console.log('  effortShare: ' + r.effortShare + '%');
  console.log('  ' + r.verdict + '\n');
});

What to expect. When you run the file with Node, the output is exactly this:

=== isRealMVP: three candidates for Mercado's checkout ===

"Full checkout, just without dark mode or animations"
  effortShare: 90%
  is NOT a real MVP: does not declare an explicit assumption; costs almost the same as building everything (90% of the full effort)

"Buyer survey: would you simplify checkout to 3 steps?"
  effortShare: 3%
  is NOT a real MVP: measures opinion, not real behavior

"Simplified 3-step checkout, active for 10% of real traffic, no saved card"
  effortShare: 20%
  is a real MVP

The three results teach something different. The first candidate is the most common mistake of all: someone stripped two cosmetic details from the full checkout and called it "MVP", but it still costs 90% of the total effort and, worse still, nobody declared what assumption it's supposed to test —it's, literally, v1 with fewer features, with no hypothesis behind it—. The second candidate is cheap (effortShare: 3%) and does declare an assumption, but fails the second criterion: asking people whether they believe simplifying would help isn't the same as observing whether, put in front of the real 3-step checkout, they complete more purchases. It's the spoonful analogy's first trap: an opinion about the recipe, not the recipe.

The third candidate is the only one that passes all three tests: it declares the assumption ("a 3-step checkout increases conversion"), measures real behavior (real buyers, with real money, on 10% of traffic), and costs a fifth of building everything. Notice something important: it isn't the cheapest of the three —the survey costs less—. Cheap isn't the criterion; cheap and also real and also with an explicit hypothesis, is. All three conditions are necessary together; none is enough on its own.

Why the real-behavior condition matters so much

It's worth pausing on the survey trap, because it's subtle and shows up all the time in teams with genuinely good intentions. Eric Ries sums it up with a sentence worth memorizing: people are bad at predicting their own future behavior, especially when the question is hypothetical and answering it has no real cost. A buyer can honestly say "yes, I'd prefer a simpler checkout" and, put in front of it for real, behave exactly as they always have —or the opposite—. The only way to know is to observe what people do, not what they say they would do. That's why measuresRealBehavior is a condition separate from statesAssumption: you can have an excellent hypothesis and still design an experiment that only measures opinions about it.

Common mistakes

The "MVP" that's actually v1 with trimmed features and no hypothesis. What happens: as you saw with the first candidate, someone takes the full plan, strips a couple of non-essential details (dark mode, the animations), and presents it as "the MVP" —when it's actually almost the same effort, with no declared assumption—. Why it happens: trimming visible features feels like "doing less", even though the real cost and the lack of a question to answer haven't changed. How to spot it: ask "what specific assumption does this plan test that the full plan wouldn't test just as well?" —if the answer is "none, it's literally the same but simpler", it isn't an MVP—. How to fix it: demand isRealMVP's three conditions before accepting the name. If the effortShare is above 50% or there's no explicit assumption, call it what it is: a trimmed v1, not an MVP.

Confusing asking with testing. What happens: the team designs a survey, a focus group, or an interview, and treats it as if it were the experiment that validates the bet —as in the second candidate—. Why it happens: talking to users feels rigorous and user-centered, and it is —but it answers a different question ("what do they think?") than the one you need answered ("what would they do?")—. How to spot it: the "MVP" plan includes nobody using, buying, or interacting with anything real; it only includes someone answering questions. How to fix it: opinions are a valuable input —in fact, understanding why people do what they do is exactly product-discovery-and-prototyping-guide's job—, but they don't replace an MVP. An MVP always includes a real action, even a tiny one: a click, a purchase, a signup.

Thinking anything cheap counts, without verifying it tests the SAME assumption you care about. What happens: the team builds something very small and fast, celebrates its low cost, but on closer look it tests a different question than the one that originally worried them —the plain-rice dish from the analogy, not the new recipe's spoonful—. How to spot it: ask "if this goes well, what exactly can I conclude about the original assumption?" —if the answer requires a big logical leap ("well, if they liked A, they'd probably like B too"), it isn't the same assumption—. How to fix it: before approving any plan as an MVP, write the risky assumption in one sentence, and verify that the proposed experiment, if it goes badly, directly refutes it —not something similar, the assumption itself—.

Exercises

Exercise 1 — Classify a fourth candidate. Mercado's team proposes, for the recommendations bet (fullEffort: 40): a "See recommendations for you" button in the cart, with no real backend behind it —no recommendation engine, not even a fixed table—, that just counts how many buyers click it, to measure whether interest exists before building anything (effort: 1, statesAssumption: true, measuresRealBehavior: true). Before running the code, decide whether isRealMVP would classify it as a real MVP. Then verify.

{
  name: 'See recommendations for you" button in the cart, no backend: just counts clicks to measure interest',
  effortShare: 3,
  isRealMVP: true,
  verdict: 'is a real MVP'
}

Exercise 2 — Defend with the analogy. A coworker insists the worked example's survey ("would you simplify checkout to 3 steps?") is a valid MVP, because "it's the cheapest of the three and we're asking users directly, what more rigor do you want?". Using the spoonful analogy, explain in 3-4 sentences why low cost and talking to users aren't enough.

Exercise 3 — Design your own candidate. For the Search filters by price range bet (improving search with price filters, from module 1's backlog), propose an MVP candidate that meets isRealMVP's three conditions. Describe: what assumption it declares, how it measures real behavior (not opinion), and why it's cheap compared to building the full filter system.

Summary and next step

In this lesson you learned the precise definition of an MVP: it isn't "v1 with fewer features", it's a plan that meets three conditions at once — it declares an explicit assumption, it measures real behavior (not opinion), and it costs a small fraction of building the full bet. You saw, with isRealMVP run over three candidates for Mercado's checkout, how a plan can fail for any of the three reasons —no hypothesis, measuring opinion instead of behavior, or simply costing almost the same as building everything— and how only the one that meets all three is a real MVP.

Before moving on you should be able to: name a real MVP's three conditions; explain, with the spoonful analogy, why a survey isn't an MVP; and classify a proposed plan using isRealMVP's logic.

Lesson 3 takes a specific piece of this definition and deepens it: when you trim a plan to make it cheaper, there are two different things you might be trimming —scope (how much you build) and learning (what you can conclude)—, and only the first is safe to trim without a cost.

Resources

• Eric Ries, The Lean Startup — theleanstartup.com. The origin of this lesson's three conditions: an MVP exists to maximize validated learning per unit of effort, not to minimize features. In English.
• Henrik Kniberg, "Making Sense of MVP" — blog.crisp.se/2016/01/25/henrikkniberg/making-sense-of-mvp. The skateboard-to-car drawing is, precisely, the visual argument against "v1 with fewer features" (which would be a wheel, or a quarter of a car). In English.
• Marty Cagan (Silicon Valley Product Group), "MVP" — svpg.com/articles. On the MVP as the fastest way to test a value or viability hypothesis, with minimal engineering effort. In English.