While this can be advantageous for many disciplines that require “being in the zone,” or having long focused periods of uninterrupted work, it can feel limiting and isolating for the traditional product leader. Co-located product leaders and team members are used to seeking face-to-face feedback on ideas, working through fire-fights in a war-room, or hearing about new features and plans from any number of co-workers.
Product leadership (and mutual trust) is often earned via a mixed set of emotional intelligence parlayed by physical feedback in hallway encounters, high stakes meetings, and product roadmap debates and tradeoffs.
Putting digital communication tools such as email and slack (not to mention miles and timezone) between you and your team can feel alienating, lonely and chaotic.
Therefore it is imperative that as a product leader on a distributed team, you harness a variety of software tools, dedicated practices and a mindset tailored towards distributed team management to energize your coworkers and clearly communicate the company product direction and goals.
Taking communication to the next level.
Product managers need to have uncommonly good communication skills to be successful. However, even the best PMs will be constantly pushed to polish all their communications when working with a distributed team.
Empowering your emotional intelligence
Product managers who have developed a strong sense of emotional intelligence (EQ) in their work-life will find it difficult to read their colleagues opinions and positions as easily, or understand how important particular asks are from stakeholders without daily face-to-face time. Slack channels, much like emails, are great for instant or asynchronous, highly distributed communications — however they are terrible for simply communicating tone and emotions. Phone calls and Video chats get more to the point, but even then you are missing important physical indicators that help you see bring teams together and lead.
In order to make up for this deficiency it’s critical that product leaders make extra time and adopt new habits to bridge the digital divide between themselves, their coworkers and their product stakeholders. There are a few tips that I’ve found useful for this:
Don’t be shy: ask your colleagues questions, or for help, on slack, video or via phone — even if it’s just for confirmation of what you already know. This type of interaction happens so naturally in an office — in a hallway, after a meeting, over lunch — it’s easy to forget how important asking small, simple questions are to develop trust and relationships within the office. Asking people you work with for their outlook on specific issues shows them that you value their knowledge and viewpoint. It also opens up channels for ad-hoc feedback and creative thinking, maybe even leading to your next great idea.
Be extra-clear about your feelings, good, bad or otherwise. If you are a product leader, it’s often your ability to rally your team around an idea or mission that helps get people excited and focused. It’s hard to rally a remote, asynchronous team over slack (or email) — but it can be done! Trite as they may seem at times, emojis, ascii art, animated gifs and a solid use of punctuation (!) can help emphasize your thoughts. The critical point here is that written communication can often leave so much up to reader to interpret, or misinterpret, so that it is your job as a product leader to leave as little room for misunderstanding as possible by using all the tools at your disposal.
If all else fails, get in the same room. The reality is that you may need to get in the car, or hop on a plane when the going gets tough. Again, it falls to the Product Leader to make this choice and bag the miles. As Ken Norton often says, it’s your job to “bring the donuts,” and that means putting in the effort to get face to face time with your coworkers when it matters. You’ll find that doing so not only helps you get to that Aha! moment of alignment and understanding, but also triply builds up that bridge of trust. Like Ben Horowitz has said, it’s doing the hard work that leads to success, and there’s just no way around it.
Helpful Product Leader Practices
Much of distributed product leadership takes place asynchronously. As a product leader, your are often writing specs for others to read and provide feedback on, writing tickets for those products to be built and shipped, or asking questions about product features, timelines and scope. Your coworkers who are reading these documents and communications at different times, in different locations, even with different experiences and knowledge of language, can easily (and often do) interpret them all slightly differently. It’s your job to make sure you make your communications as clear and easy to understand as possible.
Use language and grammar wisely. Product Leaders will need to commit to clear, concise and comprehensible writing. It is critical that your team understand what you are saying, not be impressed with how you have said it. Ernest Hemingway said that you “should put down on paper what I see and what I feel in the best and simplest way.” Simple and pure. This is how you should think about communicating with your team. Use bullets and numbered lists to clearly communicate tasks and priorities. Don’t use 2 words when one will suffice. Do not embellish, add flowery language or use overly complex language when you can otherwise get the point across in a simpler, more understandable way. No one wants to read a product requirements docs that is 5 pages long and full of words that they have to look up to understand. That type of verbal vomit does not help teams understand the product goals, or ship products — it only causes your team to waste time.
Using Slack (or any digital team communications tools). Slack is simultaneously the best and worst friend for a distributed Product Leader. Having instant access to your team, to topical channels and a wealth of information is a blessing, but its achilles heel is that it leads to information overload and asynchronous communication mayhem. Private and unlisted channels often hold critical conversations and information. Channel dialog can run like a firehose, obscuring critical messages and files. Simplifying Slack usage by only using threads (with bolded titles) can help channels stay cleaner, and improve share-ability and search-ability of conversations. Working with your team to establish guidelines around open dialog (minimizing private channels and 1:1 messaging) can help keep critical information public. Periodically sweeping channels and removing them can help information stay visible in places that people are actually present and interactive.
Create a space for celebrating the small things. In a co-located environment this might be a wall where you tack up accomplishments (Launched new website on time! Reached revenue goals for Q2!). In a distributed team
Making a plan for e-mail. Everyone has found themselves looking that the list of names included on an email they’re about to send and wondered if they have all the right folks there. Over the year email groups and listservs have tried to help by automating some of this headache out of the process with some success. Unfortunately this often leads to a different frustrating issue — email inbox overload. Within a distributed team which primarily communicates with a tool such as Slack, you should consider limiting email to only those communications which have to involve an external partner. In this way, you quickly cordon off tools responsibilities. Now on email, you know that what you are getting likely involves someone outside of your company, and you’ve greatly reduced your inbox overload.
Define what it means to be “in the office.” Without seeing your coworkers sitting next to you, coming and going, distributed teams can start to operate like micro-offices — complete with time shifted schedules or practices that make it difficult for timely conversations and communications. It’s better to set an “in the office” expectation. You and your team mates can call, text, slack or email each other on important issues between 9am and 5pm (or whatever hour you choose) — and you shouldn’t be shy. If you have a burning question and you reach out via Slack, but don’t hear back, make a phone or video call. Set the expectations that just as in the office, when someone might be working in the seat across across from you, that you are available and in the office — ready to work or pick up the phone at a moments notice (meetings etc. aside). This enables teams to stop feeling guilty — like they are always interrupting — and get critical feedback and communications across when needed.
Sharing your product vision, roadmap and updates
Making sure your team understands and is in sync with the product vision and roadmap can be a difficult task in any organization. Your distributed team will need consistent, easy access to the roadmap, and a strong goal oriented company process
Plan product off-sites and meet ups. You’ll never get your company to live and breathe the vision if your product team isn’t on the same page. It’s highly valuable to do this in person. Quarterly product strategy and planning off-sites are extremely useful for hammering out roadmaps, debating strategies and hammering out your plans. Gib Biddle has a great overview of how you can run these meetings. Doing this in person enables you to quickly debate and challenge each other in a way that may not be possible online. Quarterly is a reasonable rate not requiring too much travel, too often from your team.
Share, consistently and openly. Once you have your plan, make sure the company is seeing it. Whether you do quarterly product kick off meetings, weekly sync-ups or slack channel updates with your team the most critical part is that you consistently establish a methodology for sharing these goals and plans. Set a cadence for them. Publish weekly, monthly or whatever works for your team, and when it’s out there notify them. If you are publishing ad-hoc, in the dark, it’s a guarantee that people are going to miss it.
Tie it into company goals so it’s easier to remember. Using Googles Objectives and Key Results (OKR) process or something similar (i.e. Intel’s MBOs etc.), getting your entire team on a system does wonders for alignment — especially in distributed teams. It is also helpful for publicly publishing those goals and their rollups, helping build clarity into the process.
It can be done.
It will take hard work to energize your coworkers and communicate your product direction and goals. You will need to develop a proficiency for working with the right tools, best practices and emotional intelligence that are the best fit for your distributed team. But if you take the time, put in the effort you will get there.
When you do you might just realize some of those wonderful, though sometimes elusive, benefits that are so touted in the work from home, distributed team era.