The Wizard of Oz MVP: Fake the Backend, Validate the Frontend
A Wizard of Oz MVP is a validation test where users interact with what looks like a fully automated product, while a person manually performs every step the software would eventually handle. The interface is real; the automation isn't, yet. It proves whether the workflow holds up once people believe it's real — before you build the engine behind it.
Quick Answer: A Wizard of Oz MVP looks and feels like finished software, but a human does the "automated" work by hand, out of sight. Customers experience a product that appears to run itself. You experience a manual, often exhausting, backend — and that gap is exactly what tells you whether the workflow is worth automating at all.
How a Wizard of Oz MVP works, step by step
The mechanic is simple, even when running it well isn't: build a front end that looks finished, then have a person quietly perform every "automated" step behind it in real time, while logging exactly what that person had to do.
- Build or borrow a front end that looks real. This can be an actual working app screen, a form wired to a spreadsheet, or a simple landing page with a signup or request flow — whatever it takes for a user to believe they're interacting with a finished product, not a mockup.
- Pick the one moment you're testing, and only that moment. Decide exactly what "automated" step you're faking — a matching algorithm, a recommendation, an instant quote, a generated plan — and keep the rest of the experience as simple as it needs to be to support that one moment convincingly.
- Route every request to a human, live. You, or a small team, sit behind the interface and manually produce whatever the "automated" feature is supposed to deliver, for every single user action, in real time.
- Match the response time real automation would have. If the finished product would answer in seconds, a five-minute delay breaks the illusion and contaminates what you learn — you're no longer testing whether the workflow works, you're testing whether people tolerate a slow support queue.
- Log every decision like you're writing the spec. Each time the person behind the curtain makes a judgment call, write down what the input was, what they decided, and why. That log becomes the actual requirements document for the algorithm or automation you'll eventually build.
- Set an end date before you start, then make the call. Run it long enough to see the workflow repeat across enough users to trust the pattern, then either build the real automation for the part that mattered most, adjust the workflow and run it again, or kill the idea because the human-powered version already showed it doesn't hold together.
This is one stage in a sequence, not a standalone trick — it typically comes after you already have some signal that people want the outcome, and before you commit engineering time to automating it. See the lean experiment playbook for how a Wizard of Oz test fits alongside interviews, concierge tests, and the other experiments that come before and after it.
A Wizard of Oz MVP in practice: an online shoe store with no shoes
One of the most frequently told Wizard of Oz stories in startup circles is also one of the earliest: the origin of Zappos.
Before Zappos existed as a company, its founder, Nick Swinmurn, wanted to answer a single question: would a stranger buy shoes online, sight unseen, without trying them on first? Rather than build an inventory system, negotiate with suppliers, or write a line of e-commerce code, he walked into local shoe stores, photographed their stock with permission, and posted the photos on a simple website as if it were a real online shoe retailer with its own inventory. When an order came in, he went back to the store, bought that exact pair at full retail price, and shipped it to the customer himself.
To the customer, the experience looked like an ordinary online store: browse shoes, place an order, receive a package. Behind that screen there was no warehouse, no supplier relationships, and no automated fulfillment — just one person driving to a mall and absorbing the price difference to keep the illusion intact. That gap between what the customer saw and what was actually happening behind it is the entire definition of a Wizard of Oz test.
What made it worth doing manually, at a loss, rather than surveying people about whether they'd buy shoes online, is that it produced real behavior instead of a stated opinion. People who complete a purchase are telling you something a questionnaire never can. Once orders kept coming in, Swinmurn had an answer to the one assumption the whole future business depended on — and that answer, not a business plan, became the founding premise for what grew into Zappos.
Wizard of Oz vs. concierge vs. fake door
These three approaches often get lumped together as "cheap ways to test an idea before building it," but they test different things, and confusing them leads founders to draw the wrong conclusion from a result.
| Approach | What the customer experiences | What's actually running behind it | Best used to test | Main limitation |
|---|---|---|---|---|
| Wizard of Oz MVP | A working, seemingly automated product | A human manually operating the "automated" step, in real time | Whether the workflow and interface hold up once it looks and feels automated | Doesn't scale past what a human can keep up with; a trust risk if customers discover the human |
| Concierge MVP | A person openly doing the work for them | Nothing automated — you are the entire backend, and the customer knows it | Whether people will pay for the outcome at all | Tells you little about how the eventual software will feel to use |
| Fake door MVP | An ad, button, or landing page for something that doesn't exist yet | Nothing — a click leads to a "coming soon" message or a waitlist signup | Whether there's enough top-of-funnel interest to justify building anything | A click isn't a purchase or real usage — the weakest signal of the three |
The distinction that trips people up most is between a Wizard of Oz MVP and a concierge MVP: both use a human to fake the backend, but a concierge test is openly a person doing the work, while a Wizard of Oz test depends on the customer believing the opposite — that no person is involved at all. A fake door test sits a step earlier than either: it doesn't even deliver a real outcome, so it can only tell you whether people are curious enough to click, not whether they'd use or pay for what's on the other side.
When a Wizard of Oz MVP matters for validation — and the ethical line on deception
A Wizard of Oz test earns its cost when you already have some evidence that people want the outcome, and the open question is whether the workflow and interface hold up once the product looks and behaves like finished software. If you're still deciding whether this is even the right experiment to reach for next, the complete guide to startup idea validation maps the wider sequence of tests founders run before committing engineering time to anything automated.
What it's genuinely good at proving. It shows you whether an automated-feeling experience actually works in practice — the interface, the turnaround time, the format of the output — in a way a concierge test, where the customer knows a human is involved, can't. It also generates the real decision logic your future automation needs: every judgment call the person behind the curtain makes is a requirement you'd otherwise have to guess at before writing any code.
Where it stops being useful. It tells you little about willingness to pay if you haven't already tested that separately — people can be delighted by a demo that a human is quietly propping up and still balk at the price once it's real. It also doesn't test technical feasibility: proving a human can produce a good recommendation by hand says nothing about whether an algorithm can do the same thing at the speed and cost your business model needs. And because a person is standing behind every interaction, it caps out at whatever volume that person, or a small team, can sustain.
The ethical line. A Wizard of Oz test only works because users believe something that isn't true — that they're dealing with automated software when they're not — and that puts a real limit on what's acceptable, unlike a concierge test where the human is disclosed from the start. Three guardrails keep it on the right side of that line: stay out of domains where a person might make a real decision — medical, legal, financial, safety — believing it was made by an unbiased system, because the deception itself could cause harm there in a way it can't in, say, a scheduling app. Keep it time-bound and small, run for a defined stretch with a defined group, not as a permanent way to avoid building the real thing. And be ready to tell early users what actually happened once the test is done, especially if you intend to keep serving them or keep using data they gave you.
Eric Ries's The Lean Startup is the book most associated with this style of test, and its core argument is worth keeping in view here: the point of validated learning isn't to fool people forever, it's to get an honest, fast answer to a build-or-don't-build question and then stop pretending the moment you have one.
The mistakes that quietly undermine the test. The most common is making the illusion too good — a human who's more careful and creative than the eventual algorithm will be sets an expectation the automation can't meet, so the test ends up validating a version of the product you can't actually ship. A second is running it long after you already have your answer, because the manual version is working and nobody wants to fund the engineering effort to replace it — at that point it's not a test anymore, it's an expensive way of avoiding a decision. A third is skipping the log in step five, which leaves you with a good demo and no actual specification. And the last is testing in a domain where the deception itself carries risk — that's not a mistake to fix with better process, it's a sign this isn't the right method for the question you're asking.
Key Takeaways
- A Wizard of Oz MVP fakes the automation, not the interface. Customers experience what looks like finished software; a human performs the "automated" step behind the scenes, in real time.
- It tests the workflow, not just the demand. Use it once you already have some signal people want the outcome, and the open question is whether the experience holds up once it looks real.
- Response time is part of the illusion. If real automation would answer in seconds, a slow manual response contaminates the result — you'd be testing patience, not the workflow.
- The manual log is the actual deliverable. Every judgment call the person behind the curtain makes becomes a requirement for whatever you eventually automate.
- It's different from a concierge MVP in exactly one way that matters. A concierge test is openly a person doing the work; a Wizard of Oz test depends on the customer believing no person is involved.
- The deception has a real ethical boundary. Stay out of domains where believing a decision was automated changes how much someone trusts it — medical, legal, financial, safety — and keep the test time-bound.
- Set the end date before you start. A Wizard of Oz test that quietly becomes the permanent way you run the business stops being a test.
Frequently Asked Questions
What is a Wizard of Oz MVP?
A Wizard of Oz MVP is a validation method where users interact with what appears to be a fully automated product, while a person manually performs the "automated" work behind the scenes, in real time. It tests whether a workflow and interface hold up once people believe they're using finished software, before any of the actual automation gets built.
Is a Wizard of Oz MVP ethical, or is it just lying to users?
It sits on a real ethical line because it depends on a belief that isn't true, which is why it's not appropriate everywhere. It's on solid ground when the deception is low-stakes, time-bound, and the eventual product genuinely will be automated — the test just moves that automation earlier in appearance than in fact. It becomes a problem in domains like medical, legal, or financial decisions, where someone trusting an "automated" judgment more than a human one could cause real harm.
How is a Wizard of Oz MVP different from a concierge MVP?
The customer's belief about who's doing the work is the difference. In a concierge MVP, the customer knows a person is delivering the outcome by hand — it's an openly manual service. In a Wizard of Oz MVP, the customer believes the product is automated, while a person is secretly performing the steps that aren't built yet.
How long should you run a Wizard of Oz test before building the real thing?
Long enough for the workflow to repeat across enough users that you trust the pattern, and no longer — there's no fixed number, but if you're still running it purely because building the real automation feels like more work, that's a sign you've already learned what you needed to know. Once you can name the exact decision logic the person behind the curtain keeps repeating, you have enough to specify what to build.