I Build the Prototype Before I Write the PRD
I Build the Prototype Before I Write the PRD
I've written 20+ PRDs. The ones I'm proudest of have something in common: by the time I wrote them, I'd already clicked through a working version of the thing. Not a mockup, a functional prototype I built myself with Claude Code, before a single engineer was assigned.
Documents hide disagreement, prototypes expose it
A PRD can be read three different ways by three different people and still get approved. Everyone signs off, then two sprints in you discover that business thought a step was optional and engineering thought it was skipped entirely.
A clickable prototype doesn't allow that. When someone walks through the flow, they either object or they don't. The conversation stops being about the wording of a requirement and starts being about the behaviour of a product. In insurance workflows, where a single field can change what's legally on offer, that difference is worth a lot.
Discovery is cheapest before engineering is committed
The most expensive way to learn that a user journey is wrong is to learn it in QA. The second most expensive is to learn it in design review. The cheapest is to learn it in an afternoon, alone, with a prototype nobody has staffed yet.
That's the whole argument for AI-assisted prototyping. It moves the moment of learning earlier, to the point where changing your mind costs nothing but your own time. I use it to validate hypotheses, user flows, and UX decisions before engineering investment, and the effect on discovery cycle time has been the single biggest change to how I work.
What the prototype is not
It's not the implementation. It's not architecture, it isn't secure, and it doesn't handle the data model the real system needs. Treating a prototype as a head start on the build is how you end up with a codebase nobody wants to own.
I'm explicit with engineering about this: the prototype is a specification artefact. It exists to make the PRD unambiguous, and then it gets thrown away. What survives is the flow it proved and the edge cases it exposed.
It doesn't replace talking to users
There's a failure mode here worth naming. Prototyping quickly can make you feel like you've done discovery when all you've done is externalise your own assumptions faster. A prototype tests whether an idea is coherent, not whether anyone wants it.
Market and user research still comes first. The prototype is what I use after I understand the problem, to pressure-test my proposed solution before it becomes anyone else's sprint.
Where this is going for PMs
The PM who can build a working version of their idea has a different kind of leverage. Not because they should be shipping production code, but because they can arrive at a discussion with evidence instead of a deck.
The core skill hasn't changed. You still have to know which problem is worth solving, prioritise honestly, and write clearly enough that engineering doesn't have to guess. AI just removed the excuse for showing up with a hypothesis you haven't tried yourself.
Anuj skipped presentations and built real AI products.
Anuj Kantharia was part of the June 2026 cohort at Curious PM, alongside 20 other talented participants.