PRD Example: A Sample PRD and Its Critique

The fastest way to learn what a good PRD looks like is to read one, then read what's wrong with it.

So here's a complete example PRD for a feature most teams have built, followed by the exact gaps a review flags in it. The sample is good enough to pass a casual read. That's the point. A flawless example teaches you nothing about review, because the whole skill is catching the problems that survive a read-through. This one has five planted in plain sight. See how many you catch before you reach the critique.

The example PRD

What follows is a one-page PRD for an @mentions feature in a collaboration tool. It's the kind of draft that gets nods in a review meeting and ships with three gaps still in it.

---

PRD: @mentions in comments · Author: PM · Status: in review · (illustrative example)

Problem. People collaborating in a shared document can't pull a specific teammate into a comment thread. They fall back to Slack messages like "see my comment on the doc," which get lost, so feedback stalls and decisions wait.

Goal. Increase collaboration and engagement in document comments.

Target user. Any user working in a shared document with at least one collaborator.

Requirements.

• Typing @ in a comment opens a picker of people in the workspace.
• Selecting a person inserts a mention and sends them a notification.
• Notifications should be timely and reliable.
• A mentioned user can click the notification to jump straight to the comment.

Scope. Mention individual people inside document comments.

Rollout. Release to all users at launch. Track comment volume week over week.

---

Read fine? It mostly does. Now here's what a review does to it.

What an 11-pass critique flags here

A review reads for what's missing, not what's wrong with the sentences. Run this draft against the checks in the PRD review checklist and five findings come back, sorted by severity.

Blocker · Goal. "Increase collaboration and engagement" can't fail. There's no baseline, no target, no date, so there's no version of launch where you'd admit it didn't work. Rewrite it as a claim you could be wrong about: lift the share of comment threads that get a reply within 24 hours from 40% to 60% within one quarter. Now it has a scoreboard.

Major · Requirements (missing edge case). The picker shows "people in the workspace." It says nothing about whether you can mention someone who can't access this specific document. That's not a detail, it's a security decision: do you silently drop the mention, notify a person who then hits a permission wall, or block the mention in the picker? Unspecified means an engineer picks one under deadline pressure, and one of those choices leaks who's working on what.

Major · Requirements (untestable). "Notifications should be timely and reliable" is a hope, not a requirement. QA can't test "timely." Give it a number: the mentioned user receives an in-app notification within 10 seconds and an email within 2 minutes, with delivery retried on failure. The form to write these in is in testable acceptance criteria.

Minor · Scope. There's an in-scope line and no out-of-scope line. Can you mention a group or a whole team? Mention someone in a different workspace? The draft doesn't say, so every "could we also…" in standup becomes a yes. Name the boundary: out of scope for v1: team/group mentions, cross-workspace mentions.

Minor · Target user. "Any user with a collaborator" is everyone, which means no one. No requirement below changes based on who this user is. Either the persona is doing no work and should be cut, or there's a real primary user (the reviewer waiting on feedback?) whose job-to-be-done should shape the notification design.

Five findings. None of them is a typo, and none of them would surface in a "looks good to me" read. The blocker alone would let the feature ship with no way to tell if it worked. That gap between "reads fine" and "survives review" is the entire reason the review step exists, and the argument for why review is a different skill than writing is in what makes a good PRD.

What the fixed version looks like

Apply the five and the same PRD changes shape. The goal becomes a falsifiable metric. The requirements section grows a permission rule and a delivery SLA. The scope section gains an explicit "out" list. The persona narrows to the user whose problem actually drove the feature. None of that makes the document longer in any way that matters. It makes it decidable: an engineer can estimate it and a stakeholder can approve it without booking a call.

That's the move every time. A draft is a set of claims; a review is the pressure test that finds which claims are hollow. You can run that pass by hand with the checklist, or watch it run automatically: Thinkr's Critique does exactly this across eleven named passes, landing each finding as a comment on the line it concerns, classified blocker, major, or minor, with a suggested rewrite. The full teardown of one PRD shows it end to end on a real spec.

Use the example, then write your own

Reading a PRD with its critique attached is the cheapest way to train your eye for the gaps. Once you've seen the five failure modes here, you'll spot them in your own drafts.

When you're ready to write one, start from the PRD template, which has these review checks built into each section, and follow the step-by-step in how to write a PRD. If you're not sure what the document is for in the first place, that's what a PRD is. And if the blank page is the blocker, PRD generation drafts the structure from your product context so you have something to critique instead of nothing to start from.

Frequently asked questions

What does a good PRD example look like?

It frames the problem before the solution, sets a metric that can fail, writes requirements a tester could verify, names the edge cases, and says what's out of scope. The example above does some of that and misses the rest on purpose, which is what makes the critique worth reading.

What makes a PRD fail review?

The recurring five: a problem nobody validated, a success metric that can't come out false, a generic persona, requirements no one can test, and edge cases left blank. Each reads fine on the page, which is why they survive a casual read and only surface in a real review.

Where can I find real PRD examples?

Companies rarely publish their actual PRDs, so most public examples are illustrative, like this one. The value is less in the sample text and more in reading it against a rubric. A sample plus its critique teaches more than a polished template whose flaws you can't see.

How is a PRD example different from a PRD template?

A template is the empty structure, the sections waiting to be filled. An example is a filled-in PRD you can read end to end. Use the template to start your own; use an example to see what good, and not-yet-good, looks like in practice.

The point of reading one

A polished example makes you feel like you know what good looks like. An example with its critique attached actually teaches it, because it shows you the difference between a draft that reads well and one that holds up. Train on the gap. It's the whole job.