When it comes to Product Ownership, there are a couple of things that are essential to get the job done right. Effective stakeholder management is one of them! In this blogpost, I’d like to outline a few tips that I found helpful being a Product Owner myself or when coaching and mentoring others in the role.
What the Scrum Guide says
So what does the Scrum Guide have to say about stakeholder management? You’d be surprised: Not too much. At least not on first sight. Although the word stakeholder is mentioned quite a few times (to be precise six times at the time of this blogpost). It states that “… the Scrum Team and stakeholders collaborate”, that “… information [concerning progress to a goal] is made transparent to all stakeholders” or that the Sprint Review participants “… include the Scrum Team and key stakeholders invited by the Product Owner”. However the details remain blurry. How does collaboration take place? Have we considered all stakeholders? Which of them are key?
Scrum is called a framework for a reason. In a complex environment best practices and cookbook recipes don’t make a lot of sense. You should fill the framework with stuff that is useful for your particular context and that is what we want to look at now for that effective stakeholder management we mentioned earlier. So let’s go ahead and look at three approaches that might help you as a Product Owner to work with your stakeholders.
Matrix of influence
I’ve used this particular practice - by instinct or accident - quite a few times and only later ended up finding it in the excellent book “Product Mastery” by Geoff Watts. Just start with a simple 4-quadrant classification. Label one axis “power” the other one “interest”.
Simple as that you now have a first classification of your product’s stakeholders
- Crowd (Low interest / low power)
- Context setters (Low interest / high power)
- Subjects (High interest / low power)
- Players (High interest / high power)
I’ve ordered the groups according to the - in my experience - increasing effort and time that should be put into your relationship with them as a Product Owner.
Your Crowd should be informed about your product. Usually it is sufficient though to make information available to them. It may be passive (giving them access so they need to pull information themselves) or active (sending out a newsletter, version notes for the latest state of the product or else).
Context setters are a tricky folk to deal with. They usually don’t show a lot of interest in your product itself however they have to power to influence your development efforts. Because of that you should be aware of possible connections of your product and their domain. It makes sense to establish a good relationship to them so they feel that possible needs and concerns of them might not be unheard. However, be clear about the fact that you as a Product Owner need to be the one who makes the calls when it comes to decisions for the product.
Every product also has Subjects that have a high interest in the product but do not have a lot of power to influence the surroundings or the product itself. However, this is definitely a group of people that should be taken into account. Given this definition they might even be users of your product and heavily influenced by whatever you as a Product Owner decide! Therefore it makes sense to include them as soon and as close as possible. Gather their thoughts, get their feedback, evolve a sense for their needs and use it to make informed decisions as a Product Owner. This is typically a group of people that might also be included in a Sprint Review.
Players are quite similar to subjects when it comes to interest and being affected by the product. What they also have is the power to influence their own fate - for better or for worse! This make them powerful allies as well as a possible nightmare for a Product Owner. Work closely together with them to benefit from their ideas as well as the strings they might be able to pull for you. Establish a trusting relationship but be also ready to work out constructive conflict! The goal is not to work FOR the players but WITH them.
To put the tool into practice, I usually recommend to identify the most important stakeholders for each quadrant. Then decide how often and with which type of communication you want to approach and interact with the different groups. Usually most time and effort is spent with the players but your mileage my vary.
Diffusion of Innovation
I found the following approach especially useful when developing a completely new product. It helps to find out which stakeholders to address to really get attention, to manage through a growing base of users and economic success. The model itself goes back to Everett Rogers and is used to illustrate how innovations are communicated over time within a social system.
Simply put, a product will be adopted in the market at different rates by different groups of people. The innovators are the ones most willing to trying out new things. Unfortunately they are also the smallest group and are easily bored if things don’t change fast enough. On the other side are the laggards. Timewise they will be the last ones to even hear of your product. Hard to convince and win but quite loyal once they have decided to use it. As a Product Owner you can use this once again to categorise your stakeholders and approach them.
Innovators are always on the edge of every new development. Already looking for the next one around the corner. It might be easy for you to get their attention - if your product provides new features and looks - but it is also hard to keep them interested. For this group of people you need to provide information fast, allow them to use the product and interact with it as soon as possible. They want to feel special and love having information and access sooner than anybody else. Their feedback might be helpful in further developing a product but expect rather too many ideas from their side which you can’t possibly all be taken care of. In addition they are usually not a very big group of people (2,5% of a specific target group) so balance your efforts in addressing them.
Early adopters are almost as easily to attract as innovators. However they usually are a bit more conscious in their choices of new products. However they tend to be a bigger percentage (13,5%) of your potential customer base. They are also considered to be opinion leaders (which means: each group coming later will look into their direction and will be influenced by them) and that makes them a very valuable stakeholder group to interact with!
Your products early majority will take an even longer time than early adopters to make use of a new product. They are usually influenced by the groups before rather than influencing things themselves. This is the beginning of a wide distribution over a whole market or a specific market segment and if you are targeting this with your product: Get these people on board. They are obviously too many (34%) to include them all. So think of strategies to at least include a significant amount of key stakeholders here.
The good thing is: The late majority of your user base can be addressed in a quite similar fashion. They share almost the same traits but will be willing to adopt a product a bit later. Most likely because it has been recommended by some people earlier in the adoption curve. Together with the early majority they represent the biggest group of potential customers (34%).
Laggards are the ones that are the latest adopting something new, clinging to tradition and things that have been there for quite some time. Therefore they will be hard to convince to adopt your product. Usually you’re time and effort is better spent elsewhere and it should be enough to keep them informed. They also tend to be a not too big a group (16%).
Users / Influencers / Providers / Governance
Another way of bringing structure into stakeholder management is to find out in which way they are interacting with your product our your development effort. This model classifies stakeholders in four different categories. Users, influencers, providers and governance.
Users are simply explained: They will be using your product. Here, it makes sense to work with personas to get a better feeling who they really are. A strategy I’ve also used in the past is to combine it with the “Matrix of influence” to add a bit more detail. Their feedback is important to determine whether your product resonates with the intended target group.
Someone who is an Influencer for your product might also be a user. The only difference is that as an influencer they have the power to change the direction of your development effort. This might happen indirectly (because you listen to them as a Product Owner) or quite directly (because this group of people usually have the means to make their voice heard). Keep them close to make sure you keep the ability to set the direction for product development.
Stakeholders who fall into the category of a Provider will obviously supply something for your product (e.g. a supplier or vendor). They might also be a business partner. Although they usually don’t use the product themselves, they can determine its success or failure if you are not aware of who they are and keep a healthy relationship with them.
This is even more the case for everybody in the role of Governance for your product. They might either have the interest and means to influence product development (e.g. the law, regulators for your market or auditors) or playing a governance role within your organisation (e.g. the management board, health and safety, compliance or even C-level in general). It is important to find out who those people are. Otherwise there is a pretty good chance that they will find you. Together with them determine how you interact, which decisions are up to you as a Product Owner and for which you need to consult with them beforehand. Your goal should be to be able to act as independently as possible while using the knowledge and support governance might provide.
Having introduced those four groups, be aware of one thing: It might also be the case, that one person is acting in different roles as a stakeholder and in his relationship to you. In that case it the models help to make this fact transparent then act upon it so there is less confusion.
What you should take away
Altogether I recommend three things that can be a helpful start with stakeholder management:
- Be aware of the fact that every product has stakeholders. Even if you don’t know them yet.
- Find out who they are and if there are similarities that allows for some kind of grouping.
- Decide on specific ways of collaborating and communicating with each group.
It also makes sense to use an empiric approach here by inspecting and adapting as you collaborate with them as a Product Owner. You might very well combine all three of the approaches above and make it fit to your own world. As always - all models are wrong, some can be useful.
I wish you all the best in your endeavours and appreciate your insights, experiences, thoughts and further ideas in the comments!
Scrum on!