A PRD, or product requirements document, is the document that says what you are actually building. It is the companion to your one pager, and the split between them is simple: the one pager is why, and the PRD is what.

You write it after the research and after the one pager, and before anybody starts building. Written earlier than that, it records your guesses in a format that makes them look like decisions.

What goes in it

For each feature: a problem statement explaining why the feature exists, and under it the list of acceptance criteria, meaning everything that has to be true for it to be complete.

You are defining your problem, your goals, your requirements and your acceptance criteria before you think about implementation. That order is the whole discipline.

What to say and what not to say

We are not saying how things would be built. We are saying what will be built.

You can write that you are thinking this will be a full screen pop up, while making clear you have not decided. There are no decisions at this point about implementation. Leaving that space open is not vagueness, it is what lets a developer or a designer bring you the better option they know about and you do not.

Success metrics, but only a few

You want success metrics on your PRD. They should not be a lot, two to four maximum, and you are just saying how we will measure success of this product or this feature.

There is also a version of that question that is not about numbers. What does success look like from a did I solve the problem point of view? Does this solve a problem, and how do we know? Use that section to talk about how it will improve the life of your user.

And a PRD is not only for a whole product. We do a PRD for individual features too.

Do you need one if you are building alone

If you are a solopreneur, you need less of this than a company does. The problem statement is the piece I would not skip.

The argument for writing more of it than you think you need is one I learned the annoying way. You need evidence, especially if you have stakeholders. I am my own stakeholder two years later, and I do not have the evidence any more, because I kept it all in my head.

But there is a specific case where you do want a PRD even alone: when someone else is going to build any part of it. The PRD is what turns your idea into something a developer can quote on and deliver against, instead of something they interpret.

If you are writing the code yourself, write the acceptance criteria at least. They are what stop you from redefining done halfway through a hard afternoon.

On having AI write it

I have used AI for a first pass on a PRD. After a client requirements meeting I give the transcript tool my PRD template and ask it to write a PRD based on the meeting, so I spend an hour fixing it rather than five hours writing it.

That works because the meeting happened. The research exists and the AI is reformatting it.

What does not work is the version where you give a tool an idea and it prints a PRD. I looked at one of those and my reaction was that you are just making stuff up. You have not done any actual real research.

It is the same problem as looking for examples online. You go searching for what a real one looks like and you find templates, because people do not publish their actual work, they publish the empty shape of it. A template tells you where the headings go. It cannot tell you whether what you put under them is true.

A PRD is a record of decisions you made from evidence. If there is no evidence behind it, it is a nicely formatted guess, and it will read as authoritative to everyone who did not watch it get generated.

It will change

These are living documents and they are going to constantly change. You have not started development yet, so it is a work in progress, and once development starts it is still always changing.

Keep reading

What Are Acceptance Criteria and Who Writes Them?

What Is a One Pager and What Goes In It?

What Do I Need to Know Before Hiring a Developer?

Learn this with me

The PRD is class 8 of From Passion to Product, my free six-week live course, in the same class as the technical decisions. I teach it as eleven core sections, alongside working with designers and how to run a design review. It is the last document in the package, because everything in it comes from the seven classes before it.

I teach the same material to engineering teams, as a one day workshop or a longer program, for engineers who want to write these rather than receive them.

Join the waitlist for the free cohort, get the workbook, or look at the team programs.