AI can help a product manager turn a proposed workflow into something people can try before the team commits to building it. That moves some discussion from descriptions to observable behaviour. It does not remove the need to establish the problem, interpret evidence or decide what deserves production work.
Consider an education centre exploring a trial-class booking flow. A convincing demo can show available slots and a confirmation screen. The unresolved question is whether parents can make the booking they need, with the information and constraints the centre actually has.
What Changes When Prototypes Become Easier?
Tools such as Figma Make can generate functional prototypes from prompts and design context. Instead of discussing an imagined interaction, a team can inspect an early version. That makes misunderstandings easier to expose, but also makes it easier to polish the wrong idea.
The product requirements document, or PRD, still has a purpose: record the problem, scope, rules and decisions. It can evolve alongside a prototype rather than becoming a long specification written before anyone has tested the central assumption.
1. Define One Decision Before Generating Screens
For the education centre, write a short brief: “We need to learn whether parents can identify a suitable trial class and request a place without calling the centre.” List the information required—age group, branch, timing and availability—and what remains unknown.
Ask AI to suggest missing questions, then check them against real enquiries or staff knowledge. A model's plausible list is a research aid, not evidence of what parents want. Our audience research guide explains how to separate observations from assumptions.
2. Build Only the Flow Needed to Test It
A useful first prototype might include class selection, an unavailable-slot state and a request confirmation. Use invented names and sample bookings; do not paste identifiable family records into a tool without the required permission and data arrangements.
Tell the tool which information is simulated and which actions must not send real messages or payments. A button that displays “confirmed” in a demo is not proof that a real place has been reserved.
3. Observe the Task, Not Just the Reaction
Give a suitable participant a task: find a trial class for a child in the relevant age group at a branch they can reach. Let them attempt it before explaining the interface. Record where they hesitate, what they misunderstand and what they need to know before committing.
“Looks good” is weaker evidence than seeing whether the person chooses the right branch and understands that a request still needs confirmation. A small test can reveal problems; it does not establish market-wide demand or a conversion forecast.
AI can help organise notes, but compare its summary with the underlying observations. Keep a participant's words distinct from your interpretation. Synthetic personas can suggest test cases, not substitute for the people whose behaviour you are trying to understand.
4. Turn Feedback into a Decision Record
For each significant finding, record the observation, your interpretation, the proposed change and what would test it. If parents cannot distinguish a request from a confirmed place, revise that wording and state transition before adding another feature.
Keep unresolved questions visible: who maintains class availability, when a place is held and how staff handle cancellations? These rules belong in the requirements, not only in a prompt history. A changed interface needs an updated decision record so engineering and operations receive the same meaning.
5. Review What the Demo Has Not Proven
Before production, the responsible team still needs to check real availability, identity and permissions, error handling, accessibility and operational ownership. Decide whether the generated implementation is suitable to continue or whether the prototype has completed its learning purpose and should be rebuilt.
Run the full journey with realistic constraints, including a full class and a failed request. Measure completed, valid bookings separately from button clicks. The next product decision should follow that evidence, not the amount of code generated.
Frequently Asked Questions
Does AI Replace the Product Manager?
Generating drafts or interfaces does not assign accountability for the problem, evidence or trade-offs. Roles may change, but a prototype alone cannot decide what the organisation should build.
Do You Still Need a PRD?
You still need a shared record of scope, rules and decisions. Its length should follow the product's complexity; the prototype can illustrate interactions while the document explains requirements it cannot show.
Is an AI-Generated Prototype Production-Ready?
Not simply because it runs. Check the implementation and real operating requirements before using it with customers. Some prototypes are deliberately disposable.