By Night Watcher · Examples are fictional and illustrate a research method.
Turn the idea into a testable claim
Write down one buyer, one recurring task and one costly failure. ‘An AI assistant for businesses’ leaves too many assumptions hidden. ‘A weekly exception report for owners of small repair shops who reconcile invoices manually’ gives you a buyer and a workflow to investigate.
Separate three claims: the problem occurs, the buyer wants a different solution, and you can reach that buyer at a sustainable cost. Evidence for one does not establish the others. Search demand can reveal vocabulary; it cannot prove willingness to pay for your version.
Ask about the last occurrence, not hypothetical enthusiasm
Ask a prospective buyer to walk through the last time the problem happened. What triggered it? What did they do? Who else helped? What did the delay or mistake cost? Ask what they already pay for and who approves purchases. Request permission before recording anything, and avoid collecting customer records you do not need.
A compliment is weak evidence. A buyer showing an existing workaround, explaining a budget or agreeing to a concrete pilot is more useful. Keep observations separate from your interpretation: ‘uses a spreadsheet every Friday’ is an observation; ‘will pay $50 monthly’ remains an assumption until tested.
Offer the smallest honest pilot
Describe exactly what the pilot delivers, what still requires manual work, the price and the end date. A manual service or clickable prototype may test the outcome before you automate it. Never imply that an unfinished product already has capabilities it lacks.
Choose your decision rule before contacting people. For example, you might require three suitable buyers to commit to a paid pilot and at least two to use the result twice. Those are illustrative thresholds, not statistical proof. Use a rule appropriate to your economics and access to buyers, and record rejection reasons rather than quietly changing the bar.
Worked example: a repair-shop report
Suppose eight fictional interviews reveal that five owners reconcile invoices weekly, but only two report a costly problem. Both request a pilot; one agrees to pay. This supports testing with that buyer, not claiming that five out of eight businesses will become customers. The sample is small and selected by your outreach.
Deliver the report twice. If the customer does not open it, find out whether timing, trust, accuracy or usefulness failed. If they use it but reject the price, test the value proposition or delivery cost before adding features. Track actual effort so a popular manual pilot does not hide an unprofitable service.
Decide what to do next
Continue when behavior supports the problem, the buyer can pay and delivery appears viable. Narrow the segment when evidence clusters around one type of buyer. Stop or change direction when repeated interviews reveal infrequent pain, inaccessible data or no credible route to purchase.
Validation reduces uncertainty; it does not remove it. Keep the evidence log after launch and compare renewal and use with your original assumptions. Use the pricing calculator to check your scenario, without treating a favorable spreadsheet as customer evidence.
Your worksheet
Copy these prompts into your own notes. No signup is required.
SaaS validation worksheet Buyer and role: Recurring task and trigger: Most recent occurrence: Current workaround and spend: Observed cost of failure: Purchase decision-maker: Evidence source and date: Assumption still untested: Pilot promise, price and end date: Decision rule chosen in advance: Observed pilot use: Continue, narrow or stop — and why:Download the text worksheet
Test your assumptions
Use the related free calculator, then compare the scenario with evidence from actual buyers.
For company and search-demand research, explore Night Watcher plans.