Product manager
AI Prompts for PRDs
Written by PromptsByRole
Start with Step 1See an example
- Who it is for
- Product managers who have a problem worth solving and some notes, and need a requirements draft their team can review.
- Outcome
- A one-paragraph problem statement, a PRD draft with goals, non-goals, requirements and success measures you choose, a list of open questions and assumptions, and a review pass from the point of view of engineering, design and support.
These prompts are plain text, so they work in whichever AI chat tool you use. Paste each step into the same chat so the AI keeps the context from earlier steps.
Step-by-step prompts
How to use it: replace the words in [brackets] with your details, paste Step 1 into your AI tool and answer any questions it asks, then paste the next steps into the same chat. Read and edit the result before you use it.
Step 1
Load the problem and what you know
I'm writing a product requirements document (PRD). Use only what I give you below. Never invent user quotes, research findings, metrics, dates or decisions. Where the PRD needs something I haven't given, write [NEEDED: what's missing]. - The problem, as users or customers describe it: [PASTE QUOTES, TICKET SUMMARIES OR RESEARCH NOTES, WITH NAMES AND ACCOUNT DETAILS REMOVED] - Who has the problem: [USER TYPE OR SEGMENT] - Why it matters now: [REASON, OR "NOT YET CLEAR"] - Constraints: [E.G. DEADLINE, PLATFORMS, TEAM SIZE, THINGS WE CAN'T CHANGE, OR "NONE GIVEN"] - Decisions already made: [LIST, OR "NONE"] First, write the problem in one paragraph using only these notes. Then list the questions I should answer before the PRD goes to review.
Step 2
Set goals, non-goals and success measures
Suggest goals and non-goals for this work. For each goal, suggest one way we could tell whether it worked, written as something we could observe or count. Don't suggest target numbers: write [TARGET: I set this]. Then list three things that are tempting to include but should be non-goals, and say why in one line each.
Step 3
Draft the PRD
Using Steps 1 and 2 and only the goals I've kept: [LIST THE GOALS AND NON-GOALS YOU KEPT], draft the PRD with these sections: Problem, Who it's for, Goals, Non-goals, Requirements (numbered, each one testable, marked Must or Should), User flow in plain steps, Success measures, Risks and dependencies, Open questions. Keep it under [800] words. Keep every [NEEDED] and [TARGET] placeholder. Describe what the product must do, not how engineering should build it.
Step 4
Review it from three seats
Review the draft three times, once as each of these readers: 1. An engineer who will estimate it: which requirements are ambiguous or can't be tested? 2. A designer: which user steps are missing, unclear or contradict each other? 3. A support lead: what will customers ask about or get stuck on? For each reader, list up to five issues and suggest a rewrite for each. Then list every assumption the PRD makes that nobody has confirmed yet.
Step 5
Write the review request
Write a short message under [100] words asking [REVIEWERS] to review the PRD by [DATE]. Say what decision we need from them, list the three most important open questions, and say where to leave comments.
Example of good output
Illustrative example: fictional product and notes; not real model output.
Given notes (illustrative): Three support tickets say customers "can't find past invoices", for example last month's. Users: small-business account owners. Constraint: no changes to the billing system this quarter.
Problem (Step 1): Account owners can't find past invoices on their own, so they contact support to get them. Billing can't change this quarter, so any fix has to work with the invoices the system already produces.
Requirement 3 (Step 3): Must: an account owner can open any past invoice from inside their account. [NEEDED: how far back invoices are kept]
Success measure (Step 2): Fewer support tickets asking for past invoices. [TARGET: I set this]
Engineer's review (Step 4): "'Any past invoice' can't be estimated until the retention period is known." This was added to Open questions.
Tips and pitfalls
- Start from evidence you can show. Paste real ticket summaries or research notes so the problem statement is grounded. If you only have a hunch, label it as a hunch in Step 1 so the draft treats it as an assumption to confirm.
- Write non-goals early. A clear list of what this work won't do heads off scope debates in review.
- Set your own targets. The AI doesn't know your baseline or what your team can commit to. Fill in every [TARGET] yourself.
- Keep requirements testable. If nobody could check that a requirement was met, rewrite it until someone could.
- Remove customer details first. Strip names, emails and account numbers from tickets and notes before you paste them, and use an AI tool your company approves.
FAQ
How is this different from the user stories playbook?
This playbook defines the problem, goals and requirements for a piece of work. The user stories playbook breaks agreed work into stories with acceptance notes, so it usually comes after a PRD is approved.
Can it write the technical design?
No. A PRD says what the product must do and why. Leave the technical design to the engineers who will build it.
My company has its own PRD template. Can I use it?
Yes. In Step 3, paste your template's section headings in place of the list in the prompt and ask the AI to keep them in that order.