Wizard of Oz MVP: How It Works, with Examples

TL;DR

A Wizard of Oz MVP is a validation method where the product looks fully automated to the user, but humans perform the work behind the scenes, so you can test a real product experience before building the technology. The customer believes they are using finished software; in reality, you are the software. It is the right MVP type when you already know the solution and want to test whether people will actually use and pay for it, without first building the expensive automation. The catch is that it raises an ethics question the other MVP types do not, because the user does not know.

Where it fits: the Wizard of Oz MVP tests demand for an automated product; once validated, you build the real automation. At HorizonLux we help founders decide whether to fake it first or build directly, then ship the real product, usually a single-feature MVP in 3–4 weeks. This guide covers how to run a Wizard of Oz MVP well, including the examples and the ethics. It is one of the eight types of MVP in our wider map.

What is a Wizard of Oz MVP?

A Wizard of Oz MVP is a minimum viable product that simulates a working, automated system while humans secretly do the work behind it. The user interacts with what looks like a finished product. Behind the interface, a person reads the request, performs the task by hand, and returns a result that appears to come from software.

The name comes from L. Frank Baum's 1900 novel The Wonderful Wizard of Oz. The all-powerful wizard turns out to be an ordinary man behind a curtain, pulling levers to project an illusion of magic. "Pay no attention to the man behind the curtain" is the whole idea: the user experiences the magic without knowing a human produces it. That hidden operator is the defining trait of this MVP type.

The purpose is to validate the real product experience and real demand before building the engine. If people use the automated-looking product, request more, and pay for it, you have strong evidence that the eventual automated version is worth building. You get that evidence for the cost of doing the work by hand for a while, instead of the cost of building software that might fail in the market.

Wizard of Oz vs Concierge MVP

The Wizard of Oz MVP has one close sibling, the Concierge MVP, and confusing the two leads founders to run the wrong test. Both deliver value manually. The difference is whether the user knows.

The simplest way to hold the distinction: a Wizard of Oz test happens behind the curtain, hidden, while a concierge test happens behind the desk, in plain view. Use the concierge approach when you are still figuring out what the product is, because open, hands-on contact teaches you the most. Use the Wizard of Oz approach when you already know the solution and need to test whether people will adopt the automated product as if it were real. The two even pair in sequence: run a concierge MVP to learn what to build, then a Wizard of Oz MVP to test whether the automated version will sell. We cover the transparent counterpart in full in the Concierge MVP guide.

When to use a Wizard of Oz MVP

A Wizard of Oz MVP is the right tool in a specific set of situations, and the wrong one in others.

Reach for it when:

• The product would be expensive or slow to automate. If the automation is the hard, costly part (an algorithm, a model, a complex integration), faking it first lets you validate demand before you pay to build it.
• You already know roughly what the product should do. Unlike a concierge test, the Wizard of Oz approach assumes the solution is fairly clear and you want to test whether the market wants it delivered as a product.
• A realistic product experience matters to the test. Because the front end looks real, you get genuine usage and conversion data, closer to how people would behave with the finished product.
• The work can be done by hand within a reasonable time. The illusion only holds if a human can deliver the result fast enough that it feels automated.

Skip it when:

• The value cannot be delivered fast enough by hand. If users expect an instant response and a human cannot keep up, the illusion breaks and the test fails.
• The data is sensitive. Having humans secretly handle private financial, medical, or personal data that users believe only a machine sees is an ethics and privacy problem, covered below.
• You are still unsure what to build. Then a transparent concierge test will teach you more, because you can talk to users openly.
• You would be tempted to never build the real thing. A Wizard of Oz MVP is a temporary test, not a permanent business model. If you cannot commit to automating it, do not start.

How to run a Wizard of Oz MVP: a step-by-step playbook

Running a convincing Wizard of Oz MVP takes more setup than a concierge test, because you must maintain an illusion. Here is the playbook.

Step 1: Build a believable front end

The user-facing part has to look like a real product. This does not mean building the whole thing; it means building only the interface and the input and output. A simple web form, a chat interface, or a landing page with a "start" button is often enough. The rule is that the parts the user touches must feel finished, while everything behind them can be held together with tape. No-code tools make this fast and cheap.

Step 2: Set up the human back office

Behind the front end, build the manual fulfillment process: where requests arrive, who handles them, and how results are returned. This is your curtain. When a user submits something, it should land somewhere a person can see it (an inbox, a dashboard, a queue), get handled by hand, and be delivered back through the same product-like interface. Keep this process tight, because its speed and consistency are what sell the illusion.

Step 3: Set a response-time promise that hides the human

The biggest risk to a Wizard of Oz MVP is timing. If users expect an instant result and a human takes an hour, the magic dies. Solve this by setting expectations the manual process can actually meet: "results in a few minutes," or "your report will be ready within the hour." A small, honest delay framed as processing time keeps the illusion intact while a person does the work. Many real automated products have processing times anyway, so this is not inherently deceptive about speed.

Step 4: Deliver manually, fast and consistently

Now do the work. For each request, perform the task by hand and return a result that looks like software produced it: same format, same tone, same structure every time. Consistency matters more than perfection, because inconsistency is what makes users suspect a human. The goal is a product experience indistinguishable from the automated version you intend to build.

Step 5: Instrument the front end

Because the front end is real, you can measure real behavior. Track who signs up, who completes the core action, who comes back, and who pays. This is the data a concierge test cannot give you as cleanly, and it is the whole point: you are measuring how people behave with the product, not just what they say about it.

Step 6: Learn the algorithm, then automate

Every manual fulfillment is a recorded example of what the eventual software must do. After enough requests, patterns emerge: the rules you follow, the judgment you apply, the inputs that map to outputs. That is your specification for the real system. When you build it, it works, because you are automating a process you have run by hand hundreds of times. This is the bridge from Wizard of Oz MVP to a real product, and it is exactly how Aardvark's matching algorithm was born.

The Wizard of Oz MVP toolkit

You do not need engineers to run a Wizard of Oz MVP. The point is to build the illusion cheaply, and modern no-code tools make that possible in a day.

The front end (what users see):

• A landing page or form builder (Webflow, Carrd, Tally, Typeform) for the entry point.
• A simple app builder (Softr, Glide, Bubble) if you need accounts or a dashboard.
• A chat interface (Intercom, Crisp, or even a plain email thread) when the product is conversational.

The back office (the curtain):

• A shared inbox or queue (a Gmail label, a Slack channel, a Trello or Notion board) where requests land.
• A spreadsheet or Airtable base to track each request, who handled it, and the result.
• Automation glue (Zapier, Make) to route requests and send results back in a consistent, product-like format.

The delivery (what comes back):

• A templated response (a saved document, a formatted email, a generated PDF) so every result looks machine-made.

The combination, a polished front end plus a tracked manual queue plus a templated output, is enough to make a hand-run service feel like finished software. Spend your effort on the parts users see and on consistency; everything else can be duct tape, because it is temporary by design.

Real Wizard of Oz MVP examples

Zappos

The most famous Wizard of Oz MVP. Before building any inventory or logistics, founder Nick Swinmurn tested one question: would people buy shoes online? He photographed shoes at local stores, posted them on a simple site, and when an order came in, he bought the shoes from the store and shipped them himself. To the customer it looked like a real shoe retailer. Behind the curtain, there was no warehouse, no system, just a founder proving demand before building the company. Zappos went on to be acquired by Amazon for around $1.2 billion.

Aardvark

Aardvark was a social question-and-answer service that looked like clever automated matching. A user asked a question, and the system seemed to route it to the right expert algorithmically. In the MVP, the team did the matching by hand: humans read each question, decided who could answer it, and coordinated the response in real time. It looked like AI; it was people. The manual work taught them exactly what the algorithm needed to do, and when they built the real matching system, it worked because it was trained on hundreds of human-made matches. Google acquired the company.

CardMunch

CardMunch let users photograph a business card and get a digital contact back, apparently through image-recognition technology. There was no such technology in the MVP. Instead, the photos were sent to people on Amazon's Mechanical Turk service, who read each card and typed the details into the database by hand. Users got accurate contacts and assumed software did it. The illusion validated demand for the product before the recognition technology existed. LinkedIn acquired CardMunch.

"AI" assistants

The Wizard of Oz pattern is everywhere in AI product history. Early AI scheduling assistants, for example, presented themselves as automated agents that booked meetings over email, while humans behind the scenes handled the cases the software could not yet manage. This let the companies ship a working-feeling AI product and learn what real automation had to handle, long before the models were good enough to do it alone. It is also where the ethics get sharp, which we come to shortly.

Wizard of Oz MVPs and AI in 2026

The Wizard of Oz MVP and artificial intelligence have a long, tangled history, and in 2026 the relationship is more relevant than ever. For years, "AI" products were often Wizard of Oz MVPs in disguise: a slick automated front end with humans quietly doing the work, because the technology was not ready. The phenomenon was common enough to earn a nickname, pseudo intelligence: humans pretending to be bots.

What changed in 2026 is that the technology often is ready. You can frequently build a real AI-powered version faster and cheaper than you could fake one a few years ago. That shifts the calculus. The Wizard of Oz MVP is no longer mainly a way to fake AI you cannot build; it is a way to test demand for an AI product before you invest in making the model genuinely good for your specific use case.

There is also a hybrid worth naming: a human-plus-AI back office behind an automated front end. The user sees a finished AI product; behind the curtain, a person uses AI tools to produce the result faster, applying judgment the model still needs. This is a powerful, fast way to validate an AI product, and it blurs the line with the concierge approach. The deciding question remains transparency: in a Wizard of Oz MVP, the user does not know a human is involved, and that is precisely what makes the ethics matter.

The trap, sharpened by AI, is the temptation to fake it forever. Because a convincing AI front end is cheap to build, some companies run a permanent Wizard of Oz, taking money for "AI" that is secretly humans, with no real intent to automate. That is not validation. It is fraud, and it is the thing an honest founder must be careful never to slide into.

The ethics of the Wizard of Oz MVP

This is the section no honest guide to the Wizard of Oz MVP can skip, because this type, alone among MVPs, is built on a deception. The user thinks they are using automated software when they are not. That is fine as a brief test and a problem as a way of life. The line between the two is what every founder running this test needs to understand.

Why a temporary illusion is acceptable. A Wizard of Oz MVP is closer to a film set than a con. You are testing whether a product people want can exist, with every intention of building the real thing. Users get genuine value: their shoes arrive, their question is answered, their card is digitized. No one is harmed, and the manual phase is short. Used this way, the deception is the same kind a magician's audience consents to: the result is real, the method is hidden, and the hiding is temporary.

Where it crosses the line. Three things turn an acceptable test into an unethical one. First, sensitive data: if users believe a machine is the only thing seeing their financial, medical, or deeply personal information, having humans read it secretly is a real privacy violation, not a clever test. Second, no intent to build: taking money for "automation" you never plan to create is fraud. Third, trust damage at scale: if the illusion is discovered, users feel deceived, and that distrust spreads, not just to your product but to the whole category. People who learn their "AI" was fake grow skeptical of real AI too.

How to run it honestly. Keep the test small and short. Protect user data as if a human will see it, because one will, and avoid the method entirely for genuinely sensitive information. Commit upfront to building the real version if the test succeeds. And consider a soft, honest framing where you can: "human-assisted," "early access," or "concierge beta" lets you keep much of the realism while reducing the deception, edging toward the transparent concierge model. The most respected founders treat the Wizard of Oz MVP as a quick, contained experiment they fully intend to make real, never as a permanent disguise.

What to measure in a Wizard of Oz MVP

Because the front end is real, a Wizard of Oz MVP gives you quantitative behavior data, which is its advantage over the concierge approach. Track:

• Conversion: do users complete the core action and pay? This is the headline signal, and it is realistic because the experience feels like a product.
• Activation and repeat use: do they come back and use it again, the way they would with finished software?
• Demand volume: how many requests come in? This tells you whether real automation would have enough load to justify building.
• The manual workload: how long does each fulfillment take, and where is it hard? This reveals what the automation must do and how expensive it will be.
• Where the illusion strains: the moments users notice delays or inconsistency. These are the parts the real product must get right.

You are looking for two things at once: proof that people want the product, and a clear picture of what the automation will need to do.

Pros and cons of the Wizard of Oz MVP

Pros:

• Realistic demand and conversion data. Because users experience a real product, their behavior predicts how they would treat the finished version.
• Validates expensive automation before you build it. You learn whether the costly engine is worth building before spending on it.
• A ready-made specification. Every manual fulfillment teaches the eventual system what to do.
• Fast and cheap to start. A believable front end plus a manual back office is far cheaper than real automation.

Cons:

• It does not scale. Manual fulfillment caps volume, and maintaining the illusion gets harder as demand grows.
• The ethics question. The deception is acceptable only as a short, honest test, and it is a real risk if mishandled.
• The illusion is fragile. Delays or inconsistency can break it and invalidate the test.
• Privacy exposure. Humans see data users may assume only a machine sees.

Common mistakes founders make

1. Faking it forever. Running a permanent Wizard of Oz with no plan to automate. That is no longer a test; it is a business built on a lie that eventually collapses.

2. Ignoring data privacy. Letting humans secretly handle sensitive information users believe is machine-only. Avoid the method entirely for sensitive data.

3. An illusion that is too slow. Promising instant results a human cannot deliver. Set processing-time expectations the manual process can actually meet.

4. Inconsistent output. Hand-delivered results that vary in format or tone tip users off. Standardize everything so it looks machine-made.

5. Not instrumenting the front end. Running the illusion but failing to measure behavior wastes the test's biggest advantage. The realistic front end exists precisely so you can measure real usage. Treating the MVP as the destination rather than a test is one of the core MVP development challenges we see.

Signs your Wizard of Oz MVP is working (and when to stop)

A Wizard of Oz MVP is working when the behavior data points clearly in one direction:

• People convert. Users complete the core action and pay, treating the illusion like a real product. This is the strongest signal, and it is credible precisely because the experience felt automated.
• Demand outpaces your hands. When requests arrive faster than you can fulfill them by hand, you have proof of real pull, and a clear reason to automate.
• The work becomes routine. Each fulfillment starts to look like the last, which means the process is repeatable and the algorithm is knowable.
• Users ask for more. Requests for additional volume or features signal genuine engagement with the product, not just curiosity.

And the clearest sign to stop: when the manual work strains the illusion or eats all your time. Once you are spending every hour fulfilling requests by hand and demand is proven, the test has done its job. Continuing past that point risks the illusion cracking and your time draining away. Build the automation, bring the curtain down, and turn the proven illusion into a real product.

How to graduate from Wizard of Oz to a real product

The Wizard of Oz MVP ends when you can answer two questions: do people want and pay for this product, and what exactly does the automation need to do? The conversion data answers the first; the record of your manual fulfillments answers the second.

When both are clear, you build the real engine, usually starting with a single-feature MVP that automates the one workflow you have been performing by hand. Because you have run the process hundreds of times, the build is grounded in a real specification rather than a guess, which is exactly why the automated version tends to work on the first serious attempt. For where this sits in the bigger picture, see the MVP stage of a startup; for the budget of the build that follows, how much it costs to build an MVP.

There is also an honesty milestone at graduation: once the product is real, the curtain comes down, and the automation users believed in all along finally exists. The temporary illusion becomes a true product, which is the only ending that makes the whole exercise legitimate.

A worked example: a Wizard of Oz MVP in action

To make it concrete, imagine you want to build an AI tool that reviews freelance contracts and flags risky clauses. Building a genuinely good legal-AI model is expensive and slow. The Wizard of Oz version tests demand first.

Build the front end (Step 1). You make a simple web page: upload your contract, get a risk report back. It looks like an automated AI service.

Set up the back office (Step 2). Uploaded contracts land in a private queue. A legal-savvy reviewer (you, or a contractor) reads each one by hand and writes up the risky clauses.

Set expectations (Step 3). The page says "your AI review will be ready within 30 minutes." That window is plausible for an automated tool and gives the human time to work.

Deliver consistently (Step 4). Each report comes back in the same clean, structured format every time, so it reads as machine-generated.

Instrument (Step 5). You watch how many people upload contracts, how many pay the $19 fee, and how many come back with another. Strong conversion is real evidence that an AI contract reviewer has a market.

Learn and automate (Step 6). After fifty reviews, you have a precise picture of which clauses matter, how to phrase the warnings, and what the model must detect. That becomes the spec for the real AI, which you can now build with confidence.

Mind the ethics. Contracts can be sensitive, so you would need explicit terms that a human reviewer is involved, careful data handling, and a real intent to automate. This is exactly the kind of case where a soft "human-assisted review" framing is wiser than a pure hidden illusion. The test still works, with the honesty dialed up.

How HorizonLux helps

A Wizard of Oz MVP is a powerful way to validate demand for an automated product, especially an AI one, before you spend on building the engine. We often advise founders to run one, and we help them set it up honestly: a believable front end, a clean manual process, and a clear plan to automate.

When the test proves demand, we build the real thing: most often a single-feature MVP, shipped funding-ready in 3–4 weeks, built by senior engineers around the workflow your Wizard of Oz run validated, on a clear, scoped quote you approve before we start. You get honest advice on whether to fake it first or build directly, and the team to build the automation when the evidence is in. We will also tell you plainly when the data is too sensitive or the case too risky to fake, and a direct build is the better path.

Validated demand with a Wizard of Oz test and ready to automate? Tell us what you proved and we will build the real product.

Frequently asked questions

What is a Wizard of Oz MVP?

A Wizard of Oz MVP is a validation method where a product looks fully automated to the user, but humans perform the work behind the scenes. The user believes they are using finished software. Its purpose is to test demand and the real product experience before building the expensive automation. The name comes from the wizard in The Wonderful Wizard of Oz, an ordinary man creating an illusion of magic from behind a curtain.

What is an example of a Wizard of Oz MVP?

The classic example is Zappos, whose founder photographed shoes in local stores, posted them online, and bought and shipped each pair by hand when ordered, with no inventory, to prove people would buy shoes online. Aardvark manually routed questions while appearing to use an algorithm, and CardMunch used human transcribers behind an apparent image-recognition app. Each faked automation to validate demand before building it.

What is the difference between a Wizard of Oz MVP and a Concierge MVP?

Transparency. In a Wizard of Oz MVP the manual work is hidden and the user thinks the product is automated, so you test the front end (whether people will use it). In a Concierge MVP the user knows the service is delivered by hand, so you test the back end (what to build). Wizard of Oz suits a known solution you want to test demand for; Concierge suits learning what the product should be.

Is a Wizard of Oz MVP ethical?

It can be, as a short, honest test with the intent to build the real thing. It crosses an ethical line when the data is sensitive (humans secretly reading information users think only a machine sees), when there is no intent to ever automate (taking money for fake automation is fraud), or when discovery would damage user trust. Keep it small, protect data, commit to building, and consider a "human-assisted" framing to reduce the deception.

When should I use a Wizard of Oz MVP instead of just building the product?

Use it when the automation is the expensive, risky part and you want to validate demand before paying to build it. If the real product is cheap and fast to build, it is often better to just build a single-feature MVP. The Wizard of Oz approach earns its keep specifically when faking the hard part lets you prove the market wants it before you invest in the technology.

Does a Wizard of Oz MVP scale?

No, and it is not meant to. Manual fulfillment limits volume, and the illusion gets harder to maintain as demand grows. It is a temporary test, not a business model. Once you have validated demand and understand what the automation must do, you build the real product and retire the manual process.

How is a Wizard of Oz MVP used for AI products?

It is one of the most common ways to validate an AI product: present an automated-looking AI front end while humans, often assisted by AI tools, produce the results behind the scenes. This tests whether people want the AI product before you invest in making the model genuinely good. The ethics matter more here, because faking AI misleads users about the technology itself, so transparency about human involvement and a real plan to automate are essential.

What comes after a Wizard of Oz MVP?

You build the real automation, usually starting with a single-feature MVP around the workflow you validated. Because you have performed the task by hand many times, you have a precise specification, so the automated build is grounded in evidence. Once it is live, the curtain comes down and the product genuinely does what users believed it did all along.

Is a Wizard of Oz MVP the same as a concierge MVP with AI?

Not quite. A concierge MVP is transparent: the user knows a human (possibly AI-assisted) is delivering the service. A Wizard of Oz MVP hides the human behind an automated-looking front end. Both can use AI behind the scenes in 2026, but the defining difference is always whether the user knows a person is involved. That difference is also why the Wizard of Oz approach carries an ethics question the concierge approach does not.

How long does it take to set up a Wizard of Oz MVP?

Often a day or two. Because you build only the front end (a form, a page, or a chat interface) and wire it to a manual queue using no-code tools, there is no real engineering to do. The ongoing cost is your time fulfilling each request by hand, not the setup. That speed is part of the appeal: you can be testing real demand by the end of the week.

Can a Wizard of Oz MVP validate pricing?

Yes, and it is one of its strengths. Because the experience feels like a finished product, charging real money produces a credible read on willingness to pay and price sensitivity. If users pay for what they believe is an automated product, that is strong evidence the real version can command the same price. Just keep the test short and commit to building the automation you are charging for.

Sources and references

This guide draws on established lean-validation research and documented startup histories:

• Learning Loop, Wizard of Oz experiment definition, how it works, pros and cons
• Shortform, Wizard of Oz MVP examples and practical tips
• Wikipedia, Wizard of Oz experiment the origin of the term and method
• Eric Ries, The Lean Startup the validation philosophy behind the technique

Startup examples (Zappos, Aardvark, CardMunch) are widely documented; the 3–4 week figure reflects HorizonLux delivery data for single-feature MVP builds.