Ask a Product Owner #3 - Stakeholder Management

💡 Please let me know what topic should I address in a future session of 'Ask a Product Owner'! 💡

On LinkedIn, all my connections and followers had the opportunity to ask any burning question they might have related to Stakeholder Management.

I’ve packaged all the questions anonymously here together with my answers. I also sometimes bundled together variations on the same question (or because my answer to them is related).

Let's start with the questions!

Should we consider end users as stakeholders?

"In my experience we often consider the stakeholder to be people directly involved with the product. So business owners, managers etc. what about the customer ie the end user? Should we not consider them? Should we consult with them?"

The loudest voices standing at your desk often get the most attention, but in fact, unless the customer cares about what you're doing, and it makes a difference in their lives, it doesn't really matter how much you please your stakeholders. Your product won't succeed.

As Kathy Sierra has said: "Don't upgrade your product, upgrade your user."

Try to understand how they are (trying) to solve the problem at the moment, what they like about the solution, and what struggles and frustrations they are facing. What other options did they consider? Etc.

Without understanding what they are trying to achieve, you can't help them to achieve it.

How do you resolve priority conflicts between stakeholders?

"In case of two or more stakeholders are in conflict with their vision/problems and priority. How do you enroll them in a possibility that they all agree on and is best for the product?"

I'd meet with the stakeholders in question, separately, and ask for their help. Explain the problem, without mentioning names, and how you could best resolve it.

Of course, you already have ideas on how to solve it, but generally speaking by involving them in the solution, you will immediately obtain their buy-in.

Likely, the conclusion should be:

1. Competing priorities / different visions is a problem we should fix.

2. We should fix it by agreeing together on what matters.

Ultimately, if you don't decide what matters, it will be decided for you. It's about control. And that's also how I would present it to them.

Do you want to have control over what we do? Or do you want to leave it up to chance?

What is the difference between stakeholder management and stakeholder engagement?

"(tongue in cheek) what's the difference between stakeholder management and stakeholder engagement? Which do you prefer?"

Here's my take, but curious to hear your perspective.

Stakeholder management is about involving stakeholders who will be affected by what you're doing.

Management implies you're managing them. Engagement means it's a more equal relationship where you collaborate together on what best to do. Management can be more passive, engagement is active.

However, if you look at the Wikipedia definition, then it is defined as engaging stakeholders already.

I prefer treating stakeholders as equals and involving them because great products are built by cross-functional teams who are fully engaged.

Excluding stakeholders is the easiest way to disconnect their valuable contributions from your product, and you need many different perspectives to make your product succeed.

How do you deal with busy stakeholders who don't have time for you?

"How to manage stakeholders who are not ready/don't have time to engage and give their inputs regarding the product?"

I can't answer that question without understanding why they don't have time to engage.

Do they have time to engage when things don't go their way? Then I'd use that to engage in a dialogue.

Shooting down results they are not expecting, without being involved to manage their expectations is unfair and demotivating to everyone.

They will probably be frustrated, but you can also express to them that you're frustrated in a respectful way.

It's an easy problem to solve. Instead of investing time when things go wrong, invest time to make sure things go right.

Do you want to do damage control, or do you want to manage the results?

What are the 5 biggest anti-patterns regarding Stakeholder Management?

"In your opinion, What are the top 5 of Po's anti-patterns regarding Stakeholder management?"

1. Not involving your stakeholders in vision, strategy, roadmap

2. Not explaining the nature of complex work and the impact this has on predictability and planning

3. Not building rapport and trust before you need their help

4. Seeing the relationship as adversarial, instead of a collaboration to achieve the best results

5. Shielding teams from interacting with stakeholders. Get everyone to a place so it's not us vs. them but we're all working towards common goals.

Can you use Scrum at a Digital Agency?

"Is it possible to keep working Scrum when running a digital agency, if so could you give practical examples of how to do it?"

Even though this is technically not a Stakeholder Management question, I'll allow it.

I believe the main challenge is trust. The customer wants to pay X to get Y.

As a consequence, everybody focuses on contracts, requirements, and specifications, and delivering what was promised becomes more important than delivering what matters.

We worked with a customer that realized that contract collaboration is not as effective as true collaboration to do what's best for the customer. So basically we switched to an approach where they would pay a fixed fee per month, and they would have control over what we would be working on.

How do you deal with stakeholders who don't believe in Agile?

"How do you influence a sponsor who feels that agile is too risky and wants every detail planned up front?"

What does the stakeholder believe, and why?

What I often notice, is that those stakeholders have rigid beliefs that do not fit with the nature of complex work.

Can we predict how much time it will take to deliver feature X?

Can we make perfect plans?

Stakeholders usually believe software development is complicated or simple, and this means they think it's (almost) perfectly plannable.

I use two concepts to explain the nature of complex work:

1. The fog of beforehand. Before we start, we don't know enough, and every step we take removes some of the fog.

2. The fog of speculation. Too much planning and analysis is harmful. When you lack information, too much thinking injects speculation and fantasy into your plans. It anchors your plans in your imagination.

Only by doing, learning and adjusting can you anchor your plans in reality.

Should you consider stakeholders as peers or a customer?

"Do you (stakeholder) consider yourself a customer of the team(s) working on the things you care about, or instead their partner/peers? If the latter, how did you foster that peer/partner relationship?"

By including them as partners from the start, instead of only involving them when we're delivering something to inspect whether we've done a good job.

You need to spend a lot of time building relationships, rapport and trust. A good start is to sit regularly and try to understand what they care about and why, before you actually need them for something.

How do you balance tech debt with delivering features?

"Do you have any advice on communication relating to balancing the stakeholder need to deliver projects, with the team desire to do tech debt/build everything in the best way possible."

I like Knibergs kitchen analogy of technical debt.

https://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt

I used that to talk about technical debt in a way they can relate. I usually try to tell a story and ask them what happens if I'm cooking and I don't clean up while I'm cooking.

I also try to explain, just like a cook shouldn't need permission to clean their kitchen, fixing tech debt should happen without devs having to ask.

Unless we want to have a kitchen we can no longer cook in at some point.

Those were all the questions and it's a wrap! Let me know what you want the next Ask a Product Owner session should be about.