Is a user story a spec?
A story belongs in the PRD. It says who does what and why. A spec is what you add when that story needs rules: fields, errors, and the check for done. One story can be enough of a spec when the step is simple.
Guide
PRD vs spec vs roadmap
A PRD says what you are building and why for this version. A spec says how one slice behaves, in enough detail to build and test it. A roadmap orders later bets without designing them. Write the PRD first, then the spec for the slice you will build now, and keep the roadmap as a sequence rather than a promise.
Want to try FounderBrief?
Describe the idea and get a PRD and build plan. No card required for the first one.
Try FounderBriefWhat is a PRD?
A product requirements document says what this version is for. It names the user, the problem, the outcome, the scope, the non-goals, the stories, the success signal, and the constraints. It is a decision about the product, written so someone else can tell what is in and what is out. It is not a design file, and it is not a list of every idea you have had.
For a startup, the PRD should describe the first version you are willing to build, not the company you hope to be. If the outcome cannot be checked, it is still a wish. The guide on how to write a PRD for a startup is the longer pass on writing that decision. This page is about how that decision sits next to the other two documents.
What is a spec?
A spec takes one slice of the PRD and says how it behaves. It is detailed enough to build or to test. For the confirm-a-shift step, a spec might say: the link opens without an account, the shift's time and place are visible, confirm stores the person's name and the time, and the manager's list updates. A PRD says that confirmation exists. The spec says what confirmation does.
You do not need a spec for every future idea. You need one for the slice someone is about to build. If the spec contradicts the PRD, fix one of them before the work starts. Two documents that disagree are worse than one short PRD. Keep the spec boring. Edge cases belong here. Vision does not.
What is a roadmap?
A roadmap is the order of later bets. It says what you intend to learn or build after this version, and what you are explicitly not designing yet. "After clinics use the link for a month, decide whether to add a native app" is a roadmap line. A mock of that app, with a feature list, is a second PRD you are pretending not to have started.
Order is the whole point. A roadmap that is a pile of columns with no sequence does not help you say no. Put the next bet, the one after that, and a parking lot for things you will not sequence until the current outcome is real. Dates are optional. If you put a date on a bet you have not specified, you have made a promise about a product you have not decided.
Which document should you write first?
Write the PRD first. It is the filter. Until the user, the outcome, and the non-goals exist, a spec has nothing to be precise about, and a roadmap is a wish list with headings. Founders often start with the roadmap because it feels like progress. It spreads attention across bets that the first version has not earned.
Then write a spec only for the slice in the build order. The MVP planning checklist is a short way to check that the slice is one job. If you are hiring, the PRD is what you send before the estimate. The spec can follow once the developer is looking at that slice. The roadmap can be five lines at the bottom of the PRD until you have more than one version in market.
How do the three documents point at each other?
Each line in the spec should point at a step or a story in the PRD. If it does not, it is scope creep or a missing requirement. Add it to the PRD on purpose, or take it out of the spec. Each item on the roadmap should be something the PRD refused or deferred. If a roadmap item is required for the user to finish the job, it is not later. It is scope, and the PRD is wrong.
Use the same words in all three. If the PRD says "locum" and the spec says "contractor" and the roadmap says "provider," you will have a meeting about vocabulary. Pick the user's word and keep it. Link the documents. Do not paste the whole PRD into the spec, or the spec stops being the precise page and becomes a second copy that drifts.
What happens if you only write one of them?
A PRD alone can be enough to start, if the first slice is small and the stories are testable. Add a spec when a step is being misbuilt. A spec alone, with no PRD, tends to grow, because nothing says what the product is not. A roadmap alone is how teams stay busy without a version anyone can use. If you only have time for one page, make it the PRD, and put three roadmap lines and the first slice's acceptance notes on that same page.
You can try FounderBrief when you want that page drafted from a description of the idea. The generator writes a PRD and a build plan: goals, non-goals, stories, requirements, constraints, and milestones. That is the PRD plus a sequence. It is not a full engineering spec of every screen, and it is not a multi-quarter roadmap. Treat the draft as a start, then cut it to the version you will actually build.
What are the common questions?
Can a roadmap live inside the PRD?
Yes, as a short later list, while you only have one version. Split it out when later bets need their own owners. Do not let the later list change the scope of the version you are building.
Who writes each document?
The founder or product owner writes the PRD and owns the roadmap order. The person building the slice writes or co-writes the spec, because they are the one who has to make the behavior precise. The founder still checks that the spec matches the PRD.
Which guides should you read next?
- How to write a PRD for a startup
Write a startup PRD before you build: user, problem, scope, non-goals, success metrics, and the technical constraints a builder needs.
- MVP planning checklist
An MVP planning checklist: the user, the one job, the steps, the non-goals, the success signal, and the build order — before you code.