How to Validate a B2B Idea With a Concierge MVP

TL;DR. To validate a B2B idea with a concierge MVP, deliver the proposed outcome manually to a narrowly defined customer before automating the workflow. Agree on the inputs, output, price and success criteria, then observe whether customers use the result and pay to receive it again. Set limits and stop criteria before starting. Treat the findings as evidence about demand for that service, with software usability and scalability still to test.

What should a concierge MVP test?

A concierge MVP is a deliberately manual service used to test a proposed product outcome. Customers know people are doing the work. You might collect inputs through a form, analyse them in a spreadsheet and deliver the result in a document.

Start with a decision: what must you learn before investing in software?

A useful hypothesis identifies:

• Customer: the role and business situation you serve.
• Problem: the recurring task or decision causing difficulty.
• Outcome: the useful result you will deliver.
• Commitment: the price, access or effort the customer must provide.
• Evidence: the behaviour that would support continuing.

For an illustrative example, consider operations managers who prepare unresolved-order reviews. The hypothesis is that they will pay for a weekly exception brief, supply the required records and use the brief to assign follow-up work.

That tests a specific outcome. Testing whether managers like a dashboard leaves too much undefined.

Use How to Build an ICP to narrow the customer group, then Jobs to Be Done for B2B Product Teams to clarify the task behind the request.

How do you define the service boundaries?

Write a short service agreement before recruiting. Make the manual delivery explicit and describe exactly what the customer receives.

For the illustrative exception-brief service, the boundaries could look like this:

Boundary	Agreed scope
Inputs	One agreed order export supplied by the customer
Output	A prioritised exception brief with reasons for each flag
Frequency	One brief per weekly review cycle
Customer responsibility	Supply usable records and review the findings
Exclusions	No customer outreach, record changes or purchasing decisions
Support	One clarification conversation per delivery
Data handling	Agreed access, storage, deletion and permitted use
End condition	A fixed pilot followed by a separate continuation decision

Choose a workflow the customer can share with permission. Request only the information needed to produce the result.

Record exceptions instead of quietly absorbing them. If every delivery requires a different input format or a new type of analysis, that changes what you are testing.

Who should join the pilot?

Recruit people who experience the problem and can realistically buy the eventual offer. Start with a conversation about their current workflow.

Ask them to walk through a recent instance: what triggered the work, what they did, where it became difficult and what happened afterwards. Request a sample input where appropriate and permitted.

Before accepting a participant, establish:

• Who uses the output?
• Who controls the budget?
• Who must approve access or purchasing?
• When will the next real need occur?
• What would the customer otherwise do?

A friendly contact can help you rehearse delivery. Keep that learning separate from evidence gathered through a realistic buying decision.

When the user and buyer differ, involve both. User enthusiasm answers a different question from budget approval.

How should you test willingness to pay?

Offer a bounded paid pilot with a clear price, deliverable and end point. State what payment covers and what happens if you cannot deliver the agreed work.

For the illustrative example, offer three weekly exception briefs for an illustrative fixed fee of $600. Those figures are experiment choices, not pricing benchmarks.

Track the buying decision separately from delivery:

Observed behaviour	What it supports	What remains uncertain
Positive feedback	Interest in discussing the problem	Willingness to commit
Real records supplied	Willingness to provide inputs	Willingness to pay
Paid pilot purchased	Demand at the stated pilot terms	Demand at a different price or scope
Output used in a review	Practical use of the result	Continued use
Paid continuation agreed	Demand beyond the initial pilot	Retention over longer periods

If purchasing takes time, record the approval stage, budget owner and next decision. Keep unpaid commitments separate from collected payment.

Avoid changing price, scope and audience together after each refusal. Change one condition deliberately so you can interpret the response.

What should you measure during delivery?

Keep a delivery log with separate records for customer value and your effort.

For customer value, record whether the customer supplied inputs, reviewed the output, used it in the intended workflow and requested another delivery. Ask what action followed. Where permission allows, inspect the resulting decision or work record.

For delivery effort, record time spent collecting inputs, cleaning data, analysing it, checking the result and answering questions. Note rework and steps that required judgment.

In the example, producing a brief completes your activity. Using it to assign follow-up work supports the intended outcome. Confirming that assigned work was completed gives you another observation.

Do not claim time savings unless you have an agreed comparison. Separate customer estimates from measurements, and document how any measurement was made.

What stop criteria should you set before starting?

Choose limits before enthusiasm or sunk effort influences the decision. Define the recruitment window, spending ceiling, delivery capacity and minimum evidence required.

The following is an illustrative decision checklist, not a universal standard:

• Recruit four customers who fit the same narrow profile.
• Require payment before the first full delivery.
• Complete the agreed pilot for each participant.
• Require at least two customers to purchase continuation at the stated ongoing price.
• Confirm that continuing customers used the output in the intended workflow.
• Cap manual delivery at three hours per customer per cycle.
• Stop if authorised inputs cannot be obtained or the result cannot be delivered reliably.

Set rules for mixed results. Payment without use calls for investigating why the output was ignored. Use without continuation calls for examining price, frequency and priority.

If success depends on work outside the agreed scope, rewrite the hypothesis before running another pilot. Record what changed.

What does success prove about software scalability?

A successful pilot supports demand for the delivered outcome under the tested conditions. It leaves several product questions open:

• Can customers prepare inputs without personal help?
• Can software reproduce the decisions made during manual delivery?
• Can users understand and act on the output independently?
• Can the service handle varied data reliably?
• Can the eventual price cover software, support and ongoing operations?

Mark each manual step as repeatable, judgment-heavy or customer-specific. Then choose the next experiment around the largest unresolved risk.

For the example, you might first test whether customers can upload a usable export without assistance. Next, test automated exception detection against manually checked results. Test comprehension before removing the explanation call.

Put those uncertainties into a Now, Next, Later Roadmap. Each build step should answer a question the manual pilot could not.

What common mistakes weaken the experiment?

Expanding scope to preserve a sale. Record the request and make a separate decision about testing it.

Treating free work as a pricing test. A free pilot can test delivery and use. It leaves willingness to pay unresolved.

Counting bespoke consulting as software validation. If customers mainly value your personal judgment, test whether they want the more standardised result a product would provide.

Hiding the manual work. Explain the delivery model so customers can assess access, confidentiality and service expectations.

Automating before identifying the bottleneck. Use the delivery log to choose what needs building.

Using concierge delivery where the core risk requires software. If value depends on instant responses, live collaboration or performance under load, run a technical experiment alongside discovery.

What questions come up before starting?

Related reading

• How to Build an ICP — define the customer group your pilot serves.
• Jobs to Be Done for B2B Product Teams — connect the offer to a concrete customer task.
• Now, Next, Later Roadmap — turn unresolved questions into focused next steps.