Denying requests without saying "No"

My recent post about why saying "No" or "But" might be avoided spawned the question: "A Product Owner should better say NO quite frequently". Based on my experience, here are some tips for a Product Owner to deny a request without actually resorting to "No". I've been using these kinds of statements for years, so this is a small collection of keeping your product in shape while staying positive.

How exactly does this idea fit into our long term strategy?

Any request which is not yet in the backlog is not worth considering in the light of the current strategy. The burden of proof to the contrary rests on the stakeholder rquesting something new.

The Product Owner should be very clear about the product strategy. Requests that either conflict with this strategy or are irrelevant to the strategy have tremendous impact. While the PO can explain the current strategy to the requester, it is the responsibility of the requester to convince the PO that this item will actually support reaching significant strategic goals faster. Tools like "Impact Mapping" are great ways of doing this visually.

You just need to convince the other stakeholders. 

"Can you ask the others to approve your request before I do something that conflicts with theirs?"

Especially in corporations, there are often many stakeholders with conflicting interests. As soon as the PO puts an item into the backlog at a certain priority, they need to justify to all of these parties why this item has been placed there - especially since it means that all stakeholder requests of a lower priority will be either deferred or descoped. Why would you want to be in that position? Just let the requester go into the line of fire. Tools like "Buy-a-feature" may be invaluable to do this effectively.

This is probably going to cost you about 10x as much as you'd want it to.

"I just asked the team, this is much bigger and more expensive than you thought".

Random ideas can quickly congest the path on your journey to maximum value. Often, stakeholders have little or no understanding how much work a "small favour" actually causes. Since the PO also doesn't have all of the information, it is very risky to commit anything behind the team's back. I have experienced "just a few days" items become severely impactful on strategic milestones, and that's not something you want. The most effective way to avoid cost/effort/timeline traps is applying the very simple tool "Ask the team".

We have limited WIP.

"Which of your requests should I scrap in order to put this into the backlog?"

People are good at coming up with ideas to keep others busy. Many people are just very bad at understanding that WIP Limits are pretty much essential to keep getting things done and delivering a valuable product. You need to exercise caution to avoid becoming a "request manager" tracking endless lists of things that have no chance of ever getting done. You don't want become responsible for reporting status of items that aren't being worked on - and you also don't want to justify why you're not getting more things done than the team can do. Make it the responsibility of the stakeholder themselves to get gray hairs over figuring out which things they really need.
A very simple tool is to have a Visual Dashboard with strict WIP limits. If that doesn't help enough yet, assign specific WIP limits to each stakeholder - for example, 3: Requests are only accepted once something got done.

Our backlog is a prioritized list.

"Do you have any data that warrants putting it into a position where it has a chance to be done in the next half year?"

Why should you, as Product Owner, waste your precious time to figure out whether something is worth doing when even the person making the request can't be bothered to do that? You are a bottleneck. Delegate as much work as possible. Avoid feeling pressured to put something at Priority 1 just because the Group CEO just had another great idea. Arrange your backlog items so that they make sense from an economic perspective. You can keep items off the list that aren't healthy for the company with the tool "WSJF" (Weighted shortest Job First).

Based on the current state of the backlog, this has no chance be done anytime soon.

"It won't be done within the next half year. I suggest you come back in about 5-6 months, if it's still important."

Why would you even bother to track things so far into the future that it's more likely your product won't fit to the idea any more than seeing these things actually get done? If the idea is good, it will come back later. If it isn't - well, why is it important to keep?
Once a request is not sufficiently valuable to get done anytime soon, it is very likely that this is the actual value of the idea. As our product grows, our ideas should actually get more valuable over time - so ideas that already aren't valuable enough now will probably never be. By keeping a rough idea how much work is currently in your backlog, you get a rough idea when the item at position 20/30/50 will be done. Any item moving to the bottom of the backlog, being beyond a predictable horizon, wastes your capacity as you need to think about it all the time.
You make your life as PO significantly easier by capping the backlog size to contain roughly 1/2 year of work.

We discuss things when they become important.

"We will consider your suggestion at an appropriate time. Thanks."

And 'now' is not that time. This means nothing short of 'This item is wasting my time', it's just phrased a little more polite. 

At any time, the Product Owner should maintain focus on the top few priorities in the backlog. Anything that is not there reduces the odds of success - who would want that? 

Avoid getting dragged into meeting madness for things that may never happen. If others want to discuss these things - fine. Let them. Once they have overwhelming evidence that you should invest time, go ahead. Until then, feel free to assume that your product is doing perfectly fine without adding the request.

Resort to Backlog Weeding. Treat all ideas that aren't worth doing anytime soon as weeds.

Summary

Being a Product Owner and staying positive towards all requests is always a tightrope walk. 

Use the approaches and tools described in this article as stepping stone towards respectful product ownership in challenging environments.