Wizard-of-Oz MVP Plan

Test the Interaction, Not the Magic

A Wizard-of-Oz MVP gives the customer a product-shaped path while a founder operates part of the machinery behind it. It is useful when the unanswered question depends on the interaction itself: will someone submit the request, trust the result enough to use it, recover from a problem, and return for another run?

The backstage work may be unobtrusive. Material facts may not. A customer need not watch the founder move a request through a queue, but must know when human review changes data access, confidentiality, turnaround, professional responsibility, or the authority of the result. The product may simplify its mechanics; it may not create false confidence about privacy, safety, capability, or automation.

When the Interface Is the Question

Use a Concierge MVP Plan when open collaboration with the customer will reveal the workflow. Use this plan when a stable product surface is necessary to observe self-service behavior while declared manual operations remain behind it. Do not use either approach when a temporary process cannot handle the data, decision, or failure responsibly.

Copy the Control Plan

Write one plan for one user path and one decision. Bring the boundary from the MVP Experiment Card, then describe the visible experience and backstage operation as one system.

WIZARD-OF-OZ MVP PLAN

Decision this experiment will change:
Customer segment and current alternative:
Value moment:
First action and natural return interval:

VISIBLE EXPERIENCE
Request the user makes:
Result the product returns:
Status, delay, and failure the user can see:
Actions the product must never imply it completed:

DISCLOSURE AND USE BOUNDARY
Human involvement the user is told about, and where:
Data people may inspect, why, and for how long:
Consent, permission, review, or approval required:
Excluded inputs, customers, decisions, and uses:

BACKSTAGE OPERATION
How a request enters the manual queue:
Founder steps, tools, and expected minutes:
Quality check before release:
How the result returns to the correct account:
Recovery path for late, incomplete, or unsafe work:

CAPACITY AND PROMISE
Service hours and honest turnaround:
Maximum open requests and requests per day:
Condition that pauses intake or disables the feature:

RUN RECORD — COMPLETE FOR EVERY REQUEST
Request, user, and timestamps:
Manual steps, corrections, judgments, and exceptions:
Result released, rejected, or returned for more input:
User action after the result:
Support, trust concern, and founder minutes:
Unprompted return at the natural interval:

DECISION RULES — WRITE BEFORE THE FIRST REQUEST
Continue the test while:
Narrow the promise or segment when:
Automate one step when:
Keep a step manual when:
Stop when:
At the cutoff, the next decision will be:

Protect Every Handoff

The visible experience and backstage operation should join at explicit handoffs. Every accepted request must enter a queue. Every released result must belong to the requesting account. Every promise of progress needs a state for delay or failure. If the founder becomes unavailable, the product should stop accepting work or show an honest delay; it should not leave requests pretending to run.

Follow One Request Through the System

Suppose a founder is testing inbox triage for small online retailers. A support lead connects a shared inbox, opens a product queue, and receives a proposed category, urgency, and draft reply for each new message. The unanswered question is whether the lead will review those suggestions, resolve tickets through the queue, and return on the next support shift.

During a ten-day test, the founder classifies messages and prepares drafts behind the interface. Onboarding says that the founder will review message content to operate the private pilot; it also states the storage and deletion period. The product never sends a reply. It labels each response as a draft, names the supported message types, and requires the support lead to approve, edit, and send through the retailer’s existing help desk.

Requests enter a private queue tied to the correct retailer. Before releasing a suggestion, the founder checks the account, source message, category, urgency, unsupported claims, and whether the draft asks the customer for information that is already present. Ambiguous payment disputes and threats are returned as “needs owner review” rather than forced through the promised flow. If the queue reaches twelve open tickets or the founder cannot meet the two-hour service window, intake pauses and the interface directs the lead back to the existing inbox.

Those numbers bound this experiment; they are not benchmarks for another product or founder. Their purpose is to keep the service promise credible and the result interpretable.

For each ticket, the founder records handling time, classification changes, draft edits, exceptions, support questions, and the lead’s next action. The return signal is not that a draft appeared. It is that the lead resolves supported tickets through the queue on a later shift without a founder reminder.

This run can expose several different truths. Repeated category rules may deserve automation. Retailer-specific tone may remain configuration. A recurring judgment about refunds may require an explicit policy supplied by the customer. Founder rewrites that rescue vague output reveal a weak product path, not an automation backlog.

Automate an Observed Rule

Volume alone does not earn software. A manual step is ready for automation when its inputs are known, its rule recurs, its output can be checked, and its failure can be shown or recovered without silently weakening trust. Automate one such step and keep the review point until evidence justifies removing it.

Keep the step manual when judgment is part of the value, exceptions still change the model, or the cohort is too small to reveal a stable rule. Narrow the experiment when one segment or request type produces coherent work and the rest requires rescue. Stop when customers do not return, the product-shaped path adds no useful evidence beyond a concierge service, the capacity promise cannot be sustained, or responsible disclosure makes the intended experience unacceptable to the customer.

A Wizard-of-Oz MVP succeeds by making a product decision possible. It may justify a narrow automation, a longer manual operation, a different interface, or no product at all. The plan is complete when each outcome has a named consequence before the founder starts performing the result by hand.