I shot an interview with Adolfo Foronda about saying “no” as a product owner. Check it out! Click “Continue reading” below for an approximate transcript.

One of the biggest jobs for a product owner is to say no. Tell me how often you’ve had to say no, to what title (for example CEO, owner, VP, other), how you did it and what was the outcome? What did you learn about communicating the “no” to higher managers?

I somewhat disagree that “saying no” is the biggest job for a product owner. This doesn’t mean that a product owner should ever blindly say “yes,” but rather that we need to look at the product owner’s core objective and choose the best way of accomplishing that, which isn’t always done by saying “no.” In fact, I am having a hard time thinking of a time in my career where simply saying “no” would have been the correct approach.

It’s important to understand everyone’s responsibilities to set the context for this conversation. It’s a product owner’s job to maximize value delivery by effectively building the correct product. The two parts of this are “effective” and “correct product.” Having the team oscillate between multiple different priorities at once or overworking is ineffective. It creates waste due to context switching (a form of “muda” waste) and overburden (“muri” waste). Working on multiple things at once also delays value delivery. Building the wrong thing is a form of overproduction as well, another example of “muda” waste. One of the companies I used to work for had propaganda-style posters that exclaimed “waste is anything the customer doesn’t want and isn’t willing to pay for.”

It’s usually a leader’s job to ensure that their teams are delivering a maximum return on investment. So these objectives are quite complimentary. Often a leader will come to a product owner with a request because they believe it will deliver more value than whatever the product owner and their team is working on now. They sometimes have more information than the product owner about how solving this problem fits into the company’s strategic vision, especially in more complex environments with lots of interdependencies. Often, they’ll come to you with requests because they don’t understand the value of what you’re already working on. This means you may not have been doing a good enough job of selling your product and backlog’s value.

It’s important to understand where the leader is coming from. In larger organizations—particularly those with heavily command-and-control cultures—that leader may very well be just a messenger of their manager’s directive. Their bonus could be tied to getting a particular product out the door by a given date. It is important to empathize with the person who is making the request. My favorite description of anger is “the emotion that rises in response to a goal impeded.” In the wrong culture, hearing “no” can create a lot of fear and anger.

I highly recommend a book and training course called “Crucial Conversations.” They’re designed to help you hold conversations when ”the stakes are high, opinions vary, and emotions run strong.” Clearly we can see that these conditions will be present virtually anytime a product owner has to say “no.” There’s a lot of gems here, but in a nutshell: do you have rapport? Can you create safety and a sense of shared purpose? Can you come to a solution together. Building trust with your leaders in advance will make all of these conversations infinitely easier. So that’s the context that all of this takes place in. What you say is less important than how you say it.

That said, you still need to say something.

So it’s valuable to talk to one another. The first words out of your mouth shouldn’t be “no,” but rather, “what problem would you like to solve?” Leaders often come to product owners with specific ideas or solutions in mind. Product owners are generally better than leaders in understanding what solutions are appropriate for a given problem statement, and user experience folks are even better than product owners. It may be that the problem that the leader is looking to solve is either a) not really a problem or b) better solved another way. You may not need to say “no” after all.

Can you share some of the techniques and approaches you use to convey the message that something is not possible?

First, things are rarely “not possible.” Many thought landing a person on the moon was impossible. JFK is credited with asking the people who said it couldn’t happen with making it happen. It can be challenging, but there’s a real growth mindset in asking yourself “what would it take to make this possible?”

Just because something is possible doesn’t mean it should be done, or at least not right now. Figuring out that “no” versus the “not yet” is important. Saying “no” puts up much more of a barrier to your leader’s goal progression than saying “not yet.” Sometimes it’s worth taking the problem statement back to the team for their perspective as well. Sometimes it’s worth declining or deferring a solutioning discussion because the problem isn’t worth solving yet.

If your answer is “not yet,” this is a prioritization discussion. Your leader might want it right now. Can you justify why this is worth interrupting work in process at a cost of not only deferring that work but also losing most if not all of the progress that has been made so far?  If you can avoid this, you’ve already done a good job of defending your team. Either way, this is a matter of “what would you be willing to delay or give up so that I can deliver this for you?” If their answer is “nothing,” you don’t have the rapport with your leadership or the corporate culture to do your job well.

Finally, if you wish to say that something is impossible, you had best be sure that your team agrees with you. Better yet, consider running a “spike” to do some investigative research with your team. Your success will again depend on your rapport, culture, and ability to articulate why something is impossible.