How to say no – an underappreciated skill for Product Owners

As a Product Owner (PO), it sometimes feels like my main job is to say “no” to stakeholders. Naturally, they all have important wishes and ideas on how to improve the product. However, product development is always constrained by capacity and available time. Thus, the PO has to rigorously prioritize and frequently deny requests.  

This was particularly true for me personally when I was PO of a business intelligence team. The very broad set of responsibilities the team had meant that essentially every single employee in the company was a stakeholder. Combined with the fact that we also had external customers we were delivering reports to meant that I was seemingly saying “no” 20 times for every one time I was saying “yes” to requests.

Of course, this is not a lot of fun. The vast majority of people working in product development love to build great products. Therefore, the instinct is to generally say: “Yes, we can somehow squeeze this in.” I also have the feeling that it may be related to human nature. It makes us feel good to deliver what others need and get the recognition for delivering.

Well, you surely don’t get that if you’re constantly telling others that you won’t be prioritizing their requests. But this is the nature of the PO role. Saying “no”, being able to explain the decision, and get buy in to the decision is one of the main aspects of stakeholder management, one of the main qualities of a good PO.

The Backlog is a bi-weekly newsletter about the undervalued and overlooked in modern product development. It covers product development, self organization, and productivity. I include methods, books, and write about my own experience. The target audience are Product Owners, Scrum Masters, Developers, and project leaders. The Backlog is about getting the most out of product development.
Subscribe to get new posts straight to your inbox. 

Why we should say no a lot

Although it is counterintuitive, saying “no” is actually a good thing. It is a sign that the product is being built in an effective way. It’s one of the reasons for having a PO and it means that he or she is actually thinking about how to spend the scarce resources on things that matter instead of blindly building everything that is requested without really understanding what brings the most value. 

It brings focus, whereas not being able to decline requests can result in chaos. It usually leads to a self-enforcing negative dynamic.

Too many things are on the plate, topics – often the actually important ones – are forgotten, the team is reprioritized, things are added to the sprint, the team is unhappy and loses motivation, productivity suffers, stakeholders don´t trust the PO and team. This cycle of overcommitting, disappointment, and loss of trust is really hard to break out of.

How to make saying “no” less horrible

By now, we have established that it can be crucial to say “no”, but that it sucks to do so. How can we make it suck less? The short answer is, as it often is in life: practice. The more often you do it, the more often you witness the benefits, the easier it gets. 

The long answer is that, essentially, this entire topic is about trust between stakeholders and the PO. Building trust is hard and takes time whereas destroying trust is quickly done. One sprint where things are not delivered can easily make the last three successful sprints forgotten. 

One important factor to build trust is communication. This should be a given for POs but it often is not. Performing stakeholder management means constant communication, constantly talking to the stakeholders and explaining what’s going on. There are different ways to this: standing meetings, one on one calls, blog posts, email…The important thing is to share what is happening, and crucially why it is happening.

Stakeholders need to be informed about what is being done and what is not, why the decisions are made, and how the decisions fit the context, the long-term goals. If that is done, it is much easier to accept a “no”. Far too often do I see it that some feature is requested, maybe a ticket is created, but then nothing really happens. This is frustrating for all involved.

I know it’s hard to have these conversations, I frequently struggle with them. It´s easy to ignore them and let future me worry about the consequences. However, I frequently find that it’s much harder for future me to actually deal with the consequences. It’s so cliche but so true, communication is the key.

In my experience, it’s best to be honest and state from the beginning that a request likely won’t be completed, if that is the most realistic outcome. Generally, it’s better to under promise and over deliver than the other way around. 

However, you have to be very careful to not create a dynamic where you never commit to anything. I am arguing to be realistic and to only commit to what can be done. I am not advocating for saying “no” to everything and hiding behind the excuse of not having enough resources for the things required.

Essentially, it’s about setting aspirational but realistic goals, being very mindful of what can and cannot be done, and honestly communicating that.

Work with numbers

In honest communication, especially when making decisions and explaining them, in my experience, it helps to quantify as much as possible. Whether it be quantifying the value of the requests in $ or €, analyzing the number of impacted customers, or something else, using numbers to explain the decisions is crucial. 

This is particularly useful in comparing different options. Stakeholders naturally are driven by their own goals, incentives, and KPIs. Of course, they push the team to implement what most improves those goals. By using one set of numbers to compare features (instead of using the various KPIs of individual stakeholders) the PO can create context. In my experience, this leads to good understanding, in case of rejecting requests.

Create a transparent system

Building on the paragraphs above, it greatly helps to have some sort of standardized, transparent, and (as much as possible) objective system in making the decisions of what gets prioritized.

This creates some clear rules and makes decisions transparent. There are many options to choose from. Some examples I have used include feature canvasses, standardized business cases, R.I.C.E scoring, or the Kano method.

There are many others. It doesn´t matter which option is used. It is only important to rigorously apply it to making the decisions. If this is done consistently, it leads to much greater acceptance of the decisions.

Make the work visible

I often joke that when companies decide to become agile, they create some boards and that’s it. They are now agile. While that is obviously not sufficient, the boards do serve a very important agile principle, making the work visible, one final small thing that helps in saying “no”.  

This applies to the individual work packages that the team is working on, the tickets included in the sprints. Here, in case a board is being used, they are visible.

However, I also encourage to visualize the larger, high-level topics, the epics and feature requests. The discussion changes once the stakeholders are able to actually see all the options that are currently on the table for the team to work on.

Just try it

To summarize, saying “no” is not easy. If done properly it provides some real benefits and there are ways to make it less horrible. My advice to all POs is therefore to practice saying “no” more often. The benefits are real.

And don´t worry if you can´t always do it, particularly in the beginning. Still to this day, I frequently fall into the trap of overcommitting to things, simply because my natural tendency is to want to fulfill stakeholder requests. An 80% solution is better than no solution.