In this article 12 sections
Test willingness to pay by offering a specific outcome to a specific buyer at a stated price and asking for a real next step. A paid pilot can provide stronger evidence than positive feedback, but it still does not prove repeatable demand. Record who accepted, who declined, why, and what it took to deliver the result.
“I would use that” is a useful opening to a conversation. It is a weak ending to a demand test. A person can like an idea without having the problem often enough, the authority to buy or the motivation to change an existing process.
A willingness-to-pay test makes the trade-off concrete. The buyer understands the outcome, the price, the work they must do and the limitations of what you can deliver. You then observe a decision. The process below is a practical editorial framework; its example targets are not statistical benchmarks.
Start with a recent problem, not a hypothetical preference#
Ask about the last time the problem occurred. What triggered it? How was it handled? Who spent time on it? What happened when it was left unresolved? GOV.UK’s guidance on learning user needs offers a useful starting point for investigating people’s actual circumstances.[1] For a commercial test, extend that investigation to the purchasing process.
Distinguish the user, the budget holder and anyone who can block adoption. A staff member may want the product but be unable to approve it. A founder may approve the price but discover that the team will not change its workflow. Write down whose decision your test is actually measuring.
Choose one buyer and one purchasable outcome#
A broad product vision is difficult to test. A bounded offer is easier: for example, a manually assisted weekly report that helps a particular operations team reconcile a specific set of records. Describe what arrives, when it arrives and what the customer needs to provide. State what is outside the offer.
Choose a price that makes the decision meaningful in the context of the buyer. Explain whether it covers a one-off pilot or an ongoing service. Avoid presenting an introductory price as evidence that a different future price will work. You are testing this offer, for this audience, under these conditions.
Pick a commitment that matches the stage#
| Response | Useful evidence | What it does not establish |
|---|---|---|
| Positive feedback | The idea is understandable or appealing | Budget, urgency or adoption |
| Follow-up with the buyer | Someone will invest more time | A purchase will happen |
| Access to a test workflow | The problem is important enough to investigate | A sustainable price |
| Agreed paid pilot | A buyer accepts this bounded offer | Repeatable sales or retention |
| Renewal after delivery | The delivered result still has value | Scalable acquisition or margins |
The strongest feasible signal depends on the market. A procurement-heavy buyer may need several approvals before payment. Record the real steps taken instead of turning every conversation into a binary “validated” label. Never take payment for something you cannot explain or responsibly deliver.
Set the decision rule before running the test#
Write down which assumption you are testing, the audience, the offer, how you will reach people and the decision you will make afterwards. An early test might ask whether a small, clearly defined group of qualified buyers will accept a pilot and provide the required data. Choose the threshold according to what you need to learn, not a generic internet conversion benchmark.
Keep the denominator visible. Three acceptances from ten relevant conversations means something different from three acceptances after hundreds of unrelated messages. Track qualification criteria and rejected offers too. A small early sample should guide the next experiment; it cannot estimate the entire market with confidence.
Our MVP validation guide connects this experiment to other risks, such as whether people understand the workflow and can reach the promised outcome.
Deliver manually, and record the hidden work#
A manual pilot can reveal which parts of the proposed product matter before you automate them. Tell the customer how the service works. Do not present human intervention as a fully automated system. Keep the scope narrow enough that you can deliver the promised result and handle problems directly.
Record onboarding time, data cleaning, delivery effort, support and corrections. If each customer needs a different report and hours of interpretation, the useful discovery may be a service opportunity rather than a repeatable software workflow. GOV.UK’s discovery guidance supports understanding the problem before committing to a service; it does not prescribe the commercial test or prices used here.[2]
Read rejection carefully#
Ask which part prevented the purchase. Was the problem unimportant, the outcome unclear, the price too high, the timing wrong or the switching cost too great? Do not automatically lower the price. A buyer who does not trust the data handling may still decline a free pilot.
Change one meaningful part of the offer when you can, then test again with a comparable audience. Keep notes about changed conditions so you do not attribute an improvement to the wrong cause. If friends and existing clients buy, label that relationship: trust you already possess may not transfer to a new acquisition channel.
Let the evidence determine the first product#
After delivery, ask whether the customer wants the outcome again under clear ongoing terms. Review repeat use, renewal, support effort and the steps that produced value. Build around the recurring part of that journey. Our first-release scope guide can help turn that evidence into a smaller build.
For a two-sided product, payment on one side is only part of the test. You also need the other side to participate and complete the transaction. The marketplace MVP guide explains why a list of interested people is not yet a functioning market.
Write an offer a buyer can decide on#
A hypothetical offer might be: “For a four-week pilot, we will turn your weekly supplier spreadsheet into an approved purchasing report, with one review call each week, for a stated fee.” Specify the input format, turnaround, limits and what the customer must provide. Explain manual work and do not imply a fully automated product if a person performs the service.
A buyer can evaluate that offer more concretely than “Would you pay for an AI operations platform?” The latter leaves outcome, timing and price undefined. A refusal is also easier to interpret when the proposition is specific.
| Measure | Definition to record | Why it matters |
|---|---|---|
| Outreach | People contacted through a stated route | Shows acquisition effort |
| Qualified conversation | Person matches the segment and has a relevant need | Keeps irrelevant responses out of the offer denominator |
| Offer | The same defined outcome and price were presented | Makes acceptances interpretable |
| Paid pilot | Commitment and payment under agreed terms | Shows more than general interest |
| Delivered value | Customer received and used the promised outcome | Tests the actual service |
| Renewal decision | A new paid commitment or explicit rejection | Adds evidence about continuing value |
Read a rejection without explaining it away#
Record the buyer’s words, the observed action and your interpretation separately. “We cannot get procurement approval this quarter” is different from “The report would not change our decision.” Neither proves a universal market conclusion. Note whether you reached the actual budget owner and whether a material constraint was missing from the offer.
If you change the price or add substantial bespoke work, start a new offer version. Do not pool different promises into one conversion rate without showing the difference. Discounted pilots can be useful, but make the later price and renewal decision visible.
After delivery, compare revenue with the work needed to produce the outcome. A customer may be willing to pay while the current service is still too costly to repeat. That is a product-design finding, not a reason to conceal labour or present gross revenue as profit.
Put this guide to work#
Frequently asked questions#
Is a verbal promise to pay enough?
It is a signal to investigate, but weaker than an actual decision under clear terms. Ask for the next appropriate commitment: a paid pilot, signed scope or another concrete step. Record what happened rather than converting enthusiasm into assumed revenue.
Should I offer the first pilot for free?
A free pilot may help test usability or delivery when payment is not the current uncertainty. It cannot directly establish willingness to pay. If you use one, state the later paid offer and keep its evidence separate from paid acceptance.
How many paying customers prove demand?
No universal number proves repeatable demand. Consider who bought, how they were acquired, whether the offer was repeatable and whether value continued after delivery. A small paid cohort may justify the next experiment without supporting a market-wide claim.
What if customers only buy after a large discount?
Record that price and the conditions honestly. Test whether the standard offer produces sufficient value and whether delivery economics work at the accepted price. Do not report discounted acceptance as evidence for an untested full-price product.
Can I take payment before the software exists?
A clearly described paid service or pilot can precede full automation, provided you can deliver the promised outcome and agree appropriate terms. Be explicit about what exists, what is manual, timing and cancellation. Do not sell an imaginary capability as an available product.
Sources and methodology#
This guide combines editorial analysis with the linked primary sources. Decision frameworks, worksheets and worked examples are our own; examples are illustrative unless explicitly identified as supplier claims or published research. We have not conducted original interviews, comparative supplier testing or a controlled experiment for this article.
- GOV.UK Service Manual: learning about users and their needs ↗
Primary guidance on understanding users and existing behaviour.
Accessed 16 October 2026 - GOV.UK Service Manual: how the discovery phase works ↗
Public-service guidance used for its problem-definition principles, not as a startup timetable.
Accessed 16 October 2026
Source check: 16 October 2026. Platform documentation can change. Published as part of our editorial collection.
Expanded 16 October 2026 with practical decision material, downloads and topic-specific answers. Supplier and platform claims are identified by their linked sources.
MVP Build Editorial. “How to test willingness to pay before building the product.” MVP Build, 16 October 2026.
https://mvpbuild.xyz/startups/test-willingness-to-pay/