Generative AI for Writing PRDs

I've been using generative AI to assist with PRD writing for over a year. Here's what it's genuinely good at, where it falls flat, and what I've kept in my workflow after the novelty wore off.

The promise of AI for PRDs sounds almost too good: you describe a feature, the AI writes the requirements document, you review and edit. Hours of work compressed into minutes. The reality is more nuanced — but still quite useful, once you understand the right way to use it.

---

What AI Does Well in PRD Writing

Generating comprehensive first drafts

If you give an LLM sufficient context — the problem you're solving, the target user, the proposed solution, the success criteria, the constraints — it will produce a structured first draft that covers most of the standard PRD sections. The draft won't be right in all the specifics, but it will be a useful starting point that's faster to edit than to write from scratch. More importantly, it will surface structural gaps and sections you might have skipped if writing quickly.

Edge case identification

Ask an LLM to identify the edge cases for a feature description, and it will produce a more exhaustive list than most PMs generate under time pressure. Some of these won't be relevant. But the process of going through the list and deciding which ones matter is faster than generating the list yourself. And catching edge cases in the PRD is cheaper than catching them in QA or production.

Technical constraint articulation

When working with engineers who have provided technical constraints verbally in a planning session, I'll use AI to help me translate those verbal constraints into clear, written requirements language. This is particularly useful when the technical context is complex and I want to make sure the documented constraint accurately reflects what was said.

---

What AI Fails at in PRD Writing

Context and strategy

The most important sections of any PRD are the ones that explain why. Why this problem? Why now? Why this solution over alternatives? These sections require deep context about the business, the user, the competitive position, and the strategic priorities — context that doesn't exist in a prompt. AI-generated "why" sections are generic and often wrong for your specific situation. These sections must be written by the PM who has the context.

Trade-off documentation

Good PRDs document the trade-offs considered and the reasoning behind choices. AI doesn't know what alternatives you considered, what constraints shaped your choices, or what you decided not to do and why. This institutional memory lives with the PM and needs to be written by the PM.

Stakeholder-specific framing

A PRD is a communication document. The best ones are calibrated to their specific audience — they anticipate the engineering lead's concerns, address the design team's questions, and provide the context that leadership needs to understand the priority. AI doesn't know your stakeholders. It produces generic documentation that doesn't anticipate specific audience needs.