Understanding The Product Requirements Gathering Process

Understanding the Product Requirements Gathering Process
Understanding the Product Requirements Gathering Process

As everyone knows, the product requirements gathering process is exactly like picking fruit off trees.

Product Requirements Gathering Process - it's easy, like picking fruit from a tree
Hey, lets gather some product requirements. They just grow on trees

Mazel tov (that’s yiddish for congratulation) on successfully validating a product hypothesis, although the reality is that you are simply reading the blog without doing the work, but we can pretend that you did it. So continuing on as if you did the work, the next stage in the product development lifecycle is the solution design phase, which pretty much is what it sounds like. 

Overall the process involves capturing the initial requirements from internal and external stakeholders, refine those initial requirements and break them down into user stories to be worked on by the development team.

Program designers have a tendency to think of the users as idiots who need to be controlled. They should rather think of their program as a servant, whose master, the user, should be able to control it. If designers and programmers think about the apparent mental qualities that their programs will have, they'll create programs that are easier and pleasanter — more humane — to deal with.

John McCarthy, "The Little Thoughts of Thinking Machines", Psychology Today, December 1983, pp. 46–49.

Product Requirements Gathering Process: The MVP

The purpose of the product requirements gathering process is the determination of the features/functions to include in your minimum viable product (MVP).  If you have been following along, you should know that the purpose of these features and functions is to solve the user pain point you validated in your product hypothesis.

So the question is now, what are the features you in need to include in your MVP.  The answer my friend is figured out by the product requirements gathering process.

The Product Requirements Document

Ideally, your product requirements gathering process culminates in the creation of what is called, aptly enough, the product requirements document.   This document plays a fundamental role in the development of any new product. It also marks your transition from talking to executives to talking to colleagues who execute on things like the product roadmap, so if you need a clear indication of where you should stop talking in themes and start talking in features, this is the place. 

The product requirement document is fundamental to the process
The first product requirements document was produced with a quill. It's that old!
Although, I’ve always found that a product requirements document flies in the face of all that is preached by the church of Agile product management and it much ballyhooed “We don’t believe in documentation” schtick, any experience product manager who has had the responsibility for managing anything more than their ability to get a glass. of water needs one. The product requirements document explains the product you are building. It explains:
  • Why you’re building this product
  • The scope, which is the features and functionality of the product
  • What you’re specifically not building
Product Requirements documents
Don't go chasing waterfall style product requirement documentation. Source: Beatriznog10, CC BY-SA 3.0 , via Wikimedia Commons
Product requirement documents are an ongoing point of contention in the world of product management they can span a spectrum from:
  • Something you would find in the waterfall school of thought novel that specifies every aspect of a product up front, they are difficult to read, and they are essentially immutable once finished—
  • Huh? Product requirements document? What dat? Some believe quick iteration removes the need for long/detailed specifications.  To these people, I offer one of 2 remarks:
    • You probably don’t have enough responsibility at work.
    • You only work with 3 other people.   Try managing a team of 40 people without documentation.
The truth is that you need a product requirements document, so you need to learn how to do them properly.

The Basics of a Product Requirements Document

As product manager, you’ll come to realize that a good product requirements document is a multi use tool that evolves over the life of project as it:
  • Get all the key stakeholders on the same page.
  • Help the team understand the project.
  • Allows other teams, like marketing, customer support and sales to find what they need to know about the product.
This is why knowing how to build out a product requirements document communication strategy is so critical. Since this is a living document, as the project moves forward, it gets updated to include:
  • Changes in scope.
  • Key decisions.
  • Results of relevant sources of information like user design tests, surveys and research.
If you want to see product requirements document sample.   And be grateful!!!

User Personas

User personas are the tool product managers have come up with to simplify the process for our tiny reptile brains abstract the shared characteristics of users we would like to target with our product. We went to great pains to explain the importance of user personas in product management, so the least you could is read it, or use it to hide other content on your screen when your boss walks by. It’s also important to note that the use of user personas bleeds into user scenarios as well.

User Scenarios

A product requirements document will likely have multiple user scenarios covering different personas and their use cases.

When designing your MVP, you need to figure out the most relevant user scenarios in order to write user stories and use cases to guide the development team. 

Ideally, each scenario breaks down into one user story and a number of use cases.

What you should notice is that some of the features you thought would be needed in the MVP are not backed up by the user scenarios, which is a good thing as don’t need to build those features (Less work!!!)

Cornerstones of the User Scenario Process

  • Don’t forget about the onboarding user scenario: How will a customer first encounter this product and learn to use it? 
  • Be descriptive, not prescriptive:  It is the job of the designers and engineers to  figure out the solution to to the customer problem you describe in the scenarios.  

What To Do With a Product Requirements Document?

So just like Moses, you’ve crossed in the end zone and scored a touchdown by finishing the product requirements document, other than laughing at my mixed metaphor, what do you do next? 

Experienced product managers know that if you haven’t already done so building out a product requirements document communication strategy is the next step.

Table of Contents
More From Our Blog
agile requirements gathering cover
Product and Solution Design
Agile Requirements Gathering

Before you start running around your office shouting buzzwords about Agile requirements gathering, you should take the opportunity to educate yourself about Agile software development

Read More »
the product design process
Product and Solution Design
The Product Design Process

As a product manager, having a good overview of the product design process is essential so you can: do the designers job get their asses

Read More »