Saying no to a stakeholder can be very difficult.
Most of us like to please others, and when we say no, we know we're disappointing someone.
But saying no the stakeholders is an important part of the product owner or product manager's job.
They're tasked with optimizing the value delivered by a product, not with saying yes to every customer request.
For every time a product owner says yes to one stakeholder's request, the product will need to say no to some future request.
A team's time is limited, and a yes today will necessitate saying no some later opportunity.
This means that learning to Say No to Stakeholders is a skill every product needs to master.
I want to share six guidelines for how you can do so politely but firmly.
When you need to tell a stakeholder no, be clear what no means.
If you're saying that you'll never have the team work on this feature, don't leave the door open to encourage the stakeholder to ask again later.
That's a waste of their time and frustrating for you to have to continually say no when you know you will never do that feature.
If, on the other hand, you're telling the customer no for now, that you might work on their request later, be clear about that as well.
Tell the stakeholder why you can't work their requests now and when you'll reconsider it.
I also like to ask them to remind me about the request at that time.
This is a simple way of confirming the requests is still important.
If the stakeholder isn't willing to do something as minor as remind me later, whatever they want probably isn' t that important.
Most importantly, don't let the stakeholders leave the conversation they should ask again in a month if your answer was really that you never intend to
what they've requested.
When you have to say no, express both appreciation and empathy.
To do this sincerely, take time to understand the request, both what the stakeholder wants, but also why it's important to them.
The feature may be required to fulfill goals assigned to it by their boss.
It might even be tied to a bonus or other incentive.
To express appreciation and empathy, say something like, I appreciate you thinking of how our product could be better, and I can see why this feature is
important to you in achieving.
And then in your own words, restate what they told you about why the feature important.
Be sure you're sincere about this.
False empathy is obvious and frustrating.
When saying no, it's best for product owners to provide one compelling reason rather than a list of reasons.
When offered a List of Reasons, people tend to pick the weakest reason and argue against it.
For example, I heard a product owner tell a stakeholder that she was unwilling to interrupt the current iteration to work on the stakeholder's latest request
for four reasons.
It would interrupt a team's momentum.
The team would need to re-plan the iteration.
She wasn't sure the new work would fit, and she wasn' t yet convinced the request was truly a higher priority.
The only one of these that mattered was the last.
That she was not convinced the new thing was a higher priority.
None of the other reasons matter.
But when the stakeholder heard the four reasons, she argued against the need to re-plan the iteration.
When saying no, be firm and offer your one most compelling reason.
If you and the stakeholder you're telling no to share the same overarching goal, remind them of this.
A product owner and stakeholders often have many different goals.
And yes, sometimes they're in conflict, but usually there is a higher product level goal that is shared that you can reference.
While working on a SaaS product, I saw the product owner handle this very well.
He and the team were working diligently toward a goal of decreasing subscriber churn by 10%. When asked to work on something he considered a distraction
from that, he reminded the stakeholder of their shared overarching goal, of reducing chern.
This helped the stakeholders understand why his request wouldn't be worked on in the short term.
When rejecting a stakeholder request, product owners should explain the consequences of saying yes.
This can help the stakeholders see why you feel compelled to say no.
If working on the stakeholder's request will affect the team's ability to achieve another goal, say so.
Explaining the consequence will help this stakeholder understand and hopefully empathize with why your saying no Instead of outright saying no to a customer,
a product owner may be able to offer an alternative.
While there may not be time to do everything a stakeholder is asking for, would it be possible to just do a portion of it?
Or ask the stakeholder if it would be acceptable to start on the request in three weeks.
Be careful though, only offer alternative if you really mean it.
Product owners often fear saying no and disappointing their stakeholders or customers.
But saying, no doesn't have to be so difficult.
I've found that being clear, providing one reason rather than many, being empathetic and appreciative, conveying that we share the same ultimate goal,
Explaining the consequences of saying yes and offering an alternative makes saying no much easier.
When done well, saying No can improve rather than harm a product owner's relationship with their stakeholders.