A Product Manager's Guide to Navigating Stakeholder Feedback

Product Managers are no strangers to exploring customer needs, but managing stakeholder feedback can be a more delicate – and dare I say tension-filled – story.

You’ll know the struggle is present when you hear comments from Product folks like, “My stakeholders aren’t on board,” or “my VP doesn’t get what we’re doing here,” or “the directors don’t seem to like my roadmap.” 

The reality is, you probably have to talk to your stakeholders more than you get to talk to your customers. I mean, your customers aren’t heating up their leftover pasta in the breakroom when you pop in to refill your coffee, and they probably don’t show up in your internal company chat at 3:45p on a Friday. 

If these interactions fill you with existential dread, then you’re in need of a stakeholder communication tune up. Here’s what that entails:

Act I: Actually Have a Conversation

It sounds obvious, but be honest with yourself: when was the last time you heard feedback – whether directly or indirectly – from a stakeholder and decided to pursue a broader conversation around it?

Believe me, I know it can be scary to face the chatter or rumor mill or company grapevine head on, but addressing the feedback with the person who gave it is critical to finding clarity and alignment. 

Early in my career, I received an SOS message from someone six levels above me and, without questioning it, marched straight back to my team with the new orders from the top. And do you know what my team said? “Why are we being asked to make this change?”

I didn’t have an answer because I was too afraid to ask, and that’s not the best way to solve problems.

Here’s another example: let's say that coming out of a roadmap review, you heard that one of your VPs challenged where a security upgrade fell on the priority list, but told your leader instead of talking to you directly. Or, maybe they delivered their displeasure in the last 10 minutes of a meeting (the notorious “swoop and poop” maneuver). Rather than assuming it means you need to revise everything, what if you had a conversation with the person to better understand why they’re feeling that way?  

This leads me to the next step in navigating feedback with more confidence and finesse.

Act II: Dig Deeper 

As a Product person, I have no doubt that you know about the Five Whys – a tool used widely in user research to get at the essence of helpful information.

The idea is that by asking “why” five times, you slowly peel back the layers of the onion, shedding the superficial responses early on and eventually getting at the good stuff by the time you reach question/answer four or five. This technique works as well with stakeholders as it does with customers in discovering the truth behind a reaction. 

So, in the case of our VP and the security upgrade, you can use the “5 Why’s” to figure out what's behind the concern. And not just the “because I said so” answer. Is it that the risk of waiting to do the upgrade has been over- or under-stated? Why do they believe that? Do they know about some competitive information that changes the landscape? Is there a big contract up for review with a nervous customer? Is legislation changing that might render the upgrade obsolete? All of the answers to the questions above could make the case for accelerating OR delaying the upgrade. Until you start asking “Why,” you won’t know what to change or how to change it. 

Truthfully, Product folks deserve a lot more information than they typically get with regard to stakeholder feedback. We all know the exquisite pain of a quickly jotted note asking to move something up, push it back, or question why we’re doing it in the first place. But taking the time to seek added context is essential to being able to troubleshoot useful solutions and viable alternatives. 

This approach opens up bigger (and necessary) conversations that allow you to get inside the minds of people whose input you’ll need to take seriously in order to get buy-in.

In Closing

As Product people, it’s important to remember that we can and should apply the tools we have as broadly as possible. In this case, curiosity about the customer and user experience should be extended to your internal stakeholders to help you be more successful.

Sometimes these stakeholder behaviors are indicative of a broader cultural or operating model issue (which is what we’re kind of obsessed with addressing at Tuckpoint). 

That said, sometimes you really can save yourself a great deal of churn and rework just by having a simple conversation.