AI Product User Interviews and Willingness-to-Pay Validation: From Verbal Interest to Verifiable Commitment

"If we build it, will you use it?" will almost always get a polite yes, but that answer cannot support a build decision. The respondent bears no cost for agreeing, nor must they face budget, approval, data security, or migration friction. The goal of evidence-based interviewing is not to collect compliments, but to confirm whether a certain type of user has repeatedly hit the same problem in the past, what they have already spent on it, and whether they are now willing to hand over a scarce resource.

For AI products in particular, beware the demo effect. A dazzling generation excites people, but does not prove it can reliably enter a workflow. Interviews should separate "the model is cool" from "the result is worth paying for" — validate the problem first, then the delivered result, and only then the implementation approach.

Write a falsifiable hypothesis before interviewing

Don't use an unfalsifiable sentence like "SMBs need AI." Record the hypothesis with audience, scenario, frequency, loss, and alternatives, for example:

In software companies of 10 to 50 people, the pre-sales lead manually organizes customer interviews at least twice a week; each takes more than 90 minutes and is already being addressed through overtime, outsourcing, or general-purpose transcription tools. If a traceable requirements summary can be delivered within 30 minutes, they are willing to pay 800 yuan for a four-week pilot.

Also register disconfirming conditions: if fewer than 5 of 12 qualified respondents actually performed the task in the past month, or fewer than 2 are willing to enter a paid pilot, suspend the direction. Writing thresholds first prevents the team from moving the goalposts after hearing scattered praise. When the product direction is still unclear, you can first use the Indie Hacker AI Verification Workflow to define the audience and problem, rather than starting straight from a feature list.

Only ask about things that have already happened

A 30-minute interview can advance along a timeline:

1. "When was the last time you handled this? Who initiated it, and what was the input?"
2. "Please walk through it in order — which tools did you use, and at which step did you rework?"
3. "How long did the whole process take? If delayed, do you lose orders, labor hours, or reputation?"
4. "How many times has this happened in the past three months? What solutions have you tried buying or building?"
5. "Who owns the budget, who reviews AI-generated results, and who can veto rollout?"

Ask them to show desensitized spreadsheets, templates, tickets, or calendars instead of accepting general descriptions. Showing does not mean copying sensitive data; just record the artifact type, number of fields, processing time, and exceptions. Label every observation as observed, reported, or inferred, so during later review you won't treat researcher inferences as user facts.

Avoid leading questions like "Is this auto-summary helpful?" More effective questions are: "If you didn't have this tool today, how would you complete the task?" and "What kind of error would make you stop using it immediately?" The former reveals alternatives, the latter reveals quality thresholds. The homogenization risk common during the cold-start phase can be checked against AI Product Cold Start and PMF to see whether users are buying the result or are merely attracted by the AI label.

Use a commitment ladder to validate willingness to pay

Evidence strength can be ordered by increasing cost: willing to keep chatting, providing samples, inviting colleagues, arranging a pilot, signing a pilot scope, paying a refundable deposit, completing payment. The first three levels indicate the problem is worth attention; only the last three approach a commercial need. Don't put email sign-up and payment into the same "conversion" metric.

A paid test must specify deliverables, duration, level of human involvement, data usage, and refund terms. You can charge a 199 yuan refundable deposit via a payment link, or open an 800 yuan human pilot with a clear scope; you must not fabricate artificial scarcity, hide the fact that the product is not yet automated, or collect money without delivery capability. Before pricing tests, first account for inference and human costs; the method is described in AI Product Pricing Models.

Suppose you recruit 18 people, of whom 12 match the preset persona. Of those 12, 9 performed the target task in the last 30 days, 6 provided desensitized samples, 4 signed a pilot scope, and 3 paid 800 yuan. The recomputable results are: problem incidence 9 / 12 = 75%, qualified-interview-to-payment conversion 3 / 12 = 25% — not dividing 3 by all landing page visitors. If each paying customer saves 6 hours per month and their fully loaded hourly cost is 150 yuan/hour, then the verifiable value ceiling is about 900 yuan; this is only a price basis, not a revenue commitment.

Build an evidence table a second person can review

Each interview should save at least these desensitized fields: recruitment channel, persona match reason, most recent event date, monthly frequency, time per occurrence, current alternative, quantifiable loss, budget owner, commitment level, rejection reason, and researcher confidence. Original recordings require consent and a deletion deadline; without consent, keep only structured notes.

After every 5 interviews, do a cross-check. Have someone who did not participate in the interviews randomly pick two conclusions, trace them through the notes to the original words or observational basis, and recompute the frequencies and conversion rates. If no basis can be found, downgrade the conclusion to a hypothesis. Encode rejection reasons too — e.g., no_problem, quality_risk, no_budget, approval_blocked — otherwise the team will only remember the cases that support its own position.

Validation checklist before issuing a build task

• Do the respondents come from the preset target audience, rather than friends or generic AI enthusiasts?
• Does every demand conclusion correspond to a recently occurred specific event and existing switching cost?
• Are the payer, user, and approver identified separately?
• Does willingness to pay come from real payment or an explicit pilot contract, rather than a verbal answer to a price question?
• Are the denominator, failure samples, and refunds fully recorded, and can another person recompute them?
• Did the preset disconfirming conditions trigger, and did you actually pause when they did?

The final output of interviews is not a report full of quotes, but an evidence chain: the target user has experienced the problem, the problem has a quantifiable cost, existing solutions aren't good enough, the decision chain allows adopting a new solution, and at least someone is willing to pay a real price for a defined result. Only when this chain holds does the next step of feature development have a basis.

Further reading

• Indie Hacker AI Verification Workflow
• AI Product Cold Start and PMF
• AI Product Pricing Models
• AI Product Concierge Pilot