PRD Writing Prompt for Product Teams

What this prompt does

A PRD writing prompt turns a rough product decision into a requirements document that states the problem, names who has it, defines what success would look like, and lists requirements a second team could build from without booking a call with you. It covers one release or feature area, and every gap comes back marked as a question rather than quietly filled in.

The gaps are the point. A model asked to write a PRD will produce a beautiful one from almost nothing, complete with a target of "30% increase in engagement" that came from nowhere and a requirement that the interface be "intuitive and seamless." Both read like product work. Neither can be built or checked.

So the rules below spend most of their effort on refusal: what the model may not invent, which words it may not use, and where the unknowns go instead.

A PRD scopes a decision. It doesn't write the tickets inside it.

The prompt

Write a product requirements document from the brief below. Follow every rule.

**What we're considering building:** [ONE OR TWO SENTENCES, ROUGH IS FINE]
**Who has the problem:** [A SPECIFIC ROLE OR SEGMENT, never "users"]
**Evidence it's real:** [TICKETS, SALES CALLS, USAGE DATA, or "none yet"]
**What they do instead today:** [THE WORKAROUND, or "nothing, they leave"]
**Constraints I already know:** [DEADLINE / TEAM SIZE / PLATFORM / LEGAL, or "none"]
**Explicitly not in this release:** [WHAT I'VE ALREADY RULED OUT]

Return these sections, in this order:

1. **Problem.** What breaks today, for whom, and how often. Written so someone outside the team understands it without product context. If my evidence field says "none yet", open this section by saying the problem is unvalidated.
2. **Who it's for.** The primary role, and who is explicitly not the audience for this release.
3. **Success.** Name the goal first, then the signal that would show the goal was met, then the metric that measures the signal. Do not state a target number. Instead write the metric and then "baseline needed" so I know to go get it.
4. **Requirements.** Numbered. See the rules below.
5. **Out of scope.** What this release does not do, including anything a reader would reasonably assume it covers.
6. **Assumptions and open questions.** Everything you had to guess at, phrased as a question addressed to me. This section is not optional. If you think it's empty, say why.
7. **Risks.** What would make this the wrong thing to have built, and the cheapest way to find that out early.

Rules for the Requirements section:

- One requirement per numbered line. If a line joins two capabilities with "and", split it into two lines.
- Every requirement must be checkable by someone who has never spoken to me. If you cannot describe how you'd verify it, the line does not belong in this section.
- These words are banned: fast, easy, intuitive, seamless, robust, flexible, scalable, user-friendly, appropriate, as needed, etc. Replace each with a number I can test against, or move the line to Open questions.
- State what the product must do, not how to build it. No database choices, no framework names, no screen layouts.
- Mark each requirement Must or Should. Anything you'd call "nice to have" goes in Out of scope instead.

Rules for the whole document:

- Use only what I gave you. Do not invent usage numbers, research findings, competitor names, revenue figures, or customer quotes.
- Any number I did not supply goes in Assumptions as a question, never in the body.
- No effort estimates and no timeline.
- Where my brief contradicts itself, write neither version and raise it in Open questions.

How to use it

1. Put the evidence in even when it's thin. "Three tickets in June and one sales call" beats leaving the field blank, because the model writes the Problem section at the confidence level you gave it. Type "none yet" when that's true and the PRD says so out loud, which is the sentence you want reviewers arguing with.
2. Read section 6 first. Assumptions and open questions is where the document admits what you haven't decided. Most entries take a minute. One or two won't, and those are the real product decisions hiding inside what looked like a writing task.
3. Check the requirements against the ban list yourself. Models slip vague adjectives back in when the output runs long, usually in the last few lines.
4. Fill in the baselines before you circulate it. Every metric arrives marked "baseline needed," so go get the current number. A goal of 40% is meaningless until you know whether today is 12% or 38%.
5. Rewrite the Problem paragraph in your own words. People quote it in meetings for the next two months, and a paragraph in your voice gets challenged honestly in a way a generated one doesn't.

Six of the words this prompt bans are ruled out by name in NASA's systems engineering handbook, whose appendix on how to write a good requirement rejects "flexible, easy, sufficient, safe, user-friendly, usable, appropriate, fast, robust, quickly, easily, clearly" and more besides, on the grounds that none of them can be verified. That appendix also asks whether each statement expresses "only one thought per requirement statement," and insists requirements "state what is needed, NOT HOW to provide it." Aerospace and your feature release have little in common, but an untestable sentence fails the same way in both.

Success runs goal, then signal, then metric, because that order stops teams from measuring whatever the dashboard already shows. Kerry Rodden, Hilary Hutchinson and Xin Fu set out that process alongside the HEART framework (Happiness, Engagement, Adoption, Retention, Task success) in their CHI 2010 paper at Google, arguing that a metric "is unlikely to be useful in practice unless it explicitly relates to a goal." They also found product teams "have not always agreed on or clearly articulated their goals", the disagreement a PRD exists to surface before engineering starts.

Example output (partial)

Brief: invoice reminders for a small-business billing tool. Evidence: 14 support tickets since March, 2 churn interviews. Not in this release: partial payments.

Problem. Owners billing 20 to 60 invoices a month chase late payment by hand, usually on a Monday, exporting the list and emailing customers one at a time. Fourteen support tickets since March asked for reminders. Two of the four churn interviews this quarter named manual chasing as a reason for leaving.

Success. Goal: owners stop leaving because chasing payment is manual. Signal: reminded invoices get paid sooner than unreminded ones. Metric: median days-from-due-to-paid, split by reminded and not. Baseline needed.

Requirements.

1. Must. An owner can turn reminders on or off per invoice, any time before the invoice is marked paid.
2. Must. A reminder sends at 09:00 in the account's own timezone, not the server's.
3. Must. No reminder sends for an invoice marked paid, including one paid between scheduling and send time.
4. Should. The owner can see, on the invoice, every reminder sent for it with the date and recipient address.

Out of scope. Partial payments. SMS or WhatsApp delivery. Automatic card charges. Recurring subscriptions, which have a different due-date model.

Assumptions and open questions. (1) Which address does a reminder go to when an invoice has both a billing and a contact email? (2) What's the current median days-from-due-to-paid? Nothing in the brief gives it, and neither metric can be read without it. (3) Are reminders on by default for new invoices? Default-on and default-off are different products for the same feature.

Risks. If most late payment is customers who can't pay rather than customers who forgot, reminders move nothing and the churn interviews were about something else. Cheapest early check: send manual reminders from a shared inbox to 20 accounts for two weeks and read the replies.

Question 3 is the one worth the meeting. Default-on gets the feature used and risks a customer's client receiving an email the owner didn't know was going out, and no amount of writing settles which of those you'd rather explain.

Variations

When the idea is too early for a PRD

"Don't write a PRD. Write the launch announcement instead, in past tense, as if this shipped: one page, no jargon, for a reader who doesn't work here. Then list the questions that announcement can't answer yet."

For a release that mostly changes existing behaviour

"Add a 'Current behaviour' line to every requirement, describing what happens today. Where a requirement changes something users already rely on, add a migration note for existing accounts."

For a technical or platform PRD

"The audience is engineers. Keep the ban on implementation detail for the Requirements section, but add a Constraints section covering the interfaces, data ownership, and rate limits this must live inside."

Common pitfalls

• Don't let the document get long because it can. Amazon's PR/FAQ, used to propose products since 2004, holds the press release to "a few paragraphs, always less than one page" with the FAQ "five pages or less". A twelve-page PRD isn't more rigorous, it's just unread.
• Don't paste competitor research into the brief and expect it back unchanged. Anything you supply is treated as fact, so a shaky half-remembered claim becomes a requirement's justification. Keep competitive analysis as its own document and cite it.
• Don't delete the Assumptions section before circulating. It's the part reviewers can actually help with, and cutting it makes a document full of guesses look like a document full of decisions.
• Try instead: hand the requirements list alone to an engineer and ask "what would you need from me before starting?" Every question the list should have answered is a requirement that isn't checkable yet.

ChatGPT and Claude both hold the section order and the ban list across a full-length document. Gemini tends to reintroduce a target number in Success, so add "state no target numbers anywhere" as a final line. All three drift toward compound requirements as the output runs on, which is why the one-per-line rule sits at the top of that block rather than the bottom.

Who uses this prompt

• Product managers: writing up a direction the team has agreed on verbally, so refinement argues with a document instead of a memory. The rest are in prompts for product managers.
• Project managers: inheriting a feature with no written scope and needing the out-of-scope section most of all. See prompts for project managers.
• Entrepreneurs: scoping the next build with a contractor or a small team, where an unwritten assumption gets expensive fast. More in prompts for entrepreneurs.

The tell that it worked isn't the requirements list. It's that the open questions section contains something you'd been avoiding deciding, written down where other people can see it.