Wizard of Oz MVP

Features that run by themselves are expensive to build. Adding one that reads an uploaded document and returns a summary means designing the processing flow and tuning output quality, and two months go by. The trouble is that shipping after those two months and finding nobody uses it is not a rare outcome. At that point you can't even separate whether the feature was weak or whether nobody wanted the idea in the first place.

So teams tried asking first, and asking didn't work. Pose the question — "would you use a feature that summarizes documents you upload?" — and nine out of ten say yes. There's no reason to say no to a question that costs nothing and takes no time. Ship the thing and three of the hundred people you invited try it once and never come back. The gap always got summarized the same way in meetings: everyone says they'd use it, and you can't bet two months of engineering on that answer.

A Wizard of Oz minimum viable product (MVP) imitates the feature instead of building it. The screens the user sees are identical to what an automated product would show, and the actual work happens by hand out of sight. The user behaves as though using automated software, and the team watches that behavior without writing the automation. The name comes from the novel's wizard, who looked enormous while working the machinery from behind a curtain.

Pin down what you're checking in one sentence, then build only the surface that checks it. Six steps.

1. Write the hypothesis as a single sentence. A hypothesis is a guess written so it can come out true or false. "A user who uploads meeting notes and gets a summary uploads again the following week" carries its own measurement inside it.
2. Build only what the user sees. An upload screen, a processing indicator, and a result screen usually cover it. Unlike a prototype, this thing actually works — real results arrive and users put them to use.
3. Decide who handles requests and what turnaround you promise. Operating hours of 10 to 7 on weekdays with a thirty-minute response commitment is a normal shape. Because you aren't telling anyone a person is involved, that promise has to hold.
4. Give the person doing the work a separate console. A queue of incoming requests and a field to type the result into is enough. Skip it and start editing the database directly, and every slip shows up on the user's screen.
5. Cap the inflow. Set a ceiling of thirty requests a day and invite forty early adopters — the users who will try something rough before it's polished. Without a cap, the human side breaks before the product learns anything.
6. Decide what you're measuring before you start, and log it. Record how many people made a second request and what kinds of documents came in. A retention reading, which tracks whether people come back at all, sits closest to the answer.

It works best when building is expensive and demand is uncertain. Checking a two-month feature with a two-week imitation drops the cost of being wrong from two months to two weeks. It also fits when output quality is the hypothesis itself: if the open question is whether people keep using summaries once the summaries are good, human-written summaries can answer that question first.

Where it doesn't fit is equally clear. A feature that has to respond within a second can't be faked by someone sitting behind it. Neither can anything handling personal data or contracts that outsiders must not read — looking at that material without disclosing that a person reads it breaks your own terms of service and is grounds for a complaint. It also can't test scale. Thirty requests a day running smoothly says nothing about thirty thousand.

The ceiling comes from the human labor. Cost climbs in step with volume, so the arrangement collapses at some line no matter how well it started. That's why these runs are time-boxed from the start: pick two weeks or four, build if the answer arrives inside that window, and drop it if it doesn't.

Sibling methods answer different questions. With a concierge MVP the user knows a person is doing the work, which leaves you with a lot of conversation. A landing page MVP puts up a page with no product behind it and measures interest and nothing further. Pick the Wizard of Oz version when you want to see how people behave while using what they believe is automated software.

"Let's run this as a Wizard of Oz for two weeks and decide after."

A proposal to put up the surface and read the reaction before committing build time.

"It's a Wizard of Oz — can we promise twenty minutes? What about requests that land at 3 a.m.?"

Pointing out that a human-powered version needs operating hours and a response promise settled up front.

"We can't use the satisfaction scores from the Wizard of Oz run. Those summaries were written by people."

A warning that automation won't reproduce the quality a person produced by hand.

Pagedeck checked its automatic document summary feature this way. Mia built an upload screen, a processing indicator, and a result screen, then invited forty users. Uploading a document triggered a notification twenty minutes later, and during those twenty minutes Mia and an intern read the file and typed the summary in. Theo wrote no summarization code at all during the run.

What survived after two weeks changed the plan. Twenty-six of the forty uploaded more than once, so demand was real, but almost everything uploaded turned out to be meeting notes. A plan to summarize every kind of document narrowed to a feature shaped around meeting notes, and the build estimate dropped from two months to three weeks.

The most common misreading is that this is the cheapest option because no code gets written. Looking only at the absent automation, that seems right. But the surface and the operator console still have to be built, and above all a person attaches to every single request. Thirty a day is one person's whole day; four weeks of it is one person's month. Teams that leave this out of the estimate watch a two-week experiment stretch to six while the operator burns out, and they stop before an answer arrives.

Reading the resulting numbers as future metrics is the other frequent mistake. Summaries a person wrote with time to spend are usually better than what fresh automation produces. Collect a 4.5 satisfaction score, expect the same score after automating, and you'll see low threes at launch and go hunting for the cause in the wrong place. This method answers whether demand exists, and quality targets get set again once the automation is in.