Skip to content

AI for Product Discovery: Research Before You Build

Product discovery asks what to build before delivery asks how to build it. Good discovery starts with a decision, evidence about the customer, and a hypothesis that can fail.

AI can speed up early exploration. It does not remove the need for interviews, observation, behavioral data, or human validation.

A five-step path: define the target audience and job context, run simulated comparisons across segments, narrow to the questions that remain uncertain, validate those with real customers, then decide what to build.
Simulation narrows which questions need real customers; it does not replace the decision to build.

What discovery must establish

A useful discovery process identifies the customer's real problem, tests whether a proposed action addresses it, separates essential features from nice-to-have work, compares segments, and challenges assumptions before engineering begins.

Traditional discovery may take weeks because recruitment, scheduling, sessions, and synthesis all require time (User Research Participant Recruitment Guide, User Intuition). Simulation can help a team prepare and screen options while that work is arranged.

Use simulation to narrow the question

Define the target audience, job context, expertise, goals, and constraints. Then compare product or message alternatives under the same conditions. The output is a hypothesis about aggregate behavior, not a faithful copy of one individual.

A planning example might run five rounds of simulated discovery in the time required to schedule one round of interviews. Another might test five concept directions in an afternoon and select the two worth taking to real customers. Treat both as workflow examples, not throughput guarantees. See how the research behind this approach is designed.

Five applications

Problem validation

Ask how often the problem appears, what people do now, and which constraints shape the workaround. Do not treat a simulated willingness-to-pay answer as a pricing decision.

Solution-hypothesis testing

Compare proposed solutions against the same outcome. Ask how each alternative fits the current workflow, where it adds friction, and what evidence would change the result.

Feature prioritization

Present candidate features to several defined segments. Use the result to identify tradeoffs for a causal experiment or real customer study. A ranked simulated list is not a roadmap decision by itself.

User-story validation

Test whether the story reflects the customer's problem and whether the proposed action matches the expected workflow. Record edge cases for human review.

Onboarding and adoption

Onboarding is underused. Compare alternative instructions, steps, or messages for a new customer. Measure the intended behavior rather than asking a persona to narrate an entire interface it cannot actually use.

Know where simulation fails

Models often match aggregate patterns better than individual behavior. Novel use cases, genuine surprise, sensory experience, and unusual early adopters are hard to simulate. Prompt sensitivity and demographic flattening can also hide meaningful differences.

Use simulated exploration to identify the most important questions. Use real customers and usage data for the discovery that shapes the product direction.

A list of five discovery applications for simulation: problem validation, solution-hypothesis testing, feature prioritization, user-story validation, and onboarding and adoption.
Each application answers a different discovery question, so picking the right one matters more than running more sessions.

A practical setup

Define two to four key audience types, including the primary segment and important secondary segments. Describe each with only the context relevant to the decision.

Focus each session on one topic. Compare the same stimulus across audiences. Capture what the exercise suggests, what remains uncertain, and what needs real-user validation.

Subconscious supports controlled, decision-specific experiments on product, pricing, messaging, and go-to-market actions. The useful result estimates which action changes which outcome for which segment under the study conditions. It does not tell a team what to build without judgment and real evidence. See how the process runs or book a demo to test a specific discovery hypothesis.