Product Requirements Document

Agent Prompt Snippet

Ensure the project has a product requirements document capturing user needs, business objectives, feature scope, and measurable success criteria.

Purpose

A Product Requirements Document (PRD) is the contract between the team building a product and the people who asked for it. It captures: who the users are, what problem is being solved, what the product must do (and must not do), and how success will be measured. Everything downstream—design, engineering, QA, marketing—is grounded in the PRD.

The PRD’s primary function is alignment. Before a PRD exists, everyone on the team has a slightly different mental model of what is being built. The PRD makes that mental model explicit, surfaces disagreements early (when they are cheap to resolve), and creates a shared reference for all subsequent decisions. “But the PRD says…” is one of the most productive things a team member can say in a scope debate.

A PRD is not a feature specification. Feature specs describe how something works; the PRD describes what must be true when the product is done and why those things matter. The PRD answers: What user pain does this address? What outcome are we trying to achieve? What are the constraints? How will we know we succeeded?

Well-written PRDs are scenario-driven. Instead of listing features (“the system shall have a search bar”), they describe user journeys (“when a developer can’t find a function name, they can search the codebase and get results in under 500ms”). Features emerge from scenarios; scenarios are grounded in user need.

Who needs this document

Persona	Why they need it	How they use it
Sam (Indie Dev)	Prevents over-building; keeps solo projects focused on the user problem that matters	Writes PRD before building; uses it as a filter: “does this feature serve the stated user need?”
Claude Code (AI Agent)	Cannot generate product-appropriate implementations without knowing user goals and constraints	Reads PRD to understand who the user is and what success looks like before designing solutions
Priya (Eng Lead)	Manages scope; uses PRD to push back on late-stage feature requests that aren’t in scope	References PRD in sprint planning; flags work items that don’t map to a PRD requirement
Leo (OSS Maintainer)	Communicates project vision to contributors; helps evaluate PRs for product fit	Links PRD from README; evaluates contributions against PRD user scenarios

What separates a good version from a bad one

Criterion 1: User personas are specific, not demographic abstractions

✓ Strong: “Primary persona: Alex, a senior backend engineer at a 50-person startup. Alex deploys new services weekly and spends 3–4 hours per week on documentation. Alex’s pain: by the time a service is deployed, there’s no record of why architectural decisions were made. Alex’s goal: spend 15 minutes writing documentation that prevents 3 hours of archaeology later.”

✗ Weak: “Primary persona: developers who build software.” (This persona describes 25 million people and generates zero useful product decisions.)

Criterion 2: Success metrics are measurable and time-bound

✓ Strong: “Success: 60% of active users generate at least one document within 7 days of signup (measured via event: doc_created). P50 time-to-first-document < 10 minutes from signup. NPS > 40 after 90 days of use. Target: 500 MAU by end of Q2.”

✗ Weak: “Success: users find the product useful and adoption grows.” (Unmeasurable. In six months, no one will be able to agree on whether the product succeeded.)

Criterion 3: Out-of-scope is explicit

✓ Strong: “Out of scope for v1.0: real-time collaboration, git integration, custom templates, user-defined taxonomies, team billing. These are logged as future consideration items in the product backlog but will not delay v1.0 launch. Scope decisions are final until the next planning cycle.”

✗ Weak: “Future enhancements may include additional features.” (Does not prevent scope creep. Every new feature request will be positioned as a “future enhancement” someone mentioned.)

Criterion 4: Constraints are surfaced, not buried

✓ Strong: “Constraints: (1) Must work offline—target users are on planes and in conferences. (2) Must be accessible on iOS 16+—50% of beta users are on iPhones. (3) No user data leaves the device—compliance requirement from enterprise pilot customers. These constraints are non-negotiable and override feature requests that violate them.”

✗ Weak: “The product should work across different devices and be secure.” (Vague. Does not tell an engineer what trade-offs to make or what to refuse.)

Common mistakes

Writing PRDs after engineering has already started. A PRD written to document a decision already made is not a PRD—it is a changelog. The alignment value of a PRD comes from writing it before any implementation decisions, when the document can shape the product rather than describe it.

Conflating requirements with solutions. “The system must have a dashboard with a line graph showing weekly active users” is a solution, not a requirement. The requirement is “users need to understand adoption trends at a glance.” The solution (a dashboard, or a weekly email digest, or a Slack notification) comes from design.

No prioritization within the document. A PRD with 40 equally-weighted requirements is not actionable. Every requirement should be labeled Must Have / Should Have / Nice to Have (or MoSCoW) so that engineers know where to spend time when trade-offs arise.

Success metrics that can only be measured post-launch. If you can’t measure your success metric before launch, you’ll never know if you succeeded. Define proxy metrics (e.g., time-to-first-action in user testing) that can validate the PRD assumptions before shipping.

How to use this document

When to create it

Write the PRD before any design or engineering work begins. The PRD is the first artifact in the product development cycle. For new features on an existing product, write a mini-PRD (half a page) before opening the design file.

Who owns it

The product manager or, in smaller teams, the technical founder or project lead. Engineers and designers are collaborators and reviewers—the PRD is not written in isolation. Stakeholders approve the PRD before implementation begins.

How AI agents should reference it

get_standard_docs(type="web_app", features=[])
→ prd in documents[]
→ agent reads PRD to understand user personas, success metrics, and constraints
→ agent checks proposed features against the "out of scope" section
→ agent uses success metrics to frame engineering trade-off decisions

The prompt_snippet — “Ensure the project has a product requirements document capturing user needs, business objectives, feature scope, and measurable success criteria” — tells the agent to verify that all four dimensions (users, objectives, scope, metrics) are present.

How it connects to other documents

The PRD is the source document for the Requirements Specification (which translates PRD requirements into engineering acceptance criteria), the UI/UX Specification (which translates user scenarios into interface designs), and the Architecture Overview (which constrains how requirements can be met). The SLA definition’s performance targets should be traceable to specific PRD requirements.