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.<\/p>\n\n\n\n
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 \u201cno\u201d. That opened up a whole new world for her. The word \u201cno\u201d 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\u2019s a good thing.<\/p>\n\n\n\n
For some Product Owners it\u2019s hard to say \u201cno\u201d. In nature, a lot of us want to make people happy. So saying \u201cno\u201d to a request is hard. Even though we sometimes know we don\u2019t have time or means to grant it. Or the requested feature doesn\u2019t add enough value for enough stakeholders. One of the Scrum values is \u201cFocus\u201d. To quote Steve Jobs:\u201d Focus is about saying NO.\u201d So when a stakeholder is asking something that doesn\u2019t add to the Product Goal or there isn\u2019t enough time to create it, those are the times a Product Owner should think back of their childhood and say \u201cno\u201d.<\/p>\n\n\n\n
There are a lot of ways to say \u201cno\u201d. Important is who you are saying \u201cno\u201d to. This doesn\u2019t mean, the higher the paygrade of the stakeholder, the less you say \u201cno\u201d. 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 \u201cno\u201d 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.<\/p>\n\n\n\n
If you are talking with a stakeholder about a request, always really listen to him. Stephen Covey said:\u201d Most people do not listen with the intend to understand; they listen with the intent to reply.\u201d So listen with the intent to understand the stakeholder. And if you don\u2019t 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.<\/p>\n\n\n\n
Important is building enough credit to be able to say \u201cno\u201d. Always saying \u201cno\u201d doesn\u2019t work. You need to be able to explain why you are saying it. Also be clear that \u201cno\u201d doesn\u2019t always mean \u201cno, never\u201d but it can also mean \u201cno, not now\u201d or \u201cno, there is no budget\u201d or \u201cno, it doesn\u2019t add to achieving the current Product Goal\u201d.<\/p>\n\n\n\n
Want to know more on how to say \u201cno\u201d? Robbin Schuurman and Willem Vermaak have written the book \u201c50 tinten nee\u201d (the English version is called \u201cMaster the art of NO\u201d) about how saying \u201cno\u201d is part of effective stakeholder management. <\/p>\n\n\n\n
When my daughter got a bit older, she got more and more curious. When she was about 4 years old, she often asked \u201cwhy\u201d. \u201cWhy do people smoke? It stinks.\u201d \u201cWhy do we have to eat peas?\u201d \u201cWhy do I have to go to bed this early?\u201d \u201cWhy can\u2019t I go from school to home alone?\u201d When we grow older, we tent to ask \u201cwhy\u201d less and less. We assume a request is just. Sometimes we ask \u201cwhy\u201d but are easily satisfied.<\/p>\n\n\n\n
An example:<\/p>\n\n\n\n
Stakeholder: \u201dHi 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?\u201d<\/p>\n\n\n\n
PO: \u201cWhy do you want this?\u201d<\/p>\n\n\n\n
Stakeholder: \u201dWe want to prevent mistakes.\u201d<\/p>\n\n\n\n
End of conversation.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
A good way to get to the root cause is to keep asking \u201cwhy\u201d.<\/p>\n\n\n\n
Stakeholder: \u201dHi 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?\u201d<\/p>\n\n\n\n
PO: \u201cWhy do you want this?\u201d<\/p>\n\n\n\n
Stakeholder: \u201dWe want to prevent mistakes.\u201d<\/p>\n\n\n\n
PO: \u201cWhy do you want to prevent mistakes?\u201d<\/p>\n\n\n\n
Stakeholder: \u201cWe have refunded customers but the money went to the wrong bank account.\u201d<\/p>\n\n\n\n
PO: \u201cWhy did it go to the wrong back account?\u201d<\/p>\n\n\n\n
Stakeholder: \u201cA wrong bank account number was put in.\u201d<\/p>\n\n\n\n
PO: \u201cWhy was the wrong account number put in? There is a check an account number is valid.\u201d<\/p>\n\n\n\n
Stakeholder:\u201d It was the account number of an employee of ours. He had refunded it to himself.\u201d<\/p>\n\n\n\n
Now the reason why a team lead needs to give an ok for a refund is clear. But wouldn\u2019t 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.<\/p>\n\n\n\n
Also, it\u2019s 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\u2019s put on the Product Backlog without contributing to the Product Goal.<\/p>\n\n\n\n
So dear Product Owner, keep asking \u201cwhy\u201d and don\u2019t be afraid to say \u201cno\u201d.<\/p>\n","protected":false},"excerpt":{"rendered":"
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. … <\/p>\n