“This is interesting.”
Positive reactions can open a conversation. Explore the problem, the customer’s current process, and the reason they would act.
AI Product Validation
A working product.
A business still to prove.
Validation tests whether a specific customer has a meaningful problem, whether the product solves it reliably, and whether the improvement is valuable enough to buy and keep using.
Replace assumptions with evidence
Find out what is true
before scaling what is possible.
Product development asks whether the software can work. Validation asks whether it works for a real customer, in an actual workflow, under conditions that could support a business.
The process connects customer conversations, observed work, product trials, and commercial commitments. Each helps answer a different question. A convincing demo cannot establish demand, and customer interest cannot establish reliable product performance.
The aim is to learn where the opportunity is strongest, what needs to change, and which assumptions remain unresolved.
“Let’s use it on this workflow.”
A customer who makes time, involves the buyer, runs a defined trial, or pays for the outcome provides evidence that moves beyond a first impression.
Six connected tests
Validate the customer,
the work, and the economics.
Keep a record of what you assumed, what you observed, and what remains uncertain. The strongest conclusions draw on repeated behavior across relevant customers, rather than one unusually enthusiastic conversation.
Customer: be specific.
Define the initial customer by role, industry, workflow, and context. Separate the user from the budget owner and anyone whose approval is needed to adopt the product.
Questions & evidence
- Who experiences this problem repeatedly?
- Who performs the task, who pays, and who approves a change?
- Can we find more customers with the same circumstances?
What to look for: A clearly defined customer group and access to people who perform or buy the work.
Problem: understand the consequences.
Ask about actual experiences. A recurring task is not automatically a meaningful problem: learn what makes it expensive, frustrating, slow, or error-prone and what happens when it is left unresolved.
Questions & evidence
- When did this problem last occur?
- What did it cost in time, money, rework, or missed opportunities?
- How important is solving it compared with other priorities?
What to look for: Specific recent examples of a problem the customer already has a reason to solve.
Alternative: study the current process.
Map how the work happens today. Manual effort, spreadsheets, existing software, and simply tolerating the problem are all alternatives. Understand what is useful about the current approach as well as its weaknesses.
Questions & evidence
- Can the customer walk us through the last time they did the task?
- What inputs, systems, and people are involved?
- What would make switching difficult or risky?
What to look for: A realistic baseline and a clear understanding of adoption friction.
Value: measure the whole improvement.
Compare the current process with the product-assisted process. Include setup, review, corrections, and exception handling. Confirm that the improvement matters to the buyer, not just to the builder.
Questions & evidence
- How much time or effort changes from start to finish?
- Does output quality remain acceptable for the task?
- What can the customer do with the capacity or improvement created?
What to look for: A repeatable before-and-after comparison tied to an outcome the customer values.
Payment: test a concrete offer.
A compliment is useful feedback, but it is weak evidence of demand. Present a defined offer with scope, price, and expectations. Learn how an interested user becomes an approved purchase.
Questions & evidence
- Will the budget owner pay for this outcome?
- What is required to approve a pilot or purchase?
- If the pilot works, what happens next and who decides?
What to look for: A meaningful commitment and a understood path toward a paid relationship.
Access: find the next customers.
Validate the path to buyers alongside the product. A few friendly users may provide helpful feedback without representing an accessible market. Test whether similar prospects can be identified and reached.
Questions & evidence
- Where can we find buyers with this problem?
- Which introductions, industry groups, or channels generate conversations?
- Can we reach customers beyond our immediate network?
What to look for: A practical way to start conversations with additional customers in the same segment.
Customer conversations
Ask about the work.
Listen for the evidence.
Questions about past behavior usually reveal more than predictions about what someone might use. Look for detail, examples, and actual constraints. Give customers room to explain the problem in their own words.
Ask about the last time.
“Walk me through the last time you completed this task.” Start with real behavior and follow the sequence: inputs, steps, handoffs, delays, and output.
Explore what makes it matter.
“What is the most difficult part? What happens if it is late or wrong?” Learn the consequences before suggesting a solution.
Understand the buying process.
“Who would need to approve a tool like this? How have you bought similar tools?” Separate the enthusiasm of a user from the process of a buyer.
Observe before demonstrating.
Where appropriate, see the workflow or an example output. Present the product after understanding the baseline so the demo does not shape every answer.
Learn how the customer works today before asking them to imagine how they might work tomorrow.
AI-specific product evidence
A good demonstration
is only the beginning.
Test representative work.
Use tasks and inputs that reflect the customer’s actual workflow, including difficult cases. An ideal example may hide the conditions that make everyday delivery challenging.
Define acceptable output.
Agree on what a useful result looks like and where mistakes have consequences. Evaluate quality against the task’s requirements rather than how impressive the output appears.
Include human review.
Track what the user must verify, correct, and approve. A faster initial output may deliver little overall improvement if substantial checking remains.
Understand data and integration.
Determine whether the necessary inputs can be used appropriately and whether the product fits existing systems. Access, permissions, and integration effort affect adoption.
Measure delivery costs.
Track AI usage, processing, support, and manual intervention. Assess whether delivering a reliable outcome can work economically at the proposed price.
Watch repeat use.
See whether customers return to the product on subsequent tasks. Repeated use and continuing value are more informative than novelty-driven experimentation.
A focused pilot
Make the test small.
Make the learning clear.
A pilot should resolve a defined uncertainty. Agree on the workflow, participants, duration, commercial terms, and the decision to be made at the end.
Establish the baseline.
Document how the work happens today, how much time it takes, and what quality is required. Choose measures before the trial begins.
Define success and responsibility.
Specify what would count as a meaningful improvement, who reviews the results, and what support the customer and product team will provide.
Observe real use.
Capture usage, output quality, review effort, errors, and customer feedback. Include cases where the product is bypassed or requires extra assistance.
Decide what comes next.
Review the evidence with the buyer. Decide whether to continue, change the offer, run a narrower test, or stop. A pilot without a next decision can produce activity without commercial progress.
Illustrative example
Validate the whole estimating workflow.
For a tool serving commercial roofing contractors, the hypothesis might be that preparing an estimate can fall from four hours to twenty minutes. Those numbers are an example to test, not a proven result.
Before the trial
Observe how estimates are prepared, identify the reviewer and buyer, and agree on what counts as a complete, accurate estimate.
During the trial
Test realistic jobs. Measure preparation and review time, corrections, missing information, and the effort needed to get an approved output.
After the trial
Ask whether the measured improvement justifies the price and fits the contractor’s process. Then test continued use on the next estimate.
Use the evidence
Proceed.
Refine.
Or change direction.
Proceed when the customer, workflow improvement, buying commitment, and delivery economics support a focused next step. Keep tracking assumptions that have not yet been tested.
Refine when the problem is meaningful but the offer, customer segment, product performance, onboarding, or price needs adjustment. Make the next test address the specific gap.
Change direction or stop when the evidence consistently fails to support demand or a viable way to deliver value. Learning this early protects time and resources for a better opportunity.
At LaunchWorks, validation informs the business we build around a product. It shapes positioning, pricing, launch planning, and the decision about what to pursue next.
Explore AI product commercialization →