Mark Andrews Creative came to us with one sentence: "a platform to sell my courses, books and products with an e-learning system like Coursera and Udemy." There was no documentation and no plan. I wrote all the requirements, specs, feature definitions and business logic, and the developers built from my specs. The platform went live in 12 weeks, and the business now makes over $1M a year on it.
A good PRD is what turns a sentence like that into something a team can build. This post covers what a PRD is for, the sections that matter, how to write business rules so nobody guesses, and a free template you can download or copy.
What is a PRD for?
A PRD (product requirements document) is the single place that says what the product must do and how it must behave. Developers build from it, designers design from it, and when a question comes up halfway through the build, it's where the answer should already be.
The test of a PRD is simple: could a developer build from it without coming back to ask what you meant? Every question they have to ask costs time, and every question they don't ask but guess at costs more, because a guess can end up in the product.
What sections should a PRD have?
These are the nine sections in my template, and the question each one answers.
| Section | What goes in it | The question it answers |
|---|---|---|
| Problem | Who has the problem, what it costs them today, how they solve it now | Why are we building this? |
| Users | Each type of user, one line each | Who is it for, and what do they come to do? |
| Scope | What's in this release, and what isn't (and when it comes) | What are we building now? |
| Flows | The main flows, step by step, linked to wireframes | How does someone get from start to finish? |
| Business rules | Every rule, written in the same shape | What exactly happens, for whom, up to what limit? |
| Edge cases | No data yet, a failed payment, a limit reached, two people editing at once | What happens when it goes wrong? |
| Data | What's stored, where it comes from, who sees it, what moves from an old system | What does the product know? |
| Success metrics | The metric, how it's measured, the target and the time window | How will we know it worked? |
| Open questions | Each undecided point, its owner and a date | What haven't we decided yet? |
How do you write business rules nobody has to guess?
This is the section that decides whether a PRD works. Most of the rework I've seen comes from a rule that was never written down, so two people built two different versions of it.
I write every rule in the same shape:
When [situation], [who] can [do what], up to [limit]. Otherwise, [what happens].
Here's how that looks for two kinds of rule from Mark Andrews Creative, whose subscriptions have rules about users and downloads.
Users per plan. Each subscription includes 5 users at a fixed price, teams can invite more, and extra users are billed per the tier's conditions. As a rule: When a team on a subscription invites someone, an admin can add them; 5 users are included, and each extra user is billed per the tier's conditions.
Download limits. Each subscription tier has monthly download limits on courses and modules, and downloads stay with the subscriber. As a rule: When a subscriber downloads a course or module, it counts against their tier's monthly limit, and anything they've downloaded stays theirs.
Now try to fill in the "otherwise" for the second rule: what happens when a subscriber reaches the limit? If you can't answer it from the PRD, that's exactly the point. It belongs under open questions, with an owner, before anyone builds it. The shape of the rule is what exposes the gap.
Looking back on Mark Andrews Creative, I'd put all of these rules into one written, signed-off rulebook in week one, so every edge case (users per plan, download limits, course access) had a single reference. I wrote about the commerce side in How Mark Andrews Creative sells subscriptions, courses and products in one checkout.
What if you take over requirements someone else wrote?
On AidNetwork, a healthcare staffing platform, the project manager who wrote the first requirements left mid-project. I took over and kept the first version as the baseline instead of starting again, closed its open decisions with the client, and agreed success metrics and launch targets before launch. The platform launched about two months after I took over.
What I'd add next time is a handover audit on day one: go through every inherited decision, open question and assumption in the requirements before changing anything, so nothing important is lost in the switch. That audit is really just the "open questions" section of a PRD, written by the person who inherits it.
How long should a PRD be?
As long as it takes to answer the questions developers will ask, and no longer. For a single feature, two pages is often enough. For a platform like Mark Andrews Creative, with orders, subscriptions, courses, promotions, 20+ reports and settings, it's a set of documents.
Two habits keep it useful whatever its length. Write the scope as two lists, in and out, so anything missing was left out on purpose; I go through how to make those cuts in How to scope an MVP. And date every open question, because an open question without an owner stays open.
The PRD template
Download the two-page PDF with the form below, or copy this outline into your own document.
PRD: [product or feature]
Owner · Version · Last updated · Status (draft, in review, signed off) · Signed off by
01 Problem
Who has the problem, what it costs them today, and how they solve it now.
02 Users
Each type of user on its own line: who they are and what they come to do.
03 Scope
In this release:
Not in this release, and when:
04 Flows
The main flows, step by step, from start to finish. Link the wireframes.
05 Business rules
When [situation], [who] can [do what], up to [limit]. Otherwise, [what happens].
06 Edge cases
No data yet, a payment fails, a limit is reached, two people change the same thing.
07 Data
What is stored, where it comes from, who can see it, what moves from an old system.
08 Success metrics
Metric · How it is measured · Target · Time window
09 Open questions
Question · Owner · Decide byFrequently asked questions
What is a PRD?
A PRD, or product requirements document, describes what a product or feature must do and how it must behave, in enough detail for designers and developers to build it. It's the single reference everyone checks when a question comes up during the build.
What should a PRD include?
At minimum, the problem, the users, what's in and out of scope, the main flows, the business rules, edge cases, the data, success metrics and open questions. Those nine sections are what my template uses.
How long should a PRD be?
As long as it takes to answer the questions developers will ask, and no longer. For a feature that might be two pages; for a whole platform it's a set of documents. Length matters less than whether every rule is written down.
Who writes the PRD?
Usually the Product Manager, with input from design, engineering and the client or business owner. On Mark Andrews Creative I wrote all the requirements, specs, feature definitions and business logic, and the developers built from my specs.
