A product requirements template should contain the essential answers to why you are building something and what you are building.
Your engineering team, design team, and future readers such as leadership should be able to read this document to fully understand what the feature is doing, what value we expect to drive with it, and how it will help our customers.
Here’s how I write mine:
Header if Needed
Author Date
Company Name: Feature Name
Problem
What is the current customer experience? Why is it a problem?
What data do you have to show this a real problem worth solving?
Include any relevant information that may inform design choices such as Looker, Mixpanel, competitive projects, market research or customer feedback.
While this problem remains unsolved, what is the impact on customers?
Make sure to quantify the size of the impact here.
Solution
What do you envision as the solution to this problem? Describe, in detail, the feature set needed to meet the customer’s needs. Identify how each feature will address a specific customer need and/or the goal of each requirement. User stories can be added here as well.
Generate a detailed plan of the expected customer flows and actual deliverables. This should be a living document, updated with specific requirements that are actionable without being overly prescriptive for the design and tech teams. Scope changes will be noted or changes to delivery timelines as work progresses and the plan is finalized before work begins.
Describe the feature to a customer in 1-3 sentences. How will we position this feature to our ideal customer?
Design link: Figma
What assumptions are you making?
Bullet 1
Bullet 2
Bullet 3
Identify any constraints
Bullet 1
Bullet 2
Bullet 3
Identify any external dependencies such as vendors or needs from other technical teams.
Bullet 1
Bullet 2
Bullet 3
Rollout
Define the cohort of customers upon which the feature will be tested, including the percentage of customers that receive the variant vs the control as well as the profile of customer (new customers, trading customers, etc.).
What are the milestones? Define a milestone as a shippable, valuable product for customers, not technical milestones.
First milestone:
Success
What are the goals of this product?
Remember SMART - goals should be specific, measurable, attainable, relevant, and time-based.
Bullet 1
Bullet 2
Bullet 3
How will we measure success?
What metrics do you expect to impact with this feature?
Bullet 1
Bullet 2
Bullet 3
What are the specific KPIs we need to reach to consider the product a success?
Establish the baseline vs the proposed improvement to the metric that would allow us to call the project a success.
Bullet 1
Bullet 2
Bullet 3
Change Log
Provide a description of each important change to the PRD including who changed it, when they changed it, and what they changed.
Stakeholders
Have you received sign off from all relevant stakeholders such as the General Manager, engineering and product leaders, legal, fraud, compliance and security? Document all approvals and concerns from stakeholders.
Addendum: Support Materials
Add information that will help your engineering team or future readers with all of the necessary context. They shouldn’t need to read any other documents to understand what to build.
Documentation
Internal Data
Figjam
Whiteboards