# What is a PRD? How to write one, step by step

> A PRD is a product requirements document. Learn what goes in one, how long it should be, how to write it step by step and the mistakes to avoid.

A product requirements document says what you are building, for whom and why, and how you will know it worked. Here is what goes in one, how long it should be and how to keep it useful.

Web page: https://kansohq.app/guides/what-is-a-prd

Updated: 5 October 2026

## What a PRD is

A product requirements document, or PRD, is a short document that describes a product or a feature before it is built: the problem, who has it, what the answer looks like, what is in and out of scope and how success will be measured. It is the agreement between the people who decide what to build and the people who build it.

A PRD covers **what** and **why**. It leaves **how**, the technical approach, to the design doc. See [how to write a technical design doc](https://kansohq.app/guides/how-to-write-a-technical-design-doc.md).

## What goes in a PRD

- **Problem:** who is hurt today, and what it costs them.
- **Goals and non-goals:** what this must achieve, and what it will not try to do.
- **Users:** the main user, and who it is not for.
- **Solution:** the shape of the answer in a few sentences, with a flow or a sketch if that helps.
- **Scope:** what is in the first version, and what is explicitly out.
- **Requirements:** the behavior the product must have, each one testable.
- **Success measure:** one number or one thing you can observe.
- **Open questions:** what is still undecided, and who decides.

## How long should a PRD be?

As short as the decision allows. One page is enough for a small feature and three for a large one. If a PRD needs ten pages, the feature is probably several features. A short PRD that people read beats a long one that people sign and forget.

## How to write a PRD, step by step

1. Write the problem first, in one paragraph, before any solution. If you cannot state it plainly, you are not ready to write the rest.
2. Name the user and the moment they hit the problem. “People who work offline” is better than “users”.
3. Write the success measure before the solution, so the solution has something to be judged against.
4. Describe the solution as a flow: what the person does, what the product does back, what the result is.
5. Cut scope. List what is out of the first version, in writing, so the question is settled once.
6. Turn each requirement into a line that can only be true or false. See [how to write acceptance criteria](https://kansohq.app/guides/how-to-write-acceptance-criteria.md).
7. List the open questions, each with a name beside it.
8. Share it for review, change it where the review is right, and keep it up to date as the work moves.

**A short example**

> **Problem:** field crews lose edits when the signal drops, and redo up to an hour of notes a day.
> **Success:** crews report no lost edits for four weeks after launch.
> **In scope:** edits made offline are kept and merged when the device is back online.
> **Out of scope:** editing the same line offline on two devices (the later edit wins, for now).
> **Open question:** how long to keep an unsent edit? Owner: engineering lead.

## PRD mistakes to avoid

- Starting with the solution, so the problem is written to fit it afterwards.
- Requirements nobody can test, like “fast” or “easy to use”.
- A PRD that is never updated after the first review, so it describes a product that no longer exists.
- Hiding open questions to look finished. A named open question is a strength.
- Filling in every heading of a template when half of them do not apply.

## PRD, BRD and MRD: what is the difference?

Three similar abbreviations get mixed up. They describe different questions, and a team may use one, two or all three.

| Document | Question it answers | Usually written by |
| --- | --- | --- |
| MRD (market requirements document) | Who is the market, and what do they need? | Product marketing or the founder |
| BRD (business requirements document) | What does the business need from this, and what is it worth? | A business analyst or sponsor |
| PRD (product requirements document) | What will the product do, for whom, and how will we know it worked? | The product manager or lead |

Small software teams usually skip the MRD and the BRD and write one PRD that opens with the business reason. If a stakeholder asks for a BRD, the first two sections of your PRD (the problem and the success measure) are most of it.

## Keep a PRD alive

- Put a date and an owner at the top, and update the date whenever the content changes.
- Record each change of scope in the PRD itself, with the reason, rather than in a thread nobody will find.
- Mark each open question as answered when it is, and write the answer beside it.
- When the feature ships, add what happened against the success measure. That is how the next PRD gets better.

## Who should review it

Ask one engineer who will build it, one person who will test it and one person who owns the product decision. Engineers find scope that is bigger than it looks, testers find requirements that cannot be checked and the owner finds the places where the document and the intent have drifted apart. Three reviewers who read carefully are worth more than ten who skim.

## A PRD in Kanso

Kanso keeps the PRD in the project it describes. Start from the [PRD template](https://kansohq.app/templates/product-spec.md), turn each to-do in the spec into a card on a [board](https://kansohq.app/product/boards.md) (the two stay linked), gather the work behind the ship date on a [release page](https://kansohq.app/product/releases.md) and send reviewers a read-only link that opens without an account. See [Kanso Docs](https://kansohq.app/product/docs.md).

## Questions

### What does PRD stand for?

PRD stands for product requirements document: a short document that says what a product or feature must do, for whom and why, before it is built.

### What is the difference between a PRD and a product spec?

In practice the two words mean the same thing: a document that says what to build and why. Some teams call the full document a PRD and the detailed behavior of one feature a spec. Pick one name and use it everywhere.

### Who writes the PRD?

Usually the product manager or whoever owns the problem, with input from design and engineering. On a small team the founder or the lead engineer often writes it.

### Does a PRD replace the technical design?

No. A PRD says what to build and why. A technical design doc says how it will be built. Write the PRD first and the design doc against it.

## Keep reading

- [How to write a product spec your team will read](https://kansohq.app/guides/how-to-write-a-product-spec.md): A good product spec is short, specific and honest about what is not decided. Learn how to write one, what to leave out and how to keep it current.
- [How to write acceptance criteria, with examples](https://kansohq.app/guides/how-to-write-acceptance-criteria.md): Acceptance criteria say when a task is done. Learn how to write them as clear true-or-false lines, with examples and a checklist for software teams.
- [How to write a technical design doc](https://kansohq.app/guides/how-to-write-a-technical-design-doc.md): A technical design doc explains how you will build something and why. Learn the sections to include, how to compare options and how to get a useful review.
- [PRD template: a free product spec to copy | Kanso](https://kansohq.app/templates/product-spec.md): A free PRD template for software teams: problem, solution, who it is for, scope, success measure and open questions. Copy it, or start it in Kanso.
- [Feature spec template with acceptance criteria | Kanso](https://kansohq.app/templates/feature-spec.md): A feature spec template with how it behaves, acceptance criteria, edge cases and what you are not doing. Copy it, or start it as a page in Kanso.

## Parts of Kanso used

- [Kanso Docs](https://kansohq.app/product/docs.md): Pages with headings, to-dos, tables and code, kept inside the project they describe, next to its board and its release.
- [Kanso Boards](https://kansohq.app/product/boards.md): A board for each piece of work. Cards carry a priority, an owner, a due date and the criteria that say when they are done.

[Kanso home, with plans and prices](https://kansohq.app/index.md)