As a product manager, balancing the priorities of product features with their level of detail is key to shipping the best product as quickly as possible. Understanding the context that the business operates in gets you to the right product feature priorities. Translating those features into technical requirements that faithfully represent the needs of the business, market, and the product is challenging. What is the right level of detail to provide direction to the development team? You will know that your development team is on the right path when you can answer key questions during the product development lifecycle.
What is a Requirement?
Before we start, let’s get a clear understanding of what I mean when I use the term “requirement.” In this post, I am not specifically talking about the artifacts generated by this process such as user stories, non-functional requirements (NFRs), and other documentation. Those are manifestations of the requirements that will be used by the team to build or update the product. At their heart, and what I’m getting at in this post, requirements are a translation of the business desire into language the team can use to better understand the problem the business faces and how to fix it.
The Questions You Ask Drive the Requirements You Need
The understanding of a product is a layered approach, from a high altitude view of the context in which the product will operate all the way down to the weeds of specific implementation guidelines. Rather than a linear approach, think of this as a map view with a sliding zoom-level that you increase or decrease according to your needs. This means:
- It is not linear. You will zoom in as your understanding increases, and zoom back out when you uncover unknowns or a change in the product’s context.
- It is a wide rather than a narrow focus. While you have adjusted your zoom to one level in order to focus your requirements gather effort, you will simultaneously refine your understanding at a higher zoom-level and begin to sketch out your findings at a lower level.
As a product manager, you can gauge where a team is by asking the following questions. The answers you get will tell you where they are in the process.
What Is the Scope?
Before you do anything, you need to understand the scope of the problem you are trying to solve. Who are the actors directly affected by this problem? What are the objects they are manipulating? Who has an impact on these actors? Who is impacted by them? And who has a stake in this whole process?
Answering these questions allows you to further answer who must be served, who must be kept happy, and who is a lesser priority. That is, what is the scope of the problem we’re trying to solve? This exercise also drives a common terminology that describes the users, stakeholders, and objects processed by the system. This will minimize future miscommunications.
When reviewing these artifacts with the team and the stakeholders, you will know that they have the right level of scoping requirements when there is consensus on who are the current users impacted by the perceived problems you’re addressing and who might be affected by any changes. If it appears that there is a lack of agreement, then the team likely needs greater detail on the context. Usually, it’s because a role perceived as a single actor is really two or more when, for example, there are disparities in skills.
What Is the Problem?
Given the answers we documented when asking, “What is the scope,” we can now define the problem we are trying to solve. The team starts with the problem as communicated by the stakeholders and then determines the root causes. They should clearly define all of the terms that come up during these sessions to make sure people are talking about the same thing.
The goal is to build a consensus around a precise problem statement of a sentence or, at most, a paragraph of text. The typical artifacts generated at this stage to support the problem statement are process flow diagrams and data models that document the current state and the deficiencies in it. At this stage, we’re not considering solutions or implementation, solely a definition of the problem.
You will know the team has this nailed when you ask all involved, team members as well as stakeholders, what is the problem and get back a consistent answer from everyone. Inability to provide a definition is clearly an indicator that the team has a lot of work to do. Inconsistent answers may just indicate that they were still in the process of formulating that statement. Major events, like changes in business plans, also lead to redefining the problem.
What Does Success Look Like?
Before you can suggest solutions to the problem, you need to understand what viable solutions might look like. You’re looking to develop a rubric that can be used to evaluate possibilities. This is the transition point from defining the current state to mapping out the desired future state. Building consensus at this stage will head off costly changes as the team begins development.
Helpful artifacts at this stage are NFRs and wireframes that describe how a good interaction might play out. The team will begin to map out epics and user stories at this stage. While you should try to remain implementation agnostic, you may be constrained by current business practices to only consider certain implementations, such as the CRM tool your organization is using.
I’m sure you have considered some possible solutions. Informally run them by the team to see what they say. If they provide you with precise reasons why that may or may not be a good idea, then you’ll know they have a good grasp on the success criteria. Likewise, with the stakeholders, see how their ideas for a solution have changed over time and how they support their ideas. Hopefully, they don’t diverge too much from the team’s understanding.
What Is Our Hypothesis?
Given the problem statement, what set of features does the team believe will drive a result that looks like the definition of success? This needs to be presented in a form that the stakeholders can understand and knowingly agree that this is the approach to take.
The requirements at this stage will be represented by more fully-formed user stories that make up your product backlog. These will be backed up by more detailed mockups that demonstrate the user flows. You should also include at least a straw-man release plan to give the stakeholders an understanding of the level of effort required. You know you have the right level of detail when your team can t-shirt size their estimate of user stories that make up the hypothesis.
Can the team and the stakeholders tell you the hypothesis? It doesn’t have to be a rote recitation, just a sense that everyone still is in agreement on the problem statement and success criteria, as well as what set of features to be built.
How Do We Test Our Hypothesis?
This is the nitty-gritty. How do we cheaply and quickly determine whether our hypothesis is on the mark? How can we get a set of working features into the hands of those who can provide the feedback necessary to determine whether we’re building the right product?
To be effective at this stage you need to maintain a groomed product backlog that can be used to feed the sprint backlog during sprint planning. This means enough detail for the team to understand when a user story is done and provide greater detail in their estimate of the effort required to implement it.
You judge how well the team is testing their hypothesis by the working software they deliver. Disproving the hypothesis is not necessarily a bad thing, especially if done early. You want to make sure the team is drawing the correct conclusions from the feedback they are getting from the stakeholders and others who are using the software: Does the hypothesis need adjusting or what they’re building? Likely a combination of the two. That’s the essence of getting to the right product.
It Ain’t Over Til It’s Over
Implicit in asking when you have enough requirements is that the process of gathering them has a specific path with a distinct ending. Requirements gathering, however, should end only when you retire the product. Things change constantly: new business objectives, new customers, existing customers’ needs change, etc. The moment you stop gathering requirements is the point in time when you’re understanding of the environment in which the product operates begins to get stale. The requirements are like a garden: they need constant care and attention. Likewise with your worry over whether you’re building the right product.