What does validation need to establish?
Validation reduces specific uncertainties: whether the problem happens, who experiences it, how it is handled today, and whether a proposed solution earns a meaningful commitment. No single interview count or waitlist total proves a market. Define the decision you need to make and the evidence that could change it before collecting responses.
What should you ask prospective buyers?
Ask about the last time the problem occurred. What triggered it, which tools were used, who did the work, and what happened when it went wrong? Ask to see an anonymized example where appropriate. Avoid pitching features before understanding the workaround. In a fictional revision organizer interview, learning that a studio already has a satisfactory client portal is more useful than hearing that an AI summary sounds interesting.
How can you run a useful small test?
Offer a clearly described manual pilot or prototype with a defined task and voluntary participation. State what is available today, the effort required, and any payment or cancellation terms. Record invitations, acceptances, completed tasks, repeat requests, and reasons for declining separately. A waitlist can test interest in the promise; it cannot demonstrate that the software works. Do not take payment for a product you cannot deliver under the stated terms.
When should you build, revise, or stop?
Set a decision rule for the experiment rather than borrowing a universal conversion threshold. You might require evidence that target buyers repeat the task and can complete a pilot without extensive rescue. If the problem is real but the workflow fails, revise the workflow. If interviews consistently show no recurring need, investigate another problem. Take the strongest observed task into the MVP plan and test the pricing assumptions separately.