Validation & Discovery
Wizard of Oz MVP
Wizard of Oz MVP is a validation method where customers interact with what looks like a finished, automated product, but humans secretly fulfill the work behind the scenes. The front end is real; the back end is faked manually so you can test demand and behavior before building the engine.
Also known as: Wizard of Oz testing, Wizard of Oz prototype, manual-behind-the-scenes MVP
Why it matters
Building the automated version of a product is usually the most expensive and risky bet a founder makes, and a Wizard of Oz MVP lets you defer that bet until you have proof people will actually use the thing. Because the customer cannot tell the back end is manual, you get real behavioral data (do they come back, do they pay, do they trust the output) instead of opinions from an interview. It exposes the part of the workflow that actually matters before you sink months into engineering the wrong automation. It is also the fastest way to learn the messy edge cases your real product will have to handle, since you are doing the work by hand and feeling every gap. The build-or-kill signal is sharp: if customers will not engage even when a human is quietly doing the hard part flawlessly, automating it will not save the idea. Use it when the perceived product is simple but the underlying tech is hard or slow to build. Skip it once manual fulfillment can no longer keep up with demand, because that is your signal to actually build.
Worked example
Zappos started as a Wizard of Oz MVP: the founder photographed shoes at local stores, posted them online, and when an order came in he bought the pair at retail and shipped it himself, with no inventory or fulfillment system behind the storefront. A modern version: an AI meal-planning startup puts up a slick app, but for the first 40 users a nutritionist writes each plan by hand overnight. If 30 of those users return weekly and 12 convert to a paid tier, you have demand proof worth automating against.
Common mistakes
- Faking it so well that you never feel the operational pain. The point is to learn the hard parts of fulfillment by hand, so track time-per-task and failure cases instead of just collecting happy users.
- Running it past the point of usefulness. Manual work caps your sample, so once you have a clear yes or no signal, stop and either build or kill instead of grinding through hundreds of orders by hand.
- Measuring the wrong thing. Good looks like repeat usage, willingness to pay, and trust in the output, not signups or polite praise from people who think it is already automated.
Frequently asked questions
What is the difference between a Wizard of Oz MVP and a concierge MVP?
In a Wizard of Oz MVP the customer believes the product is automated, while humans secretly do the work behind a polished interface. In a concierge MVP the service is openly manual and personal, with no pretense of automation. Wizard of Oz tests whether the productized experience holds up; concierge tests whether the underlying service is wanted at all.
When should I use a Wizard of Oz MVP instead of just building the product?
Use it when the front end is cheap to mock but the back end (AI, complex logic, integrations) is expensive or slow to build. It lets you confirm real demand and learn the workflow's edge cases before you commit engineering time. If the automation is trivial to build, just build it and skip the theater.
What is a good signal that a Wizard of Oz MVP is working?
Look for repeat usage, willingness to pay, and trust in the output you delivered manually. A handful of users coming back weekly and converting to paid is far stronger than dozens of one-time signups. If people churn after one use even when your manual work was flawless, automating it will not fix the idea.
Is a Wizard of Oz MVP dishonest or unethical?
It is a gray area, so handle it carefully. Hiding that fulfillment is manual is generally fine for short validation runs, but never fake data accuracy, security, or outcomes people rely on for health, money, or legal decisions. When you charge money, deliver real value, and transition to disclosure or automation before scaling.
How long should I run a Wizard of Oz MVP?
Run it just long enough to get a clear build-or-kill signal, often a few weeks and a few dozen users. The constraint is your own capacity: when manual fulfillment can no longer keep up with demand, that backlog is the signal to start building the real engine. Dragging it out past a clear answer wastes the time the method was meant to save.
What are examples of a Wizard of Oz MVP?
Zappos is the classic case: a storefront with no inventory, where the founder bought and shipped each pair by hand. Many early AI products do the same, showing an automated-looking app while a human writes the responses overnight. Chatbots, recommendation engines, and matchmaking services are common candidates because the interface is simple but the back end is hard.
Related terms
More in Validation & Discovery
Stop reading definitions. Pressure-test your idea.
Knowing the terms is the easy part. Olune runs your actual idea against live Reddit signals, competitor data, and real search demand, then gives you an honest GO / NO-GO verdict in about eight minutes. Free, no card.
Last updated 2026-06-09 · Back to the glossary