As a Product Owner, you are responsible for stakeholder management. It's important that you know your stakeholders, their interests, what they need from you and your Product and how they may be able to help you out as well! Stakeholders come in many different forms, they may be customers, users, managers, colleagues, etc. etc. and as a Product Owner, you need to manage them and collaborate with them effectively, in order to maximize the value of your Product. In this post, we'll cover 10 tips about stakeholder management. In the blogs to follow, we'll also cover tips on the other aspects of Product Ownership. I hope you enjoy them!
10 Tips about Stakeholder Management:
1. Start saying 'no' to stakeholders
As a Product Owner, your job is to maximize value for your Product. This involves making choices and it's best to do a couple of things really well, instead of doing a a lot of things halfway. This is a hard job! It's a job in which you can't satisfy everyone. Imagine a product you use yourself (almost) every single day... Is this a Product with tons of features? Or is it a relatively simple Product, which does a couple of things really really well?
In order to maximize value for your customers and users, you as a Product Owner will have to make conscious decisions, especially about what not to do! So, start saying 'no' to stakeholders! There are many different ways and forms of saying 'no'. As a matter of fact, a colleague of mine and I are writing a book on saying no, specifically for Product Owners! So keep your eyes open if you want to learn more about this! ;-)
2. Stop treating all stakeholders equally
Many Product Owners are very busy people. They always got tons of work to do, like refinement sessions, Sprint Reviews, writing Product Backlog Items and of course, those stakeholders that take up soo much of your time! If you are one of these Product Owners, than this tip may be one for you: Stop treating all your stakeholders equally! I encounter a lot of Product Owners, who spend tons of time on managing all their stakeholders, and this is certainly not a bad thing! I believe it's very important to spend a significant amount of your time on your stakeholders! But... These stakeholders should be your most important stakeholders (like the customer and/or the Products users). In daily practices however, I encounter a lot of Product Owners who spend all their time on all their stakeholders. Everyone seems equally important to them. But I'm sorry... That is just not true! Not all stakeholders are equally important! Some have a high interest in the Product, others have a low interest... Some have a lot of power, others don't... Some are you 'partners in crime', others are just interested in the impact of your Product on their department and people... So, you have to be more explicit about who your important, and not-so-important stakeholders are. In order to do so, create a Stakeholder Map for example. This may help you in spending/dividing your time amongst stakeholders in a more effective, efficient and smart way.
3. Stop managing stakeholders individually
In line with the previous tip, many Product Owners not only spend a lot of time on the 'wrong' stakeholders, but they also manage a lot of stakeholders individually, which costs loads of time! What I've done in the past and what I see some of the more effective Product Owners do, is to manage stakeholders in groups. For example: some Product Owners invite groups of users at regular 'demo' sessions (not be confused with the Sprint Review). In these demo sessions, the Product Owner / Developers show the new Products' features to a large group of people, sometimes even including some user/system training. These Product Owners invite other groups (such as the most important stakeholders) to the Sprint Review Events, in which they collaborate to decide on the next steps to be taken in order to maximize the Products' value. Then in the refinement meetings for example, they invite users, customers and other people to work out some new features, brainstorm on ideas and do market validation. So as you can see, you could easily save loads of time when you put your stakeholders together in the same room!
4. The customer is also a stakeholder
In many organizations 'the customer' seems to be someone who is 'scary'. I encounter a lot of Product Owners who are afraid to show a Product to customers which isn't 100% complete. They rather keep working on the Product for a longer period of time (whilst not getting feedback), instead of going out there and collaborating with customers. This is such a shame, since there are many customers and users out there who would love to collaborate more, in order to get Products that are actually valuable for them! For example, a couple of years ago ING Bank (in the Netherlands) released their first version of their mobile banking app to customers. This first version of the app only included a feature to gain insight in your payment bank account. Besides that, there was a feedback button. This functionality was all that was included in the first release, which was done to actual customers/users of the bank. By delivering this version, the bank got thousands and thousands of feedback responses from customers, which they used to develop the app further. So, don't be afraid for your customer(s)! Involve them in your products' development process, and you'll be amazed!
5. Act as an owner to increase your mandate
Many starting Product Owners don't have a lot of mandates (yet). On the Product Owner maturity level, they are often a Scribe, Proxy or Business Representative. A lot of these Product Owners we meet, are complaining that they don't have any mandates, any power to make decisions or any freedom. But guess what? There is something you can do about this!
Alright sure. So 'Act as an owner to increase your mandate'. What does that mean? Well, we've coached many Product Owners who were continuously asking permission or consent from their stakeholders. They asked permission to develop a new feature, they asked permission to spend some time on resolving bugs/issues, the asked permission to spend time on reducing technical debt. I'm not saying there is anything wrong with including/involving your stakeholders! But if you want to really become an entrepreneurial Product Owner, you have to stop acting as a scribe and start acting as an owner! The way you present yourself to the stakeholders, the way you present your Product to them and the way you act (talk, behave, your appearance, etc.) determine the mandate that you get! So, if you start acting as the owner of the Product, taking responsibility, making a plan (your plan), showing that you love and care for the Product and your team, will help you in increasing your mandate. To put it differently: 'If you don't make a plan for yourself, you will become (and remain) part of someone else's plan!'
6. Make your own plan, instead of becoming part of someone else's plan
The sentence which we closed off tip five with, is also tip six! That's cool! So yeah, as a Product Owner, or as an entrepreneurial Product Owner, you don't want to become part of someone else's plan I hope! You want to create your own plan, build your Product and make it successful. In many organizations that are adopting 'Agility', I meet people who say that planning is impossible in Agile, so we're not doing it anymore. This of course is nonsense! Of course you can make a plan in an Agile environment! But the way we look at the plan is a bit different though!
Traditionally seen, we want to create a plan, which we next want to follow and when we are deviating from the plan, we want to manage things as exceptions or problems, in order to get back on track with the plan. The way we look at planning from a more Agile perspective, is that a plan is actually a plan to deviate from! It is a roadmap, a forecast, something that guides us for a (short) period of time, but it is not 'the holy grail'. It is not carved in stone. And it is not that we have the illusion that we can predict what is going to happen in the far away future. But still... We have to make a plan. Otherwise, how can someone possibly know what to do? How will we determine where to go next? We have to make our assumptions clear, get a shared understanding of the vision, strategy and roadmap, but we also must accept that the world changes around us. That we can't predict what will happen 3 months from now. But we do need a plan to deviate from!
7. Stop spending (so much) time on your least important stakeholders
This tip is a bit in line with tip 2, which was 'treating all stakeholders equally'. Many Product Owners I meet spend most of their time on their least important stakeholders. The least important stakeholders, are often the ones with little power and little interest in the Product. Often, these are groups of people that should mainly be 'monitored'. You have to keep an eye on them once in a while, to see if their power or interest hasn't changed and besides that, you may want to send them a newsletter, post an update on the intranet or something similar, but you most certainly don't want to spend the majority of your time on these stakeholders! In daily practice however, I do see a lot of Product Owners that aren't following this guideline, so I hope you will take advantage of this tip.
8. Know your stakeholders' interests by heart
For some Product Owners, this may be an open door. For a lot of Product Owners though, knowing your stakeholders interests by heart isn't top of mind. As explained earlier, you have to manage your different stakeholders in different ways. You have to speak their language. What really helps in speaking their language, is if you know their interests. For example, if one of your stakeholders is responsible for the operations department, he or she probably won't be very interested in hearing about your new Product features. He or she may on the other hand be very interested in the impact of your new features on the straight-through processing (STP) numbers, the expected impact on the Net Promoter Score (NPS) or maybe expected process-efficiency gains. If you know your stakeholders' interests by heart, it makes it much easier to keep them updated, it makes it easier to speak their language and it probably saves you time as well talking to these stakeholders, when you know that matters to them.
9. Involve your Scrum Master / Agile Coach in stakeholder management
Managing stakeholders effectively may be rather challenging and complex from time to time. Especially with the more 'difficult' stakeholders. Although you as a Product Owner are responsible for stakeholder management, this doesn't mean you have to do it on your own! So, let your Scrum Master or Agile Coach support you! He or she can perfectly support you when you are getting a lot of questions about the development process, the way of working, why you're working Agile, etc. etc. Stakeholders (especially (senior) management) are often used to having 'control'. And this is important for them, since they are often responsible for running a (part of the) business. Control is important, also in Agile environment! The way we get control however, is quite different in Agile environments. We often use other practices, tools and techniques than we are used to. For example, steering committees are often not needed in Agile environments anymore. But you can't just erase them without replacing this control mechanism with something else. So let your Scrum Master or Agile Coach support you and your stakeholders so that together, you can find new/other ways of remaining in control, whilst increasing your Agility!
10. Don't be a proxy between stakeholders and the Developers
In tip 9, we just talked about being in control. Being in control is something that is often very important for starting Product Owners as well, just like for the stakeholders. What we see Product Owners do quite often, is that they start acting as a proxy, a gateway, the single point of entry, towards the Developers. The Developers aren't allowed to talk to stakeholders, customers and users. All communication in these teams is done via the Product Owner. This costs you massive amounts of time as a Product Owner and not to forget, it is also very ineffective and inefficient!
What we've seen more successful Product Owners do, is to support direct communication between stakeholders, customers, users, business people and the Developers as much as possible. This is way more effective, since the Developers can immediately embrace/adapt to the feedback on the Product. Also, the Developers get to understand the users and the business much better. Besides all other advantages, it also saves you loads of time as a Product Owner, when you do not longer have to act as a carrier pigeon (in Dutch: stop met postduiven!).
One of the things that starting Product Owners are often afraid of, is that the development of the Product will go in all kinds of directions, but not the right one. You won't solve this problem by doing it all yourself. Instead, make very clear agreements with the team! Make sure they really understand the Product vision, the direction you want to go to, and what the next steps are to be taken. Provide them with a clear Sprint Goal, to give them focus. Make agreements on how much change the Developers can embrace, before they have to get in touch with you. These kinds of actions and agreements will help you much more than doing everything yourself. And if something goes wrong, use the Sprint Retrospective with the team, to learn what went wrong and how things can be improved in the future.
So, these are the 10 tips for Product Owners on the topic of Stakeholder Management! I hope you enjoyed them and that they'll help you in becoming a better Product Owner!
Also check out these other tips for Product Owners!
Holy Guacamole! Are there even more tips for Product Owners? Yes there are! We've described 60 more tips for Product Owners, to help you to become better in your role! We've defined 7 aspects of Product Ownership on which we have interesting tips to share with you, so check them out: