Product validation with AI: from assumptions to evidence

An AI assistant can produce a market analysis, customer personas, objections, and a launch plan before you have spoken to a potential buyer. The resulting document may be useful preparation. It does not show that anyone needs the product enough to change what they do.

Product validation with AI works best when AI helps you design, build, and interpret an experiment that reaches real people. Keep the generated assumptions separate from the behavior you observe.

The goal is to make the next investment decision better: continue, change the offer, investigate a different risk, or stop.

Start with the decision you are about to make

“Validate the idea” is too broad to guide an experiment. Name the commitment you are considering. You may be deciding whether to build a prototype, spend a month implementing an integration, hire someone, or offer a paid pilot.

Then ask which uncertainty could make that commitment a mistake.

These questions need different tests. A positive response to a landing page does not answer whether the product handles a difficult real task. A successful prototype session does not establish an affordable acquisition channel.

This is consistent with the GOV.UK guidance on planning user research: define the questions and user groups, then choose activities that can answer them. For a commercial product, add the buying and delivery questions your business depends on.

Use AI to make assumptions specific

Consider a fictional proposal-writing tool for small service agencies. “Agencies need better proposals” leaves too much unspecified. Which agencies? What kind of proposal? What is wrong with their current method?

Ask the AI to challenge the idea:

List the assumptions this product depends on. Separate problem frequency, buyer authority, current alternatives, willingness to change, willingness to pay, and delivery feasibility. For each assumption, describe what evidence could contradict it. Do not report an assumption as a market fact.

You might arrive at a narrower hypothesis: owners of small implementation agencies repeatedly rebuild proposal scope from discovery notes and would try a tool that produces a useful first draft from those notes.

That statement still needs testing. It now tells you whom to recruit, what recent work to discuss, and what task to observe.

Match the experiment to the uncertainty

If you do not understand the current workflow, begin with interviews and examples of recent proposals. Ask people to show how they did the work. AI can help prepare questions and organize notes, but a synthetic interview is not evidence of a real buyer's experience.

If the workflow is clear and cheap to reproduce, build a narrow working slice. For the proposal example, accept one type of discovery note and produce an editable scope section. Leave billing, team administration, and template marketplaces out of the experiment.

If purchase is the main uncertainty, make a clear offer. A polite statement of interest is different from agreeing to a price and a defined next step. Do not describe a mock checkout or a no-obligation signup as revenue.

Our earlier article on how cheaper building changes product validation explores when a working version can be a useful early experiment. It still needs a route to the right users and an explicit learning objective.

Write the decision rule before seeing the result

Record the hypothesis, activity, measurement, and decision rule in advance. Strategyzer's Test Card is a useful reference for making these elements explicit.

For the fictional proposal tool, an initial qualitative experiment could be:

Set numerical thresholds only when they fit the decision, method, and available sample. A few sessions can uncover failures worth fixing; they do not establish a market conversion rate.

Keep recruitment and selection visible. Feedback from friendly peers may be valuable, but it answers a different question from a buying decision by someone with the problem, authority, and budget.

Keep observation, interpretation, and action separate

After a session, it is tempting to ask AI for a confident verdict. Ask for a structured evidence review instead.

Observation: The participant rewrote the pricing section and kept the scope section.

Interpretation: The scope draft may be useful, while pricing requires information the tool did not receive.

Next action: Investigate which pricing inputs are missing before expanding the pricing feature.

The interpretation is provisional. Maybe the participant kept the text to be polite. Maybe the output was useful only because an operator corrected it during the session. Record those alternative explanations.

Ask the AI to connect every finding to a note, recording timestamp, or artifact you are permitted to use. Review the underlying evidence before treating a pattern as established.

Measure the work required to deliver the value

A prototype can appear successful while hiding heavy manual correction. Track that correction as part of the experiment.

For the proposal tool, record the operator's preparation, review, and revision work. Note which errors are cosmetic and which could create an incorrect commercial commitment. Also check whether a second user can obtain a useful result without the original builder explaining each step.

This helps distinguish a promising service-assisted pilot from a repeatable software workflow. Either may be worth pursuing, but they have different operating requirements.

Make the next commitment proportional to what you learned

A useful test can end with a smaller product, a narrower segment, or a decision to stop. It can also reveal that the original assumption was too vague to evaluate. Those are legitimate outcomes when they prevent a larger unsupported commitment.

If you need help choosing and running the next experiment, Worklayer Agency's product validation service focuses on moving ideas toward market evidence. Bring the decision you are considering, the evidence you already have, and the assumption you are least comfortable relying on.

Before opening another AI research prompt, write one sentence: “We will use the result of this test to decide whether to ___.” That sentence determines what evidence the experiment needs to produce.