8 skills that a Product Owner should learn to effectively convey a NO message to stakeholders (II)

This is the transcription of the interview done by Adolfo Foronda a few weeks ago about how a Product Owner can effective convey a NO message. I hope you enjoy and find it useful.

ADOLFO: I’m your host Adolfo Foronda at nerd stalker on Twitter.

Today I am with a very special guest Erich Bühler. He is a senior Agile consultant, he regularly pairs with Certified Scrum Trainers (CSP’s) and he’s an expert in agile business Agility and organizational transformations.

He’s also the author of the first book in .NET in Spanish back in 2002. Speaker in many international events and he recently run a Web in Enterprise Social Systems (ESS) for Scrum Alliance, organized the first ScrumDay in Chile and Valencia, and Erich has served as a trusted adviser over the past 22 years for the following leading companies… there’s a ton of them here… LATAM Airlines, Chile, Microsoft Iberica, Ministry of Defense Spain, British Telecom UK, London Stock Exchange, INDRA Spain, MasterCard Uruguay, AXA insurance Mediterranean Spain,  and many more companies in Malta and New Zealand….

Erich welcome to the show.

Erich: Thank you.

ADOLFO: Where are you anyway? You’re in New Zealand right now, you said?

Erich:  Yes, I’m in Auckland city at the moment.

ADOLFO: Wow. I heard it’s wonderful there…

Erich:  Yes, except for winter ha ha ha

ADOLFO:  All right. Well Erich let’s get to it.

Erich: Ok!

ADOLFO: So… one of the biggest jobs for a product owner is to say NO, metaphorically or literally. Tell me in your experience how often do you see a Product Owner say no and to what title for example CEO owner or V.P. or other, how they should do it, and what are the desired outcomes…

Erich: Well that’s a great question!
The first thing we need to understand is what NO means. It is different in an Agile organization than in a traditional one.

“NO” in a traditional company probably means that we won’t be able to take that on board. And if we are talking about technical requirements, it means that we are not going to do it. That’s simple.

So if we are talking about a new idea…. it means that we are not going to do that or we’re not going to take that idea on board.

So traditional companies are also plan-based, so it’s harder to take changes on board especially if we are in the middle of a fiscal year. You probably know about that.

We also need to understand some of the core characteristics of the Agile or modem companies and say NO is a crucial skill especially for Product Owners.

Imagine that someone asked for some requirements, something to be added into your product… so let’s talk about that new your request.

So how we can say NO in fact without saying NO at all?

For this, we need to understand how Agile works and how SCRUM and KANBAN works, as also as vision and roadmaps.

First of all, when we’re talking about a Agile company, we need to have a clear vision for our products. And in here we’re talking about a vision which shared and must be understood by everyone and is inspiring.

Many time, when we see a requirement that doesn’t comply really with the current vision, we need to do something…

And in Agile we have two clear options.

#1

It is about saying that it doesn’t comply with the current vision and ask the person to review the requests and come back with a different idea or a new one, for example.

#2

it is just about changing the vision. If the person wants to take that on board and doesn’t comply with the vision we need to change our vision.
But changing the vision is not that easy. We would probably need to organize a workshop, invite all the stakeholders, Product Owner has to be there, the team and they need to come with some kind of shared agreement about the new vision.

Unless is someone with a lot of power, let’s say… the CEO asking for the requirement, then they would probably don’t feel comfortable about the situation and try to reshape the request.

Also as a general rule, you don’t generally change your vision without reviewing your current strategy.

So you don’t really need to say no but you need to make sure that the request comply with your vision.

We also have a scenario which is slightly similar which is related to the roadmap. Someone again asked for something and then it doesn’t comply with the goals defined on your roadmap.
So imagine that the request doesn’t comply with your current roadmap. Companies review their roadmaps every a few months so… they would probably need to wait for the next review to see if you’re going to change the direction they are going.

And that’s similar to the previous one that I mentioned.

#3

The 3rd. scenario is where something really complies with your roadmap and the vision so you can’t say NO in here.

In here you have again a couple of options

SAY NO and explain why. You always need to explain why you’re saying no! or otherwise you need to add it to your backlog. A great Product Owner know a lot of techniques to prioritize the backlog.

It should be easy for the Product Owner to explain why the feature is going to be place at the bottom, in the middle or high priority.

A couple of weeks ago I was teaching a group of Product Owners different techniques to prioritize a backlog. We had approximately 10 different techniques to prioritize a Product Backlog.

In the first part, we explained 3 different scenarios without saying NO but there are some specific situations where you have to say NO. It is part of your work!
We need to understand for that the Product Owner role very well, as the PO is the person responsible for delivering value and anything blocking the business value delivery has to be probably removed as soon as possible from the value chain.

For example, if a Product Owner sees some increase in organizational complexity… let’s say someone adding new rules or perhaps someone is willing to change the organization in a way that is going to decrease business value produced by the team/teams, it has to be stopped as soon as possible.

I think here it is the only option so if you see that someone adds new rules, we see that specifically in traditional companies using Scrum.

In there, everyone wants new report, add new rules etc. etc. etc. or new metrics for example.

We have to say no!

The second scenario here are related to behaviors which basically go against the team’s values or the organization values.

As an example, we can see that someone want to measure the teams in a way that is not in an Agile way and it’s going to affect the whole value network. When we say the whole value network, we are talking since someone came up with an idea until you deliver that service (all the people involved in that).

I’ve seen this plenty of times for example management asking to come to a retrospective, for example, or the CEO wanting to come to a retrospective.

Here you have to say no!

If you don’t stop this kind of behavior then you’re not going and never going to reach a point where you or your team feels safe.

The last a scenario is when you have very low priority activities. You can see that Product Owners generally have a lot of meetings and they consume a lot of time.

It’s really important to say NO to this kind of activity as they are generally time- suckers. I know it’s difficult to say NO if that requirement is coming from the CEO, but you have to have a consistent behavior.

The first group of actions we have seen are related to when you say NO without saying NO and are all related to product features. You can say no without in fact saying no.
Just by using all the SCRUM and AGILE ecosystem such as the vision, roadmap, backlog and their dynamics.

The second one is related to behaviors. In here it is very important that you say NO and you have to practice it.

ADOLFO:  So would you say that is rare to say NO?

Erich: Yes, it is rare to say no for them and they find it truly difficult.

Today we’re going to see a couple of techniques that are going to help the Product Owner communicating that NO.

ADOLFO: Erich how do you help product owners learn and communicate the NO news to authority figures and otherwise?

Erich: Well in my experience, where you’re transitioning from the traditional organization to the Agile one, there is a lot of friction.

I’ve seen many managers not understanding very well the PO’s role and that creates many misunderstandings.

In general, when I’m helping companies that’s one of the first things you should do. You should help middle management to understand the role very well.

What try to do here is to make sure that when you have ne POs, you also have Scrum Masters, middle management and the sponsor for the initiative trying to re-enforce visibility and the role.

And that’s a very important thing. You generally need to get a lot of support from all these people around. In my experiences is also different based on the country.

For example, when you have some issue in New Zealand, for example a scenario where nobody understands the PO role very well. In there, people like stories.
You have to tell them what the role does in terms of stories, in other countries is more oriented to numbers and facts and why the role works in that way.

It depends really on the country, for example what I do if I am working in Spain or in South America or even in America, then I try to go for facts.

I would explain “the reason why we work in this way is because… why the role is in this way…” and I would try to explain what we want to achieve. I would also try to show, example, the CHAOS report which shows some numbers and explain why we have that role in first place.

Remember, if you are in Australia or in New Zealand you go through different stories instead. You have to tell people about stories you experienced to explain why they shouldn’t be afraid of communicating a NO.

But for that to happen people need to feel safe and well supported. We’ve said before when we have new Product Owners, we need to make sure we have Scrum Masters and especially the person supporting the initiative to make sure that you have the structures supporting that PO.

People have to feel safe in here.

A way to convey a NO is generally by making sure that before trying to convey the NO you have a conversation with the sponsor for the initiative and you have the right to structures in place (everyone understands very well what is happening!).

In some companies, for example, after making a no decision they discussed that in the Scrum of Scrums meeting with management so everyone around understand what’s happening and they can properly support the Product Owner.

ADOLFO: Can you share some of the techniques and approaches you use to convey the message that something is not possible?

Erich:  Well…if we are using the SCRUM, sometimes you can convey a message by using the artifacts, such as the burn-up or burn-down, the velocity chart. They probably support very good conversation.

A typical scenario is where the team is not able to finish with the user stories, for example, and the Product Owner must tell the stakeholders that they were not able to finish with these. That is a NO message obviously.

We need to make sure in here that we work with different technique to improve visibility; we can use Kanban Boards, we can make the progress visible, we can make technical debt visible and make sure that everyone understands and knows how to read these charts to help convey information

As much as you can DO NOT USE EMAILS to convey information.

ADOLFO: That’s right.

Erich:  I remember long time ago in company with very very low visibility where the first day I went there I just canceled my email account so everyone had to talk to me. It worked very very well.

And in fact, some people could say… how are you going to interact with people who are remote?

Well… use skype and face to face communication.

I’m going to share with you something… I was having a conversation with Stefan Sohnchen, who is an Agile Coach here in New Zealand. We were discussing about 8 important points about conveying a NO message so LISTEN CAREFULLY NOW.

#1

Saying NO requires you to accept that saying NO can be a hard thing for you but it is also a hard thing for others!

#2

It doesn’t make you a bad person. There is no reason to feel guilty. That this is a very important thing, right?

#3

It is not cruel or a cruel thing.

#4

So you are not rude, unprofessional or rude.

#5

If that’s the case, try to create some working agreements with the people around you to make sure they support your NO’s.

If people don’t feel comfortable about saying NO then you need to see why. Perhaps we just need to create some working agreement so people can feel safe, and that’s a very very important thing!

#6

Saying NO is part of accepting the power and the importance of being a Product Owner

That is something you need to practice!

#7

When you’re afraid of saying NO you’re probably fueling an anti-pattern that we generally see in company which is called “disease to please”.

If you had kids, for example, learn how easy is for them to say NO, especially if they have less than four years old, and try to pay attention why older kids don’t generally say NO.

And the last part which is very important…

#8

Avoid being tired or sick as people associate that with the answer.

The most important here is to distinguish between the person making the requests and the attributes for the request being made.

You can always change your mind during the journey.

In my experience, it is a good idea to practice…don’t laugh of this!… in front of the mirror.

ADOLFO: Yeah, for sure. That’s how actors do it and a lot of people do it.

Erich:  Yes.

I recommend Product Owners to do it. If you’re doing some pairing, for example, then ask the other person for feedback.

And remember… if you say no be ready to make a counter offer.

And don’t forget that you always want to convey a NO message in an environment where you feel safe.

There is a great book that, I don’t know if you have heard of it, it is from Patrick Lencioni called “The advantage.

ADOLFO: No, I don’t.

Erich: That’s a great book and I’m going to share this framework. It is to make healthy organizations and I am going to share the framework for free.

It has basically for repetitive actions to make sure that the organization grow in a healthy way and that supports your NO’s.

The first one is about building that cohesive leadership team.
If you especially a transformation and you’re a brand new Product Owner, try make sure that there is a leadership team underneath supporting you, otherwise nobody is going to support your NO’s.

The second is about creating clarity.  When you say NO, make sure that everyone understands why, make sure that you have the right behaviors and try to make sure that if there are no good behavior, address them first with the sponsor for the initiative.

The first part of this framework is about over communicating clarity. So make sure that the same message is repeated once and again and again and again and the good behaviors as I said, you have to be consistent with your behaviors.

This is all about enforcing clarity.

Here you can use all the SCRUM techniques and everything that you have at hand to make sure that you improve visibility

I really recommend if you haven’t read this book, it’s a great opportunity for you to make sure that you understand how a healthy organization works. You always want to say no in a healthy organization. You want to feel safe when you say no, right?

ADOLFO: Erich, for the listeners and everyone, where can we get more information about you and what you’re up to?

Erich: They can contact me on LinkedIn in ERICH BUHLER or Innova1st.com. We can be in touch.

I’m always supporting communities in Latin America mainly and now in New Zealand.

ADOLFO: Well thanks so much.

Erich: Great, thank you Adolfo!

And remember… if you want to know more about the ways to boost Scrum and Agile teams within your company, please visit our website.

Leave a Reply