A Complete Product Requirements Document (PRD) Example

TL;DR

• Go through one full PRD, start to finish, instead of piecing one together from scattered examples
• Get a structure you can steal for your next feature, laid out section by section
• See what a finished PRD looks like inside a real tool (Docmost)
• Read this alongside our guide on how to write a PRD, and you'll have the reasoning and a finished result to copy

You've read the guide. You know a PRD needs a problem statement, a scope section, user stories with acceptance criteria, success metrics, and open questions. You know it should fit in three pages. And you're still staring at a blank page, because knowing the five parts isn't the same as knowing how they connect.

One feature is taken through every section of a complete PRD, from the problem statement to the open questions at the end. For the reasoning behind each choice, our guide on how to write a product requirements document covers that in detail. This post is what you get when you follow it.

The feature we'll use is one you've probably seen in some form already: an email that lets a project manager know when a task they handed off gets finished.

Quick Look At A Full PRD

That's three pages total, plus a short header at the top. Let's fill in the parts.

The PRD header

The header is above everything else and only takes a few lines. It tells anyone who opens the page who owns the document, and it points to the mockups so nobody has to look for them. It also shows the status, updated as the PRD moves from draft to review to approved.

For our example feature, the header looks like this:

• Feature: Task-completion email notifications
• Owner: Product manager, notifications team
• Reviewers: Engineering lead, designer, support lead
• Status: In review
• Mockups: Link to the current version

The problem statement

For our example feature, the problem statement reads like this:

"Project managers have no way to know when a task they've assigned to someone else gets marked complete unless they open the app and check. Right now, PMs check task status throughout the day out of habit, which usually means a lot of app switching for information that could just show up in an inbox. Two PMs on the beta team have said outright that they'd rather get an email than keep refreshing a board."

What this doesn't do

It doesn't say "we should build email notifications."

• It describes the problem: checking status by hand
• It describes why that's a problem: PMs lose time to a check that usually turns up nothing, and some have already asked for something better
• It says who's affected: project managers who hand off tasks and need to know when they're done

The solution comes later. But here, we're just describing the problem.

Scope and non-scope

In scope:

• An email to the project manager when a task they assigned is marked complete
• The email includes the task name, who completed it, and a link straight to the task
• Users can turn this notification off in their settings

Out of scope:

• Notifications for anything besides task completion. Comments, mentions, and due-date changes are separate features
• Push notifications or SMS (this is email only for now)
• A digest or summary option (each completion gets its own email)
• Notification preferences beyond a single on/off switch. No per-project settings, no quiet hours, no frequency controls

Every line in the out-of-scope section settles a conversation that would otherwise happen mid-build. Questions like: "Should we also notify on comments?" "What about a digest instead?" "Can people mute this per project?" Answering those now, in writing, means nobody has to raise them again.

User Stories And Acceptance Criteria

User story 1: As a project manager, I want to receive an email when a team member completes a task I assigned to them, so I can update my status reports without opening the app every hour.

Acceptance criteria:

• Email is sent within 60 seconds of task completion
• Email includes the task name, who completed it, and a link straight to the task
• Email isn't sent if the project manager already has the app open and active
• Email follows the existing notification email template
• Users can turn this notification off in their settings

User story 2: As a project manager, I want the completion email to name who did the work, so I know who to follow up with if something's wrong.

Acceptance criteria:

• The completer's name appears in the email subject line and body
• If the task was reassigned before completion, the email shows who completed it, not who it was originally assigned to

User story 3: As a project manager, I want to turn off these emails without turning off every other notification, so a feature I don't use doesn't fill my inbox.

Acceptance criteria:

• The setting for this notification is separate from comment and mention notifications
• Turning it off takes effect right away, starting with the next task completion
• The default is on for everyone, and switching it off doesn't require contacting support

User story 4: As an engineer on the notifications team, I want a single, clear trigger condition for this email, so I don't have to guess what counts as task completion for every task.

Acceptance criteria:

• The email only sends when a task's status changes to 'Done'
• Recurring tasks send an email every time they're completed, not just once for the whole series
• Completing a subtask doesn't send the parent task's completion email. Only completing the parent task does

User story 5: As a project manager, I want the link in the email to take me straight to the finished task, so I can check the work without searching for it.

Acceptance criteria:

• The link opens the task itself, not the project board or the home screen
• If the project manager is signed out, they land on the task after signing in, not on the home screen
• If the task has been deleted since the email went out, the link shows a plain "this task no longer exists" message instead of an error page

Every one of those is something you can build and test. When you compare that to a user story like "As a user, I want good notifications," you can see it tells an engineer nothing and a QA person even less.

Success Metrics

• Weekly active use of the task board doesn't drop in the 30 days after launch. A notification feature shouldn't teach people to stop opening the app, but it should give them a reason to open it when needed
• At least 40% of eligible users receive at least one completion email in the first week. Hitting that number shows the trigger is working for real people completing real tasks, not only the test accounts used before launch
• Fewer than 5% of users turn the notification off in the first 30 days. A high opt-out rate this early would mean the emails are annoying more people than they're helping
• If opt-outs pass 15% in the first 30 days, new users stop getting the notification by default, and the team reviews what's triggering it before turning it back on

That last one is important because it names what failure means directly, and states what should happen next if it occurs.

Open Questions

• If a "do not disturb" setting gets added later, should this email respect it? Push notifications might need to follow quiet hours, but email may not work the same way. Owner: product manager
• What happens if a task gets marked complete and then reopened a few minutes later? Right now, nothing cancels the email that already went out. Owner: engineering lead
• Would project managers who assign work to more than 20 people prefer one daily summary instead of a separate email for every task? We're launching without a summary option, but that could change based on feedback. Owner: product manager, after the first month of feedback

None of these have answers yet, and that's the point of the section. Writing them down means the team knows what's still open, instead of quietly assuming an answer and finding out later that someone assumed differently. Putting an owner next to each one means somebody is responsible for closing it.

Seeing It As One Document

This is the whole thing put together as one document in Docmost, nested under whichever parent page matches how the team already organizes things, such as a "Notifications" page or a quarterly planning page:

Notifications

• PRD: Task-completion email notifications
  • The problem statement
  • Scope and non-scope
  • User stories and acceptance criteria
  • Success metrics
  • Open questions

The sections run top to bottom in that order, and Docmost lists every heading in a table of contents alongside the page, so a reader can see what the whole document contains before reading it.

In this example, most of the comments land on the user stories. Story 4 gets one from an engineer:

Subtasks need their own rule here, or completing a subtask could trigger this notification too.

Ideally, a conversation before writing the PRD would have caught this edge case. Since that conversation didn't happen, the comment on Story 4 catches it instead. The subtask rule in Story 4 exists because of that comment. Once the rule was added, the comment was marked resolved and disappeared from the open list.

Say the 40% target turns out to be too high after the first week of real data. The team updates it directly in the document. Docmost automatically saves versions of the page as people edit, so opening page history and picking an earlier version shows exactly what changed:

• Before: "At least 40% of eligible users receive at least one completion email in the first week"
• After: "At least 25% of eligible users receive at least one completion email in the first week"

So nobody has to ask "didn't this used to say something else?" in a meeting three weeks later.

Where A PRD Like This Should Live

A PRD like this only stays useful if it's easy to find and easy to keep current. A doc buried deep in a shared drive, or a link that only half the team has bookmarked, turns into exactly the kind of record nobody trusts. And what someone was meant to build is now disconnected from what got built.

If you're deciding where PRDs and other product documents should live, our comparison of documentation tools for product teams walks through seven options and what each one is good at.

Frequently Asked Questions

1. How long should a PRD be? 

Long enough to cover the five sections above, and short enough that someone can read the whole thing in one sitting. Our rule of thumb is about three pages. If yours runs longer, look for a section that's trying to do too much, or a feature that should be split in two.

2. What should a PRD contain? 

A problem statement and a scope section, at minimum, since those are what keep a feature from growing out of control mid-build. Most feature-level PRDs also need user stories with acceptance criteria and success metrics on top of those two. Very small changes or early-stage exploration might skip the last two if there's nothing concrete yet to test.

3. What's the difference between a PRD and a technical spec? 

A PRD defines what to build and why, from the user and business side. A technical spec defines how to build it: architecture, data models, implementation details. The PRD's user stories and acceptance criteria are usually the spec's starting point, not a substitute for it.

4. Should a PRD include mockups or wireframes? 

A link to them, yes, and the header is a good place for it. The mockups themselves usually live in a design tool, but the PRD should point to the current version so anyone reading it can see what's being built without hunting for a separate file.

5. Who should review a PRD before it's finalized? 

At minimum, an engineer who'll work on the feature, since they'll catch technical issues in the acceptance criteria before sign-off instead of after. Beyond that, whoever the feature affects: design for a UI change, support for anything customer-facing, legal or compliance if you work in a regulated industry, and a stakeholder if scope needs a final call.

6. How do you handle a PRD once requirements change mid-build? 

Update the document itself instead of starting a side conversation about the change. Note what changed and when, either in a changelog at the bottom or through your documentation tool's version history, and let everyone working from the PRD see the current version instead of finding out about it secondhand.

Give your PRDs this structure

Give your PRDs a space that keeps every comment and every version attached, instead of a folder that only holds the file. Talk to our team about setting up a space in Docmost for the product documents your team writes and needs to trust.