Simple Product Requirement Document Template (PRD)

A strong PRD tempalte helps stakeholders understand the intent, scope, and solution outline for your project. Use our template to get started taking your product ideas from sketch to launch.

# Product Requirements Document \(PRD\)

Product Requirements Documents \(PRDs\) are a helpful way to gather key context, information, and ideas as you take a project from start to finish.

_Credit to _[_Kevin Yien_](https://www.linkedin.com/in/kevinyien/)_ for inspiration for this template\!_

| **Owner** | _Name_ |

| **Contributors** | _Names_ |

| **Stakeholders** | _Names_ |

| **Resources** | _Link to docs, boards, and other materials relevant to this brief._ |

| **Status** | _Draft, Review, Launched_ |

| **Last updated** | _Date_ |

# Problem

**Tip:** A good problem description is concise and readable by anyone at your company. It should clarify what the problem is and why it’s important.

_Describe the problem at hand and why it matters to customers and the business. Also provide any key evidence or insights to support the issue._

_Consider sharing annotated screenshots \(e.g. using [Annotated Screenshots](https://whimsical.com/annotated-screenshots-PAC5DDYYhhXJ5cet7W8DGR)\), embedding video walkthroughs, or other visualizations to show the problem from the customer’s point of view._

## _Impact_

_List a few general goals and related metrics or outcomes that will determine if the project was successful._

---

# Solution Outline

**Tip:** Instead of trying to think through aspects of the solution on your own, conduct a [Brainstorming Workshop](https://whimsical.com/brainstorming-workshop-7RApeZ6icUthAJhtFKZxCp) or other collaborative sessions with your project team to gather ideas and considerations. And not only at the start of a project, but as you uncover unexpected complexity.

_A brief description of the proposed solution that illustrates its scope and mechanics. _

## Key features

_A prioritized list of planned features that define the boundaries of the solution space, encouraging stakeholders to assess and share ideas that stay within scope._

_Also include relevant design and development considerations, conditional logic, and possible edge cases._

## Key flows

**Tip: **While some product managers wait to request feedback until they have a full first draft finished, others share PRDs as they make progress on each section. How you work may depend on the project, team, and habits at your company.

_Consider making user flows and/or wireframes in a nested board to compare the current and proposed end-to-end experience of using the solution’s features._

## No-gos

_Related projects or problems intentionally left out to manage scope._

---

# Launch Plan

_An overview of the project release strategy and timeline. Will it be A/B tested? Will it coincide with other releases? How will it be reported?_

## Milestones

_In the table below, define the intent for each phase in bringing your product or feature to market, and the criteria it must meet to move forward._

| --- | --- | --- | --- |

## Operational Checklist

**Tip:** Document what you need from each team as specifically as possible in order to keep track of each moving part in the context of your PRD. Consider documenting the status for each need like we’ve done in the table below.

| --- | --- | --- | --- |

---

# Appendix

## Considerations

_Additional notes, open questions, and concerns not captured above._

## FAQs

_Address anticipated or common questions readers may have about the project, especially on topics which may be controversial._

## Changelog

_A changelog can be helpful to document key decisions, updates, and discussion threads, linking to relevant documentation as necessary._

| **Date** | **Change** |

| --- | --- |

| | |