The task
You have a feature idea in your head (or in a Slack thread) and you need it in PRD form before the next planning meeting. The PRD has to be specific enough that engineering can estimate it, narrow enough that design can mock it, and honest enough that leadership can prioritise it against everything else in the queue. Without a PRD the conversation circles for weeks. With a vague PRD, the wrong thing gets built.
When AI helps — and when it does not
AI is excellent at turning a paragraph of context into the right shape of a PRD: it remembers to ask for non-goals, success metrics, edge cases, and open questions even when you forget. It is poor at deciding what the feature should actually do. Treat the AI draft as a forcing function — every section it fills with placeholder text is a section you still owe an answer on. Do not let AI invent product requirements you did not request, especially around legal, pricing, or data handling.
What to feed the AI
- The one-line feature idea, in plain language
- The user problem and any quotes / tickets / behavioural data that motivated it
- Business context (which OKR or strategic bet this ladders into)
- Hard constraints (deadline, headcount, tech stack, compliance)
- What is explicitly out of scope — anything you can rule out makes the PRD twice as useful
Copy-ready prompt
You are drafting a PRD for an internal product team.
Idea: <one line>
User problem and evidence: <quotes, tickets, data>
Business context / OKR: <bet>
Hard constraints: <deadline, stack, compliance>
Out of scope: <list>
Return a PRD with these sections, in this order:
1. Problem statement (3-5 sentences, no jargon)
2. Goals (3 max, each measurable)
3. Non-goals (at least 3 — what we are explicitly not doing)
4. Target users and primary use cases
5. Functional requirements (numbered, testable)
6. Non-functional requirements (latency, accessibility, privacy)
7. Success metrics (leading + lagging, with target numbers)
8. Open questions (things engineering or design needs to decide)
9. Rollout plan (flag, cohort, kill switch)
Where you do not have evidence, write "TBD — owner: <role>" instead of guessing.For richer drafts, try a second variant focused on adversarial review: “Now critique this PRD. Where are the assumptions that would sink it? Which metric is gameable?”
Recommended output structure
A skim-readable PRD: H2 per section, bullet lists for requirements, a table for metrics (metric / definition / current / target), and an “Open questions” list with an owner per row. Engineers should be able to find functional requirements without reading the strategy section.
How to check the output is usable
- Every goal has a number, a window, and a way to measure it
- Non-goals exist and are specific (not “we’re not building a CRM”)
- Every functional requirement is testable in one sentence
- The TBDs have owners, not just question marks
- Nothing in “Out of scope” reappears as a requirement
Common mistakes
- Letting AI invent metrics like “increase engagement by 25%” with no baseline
- A PRD with no non-goals — every PRD without non-goals expands by 40% in implementation
- Mixing functional and non-functional requirements into one bullet list
- Pasting the AI’s draft into Notion without removing TBDs — stakeholders treat placeholders as agreed scope
- Writing it solo and shipping it. Use AI to draft, but circulate it for engineering / design / data sign-off before estimation
Practical depth notes
For How to Use AI to Draft a PRD: Inputs, Prompt, and Product Requirements Structure, the difference between a usable AI result and a generic one is the input packet. Give the model the audience, the current draft or raw material, the desired format, the decision you need to make, and two examples of what good and bad output look like. Ask it to preserve facts first, then improve structure or wording second.
After the first response, do a separate review pass. Look for missing constraints, invented details, weak calls to action, and language that sounds plausible but does not match the real situation. The best final output should be easy to use immediately: clear owner, clear next step, and no hidden assumption that someone else has to untangle.
FAQ
- Should the PRD include UI mocks? No — PRDs describe behaviour, not pixels. Link the Figma file from “open questions” until design lands.
- How long should a good PRD be? One screen of bullets per section is plenty. If the PRD is 12 pages, you have a strategy doc, not a PRD.
- Can AI estimate engineering effort? No, and you should not ask it to. Effort estimates need someone who has touched the codebase.
Related
- PRD draft prompts — alternative prompt phrasings and PRD section templates
- User story writing — turn PRD requirements into agile user stories
- Feature prioritisation — once you have a PRD, decide whether to build it now
- PRD outline prompts — lighter-weight outline before the full PRD