How long should a startup PRD be?
Long enough that a builder can start, and short enough that you will reread it. A few pages covering problem, scope, non-goals, stories, metrics, and a phased plan is enough for an MVP.
Guide
Write a startup PRD before you build. Name the user, the problem, the outcome, and the smallest product that can prove it. Include the core flow, explicit non-goals, success metrics, and technical constraints. Leave stack choices until the scope is stable. A good PRD is short enough that a builder can start without a meeting.
Describe the idea and get a PRD and build plan. No card required for the first one.
Generate your first PRD freeOpen with one sentence: who this is for, what they are trying to finish, and what is broken today. If you cannot name a person and a job, the rest of the document will wander.
Then write the outcome of the first version in a way you could check. “Users can request a pickup, pay, and see the rider” is a PRD. “Delight customers” is not.
List what the first release will not do. Non-goals are how a startup PRD stays buildable. Every feature you defer is time you can spend on the path that proves the idea.
Write the core flow as steps a user takes, then the requirements that make those steps work. Stories should be testable: a person, an action, and a result.
Note platform, auth, payments, data you must store, and anything that is risky. That is the technical half of the plan. It should follow the scope, not replace it.
Close with phases: what ships first, what it depends on, and how you will know the version worked. FounderBrief drafts this from a short idea description so you can edit a plan instead of staring at a blank page.
Long enough that a builder can start, and short enough that you will reread it. A few pages covering problem, scope, non-goals, stories, metrics, and a phased plan is enough for an MVP.
The user and problem, the outcome of the first version, the core flow, explicit non-goals, success metrics, technical constraints, and the order you will build it.
Write constraints first: platforms, auth, payments, and data. Choose specific tools after the scope is stable, so the stack serves the product instead of the other way around.