The best AI demo I ever saw was a man named Dave with a spreadsheet. The founders showed investors a sleek interface where uploaded invoices got "automatically coded by machine learning." Behind the curtain, Dave read each invoice and typed the codes himself, at superhuman speed and with what I can only describe as theatrical confidence.
Those investors were not deceived about the important part: the workflow was real, the value was real, and the automation did not exist yet. That is wizard of oz prototype software in its natural habitat. The interface is real, the user reactions are real, and the expensive machinery behind it is a human being doing the job until the job is proven worth automating.
It is the cheapest truth serum in product development. Here is how to run one without fooling the wrong people.
The short answer: a wizard of oz prototype puts a human behind a real interface so users experience the actual workflow while you fake the automation. You validate the risky part, whether people will use the thing, before paying for the expensive part, building the machinery. A typical wizard of oz week costs single-digit thousands; the full build it replaces costs six figures.
The human behind the curtain: wizard of oz prototype software, defined
The term comes from the film: impressive spectacle, ordinary machinery underneath. In software, the screen the user touches is real, the workflow is real, and at least one critical step is secretly a person. The user asks for a report; an analyst assembles it in twenty minutes and the system "generates" it. The user submits a request; it routes perfectly because Dave is the router.
This differs from a clickable mockup, where nothing works, and from fake door testing, where the door itself is the experiment and nothing exists behind it. Here you test the whole journey with the machinery replaced by elbow grease.
Why fake it before you build it
The economics are lopsided in a way most roadmaps ignore. In almost every new workflow, the risky part is whether humans will change their behavior to use it. The expensive part is the automation. Teams routinely spend the expensive part to learn the risky part, which is backwards.
This discipline exists to validate the workflow before building the automation. Say you are weighing an automated dispatch-suggestion engine: twelve weeks of build, maybe $120k all-in with integration work. The open question is not whether the algorithm works; it is whether dispatchers trust suggestions enough to act on them. A wizard of oz week, real interface, human generating suggestions behind it, answers that question for perhaps $8k and five days. If the answer is no, you saved $112k and eleven weeks. If yes, you build with evidence and a list of the overrides dispatchers actually wanted.
What to fake and what to build real
The art is choosing where the curtain goes. These rules of thumb hold up.
Build the interface real, always
Users judge what they touch. The screen, the fields, the flow, the latency: all real. A wizard of oz prototype lives or dies on users believing in the experience enough to behave normally, so the front end is where you spend.
Fake the intelligence
Recommendations, classifications, extractions, routing: a person does these. This is usually the most expensive engineering in the real build and the cheapest to fake, because a smart human with the right context outperforms most v1 models anyway.
Fake the integrations
A manual backend prototype means exactly that: CSV exports, copy-paste between systems, a nightly batch that is actually an intern. Integrations are plumbing. Validate that water flows before hiring the plumber.
Never fake the data model
The one thing you build properly, even in week one, is the shape of the data. If the workflow wins, this schema graduates into production. Skimp here and your successful experiment becomes a rebuild.
A wizard of oz week in practice
Day one: ship the interface to a handful of friendly users on the thinnest honest plumbing. Days two through four: run the manual operation behind it, logging everything. What you measure is behavioral, not aesthetic: task completion rate, where people drop off, how often they override the suggestion, which fields they ignore. Day five: retro with the users and the wizards. The overrides list is your v1 backlog; the drop-off point is your design flaw.
One team I watched ran this for a returns-triage workflow. Their day-three log showed something no survey would have caught: agents accepted the suggested disposition for clean cases in seconds but overrode it every time a photo was attached. The automation was fine; the trust model was wrong. That single observation reshaped the build, and it cost one person three days of spreadsheet duty to learn.
This slots neatly into a broader rapid prototyping playbook, and it pairs well with the discipline of the one-week prototype format. A week is usually enough. You are measuring behavior, not statistical significance.
The ethics and the exit ramp
The honest line: deception about machinery is fine, deception about stakes is not. Internal users piloting a new workflow can usually hear "some steps are manual during the pilot," which preserves realism without lying. External users in anything touching money, health, or rights deserve to know a human is in the loop. When in doubt, disclose. "Our team reviews every submission during the pilot" is both honest and, frankly, a selling point.
Set the graduation criteria before you start: "if 70 percent of suggestions are accepted without edits for two weeks, we automate the top three suggestion types." Set kill criteria with the same clarity. The v0 to v1 checklist is a good template for what graduation demands.
When a wizard of oz prototype is the wrong call
Four cases. Safety-critical workflows, where a slow or wrong human behind the curtain can hurt someone. High-volume processes, where Dave cannot type fast enough to simulate the real load. Latency-sensitive flows, where a two-minute human delay teaches you nothing about a two-second user decision. And products where the automation is the value: if you are selling the algorithm itself, faking it tests nothing but your acting.
For everything else, the pattern in the MVP mistakes FDEs see most holds: teams build too much machinery before proving the workflow earns it. Put a Dave behind the curtain first. If users love the show, then you build them a wizard.