This is the domain that decides whether you spend five months building something nobody wants, or four days finding out they don't want it. MVPs and experiments are how you convert opinions and whiteboard strategy into evidence, before the evidence gets expensive. Every concept below answers some version of the same question: what is the cheapest, fastest test that would actually change your mind? Use this guide to design the test before you build the thing.
MVP
An MVP is the smallest thing you can put in front of real customers that tests your riskiest assumption — a learning tool, not a small product. Eric Ries, in The Lean Startup, is blunt about the definition: an MVP "is not necessarily the smallest product imaginable... it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort." That's a different target than "smallest." A single landing page can be a valid MVP; so can a five-month build, if that's genuinely the fastest way to test the assumption that would kill you.
The catch Ries flags is that an MVP is harder to build than a normal prototype, not easier — because unlike a prototype evaluated by your own engineers for internal quality, an MVP has to be instrumented to measure real customer reactions, sometimes including whether they'll actually pay. IMVU's first MVP was an avatar that couldn't walk — it teleported, because the team hadn't built pathfinding yet. It felt embarrassing to ship. It was still enough to test whether people wanted to chat as avatars online at all.
Watch out: the most common failure mode is building a "minimum" version of the product instead of a minimum test of the riskiest assumption. If you cut features but still spend three months building, you haven't made an MVP — you've made a small, slow product. Ask "what's the least amount of stuff I can build that still generates a real, measurable customer reaction to the thing I'm most unsure about?"
→ practice this in the smallest-testable-thing mission.
Prototype
A prototype is a disposable mock — clickable screens, a sketch, a demo — built to test whether people understand and want the solution before you build it. Alberto Savoia, in The Right It, deliberately distinguishes this from what he calls a pretotype: prototypes test whether an idea can be built and how it should work; pretotypes (and MVPs generally) test whether an idea is worth building in the first place. He argues the word "prototype" is dangerously generic — it gets used for both a five-minute paper mockup and a five-year, $5 million engineering effort, and treating those as the same thing sets the wrong expectations. A prototype should cost hours or days, not months.
A prototype is typically the step before an MVP: you use it to check that customers understand the pitch and can navigate the intended flow, before you invest in a version they can actually use and pay for. A team designing an expense-approval tool might click through eight Figma screens with five finance managers before writing a line of code — not to sell anything, but to see if the workflow makes sense to someone who didn't build it.
Watch out: a prototype that only gets evaluated by your own team for "does this look right" isn't testing anything about the market — it's testing your own taste. Put it in front of people who aren't invested in the idea.
Landing Page Test
A landing page test is a page that pitches the product as if it exists and measures who clicks, signs up, or pays — testing demand before writing product code. Testing Business Ideas (Bland & Osterwalder) catalogs this as one of the cheapest, fastest experiments in the entire library, and The Right It frames the same move as a "fake door" — putting a real doorway in front of customers to see how many walk through it, before building the room behind it.
The mechanics: write real copy, real pricing (if relevant), and a real call to action — "Join the waitlist," "Get early access," "Buy now" — then drive a small, targeted batch of traffic to it and measure the click-through and conversion rate. Dropbox's original MVP, referenced in The Lean Startup, was essentially this in video form: a demo video pretending the product worked, with a signup box beneath it. The video was the whole test.
Watch out: traffic quality wrecks this test more than anything else. Driving 10,000 random visitors and getting 40 signups tells you less than driving 50 warm, on-target visitors and getting 15. Match the audience to your actual customer profile, or the conversion rate measures nothing you can act on.
→ practice this in the landing-page-test mission. Pair with the conversion-funnel calculator to see what the resulting numbers mean.
Concierge MVP
A concierge MVP means delivering the service manually to a handful of customers, by hand and in person, to learn what the product must do before automating it. Ries's canonical example is Food on the Table: instead of building an app to generate meal plans from grocery-store sales and family preferences, the founder met with customers face-to-face and built their meal plans and shopping lists by hand, one at a time. Every plan was custom, unscalable, and completely manual — which was the point. It surfaced what customers actually wanted from the automated version, long before a single line of matching-algorithm code got written.
Ries is explicit that in a concierge MVP, "this personalized service is not the product but a learning activity designed to test the leap-of-faith assumptions in the company's growth model." A common — and valuable — outcome is that it invalidates your assumed growth model even while the manual service itself is profitable; the discipline is not mistaking a happy handful of hand-served customers for a scalable business.
Watch out: concierge MVPs feel great because customers love the white-glove treatment — that warmth doesn't prove the automated product will land the same way. It only proves the underlying need is real and shows you what to automate first.
→ practice this in the concierge-mvp mission. Concierge delivery often doubles as a live problem-interview — you're in the room while the work happens.
Wizard of Oz Test
A Wizard of Oz test is a product that looks automated to the customer but is powered by humans behind the curtain — testing the experience before the technology. The name (and the "Mechanical Turk pretotype" that Savoia describes in The Right It, referencing the 18th-century chess "automaton" secretly operated by a hidden chess master) both point at the same trick: fake the hard engineering, keep the customer-facing experience real. IBM famously tested speech-to-text this way — a "typist in the next room" transcribed what users spoke, letting IBM validate the concept years before the underlying technology existed. Aardvark, a Q&A startup later acquired by Google, used Wizard-of-Oz techniques repeatedly to test which questions people would actually ask and how they wanted answers routed, without building a matching engine first.
The distinction from a concierge test: in Wizard of Oz, the customer believes they're interacting with automation. In concierge, the human involvement is visible. Choose based on what you need to learn — whether people trust and want an automated experience, versus whether the underlying service has value at all.
Watch out: this only works when the "curtain" holds — if customers realize a human is faking the automation, you contaminate both the data and the trust. Keep the operation genuinely invisible, and be honest with customers afterward about what they participated in.
Experiment, Hypothesis, and Minimum Success Criterion
An experiment is a structured test with a hypothesis, a metric, and a pass/fail threshold decided before you run it. A hypothesis is a falsifiable belief written as "we believe [segment] will [behavior] because [reason]" — specific enough that an experiment can kill it. A minimum success criterion is the result threshold, set before the experiment runs, below which you admit the hypothesis failed — your defense against rationalizing weak signals.
Testing Business Ideas structures every experiment as a four-part "test card": (1) the hypothesis you're testing, (2) the experiment description, (3) the metric you'll measure, and (4) the criteria for success. The book stresses starting hypotheses with "We believe that..." and warns that phrasing everything as confirmation ("we believe X will happen") invites confirmation bias — you end up hunting for evidence that you're right. It recommends also writing a disconfirming version ("we believe X will not happen") so you're honestly trying to break the idea, not prove it. A well-formed hypothesis is testable (can be shown true or false with evidence), precise (you know what success looks like — the exact who, what, and when), and discrete (it tests exactly one thing). "We believe millennial parents will subscribe to science kits" is too vague; "we believe parents of kids 5–9 will pay $15/month for curated science kits matched to their kid's level" is testable, precise, and discrete. Savoia's Market Engagement Hypothesis (MEH) in The Right It is the same discipline under a different name: your explicit, numeric belief about how the market will respond — will they explore it, adopt it, pay for it, repeat, refer — stated clearly enough to be provably wrong.
The minimum success criterion is what stops a shrug of "well, 40 signups feels okay" from becoming a green light. Decide before you launch: "we'll consider this validated if at least 8% of visitors join the waitlist." If you get 5%, the hypothesis failed — even if 5% still feels like a win emotionally. Setting the number after seeing the result defeats the entire purpose.
Watch out: the most common failure isn't running the wrong experiment — it's setting the threshold after seeing the data, which turns every result into a win by definition. Write the number down before you launch, and hold yourself to it.
→ practice this in the experiment-design mission.
Activation and Onboarding
Activation is the moment a new user first experiences the product's core value — the earliest behavior that predicts they'll stick around. Onboarding is the path from sign-up to first value, designed to get users activated before their initial motivation fades.
Lean Analytics (Croll & Yoskovitz) places activation as the second stage of Dave McClure's AARRR "Pirate Metrics" framework — Acquisition, Activation, Retention, Revenue, Referral — describing it as the step that turns "drive-by visitors into users who are somehow enrolled": completed onboarding, used the service at least once, created an account. Activation is deliberately distinct from acquisition (getting someone to show up) and from retention (getting them to come back); it's the bridge between the two, and it's usually the leakiest part of the funnel. A meal-kit app might acquire 1,000 signups a week but only "activate" 300 of them — the ones who actually complete a first order — and only activated users show up in next month's retention numbers at all.
Inspired (Cagan) frames onboarding as a core product-design question, not an afterthought: "how will we onboard a first-time user and (perhaps gradually) reveal new functionality?" is one of the standing questions a product team should answer for the full customer journey, not just the first session. Good onboarding reveals only what's needed to reach the first "aha" moment, then layers in complexity — cramming every feature into day one usually delays activation instead of accelerating it.
Watch out: teams routinely optimize signups (acquisition) while activation quietly leaks users out the bottom — check the sign-up-to-first-value conversion rate specifically, not just top-of-funnel volume.
→ practice this in the activation-metric mission. The conversion-funnel calculator makes the acquisition-to-activation drop-off visible.
Build-Measure-Learn
Build-Measure-Learn is the Lean Startup loop: build the smallest test, measure real behavior, learn, and decide whether to persevere or pivot. This is the organizing idea of Ries's The Lean Startup — he calls it "the fundamental activity of a startup." Crucially, Ries argues you should plan the loop in reverse: figure out what you need to learn first, use that to decide what to measure (this is what he calls innovation accounting — a replacement for traditional accounting suited to extreme uncertainty), and only then figure out the minimum thing you need to build to generate that measurement. The letters are in build-first order because that's the order the work happens in; the thinking runs the other way.
The output of the loop is what Ries calls validated learning — not a good story or an after-the-fact rationalization, but empirical proof, backed by real customer data, that you've discovered something true about the business. He contrasts this sharply with vanity metrics (gross signups, page views — numbers that go up but don't tell you if the business works) and "success theater" — burning resources to make numbers look good instead of building a sustainable engine. The IMVU team learned this the hard way: they spent months improving product quality, watched sales stay flat, and only understood why after tightening the loop and confronting the data directly instead of explaining it away.
Watch out: teams that adopt "MVP" language without adopting the measurement discipline just end up building small things slowly and calling it lean. The loop only works if "measure" produces a number that can prove you wrong.
Pivot
A pivot is a structured change of strategy — new segment, problem, or model — made while keeping what the evidence says is working. Ries describes it as "changing course with one foot anchored to the ground": unlike randomly trying a new idea, a pivot preserves whatever validated learning you've already earned and redirects the rest.
The Lean Startup catalogs specific pivot types worth knowing by name, because naming the move clarifies the decision. A zoom-in pivot takes what was previously a single feature and makes it the whole product (a voter-engagement platform's social layer got dropped so the registration-technology feature could become the entire offering). A customer segment pivot keeps the product the same but changes who it's sold to — the same tool moving from consumer activists to B2B fundraising organizations, changing the business from B2C to B2B in the process. A platform pivot shifts from selling a single application to offering a self-serve platform others build on top of — think a one-customer-at-a-time sales tool evolving into an AdWords-style self-serve product.
Ries recommends scheduling a recurring "pivot or persevere" meeting — not spontaneous, not just after a bad week — bringing both the product team's tuning results and the business team's customer conversations to the table together. The decision is emotionally loaded (sunk cost is real), which is exactly why it needs a structured, scheduled forum instead of being made in the heat of a bad quarter.
Watch out: the danger isn't pivoting too often — Ries argues most startups pivot too late, propped up by vanity metrics and sunk-cost attachment to the original plan. If your engine-tuning efforts have stopped moving the metrics that matter, that's the signal, not a feeling of despair.
Validation
Validation is confirmation through customer behavior — not opinion — that an assumption about demand, usage, or willingness to pay holds. This is the connective tissue across the whole domain: every method above (landing page, concierge, Wizard of Oz, MVP) exists to produce validation, and every experiment needs it as its output.
The discipline validation enforces is behavioral evidence over stated preference. A customer saying "I'd definitely use this" in an interview is weaker evidence than a customer giving you a credit card number, because talk is free and money isn't — this is the same logic behind Savoia's "skin in the game" tests in The Right It and the whole premise of landing page and presale experiments in Testing Business Ideas. Continuous Discovery's assumption tests, run inside an opportunity solution tree, follow the identical principle: a solution idea sits on the tree until an assumption test either supports it with real evidence or knocks it off.
Watch out: validation is graded, not binary. A single positive data point ("12 people signed up") isn't validation on its own — it's validation only relative to the minimum success criterion you set beforehand. Without that threshold, "we got some signups" can mean almost anything.
Go deeper
- Eric Ries, The Lean Startup — the definitive source for Build-Measure-Learn, validated learning, innovation accounting, and the taxonomy of pivots.
- Alberto Savoia, The Right It — pretotyping vocabulary (Mechanical Turk pretotype, fake door), and the Market Engagement Hypothesis for stress-testing your belief about market response.
- David Bland & Alexander Osterwalder, Testing Business Ideas — the test-card structure (hypothesis, experiment, metric, criteria) and a library of experiments including concierge, Wizard of Oz, and landing page tests.
- Teresa Torres, Continuous Discovery Habits — opportunity solution trees and assumption testing as an ongoing discipline, not a one-time launch event.
- Marty Cagan, Inspired — onboarding and activation as core product-design questions, not growth-team afterthoughts.
- Alistair Croll & Benjamin Yoskovitz, Lean Analytics — the AARRR framework that locates activation between acquisition and retention, and the vanity-vs-actionable metrics distinction that innovation accounting depends on.