Collaborating Effectively With Remote Stakeholders: All You Need To Know As A Product Manager
It was a sunny afternoon here in İstanbul. I was about to go on a quick call with an old-time friend who also happens to be a product manager. Very few times, a short call of 15 minutes turns into a 60-minute conversation. But when that happens, it’s no less than magic. Especially in this case because the topic we coincidentally talked about was close to both of our hearts — product management.
My friend has been a product manager in one of the leading fashion eCommerce companies in Europe. While our call was just a regular check-in that we do once a month, our conversation went in the direction of how we were doing in our respective jobs. The conversation took an interesting turn when my friend talked about how his team tackled the challenges of collaborating with multiple remote stakeholders. This subject has always intrigued me since I have been working with a distributed team and most of the product managers I know personally in my network are.
Considering the crucial role of stakeholder collaboration in product management, I know remote stakeholder collaboration has its own challenges. Sharing our views and explaining them to someone is pretty easy when someone is right in front of us. But working remotely adds a layer of difficulty. How do you manage collaboration with remote stakeholders in such cases? Do you use different tools? What processes did you come up with to ease the collaboration? These were the questions that came to my mind straightaway when we started talking about this topic.
This article contains the usage of tools and processes that my friend and his team incorporated to effectively manage remote stakeholders. It’s a case study that will help product managers worldwide understand how to be close to their stakeholders even though they might not be physically close to them.
To understand remote collaboration with stakeholders, we first need to understand who “stakeholders” are. I wrote a detailed guide about how to identify the stakeholders and how to categorize them. The 3 main stakeholders that we will talk about in this article are as below,
Collaborating Remotely With Engineering & Design
Engineering and design are one of the main stakeholders of the product. Simply because they are the ones with whom product managers communicate every day. They are also the ones behind developing the functional product, thereby solving a customer’s pain point.
When my friend narrated the story of his company moving permanently to remote, he didn’t know that remote work would come up with its own set of challenges to collaborate with engineers and designers. Some challenges that his team faced are listed below.
Here are the solutions his team came up with to solve those challenges.
A) Separate Google chat channels (preferred communication tool) to facilitate better communication and engagement. The channels were as follows:
- Check-in: They didn’t know when team members were starting their work and ending it. This was easy when they were working from the office. So they created a channel where everyone would post “In” and “Out” whenever they checked in and checked out for work. This made it very easy for everyone to know the availability of team members.
- Kudos: When they used to work from the office, they had a kudos board. And the organizer used to read out all the kudos in the retros, but since they moved online, they realized they were taking a lot of time sharing their kudos for the work of the team members during the retro. This was mainly because they did not have a physical kudos board. So they changed this and created a “kudos “channel where everyone could add their kudos in advance, much like a physical “kudos” board. And during the retros, the organizer would just go through these kudos and narrate them the way they were written. This saved a lot of time in the retros and focused the team on discussing the main retro topics without missing out on an essential part of team building — thanking other team members.
- 4-eye review: They realized there were multiple long discussions in the grooming and estimation of JIRA tickets after they switched to remote work. This was because tickets were unclear, and the engineering and design teams had multiple doubts. Upon retrospect, they realized that while working from the office, it was easy for the engineering and design teams to get the initial questions clarified in person with the author of the ticket since everyone was sitting next to each other. But after moving to remote work, it became increasingly difficult to make these one-on-one conversations. As a result, tickets started coming to the grooming with incomplete information. To tackle this, they created a separate channel for ticket review where the tickets would be posted even before going to the grooming session. And only after getting two thumbs up from 2 different members other than the author would the ticket be taken in grooming. This is what they called “4-eye”. This tremendously improved the quality of the tickets since the author got the feedback early on. And the grooming sessions started becoming more productive.
- Fun: They realized that they didn’t have much fun since starting remote work. They weren’t cracking jokes with each other. In fact, all the conversations were related to work. So they created a separate channel for sharing everything related to fun. They shared memes, organized doodles, online get-togethers…etc. This helped them to connect with each other again.
B) Since teams were distributed, it was imperative to have robust documentation. Here’s what they did to have better documentation:
- They created the proper folders with the right names. Example: Product, Design, and Engineering would have their own folders. While there would be another folder, “Projects,” with all the documents related to a specific project or an initiative. Additionally, they had “Business” and “Customers” as folders for business and customer-related documentation. This helped the teams find the relevant documentation instantly. Also, new joiners were able to find information about the products, teams, and processes quickly and easily.
- Documentation requires collaboration. Hence, team members were notified in chats to read the document and share their feedback prior to meetings. This helped keep the meetings productive since most of the questions related to the topic were answered in the document. This also allowed the new joiners to understand critical decisions taken in the past and the reasons behind them.
Collaborating Remotely With Customers
Customers are one of the main stakeholders of the product. There is no doubt that product managers need to be actively communicating with customers. While working from the office, his team was sitting close to the customers (in this case, these were internal users). They all used to sit in the same building. And hence it was very easy for the entire tech team, including the engineering and the product team, to be in the close vicinity of customers.
This was affected big time since the whole team started working remotely. And because of this, they saw an increase in the number of messages related to non-urgent topics in the chat dedicated to urgent product issues, which resulted in critical topics being lost in the chat.
Here are the solutions his team came up with to solve this challenge.
A) Didicated Google chat channels for customers. The channels were:
- Urgent: For anything that requires urgent attention. This included cases where the tool stopped working or a bug was hampering the users from using the product.
- Non-urgent: For anything that wasn’t urgent. This included requests for new features or any query related to the product.
These two simple solutions helped them to communicate effectively with the customers.
Collaborating Remotely With Higher Management/Executives/Sales/Marketing
Higher management/executives/sales/marketing form the third pillar of product management stakeholders. These stakeholders are mainly interested in knowing the status of the projects.
While working remotely, it became increasingly critical to forming strong communication channels to keep these stakeholders educated about the project statuses. This quickly became a crucial problem to solve. This group of stakeholders had a very different problem listed below.
Here is the solutions his team came up with to create a rapid update culture.
A) Every week, the product manager should email a status update to relevant higher management/sales/marketing stakeholders related to projects. This email included the following:
- Feature name
- Feature description
- Owner
- Status
- If blocked, then why and what’s the path to green
This email helped to communicate the necessary details timely to the respective audience. This email was also shared on the internal company portal of the company for a wider audience.
These solutions not only helped the product manager to collaborate with the stakeholders effectively but also improved the NPS of the team, which was at an all-time low after they switched to remote work. It also drastically decreased the number of regular conversations in the “Urgent” channel, thereby helping the tech team to be more productive and focus on the critical deliverables. Overall, these measures improved the efficiency of not only the product manager but the engineering and design teams, which positively impacted the ways of working.
Remote work is here to stay. Post covid, a lot of companies have gone remote. Data shows that more companies will go remote in 2023. And considering the number of stakeholders a product manager manages, there will be new and exciting problems to tackle related to collaboration. Did your team experience problems while shifting remotely? What were these, and how did you solve them? Feel free to comment. These were such unique gems that needed to be written about.