What are Product Requirements?
A Product Requirement defined an aspect of a product or feature that must be satisfied in the solution that is created. It is a guide for the design and development teams that helps them build, launch, and market the product. Creating a great product needs lots of research and a comprehensive plan. But the problem is usually where to start. Most Product Managers choose to begin with the Requirements document.
In Agile methodology (which is a reaction to waterfall), requirements are written as user stories which are independent of other requirements and can typically be completed in a 2-week sprint. This means work can begin quickly and value delivered to users much faster, rather than waiting for a full PRD to be defined.
What is a User Story?
This is development work in agile software development that is small and self-contained and designed to accomplish specific goals within the product development. The user story is written from the perspective of the user and has a format to follow.
User stories are typically written at the feature level. PRDs at the product level. Also user stories are typically more incorporative of the team in the solution process and thus only describe the problem and acceptance criteria that are the bounds of an acceptable solution. Waterfall PRDs define the actually solution. Even when working in agile methodology however, if building a new product, there’s typically a one-page “product brief” that will lay out the high-level goals/assumptions and point to the key stories.
Product teams typically decide to break down the development work into various user stories rather than product requirements and features for the following reasons:
- They are easier to understand
- They represent deliverable and bite-sized work that easily fits into sprints where full-featured work doesn’t fit.
- They help the teams to focus on the people instead of the abstract features.
- They help in building momentum and giving the teams a feeling of progress.
What type of information should be in the Requirements Document?
The document should have all the explicit capabilities that are required for release of the product. There must be a user case that illustrates how the user will utilize its functionality to support all the capabilities. In the case of a Waterfall-style PRD this will be more explicit and solution oriented. In Agile, this may be a lightweight one-page “product brief” that provides an outline of these same key points, but emphasizing the boundaries of an acceptable solution so the team can define that solution, and thus really more of a lightweight and product-space oriented document.
Regardless which approach you take (Waterfall PRD or an Agile Product Brief), consider incorporating the following points, that provide helpful context to the individual requirements.
i. Summary – A brief overview of the feature/project, that answers the 4 W’s (what, why, where, and for who?)
ii. Goals – What is the business and/or customer outcome that you’re looking to achieve with this?
iii. Assumptions – What do you assume to be true? Everyone has assumptions upon which observations and/or solutions are built upon.
iv. Use Cases – What are the scenarios in which this product/feature might be used. Hint – Jobs to be Done (JTBD) can be a useful framework here, to articulate this from a user’s perspective.
v. Requirements – a list of the actual requirements that outline the solution. In Agile, these will be written in the form of a user story (as a user…), typically accompanied by acceptance criteria, to further accentuate the bounds of an acceptable solution to that requirement.
Conclusion
Whether you’re practicing Agile or Waterfall, the goal in writing product requirements is the same – to provide clear guidance to the team on what to build and why, so their efforts in defining the “how” can be rooted in that context. Writing effective requirements is the first step to being an effective product leader for your team.
