How to build a simple and effective product requirements document

Presented by Upasna Gautam

INTRODUCTION 

Product requirements, sometimes formally referred to as a product requirements document (PRD), serve as a blueprint that defines the product or feature that your team will build. Often drafted by a product manager with input from the product owner and other stakeholders, the PRD is a record of the purpose, features, functionality, metrics of success, and behaviors for your future product. 

The requirements document contains everything that must be included in a release to be considered complete, and serves as a guide for subsequent documents in the release process. It is usually more detailed than a simple briefing and less detailed than a technical engineering implementation plan. While PRDs don’t dictate specific implementation, they might hint at a potential implementation based on user research uncovered during the product discovery phase.

Drafting a requirements document is an opportunity to seek clarification and surface challenges that might crop up during development. During this phase, it’s the product manager’s responsibility to facilitate conversation with the technical team and to work toward product consensus with stakeholders and other team members. The goal is to fully document expectations so that there are no surprises later on, and these conversations will likely result in updates to the PRD. Once there is agreement that the requirements document is complete, it is passed to other teams to define UX design, functional specifications, and testing.

Once alignment on a requirements document is achieved among teams and stakeholders, there should be little question as to what will be shipped, how it will benefit the business, and its impact on users. The PRD provides clear direction toward a product's purpose while creating a shared understanding among business, design, and engineering teams.

While there are no rules around what to include, the core components in the section below should always be part of a product requirements document.

IN PRACTICE

Use the tips and concepts in this section to cultivate a product culture in your newsroom

Begin with project specifications

Each product requirements document should begin with high-level project information that includes: 

• A list of project leads and other participants, e.g. Product, Design, and Tech leads

• Project status, e.g. On target, At risk, Delayed, etc.

• Target release date 

Explain your objective or goals

Briefly outline the core user problem that you are solving, who the users are that you are building for, and what you hope to accomplish for the user. 

Example framework to follow:

• Vision: Where you want your product to be in the future

• Goals: Concrete product goals related to the problems you are solving with a time frame and success metrics

• Personas: Describe who the product is for

List the expected product features

For each expected feature, include a detailed description, goal, and at least one use case.

Example framework to follow: 

• Feature: Name of the feature or user story

• Description: What will the feature do for the user? What will the user achieve?

• Purpose: The action the user will accomplish

• User Problem: Pain point/challenge

• Acceptance Criteria: Conditions of acceptance and definition of “done”

Share user experience and design notes

Include notes to describe or illustrate user stories, e.g. links to Miro, or other results from design exercises, to provide clarity and ensure that design objectives are met. Priority of user stories may also be documented here, but mockups and wireframes are not typically included in the PRD.  

Define user environment requirements

List which end-user environments will be supported, e.g. supported  browsers, operating systems, memory requirements, processing power, etc.

Record assumptions, constraints, and dependencies

Use this section to provide details about the technical, business, and user assumptions you may be making. Include what is expected of users, any limits that engineering should be aware of, and any external elements required for the final solution to be functional.

TERMS

Definitions for product terms referenced in this guide are sourced from NPA’s crowd-sourced product glossary

Use Case

A scenario showing how a product’s user might interact with the product to achieve a specific goal. Product managers often employ use cases to explain (through user stories) how and why customers will use various parts of a product

User Story

An informal, general explanation of a feature written from the perspective of the end user. It articulates how a feature will provide value to the user. User stories are often expressed in a simple sentence, structured as follows: “As a [persona], I [want to], [so that].”

RELATED READINGS / RESOURCES

Discovery vs Documentation - Marty Cagan, SVPG

How to Create Modern Product Specs that People Will Read - productcoalition.com

How to Write a Painless Product Requirements Document - Jerry Cao

ABOUT THE AUTHOR

Upasna Gautam

In Upasna's role as Product Manager on the Digital News Platforms & Services team at CNN, she works with CNN's engineers, designers, editors, and journalists to develop and optimize the content management technology that delivers breaking news to the world. 

Upasna has been working in the tech industry for the last 15 years, where she has been an integral part of delivering technical, data-informed solutions for brands such as Ford Motor Company, PCMag, Mashable, Mars Corporation, and Kimberly-Clark.

Outside of her day job at CNN, Upasna is an avid public speaker, career coach for women in tech, meditation teacher, Public Speaking Coach at Shine Bootcamp, and a Community Lead with Google's Women Techmakers.

Puedes leer la guía traducida y adaptada al español aquí: Definir los requerimientos para el desarrollo de produto

Você pode ler o guia traduzido e adaptado para português aqui: Definindo requisitos para o desenvolvimento do produto