Working with stakeholders- what I have learned as a Product Manager

As I wrote about in “My move from Business Analyst to Product Manager- what changed?” a significant part of my job is keeping a huge number of stakeholders involved and updated on key decisions on things that everyone cares a lot about. The stakes are high because I am constantly thinking about how the choices I make are going to affect different teams, as each group has a different context, different goals, experiences, constraints and risk tolerance.

Why do I care?

Before I share my experience with different groups, let’s talk about why stakeholder management is extremely important for product people.

1. Individual stakeholders may not have the whole picture most of the time which a PM has & thus it leads to a lack of understanding & faith among different teams.
2. A successful product is a team effort. Product managers may not always make decisions but they need to ensure that the best decisions get made. This can only be done by collecting and synthesizing inputs from those who know something valuable to the product/business.
3. Stakeholders are directly impacted by the outcomes of the product decisions I make, if the product fails, they fail. When they fail, I fail.

For many years I have struggled to navigate through diverse groups of stakeholders to get products off the ground, from C-suite all the way to end-users. Navigating this complex landscape can often feel overwhelming and give a feeling of powerlessness.

But in general, I’ve realized the value of collaboration with different teams and how keeping everyone involved and updated is rudimental for the success of products, especially in B2B products. And the main point to appreciate here is that each of these teams has a separate world unto its own. For these reasons, you can’t communicate with these different parties in the same way.

How to be more empathetic and show that you care?

Understand their background. Start by understanding where each of the stakeholders are coming from. My favorite way to approach this is to set up a coffee chat when we first start working together, way before we get into any tricky situations. For example if I am talking to a customer support leader for the first time, I would ask about their experience with the product, challenges they have faced recently, and their goals for the year. And then when I get the answers, I dig deeper, sometimes just with a simple “tell me more”. I learn a lot of non-obvious goals this way.

Explain where you are coming from. I help them understand why I am doing what I am doing. It’s not obvious for them to understand all the constraints I am operating within. Also, once I’ve figured out their goals and their sentiments with the products, it is easier to explain changes/updates in their language, highlighting things that interest them and things they need to be fully aware about.

For example, when talking to product implementation or pre-sales teams, I try to highlight aspects of the product like steps to getting a new feature activated for a customer, the ETA for it and how to get it turned off if needed. Knowing their goals in mind usually help me anticipate how they would react to different options, and help me come up with solutions that would really work for them.

Make them a part of the journey. Providing a one-off update or getting a point-in-time decision on something is important. But what’s more important is to keep them involved in the journey as the product/feature evolves. I try to take feedback along the way and communicate any evolving decisions/ changes, so there are no surprises and uneasiness later.

My experience with different stakeholder groups

Here is my reflection on common tough situations and challenges in managing different stakeholder groups and what I do to avoid them and how I react to such situations.

💰Product sponsors and organizational leaders: who are focused on the ultimate business outcome of a product.

• Failure in launching a key product feature in time: I send regular updates especially closer to launch timelines helps in managing expectations around timelines. Also communicating the impact of the delay and mitigation plan to bring it back on track is appreciated.
• Urgent feedback from enterprise customer who shouts the most: Usually C-suite or similar positions get direct customer feedback and an outcome of that is a shift in product priorities or roadmap. In such situations, I try to understand the underlying problem the customer is facing to separate ‘wants’ from ‘needs’. I also ensure the business leadership team knows the impact of shifting priorities and the ripple effects in the roadmap.

🎭Sales teams: who are closest to customer decision makers and are selling the solutions/products.

• This is good, but the customers want more: I face this situation very often when speaking with Sales teams about any new capability. As the product manager, I know the evolution plan of the product, so it’s my responsibility to reassure the sales teams that there’s more, but it’s coming later! This also helps the sales team in customer conversations, as they can confidently talk about plans for the future and show them the journey.
• The product needs XYZ feature asap: To qualify the need I usually follow up with these questions- will it bring in new customers, or let you tap into a whole new industry, or is it because a large prospect said they might be interested if the product had XYZ feature? It is really important to maintain a positive relationship with the sales team, and not fall into the common product management pitfall of putting every request into execution. 😎

🔔Customer support: who are on the frontline and are likely to have the most in-depth user understanding on the team.

• Too many issues in a newly launched capability: This is every product/engineering team’s nightmare but it does happen. This leads to support teams facing a lot of heat. What helps, in this case, is a clear root cause analysis, list of identified fixes, the plan to fix them, regular updates on the plan and post-fix feedback.
• Lack of technical details about the new feature: I make sure that customer support teams know the technical aspects of the product like browser or device compatibility, any known issues with OS, or other troubleshooting steps for efficient first-line support. I usually partner with engineering teams to document such scenarios.

📑Developers: who have ownership of bringing the product to life.

• Shifting feature priorities and changes in the feature requirements. I try to communicate not only what the product should do, but why. How will the desired functionality benefit customers and how does that roll up into business objectives. Also, being there for them as a go-to person for any subsequent questions also helps build trust and makes developers feel that I am part of the team.
• Is it a bug or improvement? It doesn’t matter! I track the ticket type for performance metrics but at the end of the day, if there is a scope for improvement, I plan to get it done. Reading too much into whether it was a missed requirement or a wrong implementation doesn’t help end users.

🎨Designers: who are responsible for the visual communication and experience of the product.

• Balancing nice to have UX improvements and timelines: this is a tough one and requires great partnership with design teams. As much as I like to create “the best” experience for end users, sometimes timelines do not allow it. I partner with design teams to test prototypes and understand the value of the improvements, and then decide must-haves, could haves, and nice to have based on it.

Above are examples of some of the teams I work with. If only there were just limited stakeholder types, this aspect of product management would be a lot easier, only limited version of the roadmap; one eay way of explaining the product’s strategic goals and one way to answer anyone’s question. Unfortunately, there are lots of stakeholder types, and each requires a slightly different approach when it comes to communication strategy- and I believe that’s where the fun and thrill lies! 😏

Everyday is a humble attempt to understand everyone’s perspective, committing to considering their input and making best efforts to resolve their concerns. That is how you build up trust and hence why communication is critical to managing stakeholders efficiently.