How I use AI to write better PRDs

A year ago I would have told you that AI was useless for PRDs. The drafts it produced were generic, bullet-heavy, and read like LinkedIn posts. They had to be rewritten almost entirely, which meant I was doing two jobs — writing the PRD and editing a worse version of the PRD I'd written in my head.

That was a year ago. Today, AI does the first 60% of every PRD I write. It hasn't replaced the work, but it's reshaped it in a way that, on net, has made my specs better. This post is about how I got there — what I changed, and which parts of the document I still write by hand.

What changed wasn't the model. It was the prompt structure.

When I started, my prompts looked like: "Write a PRD for a feature that lets users sort their game inventory by rarity." The output was always bad in the same way: it hallucinated a problem statement, invented users I'd never met, and proposed metrics that didn't fit the business.

The shift was realizing the model couldn't write a good PRD from a one-line prompt because I couldn't write a good PRD from a one-line prompt. The information needed to write the document existed, but it was scattered across user calls, Slack threads, my notes, and my head. The job of the prompt wasn't to ask the model to write the PRD. It was to assemble what I already knew.

My current PRD prompt structure

I now feed the model six things, in this order:

  1. Context dump. A 2–4 paragraph plain-English description of the situation — what the product is, who the user is, what's prompting this work, and what the constraints are. I write this myself, and it's by far the most important part of the prompt. Bad context dump = bad PRD, every time.
  2. The problem. One paragraph on what specifically isn't working today. Not the solution, not the request from leadership. The actual user-facing problem.
  3. What I've already considered. Three to five options, with a quick note on what I like and don't like about each. This is where AI starts to add real value: it pushes back on my framing and surfaces options I missed.
  4. The constraints. Engineering, business, timeline, anything I know is fixed. "Has to ship in Q2," "can't change the data model," "must work in markets without high-quality LLM access," etc.
  5. A reference to a good past PRD. I keep two specs in a folder that I'm proud of, and I paste one in as a stylistic anchor. This pushes the output toward my voice and my team's conventions.
  6. The actual ask. "Draft a PRD covering [sections]. Be specific. Don't invent metrics, flag where I need to add them. Don't write fluff."

The output of this is usually a draft I'd grade as a B-. Which is much better than where I started two years ago, when my own first drafts were a B- and it took me a full afternoon to produce one.

What I always still write by hand

Three sections of every PRD I write are still 100% me, with no AI involvement:

Success metrics. AI is bad at this in a way that took me a while to notice. It generates plausible-sounding metrics ("increase D7 retention by 5%") that don't actually map to the feature. Worse, it picks metrics that sound rigorous but are gameable. I write these myself.

Open questions. The whole point of this section is to surface my own uncertainty. AI's tendency to project confidence makes it actively harmful here. If I let the model write open questions, I get a list of resolved ones.

The summary at the top. Two sentences. They're the most-read part of the document and they need to sound like me. I haven't found a way to get a model to write a summary that sounds like a real PM rather than a TechCrunch headline.

What's gotten better, on net

A few things that are quietly different about my PRDs since I started doing this:

They're longer, but tighter. I used to skip sections when I was rushing. Now I always have a draft of every section, even if it's brief, because the model produces them all by default. That makes the document more complete.

They engage with edge cases more. When I prompt the model to draft a PRD, it asks itself questions like "what about this edge case?" that I sometimes wouldn't think to ask under deadline pressure. Maybe a third of those are useful. The other two-thirds are noise. But the third is real.

They get worse if I'm lazy with the context dump. This is the biggest pitfall and I still fall into it. If I half-ass the context, the document's structure looks fine but the substance is hollow. Reviewers don't always catch it. I don't always catch it.

The honest caveat

I've used Claude for the bulk of this. I've also used ChatGPT and, briefly, a few other tools. The differences between them on PRD work are smaller than the differences between a good prompt and a bad one. If you're not getting useful PRD drafts out of AI tools today, my strong guess is that the prompt is the problem, not the model.

I'll write more about which tools I use day to day in a later post on AI tooling, and I'll write a separate post on how I do user research synthesis with AI — which has been an even bigger workflow shift than PRDs.

Thanks for reading. If you want to send me your PRD prompts to compare, I'll read every one — drop me a note on LinkedIn.

← Back to all posts