Stakeholder management is a core activity for anyone working in product development. It is key to building a successful product in the confines of a company. Also, it is rarely a topic of conversation. Many accept stakeholder management as an abstract concept. They don’t actively try to shape it by putting upfront thought into a stakeholder management strategy. Instead, they improvise as they go along. This often leads to problems.
Today, I want to demystify this topic. I want to explain what stakeholder management means, why it is important, share my default stakeholder management plan, and give practical advice on conducting it effectively.
Let’s start with a definition.
The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox.
What is a stakeholder?
A stakeholder in product development is anyone who can affect or is affected by the product team’s activities. This includes other product teams, company leadership, departments like sales or marketing, shareholders, suppliers, and customers.
Essentially, anyone interested in what you are building is a stakeholder.
In this article I will focus on internal stakeholders. They are relevant to almost all product teams but rarely talked about. I’m excluding customers, even though they are arguably the most important stakeholders. Understanding them better is a theme across many of my articles.
The importance of stakeholder management
Stakeholder management is important for two reasons: building trust and aligning activities.
Building trust is crucial with stakeholders that are in a position to allocate resources. Leadership wants to know that their investments in the team are well spent. A lack of trust is the main reason why stakeholders prescribe features to a team and demand the typical feature based roadmap. Thus, building trust through effective stakeholder management can be leveraged to empower the team.
Creating alignment ensures that different parts of the company move in the same direction. Depending on the product, the development activities may need to be aligned with other product teams to ensure they are not interfering with each other. Additionally, the activities need to be aligned with sales and marketing teams (and possibly others) to increase the likelihood of product success in the market.
What is stakeholder management in practice?
Stakeholder management is essentially constant communication with all important parties. Yes, this means many, many meetings. And yes, you will need to repeat yourself often.
The goal is to let product development flow as smoothly as possible by keeping everyone informed about what is going on, understanding stakeholders’ motivations and concerns, taking their inputs into account, and soothing their ego when necessary.
It is not overly complicated but it requires proactive effort. You should create a stakeholder management strategy.
My default stakeholder management plan
The following is my default stakeholder management plan. It works well for most situations. However, you might need to tweak it to fit your circumstances. The elements of the stakeholder management plan are shown in the table below.
I generally use the same basic three agenda points for all elements: what happened since we last spoke, what will happen next, and open discussion.
|At least once per iteration
|Share information, avoid meetings
|Gather feedback on last iteration, opportunity for team to showcase what they built
|Specific groups with distinct interest
|Align on short to mid-term plan, discuss issues specific to the group
|One to one
|Build trust, align on short to mid-term plan
|Other dev teams
|Align development activities
First off, there is a lot you can do asynchronously in writing or by sharing documents. This can significantly reduce the time spent in stakeholder management. At the very least, you should regularly share in writing what the team completed in the last iteration.
There are infinite possibilities and some companies default to asynchronous communication. Nevertheless, synchronous communication is in my view more effective in building trust.
Thus, I highly recommend combining asynchronous and synchronous communication.
I won’t go into much detail here. I have already written about the review. Just this much: you need to regularly gather feedback from stakeholders on what you built. A demo or review is invaluable for this. It is also motivating for the team members to show what they built. Even if you are not using Scrum you should implement a regular review or demo.
A regular product update is a great way to manage a distinct group of stakeholders and address their specific needs. As an example, in the B2B setting I have found it helpful to set up a regular update with all sales people.
I generally invite monthly. Depending on your circumstance this could also be quarterly. The meeting lasts one hour with the following agenda:
- 15 minutes: what happened in the last month
- 15 minutes: what is the plan going forward
- 30 minutes: open for questions, concerns, and suggestions
I always share the roadmap or any relevant metrics in this meeting. With this update, the group always knows what is happening. They feel that they can give input as well. It’s also a great place for them to vent and complain. 🙂
The developers can be present. But more often than not, this meeting covers topics they are not interested in. Most of the time, it makes more sense for the product update to be between the product person or project leader and the distinct group.
A side note: Some projects or products, especially in large corporations, have some sort of steering committee that is tasked with making the big decisions. If that’s the case for you, I would treat it similar to the product update. Depending on the organization it will be much shorter, though (max. 15-30 minutes). Just make sure the decisions are aligned upfront, see the practical advice below.
There may be people who are particularly interested in your product. Maybe it’s the CTO because the team is working on the technical infrastructure that is important for the entire company. Maybe it’s a particular sales VP because the product mainly influences her customers. Whatever the reason, these VIPs get one-on-one treatment.
For me, a bi-weekly conversation of 15-30 minutes is generally enough. I go more or less with the same structure as for the product update:
- 5 minutes: what happened
- 5 minutes: what’s going to happen
- Rest: open discussion
This might seem counterintuitive, but I prefer to set up many one-on-one calls at the beginning, even though I try to avoid meetings. I have found this approach to pay off later.
Some people don’t feel informed enough and request (demand?) this one-to-one treatment. It seems this is somehow mainly true for those that you need support from but are not incentivized to help you. Thus, instead of starting off on the wrong foot, I suggest setting up too many rather than too few one-on-one sessions with these key stakeholders.
You will likely find that some of these VIP sessions are not very productive. Particularly, the folks who demanded them tend to miss them often. You can always cancel if that is the case. Everybody is happy to have fewer meetings. By setting up the meeting in the first place you have shown a willingness to involve them. Thus, you have already built some sort of trust which may serve you later.
Product teams sync
This is the place for different product owners, product managers, or project leaders to align. If the team structure and product architecture allows the teams to operate independently, you don’t need this meeting. You can then align on an ad-hoc basis.
However, if there are dependencies or if the teams are working on a shared initiative, it does make sense to align on the next iteration. This reduces the risk that teams are blocked by one another.
Practical advice on conducting stakeholder management
Having covered the basics of stakeholder management, I want to share three pieces of practical advice that increase its effectiveness.
- Take notes and follow up!
- Avoid (negative) surprises in big groups
- Let stakeholders complain
Take notes and follow up!
I almost can’t believe I have to write this. It is basic but many don’t do it. Take notes, share them, and follow up on To-Dos. Acting like a professional shows you are organized. This builds trust.
If you’re struggling to find time to create some sort of meeting minutes, two things are helpful to me. First, create the meeting minutes during the conversation. Share your screen and ask for a minute to summarize after each discussion point. I often use Miro for this. Most of the time you don’t need to worry about the quality of the writing as long as the contents are summarized.
Second, create a 15-minute time-blocker after every meeting by default. Use this time to formulate meeting minutes and To-Dos. Cal Newport calls this scheduling meeting margins.
Avoid (negative) surprises in big groups
In the corporate context, there is no worse place to give bad news than in a big group setting with leadership present. Most managers hate surprises in these circumstances.
If you have bad news to share – and the timing allows it – make sure to inform the important people and opinion leaders upfront in separate one-to-one discussions.
The same goes for big and difficult decisions. Don’t just spring them on the leadership. Go to the people most affected, explain your reasoning, and agree on a decision proposal. That will make the actual decision go so much smoother.
Let stakeholders complain
Especially in the product updates that are less formal than steering meetings and more intimate than a big demo, you might end up creating an atmosphere where people vent their frustrations every once in a while.
Their frustration is often not really directed at you or the team’s efforts. More often than not, it is caused by decisions made by others that you both are feeling the consequences of. If you have a decent relationship and as long as the complaining doesn’t become personal, just let the person vent their frustrations. Try not to react and stay calm. This will create trust.
To defuse the situation, the words “I understand your issues and will talk to the team about addressing them” always help. Even if you are not going to do anything about the topic, it usually ends the rant. The next time you talk about it, the person will likely not be as animated.
Stakeholders are humans
Successful product development is not just about the product, but also about the people involved. Product development is a people’s business. Stakeholders are humans. Effective stakeholder management is crucial.
Building trust and aligning activities is the key to navigate the complexities of stakeholder relationships and drive our products towards success. The key is constant and open communication. If you do it in a structured way and create a plan, you’re already ahead of the game.
Coverphoto by rawpixel.com on Freepik