Free product requirements document (PRD) template

Use or delete sections as needed! You can find the Google Doc version of this template here. There’s also a “lite” version here.

Problem statement

Here’s a one or two sentence overview of the project or feature. The level of detail should allow users to visualize what the following sections are about, but should not be too prescriptive about the actual design implementation.

Stakeholders

Clients or stakeholders required for sign-off:

• First name, last name, role
• There shouldn’t be too many people here, these should only be the folks needed for signoff
• You can indicate where each stakeholder is on the RASCI chart (in parenthesis like this.)

Collaborators who are in other departments, vendors, or agencies:

• Another person in a supporting department
• A point person at an agency

Internal approvers from your own department who review work before it’s sent to stakeholders:

• A creative department lead
• The account point person

Personas

Who is going to be using this new feature, product, or service?

Goals

Toward what end will consumers make use of this?

You should be able to summarize the high-level goal of this project in one sentence. Goals are lofty and hard to measure, like “become a leader in machine learning” or “provide support for working mothers.” This should inspire your team when the going gets tough.

Objectives & Key Results

Objectives are tangible and measurable. Project objectives should clearly map to higher-level business strategy, and should clearly state how the impact on those goals will be measured. This is a great place for your project KPIs. You can also include a baseline for each KPI, if known, and a timeframe expected for improvement. Once it’s created, you can link to your dashboard from here and maintain this PRD as onboarding documentation for future users.

Example Objective: “Improve productivity of the customer service team by reducing time to resolution for help tickets.”

How will we measure success? “time / resolution”

Current benchmark: “Avg. call duration 6 minutes. Data Source: Zendesk.”

Target improvement: “↓ 1 minute / call”

Research

Here, you might want a quick introductory paragraph about your research methodologies. How many people will you interview? In-person or over the phone? How will you source these users? What open questions are you hoping to answer from this research?

User insights

Once your research is complete, it’s helpful to conversationally summarize insights in paragraph format, and include a link to your long-form qualitative or quantitative data. Your research might validate your assumptions, or you might have found something surprising. Be careful not to focus on interesting — but outlier — information. Make sure your takeaways accurately represent the overall feelings and behaviors of your test cohort.

Business (or product) requirements

Requirements are a combination of tactics and constraints — things you must do, and things you must not do.

• A requirement might look like “users must only be able to enter one email address.” This is a functional requirement.
• A requirement might also be a “soft requirement,” like “need to carefully manage scope and time because this needs to launch a few weeks before the summer conference.” These are business requirements.
• Requirements should be written in plain English, and conversational enough for most people on the project to be able to understand at-a-glance.

Technical requirements

• If you have more than a dozen of these, I recommend including a link here to long-form technical documentation.
• Remember to include the scope of supported browsers and devices in your technical documentation.
• If you only have a handful of requirements, they can be written like “End users should see an error if they attempt to sign up with an email address that is already associated with an account. The error needs to include a link to login and another link to the forgot password flow.”
• If many teams will be referencing these requirements, it can help to number them, like this:
• R001 — Requirements can be numbered
• R002 — Numbering system should start with a few leading zeros for scale

Accessibility requirements

• Accessibility requirements are not just technical requirements, so it makes sense to put these in their own section as they often affect UX and Design as well as the tech department.

Resources

• I’m a link to an API dependency
• I’m a link to a style guide or design pattern library
• I’m a link to the version of Python that the backend is written in
• I’m a link to a similar campaign this client really liked and wants to model her project after

Open questions

Note: In initial stakeholder interviews, I find that the maximum number of questions we are able to answer is 8, whether the interview is 30 minutes or 90 minutes. Trim your list to the most valuable 8 pieces of information you need to elicit and plan for follow up interviews. I also like to place this section last so that if the answers start to grow to a few pages, everyone can still easily skim the less frequently changing sections above.

Some example questions to start off the conversation:

• What do you believe should be our main objective?
• What pain points keep you or your users up at night?
• How are our users currently working around this problem?
• Do you have internal users who might also be using this tool?
• What constraints do we expect to encounter?
• Is there anyone else we should speak to about this?
• What does success look like for this particular experience?
• What does failure look like?

This post originally published on ProductFirst.org