How To Manage Communication as a Distributed Product Manager

With more companies embracing distributed and remote work teams, the communication challenge takes on a completely different form — product managers aren't only expected to be able to communicate excellently, but be able to pass across a message to people with different levels of understanding of the subject matter, in different locations, in varying formats.

Take a quick look at any list of required skills for a product manager, and there’s absolutely no doubt that any PM worth their salt must not only be a rockstar at communicating, but also be able to do it in a systematic (repeatable, predictable) manner. We can go into the many reasons why communication is vital, but we’ll instead focus on the added requirements of communicating in a remote or distributed team.

There is no hard and fast rule, but there are some principles that stay true and consistent — distributed or not.

1. Show up prepared

This should go without saying, but with the rise and rise of crazy-busy product managers, it’s almost easy to go through life winging it. More often than not, the PM is expected to be the most knowledgeable person in the room — and as first impressions go, if you cannot provide a knowledgeable answer to a question, the likelihood that everything else you say after that will be taken seriously reduces significantly.

This is even more important in a distributed team because of the associated implicit barrier to access, and with it, a reduced audience attention span. You want to reduce the work required to pass across a vital piece of information by being certain of what you’re talking about upfront. It's unlikely that you'll have informed responses to a question if you are not prepared beforehand.

Read that email, scan through that Product Requirements Document, do a quick search about your customer’s business. Preparedness helps you grab and hold attention, thereby making for more impactful messaging.

2. Routine

This is simply having a regular, predictable and reusable schedule about most things and keeping an almost strict pattern of getting things done.

While most teams generally benefit from synchronous communication and schedules, in distributed teams, it becomes more important to have a strict regiment because you want your team or stakeholders to be able to plan with and around your schedule — regardless of timezone barriers.

Distributed teams thrive on structure, and having a routine helps to manage expectations of your stakeholders — internal or external. A routine not only reduces the burden on your stakeholders to always try to figure out things on their own, but it also helps you become a master at planning your own work.

Define a working pattern for team meetings, for product updates, for pairing sessions, for debriefs, and then have everyone be sufficiently aware of this pattern. But most importantly, do your best to stick to that routine.

3. Verbosity over TL;DR

Verbosity literally means having a lot of words. But in this context, it connotes using as many words as it takes for your audience to understand the message you are communicating.

Speaking to a person who is right in front of you is already difficult in itself when you don’t have the right words, but having to communicate remotely with a person in a different location requires that you do not leave any room for ambiguity. Ambiguity births confusion, confusion births rework, rework births scope creep or misaligned expectations, which in turn births failure.

But there’s a caveat here, which is to know your audience — concise is not always equal to short. As much as possible, always opt for clarity over anything else.

This is a game of balance — if the answer to the question “will this provide everything the recipient needs to be sufficiently informed about the subject matter” is no, then you should take a second look. Repeat as often as it takes to achieve that clarity.

4. Share Early; Share Often

Most successful projects rely on effective collaboration, and this is predicated on getting the right amount of information shared with collaborators early enough, and as often as things change.

Again, because there is already a barrier to access when you are not physically co-located, the goal as a distributed PM is to reduce the time and effort it takes to build consensus.

The more people know, the easier it becomes to build consensus. It may be uncomfortable — actually, it is uncomfortable to share when you don’t have all the answers, but the fact that people will feel valued when they are kept in the know trumps most feelings of discomfort. It helps to use the 5% -30%-90% feedback methodology here.

There may be an increasing level of comfort with distributed and remote work across many industries, and communication remains the cornerstone in being successful as a product manager. A product manager may be great at their job while they are co-located with their engineers and other stakeholders, but there are additional nuances required to achieve the same level of success in a distributed team; effective communication is one of the most important.