Skip to main content

10 Tips for Product Owners on Stakeholder Management

December 1, 2017

Stakeholder Management
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:

  1. Agile Product Management
  2. (Product) Vision
  3. Value
  4. Stakeholder Management
  5. Scrum Framework
  6. Product Backlog Management
  7. Release Planning

What did you think about this post?

Comments (18)


Alan Larimer
10:08 pm December 1, 2017

This post has some great points that are stretched into a list of ten. (Because that is a common list item count?) Let's boil it down and improve it:
1. Maximizing value means knowing the customers and the market.

2. Focusing on value includes not including all desirements in the Product Backlog.

4. Much like prioritizing the value created via ordering the Product Backlog, focus on value regarding stakeholder interactions.
5. Customers are one of, if not the, most important stakeholders. If they do not receive value, then why are you making a product?
6. Do not become a barrier. Promote customer interaction with the rest of the Scrum Team and delegate some work to others.

Having an additional "demo session" that requires Development Team participation is waste. If additional demonstrations and training are needed, find other sources to address those needs.


error406
06:36 pm March 16, 2018

Tip #10 is clearly written by someone who has never been done any serious software development in his life. This is also why so many developers have started to hate scrum, it's been reduced to typical consultant BS by people who don't understand the actual craft of software development. Sure, developers should have access to customers and users when they need info or feedback, but no way should stakeholders have access to the development team.

Opening up direct communication ensures no developer can get any decent work done unless they burn themselves out. Whatever happened to the basic principle of the whole thing being sustainable? Hell, even the PO shouldn't be actively interrupting the developers, let alone the stakeholders.


Paul
10:50 pm March 28, 2018

Those are very real concerns. I would recommend reading through the Scrum Guide as it does address them.


Alan Larimer
12:37 pm September 4, 2019

You have a valid point. Any concerns or issues such as reduced value delivery due to overwhelming customer interaction should be addressed in the Sprint Review or, if necessary, sooner.

The telephone game (intermediate communicators) is a challenge within the traditional project management approach that resulted in misunderstandings in understanding user needs and feedback.

One technique that has worked for some Scum Teams is having a user as a Development Team member. This "position" could be filled by a specific user significantly affected by or invested in the Sprint Goal.


Omar Morales
04:34 pm November 23, 2019

I'd like to see the author comment on this great point by error406.


Alan Larimer
10:41 pm December 24, 2019

Most of the bloggers do not "Join the discussion..."


Saurabh Sharma
11:48 pm December 22, 2020

I don't think author here meant bombarding stakeholders at the dev team. Intent is you open up a direct channel if/as needed. One great way is too have them more involved during refinement sessions which anyway team may already be planning to attend.
Note any stakeholder interruptions that deviates team from meeting sprint/product goal is, anyways, supposed to be addressed by scrum master.


Alan Larimer
01:35 pm December 24, 2020

It's quite clear that nobody is advocating for bombarding the Developers (formerly Development Team). Where did you get that impression?

Product Backlog Refinement is a good option for Scrum Teams to consider.

Helping those outside the Scrum Team understand meaningful interaction with the Scrum Team is part of the Scrum Master's role. However that does not mean that the Product Owner or a Developer cannot be a part of that solution also.


Patrick
08:57 am December 29, 2020

Any idea where the book "50 Shades of No" is available today?


Adam Frischkorn
03:56 pm March 20, 2021

Thank you for tailoring major portions of your message to new POs! As someone early in his journey, I find many posts are for more seasoned individuals. I'm sure there are many others like me, so I greatly appreciate the tips for us newbies.


Flavia Ferlito
12:37 pm April 7, 2021

the article is from 2017, in 2020 scrum guide I read "the scrum team is responsible for all product-related activities from stakeholder collaboration..[..]" I haven't seen any explict mention to PO who manage stakeholders.
is As a Product Owner, you are responsible for stakeholder management still valid? does this sentence mean the Po is the main reference to engage stakeholders?
Basically, I got the doubt if the Whole scrum team manage the stakeholders or it is a PO responsability"
Thanks


Andre Bittencourt
09:05 pm June 27, 2021

I would say that "Maximizing value means knowing the customers and the market." is a bit far-fetched and the main reason is that you simply don't know any or would make a huge effort to know them beforehand. So maximizing value means shortening your time-to-learn through frequent releases of a product increment where evidence will help you uncover more information towards your customers and market.


Alan Larimer
03:39 pm July 3, 2021

Thank you. It seems that we are on the same page. Perhaps "learning" instead of "knowing" would have been a better phrasing.


Giulia
07:26 am November 10, 2021

As for the paying system you use, I heard https://m4bank.com/softpos is getting more and more popular. And it's pretty handy


Katrina Latyshava
01:16 pm May 14, 2022

So, is there a book on saying 'No' ? )


Alan Larimer
07:00 pm December 5, 2022

I am certain there are many. :) It used to be socially taught as a value regarding setting healthy boundaries.


Alan Larimer
07:03 pm December 5, 2022

I haven't examined the more recent changes as I have been out of the product development and process efficacy business for several years now due to the constant feeling of attempting to push a boulder up a mountain. I assume it's a part if the authors' desire to make the framework less prescriptive. Great questions!


Katrina Latyshava
07:21 am December 19, 2022

Well, yes ) Thank you, Alan.