Writing a PRD

The Product Requirements Document is the most misunderstood artifact in product management. In theory, it is the canonical document that describes what the team is building and why. In practice, most PRDs are 20-page documents that nobody reads, written to satisfy a process rather than to inform a team.

A good PRD is short. It answers the questions the team actually has. It gets read. Everything else is waste.

What a PRD Is For

A PRD has exactly one purpose: to create shared understanding between the PM, engineering, and design about what they are building, for whom, and why. If the team already has shared understanding (you are a 4-person startup and you all sit at the same table), you might not need a PRD at all. If the team is distributed, cross-functional, or working on something complex, you need a written artifact that aligns everyone.

Questions a good PRD answers:
  - What problem are we solving?
  - Who has this problem?
  - How will we know if we solved it?
  - What are we building? (scope)
  - What are we NOT building? (scope boundary)
  - What are the open questions?

Questions a good PRD does NOT answer:
  - How should the system be architected?
  - What technology stack should we use?
  - What should the exact pixel layout be?
  - How should the database be structured?

The Structure That Works

After writing and reading hundreds of PRDs, this is the structure that consistently produces documents that engineers actually read.

1. Problem Statement (3-5 sentences)

What is the problem? Who experiences it? Why does it matter now?

Example:
  Enterprise customers with 50+ team members cannot effectively
  manage user permissions. Currently, account admins must set
  permissions individually for each user, which takes approximately
  2 hours per month for a 100-person team. Three of our top 10
  accounts have cited this as a reason they may not renew. Support
  receives 30+ tickets per month related to permission confusion.

This is the most important section. If you cannot write a clear problem statement in under five sentences, you do not understand the problem well enough to write a PRD.

2. Success Metrics (3-5 bullets)

How will we know this worked? These should be measurable and time-bound.

Example:
  - Reduce average time to configure team permissions from 2 hours
    to 15 minutes within 30 days of launch
  - Decrease permission-related support tickets by 60% within 60 days
  - Achieve 80% adoption among enterprise accounts within 90 days
  - Zero "we might not renew" signals related to permissions in the
    next renewal cycle

Pick metrics that directly measure whether the problem was solved, not vanity metrics that make the feature look good.

3. User Stories (5-10 stories)

Who does what and why? Keep them focused and realistic.

Example:
  - As an account admin, I want to create permission groups so that
    I can assign permissions to 20 people at once instead of
    individually.

  - As an account admin, I want to see which permissions each user
    has so that I can audit access without opening each profile.

  - As a team lead, I want to request permission changes for my team
    so that I don't have to go through the admin for every new hire.

  - As a new team member, I want to have appropriate permissions when
    my account is created so that I can start working immediately.

  - As a security officer, I want to see a log of permission changes
    so that I can investigate access-related incidents.

4. Scope: In & Out

This is where most PRDs fail. They describe what is in scope but never describe what is out of scope. The "out" section is more important because it prevents scope creep and sets expectations.

In scope:
  - Permission groups (create, edit, delete, assign users)
  - Bulk permission assignment via groups
  - Permission audit view (who has what)
  - Permission change log
  - Role templates (predefined permission sets for common roles)

Out of scope:
  - Custom permission creation (users work with predefined
    permissions only in v1)
  - Cross-account permissions (each account is isolated)
  - API access for permission management (future phase)
  - Migration tool for existing permission configurations
    (manual migration with support assistance)
  - SSO-based automatic permission assignment (depends on SSO
    integration, separate initiative)

The "out of scope" list prevents the team from gradually expanding the project. When someone says "should we also add API access?" the PRD already answers: no, that is out of scope for this phase.

5. Open Questions

Every PRD has unknowns. Listing them explicitly is better than pretending they do not exist.

Open questions:
  - Should permission changes take effect immediately or require
    approval? (Need input from security team)
  - What happens to a user's permissions when they are removed from
    a group? (Revoke immediately or grandfather?)
  - Do we need to notify users when their permissions change?
    (Design to explore)
  - What is the maximum group size? (Engineering to advise on
    performance implications)

Open questions are not a sign of an incomplete PRD. They are a sign of an honest one. The team will answer these questions during design and development.

6. Mockups & References (links)

Do not embed detailed mockups in the PRD. Link to them. The PRD is for requirements and context. The mockups are a separate, evolving artifact.

References:
  - Design mockups: [link to Figma]
  - User research findings: [link to research doc]
  - Competitive analysis: [link to analysis]
  - Technical spike results: [link to engineering doc]

What Engineers Actually Want

I have asked dozens of engineers what they need from a PRD. The answers are remarkably consistent.

Engineers want:
  1. Clear problem context (why are we doing this?)
  2. Explicit scope boundaries (what are we NOT building?)
  3. Success metrics (how do we know when we're done?)
  4. Edge cases acknowledged (even if not fully resolved)
  5. Open questions identified (so they know what's still uncertain)
  6. Links, not inline content (keep the PRD short, link to details)

Engineers don't want:
  1. Implementation suggestions (they'll figure out the how)
  2. Technology choices (unless there's a business constraint)
  3. 20 pages of background (one paragraph of context is enough)
  4. Jargon-heavy business justification (plain language wins)
  5. Requirements that change silently (version the document)

The PRD that gets read is the one that respects the reader's time. If your PRD is longer than two pages (excluding links), it is too long. Cut ruthlessly.

PRD Anti-Patterns

The Novel

A 15-page document with market analysis, competitive research, user personas, technical considerations, and a project timeline. Nobody reads it. The PM spent a week writing it and the engineer skimmed it in five minutes. The length signals thoroughness but delivers confusion.

The Spec Masquerading as a PRD

A document that specifies exact UI layouts, database schemas, and API contracts. This is a technical specification, not a product requirements document. PRDs describe what and why. Specs describe how. Both are useful. They should not be the same document.

The Living Document That Never Stabilizes

A PRD that changes daily as the PM thinks of new ideas. Engineers cannot build against a moving target. The PRD should be relatively stable once development begins. Major changes should be versioned and communicated explicitly.

The Template-Driven PRD

A PRD written to fill out a template rather than to communicate clearly. Every section is filled in because the template requires it, even when the section adds no value. The best PRDs ignore template sections that are not relevant and add sections that are.

The PRD Process

The PRD should not appear fully formed. It should evolve through conversation.

PRD lifecycle:

1. Draft (PM writes alone):
   Problem statement, initial scope, success metrics.
   Takes 1-2 hours.

2. Review with design:
   Refine user stories. Identify UX questions.
   Design may start exploring concepts.

3. Review with engineering:
   Reality-check scope. Identify technical risks.
   Refine "in/out" boundaries. Surface open questions.

4. Finalize:
   Incorporate feedback. Publish to the team.
   Link to design mockups (which may still be evolving).

5. Update as needed:
   During development, update the PRD when scope decisions
   are made (not when scope is being discussed).
   Version changes: "v1.1: Removed cross-account permissions
   based on eng complexity assessment."

Versioning

When the PRD changes after development starts, make the change visible.

Change log:
  v1.0 (Jan 15): Initial PRD
  v1.1 (Jan 22): Removed API access from scope (eng estimate: 6
                  weeks, deferred to phase 2)
  v1.2 (Feb 3):  Added notification requirement based on user
                  research findings

Real-World Example: Abbreviated PRD

PRD: Team Permission Groups
Author: [PM name]
Last updated: 2025-03-15 (v1.1)

Problem:
  Enterprise admins manage permissions individually. A 100-person
  team takes ~2 hours/month. 3 top accounts cite this as a churn
  risk. 30+ support tickets/month.

Success metrics:
  - Permission setup time: 2 hours -> 15 minutes (30 days post-launch)
  - Support tickets: -60% (60 days)
  - Enterprise adoption: 80% (90 days)

User stories:
  [5 stories as described above]

In scope:
  Permission groups, bulk assignment, audit view, change log,
  role templates.

Out of scope:
  Custom permissions, cross-account, API access, migration tool,
  SSO-based assignment.

Open questions:
  [4 questions as described above]

References:
  [Links to Figma, research, competitive analysis]

This fits on one page. An engineer can read it in three minutes and know exactly what they are building, what they are not building, and what is still uncertain. That is a good PRD.

Common Pitfalls

Writing the PRD after development starts. The PRD is a planning tool, not a documentation artifact. Writing it after the fact is CYA, not product management.
Not including "out of scope." Without explicit exclusions, scope expands organically. Every "can we also add..." that was not anticipated is a scope boundary that was not drawn.
Treating the PRD as a contract. The PRD is a communication tool, not a legal document. It should enable good decisions, not constrain them. If the team learns something during development that changes the requirements, update the PRD.
Writing PRDs for tiny features. A one-line bug fix does not need a PRD. A two-day feature with clear scope might need a paragraph, not a document. Match the formality to the complexity.
Not sharing the PRD widely enough. The PRD should be visible to anyone affected by the feature: engineering, design, QA, support, sales, marketing. Transparency prevents surprises at launch.

Key Takeaways

A good PRD is short, clear, and focused on what and why. It includes a problem statement, success metrics, user stories, explicit scope (in and out), open questions, and links to mockups. Keep it under two pages. Write it before development starts and update it when scope decisions are made. The test of a PRD is not how thorough it is but whether the team reads it and builds the right thing.