A PRD (Product Requirements Document) is supposed to be the contract between "what you want built" and "what actually gets built." In practice, most PRDs are wish-list documents — a page of "the app should be fast, easy to use, and delight users" — that developers glance at, interpret however they interpret it, and deliver something that never quite matches what the founder expected.
This has always been a problem. In 2026, with AI coding tools able to generate large amounts of code from a prompt, the problem has gotten sharper: a bad PRD now produces a large amount of bad code, fast. The founders who succeed with AI tooling aren't the ones who write clever prompts. They're the ones who write clear specs.
Here's the PRD structure I've been using for years and continue to use now, whether the builder is a human developer, an agency, or an AI coding agent.
The single most common PRD mistake
Before the structure — the mistake that kills 80% of PRDs before they start:
Writing a PRD that says WHAT the product does but not WHY someone would use it or WHAT they'd do differently as a result.
A PRD that says "users can create tasks, mark them complete, and receive daily reminders" is describing a to-do app that already exists ten thousand times over. There's nothing in there that tells the builder what tradeoffs to make. Should reminders be aggressive or gentle? Should tasks be shared or private? Should the interface prioritize speed of entry or richness of options?
Every specific decision the developer will have to make in the code — and there are hundreds — needs a guiding principle to make it against. That principle comes from the user and the outcome, not from the feature list.
Fix: every PRD starts with two sections that most PRDs skip: the user, and what they'll do differently. Everything after that is calibrated against those two anchors.
The PRD structure that actually gets built
Below is the structure I recommend. Copy it, use it as a template, adapt sections that don't fit your project. Every section serves a specific purpose — cutting one has a cost, not just less writing.
Section 1: The user in one sentence
"A [role] who is trying to [job to be done] because [motivation], and who currently [current painful workaround]."
Example: "A restaurant owner with 5-20 staff who is trying to build a weekly work schedule because current spreadsheet-based scheduling causes constant conflicts and overtime, and who currently rebuilds the schedule from scratch every week."
This one sentence should force clarity. If you can't fill in every clause, you don't yet know your user well enough to build the product. Stop and go talk to five of them.
Section 2: The outcome — what changes in their life
"After using this product for [timeframe], the user will [measurable behavior change]."
Example: "After using this product for two weeks, the restaurant owner will spend under 30 minutes per week on scheduling (down from 2-3 hours) and receive zero staff complaints about scheduling conflicts."
This is the outcome that defines success. It's what you'll measure against later. If a feature idea doesn't visibly contribute to this outcome, it doesn't belong in the first version.
Section 3: The core user journey (5-7 steps, no more)
Not screens. Not features. The actual sequence of things the user does to get from "I need to do this" to "I'm done." Written in plain English:
1. User opens the app and sees this week's draft schedule. 2. User adjusts shifts by dragging staff between time slots. 3. User marks any staff conflicts (vacation, unavailability) that were flagged. 4. User publishes the schedule; staff receive notifications with their shifts. 5. Staff can request swaps; user approves or denies from a notifications panel. 6. Once a shift is confirmed, it appears on staff's personal calendars. 7. End of week, user sees a summary of hours worked vs planned.
This journey is the SPINE of the PRD. Every feature is either on the journey or supports the journey. Anything else is out of scope for the first version.
Section 4: Must-haves vs nice-to-haves (be brutal)
Three columns:
Must-have (in first version):
- Every step from Section 3
- Anything a real customer literally cannot use the product without
Nice-to-have (later):
- Features that improve the experience but aren't blocking
- Everything that sounds cool but isn't on the journey
Explicitly out of scope:
- Adjacent problems you'll be tempted to solve but won't
- Integrations you'd love to have but aren't essential to launch
The third column is the most important one. "Out of scope" written down is the only defense against feature creep once the build starts. Without it, every conversation with the developer becomes a mini-negotiation about whether X is included.
Section 5: The single hardest technical decision
Every non-trivial product has one decision that dominates the technical direction. Real-time or polling? Multi-tenant or single-tenant? Native or web? Offline-capable or online-only?
Name yours. State your position with your reasoning. State the tradeoffs of the alternative.
Example: "We will build this as a mobile web app (PWA), not a native iOS/Android app. Reasoning: restaurant owners already have this on their phone via a bookmarked link; app store distribution slows shipping by 2-3 weeks per release and doesn't add value for internal tools. Tradeoff accepted: no offline mode initially; requires internet connection for all operations."
This section prevents the developer from making this decision silently in a way you don't like. It also lets any AI coding tool you use anchor to your architectural direction rather than defaulting to whatever's most common in its training data.
Section 6: Success criteria — how you'll know it worked
Not the outcome (Section 2) — that's the user's outcome. This is YOUR outcome as a product owner:
Launch criteria (before shipping to real users):
- Every step in Section 3's journey works end-to-end without errors
- At least 3 test users completed the journey without needing help
- Performance: any page loads in under 2 seconds on 4G mobile
- Data: no user data is lost across sessions
30-day success criteria (after launching):
- X% of signed-up users complete the journey at least once
- Y% of users are still active in week 4
- Feature Z is used by at least Q% of users (proves it's actually needed)
Without these, "done" becomes subjective. With them, "done" is testable.
Section 7: Explicit constraints
Non-negotiables the builder needs to know about upfront:
- Timeline: [date] hard, [date] preferred
- Budget: $X hard cap, $Y preferred
- Regulatory or legal: [e.g. GDPR, HIPAA, industry-specific]
- Existing systems that must be integrated with: [list]
- Existing systems that must NOT be touched: [list]
- Technology preferences or constraints: [only if you have a real reason — otherwise leave open]
The last point matters. A common bad PRD constraint is "must be built in [framework name]" written by a founder who doesn't actually have a technical reason for it. Unless there's a real constraint (existing team, existing codebase, existing deployment infrastructure), leave technology choices to the builder — they'll make better decisions than you will about tools you don't use.
Section 8: What we're NOT going to worry about (yet)
This section is where you park the things you know will be needed eventually but aren't in scope now. Writing them down does two things: (a) reassures you they're not forgotten, and (b) resists the temptation to build them now.
Example:
- Analytics dashboards (v2)
- Multi-language support (v2)
- Admin roles beyond the current user (v3)
- White-label or reseller version (much later)
- Native mobile apps (only if traction proves the web version isn't enough)
PRD templates for AI coding tools specifically
If you're going to hand this PRD to an AI coding tool (Claude, ChatGPT, Cursor, etc.) instead of a human developer, add these two sections at the end:
Section 9 (AI-specific): Preferred stack
"Please build this using [Next.js 16 / React 19 / TypeScript / Tailwind CSS / Cloudflare Workers / D1] unless you have a strong reason for an alternative. If you deviate, explain why in comments."
AI tools default to whatever was most common in their training data unless told otherwise. If you don't specify, you'll get an outdated stack or an inconsistent one across the codebase.
Section 10 (AI-specific): Guardrails
"When you have ambiguity about a decision — for example, whether a feature is in scope, or whether an edge case matters — pause and ask, don't guess. When you make a technical decision that's not obviously required by the PRD, add a brief comment explaining your reasoning. Never introduce dependencies I haven't approved."
This section is the difference between an AI that ships you working software and an AI that ships you 5000 lines of code that mostly works with three subtle bugs you'll find in production.
The two-page rule
If your PRD is longer than two pages, you're either specifying too much detail (leave implementation to the developer) or including things that belong in a separate document (design mockups, technical architecture, marketing plans).
A PRD is the ONE thing that says what needs to be built and why. If it can't do that in two pages, either the product is too big to build in one go, or the spec isn't yet clear enough to hand off.
Common PRD anti-patterns
- Feature-list-as-PRD. A bulleted list of 40 features with no user, no journey, no priorities. Guarantees a product that does 40 things badly.
- Design-mockup-as-PRD. Beautiful screens with no explanation of behavior. Developers will build what the screens show and guess at everything the screens don't show.
- User-story-flood. 200 user stories in the format "As a X I want Y so that Z." Individually clear, collectively unmaintainable. Better: one clear journey with 200 lines of code, not 200 stories with 30 lines each.
- The living document that changes daily. A PRD that's updated every few days becomes noise instead of signal. Version it. Freeze it before development starts. Change only through explicit change requests.
- The PRD written after the meeting. If the PRD is written to describe what someone else already told the developer to build, you're not writing a PRD — you're writing meeting minutes.
The template you can steal
# [Product name] — Product Requirements v1.0
Author: [name] Date: [date] Version: [1.0]
## 1. User (one sentence)
A [role] who is trying to [job] because [motivation], and who currently [workaround].
## 2. Outcome
After using this product for [timeframe], the user will [measurable behavior change].
## 3. Core user journey (5-7 steps)
1. [step]
2. [step]
...
## 4. Scope
### Must-have (v1):
- [item]
### Nice-to-have (later):
- [item]
### Explicitly out of scope:
- [item]
## 5. Key technical decision
We will [decision]. Reasoning: [why]. Tradeoff accepted: [what we're giving up].
## 6. Success criteria
### Launch criteria:
- [criterion]
### 30-day success criteria:
- [criterion]
## 7. Constraints
- Timeline: [hard date] / [preferred date]
- Budget: [hard cap] / [preferred]
- Legal/regulatory: [list]
- Systems that must be integrated: [list]
- Systems that must NOT be touched: [list]
## 8. Deliberately deferred
- [feature] — reason to skip in v1
- [feature] — reason to skip in v1
## 9. Preferred stack (if handing to AI or agency)
[stack]
## 10. Guardrails (if handing to AI)
Pause and ask when ambiguous. Comment technical decisions. No new dependencies without approval.What to do this week
- Write (or rewrite) the PRD for whatever project you're currently building. Use the template above.
- Show it to the person who'll build it BEFORE they start. Their questions will reveal what's still ambiguous. Answer those questions in the PRD, not in Slack later.
- If you're staring at an existing product that got built without a clear PRD, run the refactor vs rewrite framework — most "we need to rewrite" situations are actually "we need to write down what this should have been."
- Before you hire anyone for the build, use the 12 questions for developers and the freelancer/agency/in-house decision tree — the PRD is only as good as the person who reads it.
- The free MVP planner tool on this site generates a first-draft version of this structure from a rough idea — good starting point if you're staring at a blank page.
A PRD isn't documentation. It's the shape of the product before it exists. If you can't write it clearly, you can't build it clearly. Everyone who ships products consistently does some version of this — even if they don't call it a PRD.
---
If you'd like me to review your PRD before you hand it off to a developer, an agency, or an AI tool, reach out via the contact page with the doc and a note about what you're building. I'll spend 30 minutes on it and tell you what I'd change before you commit engineering time to it.