How to Write a PRD: The Product Manager's Complete Guide
A complete guide to writing product requirements documents that teams actually use. Covers problem statements, success metrics, scope, common mistakes, and how AI tools like ChatPRD fit into the process.
By The Cala Voice Team ·Most PRDs fail not because they are poorly written but because they start from the wrong place. A PRD is not a list of features. It is a document that makes the case for building something specific, defines what success looks like, and gives a team enough shared understanding to build it without daily escalation. When a PRD does that job, it speeds up engineering, reduces design rework, and keeps stakeholders aligned without constant meetings. When it does not, it becomes a document that everyone ignores.
The reason most PRDs fail to do that job is the same reason most product decisions fail: the problem is underspecified. Requirements get written before the problem is fully understood, and the result is a document that describes a solution without establishing why that solution and not some other.
What a PRD Is Not
Before covering what a PRD should contain, it is worth being clear about what it is not.
A PRD is not a technical specification. The technical spec tells engineers how to build something. The PRD tells them what to build and why. Writing both into the same document produces a hybrid that serves neither purpose well.
A PRD is not a roadmap entry. A roadmap item says "we are building X in Q3." A PRD says what X actually is, what problem it solves, and what done looks like.
A PRD is not a contract. The most common failure mode for longer PRDs is that they become documents teams negotiate over rather than align around. When requirements are treated as immutable commitments rather than shared understanding, the PRD becomes a source of friction rather than clarity.
The Core Components
A PRD that does its job contains six things.
1. Problem statement
The problem statement is the most important part of the PRD and the part most often written badly. A good problem statement answers: what is happening today, for whom, and why does it matter? It is not a feature description ("we need a search bar") and it is not a business goal ("we need to increase retention"). It is a specific description of a user problem or gap in the product experience that this work is intended to address.
A useful test: if you removed the solution from your PRD and showed someone only the problem statement, would they understand what is broken or missing? If not, the problem statement is not specific enough.
2. Goals and success metrics
What does success look like in measurable terms? This section forces you to connect work to outcomes rather than outputs. One primary metric, one or two secondary metrics, and at least one guardrail metric that should not regress. If you cannot define what success looks like before building, you cannot evaluate whether the work was worth doing after.
3. Users and use cases
Who specifically is this for? Not "our users" — a specific segment, persona, or job to be done. If the feature is for enterprise admins and not individual contributors, that constraint belongs here, because it will shape every design and engineering decision downstream.
4. Scope
What is explicitly in scope, and what is explicitly out of scope. The out-of-scope section is often more valuable than the in-scope section. Writing down what you are not building prevents scope from expanding during development and gives you a principled basis for declining mid-project additions.
5. Requirements
Functional requirements are the behaviors the product must support to solve the problem. Write them from the user's perspective, not the system's. "Users can filter results by date" is clearer than "the system shall support date-based filtering." Keep this section as short as the problem allows — requirements tend to expand on their own, and length here usually indicates insufficient problem clarity.
6. Open questions
Every PRD worth reading has a section of unresolved questions. What do we not know yet? What decisions are deferred? What assumptions need validation before or during development? This section signals intellectual honesty and prevents false confidence about the solidity of the spec.
Writing the Problem Statement
The problem statement deserves more attention because it is where most PRDs go wrong and where getting it right has the most downstream impact.
The common failure: the problem statement is written as a justification for a solution that was already decided. "We need a bulk export feature because users have asked for it" is not a problem statement. It is a feature request wearing a problem statement's clothes.
A strong problem statement has three properties. It is specific about who experiences the problem ("enterprise users managing more than 50 projects" is specific; "our users" is not). It is specific about what the problem is, including current behavior and the gap between current behavior and desired behavior. And it is specific about why it matters — what the user cannot do, or does less well, because of this gap.
A useful structure: "When [user type] tries to [do X], they experience [problem], which means they [consequence]. This results in [measurable impact]." This is not a template to fill out mechanically — it is a test that your problem statement meets the minimum bar for specificity.
Writing for Your Audience
A PRD typically has more than one reader, and different readers need different things.
Engineers need enough detail to make implementation decisions without escalating. They need to know what behavior the product must support, what edge cases are in scope, and what constraints apply — performance, platform, accessibility. They do not need extensive market context or strategic rationale.
Design needs the problem clearly stated and user needs well-specified so they can make design decisions that serve the right goals. They need to understand what success looks like, not a wireframe prescription.
Stakeholders and leadership need the problem, the goal, and the scope. They do not need functional requirements.
Many PMs write a single document for all three audiences and produce something simultaneously too detailed for executives and not detailed enough for engineers. The practical solution: a one-page summary at the top (problem, goals, scope, timeline) followed by the full requirements below. Stakeholders read the summary. Engineers read everything.
Common Mistakes
Requirements written as solutions. "Add a dropdown to the filter panel" is a requirement written as a UI prescription. "Users can narrow search results by category" is a requirement. The distinction matters because the first forecloses design decisions that the designer should own.
No guardrail metrics. Specifying what you are optimizing for without specifying what you are protecting sets up future regression. If you are optimizing for activation rate, specify that you are not willing to degrade retention to get there.
Missing the out-of-scope section. Scope creep happens most often not through bad actors but through reasonable people making reasonable additions to an underspecified scope. An explicit out-of-scope section prevents this.
Writing the PRD after the solution is decided. The PRD process is most valuable before the solution is locked in. When it becomes a retroactive documentation exercise, it loses the alignment and clarity functions that make it worth doing.
Using AI to Write PRDs
AI tools have changed the PRD writing process in a practical and significant way. The most time-consuming part of writing a PRD has traditionally been the first draft — getting a rough problem statement and a set of notes into a structured document that is clear enough to share. This is exactly the task AI handles well.
ChatPRD is the most widely-used AI tool built specifically for product documentation. Founded by Claire Vo — CPO at LaunchDarkly — it now serves 100,000+ product managers and has been used to generate over 750,000 product documents. The core workflow: give it a rough prompt — a Slack thread, meeting notes, a feature concept — and it produces a structured PRD draft covering problem statement, goals, user stories, functional requirements, and success metrics. From there, ChatPRD reviews your draft as a CPO would, flagging strategic gaps, weak problem statements, and missing edge cases.
What makes it useful beyond raw generation is the coaching layer. The tool does not just produce output — it pushes back on underspecified thinking in ways that improve the underlying document quality, not just the prose. It integrates with Notion, Linear, Confluence, GitHub, and a range of other tools, so documents land where your team already works.
A workflow that works well: use ChatPRD to generate the first draft from your notes, use the CPO feedback function to identify weaknesses in your problem statement and success metrics, then rewrite those sections yourself with the feedback in mind. The draft is not the final PRD — it is a forcing function that gets your thinking on paper faster so you can spend your time on the parts that require real judgment.
When to Skip the PRD
Not every feature requires a full PRD. A minor UI adjustment, a copy change, a performance fix — forcing these through a full PRD process adds overhead without adding clarity.
A useful threshold: does this work require alignment across more than one team, or does it require a decision about what success looks like? If yes, write a PRD. If the scope is contained to a single engineer making a bounded change with an obvious success condition, a clear ticket description is enough.
The mistake usually runs the other direction: treating the PRD as bureaucratic overhead and skipping it for work that genuinely requires alignment. The PRD is not a checkbox. It is the artifact of having done the thinking. If you cannot write the PRD, you have not done the thinking yet.
What to Read Next
For the interview context — PM interviews regularly include questions about how you approach requirements gathering, how you handle ambiguity in a spec, and how you work with engineering — the Product Design Interview Guide covers how to demonstrate structured product thinking under interview conditions. For the metrics section of your PRDs, How to Measure Product Success covers North Star metrics, AARRR, and guardrail metrics in depth.
Cala Voice helps you practice explaining your PM approach — including how you scope requirements, make trade-off decisions, and define success — in the interview context where these skills get evaluated.