Run a PM-led AI prototyping sprint before the PRD

The Prototype Comes Before the PRD Now

For most of the last decade, PMs wrote a PRD, engineering built it, and the team learned whether the design held up at QA or at launch. Modern AI tooling has flipped the order. A PM can now build a clickable prototype in a day, hand it to five users, and rewrite the PRD against real reactions in 72 hours. The PRD that lands on engineering's desk is no longer a guess; it is a contract anchored on observed behavior.

The leverage is enormous. A 3-day sprint replaces three weeks of spec debate with a working artifact, five user sessions, and a revised plan. SVPG's writing on Inspired and Transformed has long argued that prototyping is the highest-leverage discovery action available to a PM. AI tooling brings that argument home.

Why the PRD-first order is broken

A PRD written without a prototype encodes assumptions the team cannot test until code exists. Three failure modes follow:

• Imagined flow. The user flow that reads cleanly in a doc collapses when a real user attempts it. Engineers build the imagined flow, QA passes it, the user struggles, support hears about it.
• Padding scope. Without a prototype, the team builds in defensive scope ("we should also handle this case") because the doc cannot push back. The prototype rejects scope it does not need.
• Late stakeholder push. Stakeholders give feedback on the PRD that becomes scope creep because they have no concrete artifact to react to. A prototype concentrates feedback into specific reactions.

GV's design sprint method is the canonical reference for time-boxed prototyping; the AI-tooling variant collapses the same logic from five days to three because building the artifact is now hours of PM work, not days of designer work.

How the Run a PM-led AI prototyping sprint prompt works

Day 1 is frame and prototype. The morning produces a one-paragraph problem statement, a target user, the outcome, and three core moments. The afternoon turns those three moments into a clickable artifact using AI tooling. The non-negotiables are: realistic hardcoded content (not Lorem Ipsum), end-to-end coverage of entry, key interaction, and exit, and clickability on a real device. The exit criterion is that a partner can use the prototype without the PM's help.

Day 2 is user testing. Five sessions of 30 minutes. The script is short: do the task, the PM stays silent for 60 seconds to let the user stumble, the PM notes hesitations and expectations, and the user closes by naming what would make it a 10. The synthesis is structured as three frictions, two missing features users tried to use, and one unanimous win. Anthropic's research page collects related work on user evaluation methodology that informs how PMs design these sessions.

Day 3 rewrites the PRD against the evidence. The problem statement is validated or revised. The flow drops the three frictions. The deferred-features list captures what users asked for but the team is not building, and why. The killable risk names the one thing that, if it does not test better in beta, ends the feature. This last item is the discipline; teams that cannot name a kill condition tend to build everything indefinitely.

What good AI prototyping looks like

The prototype is not the production product. It is a believable simulation of the product to the user. Three properties make it work:

• Realistic content. The hardcoded copy and data look like real customer content, not template placeholders. Users react to the words, not to the structure.
• End-to-end flow. Entry, key interaction, and exit all click through. A prototype with broken edges cannot be tested.
• Production fidelity in the moments that matter. The three core moments behave like a real product. Everything else can be a static screen.

Anthropic's eval tool documentation is useful even at this stage; teams that include eval thinking in the prototype catch failure modes before they reach a PRD.

When to use it

• You are about to write a PRD for a feature the team has not seen working yet.
• A previous launch missed because the spec was clear and the user reaction was not.
• Engineering is asking for more clarity than the doc can give and a prototype would resolve it faster.
• A new market or new persona is being explored and the team has no shared model of the user.
• Stakeholders keep changing scope at PRD review and a clickable artifact would concentrate the feedback.

Common pitfalls

• Lorem Ipsum prototype. Users react to the words. Hardcode realistic content or the test produces nothing useful.
• Three users instead of five. Five is the floor for catching the second-most-common friction. Three users gives you noise.
• No killable risk. A PRD without a kill condition is a PRD that builds everything. Name the test that would shelve the feature.

Sources

• GV Sprint - Google Ventures
• Inspired - Silicon Valley Product Group
• Transformed - Silicon Valley Product Group
• Anthropic Research - Anthropic
• Anthropic eval tool documentation - Anthropic