Excellent stakeholder management in one form or another is one of the most important things you need to do well as a product owner (PO) to maximise your product’s value.
As a PO, you are responsible for stakeholder management and working closely with your stakeholders to define and refine your product. Practically, that could be anything from helping to define your product vision all the way to refining individual items on your backlog. You can’t deliver the most value for your product without your stakeholders. There are lots of great tools you can use to help. One of my favourites is something called the Empathy Map Canvas from Gamestorming.
This tool is also useful to complement any customer persona work you might be doing.
Let’s step back for a moment first. How many times have you been involved in a project or feature for your product, started down a path and sometime later, an important decision maker suddenly appears? Where I work, I probably have to deal with dozens of different stakeholders each month. Each product, programme, project, product backlog item and small work request will often have different groups of people involved. So whenever I start a new project, I use a simple RACI chart.
If you’re not aware of it, RACI stands for Responsible, Accountable, Consulted and Informed. Gamestorming provides a simple game for teams to use, which is recommended. There are other models like RAD, RAPID and others, though I use RACI — which is well understood in my organisation. A RACI chart allows you to quickly plot stakeholders against how you should engage with them. Typically, it will help you understand roles and responsibilities and how closely you should manage your stakeholders.
For our purposes as a product owner:
- Responsible: who are the people doing the work, or who do we need to help us achieve our goal?
- Accountable: who has the final say? Who has the authority to accept or reject the work?
- Consulted: which stakeholders do we need information or a view from to help us refine our work? Stakeholders in this group will involve two-way communication by you as a PO.
- Informed: which stakeholders need to be kept updated with what’s happening (usually after a decision is made). This will usually involve one-way communication by you as a PO.
And as a PO, my product backlog is always visible to anyone who wants to see it. That’s how I have always worked, and I have found keeping high levels of transparency has helped me in many ways. Everyone on my RACI will be able to see my backlog. Whether they take the time to look at it is another matter!
The stakeholders in the Responsible category are people I usually know very well. Those in the Informed category, I keep up to date though generally on a semi-regular basis. Broadly, I worry less about those two groups — either because I’m dealing with them frequently or because I deal with them infrequently.
The stakeholders in the Accountable category are often senior managers in my immediate team, though many are often leaders across the wider business.
It’s the Accountable leaders I know less well and everyone in the Consulted category I usually use the empathy map canvas.
Once you have mapped out your stakeholders and determined which ones you should be speaking with and how often, the next question you want to answer is ‘what makes them tick?’ When you come to have those conversations, what is the best way to influence them? What are their concerns and, for you as a PO, how can your ideas and solutions solve those worries?
Being a PO often means taking your stakeholders on a journey with you. You’ll be working with them to understand what is most valuable to your customers. This will help ensure you build the product around your customer. As your thinking becomes more developed, you might need their guidance on the right tests to run or help to understand the insights you’re getting as increments start hitting your market. Or it might be as simple as understanding how best to structure your Sprint Review sessions or in general backlog refinement. Either way, understanding what makes your stakeholder tick is a powerful insight. The empathy map canvas has helped me many times.
What I love about this canvas is just how visual and clear it is to add insights. It’s a brilliant tool to help product teams develop and refine a really clear shared understanding and empathy for the people who matter most in their world, in many contexts.
As a PO, I’ve used it by myself ahead of an important meeting or session to work out how to pitch something. As a Scrum Master, it’s been a great tool in a Retrospective to work out what’s going wrong in a relationship or help the team understand how better to interact with someone. It would also be powerful as part of a design or planning session.
I use the canvas in the way it’s been designed. I start with the grey ‘Goal’ section at the top. I define who the canvas is about and what goal I’m trying to achieve by using this. I find this works best when you explain something you can observe or a clear outcome.
I then continue to work around the canvas in numerical order. If you are vague on some of the details, don’t worry. This is something to file away and refine as you get to know your stakeholders better. I will often come back to mine and add more insights as time goes on. The important thing here is that you’re trying to understand what it’s like walking in their shoes. You want to understand their experiences and concerns. The next part is when things become interesting.
Once you have gone around the canvas, the final part focuses on what is happening inside their head. Getting useful insights into how your stakeholders’ think’ and ‘feel’ is the exercise’s ultimate purpose. Once you correctly unlock these insights, it has the potential to transform your relationship with that person.
There are also complementary practices which help can more insights — for example, adding data from their DISC personality profiles. I’m a big fan of DISC and will write about it in a later blog.
I keep coming back to this excellent tool time and again, in many different contexts. It’s one I recommend to the teams I work with.