A practical approach to documentation. A PRD (Product Requirement Document) template for both B2B and B2C products. This works well for startups beyond the early stage of product development and for enterprises creating products.

1. Confidential / Internal Use / Public Page Number
Feature Name
Product Requirement Document
Table of Contents
This page doesn’t make sense if you are using online
documentation systems like Confluence.
uvtimes.blogspot.com

2. Confidential / Internal Use / Public Page Number
Overview/Objective
• Describe the feature with very short one or two line description such that a first time
reader understands what this feature is about.
PM’s Checklist
Follow a checklist before you begin documentation, helps you make sure you have all the
needed information.
Business Case
• How does this feature/product impact our business? Call out if it doesn’t.
• Do ROI estimation as well, if possible?
Insights From Research
User Meetings
• Talk to internal teams, clients and check internet for information available around this
feature.
• Summarise your research and add link to external sources/documents.
Competition Analysis
Questions
Subjective elaborate
answers
Will this be a mobile or web feature ?
Who all are the actual end user of this feature?
Try to avoid the words “Every/
All”
B2B: Which economic buyer will this feature help?
Why is this required? (Background, Customer Request,
Strategic fit, “CEO/Boss asked for it”?)
Be honest
Impact: Which all clients/users ask for it, or can potentially
adopt it?
Impact: Can it potentially improve org’s OKRs? Which ones?
Impact: Can it potentially improve user experience
significantly? (B2B: Will it Make the buyer look good?)
Can there be work arounds/ easy ways to solve this problem?
What modules are likely to get affected?
uvtimes.blogspot.com

3. Confidential / Internal Use / Public Page Number
• This section provides an overview of whether our existing/upcoming competitors are
taking care of similar requirements and in what fashion. This information can be
presented in a tabular format listing down competitors, requirements being covered or
not, and notes around how the requirement is implemented
Data Analytics
• Provide current relevant usage stats and web metrics related to the pages/ areas in
discussion in the document
Users / Personas Impacted
• This section highlights the different category of users impacted by the given requirement
– whether internal users or external users, end users or business customers.
Source/API Partner Requirements
• Description of partners that we are using to tackle the above-mentioned problem(s)
along with reasoning for choosing the same. Link to any API documents received.
Solution Approach and Assumptions
Assumptions
• List all your assumptions
Risks/Concerns
• List of everything that is unclear, changing.
Solution
• A brief description of flow, solution approach/methodology that we are using to tackle the
above-mentioned problem(s) along with reasoning for choosing the same
User interaction and design
Flow Diagram
uvtimes.blogspot.com

4. Confidential / Internal Use / Public Page Number
• A flow diagram if necessary for better understanding of how information flows and what
modules are touched. You can create one quickly using mermaid or draw.io
Requirements and Mocks
Include what pages/screens are impacted.
The user’s stories should be written in following format.
• [Mandatory/Optional/Good To Have/]: As an <actor> I want to <do something> so
that I can <achieve a goal>. Explanation/Clarification/Additional Comments
This section should contain prototype screenshots and UI wireframes with description, as
relevant to augment the text, for greater clarity.
Technical Requirements
• Description around tech changes or Link to Technical document.
Non Functional Requirements
Specifications that are important for the product and experience but usually missed out
while describing the positive and negative flows.
• Security
• Performance,
• Battery Usage,
• Response Time,
• Availability/Uptime etc.
Analytics Related Requirements
• This section provides pointers about what all events and information need to be captured
by the analytics tools like GA, Amplitude.
Success Metrics
uvtimes.blogspot.com

5. Confidential / Internal Use / Public Page Number
• This section lists the different web and functional metrics that we can use to measure the
success of the above requirements after implementation. This section lists down the
expected improvements with respect to the different web and functional metrics that we
can use to justify the implementation of this requirement. These predicted improvements
can be used as benchmarks while comparing with actual metrics observed later.
Typically a product metric falls under one or more of ACME (Acquisition, Conversion,
Monetisation, and Engagement).
Related Documents
• Any other related document like Test cases document, BRD etc
Future Scope
• This section will contain the related requirements that are outside the scope of this
document but are important and need to be implemented at a later time.
Not Doing
• List the features discussed which are out of scope or might be revisited in a later
release.
uvtimes.blogspot.com