How I Write Better PRDs in Half the Time
Post 2 of 6: The AI-Augmented Product Director
The PRD is the document every PM loves to hate. You know it needs to exist. You know it will be referenced for months. You know that a bad one will haunt you in sprint reviews, design critiques, and future retros.
And you also know that writing a good one takes a very long time.
Or it used to. Here is how I have changed that.
The Old Way (and Why It Was Slow)
My PRD process used to look like this:
- Come out of discovery with a head full of context: customer data, technical constraints, business goals, competing priorities
- Stare at a blank doc for 20 minutes
- Build out the skeleton outline
- Polish each section before moving on, then rewrite the whole thing because it still was not tight enough
- Share it, get feedback, and revise two or three more times
The mistake for me was always starting too structured: one section at a time, polished before moving on. Then I would go back and do the whole thing over, better. Repeat, repeat, repeat — and the original goal was gone.
The Unlock: I Built the Structure Into a Skill
A lot of the advice you will see about using AI for PRDs warns you not to let it write the whole thing in one shot. The reasoning: you will get generic filler that looks like a PRD but does not represent your thinking.
That advice is correct if your prompt is "write me a PRD for X." It is not correct once you have encoded your standards into a skill.
The part of my old process that was eating my time was not the writing. It was the structure. Every PRD I write follows the same template. Every PRD needs the same kinds of context: which system, which persona, which business driver. Every PRD has the same quality bars: user stories with measurable acceptance criteria, configurable defaults instead of hard-coded numbers, healthcare-domain assumptions called out explicitly.
I used to carry all of that in my head and apply it to a blank doc, one section at a time. Now it lives in an AI skill.
The skill encodes:
- The "DrFirst" PRD template, section by section
- Quality standards — Given/When/Then acceptance criteria, the "configurable value, default X" pattern, measurable performance metrics
- Healthcare and platform domain context — NCPDP standards, Gadget architecture, HIPAA compliance patterns
- An intake protocol — four questions that get the AI everything it needs before drafting
How a PRD Actually Gets Written Now
I type one sentence: /PRDs a single clip-on UI to interact with XYZ.
The skill asks four questions:
- Are there JIRA issues, Confluence pages, or other documentation I should read first?
- Which component will own this?
- Who is the primary persona?
- What is the primary business driver?
I answer in two minutes. The AI then reads the documentation I pointed it at, grounds itself in the actual product platform documentation, and writes the entire PRD in one pass — title, summary, strategic context, assumptions, goals, user narrative, user stories with Given/When/Then acceptance criteria, change log.
That is the whole drafting workflow.
What I Still Do
Review and tighten. The skill gets the structure right and the standards enforced, but I still read every line. Is the persona accurate? Do the acceptance criteria match what engineering will actually verify? Is anything missing that a reasonable reader would expect?
The voice still matters. I read it and rewrite any sentence that does not sound like me. The structure is skill-assisted; the voice is mine.
What This Does Not Replace
The skill does not know my users. It structures user stories, but the genuine insight from being in a customer conversation has to come from me.
The skill does not know my team's constraints. I have had it propose acceptance criteria that were technically nonsensical given our architecture. The final review by someone who knows the system is what makes it valuable.
The skill is only as good as what I encoded into it. Building it took real time. I spent many iterations getting the template right, the quality bars sharp, the intake questions precise. That investment is what every future PRD now compounds on.
The Bottom Line
A PRD that used to take me half a day now takes about an hour: two minutes of intake, a few minutes for the AI to read context and draft, then thirty to forty-five minutes of review and refinement.
More importantly, the documents are better. Not because the AI is a better writer than I am — it is not — but because the skill enforces the structure and standards I used to apply inconsistently, and it forces me to make my context explicit before drafting begins.
The real unlock was not finding a clever prompt. It was building a tool that encodes what I already knew.