How to Write a Product Requirements Doc
Without a Product Team
Most early-stage founders skip the PRD and go straight from idea to build. Engineers build the wrong thing. Timelines slip. The feature that ships isn’t what customers needed. A one-page PRD prevents all of that — and takes less than an hour to write.
- Why PRDs matter even with a 2-person team
- The one-page PRD format that works
- Writing the problem statement correctly
- Defining success before a line of code is written
- Scope decisions — what’s in, what’s out, and why
- Getting engineer buy-in before the build starts
- Using AI to write and stress-test your PRD
Why PRDs Matter Even With a 2-Person Team
The argument against PRDs at early stage: “we move fast, we talk constantly, we don’t need documentation.” This works up to about 3 people in the same room every day. Beyond that, it breaks down.
Without a written record, “what you want” shifts subtly between the conversation and the build. Features that seemed clear in a verbal briefing turn out to have assumptions that were never surfaced. Edge cases that seemed obvious to the founder weren’t obvious to the engineer. Priorities that felt settled get relitigated mid-build.
A one-page PRD doesn’t slow you down. It speeds you up by front-loading the decisions that would otherwise surface as surprises during or after the build.
The best PRD is the shortest document that leaves no ambiguity about what success looks like. If it requires a meeting to interpret, it needs to be rewritten.
The One-Page PRD Format That Works
Six sections, one page. Everything beyond this is either unnecessary context or a sign the feature isn’t well-defined enough to build yet.
Problem: What customer problem does this solve? Who has it? How do we know?
Context: Why now? What triggered this — a customer request, competitive pressure, a strategic decision?
Success metrics: How will we measure whether this worked? What number moves, and by how much?
Scope (in): What specifically are we building in this version?
Scope (out): What are we explicitly not building, and why?
Open questions: What decisions haven’t been made yet? Who owns resolving them and by when?
No user stories, no wireframes, no technical specs — those belong in separate documents if needed. The PRD is about the what and why, not the how.
Writing the Problem Statement Correctly
The most common PRD failure: a problem statement that describes the solution, not the problem. “We need to build a dashboard so users can track their pipeline” is a solution statement. “Hiring managers don’t know where each candidate is in the process, so they’re asking for status updates multiple times a day” is a problem statement.
The test: can you read the problem statement and imagine a different solution? If it already implies one specific answer, it’s not a problem statement.
A good problem statement also specifies who has it. Not “users are frustrated” — “hiring managers at companies with 5+ open roles simultaneously are frustrated.” The more specific the who, the clearer the what.
“I want to build [describe the feature]. Help me write a problem statement that: describes the pain without implying the solution, specifies exactly who experiences it and in what context, quantifies the cost of the problem where possible, and is no longer than 3 sentences. Then tell me: is my proposed feature the only solution to this problem, or are there alternative approaches I should consider before committing to build?”
Defining Success Before a Line of Code Is Written
The success metric is the most skipped section of any PRD, and the most important. Without it, every feature ships into a void — you can’t tell if it worked, so you can’t learn from it.
A good success metric is specific, measurable, and time-bound. “Improve engagement” is not a metric. “Increase the percentage of new users who complete their first scorecard within 7 days of signup from 23% to 40%, measured 30 days after launch” is a metric.
Define it before the build. Defining it after invites post-hoc rationalisation — picking the metric that makes the feature look good rather than the one that would have told you whether it worked.
“I’m building [describe the feature]. The problem it solves: [describe]. The users: [describe]. Help me define 1-2 specific, measurable success metrics. For each: what exactly are we measuring, what’s the baseline today, what would a successful outcome look like 30 days post-launch, and how would we measure it with the analytics we have. Avoid vanity metrics — I want metrics that tell me if the feature actually solved the problem.”
Scope Decisions — What’s In, What’s Out, and Why
The scope-out section is where PRDs save the most time. Explicitly listing what you’re not building does three things: forces you to make hard calls before build starts rather than during, gives engineers permission to push back on mid-build scope creep, and creates a backlog without letting it slow down the current release.
Format: “Not in this version: [specific thing]. Reason: [brief explanation]. Future consideration: yes/no.”
If you can’t write the scope-out section, you haven’t made the hard calls yet. Better to surface that before the build than two weeks in.
Getting Engineer Buy-In Before the Build Starts
Share the PRD with your engineer before any build decision is final. Not for approval — to surface what you don’t know. Engineers consistently identify ambiguities, edge cases, and technical constraints founders miss. A 30-minute PRD review before the build is worth five times that in avoided rework after it.
The question to ask: “Is there anything in this document you’d interpret differently from how I intend it?” This surfaces the assumptions that weren’t surfaced in the writing.
Using AI to Write and Stress-Test Your PRD
“Write a one-page PRD for this feature: [describe it]. Context: [what triggered this]. Target user: [describe]. Success looks like: [intended outcome]. Use these six sections: Problem, Context, Success Metrics, In Scope, Out of Scope, Open Questions. Keep it to one page — cut anything that doesn’t inform the build decision. Flag any section where my input isn’t specific enough to write clearly.”
“Here is my PRD: [paste it]. Review it as an engineer about to build this. What questions would you have that this document doesn’t answer? What assumptions am I making that might not be true? What edge cases haven’t I addressed? What’s the most likely thing to go wrong in the build based on how this is written? Be specific — I want gaps identified before we start.”
Get 50 more prompts for product, growth, and running a lean team — free.