Fabricate

TemplateUpdated

PRD template, with a generator that fills it in

A product requirements document says what you are building, for whom and why, and what the first version must and must not do. Fill in the form, and copy or download the PRD it writes.

A PRD for a first version needs seven parts: the product in one line, the problem, the users, goals and how you will measure them, the requirements, what is out of scope, and the questions still open. One or two pages is enough for a first version.

By the Fabricate teamWe make Fabricate5 min read
Fill in the templateFree, no account

Fill in your PRD

The form holds a worked example: a booking app for a one-van dog grooming business. Change any field and the PRD is rewritten as you type, or clear the example and start from the questions.

A working name is fine.

What it is and who it is for.

What goes wrong today, and for whom.

Each kind of person, and what they come to do.

One per line, each one you can check.

One per line, most important first.

One per line: what this version will not do.

One per line.

Your PRD, in Markdown
# Tidy Paws: product requirements

> Online booking for a one-van mobile dog grooming business.

## Problem

Bookings arrive by phone, text and Instagram message. The groomer answers them between appointments, double-books about once a week, and loses evenings to confirming times and chasing no-shows.

## Users

Dog owners within 15 miles who book a groom every 4 to 8 weeks, and the groomer, who runs the business alone from a phone.

## Goals and success measures

- Most bookings come through the app within two months of launch
- No double bookings
- Fewer missed appointments than the month before launch

## Requirements

1. Owners pick a service, a size of dog and a free slot, and book without an account
2. Each booking asks for the dog's name, breed, the address and a phone number
3. The groomer sets working days and hours and blocks out time off
4. A slot cannot be booked twice
5. The owner gets an email confirming the booking, and another the day before
6. The groomer sees the day's bookings in order on a phone, with the address of each
7. The groomer can cancel or move a booking, and the owner is emailed when that happens

## Out of scope for this version

- Taking payment online: owners pay on the day as now
- Route planning between addresses
- More than one groomer or van

## Open questions

- Should owners be able to cancel themselves, and how close to the appointment?
- Is a text reminder worth adding later, or is email enough?
Build it in Fabricate

Free, in your browser. Building opens Fabricate with your name, one-liner, users and requirements written out; nothing is built until you press Build there.

What goes in a PRD

Seven parts, each answering one question. The example under each is the same part of the dog grooming PRD.

  1. 1. The product in one line

    What is it?

    One sentence a stranger understands: what it is and who it is for. If you cannot write it, the rest of the document will drift. Leave out how it works.

    Example: Online booking for a one-van mobile dog grooming business.

  2. 2. The problem

    Why build it now?

    What goes wrong today, for whom, and what it costs them, in their words rather than yours. A problem with a number in it (an hour a day, one double booking a week) is easier to check later than one without.

    Example: Bookings arrive by phone, text and Instagram message. The groomer answers them between appointments, double-books about once a week, and loses evenings to confirming times and chasing no-shows.

  3. 3. The users

    Who uses it, and to do what?

    Name each kind of person who will use it and what they come to do. Most small products have two: the customer, and the person running the business. Say what device each one is on.

    Example: Dog owners within 15 miles who book a groom every 4 to 8 weeks, and the groomer, who runs the business alone from a phone.

  4. 4. Goals and success measures

    How will you know it worked?

    Two or three outcomes you can check after launch, with a time frame. "Users love it" cannot be checked; "most bookings come through the app within two months" can.

    Example: Most bookings come through the app within two months of launch · No double bookings · Fewer missed appointments than the month before launch

  5. 5. Requirements

    What must the first version do?

    One line per thing a user can do or the product must guarantee, written as behaviour you could test: "a slot cannot be booked twice", not "robust booking engine". Put them in order of importance, and stop when the product would be useful without the next one.

    Example: Owners pick a service, a size of dog and a free slot, and book without an account · Each booking asks for the dog's name, breed, the address and a phone number · The groomer sets working days and hours and blocks out time off · A slot cannot be booked twice · The owner gets an email confirming the booking, and another the day before · The groomer sees the day's bookings in order on a phone, with the address of each · The groomer can cancel or move a booking, and the owner is emailed when that happens

  6. 6. Out of scope

    What will this version not do?

    The things people will ask for that you have decided to leave out, so nobody builds them by accident and nobody is surprised. Say what happens instead where it matters, such as paying on the day.

    Example: Taking payment online: owners pay on the day as now · Route planning between addresses · More than one groomer or van

  7. 7. Open questions

    What is still undecided?

    Decisions you have not made yet, written as questions. A PRD with none usually has them hidden in the requirements. Answer each before the part it affects is built.

    Example: Should owners be able to cancel themselves, and how close to the appointment? · Is a text reminder worth adding later, or is email enough?

Mistakes to avoid

Describing screens instead of behaviour

Requirements such as "a blue button on the right" fix a design before anyone has tried it. Say what the person can do and what must be true; leave the layout to whoever builds it, and change it once you see it.

No out of scope list

Everything left unsaid is open to being built. Writing down what the first version will not do is the quickest way to keep it small.

Goals that cannot be checked

If a goal has no number and no date, nobody can say whether the product met it. Pick something you can count from the product itself or your records.

Writing it once and never again

A PRD is most useful while things are being decided. Update it when a question is answered or a requirement changes, and date the change.

Using a PRD with an AI app builder

An AI app builder reads a description the way a developer reads a PRD: the clearer the users and the requirements, the closer the first version is to what you meant. The requirements list, written as behaviour, is the part that matters most.

You do not need the whole document in the first prompt. Start with the one-liner, the users and the most important requirements, try what is built, then add the next requirements one or two at a time. The generator's "Build it in Fabricate" button opens Fabricate with that first prompt written out, and nothing is built until you press Build there.

Keep the out of scope list and the open questions next to you while you build. When the builder suggests something on the out of scope list, say no; when it needs an answer to an open question, decide it and update the PRD.

Questions people ask

What is a PRD?
A product requirements document (PRD) describes a product or feature before it is built: the problem it solves, who it is for, what it must do, what it will not do, and how success will be measured. Its job is to get everyone building it to agree on the same thing.
What should a PRD include?
The product in one line, the problem, the users, goals with a way to measure them, the requirements in order of importance, what is out of scope, and the open questions. Larger teams add a timeline, dependencies and sign-off, but a first version of a small product does not need them.
How long should a PRD be?
As short as it can be while still answering what, for whom, why and what not. For a first version of a small product, one or two pages is usually enough. If it runs much longer, the product is probably too big for a first version.
Who writes the PRD?
Usually the product manager, or the founder when there is no product manager, with input from the people who will build and sell it. Whoever writes it should be the person who decides what goes in and what stays out.
What is the difference between a PRD and a spec?
A PRD says what the product must do and why. A technical specification says how it will be built: the data, the services and the architecture. The PRD comes first, and the spec is written from it.
Is this PRD generator free?
Yes. It runs in your browser: nothing you type is sent anywhere until you press "Build it in Fabricate", and you can copy the PRD or download it as a Markdown file without an account.
Can I use the PRD with an AI app builder?
Yes. Paste the one-liner, the users and the requirements as your first prompt, or press "Build it in Fabricate", which opens Fabricate with that prompt written out. Add the remaining requirements once you have tried the first version.

Keep reading

All guides

Build the first version

60 credits a month to build and preview. Going live needs Pro.

Build free. No card needed.