Below are two complete PRD examples — a product requirements document you can read top to bottom and copy the shape of. The first is a dashboard redesign (a UI change); the second is usage-based billing (a backend feature). Both use the same seven-section template, so you can see how the same structure holds up whether the work is visual or plumbing.
This is the examples article in our AI PRDs guide. If you want the blank template to copy, start with the PRD template. If you're handing the spec to an AI coding agent, read PRDs for AI coding agents after this.
Example 1: Dashboard redesign
The setup: your app's home dashboard has grown into a wall of widgets. New users bounce; power users can't find what they check daily. Here's the PRD.
# PRD: Dashboard redesign
**Author:** Priya
**Status:** In review
**Last updated:** 2026-07-20
## Problem
New users land on the dashboard and see fourteen widgets with no order to them.
In the last month, 40% of new accounts opened the dashboard once and never came
back. Power users tell us the three things they check every morning are buried
below the fold. The dashboard is the first screen everyone sees, and right now
it's working against us.
## Goals
- A new user understands what the dashboard is for within five seconds.
- The three most-used widgets are visible without scrolling.
- Return visits to the dashboard in week one go up.
## Non-goals
- We are not adding new widget types in this work.
- We are not building per-user custom layouts — that's a later project.
- We are not touching the data behind the widgets, only the layout.
## User stories
- As a new user, I want a clear starting view so I know what to do first.
- As a daily user, I want my key metrics up top so I don't scroll to find them.
- As any user, I want the page to load fast so it doesn't feel heavy.
## Requirements
**Must have**
1. The dashboard shows at most six widgets by default; the rest live under a
"Show more" toggle.
2. The top row holds the three widgets with the highest usage across all
accounts (activity, tasks due, recent items).
3. First-time users see a one-line explainer above the grid that dismisses on
click and never returns.
4. The above-the-fold view renders in under one second on a mid-range laptop.
**Nice to have**
- A subtle reorder animation when "Show more" expands.
## Success metrics
- Week-one return visits to the dashboard rise from 60% to 75%.
- Bounce on first dashboard view drops below 25%.
- Time-to-first-interaction on the page stays under one second.
## Rollout
- **Ship behind:** a feature flag, on for 10% of new signups first.
- **Before launch:** update the product tour screenshots.
- **Rollback:** flag off returns the old dashboard instantly, no deploy.Notice what makes this one work: the problem names a real number (40% bounce) and a real person (the power user who scrolls). The non-goals kill three arguments before they start. And every requirement is checkable — "at most six widgets," "under one second" — not "make it cleaner."
Example 2: Usage-based billing
A very different kind of work — no new screens, mostly backend — but the same template.
# PRD: Usage-based billing
**Author:** Marcus
**Status:** Draft
**Last updated:** 2026-07-20
## Problem
We charge one flat monthly price. Small teams tell us it's too expensive for how
little they use; big teams are quietly getting a bargain and we're leaving money
on the table. We've lost four deals this quarter because we couldn't offer
pay-for-what-you-use pricing. We need to bill on actual usage.
## Goals
- Customers are charged based on metered usage each month.
- A customer can see their current usage and projected bill any time.
- Finance can trust the numbers — billing matches metered usage exactly.
## Non-goals
- We are not changing existing flat-rate plans in this work; usage billing is a
new plan type customers opt into.
- We are not building usage alerts or spend caps yet — fast follow.
- We are not supporting annual prepay for usage plans at launch.
## User stories
- As a small team, I want to pay for what I use so the price fits my size.
- As an admin, I want to see usage and a projected bill so there are no surprises.
- As finance, I want billing to reconcile with usage so I can trust the invoices.
## Requirements
**Must have**
1. Every billable action writes a usage event with an account ID, a type, a
quantity, and a UTC timestamp.
2. Usage events are aggregated per account per billing period; the total is
idempotent — replaying events never double-counts.
3. An admin can view current-period usage and a projected bill on a Billing page,
updated at least hourly.
4. At period close, the invoice line items equal the aggregated usage totals to
the cent.
5. If usage metering fails, the system fails closed — it queues events for retry
rather than dropping them.
**Nice to have**
- A CSV export of raw usage events for an account.
## Success metrics
- Billing reconciles to metered usage within $0 variance for three consecutive
closes.
- At least 15 accounts move to a usage plan in the first month.
- Zero dropped usage events (measured by the retry queue draining to empty).
## Rollout
- **Ship behind:** an internal flag; enable for three friendly design-partner
accounts first, then open self-serve.
- **Before launch:** finance sign-off on a full test-period reconciliation.
- **Rollback:** new signups fall back to flat-rate; existing usage accounts keep
metering (billing can't be un-shipped mid-period).Same seven sections, completely different work. The billing PRD's requirements read like a contract — "idempotent," "to the cent," "fails closed" — because money is unforgiving and vagueness there is expensive. That's the general rule: the higher the stakes, the more testable each requirement has to be.
What both examples get right
- The problem is a story, not a wish. Both open with real numbers and named people, not "improve the experience."
- Non-goals do the heavy lifting. Each one heads off a scope fight before it happens.
- Requirements are pass/fail. You could hand any numbered line to a reviewer and they'd know if it's done.
- Metrics have targets. "$0 variance," "under 25% bounce" — a number you can check after launch, not a vibe.
Where sfora fits
Both of these PRDs are just markdown. In sfora, that's the whole point — you drop a PRD like these into the workspace and it becomes something the team works from, not a doc that rots in a drive. People comment on it and turn requirements into tasks. And because agents are equal members, an AI agent can read the billing PRD's requirement 2, understand "idempotent aggregation," and start building against it.
The usage-billing example hints at why precision pays off doubly when an agent might be the implementer: "idempotent" and "fails closed" aren't just good engineering hygiene, they're instructions an agent can act on. Writing requirements that way on purpose is the subject of PRDs for AI coding agents. To start from scratch, grab the PRD template.