20 product manager prompts that show the tradeoffs

AI writes a confident PRD in seconds by inventing the user, the data and the scope. These prompts make it work from your brief, notes and numbers, show its math, and list the open questions before engineering starts.

Swap anything in [brackets] for your brief, notes, tickets or numbers.

01. Write a PRD from a messy brief and list the open questions

You have a Slack thread, a call note and a deadline, but no spec.

Turn this messy brief into a product requirements document.

[paste the brief, thread, call notes or whatever you have]

Sections, in this order: the problem and who has it, the evidence we have for it, the goal with a measurable outcome, what is in scope, what is out of scope, the user flow in numbered steps, requirements marked MUST or SHOULD, and dependencies on other teams.

Use only what the brief says. Where it is silent, write [OPEN: the question] in place instead of filling it in.

Then list every open question at the end, grouped by who can answer it (me, design, engineering, legal, a customer), with the three that block the build first.

02. Split a feature into user stories with acceptance criteria

Refinement is tomorrow and the feature is still one big ticket.

Split this feature into user stories a team can build and ship one at a time.

Feature: [what it does]
Users: [who uses it and what they are trying to get done]
Constraints: [platforms, deadlines, things already built]

For each story:
1. As a [user], I want [action], so that [outcome].
2. Acceptance criteria in Given / When / Then form, three to six per story, each one testable by someone who did not write it.
3. A size guess of S, M or L and the one thing that makes it uncertain.

Order the stories so the first one ships something a real user can use, even if it is small. Flag any story that is really two stories, and any that only makes sense once another story ships.

03. Find the edge cases your PRD missed

The spec looks done and engineering starts next week.

Read this PRD as the engineer who will get the bug reports after launch.

[paste the PRD or spec]

List the edge cases it does not cover, grouped under: empty and first time states, errors and timeouts, permissions and roles, limits (very long, very many, zero, duplicate), concurrency (two people editing, double clicks, retries), data from before this feature existed, and accessibility.

For each one: the scenario in one line, what the spec currently implies would happen, and the question I need to answer. Rank the top five by how likely a real user hits them in the first month. Do not invent requirements; ask.

Unlock the other 17 prompts for free

Score a backlog with RICE and show the math
Turn interview notes into jobs, pains and quotes
Write a discovery interview guide about what people did, not what they want
Group support tickets into product problems worth fixing
Write a one page spec engineers can build from
Pick a success metric and the counter metric that keeps it honest
Design an experiment and answer the sample size questions first
Build a launch checklist with an owner for every team
Write release notes users actually read
Write a stakeholder update that leads with what changed
Write a roadmap narrative that says what you are not doing
Turn down a feature request with the reason and a next step
Run a pre-mortem before the launch ships
Tear down a competitor's product page claim by claim
Write one sprint goal from a long list of tickets
Turn a requested solution into the problem behind it
Have a second model review the first one's PRD