All related (9)
Guy Levit
Sr. Director of Product Management, MetaApril 25

Ultimately Product Management is about people. I do approach stakeholders differently, but it’s based on who they are, rather their role. Some stakeholders like to be consulted ahead of time, some prefer being briefed in bigger forums where they can gauge the reactions of others. Some like structured approaches, others react to the anecdotal evidence. Some may have specific trigger points on specific topics.

Part of my role is to understand those differences and be able to navigate through them.

Marc Abraham
Senior Group Product Manager, IntercomJune 20

No, the foundations of stakeholder management are the same for me, irrespective of the discipline and expertise involved. Like I mentioned in one of my earlier answers: listening and developing empathy are key, as well as involving stakeholders early and often in the product (development) lifecycle.

Julian Dunn
Senior Director of Product Management, GitHubSeptember 7

There are some commonalities and some differences. First and foremost, across all constituents, I always promise that product management will always listen to them, carefully consider their feedback and advice, but we may not do what they want. This isn't to be mean. Many constituents not worked with truly empowered, autonomous product teams, so they don't understand why product management is not just a department of project managers to shepherd through work orders that they are issuing in the form of "feature requests". It's important to set the record straight about who's ultimately in charge of the roadmap.

Now, by doing so, I'm also obviously inviting these constituents to hold us accountable to customer satisfaction from what we are building. After all, with great power comes great responsibility, and if product continually is failing to deliver products and features that delight customers, then we deserve to lose our jobs.

With that out of the way, I always try to put myself in the shoes of the constituent and what they care about. How are they being measured, what is their background and context, what is their level of tech and business savvy and what do they need to know, in what form. This is a constant learning process, as other functions in an organization are always evolving! But just basic knowledge about what are the key drivers of constituent points of view -- to be blunt, what are they paid on -- helps to properly frame up any discussion about roadmap. It would behoove any product manager to understand the difference between "customer success", "customer architecture", "sales" (and the many roles in sales), "marketing" (and the many roles in marketing), etc. It's not all just "sales and marketing". Achieving this level of understanding is on the product manager.

Finally, be consistent. I use a small set of artifacts to describe roadmap, and I use them again and again with different constituents. The only difference between these artifacts is the level of resolution & detail. A salesperson for example typically doesn't want that much detail -- he or she just wants to know what are the hottest features that are going to help him or her retire quote. Sales engineers want to know which are the most complex features they're going to need to learn, but also which ones are going to be the most differentiated from competitors and impactful for showing off in a pre-sales motion. And so on. Being disciplined and consistent in articulating roadmap, down to just silly things like "don't call an initiative 5 different things to 5 different groups" goes a long way towards building confidence in you as a product leader, particularly as you know constituents will talk to each other without you. The more their stories align about what's going on in product, the higher level of confidence they have in you and your leadership.

Andrew Clark
VP of Product, 15FiveJune 9

Yes and no. I think of these relationships in terms layers of depth.

Design and Engineering are, of course, your deepest stakeholder relationships. You're building a product together, so the dynamic is fundamentally different.

Customer Success (and Support) should be the next layer. They should generally have a better understanding of the product than your go-to-market stakehodlers, and the time they spend with customers usually leads to more specific insights. This relationship can and should be more collaborative than the next layer.

Sales and Marketing are the next layer, as their input is typically based on pattern recognition. Incredibly important, but often not as deep as the other layers. You also need to nurture this group differently, and be intentional about demonstrating your impact, because they can often be the loudest when they don't feel they're being supported.

Tracy Montour
Head of Product Marketing, HiredScoreJuly 30

I do and it all starts with understanding their needs, what motivates them, and what demotivates them. Some teams like to be more involved and are motivated by being part of the process and others are motivated by having to do less work, making them more comfortable with a different approach. Get to know your stakeholders, understand their goals, and build relationships. Once the relationships in place, you can better understand how to influence and manage expectations for these teams. 

Andrew Clark
VP of Product, 15Five
I flinched at the word "approval" here. I don't like the idea that Product would be seeking roadmap approval from other departments in the org. What you really want is buy-in. You want your key stakeholders to be as confident and excited about the roadmap as you are.  Here's how to make that happen: 1) Provide channel(s) for continuous input and take that input seriously. Stakeholders will make sure their teams to provide good input so long as they see how that input influences the roadmap. You may have to connect the dots for them. 2) Over-communicate roadmap strategy and th...