Most PRDs fail the same way: they list features without context. No “why this,” no “why now,” no “what we’re not doing.” Engineers fill the blanks differently, scope creep arrives by week two, and nobody named the launch metric. These 12 prompts force the four things every PRD needs — a problem with a named user, a measurable goal, an explicit out-of-scope list, and surfaced open questions — and they keep the AI from padding the draft with filler.
Copy a template, replace the [bracketed] placeholders with your own facts, and paste. Want the skeleton first? Pair these with the PRD outline prompts.
TL;DR
- Pick the template that matches your scope (feature, epic, MVP, integration, deprecation, A/B, etc.).
- Replace every
[placeholder]with a real fact — the more specific your input, the less generic the output. - Every template already bakes in a success metric and an explicit “out of scope” list. Don’t delete them.
- Run prompt 11 (adversarial critique) on the draft before you share it.
- Model pick (as of June 2026): Claude Opus 4.7 or Sonnet 4.6 for long, structured docs; ChatGPT GPT-5.5 Thinking when you want fast iteration.
Which model to use
Any frontier model drafts a usable PRD, but the differences matter once the doc gets long. As of June 2026:
| Model | Context | Strength for PRDs | Notes |
|---|---|---|---|
| Claude Opus 4.7 / Sonnet 4.6 | 1M tokens | Long, structured docs; pastes whole research dumps + transcripts | Sonnet 4.6 is the everyday workhorse; Opus 4.7 for the hardest synthesis. Bundled with Claude Pro at $20/mo. |
| ChatGPT GPT-5.5 (Thinking) | ~320 pages in-app on Plus ($20); full 1M on $200 Pro | Fast back-and-forth, tight rewrites | Default model in ChatGPT since ~April 2026. |
| Gemini 3.1 Pro | 1M tokens | Synthesizing from Google Docs / Drive | Google AI Pro $19.99/mo. |
For a single-feature PRD, model choice barely matters. For an epic that ingests interview notes, analytics exports, and a half-written design doc, the 1M-token context on Claude or Gemini keeps everything in one pass instead of forcing you to chunk it. Specialized PM tools (e.g., ChatPRD) wrap these models with PM-specific templates if you write PRDs daily.
Best for
- New feature scoping
- MVP definition
- Cross-team alignment
- Vendor and agency briefs
- Integrations and platform work
- Deprecations and migrations
1. Feature PRD (1 page)
Feature: [one-line summary].
Audience: [persona — role, context, current alternative].
Problem we're solving: [pain — with one quote or data point].
Output a 1-page PRD with these sections:
- Problem (with evidence)
- Users and use case
- Goal and success metric (measurable)
- Scope: in / out (3 each, minimum)
- Happy-path UX in 5 steps
- Edge cases (>=5)
- Dependencies and assumptions
- Open questions
Each section 80 words or fewer. No section may say "TBD".
2. Epic-level PRD (2 pages)
Epic: [name].
Timeframe: [quarter].
Strategic goal it ladders to: [company-level goal].
Output a 2-page PRD:
- Market context (what changed, why now)
- User insight (the one belief this epic rests on)
- Success metric and a tripwire metric
- Hypothesis stated as "If we ship X, then Y, because Z"
- Milestones with rough dates
- Risks ranked
- Dependencies on other teams, with named owners
- 3 things explicitly out of scope for this epic
3. MVP PRD
Product idea: [one paragraph].
The 1 belief we'd kill the project for if wrong: [belief].
Output an MVP PRD:
- The thinnest slice that delivers user value AND tests the belief
- What we're cutting that future versions need (list 5)
- What we'll learn from the MVP, and the metric / threshold that means "keep going"
- Success criteria broken into "ship", "use", "love"
- Estimated build time in person-weeks (range)
- Kill criteria: when do we stop
4. Spec-from-mockup PRD
Below is a mockup or wireframe description.
Convert it into a PRD:
- User flow in 5 steps with entry / exit points
- Fields and data needed (name, type, validation, required)
- Validation rules in plain language
- Error states (>=4)
- Empty states (>=3)
- Loading / async states
- Edge cases the mockup doesn't show
Flag any interaction the mockup leaves ambiguous, listed at the end.
[paste mockup description]
5. Vendor brief PRD
I'm hiring a [vendor / agency type] to build [scope].
Budget envelope: [range]. Deadline: [date].
Write a vendor brief:
- What we want (with examples)
- What we explicitly don't want (with examples)
- Deliverables and file formats
- Milestones with payment trigger
- Acceptance criteria (objective, testable)
- IP terms in plain English
- Communication cadence
- One paragraph on what would make us cancel
6. PRD with explicit “what we’re NOT doing”
For [feature], write a PRD where 30% of the document is what's explicitly OUT of scope.
List 5-7 things people will assume are in scope but aren't. For each:
- Stakeholder who'll assume it
- Reason it's out (cost, dependency, scope discipline)
- When we'd revisit it (named version or trigger)
Then the regular PRD sections (problem, users, goal, scope-in, UX, metrics, risks).
Output starts with the out-of-scope list so reviewers see it first.
7. PRD with risk register
For [feature], write a PRD that includes a real risk register.
Risk register format:
- 5 risks minimum
- Each risk: description, category (technical / market / org / legal), probability (L/M/H), impact (L/M/H), mitigation, owner
- Risks ranked by probability x impact
- 1 risk marked as "we accept this"
Plus the normal PRD sections, kept brief.
8. Integration / platform PRD
Integration: [our product] <-> [their product / API].
Direction: [one-way pull, one-way push, two-way].
Output a PRD covering:
- User outcome and trigger
- Data model: what flows where, including PII fields
- Auth model and token lifecycle
- Rate limits and backoff strategy
- Failure modes and user-facing error messages
- Versioning: what we do when their API changes
- Privacy and compliance notes
- Monitoring and on-call alert
9. Deprecation / migration PRD
We're deprecating [feature] in favor of [new path].
Affected users: [segments, sizes].
Hard cutoff date: [date or "TBD"].
Output a deprecation PRD:
- Why we're killing it
- Who's affected and how
- Migration path (manual, automatic, hybrid)
- Comms timeline: T-90, T-30, T-7, day-of, post
- Rollback plan if migration fails
- Success metric (e.g., under X% of users still on old by Y date)
- What we promise NOT to break in the move
10. A/B-test PRD
For experiment: [what we're testing] vs [control].
Output an experiment PRD:
- Hypothesis as "If we change X, then primary metric moves by Y, because Z"
- Primary metric and how it's measured
- Guardrail metrics (>=2) that must not regress
- Sample size and expected duration (state assumptions)
- Audience and exclusions
- Variant arms with specifics
- Decision rule: ship / kill / iterate
- Pre-registered list of "we won't make these decisions on this test"
11. PRD review prompt — adversarial critique
Below is my draft PRD.
Critique it as a skeptical reviewer:
- Is the problem clear, and is it actually a problem (or a solution looking for one)?
- Is the success metric measurable, and is it the right metric or a vanity proxy?
- Is the scope realistic given the timeline?
- Are open questions surfaced or hidden in assumptions?
- What's missing that would block engineering on day 1?
- What's in scope that doesn't earn its place?
Output: 5 strengths, 5 fixes, and the 1 question I should answer before sharing this.
[paste PRD]
12. PRD-from-user-interviews prompt
Below are notes from [N] user interviews on [topic].
Synthesize into a PRD-ready brief:
- The recurring pain (with quote evidence)
- The current workaround users invented and why it falls short
- The "if you could wave a wand" requests, clustered into 3 themes
- The 1 quote that should open the PRD
- Anti-signals: people who DON'T have this problem and why
- Suggested success metric tied to language users actually used
End with the 2 things I should confirm in one more interview before writing the PRD.
[paste notes]
How to get a sharper draft
- Feed real inputs, not adjectives. Paste an actual user quote, a support-ticket count, or a churn number. “Users are frustrated” produces a generic PRD; “37% of trial users never reach the second screen” produces a focused one.
- Set hard limits. Word caps per section and “no section may say TBD” stop the model from hedging. Templates 1-3 do this on purpose.
- Make it argue with itself. Run prompt 11 on the output, then feed the critique back with “rewrite addressing fixes 1, 3, and 5.” Two passes beats one long prompt.
- Pin the metric first. If you can’t state the success metric, the AI will invent a vanity one. Decide the metric before you draft, or ask the model to propose three and pick.
Common mistakes
- No success metric, or a metric that’s just “launch the feature.”
- No “what we’re NOT doing” — that guarantees scope creep.
- Hidden assumptions disguised as facts (“users will…”).
- Edge cases left as “TBD” — engineering will define them, and you won’t like the answers.
- One PRD trying to be a vision doc, a spec, and a launch plan at once.
FAQ
Will an AI-drafted PRD pass review? A draft, not a finished doc. The model gives you structure, surfaced edge cases, and a first metric in minutes. You still own the decisions: the real success metric, the actual scope cuts, and the trade-offs only your team knows. Treat the output as a strong first draft to edit, not a final artifact to ship.
Which model is best for PRDs in June 2026? For long PRDs that ingest research, Claude Opus 4.7 or Sonnet 4.6 and Gemini 3.1 Pro all carry 1M-token context, so you can paste interview notes, analytics, and a half-written design doc in one pass. For fast iteration on a single feature, ChatGPT GPT-5.5 (Thinking) is quick and accessible. In head-to-head PRD tests by PM writers, Claude is a frequent pick for structured long-form.
How do I stop the AI from writing generic filler? Give it specifics (a real quote, a real number), cap each section’s length, and forbid “TBD.” The templates here do all three. If a section still reads vague, ask the model to “cite the exact input that supports this line or delete it.”
Should I use a dedicated PRD tool or a general chatbot? If you write PRDs occasionally, a general model plus these prompts is enough. If you write them weekly, a PM-specific tool (e.g., ChatPRD) layers templates, coaching, and integrations on top of the same underlying models. For background on inputs and structure, see How to use AI to draft a PRD.
Can the AI define my edge cases? It surfaces candidates fast (templates 1 and 4 push for 5+ each), which is the point — most missed edge cases are ones nobody thought to list. But validate each against your real system; the model guesses behavior it can’t see in your codebase or data.
Related
- User story prompts
- Feature prioritization prompts
- Product Problem Statement Prompts for PMs and Founders
- How to Use AI to Draft a PRD: Inputs, Prompt, and Product Requirements Structure
- PRD Outline Prompts: 15 Templates for the Structural Skeleton of a PRD
External: Product Requirements Document guide (Jama Software, 2026)
Tags: #Prompt #Product startup #PRD