Minimum Viable Experiment vs. MVP: Know the Difference

An MVE (minimum viable experiment) tests one assumption — will people click, sign up, pay, or show up — using the smallest, cheapest artifact that produces a real signal. An MVP (minimum viable product) is a working product built to deliver your full value proposition to real users, unattended. Founders who confuse the two spend weeks building a product to answer a question a two-day experiment could have settled first.

Quick Answer: Run MVEs before you scope an MVP. An MVE isolates one assumption — demand, price sensitivity, a specific behavior — and tests it with a landing page, a smoke test, or a manual process that's often thrown away afterward. An MVP is real, working software meant to deliver your actual value proposition and survive contact with users on its own. Build the MVP once your MVEs have de-risked the assumptions it would otherwise be built on blind.

That distinction sounds obvious in the abstract and gets ignored constantly in practice, because building feels like progress and testing feels like standing still. The pull toward "just build it and see" is real — but it's exactly backwards for the assumptions that determine whether the product is worth building in the first place. This guide lays out what each format actually tests, when to reach for which one, and how the two chain together on the way from a raw idea to a product worth funding.

MVE vs. MVP: The Side-by-Side Comparison

An MVE and an MVP aren't two sizes of the same thing — they answer different categories of question. The table below compares both across the dimensions that decide which one you should reach for next: what gets tested, what it costs, how long it takes, and what you're left holding afterward.

Read the table as a decision order, not a menu: an MVE's job is to protect you from spending an MVP's budget on an assumption that turns out to be false. The evidence column is the one that matters most — an MVE only produces a directional signal (people clicked, people didn't), while an MVP produces behavioral evidence over time (people stayed, people churned). You need the first kind of evidence before you're entitled to collect the second.

When an MVE Is the Right Move

Run an MVE whenever you don't yet know whether the assumption underneath your idea is true — and the cost of being wrong about it is a wasted build, not a wasted afternoon. That covers most of the early life of a startup idea: before you've validated demand, before you know what price the market will bear, before you know which of two workflows people actually prefer.

A few concrete situations where an MVE is the obvious move:

• You don't know if anyone wants this at all. A landing page describing the product with a "join the waitlist" button, run against paid or organic traffic, tells you whether the pitch alone converts strangers — before a single feature exists.
• You don't know what people will pay. A pricing page test, or simply asking for a card on file before the product is built, separates "I'd use that" from "I'd pay for that," which are very different signals.
• You don't know which of two approaches wins. Two landing pages, two onboarding flows, or two pitches, run in parallel and measured against the same conversion event.
• You need proof before you'll commit real engineering time. A smoke test — a fake "buy" or "book now" button that leads to an honest "not available yet, want to be notified?" page — measures real purchase intent without you writing a line of backend code.

The unifying feature of all four is that the assumption is falsifiable in days, not months, and a wrong answer costs you almost nothing if you catch it this way. That's the case for validated learning that Eric Ries builds The Lean Startup around: the build-measure-learn loop only compounds if each loop stays cheap enough to run repeatedly, and an MVE is what keeps a loop cheap.

If you're weighing which assumption to test first and in what order, the lean experiment playbook is the format for turning any assumption into a testable experiment inside a few days, instead of guessing at the shape of the test each time.

When You're Actually Ready for an MVP

You're ready for an MVP once your MVEs have burned down the assumptions that would sink a real build — not on a fixed timeline, and not because building finally sounds more fun than testing. An MVP is the wrong move while you still don't know if anyone wants the thing, what they'd pay, or which version of the workflow they'd actually choose. It's the right move once those questions have real answers and what's left to learn can only come from people using a real product over time.

Three signals tend to show up together when a founder is actually ready:

• Demand has cleared a bar you set in advance, not a bar you're rationalizing after the fact — a landing page or smoke test converted at a rate you'd decided beforehand was worth building for.
• You know the one job the product has to do, specifically enough to describe the target customer, their underserved need, and the value proposition without hand-waving. Dan Olsen's product-market fit pyramid in The Lean Product Playbook frames this as four stacked layers — target customer, underserved needs, value proposition, feature set — and an MVP only earns the fourth layer once the first three are settled by evidence, not assumption.
• What's left to learn requires retention data, not a one-time signal. Whether people come back next week, whether they'd be upset if it disappeared — that only shows up from a working product used over real time, which is exactly what an MVE structurally cannot produce.

Once those are true, the job shifts from "which assumption do I test next" to "how thin can the real product be while still delivering the actual value proposition." That's a scoping problem, not a validation problem, and it's a different discipline — building an MVP for product-market fit covers how to scope and ship that thinnest real version without quietly rebuilding the feature-complete product you were trying to avoid.

Hybrid Cases: Chaining MVEs Into an MVP Scope

The two formats aren't a single sequential handoff — a real path from idea to product usually chains several MVEs together, with each one narrowing what the eventual MVP has to include. Treating "run one experiment, then build the MVP" as a one-time step undersells how much of the actual scoping work happens across a series of small tests.

Take a hypothetical founder, Dana, with an idea for a tool that helps freelance consultants turn messy client calls into structured proposals. The instinct is to build a transcription-plus-template product and see if it sticks. Instead, Dana runs three MVEs in sequence:

1. MVE 1 — does the problem even register? A landing page describing "turn your call notes into a client-ready proposal in one click" runs against a small paid audience of freelance consultants. It converts well above the bar Dana set beforehand, which answers only one question: the pitch resonates enough to be worth testing further.
2. MVE 2 — will they pay, and how much? Dana adds a pricing page variant to the same funnel, testing two price points against each other. One clears a real willingness-to-pay signal; the other doesn't. That narrows the MVP's business model before a line of product code exists.
3. MVE 3 — which workflow do they actually want? Dana manually delivers the service for a handful of paying customers — recording calls, writing proposals by hand, sending them over email — a concierge process standing in for the product. Watching what customers edit, reject, or ask for repeatedly reveals that the proposal structure matters far more than the transcription itself.

By the time Dana scopes the actual MVP, three assumptions that would otherwise have been guesses — does the problem resonate, what's the business model, which workflow matters — are instead evidence. The MVP that gets built is narrower than the original idea, built around the proposal structure rather than transcription, and priced at the point MVE 2 already validated. None of that chain required a single engineer; all of it shaped what the engineers eventually built. That's the pattern worth generalizing: an MVP's scope isn't something you brainstorm, it's something you can read directly off the results of the MVEs that came before it.

Key Takeaways

• An MVE and an MVP test different categories of question. An MVE isolates one assumption with a throwaway artifact; an MVP delivers the full value proposition through a working product.
• Evidence type is the real dividing line. An MVE produces a directional signal (did they click, pay, show up); an MVP produces behavioral evidence over time (did they stay, did it retain them).
• Run MVEs first whenever an assumption is still unproven and cheap to test. Demand, pricing, and workflow preference are almost always cheaper to settle with an experiment than with a build.
• Readiness for an MVP is a state, not a schedule. You're ready once demand has cleared a bar you set in advance, the target customer and value proposition are specific, and what's left to learn needs retention data an MVE can't produce.
• A real path chains several MVEs together, each one narrowing the MVP's eventual scope — pricing, workflow, and positioning can all get settled before a single feature is built.
• The mistake isn't building an MVP — it's building one on assumptions nobody has tested. The fix is sequencing, not skipping either format.

Frequently Asked Questions

What's the difference between an MVE and an MVP?

An MVE (minimum viable experiment) tests one specific assumption — demand, price, a behavior — with the cheapest artifact that produces a real signal, often within days. An MVP (minimum viable product) is a working product built to deliver your full value proposition to real users over time. One validates an assumption; the other is the product built on top of validated assumptions.

Can you skip the MVE and go straight to building an MVP?

You can, but it means betting weeks or months of build time on assumptions nobody has tested — demand, price, and workflow fit all get discovered after the product already exists instead of before. It's not fatal, but it's the expensive way to learn things an MVE would have told you for the cost of a landing page.

How long should an MVE take?

Most MVEs run in hours to a few days — the format is deliberately fast because the goal is a directional signal, not a polished artifact. If an experiment is taking weeks to set up, it's usually scoped more like a small MVP than an actual MVE, and it's worth cutting it down further.

Do you need to build software for an MVE?

No — most effective MVEs use no real software at all: a landing page, a manual concierge process, a smoke test with a fake "buy" button, or even a set of direct outreach conversations. The point of an MVE is to avoid building software until an assumption has already earned it.