What is a Stakeholder?
In the context of product management, stakeholders can be defined as the set of people who have a vested interest in the product strategy and whose ability to do their job is impacted by new product deliverables.
For example, a digital marketing manager may only be able to run new digital campaigns if the product team delivers integration with the necessary third party services (e.g., Google Analytics). In this way, the product manager must balance the needs of all the requirements of all stakeholders across the organization while delivering on the product vision. Understanding requirements from stakeholders and managing relationships with them is a critical skill.
The diagram below shows some of the different business functions that can be stakeholders, such as Sales, Legal, Support, Marketing, etc.
Maintaining a Product Backlog
Product backlog has been mentioned in an earlier chapter of this course. The SCRUM Guide defines a product backlog as:
an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product.
Capturing stakeholder input
When anyone from Sales, Marketing, Legal, and other departments in the organization have a need to incorporate changes in the product, they have to consult with the product manager. It is important to realize that the product manager wields a lot of power during these exchanges where stakeholders request features. Therefore, adding an item to the backlog which includes the request makes the stakeholder feel like they are being heard.
The product manager typically operates like this:
Captures the needs of all stakeholders.
Adds the request to the product backlog.
Spends time understanding the real need and priority of the requests.
Creates a roadmap of themes.
Adds some features corresponding to the theme to the next work cycle.
The scenario above also illustrates the importance of themes. Read the following example for more information:
The head of legal is worried that some users might post illegal content so she would like to make sure that a report button appears beside each post.
The director of customer support hears about this request and knows that his team will have to examine all of these reports. He feels that he will need five more full-time employees in order to meet the predicted volumes.
The engineering manager has heard about a technology that can scan images to determine if they are offensive. He is eager to try this out as it might solve the problem or at least reduce the number of reports that the customer support team has to process.
The marketing manager wants to create a new section which tells the world how safe the site is to use. She wants to say that less than 0.001% of posts are removed because the community contributes such great content. She also wants a report to justify this figure and perhaps a live widget that shows this percentage on the site in real time.
If you read through this example, you can see that each of these feature requests may depend on each other. You may be able to solve all of these requests by taking a different approach. Rather than telling the stakeholders exactly what you will do in 3-6 months time, it is better to commit to investigating the problem. You can do this by creating a theme (e.g., Ensuring Post Quality) and allow for the team to research and choose the best approach later.
These feature requests can be put on the backlog. However, the product manager will select the workable solution and timeline.
Evaluating input
One of the most important aspects of helping stakeholders to be effective in their roles is to ensure that changes in the product help them to achieve their objectives.
When they make feature requests, the following questions help you to discover the underlying problem:
What do you want to achieve?
What is the cost of this problem today?
What would this feature enable you to do if it were built?
Can you tell me about the last time you had this problem?
You are trying to dig deeper into what the real problem is - what job the stakeholder is trying to do so that you can work with the tech team to find a solution. One technique that is very effective is to ask "why" five times in a row. This helps you dig deeper into the actual root cause or root motivation behind the request. This technique is often called the "Five Whys."
Sometimes, asking "why" five times in a row can be a little difficult (almost like a child asking a parent needless questions). For that reason, it may be more beneficial to ask five questions rather than only five "why" questions - and that technique is called the "Five Somethings." The point is to dig deeper until you find the real pain point or real opportunity that motivates the stakeholders' request.
Encouraging Input & Managing Expectations
Sometimes it can be difficult for a product manager to deal with multiple feature requests from many people. This is particularly so when working with a small tech team and limited resources. It's important to remember that this is a situation where other people in the organization are giving you input! This input is valuable. It is also important that the product manager captures this knowledge and keeps the stakeholders engaged. You don't want stakeholders to think that they are not heard as they might stop making requests for improvements that could be important.
Here are some tips for keeping stakeholders engaged:
Listen. Make sure that the stakeholder feels heard. It is also important that you understand the problem and its seriousness.
Consider. It might be tempting just to give a quick negative reply if asked for something that seems non-urgent. However, by adding something to the product backlog, you can capture the request, and later when batching feature requests into themes, you might see how some previously scheduled improvements can help with this person's request.
Dig. As mentioned above with the Five Somethings methodology, try to get to the heart of the matter and understand what job the stakeholder is trying to accomplish.
Be Creative. Even if you can't build a new feature, your knowledge or creativity might come up with a solution.
Build Consensus. If a stakeholder asks for something in a certain timeframe and you can't do it, explain what you will be doing and why it is vital to the company's objectives. Encourage the person to see the logic of your decision rather than giving a quick "no."
Summary
Stakeholders in your organization will request changes and improvements in the product.
Business functional teams like Sales, Marketing, Finance, Support, Legal, etc. are typical stakeholders.
Adding feature requests to your product backlog is a good way to capture inputs while postponing priorities until a later date.
Evaluating input allows the product manager to decide the appropriate themes that are important to add to the product roadmap.
Building consensus is the principal activity of a product manager. It requires excellent people and analytical skills. It is what makes the role so rewarding!
In the next chapter, we will learn how to create impact maps. An impact map is a visual diagram that lists deliverables (features) and explains how they contribute to the main business goals of the organization. Creating impact maps during a workshop session is an ideal way of brainstorming which can lead to identifying suitable elements for a roadmap.
