PRDs fail when they list features without context — no “why this”, no “why now”, no “what we’re not doing”. Engineers fill in the blanks differently, scope creep arrives by week two, and the launch metric was never named. These 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. Pair with the PRD outline prompts when you want the skeleton first.
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. 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 epic3. 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 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 stop4. Spec-from-mockup PRD
Below is a mockup or wireframe description.
Convert 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 — list at the end.
{paste mockup description}5. Vendor brief PRD
I'm hiring {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 cancel6. 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:
- 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 × 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 alert9. 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., < X% of users still on old by Y date)
- What we promise NOT to break in the move10. 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}Common mistakes
- No success metric, or a metric that’s just “launch the feature”
- No “what we’re NOT doing” — guarantees scope creep
- Hidden assumptions disguised as facts (“users will…”)
- Edge cases listed 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
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
Tags: #Prompt #Product startup #PRD