Is this PRD template free to copy?
Yes. Copy the sections on this page into your own document. You do not need an account to use the outline. FounderBrief can also draft a filled version from your idea, and the first generation is free.
Guide
PRD template for startups
A free startup PRD template is a short document you can copy: the user and problem, the outcome of the first version, the core flow, explicit non-goals, user stories, success metrics, technical constraints, and the order you will build it. Fill those sections before you hire or open an editor. Leave stack names until the scope is stable.
Want to try FounderBrief?
Describe the idea and get a PRD and build plan. No card required for the first one.
Try FounderBriefWhat belongs in a startup PRD template?
A template is a fixed outline so the next idea does not get a new structure. The sections that earn a place on a first version are the user, the problem as it exists today, the outcome you could check, the steps in that outcome, the refusals, the stories for those steps, the signal that it worked, the constraints a builder cannot guess, and the order of the work.
Copy the blocks below into your own doc and replace every bracket. If a bracket is still empty when you want someone to build, that section is not done. The same outline is explained as prose in the guide on how to write a PRD for a startup. This page is the blank you fill. PRD vs spec vs roadmap is the page to read if you are unsure which document you are writing.
How do you describe the user and the problem?
Name one person. A market is not a user. "Small clinics" is a market. "The office manager who confirms locum shifts by texting three group chats" is a user. Write the job they already have, the workaround they use this week, and the tools in that workaround. If you cannot picture the afternoon this happens, you are guessing, and the rest of the template will invent features to cover the guess.
Write the problem as the gap between that workaround and the result they wanted. Keep it to the gap this version closes. A second problem is a second product. Park it under non-goals. The outcome sentence has to be something a stranger could check. "The manager sends one link and the locum confirms without a phone call" can be tested. "Delight clinics" cannot. Copy this block and replace the brackets.
User, problem, and outcome
Primary user: [one person, and the job they already have] What they do today: [the workaround, including the tools] What is broken: [the gap this version closes] Outcome: When this version is done, the user can [observable result]. We will know it worked if: [a signal you could check]
What should scope and non-goals say?
Scope is the core flow plus the refusals, written next to each other. List the steps the user takes, in order, from the moment they start the job to the moment it is finished. Three to seven steps is enough for a first version. Each step should say what the user does and what the product does back. "Simple dashboard" is not a step. "The manager sees today's unfilled shifts and sends a link" is a step.
Non-goals are how the template stays buildable. Write them as refusals: no team roles, no native app, no reporting beyond one list. Every feature you refuse is time you can spend on the path that proves the idea. When someone later asks for an item on that list, the answer is "not this version," which is a decision you already wrote down. Do not hide a second product inside an adjective.
Core flow and non-goals
Core flow: 1. [step the user takes, and what the product does] 2. [step] 3. [step] Non-goals: - [this version will not do this] - [this version will not do this]
How should the user stories be written?
Write a story only for a step you already listed. The form is a person, an action, and a result: "As the office manager, I can send a booking link, so the locum confirms without a phone call." If you cannot name the result, the line is a feature wish and it should come out. Add one acceptance line under any story that could be misread, so a builder does not invent a signup wall you did not ask for.
A handful of stories is the point. A backlog of forty stories means the template became a parking lot. Cut until each story maps to a step in the flow. Skip settings, empty states, and admin screens unless the job fails without them.
Story
As [user], I can [action], so that [result]. Done when: [what a reviewer can check]
Which constraints belong in the template?
Constraints are facts a builder cannot infer from the stories. Platforms, how someone signs in, whether money moves, which records you must keep, and which other systems have to be touched. Write "not in this version" when the answer is none. Silence gets filled with assumptions, and assumptions become extra weeks. A risk you already know belongs here too, in one or two lines: a permission you do not have yet, or data that includes phone numbers.
Leave vendor and framework names out until the scope is stable. "Card payments on the web" is a constraint. A particular processor is a choice that follows from it. The same goes for hosting and UI kits. The template's job is to make that choice smaller, not to make it for you. If you do not know a line yet, write the question instead of inventing an answer.
Constraints
Platforms: [web, mobile, or both] Sign-in: [method, or none in this version] Payments: [what is charged, or not in this version] Data we must store: [records] Integrations: [systems, or none] Risks: [permission, privacy, or dependency you already know]
How do you turn the template into a build order?
Close with the sequence. The first slice should be the shortest path that lets the user finish the job, even if it is rough. Later slices are what you will do only if the first one is actually used. If that first slice is already a quarter of work, the outcome is too big. Shrink the flow. Do not shrink the calendar and hope. Read the filled template once as if you were the person building it. Every bracket should be gone, and every non-goal should still be there.
Then hand it over. You can try FounderBrief if you want a first draft of these sections from a short description of the idea. The first generation is free and does not ask for a card. Treat that draft as this template filled in once: delete any line you cannot defend before anyone builds it.
Build order
1. [shortest slice that lets the user finish the job] 2. [what depends on that slice] Later, not now: [explicitly deferred]
What are the common questions?
How long should a filled startup PRD be?
Long enough that a builder can start, and short enough that you will reread it. The sections in this template are enough for a first version. If it starts reading like a company strategy memo, move the later bets out.
Should the tech stack go in the template?
Write constraints: platforms, sign-in, payments, data, and integrations. Choose specific tools after those lines are stable, so the stack serves the product.
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.
- PRD vs spec vs roadmap
A PRD says what this version is and why. A spec says how one slice behaves. A roadmap orders later bets without designing them.