How to Write a PRD: A 3-Week Roadmap From Problem to Sign-Off
9 min read ยท 2026-10-11
How to write a PRD: start with the problem and the people who have it. Then define what success looks like, list the requirements as things a user can do, set clear scope limits, and review the draft with design and engineering before anyone signs off. This plan takes about three weeks if you follow the phases in order.
A product requirements document (PRD) explains what you are building, for whom, and why. It does not explain how to build it. That part belongs to your engineers and designers. The plan below splits the work into six short phases. Each one has a milestone you can check, so the PRD stops being a document you keep putting off and turns into a set of tasks with dates.
The roadmap at a glance
Goal: An approved PRD that design and engineering can estimate and build from without guessing. Duration: 3 weeks (15 working days)
Frame the Problem (Days 1-2)
Agree on the problem before anyone talks about features.
- Write a problem statement in two or three sentences: who has the problem, what happens today, and why it matters.
- List the target users and the situation they are in when the problem shows up.
- Write down the business goal this work supports, in plain words.
- Share the problem statement with your manager or one key stakeholder and ask, "Is this the right problem?"
Milestone: A one-paragraph problem statement that one stakeholder has read and approved.
Gather Evidence (Days 3-6)
Show that the problem is real and worth solving now.
- Collect support tickets, sales notes and feedback that mention the problem.
- Run three to five short user conversations focused on the current workaround.
- Check your product analytics for the behavior linked to the problem.
- Note what is still unknown, and write it down as an open question.
Milestone: An evidence section with sources, quotes and a short list of open questions.
Define Success (Days 7-8)
Decide how you will know the work succeeded after launch.
- Choose one primary success metric and one or two guardrail metrics that must not get worse.
- Write the current baseline for each metric, or note that you need to measure it first.
- Set a target and a date for checking the results.
Milestone: A success section with metrics, baselines and a review date.
Draft the Requirements (Days 9-12)
Describe what users must be able to do, not how the screens should look.
- Write user stories in the form "As a [user], I want to [action] so that [outcome]."
- Add acceptance criteria to each story so anyone can test whether it is done.
- Rank each requirement as must have, should have or could have.
- Add non-functional requirements: performance, security, accessibility and supported platforms.
- Write a short "out of scope" list.
Milestone: A complete first draft with ranked requirements and an out-of-scope list.
Review With the Team (Days 13-14)
Test the draft against the people who will build it.
- Hold a walkthrough with your design and engineering leads.
- Write down every question they ask that the document cannot answer.
- Ask engineering for a rough size estimate and the biggest risks.
- Cut or split requirements that are too large for the first release.
Milestone: A revised draft with no unanswered "what does this mean?" questions.
Sign Off and Hand Over (Day 15)
Lock the first version and move the work into planning.
- Send the final draft to stakeholders with a clear deadline for comments.
- Record who approved it and on which date.
- Link the PRD to its roadmap item and to the first backlog tickets.
- Add a change log at the top for later updates.
Milestone: A signed-off PRD linked to the roadmap and the backlog.
What a PRD Is, and What It Is Not
A PRD is a shared agreement on the problem, the users, the goals and the requirements for one product or feature. It answers four questions: Why are we doing this? Who is it for? What must it do? How will we know it worked? If a new engineer can read it and explain the project back to you, it does its job.
A PRD is not a technical specification, a design file or a project plan. Technical specs explain architecture and code choices. Design files show screens and flows. A project plan lists tasks, owners and dates. The PRD sits above all three and gives them a reason to exist. Keeping them separate helps you avoid a 30-page document that nobody reads, and it lets each team own its part.
The Sections Every PRD Needs
For a small feature, each section can be a few lines. For a new product, the evidence and requirements sections will be longer. Keep the structure the same anyway. Readers learn where to look, and reviews go faster.
PRD templates vary, but strong PRDs share the same core sections. Put them in this order so readers get the "why" before the "what":
- Overview: the title, owner, status, last update date and a two-sentence summary.
- Problem statement: who has the problem and what it costs them today.
- Evidence: user quotes, ticket themes and data points, each with its source.
- Goals and success metrics: the primary metric, guardrails, baselines and targets.
- Target users: the main persona or segment, plus who is explicitly not targeted.
- Requirements: user stories with acceptance criteria and priority.
- Non-functional requirements: speed, security, accessibility, platforms and legal limits.
- Out of scope: what this release will not do.
- Open questions and risks: what you still need to learn, with an owner for each item.
- Change log: what changed, when and why.
How to Write Requirements People Can Build From
The most common PRD problem is a vague requirement. "Users can easily export data" invites ten different ideas of what "easily" and "data" mean. Rewrite it as a user story with acceptance criteria: "As an account owner, I want to export my invoice list so that I can send it to my accountant." Then add the tests: the export is a CSV file, it includes date, client, amount and status, and it respects the filters currently applied.
Good acceptance criteria are specific, testable and free of solution details. Write "the user sees a confirmation once the export is ready," not "a green toast appears in the top right corner." The second version takes a design decision away from your designer. Use words like "must" and "can" instead of "should ideally" or "nice if possible." If a requirement is optional, say so through its priority level, not through soft wording.
How a PRD Connects to Your Roadmap
Your roadmap shows what the team will work on and in what order. The PRD explains one item on that roadmap in detail. Think of the roadmap as the map and the PRD as the close-up of one stop. Each roadmap item that needs real design and engineering work should link to its PRD, and each PRD should name the roadmap item and the goal it serves.
This link works in both directions. When priorities change on the roadmap, the PRD's status should change too, for example from "in review" to "paused." When the PRD review shows that a feature is much bigger than expected, update the roadmap so the timeline stays honest. Keeping the two in sync avoids the classic surprise where the roadmap promises a date that the PRD scope could never meet.
How to Adapt the Process to Your Team
A startup with three people does not need the same PRD as a company with several product teams. Small teams can merge phases: frame the problem and gather evidence in the same week, then write a one-page PRD with the problem, the metric, five to ten user stories and an out-of-scope list. The important part is that the "why" and the limits are written down, even if the document is short.
Whatever the team size, write the PRD where your team already works, whether that is Google Docs, Notion, Confluence or a shared folder. A document people can find and comment on beats a perfect template no one opens.
Larger teams usually need more review time and clearer ownership. Here is what to add when more people are involved:
- An approvers list at the top, so everyone knows whose sign-off counts.
- A separate section for dependencies on other teams, with a contact for each.
- Fixed review slots in the calendar, so feedback does not drag on for weeks.
- A rule for changes after sign-off, such as "any change to must-have scope goes back to review."
Common mistakes to avoid
- Starting with the solution. The team argues about features before it agrees on the problem. Write and approve the problem statement before any feature list.
- Writing vague requirements. Words like "fast" or "simple" mean something different to each reader. Replace them with acceptance criteria that anyone can test.
- Skipping the out-of-scope list. Without it, new requests keep sliding into the release. Add a short list of what this version will not do.
- Designing the screens inside the PRD. Layout details take decisions away from your designer. Describe the user outcome and leave the screens to design.
- Treating sign-off as the end. The document goes stale as soon as the team learns something new. Keep a change log and update the PRD when facts change.
- Choosing success metrics after launch. You end up with no baseline to compare against. Set the metric, the baseline and the review date before development begins.
Frequently asked questions
How long should a PRD be?
As short as it can be while still answering why, who, what and how you will measure success. A small feature often fits on one or two pages. A new product needs more detail in the evidence and requirements sections. If people stop reading halfway, move the details into linked documents.
Who writes the PRD?
The product manager usually owns it and writes the first draft. Design and engineering leads review it and add constraints, risks and estimates. In a startup without a product manager, the founder or the person closest to the users often writes it.
What is the difference between a PRD and an MRD?
A market requirements document (MRD) describes the market opportunity: the customer segment, the need and the business case. A PRD turns that opportunity into specific product requirements a team can build. Many teams now fold a short market summary into the PRD's problem and evidence sections instead of writing two documents.
Do agile teams still need a PRD?
Yes, though often in a lighter form. Agile teams still need a shared view of the problem, the goal and the scope limits before they break work into sprints. A short, living PRD gives the backlog context and stops user stories from drifting away from the original goal.