Product Discovery

Test at every phase of product discovery

Product discovery moves through three distinct questions: does this problem exist, does our solution address it, is the finished flow ready to ship. A recruiting lead time of two to three weeks means most teams can only answer the last question in time to act on it. Tessary runs AI personas on prototypes and live URLs and returns findings in minutes, so a test fits at each phase.

Run your first discovery test
The problem

Why most discovery tests happen too late

Research scheduled during discovery returns after launch. By then, the team has already framed the problem, built a prototype, and started the dev sprint.

47%

of researchers cite recruiting as the single hardest phase of the research process

2026 User Research Industry Survey

2–3 weeks

typical B2B participant recruiting lead time, longer than the sprint the test was meant to inform

3 phases

of product discovery each worth a focused usability test: problem validation, solution validation, pre-ship readiness
The shift

Tests arrive after the decision

When recruiting takes two to three weeks and the sprint is two weeks, findings land after the prototype is built and the dev sprint has started. The test confirms what shipped, not what to build next. A 2026 user research industry survey found that 47% of researchers name recruiting as the single hardest part of the process. That bottleneck is why most discovery testing migrates to the launch stage.

47%

cite recruiting as the hardest step

2–3 wks

typical B2B recruiting lead time
How it works

Test at each discovery phase

Three tests across a feature cycle, one per phase, become achievable without any recruiting. Each session runs against an AI persona configured for your target user.

  1. Problem-validation test

    Run before ideation. Point the persona at the current product flow where the problem should appear. The goal is to confirm the problem is real and find where it occurs in the existing experience. A finding here shapes the problem statement before any design work begins.

  2. Solution-validation test

    Run before the dev sprint. Point the persona at a Figma prototype of the proposed solution. Look for hesitation, missed interactions, or abandonment. A finding here changes a prototype at the cost of a revision, not a finished build at the cost of a sprint.

  3. Pre-ship readiness test

    Run before release on a staging URL. Confirm that the changes made in response to solution-validation findings resolved the friction. One session, one sprint slot, before the release date.
Two approaches

Discovery testing with and without Tessary

Without Tessary

Testing migrates to launch

  • Recruiting takes 2-3 weeks, longer than most sprints
  • Findings return after prototype is built
  • Problem validation happens after ideation
  • Launch-stage test confirms what shipped, not what to build
  • Sprint scope set without usability evidence
Tessary

With Tessary

A test at each phase

  • Sessions return findings in minutes, not weeks
  • Problem-validation test shapes the problem statement
  • Solution-validation test catches gaps before dev sprint
  • Pre-ship test confirms the build before release
  • No recruiting, no scheduling, no setup call required
The setup

Up and running in five minutes

Each session takes a URL or Figma link, a persona description, and a task statement. The AI persona does the rest.

Paste the prototype or staging URL

Works on any shared Figma prototype link or browser-accessible staging URL. No code changes, no browser plugin, no SDK required.

Define the persona

Specify the role, experience level, familiarity with the product category, and the specific goal for the session. The persona navigates with exactly that context, not the perspective of someone who built the product.

Write the discovery task

A problem-validation task asks the persona to complete something in the current flow. A solution-validation task asks it to accomplish the outcome the prototype is designed to support. For task-writing guidance, see the B2B SaaS persona guide.

Review findings before the sprint closes

Screenshots, interaction steps, hesitation points, and severity-ranked usability issues appear within minutes. Share the report in a sprint retro or directly with the designer before the next cycle.
Cost of waiting

What deferred testing costs

Each discovery phase has a cost for skipping the test. The cost grows with each stage that passes without one.

A sprint to fix what a prototype revision would have caught
Solution gaps found at launch require a full dev sprint to address. Found before the dev sprint, the same gap is a comment on a Figma frame.
A built feature that solves the wrong problem
Problem validation done after the build confirms a problem statement the team can no longer change. Done before ideation, the same test narrows which problem to design for.
Shipped friction that stays live until the next sprint
Pre-ship findings that arrive at launch become follow-up tickets instead of release-blockers. A single pre-ship session before the release date holds the issue where it is cheapest to fix.
Questions

Answered, plainly.

The usability testing product discovery process runs a distinct test at each of three phases: problem validation, which confirms the pain point exists in the current flow; solution validation, which tests the prototype before the dev sprint; and pre-ship readiness, which verifies the finished build before release. Each phase answers a specific question, and findings feed into the next phase rather than informing a launch retrospectively.
Three stages each warrant a test. Before ideation: run a test on the current flow to confirm the problem is real and locate it. Before the dev sprint: run a test on the prototype to catch solution gaps before anything is built. Before release: run a test on the staging build to verify the finished flow works as intended. Testing at each stage takes one session and changes what the next stage starts with.
Setting up a Tessary session takes about five minutes: paste a URL or Figma prototype link, write a one-paragraph persona description, and specify the task. The AI persona completes the session and returns structured findings in minutes. A PM can run a problem-validation test and review findings within the same morning, without waiting on participant availability or scheduling a session.
Yes. Tessary sessions require a URL or Figma link, a persona description, and a task statement. The AI persona navigates the flow and returns findings (screenshots, hesitation points, and severity-ranked usability issues) without involving a researcher or scheduling a participant. PMs typically run sessions solo and share the report in a sprint retrospective or directly with a designer before the next cycle.
Problem-validation findings shape the problem statement and narrow the scope of ideation. Solution-validation findings become revisions to the prototype before the dev sprint starts, which is less costly than finding the same issue after the build is complete. Pre-ship readiness findings either hold the release until the issue is resolved or become follow-up tickets with documented evidence. Each stage of findings informs the next stage of work.
A general-purpose LLM answers a question based on the prompt you provide. Tessary runs an AI persona with a specific role, experience level, and goal through the actual product in a real browser. The persona navigates, hesitates, and encounters friction that reflects its defined context, not generic AI commentary about what a design should do. The output is an interaction trace with located usability findings, not an opinion.
Keep exploring

Related pages
Get started

Run your first discovery test

Paste a Figma link or staging URL into Tessary and run the first session at no cost. No recruiting required, no setup call needed.

Start testing in product discovery