How to Write a Proper PRD: Structure and Best Practices

Write a proper product requirements document (PRD) by stating the problem and who has it, defining what is in and out of scope, listing requirements as testable statements, recording your assumptions and open questions, and setting acceptance criteria. Draft it with engineering and design in the room, not after. Then review it and keep it current.

This is a guide for product managers and tech leads writing a PRD for a real feature with a real deadline. It covers the sections a PRD needs, the order to write them in, how to document assumptions properly, when in the cycle to write it at all, and the mistakes that show up as rework six weeks later.

What should be included in a PRD?

A PRD should include the problem, the goals, the scope and non-goals, the users, the requirements, the edge cases, the assumptions, the dependencies and the acceptance criteria. Everything else is optional. Templates that run to twenty headings mostly exist to reassure the author.

Section	The question it answers	What goes wrong without it
Problem and evidence	Who is struggling, and how do we know?	The team ships something nobody asked for
Goals and success measures	What changes if this works?	Nobody can say afterwards whether it worked
Scope and non-goals	What are we deliberately not doing?	Scope grows by consent, one small yes at a time
Users and use cases	Who is this for, in what situation?	Requirements written for an imagined average user
Requirements	What must be true when this ships?	Engineers guess, and guess differently from each other
Edge cases and error states	What happens when it goes wrong?	Rework in QA, or a support queue after release
Assumptions and open questions	What are we taking on trust?	A wrong assumption surfaces in week three
Dependencies	Who or what else is needed, and by when?	Blocked mid-sprint by a team who never heard of the project
Acceptance criteria	How do we know it is finished?	Sign-off turns into an argument about intent

Non-goals earn their place more than any other section. They are the only part of the document that lets you decline a reasonable request in week four without relitigating the whole plan.

How much detail each section needs varies enormously with the size of the change, and getting that wrong in either direction is its own problem. The question of PRD length and detail level is worth settling separately. If you are unsure whether this document should be a PRD at all rather than a technical spec or a functional spec, the distinctions between the requirements document types are clearer than the naming suggests.

How to write a proper PRD?

Write a PRD in this order, because each step constrains the next and doing them out of sequence produces a document that argues with itself.

1. Write the problem statement and get it agreed before anything else. Two or three sentences on who has the problem, what it costs them, and what evidence you have. If you cannot get agreement on this paragraph, you will not get agreement on anything downstream, and you have just saved yourself a week.
2. Define the non-goals. Do this second, while the temptation to include everything is at its strongest. Writing non-goals early forces the scope argument to happen before people are attached to their favourite additions.
3. Describe the users and the situations they are in. Named segments, real scenarios. “A finance lead reconciling invoices at month end, on a laptop, interrupted constantly” produces better requirements than “users”.
4. Write the requirements as testable statements. Each one describes an observable outcome. “The system rejects a duplicate submission and shows the original submission’s reference” is a requirement. “The system handles duplicates gracefully” is a mood.
5. Work through the edge cases and error states deliberately. Empty states, permissions, partial failures, what happens on a slow connection, what happens to data already in the system. This is the section engineers read first and PMs write last.
6. Record assumptions and open questions with owners. Covered in detail below. Do not let a decision that has not been made hide inside a sentence that sounds settled.
7. List dependencies with dates and names. Another team’s API, a legal review, a vendor contract, a design system component that does not exist yet. Each one gets a person and a date, not a team name.
8. Write acceptance criteria and get the review booked. State what has to be demonstrably true for the work to be accepted. Then put a meeting in the diary with engineering, design and QA before you circulate the draft, because a document sent for comment gets comments, and a document walked through gets objections.

The order matters more than the template. A PRD written problem-first tends to end up short. A PRD written solution-first tends to end up describing a feature you have already decided to build, with the problem reverse-engineered to justify it.

If your requirements would survive renaming the feature, they are probably describing behaviour. If they would not, you have written a design document and given it the wrong title.

What are assumptions in a PRD?

An assumption in a PRD is anything you are treating as true without having confirmed it, and which would change the plan if it turned out to be false. That second clause does the work. If nothing changes when the assumption breaks, it is background, not an assumption worth recording.

They usually fall into three types:

• User assumptions. How people currently do the thing, how often, and whether they would change behaviour to use what you are building.
• Technical assumptions. That the existing data model supports the new state, that the third-party API returns what its documentation claims, that the volume fits inside current infrastructure.
• Organisational assumptions. That a team will be free in the sprint you need them, that legal review takes a week, that the pricing change is already approved.

Write each one in a form that can be checked:

We assume support tickets about failed exports are mostly caused by timeouts rather than malformed data. If that is wrong, the retry work does not help and we should be validating input instead. Priya to sample fifty tickets by Friday.

Four elements: the belief, the consequence if it is false, the person confirming it, the date. An assumption without a consequence attached gets skimmed. An assumption without an owner gets discovered by the engineer who hits it.

Keep assumptions separate from requirements in the document. Teams that blend them end up building a requirement that was never agreed, because it was phrased confidently enough to look like one.

What constitutes a good PRD?

A good PRD is one an engineer who missed every meeting could build from without asking you what you meant. That is the whole standard, and most best-practice lists are attempts to reach it by other means.

The properties that make the difference:

1. Every requirement can fail a test. If nobody can write a test that the implementation would fail, the requirement is a wish. Rewrite it or cut it.
2. The problem is separable from the solution. A reader can tell what you are trying to change and what you have chosen to build, and can disagree with the second without rejecting the first.
3. What is known is visibly separate from what is assumed. Confidence in a PRD should be graded, not uniform.
4. Decisions carry their reasons. One line on why you chose this option is worth more than a page describing the option. It is also what stops the same debate reopening in three weeks.
5. It is short enough to be read in one sitting. Not short for its own sake. Short because a document nobody finishes is not a document, whatever the wiki says.
6. It has a date and a status. Draft, in review, agreed. More rework comes from people building against a superseded version than from anything written badly in the current one.

Two things do not make a PRD good, despite appearing in most templates: exhaustive completeness, and a full set of headings. A PRD that answers nine questions well beats one that answers twenty-five with a placeholder.

When should a PRD be created?

Write the PRD after discovery has produced a problem worth solving and before design or engineering commit to a solution. Earlier and you are documenting a hunch. Later and the document becomes a write-up of decisions already taken, which is expensive theatre.

The practical trigger is a combination of three conditions:

• Someone can state the problem and point at evidence for it.
• The work is large enough that more than one person’s judgement is needed to build it correctly.
• The decisions still available are worth arguing about, meaning nothing significant has been committed yet.

If the third condition has already gone, you do not need a PRD. You need a decision record and an honest conversation about who agreed what.

Not every change earns one. A copy fix, a config change, a bug with an obvious cause: a well-written ticket is the right document. The threshold most teams settle on is roughly two weeks of work or two teams involved, though that varies with how much your codebase punishes a wrong guess. The related question of who should be writing it, and whether the format still fits an agile team, is covered separately.

What are common PRD mistakes to avoid?

The common PRD mistakes are almost all failures of process rather than writing. Here are the ones that reliably cause rework, in rough order of expense.

1. Writing it alone and circulating it for comment. The comments come back polite and shallow. The real objections arrive in sprint planning, and by then the document has an author who is defending it rather than a team who owns it.
2. Requirements that describe an interface instead of a behaviour. “A dropdown listing active projects” locks in a solution before anyone has considered whether a dropdown works at four hundred projects. Say what the user needs to accomplish and let design solve it.
3. No non-goals. Without them, every plausible adjacent request is arguably in scope, and the person best at arguing wins.
4. Assumptions written as statements of fact. This is the one that costs the most, because it is invisible until the assumption fails. See the section above for the format that prevents it.
5. Acceptance criteria that restate the requirements. If your criteria are the requirements with “the user can” in front, sign-off will be a negotiation rather than a check.
6. Skipping edge cases and calling them implementation detail. Error states are product decisions. Someone will decide what happens when the upload fails, and if it is not in the PRD it will be decided by whoever is closest to the deadline.
7. Letting it go stale mid-build. A PRD that stopped being updated in week two is worse than no PRD, because people still trust it. Either maintain it or mark it superseded and say where the current truth lives.

The first mistake causes several of the others. Edge cases get missed because the person who knows them was not asked. Assumptions harden into facts because nobody in the room had the evidence to challenge them. Getting engineering into the questioning stage, before a draft exists to react to, changes the outcome more than any template will. That ordering is what Projan is built around: it puts the scope and edge-case questions to the team in Slack or Microsoft Teams first, then writes up what was agreed and sends the resulting tasks to Jira or Linear.

For a first-hand account of what this looks like on a small team rather than in the abstract, our founder’s write-up on PRDs covers the same ground from inside a specific project.

Frequently asked questions

What should a good PRD have? At minimum: the problem with evidence, the non-goals, the requirements as testable statements, the assumptions, and the acceptance criteria. For a small change you can compress that into a page. The test is not which sections are present but whether an engineer who missed every meeting could build the right thing from it.

What are some PRD best practices? Write it with the people who will build it, keep every requirement testable, and separate what you know from what you are assuming. After that the habits matter more than the writing: review it in a scheduled session rather than by comment thread, date every material change, and delete sections that no longer describe the plan.

Should a PRD include wireframes and designs? Link them, do not embed them. Designs change faster than requirements, and a PRD carrying screenshots goes stale the week after design review. Keep the document describing behaviour and outcomes, point to the current design file, and note explicitly where a design decision is still open so nobody reads a draft as settled.

What happens to the PRD after the feature ships? Most teams archive it, which is reasonable if the tickets and acceptance criteria carry the detail forward. Before you do, spend twenty minutes marking which assumptions turned out to be wrong. That record is worth more than the document itself, because the same wrong assumption tends to reappear in the next PRD.

How do you handle a requirement nobody can decide on? Write it down as an open question with a named owner and a date by which a decision is needed, then say what the team will do if no decision arrives. An undecided requirement left in the requirements list reads as agreed. Moved to an open questions section with a deadline, it stays visible and gets chased.

A PRD is not a contract with engineering. It is the record of a conversation, and it is worth roughly what that conversation was worth. Write it with the people who will build the thing, keep the assumptions visible, and update it or retire it the moment it stops being true.