Product Requirements Document Template With a Worked Example

Copy-and-paste PRD template

Use this structure for a new product or a meaningful feature. Keep the first page readable by a stakeholder who did not attend the discovery meetings. Put detailed diagrams, research notes, and technical investigations in linked appendices instead of burying the decision inside a long document.

Start with a document header containing product or feature name, owner, status, last updated date, decision deadline, and links to research or prototypes. Then complete the sections below in order. If an answer is unknown, write the question and its owner rather than inventing certainty.

• Problem: who is blocked, what they are trying to do, and the current workaround
• Outcome: the observable change for the user or business if the product succeeds
• Target users: primary user, secondary user, and excluded audience
• Scope: capabilities included in this release and an explicit out-of-scope list
• User journeys: the smallest end-to-end paths the product must support
• Requirements: numbered, testable statements with priority and rationale
• Acceptance criteria: evidence that proves each critical requirement works
• Success measures: baseline, target, measurement source, and review date
• Constraints and risks: legal, data, platform, time, budget, and dependency limits
• Open questions: decision needed, owner, evidence required, and due date

Illustrative PRD example for an appointment reminder app

Problem: independent clinics lose staff time when receptionists manually text patients, while patients miss appointments because reminders are inconsistent. Primary user: clinic receptionist. Desired outcome: staff can schedule a reminder in under one minute and see whether delivery succeeded.

Release scope: create a patient record with consent status, schedule one SMS reminder, show pending, sent, delivered, or failed status, and allow a receptionist to cancel a pending reminder. Out of scope: clinical records, insurance data, recurring campaigns, two-way messaging, and automatic rescheduling.

A critical requirement can be written as: When an authorized receptionist schedules a reminder for a consenting patient, the system must show the appointment time, destination number ending in four visible digits, scheduled send time, and current delivery status. Acceptance criteria should then cover the normal path, missing consent, invalid phone number, cancellation, provider failure, and timezone behavior.

A success measure might be: reduce median reminder setup time from four minutes to one minute during a two-week pilot, measured from the scheduling audit log. That is stronger than a vague goal such as improve efficiency because the baseline, target, event, and review window are visible.

PRD, SRS, user stories, and proposal are different artifacts

A PRD owns the product problem, user outcome, release boundaries, and product-level requirements. A software requirements specification goes deeper into system behavior, interfaces, data rules, and nonfunctional requirements. A user story is a small planning unit inside that wider context; it does not replace the product decision.

A software proposal comes earlier when approval, budget, or client agreement is still needed. Do not copy the same generic paragraphs into all four documents. Link them and let each artifact own one decision layer: proposal for whether to proceed, PRD for what and why, SRS for detailed system behavior, and stories or test cases for delivery evidence.

Review the PRD before work starts

Run a short review with product, design, engineering, and the person accountable for the outcome. Ask whether the problem evidence is current, whether every must-have maps to a user journey, whether excluded work is explicit, and whether success can be measured with an available source.

Mark assumptions separately from approved requirements. Resolve contradictions before assigning work. During delivery, update the PRD when the product decision changes, record the reason, and keep the previous decision visible in version history. Do not silently rewrite a requirement after a failed test.

• Can a reviewer explain the problem and release boundary after reading one page?
• Does every must-have requirement have acceptance evidence?
• Are permissions, failure states, data ownership, and empty states addressed?
• Is every metric tied to a real event, baseline, target, and review date?
• Do named owners exist for remaining questions and external dependencies?

Turn the conversation into something the team can inspect

A document aligns decisions, but a working prototype exposes missing decisions faster than prose alone. In a SayCraft meeting, the team can talk through the problem, requirements, and corrections while a running web app takes shape in the live preview. The meeting replay preserves how the draft changed, which helps reviewers connect interface choices to the discussion.

Treat that prototype as validation evidence, not proof that production requirements are complete. Use what the team learns from the preview to revise the PRD, especially scope, flows, edge cases, and open questions. Free includes the live meeting preview and replay; permanent deploy access requires Pro, while source download is a Max capability.

Sources and discussion

• Atlassian product requirements document template (publisher)
• Atlassian guide to product requirements (publisher)

Community posts describe individual experiences and questions; they are not treated as universal proof.

Related resources

• /blog/software-requirements-specification-template
• /blog/user-story-examples
• /blog/requirements-gathering-questions
• /meeting-to-product
• /pricing

Build the next step with SayCraft

Bring the PRD outline into a SayCraft meeting, talk through the uncertain parts, and use the live working preview to find missing flows before the team commits to build scope.

Start building live →