How I approach stakeholder management for product teams
You need to control the narrative around your team and work
This was the feedback given to us from an executive responsible for the product our team works on. Our team's product manager and I (engineering manager), had just presented the progress we had made for the quarter, the plan for the remainder of the quarter and what we were looking to tackle next.
Two stakeholders had been chatting among their senior leadership team about what we had been working on. Both different in what they disagreed with, but common in their belief was there was higher priority work we could have delivered. The problem for us was not that the work was wrong, but we hadn't identified the stakeholders desire for more direct involvement and our lack of communication in why some work was chosen over others.
This led me on a journey to research and experiment with how I communicate with stakeholders.
To improve relationships and confidence in your team's work. Start with identifying stakeholders
First up, I find the term "stakeholders" to be vague, it's not well defined and or understood, often with different meanings across teams or organisations. The very first step I like to take is understanding who your stakeholders are through stakeholder identification. When starting with stakeholder identification I like to look at it through the lens of the DACI framework, which is a decision making framework for teams; and stands for:
- Driver - Who drives the decisions for the team or project. They don't have to influence or make the decision, but ensure it happens and stakeholders are informed.
- Approver - Who is ultimately responsible and approves the decisions being made.
- Contributors - Usually subect matter experts that inform the decisions that need to be made.
- Informed - Anyone else that may be impacted by the team's decisions or have an opinion on the project.
I'll focus on Contributors and Informed parties as this is usually where we can lack clarity or understanding our stakeholders needs.
Understand what they will be contributing, how it fits into the project. Often when their contribution is important but not a core aspect of the project their input can sometimes be impacted by trade-off decisions you and your team need to make. Try to have an understanding of how a contributor will be contribute to decision making, will they be invited to project meetings or will you seek them out separately?
Work out how they may be impacted by your project, if you're unsure, even if you are sure I would still recommend reaching out to them to see if your viewpoint is correct (it's often not) and if there's anything further they can add that you may not know. We often have a tendency to avoid conversations with people we are not close with. Over and over I see people design convoluted systems and processes in order to avoid actual conversations that may be uncomfortable. This usually always involves poor outcomes.
Have a clear communication plan
You are aiming to: build trust, educate and promote new approaches and gain feedback.
Once you have identified your stakeholders, I like to then create an open dialogue. In product delivery teams, an engineering manager and product manager together have as close to the full picture of the work for your team. Stakeholders and others who are not embedded will have different pieces of the whole. Telling that story and filling in what is missing for outsiders should be a priority of yours. I think about at it as the synthesis of what you have learnt, what you're doing now and what's next. This usually involves collaboration between engineering, product, analytics, design and other functions relevant to your work. Putting that together and telling that story of the whole.
Using DACI and the analysis you have done previously, invite appropriate contributors along to ideation, team and project meetings and have them involved with ideas and making decisions. Often you will have established ways of updating and presenting to stakeholders, this doesn't always capture all interested parties. Below are some ideas I have for recording and broadcasting your communication to reach people and keep them updated in a way that is proactive and avoids others chasing you.
Ideas on how this can be actioned
Most of these suggestions should help get your ideas in front of others and help them understand what team is thinking and planning, the earlier you share your progress the better in my experience:
- Slack channel or email list sent to stakeholders - I like to create a Slack channel that's focused on your team's mission and invite all stakeholders and anyone interested. From here you can regularly send updates on your team's work and progress to your goals. The great thing about these distribution channels is that it's easy for others to forward to or add interested people, whom you may not be aware of.
- Project coordination meetings - If your project involves coordination with other teams, you should consider organising regular meetings for that coordination. Whether project circles, standups it doesn't really matter, the main thing is to have a mechanism for coordinating alignment and understanding. Then during execution to ensure teams are unblocked and able to deliver.
- Results documents - If you ship often you will likely be able to measure the impacts of your changes against your goals. I like to use experiments as one way of achieving this. As your results are analysed, compile them in a document that can be shared with your stakeholders and others in your organisation.
- Roadmaps - If you are a product team with a clear mission and goals you will likely have a roadmap spanning quarters or years, often containing the direction you're heading and what you plan to release, with hypotheses for the work will and how it will impact your goals. Share this, get feedback and be open to receiving it!
- Quarterly / Annual planning documents - Following on from the roadmap many organisations will plan work quarterly, you can take the things your team will work on and go into a bit more detail around the execution of what you will be doing. Another opportunity to share and often this type of planning requires approval.
- Iteration or sprint reports - Send progress on what your team has worked on and delivered during your last iteration. This is a lower level update, so usually not appropriate to all stakeholders interested in a particular project or product area, but is a really quick and useful way to transparently report on what's happened recently.
Ultimately you want to build trust and relationships with your stakeholders and gain their support. By doing this you are likely demonstrating a history of delivering good work and thinking of others when you are making decisions. If you do this well your stakeholders will give you a greater chance to take on riskier and more ambitious projects in the future. Sometimes you will disagree with feedback from stakeholders and sometimes they will disagree with what your team. That's great, you're getting direct feedback that otherwise may not have reached you!
As you ramp up your communication, it's an opportunity to increase your profile in the organisation, especially when it's a high profile initiative.