Until 2024, PMs who wanted to validate an idea had two options. Write a requirements document and wait for engineering to build a prototype (weeks). Or build static mockups in Figma that look right but cannot test behavior (days, but limited signal). Both were better than nothing. Both were slow enough that most ideas died in the document phase before reaching a real user.
That gap is closing fast. AI-powered prototyping tools now let PMs build interactive prototypes (backed by real databases, not just clickable screens) in 15 to 30 minutes. Julie Price laid out what this changes in her Aha! piece. This article distills the workflow that actually works, the situations where prototyping is the right move, and the trap of "vibe coding" vs "PM coding."
Why this changes the validation loop
You can explain a feature in a requirement. Or you can prototype it and put it in someone's hands in 15 minutes.
The shift is not just speed. It is the type of feedback you can get. Static mockups generate opinions ("I like the color"). Interactive prototypes generate behavior (the user tried to click something that does not exist, the user got confused at step 3, the user finished the task in 4 seconds). Behavior is signal. Opinions are noise.
The prototype also changes the engineering conversation. Instead of a 10-page requirements doc, the PM brings a working prototype. Engineering can see what the experience should be, not just read about it. The interpretation gap that used to cost weeks of back-and-forth closes immediately.
When prototyping is the right next step
Prototyping is not always the right move. Use it when:
- The team is going back and forth on a UX decision. Two valid approaches, no consensus. A 30-minute prototype of each settles it in user feedback faster than another meeting.
- The feature behavior is hard to specify in words. Some experiences (timing, animation, interaction patterns) need to be felt, not read.
- You need to test demand or fit before committing engineering capacity. A working prototype shown to 10 customers reveals more than 10 customer interviews about the same feature.
- The stakeholder needs to see it to approve it. Executives often cannot evaluate requirements documents. A 5-minute prototype walkthrough produces decisions a 30-page doc cannot.
Prototyping is the wrong move when:
- The feature is technically simple and the UX is well-understood (a static spec is faster)
- The team needs alignment on strategy, not on implementation (prototyping is premature)
- The infrastructure work is the real challenge (a prototype hides the actual complexity)
The 5-step PM prototyping workflow
Step 1: Frame the prototype around one decision
Before opening any tool, write down the single decision you want the prototype to inform. "Should the onboarding be a guided tour or a checklist?" "Does the new export flow reduce the support ticket pattern?" One decision per prototype.
Prototypes that try to test everything end up testing nothing. The narrower the question, the sharper the signal.
Step 2: Build the prototype
Tools like Aha! Builder, Bolt, V0, Cursor, and similar let a PM describe the feature in natural language and produce a working prototype within minutes. The output is not pretty by design standards. It does behave like the product, which is what matters for validation.
Two important distinctions in this step:
- Backed by data, not just screens. A good prototype connects to a small database so users can actually create, update, and delete things. Static screen flows feel different from real interaction.
- Behavior over polish. The visual design will be refined later. The interaction patterns are what you are testing.
Step 3: Test with the right people
5-7 users from the target segment, not from the internal team. The internal team has too much context. The target users encounter the prototype the way real users will: cold, with no preamble.
The script for each test: "I want you to try to [accomplish the task]. Tell me what you are thinking as you go. I will not help you unless you get completely stuck." Watch where they hesitate. Watch what they try. Watch what they assume.
Step 4: Refine based on observation, not opinion
After each test, write three observations and zero opinions. "User tried to click the icon at the top before the button at the bottom" is observation. "User did not like the design" is opinion. Refine the prototype based on observations.
Two rounds of testing and refinement (10-15 users total) usually produce a prototype that is ready to either move to engineering build or to be killed because the signal showed the feature was not right.
Step 5: Hand off with confidence
The engineering handoff with a working prototype is fundamentally different from one with a spec. Engineering can:
- See exactly what to build
- Ask specific questions about edge cases the prototype revealed
- Estimate more accurately because the design is concrete
- Identify technical concerns earlier (this would not scale, this needs an API change, this conflicts with the existing architecture)
The PM still writes the doc, but it is now a thin doc plus the prototype, not a thick doc trying to compensate for the absence of working code.
The vibe coding trap vs PM coding
An important distinction emerging in 2026: "vibe coding" (building something that looks cool but does not behave consistently) vs "PM coding" (building something that tests a specific hypothesis cleanly).
| Vibe coding | PM coding |
|---|---|
| Built for visual impressiveness | Built to answer one question |
| Demo runs once, breaks on second try | Robust enough for 10 user tests |
| Showcased internally | Tested with target users |
| Becomes the new spec | Informs the spec, then gets discarded |
The trap is doing vibe coding while calling it prototyping. The signs: the prototype only works in one path, the team is admiring the prototype itself rather than the data it produced, the prototype gets sent to engineering as-is rather than as input.
What this changes about PM skills in 2026
The PM who can prototype now has access to a validation cycle that PMs without that skill cannot run as fast. This is becoming a baseline competency for product roles. Not because PMs are becoming engineers. Because the cost of testing an idea has dropped to a point where not testing is harder to justify.
Specifically, the PMs who learn to prototype:
- Ship better features because the validation cycle is faster
- Have more credibility with engineering because they show up with working examples
- Win more roadmap arguments because they bring evidence
- Move faster from idea to roadmap commitment to shipped feature
The takeaway
AI-powered prototyping collapses the validation cycle from weeks to hours and changes the type of signal PMs can gather. The right workflow is: one decision per prototype, build backed by data, test with target users not internal team, refine based on observation not opinion, hand off with confidence. Avoid the vibe coding trap by keeping the focus on hypotheses tested, not visuals impressed. The PMs who add this to their toolkit do not become engineers; they become PMs whose ideas reach users faster and more often, which is what the role has always been about.
