Writing PRDs

I’ve seen the same story play out dozens of times across our client projects. Someone has an idea. They get excited. They describe it in a few emails, maybe a call. The team starts building. Three weeks in, the designer asks “wait, does this also need to work on mobile?” The engineer says “nobody told me about the payment integration.” The client says “I assumed that was obvious.” And now five people discover they’ve been building five different products.

This is the problem a PRD solves. Not with bureaucracy, not with 50-page documents nobody reads. With clarity. A PRD forces you to decide what you’re building, for whom, why it matters, what success looks like, and — critically — what you’re NOT building, before anyone writes a line of code.

What a PRD is

A Product Requirements Document defines what you’re building, for whom, why, and how you’ll know it worked — from the user’s perspective. The key distinction: a PRD describes what the product does and why, not how it’s built. “Users must be able to reset their password via email” is a PRD-level requirement. “Use Redis for session storage with a 30-minute TTL” is a technical specification. Different audiences, different documents.

PMI’s research found that 47% of unsuccessful projects fail because of inaccurate requirements. Not bad code. Not slow servers. Requirements. The cost of discovering a problem escalates dramatically the later you find it. A misunderstanding caught during PRD review costs a conversation. Caught during testing, it costs days of rework. After launch? Reputation and revenue.

Not every project needs a full PRD. Full PRD for multiple teams, customer-facing launches, regulatory requirements, complex integrations. One-page brief for MVPs, internal tools, small teams. Skip the document for bug fixes and config changes. The rule: escalate formality with risk.

The anatomy

Problem statement

The most important section. A good one answers: who has this problem, what are they doing today, what’s painful, and what evidence do we have?

Bad: “We need a better onboarding experience.”

Good: “New users complete setup at a 34% rate. Post-setup surveys identify two friction points: configuring 14 settings before seeing value, and confusion about which integrations are optional. Users who complete setup retain at 3x. Competitors offer a wizard that reaches first value within 5 minutes.”

The second version gives the team something concrete to aim at.

Goals and non-goals

Goals are measurable outcomes. Non-goals are things you’re explicitly choosing not to do. The non-goals section is the one teams regret omitting. Without it, silence is interpreted as inclusion. “Are we also doing X?” defaults to “I guess so” unless X is explicitly excluded.

I wrote a 50-page PRD for a multi-tenant dental platform with an entire section called “Explicit Exclusions” listing billing, recruiting, financial dashboards, embedded LMS, native desktop apps, offline mobile, and video conferencing. Every single one would have been assumed in scope without that list.

User stories and acceptance criteria

User stories describe features from the user’s perspective: “As a practice owner, I want to see monthly production compared to my goal, so that I know whether we’re on track.”

Every story needs acceptance criteria — specific, testable conditions that define “done.” Without them, “done” is subjective. The best format is Given/When/Then: “Given a practice owner is logged in with goal data, when they view the dashboard, then they see a progress bar showing current production vs target, with green/yellow/red thresholds.” Now engineering knows what to build. QA knows what to test. No ambiguity.

Non-functional requirements

Performance, security, accessibility, reliability, compliance. These shape the entire architecture, and they’re where the most expensive rework originates when ignored. Most teams skip them entirely. Then they discover the page takes 8 seconds to load, or a security audit reveals no logging, or an enterprise prospect asks about accessibility. We had a client who wanted enterprise SSO six months after launch. The auth system wasn’t designed for it. A two-week feature became a two-month refactor.

Out of scope

Format each exclusion with a reason. “Custom calendar engine — V1 uses Calendly integration; custom engine is V2.” Without the reason, exclusions feel arbitrary. With the reason, they’re defensible decisions.

The rest

Assumptions and dependencies — things you believe true that would change the spec if wrong, and external things the project relies on. Each dependency needs an owner. Risks with probability, impact, and mitigation. Success metrics with baseline, target, timeframe, and measurement method. “Increase user engagement” is not a metric. “Increase WAU from 340 to 600 within 90 days, measured via Mixpanel” is. Open questions — a living table with owners and target dates that forces closure.

The mistakes that kill PRDs

After writing dozens and reviewing hundreds, the patterns repeat. Here are the ones I see most.

Vague requirements. “The system should be fast.” Fast compared to what? Measured how? Under what conditions? Every requirement must be specific and testable. “Page loads under 2 seconds at the 95th percentile on a 3G connection” is testable. “Fast” is a wish.

Prescribing implementation instead of behavior. “Use WebSockets for real-time messaging” locks engineering into a technology choice before they’ve evaluated alternatives. Describe the behavior instead: “New messages appear within 5 seconds without manual refresh.” Let engineering choose the best implementation.

No out-of-scope section. The single most common mistake. Everything not explicitly excluded will be assumed included by someone on the team. Always name the 4-5 things most likely to be confused with in-scope features, with reasons for each exclusion.

No acceptance criteria. Without them, “done” is a matter of opinion. The developer thinks it’s done. The PM thinks it’s not. QA doesn’t know what to test. Everyone argues.

Scope creep through silence. It never starts big. It’s always “while we’re building the events page, can we also add a waitlist?” Then “can the waitlist send SMS?” Then “can we add a custom SMS editor?” I watched a client ask for “just one more field” on a form seven times over three months. Each trivial on its own. Together, they tripled validation complexity and required a schema migration nobody had planned for. Three weeks over. The fix: treat the in-scope list as a boundary. New requests get logged, estimated, and traded against existing scope. “Adding waitlist SMS pushes the timeline two weeks. Do we cut something else, or extend the deadline?”

Ignoring non-functional requirements. The feature works perfectly in dev. Then it hits 100 concurrent users and the database melts. Or a security audit reveals no logging. Every PRD needs at least one line per NFR category: performance, security, accessibility, reliability, compliance. Even “not applicable” is better than silence.

Missing edge cases. PRDs overwhelmingly describe the happy path, but 80% of real code handles failures. For every happy path: empty state, loading state, error state, boundary conditions (zero items, maximum items), and concurrent access.

PRDs nobody reads. A 50-page document with no structure is one that sits unread. Lead with a TL;DR. Match length to risk — a two-week feature doesn’t need 30 pages.

Underspecifying integrations. “Integrate with Stripe for payments” hides weeks of work. Which API version? How do you handle declined cards? Refunds? Webhook reliability? Rate limits? Currency support? For each integration, specify: API version, auth model, key data mappings, error handling, retry strategy, and fallback behavior.

No prioritization. A flat list of 23 requirements with no priority means engineering decides what to cut under time pressure — and their priorities may not match the business’s. Use MoSCoW (Must/Should/Could/Won’t) with Must-haves capped at 60% of estimated effort.

Not involving engineering early. Writing a PRD in isolation and “handing it over” guarantees surprises. A 30-minute scoping conversation with a tech lead catches issues that would surface weeks later as blockers.

No launch criteria. “We’ll ship when it’s ready” slides under pressure. Define a go/no-go checklist: all P0 bugs closed, performance benchmarks met, security review complete, analytics verified in staging, rollback plan tested. This separates the “ship it” decision from opinions.

Confusing features with solutions. “Add a Slack integration” is a solution. The underlying need might be “notify me immediately when a high-priority issue is assigned.” Slack is one possible channel. Use Jobs-To-Be-Done framing.

Not accounting for data migration. The new model ships and nobody thought about the 4 million existing records that need migrating. Include: current state, target state, migration strategy, rollback plan, and estimated downtime.

Treating the PRD as frozen. A frozen PRD punishes learning. An infinitely fluid one punishes planning. The answer: living but disciplined. Changes are allowed, but dated, attributed, justified, and communicated.

Using Claude to write PRDs faster

Writing PRDs from scratch is tedious. Writing them well requires thinking through dozens of considerations. This is exactly where Claude excels — not replacing your judgment, but accelerating the mechanical parts.

The interview pattern

The single most effective technique: have Claude interview you. Instead of trying to write a PRD from scratch (which requires knowing the format), tell Claude to act as a senior PM conducting a requirements interview. Ask one question at a time. Probe vague answers — “a lot of users” becomes “how many specifically?” After 12-15 questions, summarize and confirm before drafting.

The interview takes 20 minutes. The draft takes 60 seconds. I spend another 30 minutes refining. What used to take a day takes under an hour. The first time I tried this, the result was better than a PRD I’d spent six hours writing manually. Not because Claude is smarter. Because the interview structure forced me to answer questions I would have unconsciously skipped.

This is how I draft PRDs for new client projects now. It’s also the technique I recommend most for non-technical founders who know their problem deeply but don’t know PRD format.

The multi-lens critique

For existing PRDs, have Claude review through four perspectives in sequence. Senior engineer: is this buildable? What’s ambiguous? What’s missing that would block implementation? Security engineer: authentication gaps, OWASP risks, compliance requirements. Accessibility specialist: WCAG 2.2 AA compliance, keyboard navigation, screen reader support. QA lead: can every requirement be tested? What edge cases are missing? Then a consolidated verdict: ship, revise, or major rework.

The pre-mortem

The most underrated technique. Have Claude assume the product failed catastrophically 12 months after launch and write the post-mortem — covering product, technical, market, organizational, and scope failure. Be specific, not abstract. Gary Klein’s research showed pre-mortems increase failure identification by roughly 30%.

Generating user stories

Feed Claude your functional requirements and have it generate structured user stories with Given/When/Then acceptance criteria, INVEST criteria evaluation, top edge cases per story, relative complexity estimates, and MoSCoW priority with justification. Then have it audit for internal consistency: do any non-goals contradict stated goals? Can all acceptance criteria pass while success metrics still fail?

The pitfalls

Claude makes PRDs faster. It doesn’t make them automatically good. Watch for hallucinated user needs when you don’t provide real research. Fabricated statistics (“Studies show 73% of users…” — did you provide that stat?). Over-specification too early when you don’t have enough information. Sentences that sound professional but are generic enough for any product. And sycophancy — ask “is this PRD good?” and Claude says yes. Instead, use adversarial framing: “Your only job is to find weaknesses. What are the five assumptions this PRD depends on that would collapse it if wrong?”

Frameworks worth knowing

Lenny Rachitsky’s one-pager — Problem, why now, success metrics, solution, scope/non-goals, risks, timeline. Start here. Expand only when needed.

Amazon’s PR/FAQ — Write the press release first, as if the product already launched. Then the FAQ. The ritual matters: 15-20 minutes of silent reading, then structured critique. Most should be rejected. That’s the point.

Shape Up pitch — Problem, appetite (a constraint, not an estimate), solution at the right abstraction level, rabbit holes, and no-gos. Deliberately low-fidelity.

Atlassian’s PRD blueprint — The industry-standard agile template. Best for enterprise projects with multiple teams and regulatory requirements.

PRDs for client work

This distinction matters because I live in both worlds. When building your own product, the PRD is a planning tool. When building for a client, it’s also a contractual boundary. The in-scope and out-of-scope lists tie directly to the statement of work. “That’s in our V2 exclusions list. We can add it as a change order.”

I learned this the expensive way on our third client project. No change order process, no explicit exclusions. The client assumed everything mentioned verbally was in scope. We assumed only the written spec counted. That argument nearly cost us the relationship. Now every client PRD has a responsibilities matrix, change order process, sign-off fields, and assumptions about client-provided materials before anyone writes code.

PRDs for AI features

If the feature involves an LLM integration, a conventional PRD isn’t enough. AI features are probabilistic, not deterministic. Add: model selection with version pinning and fallback, an eval strategy (50-500 test inputs with scoring rubrics — the eval pass rate IS the acceptance criterion), cost budget per query and per month, fallback behavior when the model times out or returns errors, safety guardrails including PII redaction and prompt injection defense, and human-in-the-loop confidence thresholds.

The bottom line

A PRD is not bureaucracy. It’s a thinking tool. The act of writing one forces you to confront decisions you’d otherwise defer, identify gaps you’d otherwise miss, and align stakeholders who’d otherwise build different products.

In 2026, AI changes the economics of PRD writing but not the discipline. Claude can interview you, draft in 60 seconds, critique through four expert lenses, and find gaps you missed. What used to take a day takes an hour. But the judgment — which problems matter, which solutions fit, what to include and exclude — that’s still yours.

---

This is the free web edition of Chapter 8. The full text — with complete PRD templates, Claude prompt libraries, acceptance criteria examples, the full 20-mistake checklist with fixes, and real PRD excerpts from client projects — is available in 42: The AI Builder’s Stack, coming Q3 2026 on Amazon in hardcover, paperback, and digital.