One of the biggest challenges that many new product managers face is that they want to make sure that they’re making a good impression on their stakeholders, and they don’t want to say “no” to any request coming in. They don’t want to be viewed as a blocker of progress or as an unsympathetic ear that only does what they want, come hell or high water.
Similarly, one of the biggest challenges that established product managers face is the realization that with limited resources, limited time, and limited patience, the company expects far more from the product and the product manager than they can ever deliver. And these unreasonable expectations only get worse as more and more people push for more and more features.
But I’m here to tell you, there’s a way to manage expectations and to turn down the opportunities that others present to you without coming off as a dictator or as a blockade to getting things done. That is the art of saying “no” without every actually saying “no”.
Listen Twice as Much as You Talk
We come first to one of my favorite aphorisms — human beings have two ears and one mouth, so they should always listen twice as much as they talk. There is almost no other role in any organization for whom this is more true than the Product Manager. It’s especially challenging for us at times, because we have so many people who want out time, who want to sell us their stories, and who want to further their agendas (either explicitly or implicitly). But it’s perhaps the best tool that you have in your backpack when it comes to saying “no” without saying “no.” And that all boils down to one simple fact — people want to know that they were heard. Even when a decision is made that they are entirely against, or that damages them in some way, as long as they know the you heard what they said and that you understood the point that they were trying to make, most people will accept the outcome.
People want to know that they were heard.
I’ve experienced this personally in, of all contexts, the courtroom. On the rare occasion I’ve been able to sit in as a pro tem judge in a District Court, presiding over traffic infraction mitigation hearings. And I found it absolutely amazing in that context just how okay people were with imposing fines and consequences, so long as they got to tell their story and they felt heard and understood. The only times that someone got upset was when for technical reasons I was unable to confirm some information that they had given me (they were licensed in another state and we don’t have cross-state driving records). She wasn’t upset that she got fined; she was upset that I couldn’t listen to her story (or, I couldn’t believe it because I couldn’t confirm it). Out of about 300 cases that I decided, this was the only one that resulted in an upset person in the courtroom.
Relate Honestly to Everyone
It’s not enough just to listen to what your stakeholders are telling you, though — you have to relate to them on some common level. You have to make them feel as though you not only hear what they’re saying — the facts, the figures, the customers, etc — but that you feel their pain to some significant degree. You need to figure out how to empathize with the person that’s describing their pain and the features that they believe will help them out. You need to use all of the capabilities in both your emotional and logical considerations. You want that person to walk away from you with the feeling that they were heard and that they were understood. Then, no matter what the outcome, they can feel like they were a valued component of the decision.
People want to know that they were understood.
This is not something that you can “fake it until you make it” with, though. Artificial empathy can be seen through like a car’s windshield, and turns something that would be comforting and reinforcing into something that condescending and patronizing. You need to figure out how to actually put yourself in the other person’s position, and you need to figure out how you can feel some amount of the pain that they do — even if you don’t believe it’s a real pain, and even if you think the person themselves is condescending and patronizing to you. Because honest empathy is the surest weapon against such artifice on the other’s side as well — if you can turn their fake pain into something real, you’ve achieved something that they themselves have been unable to do.
Provide Alternatives
Assuming you’ve identified the pain that the person is feeling, and assuming you’ve done your usual work with the Five Why’s, then you’re in a position to think about what you’ve already got in-plan or on your roadmap or backlog that might already be along the same lines. What similar problems are you planning on solving already that you can position as viable alternatives in the shorter term than whatever mega-project they’re undoubtedly asking for? Are there any other resources or approaches that can be leveraged to solve the pain — new positioning, better training, new tutorials?
People want to know that there are other options.
Rack your brain, check your resources, do everything that you can to show that there’s a light at the end of the tunnel already that the person you’re talking with can use to alleviate some of their pain. Reinforce the process that you’re using – hopefully that’s an Agile process, and they can discuss re-prioritizing things at some predictable interval. The goal here is to be a collaborator and not an obstructor — saying “no” ends the conversation; saying “maybe” or “how about this” keeps the conversation open, even if the end result is identical.
Open the Kimono
One of my favorite sayings from one of my supervisors at a job a few years ago was “How far are we going to open the kimono on this one?” He usually applied it to discussions with partners, but he also applied it to our product team. It was his way of asking us just how transparent were we planning on being within the organization. To him, and to me, the default position was one of complete transparency — in the planning, prioritization, execution, and delivery of our product. And this was an amazing tool for redirecting requests and making people understand the consequences of what they were asking for. Each of our teams had a 10-item backlog of work that was planned, defined, and prioritized. These lists were publicly available, posted on walls around the development team.
People want to know what’s going on.
And, whenever a stakeholder would come up to a member of the product team with a new project or feature that they needed desperately, we could very quickly and easily take in their feedback, and then point to the wall and say, “That’s great, but what would you bump for us to take that on?” This served two purposes: (1) it reinforced the process, the prioritization that had already occurred, and the work that we had planned for our strategic and tactical goals; and (2) it put the onus on the person asking for the feature to justify some change in plans. It was a very rare situation in which someone else was willing to put their name on such a request. And when it did, it was usually for a very good reason.
You’re Not Saying “No” — You’re Saying “Not Now”
Most importantly, the best way to say “no” without saying “no” is to not say “no” at all. It may sound like something Dick Cheney or Donald Rumsfeld would have said, but it’s very true. As a Product Manager, the times in which we should actually say “No,” are exceedingly rare; rather, we should always be saying “Not now,” or some variation thereof. “No” closes off conversations; “No” puts a wall between the two conversing parties; “No” has nothing but negative connotations — connotations that are inevitably transferred from the conversation to the person saying it.
People want to know that there’s hope.
Rather, you need to instill and reinforce the cultural belief that anything is possible — that it’s entirely a matter of prioritization and justification, and that under the right circumstances, the entire plan is subject to change on a moment’s notice, if the right problem is identified that has an urgent solution to be delivered. We want people to come to us with their ideas, with their suggestions, with their expertise and their knowledge; we need our stakeholders to believe that they can come to us with anything and see it come to fruition at some point in the future. Without the input and support of our stakeholder, Product Managers can never get the right things done at the right time.
