How technical should I get in a PRD before engineering pushes back?

Describe what needs to happen, not how to code it. Good: "When user clicks X, show Y based on their subscription tier". Bad: "Use a Redux store with async middleware". Focus on the behavior and outcomes, let engineering figure out the implementation.

How long should a PRD be?

If it is over 8 pages, you are either building too much at once or explaining too much detail. Break it into phases or remove features. Most people do not read past page 3, so make sure the important stuff is up front.

What is the difference between PRD and product spec?

PRD covers the "what and why" - like needing a login system because users are confused. Product spec covers the "exactly how" - OAuth 2.0, JWT tokens, password reset flows, etc. Most of the time you just need the PRD.

Should I include edge cases that affect very few users?

Depends on who those few users are. If they are your biggest customers or the edge case could break everything, include it. If it is something like "what if someone enters their name as an emoji", document it in "future considerations" but do not let it delay v1.

Do I need a PRD for small changes like button colors?

No. PRDs are for features that need alignment, estimation, or have unclear requirements. Button colors, copy changes, and bug fixes just need tickets. However, if that button change is part of a bigger rebrand affecting many screens, then yes.

How do I get stakeholders to actually read my PRD?

Lead with a one-page executive summary that includes key decision points and what you need from them specifically. Schedule a 30-minute "PRD review" meeting - most people will skim it while you talk through it. Make it scannable with headers, bullets, and bold text.

What success metrics should I include in a PRD?

Pick 2-3 measurable metrics: one business metric (revenue, conversion, retention), one usage metric (daily active users, feature adoption, time spent), and one quality metric (error rates, support tickets, NPS). Make sure you can actually measure them before you ship.

PRD Writing Prompt

Q: What actually goes in a PRD?

The essentials are: WHY you are building this (not just what), who will use it (with names if possible), how you will know it worked (with real numbers), and what you are NOT building. Focus on preventing confusion by defining "done" clearly and not assuming everyone has the same context you do.

Q: How do I write PRDs when requirements keep changing?

Version your PRD (v1.0, v1.1, v2.0) and keep a changelog at the top. When someone asks for constant changes, show them the changelog. It helps people realize when they are being unreasonable and provides documentation for retrospectives.

Q: What if engineering says my PRD is impossible?

Ask "impossible or just really hard?" There is a difference. If truly impossible, work together to find alternatives. If just hard, dig deeper to understand the technical constraints or edge cases you might have missed.

Creates complete Product Requirements Documents with strategic context

documentationPopularintermediateJTBDRICEMoSCoWAARRR1500-2000 words

Customize Your Prompt

Fill in the variables to generate your personalized prompt

Product/Feature Name

Target Users

Additional Context (Optional)

Enable web search for current data

Preview

See how your prompt will look with the current variables

You are a Senior Product Manager creating a Product Requirements Document (PRD) for [Product/Feature Name] targeting [Target Users].

Structure your PRD with these sections:

## 1. EXECUTIVE SUMMARY
- Problem statement using Jobs-to-be-Done framework
- Solution overview in 2-3 sentences
- Success metrics (leading and lagging indicators)
- Resource requirements and timeline

## 2. STRATEGIC CONTEXT
- Market opportunity and competitive landscape
- How this aligns with company OKRs
- RICE score breakdown (Reach, Impact, Confidence, Effort)
- Risk assessment and mitigation strategies

## 3. USER RESEARCH & PERSONAS
- Primary and secondary user personas
- User journey mapping for key workflows
- Pain points and unmet needs
- Acceptance criteria from user perspective

## 4. FUNCTIONAL REQUIREMENTS
Using MoSCoW prioritization:
- MUST HAVE: Core functionality for MVP
- SHOULD HAVE: Important but not critical
- COULD HAVE: Nice-to-have features
- WILL NOT HAVE: Explicitly out of scope

## 5. NON-FUNCTIONAL REQUIREMENTS
- Performance benchmarks
- Security and compliance requirements
- Accessibility standards (WCAG 2.1 AA)
- Integration requirements with existing systems

## 6. SUCCESS METRICS & KPIs
- AARRR framework metrics
- Leading indicators for early validation
- Lagging indicators for long-term success
- Data collection and analysis plan

## 7. TRADE-OFF ANALYSIS
- **What we're optimizing for**: [Primary goal]
- **What we're trading off**: [Explicit compromises]
- **Alternative approaches considered**: [Other options and why rejected]
- **Technical debt implications**: [What debt we're taking on]
- **Future flexibility impact**: [How this affects future options]

## 8. ROLLBACK PLAN
- **Rollback triggers**: [Specific metrics/conditions that trigger rollback]
- **Rollback procedure**: [Step-by-step process]
- **Data preservation**: [What data needs to be saved]
- **Communication plan**: [How to notify users/stakeholders]
- **Recovery time objective**: [Maximum acceptable downtime]

## 9. FEATURE FLAG STRATEGY
- **Flag architecture**: [How features will be gated]
- **Rollout phases**: [% of users and timeline]
- **Monitoring per phase**: [What to watch at each stage]
- **Kill switch implementation**: [Emergency shutdown process]

Include specific, actionable details. Address edge cases and contingency plans.

## 🔍 Web Search Enhancement

**Leverage current web data to strengthen this analysis:**

1. **Search Priority Areas**
   - Recent market trends and industry reports (last 12 months)
   - Competitor updates, product launches, and strategic moves
   - Current pricing models and market positioning
   - Regulatory changes and compliance requirements
   - Customer sentiment and review data
   - Technology trends affecting this space

2. **Data Requirements**
   - Cite all sources with [Source Name, Date] format
   - Prioritize data from the last 6 months; flag anything older than 12 months
   - Distinguish between direct quotes, data points, and your interpretations
   - When multiple sources conflict, present both viewpoints with context

3. **Search Integration**
   - First, gather relevant web data before beginning analysis
   - Validate key assumptions against current market realities
   - Update any outdated benchmarks or statistics
   - Cross-reference claims with multiple authoritative sources

4. **Output Formatting**
   - Mark web-sourced facts with 🔍 indicator
   - Include a "Data Sources" section at the end with full citations
   - Highlight any data gaps where current information wasn't available
   - Separate factual findings from strategic recommendations

**Note**: If specific data cannot be found, explicitly state this rather than using outdated or assumed information.

## Important Guidelines

### Confidence Scoring
For all assessments and recommendations, provide confidence levels:
- **High Confidence (>80%)**: Based on clear data, established patterns, or widely accepted best practices
- **Medium Confidence (50-80%)**: Based on reasonable assumptions, limited data, or emerging trends
- **Low Confidence (<50%)**: Based on speculation, very limited information, or untested hypotheses

### Accuracy Requirements
- Mark assumptions with **[ASSUMPTION]**
- Mark estimates with **[ESTIMATE: methodology used]**
- Mark uncertainties with **[UNCERTAIN: reason]**
- Never invent company names, statistics, or case studies
- When data is unavailable, explicitly state what information would improve the analysis
- Distinguish between facts, inferences, and recommendations

### Source Attribution
- General knowledge: "Based on industry standards..."
- Inferences: "This suggests that..."
- Speculation: "One possibility is..."
- Best practices: "Common approaches include..."

What Makes a Good PRD

•Clear problem statement using Jobs-to-be-Done framework
•Specific success metrics with measurable outcomes
•User stories that capture different personas and scenarios
•Technical requirements that engineering can estimate
•Clear scope boundaries (what's in and what's out)

Common PRD Mistakes to Avoid

•Writing solutions instead of problems
•Vague success criteria like “improve user experience”
•Missing non-functional requirements (performance, security)
•No stakeholder alignment on priorities
•Too much detail too early in the process

Questions PMs Actually Ask (Not the Textbook Ones)

Okay but what ACTUALLY goes in a PRD? (Not the textbook answer)

Look, I've written 200+ PRDs. Here's what actually matters: WHYwe're building this (not just what), who's going to use it (with names if possible), how we'll know it worked (with real numbers), and what we're NOT building. Everything else? Nice to have.

The stuff that gets people in trouble: forgetting edge cases, not defining "done", and assuming everyone understands the context you have in your head.

How technical should I get before engineering tells me to stay in my lane?

Ha! Been there. Sweet spot is this: describe what needs to happen, not how to code it. "When user clicks X, show Y based on their subscription tier" = good. "Use a Redux store with async middleware" = prepare for eye rolls.

I learned this the hard way when our tech lead literally crossed out half my PRD and wrote "Let us figure out the implementation" in red marker. Message received.

My PRD is already 15 pages and I'm not done. Help?

Stop. Right now. I once wrote a 47-page PRD for a "simple" dashboard feature. Nobody read past page 3. Nobody.

Rule of thumb: if it's over 8 pages, you're either building too much at once or explaining too much detail. Break it into phases or kill some features. Your future self (and everyone else) will thank you.

PRD vs product spec... aren't they basically the same thing?

Nope! PRD = "We need a login system because users are confused". Product spec = "OAuth 2.0 with JWT tokens, password reset flow includes SMS verification, max 3 failed attempts before lockout".

Think of PRD as the "what and why". Spec is the "exactly how". Most of the time you just need the PRD. Save the spec for complex features or when engineering explicitly asks for it.

Should I include that one edge case that affects 0.1% of users?

Depends on who those 0.1% are. If it's your biggest customers or something that could break everything... yes. If it's "what if someone enters their name as an emoji"... probably not for v1.

I have a rule: if addressing the edge case takes longer than the main feature, it goes in the "future considerations" section. Document it so you don't forget, but don't let perfect be the enemy of shipped.

How do I write PRDs when requirements keep changing every week?

Oh, you work at a startup too? Here's what works: version your PRD. Seriously. PRD v1.0, v1.1, v2.0... and keep a changelog at the top.

When someone asks for the 47th change, show them the changelog. Sometimes they realize they're being ridiculous. Sometimes they don't, but at least you have documentation for the retrospective about why this took 6 months instead of 6 weeks.

What if engineering says my PRD is "impossible"?

First: ask "impossible or just really hard?" There's a difference. If it's truly impossible, work with them to find alternatives. If it's just hard... well, that's why we pay engineering the big bucks!

But seriously, dig deeper. Usually there's a technical constraint you didn't know about, or they're thinking about edge cases you didn't consider. Grab coffee, sit together, and find a path forward.

Do I really need a PRD for changing a button color?

No. Please no.

PRDs are for features that need alignment, estimation, or have unclear requirements. Button colors, copy changes, fixing broken links... just make a ticket. Life's too short for 3-page PRDs about hex codes.

(But if that button color change is part of a bigger rebrand affecting 47 screens... yeah, you might need a PRD.)

How do I get my stakeholder to actually READ the PRD?

Lead with an executive summary. One page max. Include the key decision points and what you need from them specifically.

Pro tip: schedule a 30-minute "PRD review" meeting. Most people won't read it beforehand, but they'll skim it during the meeting while you're talking. Gets you the feedback you need and they feel involved in the process.

Also? Make it scannable. Headers, bullet points, bold text for key info. Nobody has time for walls of text in Times New Roman.

What's the deal with success metrics? Do I really need numbers for everything?

Not everything, but more than you think. "Users will love it" isn't a metric. "Increase user satisfaction score from 6.2 to 7.5" is.

Here's what I learned after shipping features that "felt successful" but couldn't prove it: pick 2-3 metrics you can actually measure. One business metric (revenue, conversion, retention). One usage metric (DAU, feature adoption, time spent). One quality metric (error rates, support tickets, NPS).

And for the love of all things holy, make sure you can actually measure them before you ship. Finding out your analytics don't track the thing you promised to improve is... not fun.

How to Use This Prompt