Ever since the shift towards agile practices, product teams have hung on to a set of core attributes, which range from cross-functional, to customer-centric, all the way up to iterative and independent. But there’s one aspect which should vanish from this list of must-haves: co-located.
In this first of two posts, I look at how you might approach remote product management, while my next post will examine some of the tools that you can take into your everyday working to help make remote product management a success.
Setting up for Success
The notion that successful product teams strictly need to operate from within one room is outdated. There’s been a shift in technology – and more importantly a change of mindset among employees – which has laid the groundwork so that a remote-first approach to setting up and operating product teams is equally effective.
Most people like to debate that the same teams would still “perform better” in a co-located environment over a distributed one. But that’s not the point. The point is that we should be broadening our perspective beyond the traditional status quo and challenging our assumptions about collaboration and how people actually want to work.
For product managers, this means needing to rethink existing processes beyond the simple introduction of tools like Slack. The biggest mistake I see people make is to put every team member into a different location and continue with the status quo.
In one product team that I was part of, we made this exact mistake. When two of our team members moved to remote locations, we kept our physical Scrum wall, the in-person daily standups, and the retrospectives in one meeting room. We then tried to circumvent their absence by sharing blurry panorama photos of the wall in a Slack channel and simply “dialed them in” for other meetings (only to complain about the bad sound quality of our speakers). Needless to say, these practices came to an end rather quickly because of their exclusionary nature.
While remote team setups are a great way to break free of existing paradigms and restrictions, they can also amplify existing weaknesses.
This is why I recommend that you think through the following three pillars of successful remote product teams.
But before we go through them, there are two fundamental aspects of remote work which should be understood:
- Communication can either be synchronous or asynchronous. The more emotional a topic is, the more synchronous the channel delivering it needs to be.
- Home office is not remote work. By removing only one or two people from a co-located setup, you will probably only make them feel excluded as everybody in the office continues to “do their thing”. Successful remote collaboration requires the same “handicap” for every team member.
These three pillars aim to give you a head start for managing a successful remote product team. They’re by no means a step-by-step catalog to follow religiously.
Instead, use them as inspiration for creating your own remote product team culture.
While implicit assumptions are dangerous for co-located product teams, they’re deadly for remote teams. Reduced exposure to emotions (like gestures and facial recognition) means it can be easy to mistake an ironic phrase in Slack for an insult. This is why remote product teams need to have a charter of principles which goes beyond “be kind”.
You need to think of all the ways that behavior could be misunderstood when you lack physical context. What about the religious use of status updates to indicate availability, a clear communication hierarchy (e.g. “text me on WhatsApp for urgent things when I’m not responding”) or simply a shared understanding about information shared in channels. Is it agreed, for example, that everybody checks the #customerfeedback and #knowhow channels once per day?
While tools can’t solve critical problems by themselves, the right ones, paired with a good set of principles (see above), can help you from running into some.
Enabling smooth communication and collaboration across various locations (and mostly even time zones) requires the right tools. At the same time, you want to avoid falling for shiny objects (like the new Top Picks on Product Hunt) when it comes to expanding your toolchain.
So, I recommend picking a set of core tools for key needs. Some examples are:
- Written Communication – Slack
- Video Communication – Zoom
- Issue Management – JIRA
- Document Collaboration – GSuite
From there, the key criterion for adding new tools to this mix is how well they integrate with your core tools. You should look for the best solution within your toolchain and not the one which looks best standalone.
Even though pretty much every topic can be tackled by a remote team, remote working certainly isn’t for every personality type. While at first it sounds as if nothing changes except the location of the individual, pretty much everything does.
And it’s important for existing team members, as well as new ones you’re looking to bring in, to understand the requirements that remote work demands of them.
For example, a certain set of hard skills becomes more important beyond the “typical” criteria for a domain of expertise.
- Excellent writing skills
- Confident and efficient work with synchronous and asynchronous communication tools
But there’s also a different set of soft skills you want people to bring into a remote team:
While none of the above skills are exclusive traits for members of remote teams, their importance is raised significantly when it comes to assembling team members in a distributed setup.
And while this article has hopefully got you thinking about how to approach remote working in your team in general, you may wonder how to exactly translate this into your daily business. Well, this is exactly what the second part of this short series on remote product management will tackle. In it I will discuss how to conduct remote user research, how to organize your (Sprint) routines in a remote team, and how to run remote workshops across multiple locations.
The post How do you Make Product Management Work Effectively in a Distributed Team? appeared first on Mind the Product.