From the get go I intended to include a 1-pager on ways of saying “No” for Product Owners in my book “Skills for Successful Product Owners”. It’s such an essential skill! As a Product Owner you get bombarded with feature requests and ideas. And most of them sound good enough. But having ideas is easy and – mostly – free. Implementing ideas is not. They cost time and money.
And even if they didn’t, if you just put every possible feature into your product, it will become bloated, confusing and unusable. What you choose not to include is at least as important as what you do implement.
As a PO it’s your job to have a strong vision of what problem the product solves and for whom. And then execute on that, protecting the backlog from requests that do not serve that vision. But that’s easier said than done. Telling people “no, we’re not gonna build your ‘genius’ idea” is hard.
That’s why I’m super happy that Michael Küsters has captured 7 great ways of telling people no in a way that connects with sound reasons for the “no”. Check out the 1-pager:
Are you a budding Product Owner? Check out our compilation "Skills for Successful Product Owners"
Content of 1-Pager:
A Product Owners most important word: “No”.
Here are 7 Ways to say “No” as a Product Owner
– using valid reasons instead of the word
How does this idea fit into our long term strategy?
As a PO, you should be very clear about the product strategy. New requests are viewed as not supporting the strategy unless the requester convinces you that their idea will help reaching significant strategic goals faster.
Tip: Try “Impact Mapping”
You just need to convince the other stakeholders.
As soon as you put an item into the backlog at a certain priority it pushes down other item. Items whose stakeholders ask you to justify that decision. Why would you want to be in that position? Let the requester go into the line of fire.
Tip: Try “Buy-a-feature”
This is going to cost you about 10x as much as you’d want it to.
Random ideas can quickly congest the path to maximum value. Stakeholders often have little understanding of how much work a “small favor” actually causes. Since the PO also doesn’t have all of the information, it is very risky to commit to anything behind the team’s back. Ask the team instead.
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 bad at understanding that WIP Limits are pretty much essential to getting things done and delivering a valuable product. Exercise caution to avoid becoming a “request manager” tracking endless lists of things that have no chance of ever getting done.
Tip: Try a Visual Dashboard with WIP limit 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 waste your time figuring out whether something is worth doing when 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.
Tip: Google “WSJF” (Weighted shortest Job First).
This has no chance of being done anytime soon.
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?
As our product grows, our ideas should get more valuable over time – so ideas that already aren’t valuable enough now will probably never be.
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.
Tip: Cap the backlog to contain at most 6 months of work
We discuss things when they become important.
“We will consider your suggestion at an appropriate time. Thanks.”
This is a polite way of saying: ‘This item is wasting my time’, it’s just phrased a little more politely.
At any time, the Product Owner should maintain focus on the top few priorities in the backlog.
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.
Source: