PRD (product requirements document)

What a PRD contains

A PRD describes the product from the point of view of the people who will use it. It answers what is to be built and why, and leaves the technical solution to the team that builds it. It is usually written by the person responsible for the product and read by design, development and testing.

Most PRDs cover the same ground, even though the headings differ from team to team:

• Purpose. The problem the product or feature solves and why it matters now.
• Users. Who it is for and in what situations they will use it.
• Requirements. What the product must do, often as user stories or a list of features, and qualities such as speed, security or accessibility.
• Scope. What belongs to this release and what is deliberately left out.
• Success criteria. How the team will tell that the product does what it should, for example measurable goals or acceptance criteria.
• Assumptions and open questions. What the team takes as given, what depends on other work and what is still to be decided.

A PRD has neighbours. A market requirements document (MRD) describes the market need a product answers, before the product itself is defined. A functional requirements document (FRD), also called a functional specification, goes one level lower and describes in detail how the system behaves. The PRD sits between the two: it says what the product does for its users.

How to write a PRD

Start with the problem, not the solution: in a few sentences, who has the problem and what it costs them today. Then write the requirements so that each one can be checked. “Fast” can’t be checked; “search results appear within a second” can. Say what is out of scope, because that is often where misunderstandings begin.

A PRD is a working document. It changes as the team learns more, so it pays to keep it in one place where everyone reads the current version, and to record decisions as they are made.

When an AI agent builds from a PRD, these rules matter even more. Write the open questions down instead of leaving them out: whatever the document doesn’t say, a coding agent has to work out on its own. A PRD for a whole product is usually too large for one agent session. Teams that work this way split it into smaller tasks, each with its own acceptance criteria. That is the heart of spec-driven development.

A PRD in featureloom

In featureloom the unit of work is a plan: a markdown document on the board with one piece of work, which the agent gets whole, delivers and reports. A PRD usually describes more than that, so it becomes several plans, grouped under an epic and ordered by dependencies.

You don’t have to copy a PRD out by hand. On the Capture screen, paste its text into the Material field or send it as a PDF or Word document, and featureloom generates a plan from it with your project’s plan template. The tutorial A plan from pasted text or a PDF or Word document shows each step. Whether the same material can give you more than one plan depends on your organization’s setting.

The built-in plan template asks for the goal, scope, steps, acceptance criteria and definition of done: the parts of a PRD an agent needs to deliver one piece of work. You fit the template to your team on the Project settings screen, in the Plan template tab.

You can also give a PRD to an agent in a console as a text file, with the command that carries the Planner prompt. The prompt tells the agent to read the project’s plan template, create an epic for a topic that has none yet, write each plan in the template’s sections as one piece of work for one agent session, and record the order as dependencies. For that, the person who connected the console needs the Writes plans right.