Concierge MVP Plan

Sell the Service Before You Freeze the Product

A concierge MVP is an openly high-touch service used to discover the product inside the work. The customer knows the founder is involved. Real inputs arrive, a useful result is delivered, and the founder sees the judgments, exceptions, and trust requirements that software would otherwise hide.

That visibility is the advantage. It is also the danger. A careful founder can rescue bad inputs, remember each customer’s preferences, rewrite weak outputs, and make an uncertain promise feel dependable. Customers may gladly return for that service while providing little evidence that the work can become a repeatable product.

Choose the Right Kind of Manual Test

Use a concierge MVP when the desired outcome matters but the path to it is still unclear: onboarding, data cleanup, analysis, configuration, review, reporting, or another workflow where proximity to the customer will expose the rules. Use the Wizard-of-Oz MVP Plan instead when the question requires customers to encounter a product-like interaction while declared manual operations remain behind it. Neither approach is suitable when the temporary process cannot handle the data, decision, or failure safely.

Begin with the boundary already written on the MVP Experiment Card. The concierge plan adds the service operation: what the customer is promised, what the founder will do, how much can be done, and which observations will change the product decision.

Copy the Plan

Write the plan before inviting customers. One plan should cover one segment, one delivered outcome, and one operating boundary.

CONCIERGE MVP PLAN

Decision this service will change:
What must be learned through manual delivery:
Customer segment and use context:
Include only:
Exclude:
Current alternative:

SERVICE PROMISE
Outcome the customer will receive:
Delivery interval and turnaround:
What the customer must provide:
What the customer must review, approve, or do:
What is explicitly outside the service:
Price, deposit, data access, or other commitment:

DELIVERY BOUNDARY
Manual steps the founder will perform:
Tools, scripts, templates, or product surfaces used:
Quality standard before delivery:
Data, permission, safety, and deletion boundary:
Failure and recovery path:
Support channel and response boundary:

CAPACITY
Maximum customers or deliveries:
Start date, cutoff, and natural return interval:
Maximum founder time per delivery:
Conditions that pause or refuse a delivery:

DELIVERY RECORD — COMPLETE ONCE PER CUSTOMER CYCLE
Inputs missing or repaired:
Steps performed and minutes per step:
Judgments, corrections, and exceptions:
Messages, reminders, and support:
Delivered outcome and customer action:
Payment or commitment observed:
Return request, referral, or abandonment:

DECISION RULES — WRITE BEFORE THE FIRST DELIVERY
Continue the service while learning when:
Narrow the segment or promise when:
Stay manual when:
Automate a step when:
Stop when:
At the cutoff, the next decision will be:

The capacity lines protect the experiment from becoming an accidental agency. The delivery record protects it from becoming theater. If a customer reached value only because the founder repaired the input, supplied missing context, and sent two reminders, those actions belong in the result.

Follow One Delivery All the Way Through

For each cycle, keep inputs, work, output, customer action, and return behavior together. A weekly report that took forty minutes of review is different from one that took forty minutes plus an unrecorded onboarding call and a custom spreadsheet repair. “Delivered” is not the value moment if the customer never uses the result.

Classify the founder’s work after delivery:

• Stable work follows the same rule across customers and may be ready for a script, template, or product feature.
• Segment knowledge reflects a recurring need within the chosen customer group and may deserve a tighter promise or data model.
• Customer-specific work is paid customization or service labor, not automatically a product requirement.
• Rescue work compensates for a weak promise, missing input, confusing flow, or unreliable output. Automating the rescue would preserve the wrong design.

The categories can change as evidence accumulates. A judgment that appears bespoke in the first delivery may reveal a stable rule by the sixth. A step that looks repetitive may still conceal consequential exceptions. The plan should preserve that uncertainty rather than turning every repeated action into a backlog item.

A Worked Concierge Plan

Suppose a founder is testing a weekly client-change digest for small paid-search agencies. Account managers currently export campaign data, compare periods, collect scattered notes, and write explanations for clients. The founder does not yet know whether the valuable product is change detection, explanation, review, or simply relief from assembling the report.

Decision: whether to invest in a narrow weekly-digest product for paid-search
agencies, remain a reviewed service, or stop pursuing this workflow.
Learning need: observe how raw exports become claims an account manager will
approve and send, including the corrections and context each claim requires.

Segment: agencies with five to twenty active clients that already send a
weekly performance update. Exclude agencies without a weekly reporting rhythm
and campaigns requiring unsupported data sources.
Current alternative: the account manager compares exports and writes the
client explanation by hand.

Promise: by Thursday afternoon, deliver a reviewed draft that identifies the
largest relevant changes, links each claim to source rows, and is ready for the
account manager to correct and approve. The manager uploads the agreed CSVs and
a short context note by Wednesday noon. The manager, not the founder, approves
and sends all client-facing text.
Outside the service: live integrations, automatic sending, budget changes,
cross-channel reporting, and claims that cannot be supported by supplied data.
Commitment: a paid two-cycle trial and permission to record workflow timings,
corrections, and whether the digest was sent.

Delivery: validate the exports; compare the agreed measures; draft and
source-link the changes; review every claim; deliver an editable digest; record
manager corrections and whether the digest was sent. Source files stay within
the agreed storage and deletion period. If an export is incomplete or a claim
cannot be supported, omit the claim and mark the gap rather than improvising.

Capacity: four agencies, two weekly cycles each, no more than ninety founder
minutes per digest. Pause an account when the inputs arrive late, fall outside
the supported format, or contain data the trial is not prepared to handle.

Continue if managers send the digests and return for the second cycle while
the work exposes recurring rules. Narrow the segment or input contract if
cleanup dominates. Stay manual if customers value the result but the decisive
work remains expert judgment they will pay for. Automate a step only after its
inputs, rule, failure state, and review point recur. Stop the product direction
if managers do not send the result or will not repeat the paid workflow.

These limits are decisions for this experiment, not benchmarks for concierge MVPs. Their purpose is to make the result interpretable. Four satisfied customers do not prove software economics. They may prove a valuable service, expose a narrow product, or show that the founder has been doing the work customers decline to own.

Close the Service Before Extending It

At the cutoff, compare customer behavior with founder labor. Repeat use and payment establish that the delivered outcome has value. They do not establish which portion should become software.

Automate when a step repeats under stable rules, consumes meaningful capacity, and can fail visibly without weakening trust. Stay manual when judgment is part of the value, the volume is manageable, or the exceptions still teach more than implementation would. Narrow when one segment, input shape, or outcome produces coherent work while the rest remains bespoke. Stop when customers will not commit or return, the service cannot be delivered responsibly, or founder rescue creates most of the apparent value.

If the service continues, transfer its recurring operation into the Manual Workflow Plan so every step has an owner, quality check, and evidence record. If automation is earned, choose one stable step and state what manual review remains. The concierge MVP has finished its job when the founder can distinguish a product rule from a service habit—and act on the difference.