The PRD is due Thursday, engineering asked three questions you can't answer, and the sales lead has just forwarded a screenshot saying "customers want this." AI prompts for product managers won't supply the evidence. They will help you draft faster, find the holes in what you wrote, and turn messy notes into the document formats your team expects.
These prompts are untested templates. I haven't run them against a live product, and every example output below is illustrative. The RICE numbers are real arithmetic I computed, but the features are invented. If you want a broader set aimed at Indian product teams, see AI prompts for product managers in India. This post is narrower: the documents you write every week and how to check them.
How do I draft a PRD with AI without getting filler?
Feed it the problem and your evidence, and tell it to leave gaps as questions. Filler appears when the model has to invent what you didn't provide.
You are helping a product manager draft a PRD. Use only the facts I give
you. Where something is missing, do not guess: add it to "Open questions".
Product / area: [PRODUCT AREA]
Problem (in the user's words if possible): [PROBLEM]
Evidence I have: [INTERVIEWS / SUPPORT TICKETS / METRICS, with counts]
Evidence I do NOT have: [WHAT'S MISSING]
Target users: [SEGMENT]
Constraints: [DEADLINE, TEAM SIZE, TECH, LEGAL, BUDGET]
Out of scope: [LIST]
Produce: 1) Problem statement (max 3 sentences), 2) Goals and non-goals,
3) Success metrics, each with a baseline marked [BASELINE NEEDED] if I
haven't given one, 4) Requirements, numbered, each tagged must/should/could,
5) Risks and dependencies, 6) Open questions, ranked by how much they could
change the plan.
Do not invent numbers, customer quotes or technical details.
Two lines matter most: "Evidence I do NOT have" and "Do not invent numbers". The first forces you to admit the gaps. The second stops a fake 23% uplift from entering a document your director will read.
Check the PRD against a skeptical reader
After the draft, run a second pass in a fresh message:
Act as a skeptical staff engineer reading this PRD. List: requirements that
can't be tested as written, terms used inconsistently, missing error and
empty states, dependencies not named, and any success metric with no way to
measure it today. Quote the line for each. Do not rewrite the PRD.
That output is a to-do list for you, not a replacement document.
How do I write user stories with acceptance criteria?
A story is only useful if a tester can pass or fail it. Ask for observable criteria and force an error case.
Turn this requirement into user stories: [REQUIREMENT]
Persona(s): [PERSONA]
For each story use: "As a [persona], I want [action] so that [outcome]".
For each story write 3 to 6 acceptance criteria in Given / When / Then form.
Rules:
- Every story needs at least one error case and one empty or edge case.
- No vague words (fast, easy, intuitive, simple, seamless). If I have not
given a number, write [THRESHOLD NEEDED].
- Split any story that would take more than a few days into smaller ones
and say why.
- List assumptions at the end.
Illustrative output for a requirement "users can export their invoices":
Story 1: As an account owner, I want to export invoices as CSV so that I
can share them with my accountant.
- Given I have 12 invoices, when I choose Export, then I download a file
with 12 rows plus a header.
- Given I have no invoices, when I open Export, then the button is disabled
and a message explains why.
- Given the export fails, when I retry, then I see an error with a retry
option and no partial file downloads.
Assumption: CSV only in this release. [THRESHOLD NEEDED] for max export size.
The [THRESHOLD NEEDED] tag is the useful part. It tells you which conversation to have with engineering before sprint planning.
How do I prioritise with RICE and check the maths?
RICE scores a feature as Reach times Impact times Confidence, divided by Effort. The model is good at questioning your inputs and bad at inventing them. Do the arithmetic yourself.
Here's a worked example with invented features. Reach is users per quarter, Impact uses a scale you define (here 3 massive, 2 high, 1 medium, 0.5 low), Confidence is a percentage and Effort is person-months.
| Feature | Reach | Impact | Confidence | Effort | Score |
|---|---|---|---|---|---|
| A: Bulk invoice import | 2,000 | 2 | 80% | 3 | 1,067 |
| B: Custom roles | 800 | 3 | 50% | 2 | 600 |
| C: Dark mode | 5,000 | 0.5 | 100% | 4 | 625 |
The sums: A is 2,000 x 2 x 0.8 = 3,200, divided by 3 gives 1,066.7. B is 800 x 3 x 0.5 = 1,200, divided by 2 gives 600. C is 5,000 x 0.5 x 1.0 = 2,500, divided by 4 gives 625.
Now the useful bit: sensitivity. If A's effort turns out to be 5 instead of 3, its score drops to 3,200 / 5 = 640, still just ahead of C at 625 and B at 600. If B's confidence rises from 50% to 80%, B becomes 800 x 3 x 0.8 / 2 = 960, which still trails A at 1,067. The ranking is stable against those two changes but A's lead over C is thin if effort slips. That's what to tell your stakeholders.
Here is my RICE table with the inputs and the source of each input:
[TABLE]
Do not recompute or change the scores. Instead: 1) for each row, say which
input is weakest evidence and why, 2) list what would have to be true for
the ranking of the top two to flip, 3) suggest the cheapest way to firm up
each weak input before I commit. Flag any input that looks like a guess
presented as a fact.
Use whatever impact scale your team agrees on; the scale above is just one common convention, so define yours in the prompt.
How do I write release notes customers read?
Write for what changes for the customer, not for what engineering shipped. Paste your ticket titles, not customer data.
Write release notes for [PRODUCT] version [VERSION], for [AUDIENCE:
end users / admins / developers].
Changes (from our tickets):
[PASTE TICKET TITLES AND ONE-LINE DESCRIPTIONS]
Format: a one-sentence headline, then sections New, Improved, Fixed. Each
item: what changed, who it affects, what they need to do (if anything), in
under 25 words. Leave out internal refactors. Do not claim benefits I have
not listed (no "faster" unless a ticket says how much). Mark anything
requiring action with "Action needed:". Flag any ticket you could not
classify.
If your notes come straight from git history, commit messages and changelogs from git log covers that workflow.
How do I write a stakeholder update that doesn't bury the ask?
Executives read the first three lines. Put status, risk and the decision you need there.
Write a weekly stakeholder update for [PROJECT].
Status inputs: [DONE THIS WEEK], [PLANNED NEXT WEEK], [BLOCKERS]
RAG status I have chosen: [GREEN / AMBER / RED] because [REASON]
Decision or help I need: [ASK, WITH DEADLINE]
Format: Line 1 status and one-sentence reason. Line 2 the decision I need
and by when. Then three bullets of progress, one risk with mitigation, and
next week's plan. Under 150 words. Do not soften a red or amber status. Do
not add progress I did not list.
For project-level versions of this, AI prompts for project managers covers status and risk logs.
How do I synthesise customer interviews?
Replace names with P1, P2 and remove anything identifying before pasting; check your company policy and participant consent first. Then insist on evidence for every theme.
Below are notes from [N] customer interviews, anonymised as P1 to P[N].
Find themes about [RESEARCH QUESTION].
For each theme give: a one-line statement, the participants who support it
(by ID), one direct quote per supporting participant, and counter-evidence
from others. Rules:
- A theme needs at least 2 participants; list single mentions separately.
- Quote exactly; if you can't find a quote, write NO QUOTE.
- Separate what people said they do from what they said they want.
- List what I did not ask that would change your confidence.
Spot-check three quotes against the source notes every time. The related D2C interview synthesis prompts show a variant with a counting step. With only 5 to 8 interviews, treat themes as hypotheses, not findings.
Can I run these prompts through an API or automate them?
If you do this weekly, you may want to run prompts without pasting each time, for example drafting update skeletons from a ticket export. AICredits is an OpenAI-compatible gateway where you can top up in INR via UPI from Rs 50 (AICredits). If you'd rather wire the steps into a workflow, you can self-host n8n on a Hostinger KVM 2; the setup is in self-hosting n8n with Docker on a VPS. Neither is needed for the prompts above, and I haven't tested these particular prompts through either.
Disclosure: the AICredits and Hostinger links are affiliate links; I may earn a commission if you sign up, at no cost to you.
Check before you send
- Every number in the document has a source you can name, or is tagged as needing one.
- No customer names, emails or identifiers were pasted into a tool you aren't cleared to use.
- Each acceptance criterion can be passed or failed by a tester.
- RICE inputs came from data or estimates by the people doing the work, and you recomputed the scores yourself.
- Release notes make no claim (faster, safer, easier) without a ticket supporting it.
- The update's first two lines state status and the ask.
- Three quotes from the synthesis match the source notes.
What not to automate
- The decision on what to build. The model can structure the trade-off; the call is yours.
- Estimates. Effort comes from the engineers who will do it.
- Anything you'd be embarrassed to defend line by line. If you can't explain a sentence in a review, cut it.
- Customer quotes you haven't verified.
More starting points live in the prompt library. For why the "use only what I gave you" rule works, see the hallucinations lesson.
