As a father of a almost 16 year old daughter, the time she was just a little girl are a while back now. But there are still some periods when she was little I can remember.
No!
One of them was when she was 2,5 years old and went to daycare for the first time. After a while she discovered children can also use the word “no”. That opened up a whole new world for her. The word “no” became almost her default answer to questions. A lot of children go through this stage. It helps them form an opinion about things. And that’s a good thing.
For some Product Owners it’s hard to say “no”. In nature, a lot of us want to make people happy. So saying “no” to a request is hard. Even though we sometimes know we don’t have time or means to grant it. Or the requested feature doesn’t add enough value for enough stakeholders. One of the Scrum values is “Focus”. To quote Steve Jobs:” Focus is about saying NO.” So when a stakeholder is asking something that doesn’t add to the Product Goal or there isn’t enough time to create it, those are the times a Product Owner should think back of their childhood and say “no”.
There are a lot of ways to say “no”. Important is who you are saying “no” to. This doesn’t mean, the higher the paygrade of the stakeholder, the less you say “no”. Always keep adding value to the product in mind. Does, in a large company, the CEO always know best how to add value? Or could it be, a user of your software sometimes knows better than the CEO? And is helping a single stakeholder provide enough value? More value than helping multiple stakeholders? If you are afraid to say “no” to the CEO because it might have consequences, perhaps you are not the Product Owner but the Product Proxy. In that case there is an other problem that needs to be solved. But I digress.
If you are talking with a stakeholder about a request, always really listen to him. Stephen Covey said:” Most people do not listen with the intend to understand; they listen with the intent to reply.” So listen with the intent to understand the stakeholder. And if you don’t understand, ask clarifying questions. And if you do understand, rephrase what has been said back to the stakeholder to check. That way you can figure out what problem the stakeholder is trying to solve. Perhaps you can help in a different way.
Important is building enough credit to be able to say “no”. Always saying “no” doesn’t work. You need to be able to explain why you are saying it. Also be clear that “no” doesn’t always mean “no, never” but it can also mean “no, not now” or “no, there is no budget” or “no, it doesn’t add to achieving the current Product Goal”.
Want to know more on how to say “no”? Robbin Schuurman and Willem Vermaak have written the book “50 tinten nee” (the English version is called “Master the art of NO”) about how saying “no” is part of effective stakeholder management.
Why?
When my daughter got a bit older, she got more and more curious. When she was about 4 years old, she often asked “why”. “Why do people smoke? It stinks.” “Why do we have to eat peas?” “Why do I have to go to bed this early?” “Why can’t I go from school to home alone?” When we grow older, we tent to ask “why” less and less. We assume a request is just. Sometimes we ask “why” but are easily satisfied.
An example:
Stakeholder: ”Hi Product Owner, can you create a process where a team lead must give an ok when a refund is made for a product in our webshop?”
PO: “Why do you want this?”
Stakeholder: ”We want to prevent mistakes.”
End of conversation.
Question is, why does the stakeholder want this check? What problem does he wants solved? Was there a situation that triggered this request? This question looks clear. But does it solve the right problem? The only way to be sure is having the problem clear. We are not always sure about the solution, but we can define the problem we want to solve.
A good way to get to the root cause is to keep asking “why”.
Stakeholder: ”Hi Product Owner, can you create a process where a team lead must give an ok when a refund is made for a product in our webshop?”
PO: “Why do you want this?”
Stakeholder: ”We want to prevent mistakes.”
PO: “Why do you want to prevent mistakes?”
Stakeholder: “We have refunded customers but the money went to the wrong bank account.”
PO: “Why did it go to the wrong back account?”
Stakeholder: “A wrong bank account number was put in.”
PO: “Why was the wrong account number put in? There is a check an account number is valid.”
Stakeholder:” It was the account number of an employee of ours. He had refunded it to himself.”
Now the reason why a team lead needs to give an ok for a refund is clear. But wouldn’t it be enough to have a team lead give an ok if the bank account number where is refunded to is different from the bank account the payment was received from? Having to give an ok for every refund could be a good thing but it takes away a lot of autonomy from employees and gives a lot of extra work for a team lead. Also could the team lead spot the fraudulent order between all the correct? Having the root cause clear, gives an opportunity for exploring different solutions. Perhaps it will suffice to have an ok from a team lead when the amount exceeds a certain amount or when the bank account is different. That requires a different solution.
Also, it’s important to know why a request is made to be able to know if the request should be put on the Product Backlog. Does solving this problem take us closer to achieving our Product Goal? Or is there another reason, like in this example, why it’s put on the Product Backlog without contributing to the Product Goal.
So dear Product Owner, keep asking “why” and don’t be afraid to say “no”.