How product managers should prototype with AI: build throwaway versions, then generate the PRD

The way I’d approach a PRD is to build fake versions of the thing first. Use Claude Design or Bolt or v0, do visual versions of it, and use those to inform your thinking. Then extract the PRD from the prototypes and refine it with the operational detail they were never going to show. The majority of the PRD should be generated. You shouldn’t have to write it from scratch. You should have to review it and correct it.

A lot of the advice on how product managers should prototype with AI starts from the PRD: you write it and the AI turns it into something clickable. I do it the other way round. I’ve played the product manager role on an engagement, not just the tech lead one, and the prototype is far more useful as the input to the PRD than as the output of it.

Skip the pixel-perfect Figma file

One startup I did some work with is small, but they stopped doing things in Figma and started using Bolt and v0 for the ideation. What do I want this to be, rather than trying to do pixel-perfect designs. Just getting the functional flows correct. With a lot of the startups I’ve worked with we weren’t really using Figma at all anymore. You conceptualise it in v0 or Bolt, and now Claude Design, which didn’t exist at the time, you go, yeah, that’s pretty close, and you roll it out.

I have nothing against Figma, or against PRDs for that matter. But waiting a massive amount of time for a Figma design isn’t great. AI has shoved the bottlenecks into different places in a project, into the PRDs and into the verification. The code doesn’t take as long as it used to, and if the developers are sitting there waiting on a pixel-perfect file, product is the bottleneck now. That’s a fun thing to tell a product manager.

Go broad: three to five versions of each piece

The way I’d approach it is not trying to do one design. You go broad. Ask for lots of different things and try to get three or four, even five, different versions of different pieces of it. Don’t try to do a holistic “here’s the whole admin interface”. Take one screen or one flow and get several takes on that.

Having, let’s say, five different views of the upsides and downsides of different things is what informs your thinking. You can click through and go, well, I like this bit of this one and this bit of this one.

Throwaway code is the point

It’s one of the amazing things AI has given us: the ability to have throwaway code. The storytelling doesn’t need to be in the correct design elements. It doesn’t need your design system. You can even stand in front of it and go, well, this is not real, and this is not real, and we wouldn’t do it this way, and it’s still visual in a way that a non-technical person can follow. A picture tells a thousand words, and a moving interface tells a lot more.

They’re throwaway for the most part. You can showcase them, but you’re not shipping them. What they’re for is getting the thinking done up front. If the real problems are being found in pull request review, that’s a flaw in the process. Pull request reviews should mostly be a rubber-stamping exercise, because all of that thinking should have been done before anyone built the real thing. Cheap prototypes are where that thinking gets done.

Extract the PRD from the prototype, then add what it can’t show

Once you’ve got prototypes you’re happy with, get the AI to extract a PRD from them. Then refine it with the operational things that aren’t going to be in a prototype: how it’s going to have to interface with other systems, what the database schemas are. That part is yours to add. The rest should be generative. Review it, correct it, go backwards and forwards a bit where it’s got inaccuracies. If you’re writing the whole thing by hand, you’re doing the work the AI should be doing.

There’s no right format for a PRD. I’ve seen them be too high level and too granular, and getting the granularity right is somewhat an art form.

Demo it, because people don’t read

When you do the PRD walkthrough, demonstrate the prototypes. People don’t read things, right? As much as the PRD is important, for the most part people are visual.

On one engagement a developer had been through the PRD so many times and was still confused about how a key part of it should work: how users got added and removed, and what changed when one account had two different kinds of capability. The suggestion on the table was another round of aligning on the schema. Instead I said I’d do a prototype that demonstrated pretty much all of the functionality we’d been talking about, possibly multiple prototypes if I couldn’t fit it into one. I’d spend the evening with Bolt, mock out the screens, this is one view, this is the other, and we’d go through them at our session the next day. Some of that was already moving away from the PRD a little, and that’s fine. Once there are things to click, the architecture gets clearer for the developers as well.

The walkthrough itself shouldn’t be you presenting a finished answer. It’s supposed to draw on everybody’s knowledge, and it’s not about consensus building either, because at the end of the day you’re the owner and you make the decisions. You want people going, have you considered this particular problem? Record it. From the transcript you get a huge amount to feed back into the AI to refine the PRD. Have a folder full of transcripts of discussions, and all of that becomes a big part of the spec building.

Aim for 90%, then write the next PRD

I think we should stop avoiding rework in the way we used to. The way I work on my own projects now is much more lax. It doesn’t come out right the first time? I just prompt the AI to adjust it. Vibe coding has dirty connotations, but there’s a certain amount of truth to it, in that you’re able to very rapidly go, that’s not quite what I had in mind, and adjust it.

This is where having a perfect PRD with a perfect set of requirements is less important. What you got out of it was 90% there. Great. You can even release that to customers. Then you do another PRD with a set of features that closes the gap. And once it’s out, you’re adjusting it off feedback and A/B tests anyway, rather than spending all of your time in PRDs and in Figma. It’s the same reason I’d rather ship a thin pilot in days than plan one for a quarter.

If you want help changing how your product and engineering people work together on this, that’s what team enablement is.