Product requirements document template

Use the product requirements document (PRD) template to create a single source of truth for the research behind your product, as well as the requirements to build it.

Product managers can create this template alone or have team members work online collectively.

The product requirements document template helps you:

• Get a holistic view of your product and requirements

• Get aligned with your team and stakeholders across all key aspects of your product

• Identify problem areas early and build solutions

How to use the product requirement document template

You'll work with several key sections when making a product requirements document with Mural. These sections are:

• What

• Who

• Why

• How

• Questions and iterations

Step 1: Define the "what"

This section is the foundation of product development. Here you'll write the product name and the overview. The overview should briefly describe what the product is about in three key points:

• The problem: Describe the problem (or opportunity) you're trying to solve. Why is it important for customers and your business? What insights are you operating on? And if relevant, what problems are you not trying to solve?

• High-level approach: Describe the approach you're taking to solve the problem. This should be enough for the reader to imagine possible solutions and gain a rough sense of this project.

• Define the product's purpose: Creating your product story starts with three simple questions: What is your product? Why do you exist? How are you doing it? The template provides an engaging diagram to collect your thoughts on these critical questions and a table to place information to guide the development process.

Step 2: Identify the "who"

This section defines the product's primary and secondary personas. The template provides two areas where primary and secondary personas can be developed:

• Primary personas: Here you will develop two personas that closely resemble the main target of your product or service. Their needs, challenges, and goals should inform your product design.

• Secondary personas: Secondary personas represent individuals who aren’t your key target but may also use your product or service. Secondary personas can share core needs with your primary personas but differ in demographics, behaviors and attitudes.

Step 3: Understand the "why"

This section defines goals and success metrics, and value proposition. Together, these two sectors cover the following:

• Define goals: If everything goes according to plan, what will you be doing six months and two years from now? The template provides a diagram to organize your current goals and goals for month six, year one, year two, and year five.

• Define success metrics: Here you'll organize what key metrics you'll measure your success on. This can include product KPIs (key performance indicators) such as new feature adoption and daily active users.

• Value proposition: Mural's template provides an easy-to-use value proposition canvas that will make defining the value proposition simple. The canvas allows you to compare the primary persona to your product or service.

On this canvas, you'll write your primary persona's pains and gains. On the other half of the canvas, you'll answer the following questions: How does your product relieve pain points, frustrations, and challenges for your primary persona? What benefits or solutions does your product create for your primary persona?

This information will act as the building blocks for your value proposition. Once you've completed the canvas, distill the data into a strong value proposition.

Step 4: Determine the "how"

Give an overview of what you're building. Provide an organized list of features, with priorities if relevant. This section has four main components:

• What's in: In this table, note features used in the final product. These are the distinct, prioritized features and a short explanation of why each element is essential. This is a great place for development teams to sell their product feature ideas.

• What's out: In this table, note features that will not be used in the final product. Include what features you have decided not to use and why. This table can serve as a reminder of why certain product features didn't work in the past. This information can inspire team members to add more value-added features to the final product.

• Timeline release planning: Identify any relevant milestones that people should know about. Here you can plan the dates, milestones, audience and description of each event before the product release date. Make sure to show when you're expecting to launch the product publicly.

• Key design flows/mockups: Show some mockups of the product. Link to other documentation if necessary. In general, it's helpful to organize these around specific journeys or use cases. Show enough of a clickthrough where people can walk away with a reasonable understanding of how the product works.

This section provides blank phone diagrams where you can place your mockup inside or insert your images.

Step 5: Questions and iterations

Use this space to write any questions or topics that require additional work. You can create a Q&A for your product and note any other considerations that may be useful to the development team.

Tips for building a product requirements document

To get the most out of your product requirements document, you should:

• Gather all team members and key stakeholders to make sure you avoid blind spots and anticipate challenges

• Add links and mockups directly to the canvas to centralize all your information, brainstorm ideas together, and gather feedback using color-coded sticky notes and tags

• Keep your PDR document up to date so that everyone stays on the same page and you can easily track progress