What Is a Wizard of Oz MVP? Definition + Example
A Wizard of Oz MVP is a validation test where the front end looks like a fully automated, working product, but humans quietly perform the work behind the scenes. Customers believe they are using software; in reality, a person delivers the result — so you learn whether people want the experience before building the automation.
Quick Answer: In a Wizard of Oz MVP, the customer sees a finished, automated-looking product, but a human does the actual work invisibly behind the interface. Named after the "man behind the curtain," it tests real demand for the automated experience before you spend months engineering it. Popularized by Eric Ries in The Lean Startup.
How a Wizard of Oz MVP works: the human behind the curtain
A Wizard of Oz MVP separates what the customer experiences from how the work actually gets done. The interface promises automation. The delivery is manual. The customer never knows the difference — and that ignorance is the whole point.
The name comes from the film: a booming, magical wizard turns out to be an ordinary person pulling levers behind a curtain. Your product works the same way. A user submits a request through a slick form or app, sees a professional result come back, and assumes an algorithm produced it. In fact, you or a teammate did the work by hand.
This design answers one question cheaply: do people want the automated outcome at all? Building real automation is expensive and slow. If you fake it convincingly, you can measure demand — sign-ups, repeat use, willingness to pay — before writing the hard code. Eric Ries frames this in The Lean Startup as validated learning: spend engineering effort only after evidence says the demand is real.
The manual work is deliberately unscalable, and that is fine — an MVP is an experiment, not a business at full throughput. You are buying data, and human hours are a cheap way to buy it. For the wider map of options, see the types of MVP explained overview, or the deeper wizard of oz MVP walkthrough.
A concrete Wizard of Oz example: Zappos and the shoe store test
The canonical example is Zappos, told by Eric Ries in The Lean Startup. Founder Nick Swinmurn wanted to know whether people would buy shoes online — an unproven idea at the time. Building warehouses, inventory systems, and logistics first would have been an enormous bet on an untested assumption.
Instead, Swinmurn went to local shoe stores, photographed their inventory, and posted the pictures on a simple website. When a customer ordered a pair, he went back to the store, bought the shoes at full price, and shipped them himself.
To the customer, it looked like a functioning online shoe retailer. Behind the curtain, there was no automation, no warehouse, and no inventory — just a founder running errands. The site tested the one assumption that mattered: would people pay for shoes sight-unseen over the internet? The answer came from real orders and real money, not a survey.
Notice what the test avoided. Swinmurn did not lose money optimizing a supply chain for a product nobody wanted. He proved demand first, then earned the right to build the automated business underneath it.
Wizard of Oz vs concierge MVP: what the customer knows
Both approaches use human effort instead of finished software, but they differ on one thing: whether the customer knows. In a Wizard of Oz MVP the manual work is hidden and the experience feels automated. In a concierge MVP, the manual delivery is open and personal — the customer knows a human is helping them, hands-on.
The table below contrasts the two lean experiments qualitatively.
| Dimension | Wizard of Oz MVP | Concierge MVP |
|---|---|---|
| What the customer perceives | An automated, self-serve product | A guided, human-delivered service |
| Where the human sits | Hidden behind the interface | Visible, working alongside the customer |
| Primary question tested | Do people want the automated experience? | Does the solution actually solve the problem? |
| Feel of the interaction | Impersonal, product-like | Personal, high-touch |
| Best when | The interface is the promise you must validate | You still need to learn what "done" looks like |
Takeaway: choose Wizard of Oz when you need to test appetite for an automated experience, and concierge when you still need to learn the customer's problem up close. Same manual engine, opposite level of transparency.
When to fake the automation instead of building it
Fake the automation when the automation is the risky, expensive part and the demand is the open question. If you already know people want the outcome, faking it teaches you little. The technique earns its keep when building the real system would be a large, irreversible investment against an unproven assumption.
Reach for a Wizard of Oz MVP when several of these hold:
- The core value can be delivered by hand at low volume. You can personally produce the result a few times a day without special tooling.
- The automation is the costly bet. The engineering to make it scale is months of work you do not want to commit blind.
- The experience must feel automated to be tested honestly. If the demand you care about depends on the product feeling instant and self-serve, a visible human would contaminate the signal.
- You can measure a real decision. Orders, payments, or repeat usage give you behavioral evidence, not opinions.
Avoid it when the manual work cannot even be simulated at small scale, or when doing the work invisibly would mislead customers in a way that causes real harm. Honesty about the eventual product is fine; deception that damages someone is not. Keep the experiment small, time-boxed, and pointed at one assumption.
Key Takeaways
- A Wizard of Oz MVP looks fully automated to the customer, but humans do the work invisibly behind the interface.
- Its purpose is to test demand for the automated experience before you build the expensive automation.
- Eric Ries popularized the concept in The Lean Startup, using Zappos as the classic example.
- Nick Swinmurn photographed shoes in local stores and fulfilled orders by hand — validating online shoe demand with no inventory.
- The key contrast with a concierge MVP is transparency: Wizard of Oz hides the human; concierge shows the human.
- Use it when the automation is the costly, risky bet and real demand is still unproven.
- Keep the manual work small and measure real decisions — orders, payments, repeat use — not survey answers.
Frequently Asked Questions
Why is it called a "Wizard of Oz" MVP?
The name refers to the "man behind the curtain" from the film. In the story, an intimidating, all-powerful wizard turns out to be an ordinary person operating machinery out of sight. A Wizard of Oz MVP works the same way: the customer sees an impressive automated product while a hidden human quietly produces the result.
What is the difference between a Wizard of Oz MVP and a concierge MVP?
The difference is whether the customer knows a human is involved. In a Wizard of Oz MVP the manual work is hidden and the product feels automated. In a concierge MVP, delivery is openly manual and personal — the customer knows they are being helped by a human, hands-on, rather than by software.
Is a Wizard of Oz MVP dishonest?
Not inherently. You are testing whether people want an experience, and you fully intend to build the automation you are simulating. That is a legitimate experiment. It crosses a line only if the hidden manual process misleads customers in a way that causes real harm — mishandling their money, data, or safety. Keep the test small and accountable.
What is the Zappos Wizard of Oz example?
Zappos, as told in The Lean Startup, is the textbook case. Founder Nick Swinmurn posted photos of shoes from local stores on a simple website. When someone ordered, he bought the shoes at the store and shipped them himself. Customers saw an automated online retailer; behind the curtain, a founder was running errands to test real demand.