A tester reaches the end of your prototype and says, “That was easy.” What would justify another week of work: completing the task, asking to use it again, or agreeing to pay?
AI agents for product managers can turn a narrow idea into an interactive prototype. The useful outcome is evidence for a decision. This walkthrough follows one explicitly hypothetical example, from a product question to a continue, change, or stop decision.
Choose the Product Question Before Building
Start with uncertainty that an interaction can expose. If you still need to establish whether a problem exists, interviews about recent work may be more useful than code.
Pragmatic Institute emphasizes clear outcomes, explicit constraints, and human ownership of product decisions. For AI product prototyping, apply that discipline to a question you could answer even if the prototype disappoints.
Hypothetical example: A small software team suspects that support leads struggle to review suggested duplicate-ticket groups. The question is whether showing the original tickets beside each suggestion helps leads decide which tickets belong together.
The agent builds the review interaction. Grouping accuracy, sustained adoption, and willingness to pay remain separate questions.
Turn One Hypothesis Into a Testable Prototype
Define the Audience and Observable Behavior
Recruit support leads who actually review duplicate tickets. Ask about a recent instance and their current workaround before showing the prototype.
For this hypothetical experiment, use this hypothesis:
Given a suggested group and its source tickets, a support lead can accept the group or remove an unrelated ticket without moderator guidance, then explain the decision using the ticket content.
Record task completion, moderator help, incorrect inclusions, and whether the participant inspected the source material. Ask them to assess a group; avoid instructions such as “click the source panel,” which reveal the intended path.
Set the next-step rule before testing. One illustrative rule is to revise when the same comprehension problem appears in two independent sessions, and continue only when participants complete the task unaided and can explain its relevance to their work. These are exploratory decision rules, not statistical validation thresholds.
Bound the Prototype and Its Test Data
Build one screen: a suggested group, source-ticket details, accept/remove controls, and a reset action. Include a deliberately unrelated ticket so the task requires judgment.
Use synthetic tickets labeled as sample data. Keep the suggestions fixed; no live classifier, customer connection, account system, or actual ticket merging is needed to study this interaction.
Synthetic content makes the exercise controllable, but its realism limits the conclusion. A participant’s actions are real observations within an artificial task. Neither those observations nor agent-generated “user feedback” establish real-world demand or classifier accuracy.
Request the Smallest Working Interaction
Give the coding agent a bounded request like this:
Build a local, single-screen duplicate-ticket review prototype.
Audience: support leads who review duplicate tickets.
Question: can they inspect source tickets and correct a proposed group?
Use only bundled synthetic tickets, visibly labeled as sample data.
Show one fixed group containing an unrelated ticket.
Allow opening ticket details, removing a ticket, accepting the remaining
group, and resetting the session. Keep all changes in local memory.
Use labeled controls, keyboard access, and visible focus.
Do not add login, live AI grouping, external services, or real merging.
Record local open/remove/accept events with a prototype version and
anonymous session ID. Do not send telemetry anywhere.
Return runnable files, startup instructions, checks performed,
known limitations, and any assumptions. Stop after this interaction.Keep that scope visible during revisions. In product manager coding workflows, an agent’s suggestion to add a dashboard is another product decision. Accept extra work only when it is necessary to observe the behavior under test.
Separate Implementation Checks From Product Evidence
Run the prototype yourself before recruiting participants. Confirm that removal affects the accepted group, reset clears session state, and recorded events match visible actions. Have an engineer inspect unfamiliar code or unexplained network activity before sharing it.
AI prototype validation needs two separate records:
| Record | Example evidence | What it supports |
|---|---|---|
| Implementation | Remove excludes the selected ticket; reset restores the fixture | The intended interaction works |
| Usability | A participant finds the source details and corrects the group without help | The interaction is understandable in this session |
| Potential usefulness | The participant connects it to a recent task and identifies where it could fit | A reason to investigate workflow fit |
| Commercial evidence | A relevant buyer commits to a clearly scoped paid test | A limited willingness-to-pay signal under those terms |
An agent clicking every button belongs in the implementation record. A tester following your instructions does not establish voluntary use. Even a paid-test commitment leaves retention and broader demand unresolved.
For product hypothesis testing, preserve contradictory evidence. If someone accepts the group without noticing the unrelated ticket, the acceptance event alone would make a failed review look successful. Pair event logs with observation notes and the participant’s explanation.
Decide Whether to Continue, Change, or Stop
Review observations against the rule set before testing:
- Continue to another small experiment when leads can review the group and describe a credible use in their current work. Test the next uncertainty, such as whether they choose the workflow when their existing method is also available.
- Change when the need appears relevant but participants cannot find the source evidence or understand the controls. Fix the observed obstacle and test again.
- Stop this direction when relevant participants consistently report that duplicate review is not their responsibility or that the proposed decision adds no useful step.
A broken interaction produces an inconclusive product test; it is a reason to repair the test, not reject the need. Mixed observations may also require better recruitment or a narrower question before choosing a direction.
Applying Prototype Work in Verdent
Verdent Manager can break a goal into tasks, dispatch agents, and return outputs for review. Those capabilities were checked on September 7, 2026. A suggested application is to give Manager the bounded request above, then review the resulting interaction before involving testers. This is a proposed use, not a validated customer case. Task completion cannot establish whether support leads want the workflow; the PM still defines the experiment and interprets the observations.
FAQ
What if testers ask for features outside the experiment?
Record the request and ask what task it would enable. Keep the current session focused. A requested export may be optional; a missing source field may make the review impossible. Treat the latter as a limitation of the experiment before adding it to a roadmap.
Should an internal prototype use the production analytics account?
Use a separate test project or local event log. The organization’s account can contain both environments, provided collection destinations are isolated. Keep prototype events out of production funnels and automations, and verify the destination before testing. An event-name prefix alone does not prevent contamination.
Can the same participants test successive agent-built prototypes?
Yes, for studying familiar use. Record prior exposure and distinguish first-use performance from learned performance. NN/g explains how learning transfers between conditions and presentation order affects comparisons. When both versions are available, vary and balance their order across participants. Sequential revisions cannot undo exposure; recruit fresh participants when first-use clarity matters. Faster repeat performance alone does not prove the redesign helped.
How should accessibility gaps affect an early usability test?
Fix barriers that prevent intended participants from attempting the task, including inaccessible controls or missing labels. W3C recommends combining evaluation with disabled users and accessibility checks. Record remaining gaps and assistance given. Excluding affected participants narrows the sample; it cannot support a claim that the workflow works for the whole audience.
What must be removed before sharing a prototype outside the company?
Remove customer records, credentials, private URLs, internal comments, and unnecessary logs or files from the shared package. Disable production connections and unapproved telemetry. Inspect the built app and network requests, not just visible screens. Replace sensitive fixtures, reset sessions, and restrict access to the intended testers.
Let the Experiment Inform the Next Product Decision
The encouraging comment at the end of a session needs an observable counterpart: a correctly reviewed group, a credible place in the participant’s work, or a commitment appropriate to the question. Each supports a different decision.
Keep the next investment proportional to that evidence. If the direction later warrants engineering work, carry the findings into spec-driven development. For now, the outcome can be a smaller question—or a justified decision to stop.
