As everyone knows, the product requirements gathering process is exactly like picking fruit off 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.
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.
- Why you’re building this product
- The scope, which is the features and functionality of the product
- What you’re specifically not building
- 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 Basics of a Product Requirements Document
- 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.
- Changes in scope.
- Key decisions.
- Results of relevant sources of information like user design tests, surveys and research.
User Personas
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.
