No, no, noooo…..
The title of this post is aimed to introduce the description of a behavior I see as incredibly valuable. It is a behavior that I’ve been lucky to observe in the Product Owner that I am working with and in the Product Owners that I’ve been lucky to work with in the past.
I start with a framing of the context of my reasoning:
We are taught that a good Product Owner must be good at saying “NO” to stakeholders. We are taught that this is a tough thing to learn to do and that the Product Owner should do it whenever needed.
We also come to learn that she/he needs to be empowered to say these NOs. And this empowerment can only come from the company itself or it will be an unfair game for the Product Owner.
If this empowerment exists and is publicly stated or acknowledged, it will translate in having a Product Owner really enabled to decide and capable of having her/his decisions trusted and acted upon.
In my opinion this things are underlined for a specific reason. This reason is a specific context that we implicitly assume as widespread and difficult to manage.
The context we are assuming is one in which many “big” stakeholders exert some pressure on the Product Owner, trying to push for their pet features or projects. A Product Owner not able (or not enabled to) say “NO”, will risk to overwhelm the teams with too many requests, not filtered at all or not properly ordered (thus causing multitasking, poor quality and eventually missing target goals).
This is for sure important to keep in mind and a starting point for putting in place a Product organization. But what else is on the plate that we are not talking about? What is the point of view on the other side of the barricade? What do those Stakeholders see happening?
Imagine that you drive a department or part of the business and really need something to be implemented in order to achieve a goal on behalf of the company.
You feel powerless if you receive a “NO” as an answer since the Product Owner decides about the product. It does not make any difference for you if it is only a “NOT NOW”, ’cause you really need it now!
The point here is that you are focused on your goal and you don’t know which goal is the Product Owner serving in this precise moment.
Even if you know it, you probably feel forced to wait for some other goal to be achieved before the one that you really care about is even considered.
Your Goal is mine
At this point I add a quote:
…when I talk about focusing on results instead of individual recognition, I’m talking about everyone adopting a set of common goals and measurements, and then actually using them to make collective decisions on a daily basis
Patrick Lencioni – The five dysfunctions of a Team
The author is talking about a “management group” in the book. A group that was used to divide and then focus each on her/his own goal until the next check-point meeting.
The wisdom in this advise is relevant, in my opinion, for a Product Owner as well. And it resonates with some positive behaviors that a Product Owner could enact, thus enabling the same behaviors in relevant stakeholders.
When a Product Owner is really owning a Product on behalf of a Company, she/he really has to decide what to do first and what to postpone. And she/he has to take that decision in tough situations too.
Simply saying NO to requests that the Product Owner considers less relevant is not enough if he/she is not aware of all the Goals and Impacts on the people and departments involved.
Even worse if she/he does not care about those consequences.
A Product Owner owning Company goals
The only way for a Product Owner to say meaningful NOs is having in mind any stakeholder’s Goal and, as a Product Owner, feeling them as her/his own Goals.
This is particularly relevant when some Goals are lower Priority or have no immediate effects on the revenue stream but yet compete with other goals with more visible and short term impact.
If I care about a Product, I care about all the aspects of the product and I take decisions about its evolution based on many competing parameters, namely the different goals that different departments bring to the table.
If I care only about some of them I will disregard some of the company goals and possibly cause some “hidden agendas” in the future or “political struggles” that will eventually fire back to me as a Product Owner when facing future decisions.
If I behave as if I was the owner of the company I basically suffer for every NO that I have to say, because every Goal is my goal and I spend a considerable amount of time putting things in order. The more I will make inclusive decisions the more I will really represent the Company interests.
Stakeholders working for a Company and not for themselves
If I am a person with a stake on the Product and I work with a Product Owner who shares my goal and helps me seeing the whole picture, I am more willing to support her/his decisions and make them smoother.
It will then be our collective effort to slice Goals and “things to do” in such a way that, over time, we can achieve meaningful results towards all of the Goals that we aim to achieve as a group.
The Product Owner can lead with his behavior but all the stakeholders need to get used to shared goals versus advocating own department goals against others’. The “DIVIDE ET IMPERA” approach will not payback as much as caring about a product and trusting the Product Owner.
Few sentences later, in the same book, the CEO asks the following to her audience:
“How often did you all talk about moving resources from one department to another in the middle of the quarter in order to make sure that you could achieve a goal that was in jeopardy?”
Here we are talking about representatives from different departments that should be ready to agree about which department to privilege in order to achieve their collective goals.
Conclusion
The Product Owner owns the Product but also the Company Goals. This will enable the Product Organization to not be a service provider for the rest of the company.
The Product Owner sets the stage but also the Stakeholders around her/him must learn to work together for a set of common goals. This will impact the way in which decisions are made about the Product.
This will enable agreed-upon decisions taken by the Product Owner whenever she/he will decide what to do first.
