Why product owners should say NO more often
Focus is about saying NO to everything which is not connected to the goal. That is a challenge we must overcome in order to be successful.
Focus is about saying NO to everything, which is not the goal. That is a challenge we must overcome to be successful.
A constant challenge we face in the product development world is to focus on what matters, why does that happen? Well there are a lot of factors that can bring distractions to our main goals, therefore, causing us to lose our focus, some possibilities are:
Everything is a priority;
Bugs;
Legal requirements;
The CEO wants.
I want to share my perspective on it with you. I’ve been facing such scenarios over my journey. Let’s approach each topic deeper.
Everything is a priority
That happens quite often when the PO has multiple stakeholders, and they have their wishes, then everything is seen as a priority. As a PO, we receive requests from all sides, and everyone wants everything done latest by tomorrow, because they believe it’s important. Be careful with the word “important,” without numbers; don’t trust that.
The truth is most of the time; we need to say NO, otherwise we cannot focus on what matters. There are some questions I like asking whenever someone comes with one important request:
"What happens if we don’t do it?"
Most of the requesters don’t have an answer for this question, because it is not a priority in most of the cases. In case they have a good reply, we need to search for the second NO, another question I generally ask is:
"Here is what we are working on and our plan for the near future, could you help me understand why your request is more important than these?"
Here is another moment that requesters get blocked, because as I said most of the time, it is not a priority. In case there’s a relevant answer, then we can evaluate it better and make a decision.
I came across a short but interesting article about it, you should have a look, How to prioritize work when everything is a priority?
Bugs
The famous bugs come quite often in inconvenient moments. However, we should not panic and start reacting immediately to everything that we find. We should remain always calm no matter what and evaluate more in-depth before anything else:
Is there any workaround? It means that the users can get the expected result through an alternative way;
How many users are impacted? This question helps us a lot understanding how the bug is reaching our users, therefore defining a clear priority;
How critical is that? What kind of issue does the bug bring to the users? For example, if the users can’t log in, this is extremely critical, but if there’s a wrong translation displayed, that is not critical at all (in most of the cases).
By knowing the details, we may be able to say NO for now and then decide when to work on it. In case the details prove the bug to be a high priority, then we should take the required actions, but that should be the exception only, we don’t want to be Firefighters, we want to be Product Owners.
Legal requirements
This scenario is a traditional top-down that happens in the business world; someone from the legal department may drop you an email saying that there’s a new legal requirement that has a deadline until next week. Instead of just acting immediately, we must be at least curious about this situation by asking?
If the deadline is so short, why am I being informed only at this very moment?
What are the consequences of not matching the deadline?
How can we ensure that next time I will be informed beforehand?
Laws don’t change from one week to the other, and there’s always a given time range that companies should adapt to that, believe me, it’s not one week. Therefore we should not accept such top downs and work towards a better collaboration.
Legal advisors need to understand how the product development world works. It’s our responsibility to coach them on it. By saying yes, we will only ensure this behavior is accepted, by saying NO, we will generate learning. Feedback is needed if we want to influence a behavior change.
The CEO wants
That’s a classic one; some people may come with a request and speak on behalf of the CEO by saying: we must do that because the CEO wants. Just ask: why isn’t he or she asking me that personally? The answer may be that he or she has no time or has made up his or her mind already and is not willing to talk more about it. Then you should say, changing directions abruptly causes many troubles which I need to share with him or her. We need to fight for transparency.
We must start the conversation with: sorry, we must say NO! There are many consequences, such as: losing the work already done, interruptions, and demotivating the team, and probably they will not trust the decisions anymore.
If the CEO wants to change the directions, he or she can ask for sure, but he or she needs to understand the downsides and communicate that personally to the team and not ask some else to do it.
This scenario is also worldwide known as Top-Down; how can we handle that in Scrum? Take a look at this article: Scrum and the top-down decisions.
Given these scenarios, I believe that Product Owners should say “No” more often!
The summary is, say NO at least three times to each request. If it’s essential, people will find the answers to convince you. Generally, these high priorities requests disappear after the first or second NO and never come back because they were never a priority. Less is always more, don’t fall into the trap of only pleasing people, always focus on the value for the business.
Recently I read one article from Wil Moushey about prioritization. He makes a strong point about it, which I agree with more than 100%.
I think we have all heard the phrase “when everything is a priority, nothing is a priority.” But when it comes down to it, clients, coaches, and other leaders struggle to identify the right things for their teams to focus on. I have found that many leaders lack a system or framework to assist with prioritization.
Just to finish, I want to share the view of Steve Jobs on it. You can take your conclusions.
Some recommended reading about it: