Concierge MVP experiment

We're building a comprehensive knowledge library about product development as part of our mission. The library is for anyone looking to make better decisions — primarily decisions about product development. Whether you're an inventor, a product manager, or a Chief Product Officer, using the right research methods and experiments increases your chances of building the right things for the right audience. Today we'll introduce the Concierge MVP validation method.

When to Use This Experiment?

The Concierge MVP method makes sense when real product value can be delivered by hand, through human effort, before any product — often software — even exists. It also provides evidence that people want that value offering and are willing to pay for it.

• Direct contact with users is needed to uncover their real language, pains, and purchase and automation opportunities triggers.

• When it's unclear which part of the product delivers the most value.

• The development team's capacity is limited and it's worth getting evidence the product works before any code is written.

• The job involves multi-step activities, often offline, that a simple prototype can't imitate.

• When evidence of the product's value is needed before a more complex test.

Basic Experiment Principles

The idea is simple. Instead of building the product, the tester becomes the product — delivering the outcome personally and by hand to a handful of early users, while recording everything learned along the way.

1. Define the single outcome to deliver. Describe one concrete result (for example, "a personalized weekly meal plan"), not a set of features.

2. Pick a small, precisely defined group. Find 5–10 users who match the ideal profile and resist the temptation to take everyone.

3. Set expectations openly. Users need to be told this is a hands-on service run by a person for a limited time — with no pretense of automation.

4. Deliver the outcome manually. Handle the calls, emails, and in-person steps yourself, and log every request and every user action as you go.

5. Collect data and reactions. Track time spent with the product, the customer journey, willingness to pay, and the points where people drop off. A few signals are especially worth watching: repeat usage, willingness to pay, and the number of minutes each delivery costs. Watch which of the steps could be automated. The trigger to start automating is narrow and concrete — it pays to automate the single step that recurs for almost every user and eats up a disproportionate share of time, and only once repeat usage and willingness to pay are already proven.

6. Debrief after every session. Note recurring user tasks, objections, and the features users try to "pull out" of you on their way to getting the job done.

7. Turn findings into decisions. Mine the notes for a short list of must-have features that users ask for and are willing to pay for.

8. Identify the risks. The method has real limits. By design it doesn't scale. Effort grows linearly with each user, so it's a temporary learning tool, not an operating model. Small groups mean findings are directional, not statistically robust. A founder's personal charm can inflate the results and obscure whether users want the product or the person behind it. And because the team does the work itself, it's easy to keep going past the point where everything needed has already been learned.

Real-World Experiment Example

Link to research: Rent the Runway doing things that don't scale — Alexander Jarvis

In November 2008, Harvard Business School students Jennifer Hyman and Jennifer Fleiss tested whether women would rent designer dresses instead of buying them — with no website. They borrowed about 100 dresses, rented a room at Harvard, and invited students to come try them on.

Clipboard in hand, they asked each woman whether she'd rent the dress and how much she'd pay, watching which styles sparked the most excitement. The signal was strong: demand was high, and many women would pay around 10% of retail to rent for a few days. They then repeated the test on other campuses in different formats to find out what actually drove rentals.

The experiment validated more than demand — it revealed the price points women accepted, the styles in demand, and the operational cost of cleaning and moving inventory. Rent the Runway launched its website in November 2009 and had more than 750,000 members by 2011.

What Can Be Tested With This Experiment?

A Concierge MVP pays off most when the biggest risks lie not in the interface but in how customers actually behave and how much the solution is worth to them. Because the outcome has to be delivered for real, hidden assumptions come to light.

• Real demand: whether the target segment of early users genuinely wants the service; confirmed when users come back on their own or refer others — not by mere praise for the idea.

• Willingness to pay: whether people will put real money behind the value; confirmed when they pay (or pre-pay) a real price for the manual service, not a hypothetical one.

• The customer's real need: which part of the outcome customers truly care about; confirmed when the same requests and "could you also…" asks recur across most of them.

• Fit with the value proposition: whether the promised benefit matches what customers actually experience; confirmed when the delivered value meets the expectation set and disappointed feedback is rare.

• Delivery obstacles and costs: how much operational friction and effort the real process demands; revealed by logging the time per delivery and the steps that repeatedly cause rework or delay.

• Automation priorities: which single step is worth building first; recognizable when one manual task recurs for almost every user and consumes a disproportionate amount of effort.