Steal Our Product Requirements Document Sample

Product requirements document sample
Product requirements document sample

Did you think we were just going to give you some sort of fill in the blanks product requirements document sample you can slap your company name on?

Guess again tuff guy/girl/person!!!

You are going to do some work for it!

But we will leave you better off for it, we’re gonna  walk you through a product requirement document sample and explain all of the sections to you.

While I can’t promise we will make you a better person, but we will make you a better product manager.  

Show Me a Product Requirement Document Sample Already!!!!

Product requirements document
Enough yelling already!!! We are getting to the product requirements document sample.....

So here is how we are going to go about doing this. The first part of this article is going to give you the sections you need in a product requirements document and the second part of this article is going to explain each of these details in depth.

Product Requirements Document Sample: The Sections

So, if you want to use product requirements document sample as starting point for your document, simply copy and paste the outline below (I’ll show you where to copy) into your word processor and massage it into a form you want to use. 

Start copying from here
Title: Name it.

Prepared By: Who owns the document.   Name and contact info

Change history: Record what changes from version to version.

Overview: What is this project about?

Objectives: What pain point are we solving

Success Metrics: What metrics are you using to evaluate your progress

Messaging & Marketing: What’s the planned product messaging/marketing ?

Release Planning: What does the product release look like?What are you release milestones?

Personas: What does the target customer look like?  How many personas do you have?

User Scenarios: How do the target customers use the product in context.

Required Features: Prioritized features and rationale for inclusion.

Not Including:  What aren’t you doing and why?

Designs: Sketches, mockups/wireframes/designs once they’re available.

Outstanding Issues: What factors do you still need to figure out?

Product Questions: What are users/potential users asking about the product?  What did people ask during hypothesis testing.

Stop copying just above this line

Now let’s dive into each individual section and figure out what is what is actually required for you to assemble a product requirements document.

Title

While it sound obvious, but make sure the document has a unique, identifying name for the project. 

Prepared by

Another flash of the obvious, but make sure the document names who prepared the document and their contact information.

Change History

Allows you to figure out if something changes and when. Ideally you are using a product requirement document tool that generates and documents the change history in a usable form, so you don’t have to spend the time making notes upon notes

Overview

A short paragraph that gives some high level color to the project.

Objectives

Focus on the pain points your product is looking to solve with your product. Be brief and explicitly, list:

  • What you want the customer to get out of this product
  • Your organizational objectives

Success Metrics

By explicitly stating the most important success metrics/key performance indicators by which you measure your progress, you are holding yourself accountable to a goal
Product requirement document - list your success metrics
Tell the organization how you are measuring overall success.

Although the KPIs should be driven by high level corporate objectives, they might lack a bit clarity or someone, possibly you (if you can get away with it), might be sandbagging the numbers. 

When it comes to success metrics and KPIs, you need to have a specific metric (new users/page visits/revenue/etc) along metric number to hit, or at least a range of numbers, for a few reasons:

A few word of caution/career advice on the whole metrics thing, although you want to have the metrics be as explicit as possible, you also want to leave yourself some wiggle room. The reality is that the higher up the corporate food chain you go, the less likely anyone is going to have reasonable idea of what the KPI, so while the KPI should be explicit, it needs to be reasonable in order to keep your team motivated, yet not feeling they are. on a death march. Your job is to keep it reasonable.

Also, the product requirements document is not the place to put your “knowledge” of metrics on display by vomiting them all over the document.   The mark of a professional is simplicity, and this concept should shine through in your selection of KPIs used in your product requirements document

 

Everything should be as simple as it can be but not simpler.

Roger Sessions paraphrasing Albert Einstein

Messaging and Marketing

If there is one place you are going to be taking advantage of “living” aspect of this product requirements document, its the messaging and marketing section. For starters, you are in product management, not marketing, so at best you are not a professional marketer, at worst, you’ll piss of your colleagues in marketing. 

The reality is that the marketing people haven’t spent enough time with the product requirements document to have had time to put anything into it, so be sure to flag this issue in the outstanding issues section.

Release Planning

In theory, you aren’t the project manager, you are the product manager, unless of course, you are working for a smaller start up, and you are doing the project management tasks as well (You can read our article project management vs product management to compare and contrast the differences in the roles).  So even though you may or may not own the project schedule, include some rough release timing information, but remember to:

  • Pad, Sandbag your numbers Apply an appropriate level of expectation setting.
  • Expect sales and marketing to fuck everything up

 

User Personas

If you have been doing product management properly, this is the place for you to start discussing the user personas you previously created. In order to keep the product requirements document brief, simply highlight the user personas here, focusing on their pain points and why they are likely to use the product.

Link to the fully defined persona documents elsewhere

User Scenarios

The purpose of a user story, a general explanation of a software feature written from the perspective of the end user or customer, is the articulation of how feature/set of features deliver a particular value back to the customer. Make sure you understand the difference between scenarios, user stories and use cases in product management.

Features

Ah, finally you can stop holding your OCD back and dive in the features you are including in the project with some level of prioritization.
The list of features should include:

  • The obvious basic functionality of a website
  • The features highlighted by your user stories

This section should just be bullet points with links to the flushed out details else where

Also, because some people can’t accept the fact that a by default, a “To Do” outlines how you should be spending your work time, you need to include an explicit “Don’t Do” list, to state how people should not be spending their time. 

Designs

In the spirt of keeping the product requirements document short, link to the product designs, do not include them here.

While you may want to have a sketch or two here, if the people using this document do not have the wherewithal to click a link to view the designs, its grounds for dismissal (at least in my opinion).

Outstanding Issues & Questions

These last two sections are used to:

  • Cover your ass: This is where you list your major assumptions requirements that are still unresolved.
  • Point out the lazy people: If there are people in your organization who haven’t delivered what you need in order for you to “finish” this document, and you have no way of forcing them to do so, this is where you can publicly shame highlight items that still have to be flushed out. The people you are talking about will get the message.
Table of Contents
More From Our Blog
User Personas in Product Management
Product and Solution Design
User Personas in Product Management

The importance of user personas in product management cannot be understated. Well, that’s not true, because for the most part, subject to the rules of

Read More »
Challenges of Building Product Roadmaps
Opportunity Identification
Product Roadmap Challenges

Ask a product managers to rank order their most vexing professional issues, it’s pretty certain product roadmap challenges are going to bubble to the top

Read More »