Six Guidelines for Saying No to a Stakeholder

Saying no can be very difficult. Most of us like to please others. But when we say no, we disappoint the requester.

But saying no to stakeholders is an important part of the product owner’s job. The product owner is 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 some stakeholder’s feature request, the product owner will need to say no to some future customer request. The team’s time is limited and a yes today will necessitate saying no to some later opportunity.

This means that learning to say no to stakeholders is a skill every product owner needs to master. I want to share six guidelines for how you can do so politely but firmly.

1. Be Clear with Stakeholders: Is this No? Or No, for Now?

When product owners need to tell stakeholders that they are not prioritizing a particular feature request, they should be clear about what their “no” means.

If you are you 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’ll never do that feature.

If on the other hand you’re telling the customer no for now--that later you might work on that feature--be clear about that as well. You might, for example, say,

I'm sorry we can’t work on that right now. Believe me, I wish we could. But we’ve already made commitments to deliver [name whatever it is] by August. I need to keep the team focused on that or we risk missing that commitment. But if you remind me about this in August, I promise to consider doing it after that.

Notice in this example reply, I didn’t suggest promising you’d do it later, only that you’d consider it.

Also, notice that you put the burden back on the stakeholder or customer. Make them re-initiate the request or remind you when the time is right. I do this to make sure the feature is still important to them. If the stakeholder isn’t willing to do something as minor as remind you about a feature request, I’d question whether the feature was ever very important or urgent.

Most importantly, don’t let the stakeholder walk away thinking they should ask again in a month if your answer was really that you never intend.

2. Express Appreciation and Empathy for Customers

When presented with a feature request, product owners should always thank the stakeholder and indicate their understanding of why the feature is important to that stakeholder.

Someone took time to ask something of your team. That means they’re interested in your product. Tell the customer that you appreciate their taking the time to ask. Something like this is all you need to say:

Thank you. I appreciate you thinking of how our product could be made better.

Beyond being appreciative, product owners should also show empathy for the stakeholder’s situation. You’re about to say no to a request that is likely very important to them. The feature may, in the stakeholder’s mind at least, be required to fulfill goals assigned by their boss, and might even affect them financially.

Before conveying your empathy, be sure you understand why the feature is important to the customer. And if you don’t understand, make sure you do before saying no to the feature request.

You can express your empathy for their situation with a statement like,

I can see why this feature is important to you in achieving [whatever it is].

Be sure you’re sincere about this. I don’t think I’m unique in being frustrated by false empathy.

3. Offer Only One Reason for Saying No

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.

Imagine I am your customer and I ask you to have your team put aside their current work in favor of a feature I want. You tell me,

I’m sorry but I can’t do that. We’ve already planned this sprint. I’d need the team to have another planning meeting, and they won’t like that. And I’m confident that what we’re currently working on is higher priority.

What part of your argument do you think I’ll attack? The need to do another planning meeting or that the current work is higher priority?

I’ll go after the argument that the team would need to do another planning meeting and won’t like it. I might offer to make the meeting less unpleasant by doing it over lunch and I’ll buy the pizza.

Even if you still don’t like my plan, I’ve now changed the conversation: We’re arguing about whether to conduct a meeting rather than over the merits of the feature. That’s a more difficult argument to win.

And it’s the wrong basis for making the decision.

Be firm and offer your one most compelling reason for saying no. If the stakeholder successfully convinces you to change your mind by arguing that point, it may well be worth considering whether your secondary reasons for saying no are sufficient. If not, you might need to say yes to the feature.

4. Convey that You Each Have the Same Goal

If the product owner and the requesting stakeholder share the same overarching goal, the product owner should mention it when delivering unwelcome news.

A product owner and stakeholders each often have many different goals. And, yes, sometimes, they are in conflict. But usually there is a higher, product-level goal that is shared and that you can reference.

This is particularly easy if you are both part of the same company. In that case, say something like,

• As much as I’d love to have the team work on that for you, we need to stay focused on [larger, shared goal].
• As I’m sure you remember, we’ve all been given the goal to [larger, shared goal].

Reminding the customer that you share a common goal helps them understand why you need to say no, even if they still don’t agree fully with the answer.

5. Explain the Consequences of Saying Yes to the Stakeholder

When rejecting a stakeholder request, product owners should explain the consequences of saying yes.

This can help the stakeholder see why you feel compelled to say no. You could, for example, say,

• If we worked on your feature instead, we won’t be able to meet the big deadline.
• The team is already working long hours. I can’t add this to their workload without removing something else that we’ve already committed to someone else.

Explaining the consequences will help the stakeholder understand, and hopefully empathize with, why you are saying no.

6. Offer the Customer an Alternative

Instead of outright saying no to a customer, a product owner may be able to offer an alternative.

You might offer something like:

• We can’t possibly do everything you’ve asked, but what if we did this subset of it?
• I can’t have the team work on this right now, but what if we start on it in three weeks?

Be careful: Only offer an alternative if you really mean it.

Saying No Doesn’t Need to be Difficult

Product owners often fear saying no and disappointing the stakeholder or customer. 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 make saying no much easier.

When done well, saying no can improve, rather than harm, a product owner’s relationship with the stakeholder.

What Do You Think?

How do you tell stakeholders no? Have you found certain techniques helpful or harmful? Please share your thoughts where this post was originally published, on the Mountain Goat Software blog.

If you liked this article, you can sign up to receive my one best, short tip about agile each week. These tips aren't online and signing up is the only way to receive them.