Stakeholder Buy-In
How do you get buy-in from stakeholders, who might have competing priorities, to support your program?
Stakeholders can mean anyone who was impacted by your project.
Think about a time when you faced resistance to your project. From whom and why?
First, think about 2-3 examples in your past that involve stakeholder management. Then, mention each example following a clear structure in which you describe the example, discuss what you did, and how it helped.
Do you have multiple examples or just one?
Have you expressed pros/cons for each example?
Why do you think you got buy-in in each example?
Have you taken the extra step to think about how you would handle stakeholder management in the company you’re interviewing at depending on their size, TPM team structure, and more?
Approach
This is a question about influence. When did I last influence someone to do something? How did I do that? How do I get things done when people aren't 100% behind what I want to get done? What techniques have worked for me in the past?
The standard way to think about these types of questions is through the Situation-Action-Result (SAR) method. First, I'll describe the situation. Then, I'll explain the action I took to address the situation. Lastly, I'll summarize the effect my action had on the situation.
Solution
I can think of two situations in my past experience that involve this, one involving product management and the other involving sales and the end customer.
The first situation was during a project in which we were trying to improve the security of various pages in our application. Initially, product managers (PMs) were reluctant to prioritize security improvements over existing roadmap items, typically new features. To get buy-in from PMs, I highlighted feedback that some large customers had sent in; this feedback expressed the pain the customers were facing around page security and the effect on their operations. The result was prioritization of security improvements and better customer sentiment.
The second situation was during a data migration effort in which we were moving customers using a legacy architecture to a newer architecture by migrating data from certain databases to other databases. The sales folks who handled the customer accounts as well as the customers themselves were hesitant to do the migrations as there was necessary downtime and changes to the user interface that would occur as part of the process. To get buy-in from the sales folks and the customers, I explained how the older architecture would not be supported by engineering in the future and that the newer architecture allowed for newer features that would be beneficial to the customers' operations; we also ensured them that we were performing the migrations with a lot of quality checks to ensure minimal disruption to the end customers. As a result, the sales folks and customers were excited by the post-migration world and facilitated the project.
In both of these situations, what I learned was that to get buy-in from stakeholders, I needed to understand what drove them. For product management, resolving customer frustrations was of great importance, leading to better retention and adoption. For sales, enabling future upsells of new features and keeping customers excited about the platform was of relevance. Different stakeholders had different knobs that needed turning. I could have also used the influence of engineering leadership to win over certain stakeholders but I reserve that as a last resort if stakeholders are particularly resistant to change; in these cases, I dealt with these situations less top-down as I sensed more flexibility based on my interactions. I'm curious; what kinds of stakeholder issues do you see here at your company?
Takeaways
- Be conversational. The response shouldn't be robotic; it should have a flow to it.
- Be ready to dive deeper into each example you provide. There will be questions in between and a natural flow to it.
- Following a concise yet effective structure is critical.
- Giving more than one example shows experience.
- Describing different approaches and why you chose one over the other shows that you can weigh tradeoffs. Good TPMs can wield multiple forms of stakeholder management.
- Reflection on techniques that have worked also highlights a deeper understanding of TPM work.
- Ask about how things are at the company you're interviewing with; it's as much of an interview for you to find out more about the company as it is for the company to find out more about you.