All you need to know about PRD
What is PRD?
>Outlines the product’s
>Purpose
>Features
>Functions
>Behaviors
> also defines the requirements of a product or feature
Why is a PRD required?
>Provides clear guidance
>Establishes alignment on the team
>Source of Truth
To whom should we give this document?
>Developers
>UX
>QA
>Analytics
>Stakeholders
>Other PMs
When should we write PRDs?
> For any new feature requests
> After you have determined the strategy and customer benefits
>Before developers can start building the feature
Include
>Objective
>requiremnts
>Assumptions
>Depndencies
>Neccessay links
How?
>Ask the group to read through the doc on their own
>Leave space at the end of each section for questions and notes
>Ask for the high-level feedback
>Review inline questions and feedback
> Update doc with feedback and finalize doc before development
> Update doc with any new learnings after development begins
Requirements:
Who?
>End user
>Be specific
What/How?
>Action user takes
>How the product responds
When?
>In what situations does the product react in this way (XYZ situation)
Examples of who, what, how, and when:
As a shopper, I’ll get the confirmation alert after I complete a purchase
Include:
Functional requirements:
> How a user will interact with your product
> What the system will or must not do
Example: As an Instagram user, I’ll get an error message after an unsuccessful photo attempt.
Non-functional requirements:
> product properties
>Focus on user expectations
>How the system should do what it does
Example: A photo post will timeout 30 seconds after unsuccessfully uploading.
Metrics:
>KPIs (Key Performance Indicators)
>Legal required data and logging
>Where metrics should be exposed
Example: As a PM, I can see the counts of all the users who uploaded an image in my team’s dashboard.
Now what?
> The PRD becomes the locked source of truth
>TPM, PM and devs use the PRD to create the projects plan and stories
> QA use PRD to build test cases
>PM use during the pre-launch demo to confirm implementation
