In the early days of one of the most successful food delivery services, the founders personally answered every order by phone, drove to restaurants themselves, and delivered the food in their own cars. The customer-facing experience looked like a slick technology operation. Behind the scenes, it was three people running around a city with bags of food.
That’s a Wizard of Oz MVP. The customer sees a polished curtain. Behind the curtain, there’s a human frantically pulling levers. And it works — not as a permanent model, but as the fastest possible way to validate whether customers want the end result you’re promising.
I used variations of this approach at Vulpine Creations and recommended it to dozens of startups at the Startup Burgenland accelerator. It remains one of the most effective strategies for testing a business idea quickly, cheaply, and honestly.
How It Differs From a Concierge MVP
The concierge MVP and the Wizard of Oz MVP are often confused. The difference is transparency:
Concierge MVP: The customer knows you’re delivering manually. “I’m personally creating your meal plan this week while we build the automated tool.” Full transparency.
Wizard of Oz MVP: The customer interacts with what appears to be an automated system, but you’re doing the work behind the scenes. They submit a request through a website; you manually process it and return the result as if software generated it.
Both are valid. The concierge approach is more honest. The Wizard of Oz approach produces a more realistic test of the actual product experience — because the customer doesn’t adjust their behavior based on knowing it’s manual.
Which to use depends on your situation. If transparency builds trust with your audience (common in B2B), use concierge. If the perception of automation is part of the value proposition (common in consumer tech), use Wizard of Oz.
When to Use This Approach
The Wizard of Oz MVP is ideal when:
Your product concept requires technology that takes months to build. Instead of building the AI, the algorithm, or the automation first, simulate the output manually. Test whether customers want the output before investing in the machinery that produces it.
You’re not sure what the right solution looks like. When you deliver manually, you can adjust the output in real time based on individual customer reactions. This produces rapid learning about what works that pre-built software can’t match.
You need to validate willingness to pay before building. If people pay for the result when it’s manually produced, they’ll pay when it’s automated. The reverse isn’t always true — sometimes the manual version is actually better because it includes human judgment the automated version lacks.
Your runway is short. Building software costs time and money. The Wizard of Oz approach costs only your time. If you need to validate fast, this is the fastest path.
Designing Your Wizard of Oz MVP
Step 1: Define the Customer Experience
Design the front-end experience as if the product were fully built. What does the customer see? How do they interact? What do they receive?
This doesn’t mean building a fully functional interface. It means having a clear description of:
- How the customer submits their request (a form, an email, a website)
- What the output looks like (an email, a document, a dashboard display)
- How long it takes (your manual processing time, presented as “our system’s analysis time”)
- What they can expect (format, level of detail, accuracy)
Step 2: Build the Minimum Front End
You need just enough of a front end that customers can interact with your product naturally. Options:
- A Typeform or Tally form that collects their input
- A simple website with a submission field
- A Slack or WhatsApp integration where they send messages
- A Google Form that feeds into a spreadsheet you monitor
The front end doesn’t need to be beautiful. It needs to feel real enough that the customer behaves naturally. If they know it’s manual, their behavior will adjust, and your test becomes less reliable.
Step 3: Design Your Manual Process
This is where the actual work happens. For each customer submission:
- Receive the input (automated — the form/email comes to you)
- Process it manually (you do the work — research, analysis, creation)
- Format the output to look like automated output (consistent format, professional presentation)
- Deliver it within the promised timeframe
Document your process meticulously. Every step you perform manually is a specification for the eventual automated system. The manual process IS the product specification — it’s just written in “what I do” rather than “what the software does.”
Step 4: Set Capacity Limits
You can only manually serve a finite number of customers. Be explicit about this. “Limited to 20 beta users” is both honest about your capacity and creates scarcity that drives sign-ups.
Don’t try to serve 100 customers manually. The point is validation, not scale. Ten to twenty customers is enough to determine whether the product delivers value and whether people will pay for it.
What You’re Learning Behind the Curtain
The manual work isn’t just delivery — it’s research. Every customer you serve manually teaches you:
What information they actually provide. Customers will fill out your intake form differently than you expected. Some fields they’ll leave blank. Others they’ll write novels in. This tells you what they think is important (and what they don’t).
What output they actually value. You’ll produce a deliverable. They’ll use part of it and ignore the rest. The part they use is your core feature. The part they ignore is a candidate for subtraction.
Where the edge cases are. Automated systems need to handle every scenario. Manual delivery reveals which scenarios are common (must automate) and which are rare (handle manually even at scale).
What the real processing logic is. When you manually process a request, you’re making dozens of small decisions. “This customer seems more advanced, so I’ll skip the basics.” “This input is ambiguous, so I’ll interpret it as X.” Each of these decisions needs to be encoded into the automated version. The manual phase reveals what they are.
This learning is far more valuable than anything you could spec in advance. It’s the reason I tell founders: ship ugly first, and let real usage teach you what to build properly.
The Ethics Question
Is it dishonest to present a manual process as an automated one?
I think about it this way: the customer is paying for an outcome, not a mechanism. If you promise “a personalized marketing plan delivered within 24 hours” and you deliver exactly that — a personalized marketing plan within 24 hours — the customer received what they paid for. The fact that it was created by a human rather than an algorithm doesn’t diminish the value.
Where it becomes problematic: if you specifically claim AI or automation as a selling point. “Our AI analyzes your data and generates insights” is a factual claim about the mechanism. If the mechanism is actually you with a spreadsheet, that’s misleading.
The solution: describe outcomes, not mechanisms. “You’ll receive personalized marketing recommendations within 24 hours based on your business data.” True regardless of whether a human or software produces it.
When to Drop the Curtain
At some point, you need to either build the real system or be transparent about the manual process. Here are the indicators that it’s time:
- Demand exceeds your manual capacity. You’re turning away customers because you can’t process fast enough.
- The manual process is stable and predictable. You’ve done it enough times that every step is documented and consistent.
- You have revenue to fund development. The Wizard of Oz phase should generate enough revenue to fund at least a basic automated version.
- Customer expectations are increasing. As your customer base grows, they’ll expect features (history, real-time updates, integrations) that require real technology.
When you transition, be honest with your existing customers. “We’ve been delivering this manually to ensure quality. We’ve now built the automated system based on everything we learned.” Most customers will appreciate the care and craftsmanship. Some of your best customer testimonials may come from this transition moment.
Takeaways
- The Wizard of Oz MVP simulates automation with manual work behind the scenes. The customer gets the same outcome; you learn faster than any build-first approach.
- Design the front end first. What does the customer see and do? Make this feel real. The back end is you with a spreadsheet.
- Cap your capacity at 10-20 customers. This is validation, not scale. Enough to learn, small enough to deliver manually.
- Document every manual step. Your process IS your product specification. Every decision you make manually needs to eventually be encoded in software.
- Describe outcomes, not mechanisms. “You’ll receive X within Y hours” is honest. “Our AI does X” when it’s actually you is not.
