PRD Template for Product Managers
5 likes4,964 views
The document outlines the requirements for a new feature, providing guidance on its description, business impact, and competitive analysis. It includes sections on user research, solution approaches, technical and non-functional requirements, success metrics, and future scope. The aim is to ensure comprehensive understanding and thorough documentation of the feature's objectives, design, and implementation strategy.
![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](https://image.slidesharecdn.com/prdtemplate-181130121657/85/PRD-Template-for-Product-Managers-4-320.jpg)
PRD Template for Product Managers
- 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