Do you approach stakeholder management differently based on the team you're talking to? (Design, Marketing, Engineering, Sales, Customer Success). And if so, how?

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.

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.

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.

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.

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.

My approach at my current and former company (both of which are medium sized) is based on how well-resourced the other team is.

• For example, in experiences where Design and Marketing are still growing into the opportunity, I've found that the most beneficial conversations tend to be focused on prioritization and sequencing.

• With functions that tend to operate at a greater scale, like Sales and Customer Success, I have found it is best to quickly figure out who can be your "single point of contact" – e.g., unify feedback across their org, speak authoritatively on behalf of the function – in order to avoid balancing 30 opinions from 30 people.

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.

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.