This is a complete PRD example: a product requirements document for a small MVP, written out in full. It has an objective, a target user, a do-not-build list, six prioritized features, acceptance criteria, a build order, and the open questions.
Most of what comes up when you search for a PRD example is a blank template: a heading that says Objective, an empty bullet list, and a note telling you to describe your objective. A template tells you which sections exist. It doesn't show how precise an objective has to be before an engineer can act on it, and that is the part people get stuck on.
The product is Chairfill, a waitlist tool that helps dental clinics fill last-minute cancellations. It doesn't exist. I wrote the PRD the way I'd write it for a real build, and the notes after it explain why each section is worded the way it is. Further down there are two shorter PRD examples, one for a consumer mobile app and one for an internal tool.
The example at a glance
| Section | What Chairfill's PRD says |
|---|---|
| Objective | Refill at least half of a clinic's short-notice cancellations without anyone picking up the phone. |
| Target user (ICP) | Single-location US dental practices with two to five chairs and one front-desk employee. |
| Do not build | A scheduling system, a patient app, payments, and multi-location roles, each with its reason. |
| Features | Four P0 features that block launch, one P1, and one P2. Every P0 and P1 feature has acceptance criteria written as checkboxes. |
| Build order | Four phases. The riskiest integration is attempted in week one. |
| Open questions | Two, including whether Open Dental exposes cancellations as events. |
The PRD
MVP Specs: Chairfill
How to read this spec
- Everything under Features gets built. Everything under Constraints does not, no matter how small it seems.
- A feature is done when every acceptance criterion under it passes, not when the code runs.
- If a requirement here is ambiguous, stop and ask rather than guessing.
- P0 features block launch. P1 and P2 do not.
- Build in the order given under Build order, not in the order features are listed.
- If something in this document turns out to be wrong, change this document first, then the code.
Objective
Dental clinics lose revenue every time a patient cancels within 24 hours, because the empty chair almost never gets refilled. Front-desk staff currently work down a paper list and phone patients one at a time, which takes long enough that they usually give up after three or four calls.
Chairfill fills that chair automatically. When an appointment is cancelled, patients who asked to be seen sooner get a text with the open slot, first to claim it takes it, and the clinic's calendar updates.
This works if a clinic that installs it refills at least half of its short-notice cancellations without anyone picking up the phone.
Product ICP
Single-location dental practices in the US with two to five chairs and one front-desk employee. They already run practice-management software (Dentrix, Eaglesoft, or Open Dental) and won't replace it. The person who feels the pain is the front-desk employee. The person who pays is the practice owner, who sees cancellations as lost revenue rather than as an admin problem.
Not for: multi-location dental service organizations, medical practices outside dentistry, or clinics that don't keep any kind of waitlist today.
Constraints: do not build
- A full scheduling system. The clinic keeps its existing practice-management software. Chairfill reads and writes appointment slots and owns nothing else.
- Why excluded: replacing scheduling is a multi-year product and the reason clinics will refuse to install this.
- A patient mobile app. Patients claim slots through a plain web link in a text message.
- Why excluded: nobody installs an app for their dentist. It would sink the claim rate.
- Payments. No deposits, no card capture, no billing.
- Why excluded: the clinic already collects payment at the visit. Adding money to the MVP adds compliance work and buys nothing.
- Multi-location support, roles, and permissions. One clinic, one login.
- Why excluded: the ICP has one front desk. Roles are the first thing to add if a DSO ever signs up, and the first thing to regret if we build them now.
Features
Must: MVP core
P0 · Waitlist capture
Front-desk staff can add a patient to the waitlist with name, phone number, and the treatment type they're waiting for.
- Why it's core: without a list of people who want an earlier slot, there is nobody to notify.
- Solves: the paper list that lives on one person's desk and disappears when they're off.
- Complexity: small
- Acceptance criteria:
- A patient can be added in under 15 seconds from the main screen.
- Phone numbers are validated as US mobile numbers on entry, with an inline error on failure.
- Duplicate phone numbers are flagged before saving, not after.
- The list survives a page refresh and is visible to any logged-in user at that clinic.
P0 · Cancellation trigger
When an appointment is cancelled in the clinic's practice-management software, Chairfill detects the open slot within five minutes.
- Why it's core: this is the event the whole product hangs on. Manual entry of cancellations was tested with two clinics and neither did it consistently.
- Solves: the delay between a cancellation and anyone noticing the chair is empty.
- Complexity: large
- Depends on: Waitlist capture
- Acceptance criteria:
- Detects a cancellation in Open Dental within five minutes of it happening.
- Captures slot start time, duration, and provider.
- Ignores cancellations more than 72 hours out, which the clinic can refill normally.
- Logs every detected slot so a missed fill can be traced afterwards.
P0 · Slot offer by SMS
Matching waitlist patients get a text with the open slot and a link to claim it. First to claim wins.
- Why it's core: the offer is the product. Everything else is plumbing around it.
- Solves: the front desk phoning patients one at a time until they give up.
- Complexity: medium
- Depends on: Cancellation trigger
- Acceptance criteria:
- Offers go only to patients whose treatment type matches the open slot.
- Up to five patients are texted at once, in waitlist order.
- The claim link expires when the slot is taken or 60 minutes pass, whichever comes first.
- A patient who claims a taken slot sees a clear "already filled" message rather than an error.
- Every patient is texted at most twice per week, regardless of how many slots open.
P0 · Claim confirmation
When a patient claims a slot, the appointment is written back to the clinic's software and both sides get a confirmation.
- Why it's core: a claim that doesn't reach the calendar creates a double-booking, which is worse than the empty chair.
- Solves: the manual re-entry step that would otherwise land back on the front desk.
- Complexity: medium
- Depends on: Slot offer by SMS
- Acceptance criteria:
- The appointment appears in the clinic's software within 60 seconds of the claim.
- The patient receives a confirmation text with date, time, and clinic address.
- If the write-back fails, the front desk gets an alert naming the patient and slot, and the patient is told the clinic will confirm shortly.
- The claimed patient is removed from the waitlist automatically.
Should: important, not blocking v1
P1 · Fill-rate dashboard
A single screen showing slots opened, slots filled, and revenue recovered this month.
- Why it's here: this is what the practice owner looks at when deciding whether to keep paying. It isn't needed to prove the product works, so it can land in week five.
- Complexity: small
- Depends on: Claim confirmation
- Acceptance criteria:
- Shows slots opened, slots filled, and fill rate for the current month.
- Revenue recovered uses a per-treatment value the clinic enters once.
- Loads in under two seconds with a year of data.
Could: nice to have
P2 · Waitlist self-signup
A link the clinic can text to patients so they add themselves to the waitlist.
- Why it's here: removes data entry from the front desk, but only matters once clinics have proven they'll use the waitlist at all.
- Complexity: small
- Depends on: Waitlist capture
Build order
Phase 1, no dependencies: Waitlist capture.
Phase 2: Cancellation trigger, which is the riskiest item in the document and should be attempted in week one even though it isn't first in the list.
Phase 3: Slot offer by SMS, then Claim confirmation.
Phase 4: Fill-rate dashboard, then Waitlist self-signup.
Open questions
- Does Open Dental's API expose cancellations as events, or does this need polling? Answer before starting Phase 2.
- What happens when two clinics share a patient phone number? Rare, but it breaks the "at most twice per week" rule.
Why the example is written that way
Each section above does a job that shows up later as either saved time or a rebuilt feature.
The objective ends with a number. "Refills at least half of its short-notice cancellations without anyone picking up the phone" is a sentence you can be wrong about. Compare it to "streamline appointment management for dental practices," which nobody can ever disprove and which gives an engineer no way to choose between two implementations.
The ICP is narrow enough to rule things out. "Single-location practices with two to five chairs and one front-desk employee" rules things out. It tells you the login model (one clinic, one account), the support expectations, and why roles and permissions are absent. A PRD that says "for dental professionals" would have left all three of those decisions to whoever writes the code, at 2am, without asking.
The out-of-scope section has reasons attached. Writing "don't build payments" invites someone to add payments in week three when it seems easy. Writing "don't build payments, because the clinic already collects at the visit and it adds compliance work" survives the argument. Every exclusion here is a decision someone would otherwise relitigate.
Acceptance criteria are written as tests. "Detects a cancellation within five minutes" can be verified. "Reliably detects cancellations" cannot. The rule I use: if you can't imagine the check that proves it, rewrite the criterion. Notice too that several criteria describe failure paths, like the write-back alert and the "already filled" message. Specs tend to skip failure paths, and whoever writes the code then decides alone what happens when the write-back fails.
The riskiest feature is called out in the build order. The list puts waitlist capture first because nothing depends on it, but the build order pulls the integration into week one. The point of sequencing is to find out early whether the thing that could kill the product actually works. If Open Dental turns out not to expose cancellations, everything else in the document is worthless, and you want to know that in week one rather than week six.
Open questions are in the document. Every project has them. Left out of the document, they get answered silently by whoever hits them first.
Two shorter PRD examples
Chairfill is B2B software with an integration at its center. Here are two more for other kinds of product. Each keeps the same sections, cut down to the objective, the user, the exclusions, one feature, and one open question, so you can see how the wording changes with the product.
PRD example for a consumer mobile app: Rota
Objective. People who share an apartment argue about chores because nobody remembers whose turn it is, and the whiteboard on the fridge stops being updated within a month. Rota assigns recurring chores on a rotation and reminds the person whose turn it is. This works if, in a household that installs it, at least three of four housemates are still marking chores done in week six.
Product ICP. Households of three to five adults who rent together and aren't related, mostly students and people in their twenties. They coordinate in a WhatsApp group today. One person, usually the one most bothered by the mess, installs the app and invites the rest. Not for: couples, families with children, or paid cleaning crews.
Constraints: do not build
- Expense splitting.
- Why excluded: housemates already use Splitwise or a bank app for that, and money adds disputes the MVP can't settle.
- In-app chat.
- Why excluded: the household already has a group chat. A second one would sit empty.
- Points, streaks, and leaderboards.
- Why excluded: the week-six number has to show whether plain reminders work before anything is layered on top.
P0 · Rotation reminders
Each chore has a rotation. When a chore comes due, the person whose turn it is gets a push notification.
- Complexity: medium
- Acceptance criteria:
- The notification arrives within one minute of the due time set for the chore.
- Marking a chore done moves the rotation to the next person and cancels any pending reminder.
- If the chore isn't marked done after 24 hours, the app sends one follow-up and then stops.
- If the person has notifications turned off, the chore shows as overdue on every housemate's home screen.
Open question. Does the rotation skip someone who is away, and who gets to mark them as away?
PRD example for an internal tool: Refund Desk
Objective. Support agents at an online store can't issue refunds themselves. They message a team lead in Slack, wait for a reply, and then ask someone with Stripe access to push it through. Customers wait two to three days for money the company has already agreed to return. Refund Desk lets an agent request a refund from the ticket and a lead approve it in one click. This works if the median time from request to refund drops below four hours in the first month.
Product ICP. The support team of one e-commerce company: eight agents, two team leads, and one finance manager. They work in Zendesk and payments run through Stripe. Agents raise requests, leads approve them, and finance reads the log at month end. Not for: other departments, other companies, or customers requesting refunds themselves.
Constraints: do not build
- A customer-facing refund form.
- Why excluded: the delay is in the internal approval. A form for customers adds a queue and leaves that step as slow as it is today.
- Custom approval chains. One rule only: refunds under $100 go through automatically, and anything above needs one lead.
- Why excluded: two leads approve everything today. A rule builder would take longer to build than the rest of the tool.
- Its own login system. Company Google sign-in only.
- Why excluded: there are eleven users and they are all on the same Google Workspace.
P0 · One-click approval
A lead sees pending requests with the order, the amount, and the agent's reason, and approves or rejects each one.
- Complexity: medium
- Acceptance criteria:
- Approving a request issues the refund through the Stripe API and writes the refund ID back to the request.
- A request can't be approved twice. A second click shows the existing refund.
- If Stripe rejects the refund, the request returns to pending with Stripe's error shown, and the agent is notified.
- Every approval and rejection is logged with who did it and when.
Open question. For partial refunds, does the agent enter an amount or pick line items from the order?
The sections stay the same across all three. What changes is where the risk sits. Chairfill depends on an integration, so its build order puts that first. Rota only matters if housemates keep using it, so its objective measures week six. Refund Desk has eleven known users, which is why its ICP reads like a head count.
Writing a PRD an AI coding agent can build from
If a coding agent is doing the implementation, a few things in the example change from good practice to load-bearing.
The "how to read this spec" block at the top exists because agents follow instructions literally and benefit from being told the rules of engagement before the content. Two of those rules matter more than the rest: build only what's listed, and stop and ask rather than guessing. Left unsaid, an agent fills ambiguity with plausible invention, and plausible invention is expensive to unwind.
The out-of-scope section does more work here than with a human team. A human engineer given a spec without a settings page will ask whether you want one. An agent will often just build it, along with a notifications system and an admin panel, because those things co-occur with the features you asked for in everything it has ever read. The constraints section is the counterweight.
Acceptance criteria as checkboxes also serve a second purpose with agents: they're the thing you point at when the output doesn't match intent. "Criterion three fails" is a far more productive instruction than "this isn't quite right."
This is the same reasoning behind spec-driven development, which is worth reading if the agent is doing most of the typing.
What a weak PRD looks like
For contrast, the same product specced badly:
Objective: Build a modern, intuitive platform that helps dental practices optimize their scheduling workflow and improve patient satisfaction.
Features: Waitlist management, smart notifications, calendar integration, analytics dashboard, patient portal, admin settings.
Every statement there is true, and none of it can be built. There's no user named, no way to tell whether the thing worked, no indication which of the six features matters most, and no signal that "calendar integration" is a month of work while "waitlist management" is two days. Handed to an engineer, it produces six half-features. Handed to an agent, it produces six half-features faster.
The two versions differ in risk. Every sentence in the first one could turn out to be wrong, and every sentence in the second one is safe.
Adapting this to your product
Keep the section order and replace the content. The parts that transfer without modification:
- The "how to read this spec" block, if an agent is building.
- The must/should/could grouping with P0/P1/P2 inside it.
- Acceptance criteria as checkboxes, including at least one failure path per feature.
- The out-of-scope list with a reason on every line.
- A build order that front-loads the riskiest unknown.
The parts you have to earn rather than copy are the objective and the ICP, because both depend on evidence you can only get by talking to the people who have the problem. A PRD built on an assumed user is a very organized way to build the wrong thing. That's the work that comes before this document, and it's worth doing first: how to validate a business idea covers the cheap version.
Once you have that evidence, the free PRD generator drafts the objective, the ICP, the feature list with acceptance criteria, the do-not-build section, and the open questions from a description of what you are building, and copies the result as Markdown for your coding agent. It leaves out dependencies and the build order, so add those by hand.