What is a product requirements document?
A product requirements document, often shortened to PRD, gives a team a shared description of a proposed product change. It connects the customer problem to intended behavior, boundaries, acceptance checks, and release decisions. Readers should be able to tell which decisions are settled and which still need investigation.
Atlassian's requirements guidance presents a PRD as a way to align purpose, user needs, and planned functionality. The document does not need to be long to do that job. A small, well-maintained brief can be more useful than a large specification that nobody updates after the first discussion.
This guide includes an original fictional PRD for filtering a report export. It is a worked writing example with invented evidence references, not a description of a feature currently offered by ShowMeYourSaaS. Download the completed example and a clean template near the end.
Use discovery evidence to explain the problem
Begin with the user's situation and the reason to act. In the fictional reporting app, agency operators need a client-specific export from a report containing several clients. Today they export the complete report and remove unrelated rows manually, which creates extra work and a risk of sharing the wrong information.
The example lists two invented conversation references and one invented support note, explicitly labelled as fictional. A real PRD should link to permitted evidence with enough context for the team to assess it. A customer quote or an analytics chart should not become a universal claim about every account.
Use product discovery to decide whether this is the right opportunity and approach. The PRD records the selected direction and unresolved assumptions. If the feasibility of filtering remains unknown, a bounded proof of concept can answer that question before delivery scope is treated as settled.
Write goals and non-goals that constrain the work
The example goal is to let an authorized agency operator export rows for one selected client without editing the downloaded file. The desired outcome is fewer manual corrections in the observed workflow. The team still needs to measure actual use after release rather than treating the existence of a filter as proof of improvement.
Non-goals include scheduled exports, multiple-client bundles, a new file format, and a redesign of account permissions. These boundaries help the team evaluate requests that arise during implementation. A non-goal can change after review, but that change should carry a reason and an effect on scope.
State environmental and data constraints. Which report types are supported? Which account owns the report? How is the selected client resolved? What happens when the selection contains no rows? These details often determine whether an implementation is usable and safe.
| Included | Excluded for this release |
|---|---|
| One client selection within an accessible report | Multiple-client bundles |
| Existing export file format | New formats or scheduled delivery |
| Permission checks on the export request | A new account-role system |
| Clear empty-result and failure behavior | A general report-builder redesign |
Describe the behavior with a user story and edge cases
A user story gives context, but it does not replace the behavior contract. The example story is: as an agency operator preparing a client's report, I want an export containing only that client's rows so I can share it without manually deleting unrelated data.
Then describe the sequence. The operator opens an accessible report, chooses a client available within that report, requests an export, and receives a file with the existing supported columns and only matching rows. The server checks the current user's access when processing the request.
List edge cases beside the happy path. A previously accessible report may become inaccessible. A selected client may have no matching rows. Generation may fail or a person may retry. Decide what the person sees and which operations must remain safe instead of leaving those choices to incidental implementation behavior.
Make acceptance criteria observable
Acceptance criteria should let someone establish whether the delivered behavior matches the decision. Give each criterion an identifier that can be referenced in a review or test record. Avoid statements such as export works well or interface is intuitive, which do not explain what evidence would satisfy the requirement.
The original example uses a synthetic report with three rows: two for Client A and one for Client B. A permitted Client A export must contain exactly the two Client A rows in the existing format. This small fixture makes the expected result inspectable without using customer records.
Write separate cases for access, empty results, failure, and retry behavior. The example specifies that a forbidden request returns no report data and that an empty selection shows a clear message without creating an empty download. Those are product decisions for this fictional workflow, not defaults every SaaS must adopt.
| ID | Situation | Expected result |
|---|---|---|
| AC1 | Authorized operator selects Client A | Only the two synthetic Client A rows are exported |
| AC2 | User lacks report access | No report data is returned |
| AC3 | Selected client has no rows | Clear empty-result message; no file download |
| AC4 | Generation fails | A useful retry message without report payload in logs |
| AC5 | A completed request is retried | A valid result without creating an extra billable action |
Record release controls and open questions
Name the delivery owner, review participants, intended environment, and rollout decision. The example uses a feature flag for a small pilot while retaining permission checks independently. A flag can stop future exposure, but the team still needs a recovery plan for an already-generated incorrect file.
Keep open questions visible with an owner and a decision date. The fictional PRD asks how long an export should remain downloadable and whether a very large report needs an asynchronous job. Those questions should be resolved before promising unsupported behavior.
Define what observation follows the release: successful filtered exports, reported manual corrections, failures, and permission incidents. Record event meanings and avoid placing client contents in analytics. Acceptance confirms agreed behavior; later evidence establishes whether the change helps the workflow.
Keep the PRD useful as the implementation changes
Review the brief with the people responsible for product, implementation, testing, and support. One person can hold several roles in a small SaaS, but the questions still need answers. If an implementation constraint changes the product behavior, update the decision rather than letting the document and application silently diverge.
Use the roadmap for the broader outcome and the PRD for this bounded change. Add a short decision log with date, decision, reason, and affected criteria. Keep detailed implementation notes in the appropriate technical document when they do not help readers assess the product behavior.
The completed text example and blank template include purpose, evidence, scope, user story, acceptance cases, constraints, open questions, release controls, and a review record. Replace all fictional values before using them. Source and resources checked October 27, 2026.