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!!!!
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
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
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:
- It ties the product roadmap to the corporate strategy
- Metrics keep people accountable.
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.
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 numbersApply 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
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
assumptionsrequirements 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 shamehighlight items that still have to be flushed out. The people you are talking about will get the message.
