Visit Website →
← Back to blog

Turn a Wizard of Oz MVP Into a Developer Ready Spec for Founders & PMs

September 20, 2026
Turn a Wizard of Oz MVP Into a Developer Ready Spec for Founders & PMs

A Wizard of Oz MVP is a test where the front end looks like a real product but every task behind it gets done by a person, not code. You build the screen, you play the algorithm. It exists to prove people want the outcome before you spend a dollar automating it, and it fits best when the idea depends on something expensive to build, like matching logic, AI processing, or a complex backend workflow.

TL;DR:

  • Wizard of Oz MVPs are best suited for testing user demand for automated features before investing in expensive development.
  • These tests typically involve manual work behind a simple, believable interface to evaluate real user interactions at scale.
  • Key metrics to watch are repeat requests, paid conversions, and time-to-delivery, with automation justified once 10 to 20 users request the same output repeatedly.
  • Avoid inflated service by maintaining consistent responses and transparently disclosing manual review to preserve user trust.
  • An effective manual run provides a precise, evidence-based specification to guide future automation efforts and product development.
Klaritea
Turn MVP Evidence Into Clarity
Klaritea helps founders structure ideas, test assumptions, and create a connected model before investing in actual building.
Explore Klaritea

Table of Contents

What Is a Wizard of Oz MVP, and How Does It Differ From Similar Tests?

The term comes from pretotyping research and borrows its logic from Amazon Mechanical Turk: humans quietly perform work that a computer will eventually do, while the user believes they're interacting with software. You are not testing whether you can build the algorithm. You are testing whether anyone wants what the algorithm would produce.

It gets confused with two other tests constantly. A concierge MVP puts a real human in front of the customer, no illusion involved, like a stylist who personally emails you outfit picks. A fake-door test measures interest with a button or ad that leads nowhere. Wizard of Oz sits between them: the interface is real and usable, but the labor behind it is faked entirely by a person.

Comparison of three MVP validation tests

Most founders build the front end with a landing page, a Typeform or Carrd form, or a clickable Figma prototype. The goal isn't polished. It's believability. A form that looks intentionally rough but functions cleanly often converts better than one that looks half-finished.

The Step-by-Step Playbook for Running a Wizard of Oz Test

Running one well takes structure, not just enthusiasm. Here's the sequence that keeps a manual test from collapsing into chaos.

  1. Pick one target user and one workflow. Resist testing three personas or two features at once. Narrow scope is what makes a manual process survivable for a small team, a discipline covered in more detail in defining MVP scope before you build anything.
  2. Design a believable front end. A simple intake form, a chatbot-style interface, or a scheduling page works fine. Keep copy specific ("Get your report in 24 hours") rather than vague, since specificity is what makes users trust an unfamiliar tool.
  3. Build the manual backend. A shared spreadsheet with columns for request ID, timestamp, user input, assigned wizard, output delivered, and time spent is usually enough. Add routing rules so requests land with the right person automatically, even if a human still does the work.
  4. Set delivery SLAs and capacity limits. Promise a turnaround you can actually hit, whether that's same day or a 24 to 72 hour window depending on the task, and cap how many requests you'll take per day so quality doesn't slip.
  5. Recruit 5 to 20 qualified users and run the pilot. Small pilots in that range are enough to spot repeated patterns without drowning your team in manual work, according to guidance from Felix Lenhard's writeup.
  6. Log every judgment call the wizard makes. Write down the exceptions, the edge cases, the moments someone had to improvise. That log becomes your automation spec later.

Pro Tip: Write a script for the wizard before the first real user shows up. Consistent responses matter more than clever ones, because inconsistency is what tips users off that something manual is happening behind the screen.

When to Use Wizard of Oz Versus Concierge MVP

The core difference is visibility. Wizard of Oz hides the human behind a product-like interface; concierge testing puts the human front and center as the service itself. That distinction should drive which one you pick, based on the comparison Netguru draws between the two approaches.

Choose Wizard of Oz when you need to observe how people behave inside an actual product flow, not how they behave with a person.

  • You need UX signal: does the layout, copy, and interaction pattern actually work for users at scale?

  • The eventual product will be self-serve, so a human-fronted experience would mislead your data.

  • You're testing willingness to use software, not willingness to work with a person.

Choose concierge when the goal is learning the workflow itself, not the interface.

  • You don't yet know what steps a "solution" even involves, and direct contact surfaces that faster.
  • You're comfortable being visibly hands-on early, before there's any interface to test.
  • The audience is small enough that white-glove service scales for a few weeks.

Metrics and Signals That Tell You When to Automate

Three numbers matter more than anything else after delivery: repeat requests, paid conversions, and time-to-delivery, the same core metrics Agile Alliance highlights for validating an MVP without vanity noise. If people come back or pay without being asked twice, you have signal worth acting on.

The threshold that actually matters: once 10 to 20 users are requesting the same output repeatedly, or paying for it, the manual process has proven demand. That's your cue to start automating, not before.

Operational metrics tell you what to automate first, not whether to automate at all.

  • Average minutes per request, tracked per persona if consumer and enterprise users behave differently.
  • Percentage of steps that repeat identically across requests, since repeated steps are the cheapest wins for automation.
  • Error rate and rework frequency, which flags where a script or template is missing.

Rank your backlog by frequency times time cost. The step eating the most hours across the most requests goes first, everything else waits.

Pitfalls, Ethics, and Guardrails That Keep Tests Trustworthy

The most common failure isn't getting caught, it's "inflated service," where the human wizard quietly does more than automation ever could, described well in Exponentially's breakdown of the technique. Users fall in love with a version of the product you can never actually ship, then feel cheated when the real thing launches thinner.

Ethically, the line is simple: describe outcomes honestly, never fake the mechanism behind something regulated or safety related. Felix Lenhard argues that Wizard of Oz isn't inherently deceptive, as long as you disclose manual review wherever privacy, health, or financial claims are involved.

Inconsistent wizard responses and missed SLAs are the two operational failures that erode trust fastest.

Pro Tip: Keep a written script for common request types and update it weekly. A wizard improvising fresh answers every time is the single fastest way to poison your own data.

Pitfalls, Ethics, and Guardrails That Keep Tests Trustworthy — overview diagram

Real Examples Worth Modeling

A consumer matching app can run entirely on a form plus a person manually pairing users overnight. The lesson from that kind of test is almost always the same: automate the ranking logic, never the interface, because the UI rarely needs to change.

An AI-analysis report service that delivers results by hand for the first few weeks learns something code can't tell you: which sections of the report customers actually open, forward, or ask questions about.

  • Manual matching services routinely surface messy input data long before automation does, and that becomes the first thing worth building.
  • Report-delivery tests reveal which outputs justify a price tag, since users often ignore half of what a report contains.
  • Recommendation apps show which signals (location, timing, price) actually drive a chosen match, guiding what the eventual algorithm should weight.

Your Operational Checklist for the First Test

Before recruiting a single user, write down six things: target user, core workflow, intake fields, delivery SLA, capacity limit, and the columns you'll log for every request.

  1. Build a spreadsheet with request ID, timestamp, input data, assigned wizard, time spent, and outcome delivered.
  2. Add a routing rule so requests default to whoever's on shift, rather than getting stuck in a shared inbox.
  3. Review the log weekly and tag anything that took longer than expected or needed a judgment call.

Turn those tags into backlog items using a simple rule: capture the exact input, measure how often it repeats, encode the decision the wizard made, then automate whatever combination of frequency and time cost ranks highest. For more on sequencing that backlog against a real launch date, see this release planning guide for a first MVP launch. Tools built for lightweight operations dashboards, like the workflows covered on Gainable's blog, can help once the spreadsheet starts to strain.

Why the Manual Phase Writes a Better Spec Than Any Planning Meeting Ever Will

The best product specs I've seen weren't written in a planning doc. They came from someone manually doing the work, hitting an edge case, and writing down exactly how they handled it. That's the real value of running things by hand first: it forces precision that whiteboarding never does. A structured phase zero, the kind Klaritea builds around a one line idea, doesn't replace that manual run. It makes the automation backlog you pull from it sharper, because the ICP, features, and build spec are already connected before you write a single automation ticket.

— Karl

Turn Your Manual Backlog Into a Build Spec Before You Write Code

Running a Wizard of Oz test tells you what to build. It doesn't organize that knowledge into something a developer, or an AI coding tool, can actually execute against. That gap between "we learned this manually" and "here's the spec" is exactly where Klaritea sits.

Klaritea

Type your one-line idea into Klaritea and it builds a connected model covering your ICP, TAM/SAM/SOM, competitors, features, and requirements, the same categories your manual test just generated real evidence for. AI advisors then stress-test the plan for marketing, business, and operational gaps before you spend resources building. The Free plan costs nothing to start, and paid tiers run $19 a month for Klaritea or $99 a month for Pro, with credit packs from $15 for 750 credits up to $99 for 5,650 if you need more advisory runs. Convert your automation backlog from this article into a structured build spec on the Klaritea pricing page before you write your first line of code.

Sources

For deeper context on validation methodology, review the Agile Alliance's MVP glossary entry, the Nielsen Norman Group's UX-focused setup guide for research protocols, and Felix Lenhard's practitioner writeup on ethics and pilot sizing.

FAQ

What Comes After an MVP in Agile Development?

After an MVP validates demand, teams typically move into incremental delivery, adding features based on user feedback and usage data rather than a fixed roadmap. In a Wizard of Oz context, that next phase usually means automating the highest frequency manual steps first, guided by the MVP idea-to-timeline planning process.

Is a Wizard of Oz MVP Just a Demo?

No. A demo shows what a product could do, while a Wizard of Oz MVP actually delivers real outcomes to real users, just with a human doing the work behind the scenes. Users complete genuine tasks and get genuine results, which is what makes the data trustworthy.

What Are Examples of Successful MVPs Built This Way?

Early versions of matching and recommendation apps have used manual curation behind a simple form to prove demand before building ranking algorithms. Report-delivery services have hand-built early outputs to learn which content sections customers actually value before investing in generation logic.

Why Do People Reference "The Wizard of Oz" for This Testing Method?

The name nods to the film's plot twist: the powerful wizard turns out to be an ordinary person operating machinery from behind a curtain. The technique borrows that exact structure, a person quietly running the "magic" while the user believes they're dealing with automated software.

How Is Wizard of Oz Different From a Concierge MVP?

Wizard of Oz hides the human behind a product interface, while concierge testing puts the human in plain view as the service itself, a distinction Netguru details clearly. Pick Wizard of Oz when you need to validate a self-serve interface, and concierge when you're still learning what the workflow even involves.