Product requirements document: what to hand a builder before they build

What a product requirements document is, and what it is for

A product requirements document, a PRD, is the written answer to one question: what are we building first, for whom, and what will it do. It is not a pitch, not a plan for the company, and not a technical design. It is the thing a builder reads before they estimate, and the thing you both point at when the build drifts.

Inside a company it is often a long document because many people have to agree to it. Yours can be short, because one person owns the decisions and one person or one small team is going to build them. Four to eight pages is normal for a first version. If it runs to thirty, you are describing a company, not a first release.

The reason to write one at all is not ceremony. It is that a builder who is guessing will guess in the direction that is easiest to build, and a founder who has not written the decisions down will remember them differently in three weeks. A written document costs a day. An unwritten one costs a rebuild.

There is a second reason that matters more for a founder than for a product manager. The act of writing the screens as steps forces you to notice the parts of the idea you have not decided yet. Those are cheaper to decide now, on paper, than after they have been built one way and you wanted them another.

What goes in it

Keep the order below, because each part depends on the one before it. A builder reads it top to bottom, and a builder who has to skip ahead to find out what the product is will not trust the rest.

1. The problem, in the customer's words. Two or three sentences. Who has it, when it happens, and what they do about it today. If you have interviewed people, use a sentence one of them actually said. If you have not, say so, and see the section on evidence below.
2. Who the first version is for. One kind of person, described specifically enough that you could tell whether a given stranger is one of them. Not small business owners. Independent physiotherapists who run their own bookings.
3. What the first version has to make possible. The one outcome. A dog owner books and pays a walker for an hour without a phone call. Everything else in the document serves this sentence.
4. Where it runs. Phone, laptop, or both, and which one first. This decides more of the build than founders expect, and a builder cannot quote without it.
5. The screens, written as the steps a person takes. The heart of the document. The next section is about how to write these.
6. The must-haves. The short list of things without which the first version is not usable. Not the wish list. The list you would refuse to launch without.
7. The non-goals. What the first version deliberately does not do. Builders read this section more carefully than any other, and the section after next explains why.
8. The decisions behind it, with the assumptions labeled. Why phone first. Why one payment method. Why no accounts on day one. Where you decided something on a guess, say it is a guess, so a builder who learns otherwise knows they are allowed to raise it.
9. What done looks like. How you will know the first version worked. Ten paid bookings in the first month. Five people who used it twice. A number, and a date.

That is the whole document. Everything you are tempted to add is either a later version, which belongs in a separate note, or a technical decision, which belongs to the builder.

Write the screens as steps, not as a list of features

The mistake that costs the most is writing the product as a list of features. User accounts, search, booking, payments, notifications, reviews. A list like that is impossible to estimate, because every item on it is a range from an afternoon to a month depending on decisions the list does not contain.

Instead, walk through the product as one person using it once, and write down every screen they see and what they do on it.

Start at the moment they first arrive. What is on the screen. What is the one thing they are meant to do. What happens when they do it. Then the next screen, and the next, until they have got the outcome from step three of your document. Then do the same walk for the second kind of moment, the one where they come back.

A useful shape for each screen is three short lines.

• What they see. The two or three things on the screen, in order of importance.
• What they do. The one action, or at most two.
• What happens next. The screen they land on, or the message they get.

Write it plainly. A builder can turn "a list of nearby walkers, each with a photo, a name, a price per hour and a Book button" into an estimate. They cannot estimate "an intuitive discovery experience".

Two habits make this go faster. Draw each screen as a rough box on paper before you write it, because the drawing will show you a missing step that the prose hides. And write the unhappy paths as you go, briefly: what the screen shows when there are no walkers nearby, when the payment fails, when the person is not signed in. Those are the cases a builder would otherwise have to invent, and inventing them is where a build goes off course.

When you are done you will have somewhere between six and fifteen screens for a first version. If you have thirty, the first version is too big, and the non-goals section is where you fix that.

Non-goals are the part a builder thanks you for

Every product has a hundred things it could do. The document is mostly about the handful it will do first, and the non-goals section is where you write down the ones you have looked at and decided against, for now.

It matters because of how ambiguity gets resolved during a build. If the document does not say whether the first version has user accounts, one builder will add them, because most products have them, and another will leave them out, because nothing asked for them. Both were reasonable. Only one was what you wanted, and you will not find out which until it is built.

So write the section as a plain list, and write the reason beside each one.

• No user accounts in the first version. Bookings are tied to a phone number, because asking someone to create an account before their first booking is where most of them leave.
• No reviews. There are not enough bookings yet for reviews to mean anything, and an empty reviews section reads worse than none.
• No in-app messaging. Walker and owner get each other's phone number on booking, which is what both of them wanted anyway.
• Phone only. A laptop version comes if walkers ask for one.

Notice that each line also records a decision you might revisit, with the condition under which you would. That is worth more than the list itself. Three months from now, when someone asks why there are no reviews, the answer is in the document rather than in your memory.

A short non-goals list also does something for you: it makes the first version small enough to actually ship. Most first versions that never launch died of scope, not of difficulty, and this is the section where scope is decided.

What to leave out

A founder's first draft usually has too much in it, and the extra material is not harmless. It signals to a builder that the decisions are not settled, and it invites the estimate to grow.

Leave out the technology choices unless you have a real reason. Which database, which framework, which hosting: those are the builder's decisions, and a document that makes them for the builder either ties their hands or gets ignored. The exceptions are constraints you actually have. Your customers are all on iPhones. You have to integrate with a particular booking system. Say those. Say nothing about the rest.

Leave out the competitor feature list. A document that reads "like X but with Y" tells a builder to copy X, and they will, including the parts of X that exist for X's reasons and not yours.

Leave out later versions. Keep one separate note called later, put everything you had to cut into it, and do not attach it to the document. A builder who sees version two in the same file will, kindly, start building toward it.

Leave out the business plan. Pricing model, marketing, how big the market is. None of it changes what the first screen looks like, and a builder does not need to be persuaded the company will work in order to build the product well.

And leave out anything you would describe with a word like intuitive, effortless or delightful. Those words are where an idea is still hiding. Replace each one with the screen and the step it was standing in for.

Ground it in something other than your own opinion

The weakest PRDs are internally consistent and entirely made up. Every decision in them is reasonable and none of it has met a customer.

You do not need a research department. You need three kinds of evidence, in roughly this order of usefulness.

Sentences people said. Six to ten conversations with the kind of person from step two, before you write. Ask what they do today about the problem, what they have tried, and what they would pay for. Write the exact phrases down. The problem statement in your document should be built from them, and several of your screens will change because of what you hear.

A demand test. Before building, put the promise in front of strangers and count who reaches for it. A one page description with one button, and a record of how many people pressed it, tells you more about the first version than a month of planning. The fake door test guide covers the method, and how to validate a business idea covers what to do with the number.

Whatever exists in writing already. Forum threads, reviews of the tools people use today, the comments under a competitor's launch. These tell you the words people use and the complaints they repeat, and both belong in the document.

Then label everything you could not check. A single word, assumption, beside a decision, is enough. It tells the builder which parts are firm, and it tells you in three months which parts to revisit first.

If you already have market and customer research, the document should quote it rather than restate it. A figure with a source is worth ten confident sentences.

How to hand it over, and what to expect back

Send the document before the first conversation, not during it, and ask for three things back.

Questions. A builder who has read the document properly will have between five and twenty. If they have none, they have not read it, or they are planning to make the decisions themselves. Answer the questions in writing and add the answers to the document, so the next person to read it does not ask them again.

An estimate against the screens. Ask for it screen by screen, or step by step, rather than as one number. A single figure hides which part is expensive, and the expensive part is very often something you could cut or simplify without losing the outcome.

A build order. Which screens first, and what you will be able to try at the end of each week. This is the part that keeps a build honest: you see the product working in pieces rather than waiting for a reveal.

What you should expect to give in return is availability. A builder with a question and no answer for two days will either stop or guess, and both cost you. Set a time each week to look at what exists and to answer whatever has come up.

The document is not finished when the build starts. Every decision made during the build goes into it, so that when a second builder joins, or the first one leaves, the document is still true. A PRD that is not kept up to date becomes a record of what you once intended, which is nearly useless.

One last thing to expect. A good builder will push back on some of it, usually on the must-haves, and they are usually right that the list can be shorter. Take that seriously. The first version that ships small and works is the one that gets a second version.

Writing it with LaunchValid

Everything above can be done in a document you already have open, and the thinking in it is yours to do. Where a tool helps is with the research the document should rest on, and with the writing itself once the decisions exist.

The product spec is that document, written from your idea. You describe what you are building in a sentence or two, answer a short intake about the outcome of your first version and the device your customers use, and the market and customer research is run first, so the problem statement and the customer are grounded in something other than your own opinion. What comes back is a single product document in plain language: what you are building and who it is for, the core screens and the steps a person takes, the must-have features and the explicit non-goals, and the decisions behind it with the assumptions labeled. It is written to be handed to a developer or a no-code builder, you pay once with no subscription, and one section can be reworked at no charge within two days if you want it different.

On a plan, the same documents are made inside your project. Once your research is written, the product and engineering questions open, and answering them produces both a product document and an engineering document: the recommended tools, how the parts fit together, and a build plan. Both can be downloaded as a branded PDF on any plan.

What it does not do is know what the customer said to you on Tuesday. The conversations in the evidence section are still yours to have, and the sentences from them are still the best material in the document.