Concierge Test¶
Manual value probe — instantiates Minimum Viable Learning Release
Delivers the promised outcome entirely by hand, before any product exists, to learn whether the value is real and wanted.
A Concierge Test delivers the promised outcome to real users entirely by hand — no product, no automation — so the team can learn whether the value is genuinely wanted before building anything. Its defining move is that the "release" is human labour standing in for the system that does not yet exist: the viable value threshold is met by people, not code. That inversion is its whole reason to exist — it lets you learn whether the outcome matters before you spend anything on the infrastructure to produce it at scale. The catch, and the thing that makes it honest, is that the manual effort must be explicitly named and bounded, because a concierge test can only ever validate value, never scalability; the heroic effort behind the curtain is exactly what a scaled version will have to reproduce, and usually cannot.
Example¶
Two founders think travellers will pay for hand-curated trip itineraries. Before writing a line of software, they offer 15 early users a custom multi-day plan built entirely by hand — hours of research per trip, delivered over email as a tidy document. Users experience a real, high-quality outcome; the founders experience exactly how much manual work each one costs. They watch the only signal that matters this early: do people come back for a second trip, refer a friend, or agree to pay? The value threshold is met by two humans burning weekends, and they say so plainly in their own notes — "this is us, by hand, and it does not scale." Only once repeat requests and a few paid conversions confirm the value do they consider what a product would even need to automate.
How it works¶
- Pick the outcome, not the interface. Decide what result to deliver, then produce it by whatever manual means works.
- Serve a few real users by hand. Do the work personally for a small number of genuine users who experience a real result.
- Keep the labour visible and bounded. Log the manual effort so the team never forgets what it is standing in for.
- Read whether the outcome is wanted. Repeat use, referral, or willingness to pay — the demand signal, cleanly separated from any question of scale.
Tuning parameters¶
- Manual intensity — how much is done by hand versus lightly tooled; more hands-on makes the value real but the effort less repeatable.
- Concealment — whether users know it is manual (open concierge) or not (a hidden, faked backend); concealment tests a purer demand signal but raises its own honesty questions.
- User count — a handful gives depth and demand signal; more strains the manual model and blurs the point.
- Runway — how long the team is willing to sustain the manual effort before it must decide to build or drop.
When it helps, and when it misleads¶
Its strength is validating demand at almost zero build cost: you learn whether the outcome matters before committing to the infrastructure to deliver it. Its signature failure is the manual-support illusion — a close cousin of the fully-hidden Wizard-of-Oz test[n1] — where extraordinary hidden effort makes the early result look viable in a way the automated product could never reproduce, so "people loved it" gets misread as "it will work at scale." The guarding discipline is to name the support boundary out loud and to label every positive result precisely: value validated, scale still unproven.
How it implements the components¶
viable_value_threshold— met by human effort, proving the outcome is genuinely valuable independent of any system that would eventually produce it.support_boundary— the manual labour is logged, bounded, and named as temporary, so value is never confused with scalability.learning_signal— reads whether the hand-delivered outcome is actually wanted, through repeat use, referral, or payment.
It operates no real_context_release over a participant_or_rollout_boundary — that staffed, real-population delivery is Pilot Service — and it ships no minimum_viable_scope artifact for users to run themselves, which is Alpha Release. It also commits no expansion_or_pivot_criteria, leaving the build-or-drop bar to Minimum Viable Product.
Related¶
- Instantiates: Minimum Viable Learning Release — the concierge test is the earliest, most manual instance: value first, product never yet.
- Sibling mechanisms: Minimum Viable Product · Pilot Service · Alpha Release · Limited Cohort Rollout · Small-Batch Policy Pilot · Minimum Viable Process · Feature-Flag Release
Editorial Notes¶
Form Classification¶
Form family: Experiment, Test & Rehearsal
Rationale: Delivers the promised outcome entirely by hand, before any product exists, to learn whether the value is real and wanted, making its operative form a bounded trial, probe, simulation, or adversarial exercise that generates evidence from performance.
Independent corroboration: The frozen evidence defines Concierge Test as 'Delivers the promised outcome entirely by hand, before any product exists, to learn whether the value is real and wanted', so its operative form is Experiment, Test & Rehearsal.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Innovation & Entrepreneurship
Origin pattern: Single lineage
Present-day reach: Specialized
Rationale: Lean-startup practice cohered manual delivery of a proposed outcome to real users before building the product, isolating value from scalability.
Related originating lineages:
- Human-Computer Interaction — Wizard-of-Oz prototyping supplies the neighboring lineage of human labor standing in for unbuilt automation.
Review resolution: The named test cohered in lean-startup practice as manual delivery of a proposed outcome before product automation. HCI's earlier Wizard-of-Oz prototype is a genuine neighboring lineage, but its focus on interaction simulation differs from the concierge test's value validation, so single-lineage and specialized reach are retained.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
The concierge test is usually the first mechanism in a sequence: it de-risks the demand question so a later Minimum Viable Product is built only for an outcome already known to be wanted. Skipping it means an MVP can only tell you the core loop failed after you built it.
[n1] Wizard-of-Oz test — a near-cousin in which the manual backend is fully hidden from the user, who believes an automated system is responding. The concierge test differs mainly in that the hand-delivery is often acknowledged; both share the risk that hidden human effort flatters a result the automated version cannot match. ↩