PRD Writing Prompt
Creates complete Product Requirements Documents with strategic context
- •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)
- •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
What belongs in a PRD?
Start with WHY you are building it, who will use it, how you will measure success, and what is out of scope. Add the requirements and constraints needed to make the decision.
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 much technical detail should I include?
Describe required behavior and relevant constraints. For example, state what a user sees based on their subscription tier. Specify an implementation such as Redux only when it is a real constraint.
Review technical requirements with engineering so the PRD captures constraints without prescribing unnecessary implementation details.
My PRD is already 15 pages and I'm not done. Help?
Review which sections readers need to understand the problem, scope, and decision. Move detailed supporting material to an appendix.
Length alone does not tell you whether the scope is too large. Consider phases when the work contains independently useful pieces.
PRD vs product spec... aren't they basically the same thing?
A PRD usually explains the problem, intended outcomes, and requirements. A technical specification can detail implementation choices, such as authentication flows, token handling, and retry limits. Teams use these labels differently.
Agree with engineering on which document holds requirements and which holds implementation details. Link them so readers can follow the decision.
Should I include that one edge case that affects 0.1% of users?
Assess the harm, affected users, and likelihood. A rare security or data-loss case may matter more than a frequent cosmetic issue.
Compare the risk of deferring the edge case with the cost of handling it. Document the decision and any follow-up work.
How do I write PRDs when requirements keep changing every week?
Version the PRD and keep a changelog of material changes to scope, assumptions, and decisions.
For a new request, record its impact on scope and timing before agreeing to it. The changelog helps explain how the plan changed.
What if engineering says my PRD is "impossible"?
Ask which constraint makes the requirement infeasible and whether an alternative could achieve the same outcome.
Review technical limits and edge cases together, then document the agreed approach.
Do I really need a PRD for changing a button color?
A small, well-defined change can usually be handled with a ticket.
Use a PRD when work needs alignment, estimation, or clarification of requirements. The document should match the decision’s scope.
A button-color change within a rebrand affecting 47 screens may need broader requirements and coordination.
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.
A focused review meeting can help resolve open questions. Send the document beforehand and state which decisions or feedback you need.
Use headings and lists to help readers find the problem, requirements, and decisions.
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.
Choose metrics you can measure that reflect the intended outcome. Relevant measures may include business results, usage, and quality; you do not need one from every category.
Verify the required tracking before launch so you can measure the outcome.
When to use it
Use this template when planning new features, API integrations, or product enhancements that require stakeholder alignment and engineering estimates.
Before you use the output
- •Fill in the variables with the facts and constraints you have.
- •Check the output against your source material and revise any mistakes.
- •Enable web search where available and check the dates and sources it returns.
Expected output
Structured PRD document