What this PRD example is for
A product requirements document, or PRD, explains what one feature must do, who it is for and how you will know it works.
I use a PRD before handing work to an AI coding agent because a short prompt leaves too many product decisions open. The example below plans a client feedback feature for a small design studio.
1. User and outcome
User: a client reviewing a design. Outcome: the client can open the current design, approve it or leave a comment, then see that the response was saved.
This outcome is the filter for every later detail. If a proposed feature does not help the client complete this job, it belongs somewhere else.
2. Main behaviour
This is the normal path the client should be able to complete.
- The client opens a private shared link.
- The page shows the correct design name and current design file.
- The client can choose approve or enter a comment.
- The app saves the response against the correct design.
- The page confirms the save and explains what happens next.
- The studio owner can see the response and when it was sent.
3. Boundaries for the first version
The first version does not let the client edit the design, upload a replacement, invite another reviewer or receive automatic reminders.
Writing this down matters. AI agents are good at adding plausible extras. Each extra creates more states, code and testing that may have nothing to do with the first user outcome.
Out of scope is part of the requirement because it protects the feature you are trying to finish.
4. Edge cases and acceptance criteria
These checks cover the places where the feature is most likely to fail or leave the client stuck.
- An expired or invalid link does not reveal the design and gives the client a clear next step.
- A blank comment cannot be submitted.
- A response is saved only once if the client presses the button twice.
- A failed save keeps the client's response and lets them try again.
- A successful save shows a confirmation.
5. Data the feature needs
The feature needs a design record, a private link or access token, a client identifier, the response type, an optional comment and the time the response was saved.
This is enough to start a database plan. The PRD should not invent extra tables or fields with no connection to the user journey.
6. Tasks and tests
Split the feature into shared access, the review screen, saving the response and the studio view. Give each task the relevant requirements instead of pasting the whole project into one prompt.
Add automated tests for rules such as invalid links, blank comments and duplicate saves. Then run the full client journey yourself. The feature is not complete until the checks in the PRD pass.
CodeSpring can generate focused PRDs from a mapped feature and connect them to ordered Kanban tasks. The related guide below explains the basic PRD idea first.