Most product requirements documents fail in the second paragraph. Not because the writing is bad, but because the problem section says something like "customers find the current export flow confusing" and then moves on. Nobody can argue with that sentence, which is exactly the trouble. It carries no weight in a prioritization meeting, it cannot settle a scope disagreement six weeks later, and it gives engineering nothing to push back on.
A PRD template does not fix your judgment. What it does is force each section to answer a question you would otherwise skip, and the first of those questions is the one above: how do you know. This guide gives you the seven sections, a worked example built from real support tickets, the mistakes that get a PRD ignored, and a copy-paste template at the bottom.
In this article
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
What Is a PRD, and What Is It Not
A product requirements document is the written record of what you are about to build and why. It exists so that the product owner, the engineers, the designer, and the support team who will field the questions afterward are all solving the same problem.
Three things it is not, because each confusion produces a different bad document:
It is not a technical spec
A PRD describes required behavior. A technical design doc describes how that behavior gets built, and it is written by an engineer after the PRD, not instead of it. The moment a PRD starts naming database columns or API shapes, it has stopped being reviewable by the people who need to review it.
It is not a project plan
No dates, no assignees, no estimates. Those live in the tracker and they change weekly, which means a PRD that contains them is stale within a sprint and nobody trusts the rest of it either. Keep the document about the what and the why, and let the ticket carry the when.
It is not a permanent artifact
A PRD is accurate on the day it is written and it decays from there. Update it when scope changes and archive it when the feature ships. Teams that treat it as a contract to be defended end up building the wrong thing carefully, which is worse than building nothing.
What Goes in a Product Requirements Document
Seven sections, in this order. The order does real work. Evidence sits directly under the problem so a reader cannot accept the premise without seeing what it rests on, and non-goals sit next to goals rather than at the bottom where nobody reads them.
- 1
1. Header: title, owner, status, date
One line each. The status field matters more than it looks: draft, in review, approved, shipped, or archived. Half the confusion around requirements documents comes from someone reading a draft as though it were approved, and a single word at the top prevents it.
- 2
2. Summary
One paragraph, four sentences at most, naming the problem and the shape of the solution. Write it last and put it first. If you cannot compress the feature into a paragraph, the scope is still too wide and the rest of the document will inherit that.
- 3
3. The problem, with evidence
What is broken today, for whom, and how you know. The second half of that sentence is the section. Link the tickets, quote the customers in their own words, give the count of accounts affected and the revenue behind them. This is the part of a PRD that has to survive contact with a prioritization meeting, and assertions do not survive.
- 4
4. Users and the job
Who has this problem and what they were trying to accomplish when they hit it. Name a real segment rather than a persona archetype, because "Marketing Mary" is a decoration and "accounts on the Starter plan importing more than five hundred rows" is a filter you can query. The job framing matters because it exposes solutions you did not consider.
- 5
5. Goals, non-goals, and success metrics
Two or three goals stated as outcomes rather than outputs. Then non-goals, which are the highest-value lines in the whole document. Then how you will measure it, with the current number and the target, because a metric without a baseline cannot be evaluated afterward and everyone quietly knows it.
- 6
6. Requirements
What the product must do, as observable behavior. Number them so they can be referenced in review. Mark each one as must or should, and be honest about it, because a list where everything is a must is a list that has not been prioritized. Include the edge cases and the failure states, since those are where the actual work hides.
- 7
7. Open questions and rollout
Every unresolved decision, each with a name against it, plus how this reaches users: all at once, behind a flag, to a subset first. Writing down what you do not know yet is not a weakness in the document. It is the section that stops those questions from being silently answered by whoever hits them first at 4pm on a Thursday.
How to Write a PRD From Support Tickets and Customer Feedback
The hardest part of a PRD is not the writing. It is section three, and specifically the evidence.
Every feature idea has an origin story, and for product-led software the honest version of it is usually a pile of support conversations. Someone in support answered the same question eleven times, mentioned it, and it became a roadmap item. But by the time the PRD gets written, those eleven conversations are closed tickets with subject lines somebody normalized, in a help desk nobody on the product team searches. So the evidence section gets written from memory, which is how a PRD ends up asserting that customers find the export flow confusing.
Doing it properly is mechanical if the link survived:
Start from the tickets, not the idea
Search the help desk for the complaint before you write the problem statement, not after. The exercise is not to confirm what you believe. It is to find out how many accounts actually raised it, over what period, and whether they were describing one problem or three that share a symptom.
Quote the customer, do not paraphrase
Two or three verbatim lines from real tickets are worth more than a page of your summary of them. Paraphrasing sands off the specifics, and the specifics are what a designer or engineer notices something in. Keep the customer's vocabulary, including the parts where they use the wrong name for a feature, because that is a finding too.
Count accounts, not tickets
One frustrated customer filing nine tickets is a very different case from nine customers filing one each, and a raw ticket count hides which one you have. Attach the plan tier and the revenue while you are there, since the prioritization conversation will ask for it within the first two minutes.
Note who is still waiting
Any of those tickets that are still open belong to people who will want to hear when this ships. Capturing that list at PRD time costs nothing and saves a search later, which is the same discipline that makes writing release notes a thirty-minute job instead of a morning.
A problem statement with three linked customer tickets under it survives a scope argument. One that begins "users have told us" does not.
PRD Example: Bulk Ticket Actions
Abstract advice about structure is easy to nod at, so here is the shape filled in. This is compressed, but the proportions are right: the problem and evidence take more room than the requirements do.
Header. Bulk ticket actions. Owner: M. McGarvey. Status: in review. Updated: July 29, 2026.
Summary. Support agents handling a spike cannot act on more than one ticket at a time, so triage after an incident takes hours of repetitive clicking. We will add multi-select to the ticket list with status, owner, and priority changes applied to the selection.
Problem, with evidence. After any incident that produces more than about thirty tickets, agents spend the following morning opening each one to set the same status and owner. Twenty-two accounts raised this in the last quarter across thirty-one tickets, fourteen of them on plans above the entry tier. One customer wrote: "we had 60 tickets from the outage and I had to click into every single one to close it, it took me until lunch." Two of those tickets are still open. The workaround agents found is worse than the problem, which is that they stopped triaging small incidents at all.
Users and the job. Support agents at accounts with more than two seats, most acutely after an incident. The job is to get a queue back to a known state quickly, not to process tickets individually. Solo agents on the entry tier report this rarely, because their queues do not spike.
Goals. Reduce post-incident triage from hours to minutes. Keep the individual ticket flow unchanged for the common single-ticket case.
Non-goals. No bulk delete, since an irreversible action across a selection is a different risk conversation. No bulk reply, because the reply quality problem is real and this is not the place to solve it. No saved selections or rules, which is automation and belongs in its own document.
Success metrics. Median time from incident close to queue cleared, currently 94 minutes, target under 15. Percentage of accounts with more than two seats using multi-select at least once in a month, currently zero, target 40 within a quarter.
Requirements. (1) Must: a checkbox column on the ticket list, with select-all applying to the current filter and not the whole table. (2) Must: status, owner, and priority can be applied to a selection of up to 200. (3) Must: partial failure reports which tickets did not update and why, rather than a generic error. (4) Should: the selection survives pagination within a session. (5) Should: a single undo for the last bulk action, within five minutes.
Open questions and rollout. Does the 200 limit need to be configurable, and who decides (open, assigned to engineering). Does a bulk status change fire the same automation as a single change, which is a real behavioral fork with no obviously right answer (open, assigned to product). Rollout behind a flag to five accounts that reported the problem, then general.
Notice what the requirements section does not contain. No mention of how the selection is stored, no endpoint design, no component names. Those are real decisions and they belong to engineering, in a document written after this one is agreed.
PRD vs BRD vs Technical Spec
Three documents that get conflated, three different readers. Most small teams need exactly one of them.
BRD: why the business should fund this
Framed in revenue, cost, risk, or compliance. Its reader is an executive deciding where money goes. Under a few hundred people, this is usually one paragraph inside the PRD's problem section rather than a separate document, and keeping it separate mostly guarantees the two disagree within a quarter.
PRD: what the product must do
Framed in user problems and required behavior. Its readers are engineering, design, and support. This is the document the template on this page is for, and for most software teams it is the only one that earns its maintenance.
Technical design doc: how it gets built
Framed in architecture, data model, and tradeoffs. Written by an engineer, reviewed by engineers, and produced after the PRD is agreed rather than alongside it. When a team says their PRD is too long, this is usually what leaked into it.
The PRD Checklist
Run this before sending it for review. It takes about three minutes and it catches the failures that are awkward to fix once people have read the document.
Before you circulate the draft
- The problem section links real evidence, not a recollection of it.
- You know how many accounts asked for this, over what period, on which plans.
- At least one verbatim customer quote appears, in their own words.
- Non-goals are written down, and at least one of them was tempting.
- Every success metric has a current baseline number next to its target.
- Requirements describe observable behavior, with no implementation detail.
- Not everything is marked must.
- Every open question has a name against it.
- Someone in support has read the problem section and recognized the complaints behind it.
The last two are the ones that fail, and the very last one fails for a structural reason rather than a discipline one.
Where the Evidence Section Comes From
Writing a PRD is a two-hour job. Assembling the evidence for it is not, and the difference between the two is almost entirely whether the trail from customer complaint to engineering work was recorded when it happened.
The idea in the roadmap started as a support conversation. It was reframed into an issue with a cleaner title, worked on by someone who never read the original message, and prioritized on a summary of a summary. Months later you sit down to write the problem section and have to walk backward through two tools that do not know about each other, matching a ticket subject line to an issue title by memory. Most people give up somewhere in the middle and write "customers have told us", which is how a well-structured document ends up resting on nothing.
A PRD that takes two hours
- The issue carries the tickets that produced it
- The customer's original wording is one click away
- Account count and plan tier are already attached
- You can see who is still waiting on it
- Support recognizes the problem statement immediately
A PRD that takes two days
- The issue references a Slack thread that scrolled away
- The original wording is in a closed ticket nobody searches
- Counts get estimated from memory
- Nobody knows who asked
- Support reads the PRD and says that is not quite the problem
That table is not really about requirements documents. It is about whether the handoff from support to engineering left a durable link behind it, and the PRD is just one of several moments you find out that it did not. The same gap shows up when someone tries to write a root cause analysis and cannot reconstruct who was affected, and it is the same reason closing the customer feedback loop is the step that quietly gets skipped.
For teams where support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker is what keeps that link intact. A ticket becomes a linked Linear issue in one click with the customer's own wording carried over, and the two stay in sync both ways, so when the idea comes back around as a PRD the evidence is already attached to it. The Linear HubSpot integration guide covers how the two-way sync works, and managing feature requests from support to engineering covers how demand gets aggregated before it ever reaches a requirements document.
Write the problem section from real tickets
If support runs on HubSpot Service Hub and engineering runs on Linear, IssueLinker links the customer ticket to the engineering issue and syncs both ways, so the evidence behind a feature is still there when you sit down to write the PRD.
Mistakes That Get a PRD Ignored
Four patterns account for most requirements documents that get written, circulated, and never referenced again.
Solutioning in the problem section
"Users need a bulk edit feature" is not a problem, it is a solution wearing a problem's clothes. The actual problem was that post-incident triage takes a morning, and stating it that way leaves room for engineering to point out a cheaper answer. Writing the solution into the problem is how teams build the second-best idea confidently.
Metrics with no baseline
"Improve activation" is unfalsifiable, and everyone in the room knows it while nodding along. A metric needs the current number, the target, and the date you will check. If you cannot find the current number, that is the finding, and getting instrumented is the real first requirement. Our guide to customer service metrics covers which numbers are worth baselining on the support side.
Requirements that are all must
A list where every line is required has not been prioritized, it has been transcribed. Engineering reads it, correctly concludes the ranking will happen later under time pressure, and mentally discounts the whole document. Marking three things as should is a small act that makes the musts credible.
Written once and never touched
Scope changes during a build. If the PRD does not change with it, the document and the software diverge, and the next person to read it is misled rather than informed. A stale requirements document is worse than none, because it carries the authority of something that was reviewed.
The thread running through all four is that a PRD is a decision-making tool and gets judged as one. The measure is not whether the document is thorough. It is whether someone reading it in week six can settle an argument with it.
Copy-Paste PRD Template
Here is the template in plain text. Paste it into a doc, a Notion page, the description of the epic, or wherever your team keeps this. Delete a section when it genuinely does not apply rather than writing "N/A", except for non-goals, which you should always fill in.
PRD: [ feature name ]
Owner: [ name ]
Status: [ draft | in review | approved | shipped | archived ]
Updated: [ date ]
Tracker: [ link to the epic or issue ]
SUMMARY
[ Four sentences at most. The problem, and the shape of the solution.
Write this last. ]
PROBLEM
[ What is broken today, and for whom. ]
Evidence:
- [ N accounts raised this over [period], across N tickets ]
- [ Plans / revenue affected ]
- [ Verbatim quote from a customer, in their words ]
- [ Verbatim quote from a customer, in their words ]
- [ Link to the tickets or the linked issues ]
- [ Still open and waiting on this: ... ]
USERS AND THE JOB
Who: [ a real, queryable segment, not a persona archetype ]
The job: [ what they were trying to accomplish when they hit this ]
Not affected: [ who does not have this problem, and why ]
GOALS
1. [ An outcome, not an output ]
2. [ ... ]
NON-GOALS
1. [ Something tempting that we are deliberately not doing, and why ]
2. [ ... ]
SUCCESS METRICS
- [ Metric ] : currently [ baseline ], target [ number ] by [ date ]
- [ ... ]
REQUIREMENTS
1. [MUST] [ Observable behavior. No implementation detail. ]
2. [MUST] [ ... ]
3. [SHOULD] [ ... ]
4. [SHOULD] [ ... ]
Edge cases and failure states:
- [ What happens when it goes wrong, partially succeeds, or hits a limit ]
OPEN QUESTIONS
- [ Question ] (owner: [ name ], needed by: [ when ])
- [ ... ]
DEPENDENCIES
- [ Anything outside this team that has to land first ]
ROLLOUT
- [ All at once | behind a flag | to a subset first, and which subset ]
- [ Who gets told when it ships, including the customers above ]
The last line of the rollout section is the one that gets cut when the release is late, and it is the one that turns a shipped feature into goodwill. The people quoted in your evidence section asked for this, sometimes months ago, and they are the cheapest and most receptive audience the feature will ever have. A PRD that starts with their words and ends without a reply to them has left the most valuable part of the work on the floor.
