A product manager’s guide to saying no "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 15 June 2022 False active listening, Product Management, Product Management Skills, saying no, Stakeholder Management, Mind the Product Mind the Product Ltd 1593 Product Management 6.372

As a product manager, you have to say no to stakeholders, a lot. Find out how to master the art of saying no with empathy, so you can maintain positive relationships and stop all those zombie ideas from haunting you.

In brief:

  • Listen Actively. Ask the requestor to explain the idea in their own words, even if you’re already familiar with it. Some useful phrases include “help me to understand…”, “could you walk me through…”, “remind me…”.
  • Ask clarifying questions to ensure you understand the value the change would deliver. Find out who will be affected by the change and the problem it solves.
  • Ask the idea contributor to confirm whether your portrayal of the data tallies with their understanding. By doing this, you ask them to agree that you have accurately represented the benefits their idea could deliver. Check whether you have missed anything.
  • When you say no, avoid saying “I”. It’s important that this is not your opinion but based on research and data findings.

On a field trip, you speak to John, a user. John is super-engaged with your product and has lots of ideas about how it could be improved (well, perhaps he’s a little grumpy and thinks your product should do this stuff already). Back at the office Nikola, a developer, is frustrated that some of the business logic is in the wrong part of the code base, making development inefficient. You pass your CEO in the corridor, she’s read an article claiming blockchain will take over the world and wants you to investigate it… immediately.

You open your laptop and view the roadmap. You’re under pressure to deliver improvements that should increase the trial to paid ratio to 50% by the end of the quarter, your forecast shows you might, just, make the deadline. Any new ideas would jeopardise the current plan. So you say those four magic product-manager words that will get everyone off your case… “It’s on the backlog.”

Months pass. You’d forgotten about John’s ideas until you get a call from your customer account manager. John is asking why his ideas haven’t been delivered yet. He’s angry. Your customer account manager is angry that John is angry. You get off the phone and Nikola walks past. She’s frustrated. She’s still dealing with the technical debt she spoke to you about and is losing motivation. Your CEO wants a progress update on the blockchain initiative.

You might try those same words again. But this time your stakeholders have heard it once before, and seen no results, so are less likely to believe you when you say it again. You lose credibility and your stakeholders are dissatisfied.

What happened? You created an expectation mismatch. When your stakeholder hears “it’s on the backlog”, their expectation is “great, my idea will be in the product in the next couple of months”. What you really meant was the idea is not aligned to the product strategy, would deliver limited value, and is heading directly to the bottom of the backlog to die a slow death.

There comes a time in every product manager’s career when we learn we need to say no – a lot. To maintain positive relationships, we need to get good at it. When I first started to say no, I was terrible at it. The conversation would go something like this:

Person with an idea: I’ve got this great idea, we should do X.

Me: Yes, that is a good idea, but we’re working on Y right now. Then we’ve got Z lined up so we probably won’t be able to do X for a long time.

Person with an idea: But I need X because of all these reasons.

Me: We can have a look at X but we’ll have to see whether we can fit it in or not

<Time passes during which idea is validated and (de-)prioritised>

Me: We’ve checked and we can’t fit X in.

This conversation would often go round in circles. It left both parties feeling frustrated. At first, I thought I was doing the right thing by setting expectations upfront.

I started to hear feedback that other teams in our business didn’t trust the product team to fairly represent their idea during prioritisation. Then I realised I was saying no before truly listening. Something needed to change.

When someone tells you their idea, treat it like you are receiving a precious gift. They have spent a long time crafting an ideal solution. In your contributor’s world, this idea solves one of their biggest pains. When saying no to an idea, it’s important to first spend time admiring the wrapping, reading the gift tag and carefully removing the paper. Try to look pleased at receiving the contents, even though the gift list was ignored.

I’ve found this framework enables you to say no with empathy, and in some cases, even facilitates the person suggesting the idea to say no themselves.

A Framework for Saying No

1. Listen Actively

Ask the requestor to explain the idea in their own words, even if you’re already familiar with it. Some useful phrases include “help me to understand…”, “could you walk me through…”, “remind me…”.

Your aim is to ensure the person knows they have been heard and understood. Use active listening skills during the time they are talking:

  • Reserve judgement, there will be a reason why this idea is meaningful in the other person’s world
  • Don’t interrupt
  • Use affirmative body language to show you are paying attention
  • Pay attention, don’t think of your next response while the other person is talking
  • Paraphrase by repeating what is being said, to show you have listened

2. Find the Value

Ask clarifying questions to ensure you understand the value the change would deliver. Find out who will be affected by the change and the problem it solves.  Wherever possible, quantify the value (for example, “it could reduce app crashes by 50%”). Sometimes you may need to take the idea away to gather additional data. Having measurable data will become important during the later stages of this process.

3. Summarise

Summarising is a powerful tool to demonstrate that you’ve understood what the other person has said.  It’s particularly important if there has been a break since the last conversation with your stakeholder. Summarising means you highlight the key points of what has been said in your own words, without changing the meaning. Focus on the facts and keep any opinion out of your summary. For example: “So it sounds like this change could save 25% of our customers two days of effort per month, and increase the satisfaction of our primary contact – is that correct?” Ask the idea contributor to confirm whether your portrayal of the data tallies with their understanding. By doing this, you ask them to agree that you have accurately represented the benefits their idea could deliver. Check whether you have missed anything.

4. Explain the Cost

Explain the impact of making the change. It is unlikely the idea contributor will have full sight of the cost and it’s important they understand the “why not” of their idea. The cost might include:

  • The effort to develop this idea gives a poor return on investment
  • What you would have to give up to work on this idea instead
  • A divergence from the product strategy or roadmap
  • A compromise to the overall user experience
  • Accrual of technical debt

5. Say no

Now that you’ve laid the groundwork, saying no becomes a lot easier. Your stakeholder may already be coming to this conclusion themselves. At this point, it’s worth explaining any viable workarounds. Reiterate that you appreciate their idea and would like to hear any more they have in the future.
When you say no, avoid saying “I”. It’s important that this is not your opinion but based on research and data findings. Use phrases such as:
“The data shows us…”
“When we look at our product strategy, our key focus is…”
“Idea A would deliver a bigger benefit of…”.
As a bonus, it helps to be transparent about how prioritisation decisions are made in your organisation.

Stop the zombie Ideas

To prevent long-forgotten ideas coming back to haunt you while maintaining your credibility, it’s important to say no within a reasonable timeframe.  Saying no empathetically enables you to maintain a positive relationship with everyone involved.  Nearly all ideas have some merit, but we can’t and shouldn’t develop everyone, which means you will inevitably find yourself saying no to a good idea.

Always say no at the end of the conversation, never at the start.  This ensures you have demonstrated to your stakeholder that you have fully listened to their idea, accurately considered the impact it would have and a fair decision has been made.

In the words of Steve Jobs: “People think focus means saying yes to the thing you’ve got to focus on.  But that’s not what it means at all.  It means saying no to the 100 other good ideas that there are.  You have to pick carefully.  I’m actually as proud of the things we haven’t done as the things I have done.”

There’s more where that came from! Read more content on the product management craft

Comments 0

Join the community

Sign up for free to share your thoughts

About the author

As a product manager, you have to say no to stakeholders, a lot. Find out how to master the art of saying no with empathy, so you can maintain positive relationships and stop all those zombie ideas from haunting you. In brief:
  • Listen Actively. Ask the requestor to explain the idea in their own words, even if you’re already familiar with it. Some useful phrases include “help me to understand…”, “could you walk me through…”, “remind me…”.
  • Ask clarifying questions to ensure you understand the value the change would deliver. Find out who will be affected by the change and the problem it solves.
  • Ask the idea contributor to confirm whether your portrayal of the data tallies with their understanding. By doing this, you ask them to agree that you have accurately represented the benefits their idea could deliver. Check whether you have missed anything.
  • When you say no, avoid saying “I”. It’s important that this is not your opinion but based on research and data findings.
On a field trip, you speak to John, a user. John is super-engaged with your product and has lots of ideas about how it could be improved (well, perhaps he’s a little grumpy and thinks your product should do this stuff already). Back at the office Nikola, a developer, is frustrated that some of the business logic is in the wrong part of the code base, making development inefficient. You pass your CEO in the corridor, she’s read an article claiming blockchain will take over the world and wants you to investigate it… immediately. You open your laptop and view the roadmap. You’re under pressure to deliver improvements that should increase the trial to paid ratio to 50% by the end of the quarter, your forecast shows you might, just, make the deadline. Any new ideas would jeopardise the current plan. So you say those four magic product-manager words that will get everyone off your case… “It’s on the backlog.” Months pass. You’d forgotten about John’s ideas until you get a call from your customer account manager. John is asking why his ideas haven’t been delivered yet. He’s angry. Your customer account manager is angry that John is angry. You get off the phone and Nikola walks past. She’s frustrated. She’s still dealing with the technical debt she spoke to you about and is losing motivation. Your CEO wants a progress update on the blockchain initiative. You might try those same words again. But this time your stakeholders have heard it once before, and seen no results, so are less likely to believe you when you say it again. You lose credibility and your stakeholders are dissatisfied. What happened? You created an expectation mismatch. When your stakeholder hears “it’s on the backlog”, their expectation is “great, my idea will be in the product in the next couple of months”. What you really meant was the idea is not aligned to the product strategy, would deliver limited value, and is heading directly to the bottom of the backlog to die a slow death. There comes a time in every product manager’s career when we learn we need to say no - a lot. To maintain positive relationships, we need to get good at it. When I first started to say no, I was terrible at it. The conversation would go something like this: Person with an idea: I’ve got this great idea, we should do X. Me: Yes, that is a good idea, but we’re working on Y right now. Then we’ve got Z lined up so we probably won’t be able to do X for a long time. Person with an idea: But I need X because of all these reasons. Me: We can have a look at X but we’ll have to see whether we can fit it in or not <Time passes during which idea is validated and (de-)prioritised> Me: We’ve checked and we can’t fit X in. This conversation would often go round in circles. It left both parties feeling frustrated. At first, I thought I was doing the right thing by setting expectations upfront. I started to hear feedback that other teams in our business didn’t trust the product team to fairly represent their idea during prioritisation. Then I realised I was saying no before truly listening. Something needed to change. When someone tells you their idea, treat it like you are receiving a precious gift. They have spent a long time crafting an ideal solution. In your contributor’s world, this idea solves one of their biggest pains. When saying no to an idea, it’s important to first spend time admiring the wrapping, reading the gift tag and carefully removing the paper. Try to look pleased at receiving the contents, even though the gift list was ignored. I’ve found this framework enables you to say no with empathy, and in some cases, even facilitates the person suggesting the idea to say no themselves.

A Framework for Saying No

1. Listen Actively

Ask the requestor to explain the idea in their own words, even if you’re already familiar with it. Some useful phrases include “help me to understand…”, “could you walk me through…”, “remind me…”. Your aim is to ensure the person knows they have been heard and understood. Use active listening skills during the time they are talking:
  • Reserve judgement, there will be a reason why this idea is meaningful in the other person’s world
  • Don’t interrupt
  • Use affirmative body language to show you are paying attention
  • Pay attention, don’t think of your next response while the other person is talking
  • Paraphrase by repeating what is being said, to show you have listened

2. Find the Value

Ask clarifying questions to ensure you understand the value the change would deliver. Find out who will be affected by the change and the problem it solves.  Wherever possible, quantify the value (for example, “it could reduce app crashes by 50%”). Sometimes you may need to take the idea away to gather additional data. Having measurable data will become important during the later stages of this process.

3. Summarise

Summarising is a powerful tool to demonstrate that you’ve understood what the other person has said.  It’s particularly important if there has been a break since the last conversation with your stakeholder. Summarising means you highlight the key points of what has been said in your own words, without changing the meaning. Focus on the facts and keep any opinion out of your summary. For example: “So it sounds like this change could save 25% of our customers two days of effort per month, and increase the satisfaction of our primary contact - is that correct?” Ask the idea contributor to confirm whether your portrayal of the data tallies with their understanding. By doing this, you ask them to agree that you have accurately represented the benefits their idea could deliver. Check whether you have missed anything.

4. Explain the Cost

Explain the impact of making the change. It is unlikely the idea contributor will have full sight of the cost and it’s important they understand the “why not” of their idea. The cost might include:
  • The effort to develop this idea gives a poor return on investment
  • What you would have to give up to work on this idea instead
  • A divergence from the product strategy or roadmap
  • A compromise to the overall user experience
  • Accrual of technical debt

5. Say no

Now that you’ve laid the groundwork, saying no becomes a lot easier. Your stakeholder may already be coming to this conclusion themselves. At this point, it’s worth explaining any viable workarounds. Reiterate that you appreciate their idea and would like to hear any more they have in the future. When you say no, avoid saying “I”. It’s important that this is not your opinion but based on research and data findings. Use phrases such as: “The data shows us…” “When we look at our product strategy, our key focus is…” “Idea A would deliver a bigger benefit of…”. As a bonus, it helps to be transparent about how prioritisation decisions are made in your organisation.

Stop the zombie Ideas

To prevent long-forgotten ideas coming back to haunt you while maintaining your credibility, it’s important to say no within a reasonable timeframe.  Saying no empathetically enables you to maintain a positive relationship with everyone involved.  Nearly all ideas have some merit, but we can’t and shouldn’t develop everyone, which means you will inevitably find yourself saying no to a good idea. Always say no at the end of the conversation, never at the start.  This ensures you have demonstrated to your stakeholder that you have fully listened to their idea, accurately considered the impact it would have and a fair decision has been made. In the words of Steve Jobs: “People think focus means saying yes to the thing you’ve got to focus on.  But that’s not what it means at all.  It means saying no to the 100 other good ideas that there are.  You have to pick carefully.  I’m actually as proud of the things we haven’t done as the things I have done.”

There's more where that came from! Read more content on the product management craft