Techniques for Making it Easier to Manage Stakeholders
Collaboration with internal stakeholders is crucial to the success of any new product or feature. But how do product managers engage team members who aren’t under their purview?
Every day, product managers must work together with a whole slew of different stakeholders. Whether inside our company or externally, we all have different types of people who need our attention, and each one of them has a different set of needs demanding a different type of interaction.
In this article I will try to identify the key stakeholders in a product manager’s orbit - to define how we can understand them better, create empathy towards them and more. In addition, we will focus on how to create visibility so our stakeholders feel secure that we will create a product that will help them succeed.
So what is a stakeholder?
According to Project Management Institute, 2013, a stakeholder is:
“An individual, group, or organization, who may affect, be affected by, or perceive itself to be affected by a decision, activity, or outcome of a project.”
So basically, anyone we encounter at work? As product managers, nearly everyone we work with can be considered a stakeholder, especially the people not under our purview. So how can we manage stakeholders without actually managing them?
I started thinking about this issue a lot when I felt that I wasn’t doing such a good job of managing my internal stakeholders at work.
I started by identifying the problem statement:
Stakeholders have conflicting needs and priorities, are affected by office politics and do not always share the same vision as us, but our job is always to build a product that will help all of them do their jobs.
I thought about this problem statement for a long time, and researched it through “user interviews”. That is, by speaking with my colleagues to review on the main pain points of working with me. I then came up with the following 10 commandments of “managing” stakeholders, guidelines that can make it easier for product managers to work with stakeholders.
Seems trivial, right? Well, in the heat of the moment or on a tight deadline, not so much. Do whatever it takes to make yourself feel calm before you speak with ANY stakeholder and make sure never to speak with them if you are not relaxed (or tired, hungry, or in a rush). And the same is true for the stakeholder. Make sure they are free and have the headspace to speak with you. If you try to force a stakeholder to speak with you about something you need or something you want his/her feedback about just to get it over with, then you will not receive the feedback or information you really need.
2. Identify Your Stakeholders
Different stakeholders in the company have different needs from the product team. Striving to learn and understand each stakeholder in the same way we strive to learn and understand our personas, will enhance our ability to establish a better relationship between us and the stakeholder, and to empathize with the stakeholder.
Here is a CEO persona I created as an example:
→ Goals: Making sure the company achieves its goals and keeping investors happy.
→ Type of Person: Normally very busy and travels a lot.
→ Relationship with the product manager: The PM is the person who makes sure the CEO’s high-level goals can be reached through the company’s product.
→ How can a product manager empathize with him? Understand that CEOs are under a lot of pressure and help them feel they can trust you and all is under control.
3. Empathize with Your Stakeholder
As product managers, our job is to understand the needs and constraints of our customers, to empathize with their pains and to be the voice of the customer. Well, the same approach should be taken with our internal stakeholders. We need to try and feel the pain our customer success manager feels when he or she continually reports the same bug affecting a top customer. We need to recognize the frustration the sales representative experiences when a product crashes again during a demo andthe deal is lost. Feeling the pain and empathizing with stakeholders will enable us to understand their needs better, demonstrate that we’re together in pursuit of a solution, and overall grow the sense of trust and partnership between you and the stakeholder.
4. Create Trust
Creating trust is not as simple as it may sound. It’s not just about saying “trust me,” but rather entails building a genuine relationship with the stakeholder. Relationships create the strongest trust, and when your relationship includes a personal bond in addition to a professional reliance, trust grows even more.
In addition, trust grows when you are honest. Stakeholders understand very quickly if you are playing around with them or actually telling them the truth. Hearing the truth from you, even if it isn’t always what they want to hear, makes them have trust in your honesty. Then, when you make a commitment to them, they will trust you will make it happen.
5. Avoid Opinions — Use Data
Let’s be honest, we product managers may think we are right most of the time, but we aren’t always. The way we can back our ideas and hypothesis is with data. You’re sure that this is the feature you need to work on? Prove it. Show the leak in the funnel, show how it increases the company revenues, decreases churn, whatever. It doesn’t matter what you are trying to prove or impact; if you back it with accurate data that supports your story, it will be much more convincing. Remember — be honest with the data. Abusing or bending it to prove a point will be harmful and make you lose credibility in the long run.
6. Learn to Say No Gracefully
There are hundreds of articles about this, so I’ll just share a few basic observations:
→ First of all, fully listen to the stakeholders and carefully consider
what they are saying before you shout out a NO. Stakeholders can have great ideas and are often on the front lines with customers so don’t disregard what could be a valid point.
→ Say no with facts and data. As mentioned in point 5 — nothing beats data. Use the data to explain why you think the stakeholder’s idea is smart but less important or has a lower priority than something else.
→ Say no by providing alternatives and sharing prioritization thoughts. Sharing the constraints you are facing or the priorities you have to set with the stakeholder makes it clearer why you need to say no. See more about this in point 8.
7. Plant the Seeds Early
You know that irritating stakeholder that always ruins your meeting? Yeah, that one that just popped up in your head. Think how annoying it is when that person asks questions that distract the meeting or comes in with a negative mindset. Well, you can try to prevent this by sitting with him before the actual meeting and reviewing the materials or the meeting’s agenda. Come with the attitude that his opinion is important and you wanted to get his feedback before sitting with the rest of the people. This creates a feeling for the stakeholders that they are important, that you want to hear their opinions and that they matter to you (they should be important to you and you should really listen to their opinions!). This also prevents any surprises during the meeting. I personally think that even if you need to sit with most or even all of the stakeholders one-on-one before an important meeting about a new process or the like — it can be really worthwhile, even if time consuming.
8. Involve Stakeholders in Prioritization and Tradeoff Decisions
“I wish Jane was a product manager for one day; she would never talk to me like that again.” If that thought comes to your mind often, I have an idea for you. The next time Jane says she needs something done ASAP, give her the opportunity to act as a product manager and help you prioritize. Show her the different features/goals/bugs you need to prioritize between. Explain the complexities of the different features, the impact of each and the effort needed to achieve the goals. Then let her help you decide the best way to prioritize in order to get the company to move the needle. From my personal experience, this approach gives stakeholders a lot of perspective, and many times their urgent issue becomes less urgent. Sometimes the opposite happens - we become more convinced that their request is indeed urgent because the stakeholder has a chance to better explain the impact and reason behind the request.
9. Give Your Stakeholders Visibility
“We never know what the product team is working on.” If that is a common phrase expressed in your organization, there is a problem. The basic tenet of agile is working quickly, but this is possible only by reflecting the situation to the relevant stakeholders. I will quote here Pael Heidema (from agileadvice.com):
“The Product Backlog is a constantly changing artifact, owned by the Product Owner. Stakeholders need real-time visibility into the current state of the Product. Stakeholders should be able to discuss the state of the Product Backlog with the Product Owner at any time, make recommendations and requests. Any change resulting from the request of any stakeholder(s) must be visible in real-time to all other stakeholders. One of the greatest benefits of a highly visible Product Backlog is that it becomes a conversational space for key stakeholders and many others that are connected to or interested in the work of the Scrum team.”
There are so many tools out there to make this happen (you can try Aha!, ProductBoard, ProdPad and more). Choose one, and really use it. Put up a board or screen that allows the stakeholders to really understand what is going on and make it visible to all.
10. Define a Process Which Involves Frequent Engagement with Your Stakeholders
One of the things we had to do as a team as our company grew from 30 to 160 people, was to build a process which involved our stakeholders as early as possible. For each stage of the process, we defined a goal, the stakeholders involved and the outcome of that stage. This process really helps us create and maintain clarity (as long as we keep to it 😉)
On a high level, the goals and deliverables of the process are as follows:
- Goal: Define the goal to be achieved or the project outlines. Get a clear understanding of the problem and steps needed to move forward. Define business and user needs.
- Deliverables: Business priorities & problem statement, who’s it for, KPIs, general timeline.
- Goal: Get the design and copy for the main pages right. Align the team on business and operational implications. Validate with internal and external stakeholders.
- Deliverables: High definition prototypes. An approved design to go forward and further validate with customers. A rollout plan. PRDs for initial features.
- Goal: Handoff perfect spec and design to R&D.
- Deliverables: Clear epics/stories in JIRA with mocks and flow charts (or however you pass on information to R&D in your organization).
Test and Review:
- Goal: Make sure all stakeholders are aligned with what is actually being released to customers.
- Deliverables: Demo to all relevant internal stakeholders and get feedback. Determine if there are any blockers. Approve the release.
- Goal: Train the relevant team members before going live. Have the feature go-live package-ready.
- Deliverables: Knowledgebase articles, support replies, training videos, email campaign (if applicable), etc.
🚀 Launch 🚀 Make sure you are launching to the correct set of customers if you are doing a traffic shaping or A/B testing.
You can of course play with the above process. We found it to be a good fit for us. What we need to remember is the importance of involving stakeholders as early as possible and of providing them transparency about what is going on.
Here’s to a new year of great trust and partnership between you and your stakeholders!
Thanks to Leora Horowitz for reviewing this for me!
Shout out to the Freightos product team who designed this process and taught me many of the things mentioned above.
Would love to hear your thoughts, comments, questions!