All related (16)
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.

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.

Devika Nair
Director of Product, Oracle Cloud Infrastructure, OracleOctober 30

It is important to align your requests to the goals of the team you are partnering with. From that perspective, you need to align your approach to stakeholder management.

For example, your design leadership might be more interested in the long-term vision of your product while sales is interested in how much customer demand your product is likely to generate.

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, June 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.

Karabi Bharadwaj
Program Delivery Manager, MicrosoftDecember 14

The answer is Yes.

We do not expect every stakeholder will have same questions, similar stakes, similar mindset and same requirements hence management will be different when reaching out to various stakeholders.

'How'- do I manager different stakeholders, is a broad question and I am unable to provide an answer that will be standard for various teams, this is not pragmatic. However, in general, we keep them updated on project contexts, changes, lowlights & highlights at least weekly, to avoid any surprises. In addition to this I try to be in touch with them a little less formally which helps me charter tricky situations and I usually get a buy in quickly. Since I am working remotely hence 'less formal connection' for me is a casual hellos, and quick semi formal chats. At time, I am intentional in sharing my issues and challenges with the stakeholders and reach out proactively, asking if I am making mistakes or what is their recommendation. People like to get some attention, :) hence being intuituve helps a long way.

Keeping all project specific information ready to be shared is a must.

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.