The PM Journal | Log 11
How do you keep the relationship with internal stakeholders?
How do you maintain a good communication, transparency, and synchronization within other areas and teams in your company?
In product management the ability to manage a good relationship with stakeholders is mandatory. It should be a regular activity with everyone involved in the project/product.
It is normal in the rush of the day-to-day one forgets to keep the frequency of communication. But as product managers, we must avoid these scenarios and be as much as synched and transparent as possible.
We usually have different areas to keep in touch regarding a product or a specific project. Or we are implementing a feature or functionality that is cross-dependent with another team, and we need to align the work.
Below I shared a few etiquette points to have a better relationship and connection with internal stakeholders. Notice that these are my learnings from experiences, you might think differently or act differently. If so, let me know in the comments, I love to learn new ways 😄 I will write a future article about external stakeholders.
Etiquette of Internal Stakeholders Communication
1.Do not ever say “it is not my problem”. You are responsible for the company’s success as much as everyone else that receives a payslip.
How I manage: I like to be in contact with the teams around me. You never know what the future holds, and most importantly we should be helping each other. Share discovery findings that you have learned from their areas or that might interest them. Keep ongoing catchups with other PMs, see what they are up to. Help and ask for help, you are all on the same boat.
Tip: Talk with your colleagues to create a Product space or a channel somewhere to share articles, books, etc., and add info about each other’s teams, projects.
2. Alignment means a state of agreement or cooperation among persons, groups, nations, etc., with a common cause or viewpoint. Do I need to say more?
How I manage: I like to keep everyone involved in the loop of any new updates regarding a project or a product. Before starting the project, I perform a RAID (risk, assumption, issue, dependency) workshop with the groups involved to be on the same page, mitigate the unknowns, and be prepared. These people can be from other areas, or other teams, or high-level staff. During the ongoing work, I send them a status report containing the latest details of the implementation and/or changes in the strategy. Also, I invite these people to the sprint review so they get a sneak peek of what’s coming and give feedback/ask questions as needed.
Tip: Stakeholder Map is very useful when you have a variety of people involved in a project. It also helps you identify the ones that have more power to make decisions and more interest in the project.
3. Customer Success and Customer Service teams are your allies. They are in constant contact with different types of customers.
How I manage: I like to meet them when I start in a new position and talk about the area that my team works. I ask about their process with customers, what’s more relevant for me to know, and who’s responsible for whom. As well as, combine forces and get the user feedback they frequently collect to learn more about problems, needs, behaviors, and opportunities.
Tip: I receive weekly reports containing user feedback from C-SATs that the Customer Service created for us using Qualtrics with specific keywords related to my area.
4. Synchronization to mitigate dependencies. Working in similar areas with another team can be risky.
How I manage: I like to keep strategies synched. Be co-dependent or even fully dependent on others' work is very sensitive due to the parallel implementation that happens on both sides. There has to be a non-stop conversation to plan what needs to address next, otherwise things can get messy pretty fast and the blockers will start to appear.
Tip: If you are starting a new project that has to work with another team, sit together and strategize. If you learn about the dependency in the middle of the project, sit together and strategize. If you both work in the same product, sit together and strategize. There is no secret. Have a quarterly meeting to plan the work for the quarter and anticipate risks (remember the RAID I said earlier?). Then, weekly or biweekly catchup to keep synchronization and remediate blockers. Share discovery learnings, or even better plan it together. Btw, no need to have only one backlog please.
5.Development of an internal product. End-users in-house can drive you nuts, but also give you the opportunity to deliver the best value.
How I manage: I like to make clear that dates are an unknown territory, to begin with. We work with estimates. Validate hypothesis has never been so easy to iterate your product. Having the end-users so close to you provides the chance to recruit faster to conduct tests and interviews. Send a Slack message to the company’s main channel asking for people’s support, or to specific audience to participate. In-house you can observe often how they behave to the product leading you to a better understanding. Don’t be a stalker. Ask questions during a happy hour, or in the cafeteria. See and analyze the way the product has been used. But be careful, working with an internal product can also make you oblivious to problems and/or accommodate. Take a step back to evaluate your analysis as an outsider. As well as, you might find colleagues that are biased or will not be honest about the gaps in the product. Be sure you are giving them an open space to talk and be listen to.
Tip: Sometimes I act like a consultant in the firm, and go around talking to people about their experiences, needs, problems. I am also a user of my current product; every time I use it I analyze as an end-user not as product manager and think about what I would like to see there that would facilitate my actions. Another thing that you can do is show the product to your partner or family/friend and see them going through it.
6. Openness to be free to talk, be frank with each other. Build trust with internal stakeholders through honesty.
How I manage: I like to keep things clear and preserve transparency. You don’t need to tell them everything, that is not what being transparent means. Share with them points and views that will impact the decisions. Share problems that they might be able to help you resolve. As a product manager, you need to mitigate the viability risk by having the stakeholders' support. You can only have that if they trust you. You can have the autonomy to make the decisions if they trust you. They will hold you accountable either way trust or no trust. So, it is better to have openness between associates to acquire assistance.
Tip: Be confident and firm. Say ‘I believe’. Always have a backup plan. Use data for your arguments.
7. Stay accessible for internal stakeholder interactions. Yet everything has limit.
How I manage: I like to maintain all channels available to reach me out. And every time an internal stakeholder comes to talk to me, I make sure she/he is being listened to. I concentrate on the conversation, I am polite, gentle, and respectful, if I don’t have the answer at the time, I am sincere and ask for a moment to answer back while investigating. Don’t forget to have boundaries. You should not accept after work hours contact unless is an urgent matter that needs to be approached asap. People should respect your privacy, your time off, and your Slack status. Being a nice person does not mean that you have to be available 24/7.
Tip: I like to use the outlook plugin available in Slack. It updates my status instantly then people know when I am in a meeting so I might not reply immediately.
8. Everyone will have an idea for your product. Put them in the same place for the sake of your sanity. And I don’t mean roadmap.
How I manage: I like to have a discovery backlog where I add all items that come from learnings or from people. I order and prioritize them accordingly to the strategy. I have a board called ‘in discovery’, which contains all the hypotheses we are validating, researching, so on. And another board ‘under consideration’ with the next right things to do discovery. Then the backlog holds the ideas. It is critical to not make promises either give false expectations. Say that the idea will go to the discovery backlog to be prioritized and validated. Also, give your teammates the privilege of adding ideas to the backlog, after all they are owners of the product too.
Tip: I use Jira for the Discovery Backlog. But you can use Trello or Miro too. There is an interesting template in Miro called Idea Funnel Backlog that you can combine with the template 2x2 Prioritization Matrix.
9. Involve internal stakeholders in product creation. They have lots of knowledge to share and learn too.
How I manage: I like to connect internal stakeholders with external stakeholders (end-users) to create empathy and a sense of purpose. They won’t be participating in interviews or tests unless they would be up to go and take notes (which I have never seen this happened — yet). But participate in workshops to feel engaged in the creation. It is important that they see qualitative and quantitative data combined… analytics, recordings, read feedback, to increase the visibility of how people are interacting with their product.
Tip: Invite key people to participate in the Discovery Design Sprint with the team. Perform workshops with them to distress the problem, create personas, affinity diagram. Select pieces of a user interview/test recordings and show them with a metric report related to the opportunity in the feedback.
10.Ahh deadlines… The famous “is there a release date established for this?”
How I manage: I like to prioritize the work in a way that, when there is a deadline, my thinking is about the minimum necessary to deliver that will be valuable, usable, and functional to release in time. Commonly with a deadline there is a goal to accomplish, client’s launch, sales position, time to market, etc. Then it is interesting to negotiate your plan and set expectations to achieve the desired date. Especially if they had requested an entire feature/functionality, get an agreement helping them understand the implementation is a combination of what’s feasible, viable, usable, and valuable to get done on time.
Tip: Split the backlog items in very small valuable user stories. Prioritize them with a technique that you use (stay tuned my next article will be about prioritization) and order the backlog following that priority. Then refine with the team and get the items estimated. It will give you a sense based on the team’s velocity how many items per sprint might be possible to complete. Important to highlight that along the way lots of variants may happen which can influence the implementation. It is an estimative plan.
These suggestions in how you can improve communication with internal stakeholders will help you to create a friendly environment and relationship, also reduce risks and problems. Remember, people before process 🥰
(Please notice that I’m not native in English and I apologize for mistakes)
