One of my basic beliefs is that virtually every job function in knowledge-based industries can be done effectively regardless of geographic location. Living in New York obviously does not magically make one a better stock analyst any more than San Francisco makes one a better software developer. “Clustering” effects and the legacy of pre-internet geographical concentration of knowledge-based industries are real, but their grip over the distribution of modern companies is demonstrably weakening every year. “Distributed” working is a fundamentally disruptive organizational technology that is going to eat – indeed, is eating – “the office.”
Most discussions of “remote” working* in tech have thus far centered on software engineering – mostly due to recruiting pressure. But that’s really just the beginning. The same reasons why recruiting “remote” contributors and managers is good for engineering teams apply equally to marketing, sales, operations and finance roles – as well as to Product Management.
I’ve held Product Management roles where I’ve lived and worked “remotely,” as have many or most members of my teams. Guess what? It works. In this blog, I’m going to talk a little about my experiences, what works and what doesn’t, as well as answer some FAQs I’ve fielded about what “remote product management” looks like.
* – I don’t like the connotation of this term, but given its broad adoption, I feel like fighting it is sort of futile. For what it’s worth, this thing on why “remote” is the wrong way to think about distributed working is my most-read post ever.
“How does it work?”
This is one of the most common questions I’ve ever gotten on product management in remote/distributed/non-colocated teams. Such a broad question is obviously a little tricky to answer. The main thing to know is that product management has been done remotely for a long, long time. There’s lots of wheel re-invention that goes on as each new company tries it, which most could really avoid.
Product management is essentially about the nitty-gritty details of execution and communication. Yeah, high-level vision and strategy play an important part too – but in my experience, those sexy-sounding bits tend to get way over-emphasized in a lot of the PM literature over the real grist of what the job entails. (PS – our book avoids that.) No one clicks on product management thinkpieces about post-sprint story point estimate reviews. Yet mundane-sounding stuff like sprint design, story writing, medium and long-range development planning with our engineering colleagues and marketing reviews are much of what the PM gig entails.
The irony is that, even in most co-located teams, many of these day-to-day tasks are done “remotely” anyway, via email, Slack/IM, JIRA and so forth. Many organizations use a set of team Google Docs or wikis to coordinate on tasks, roadmap dependencies, team-to-team contracts and the like. This is especially useful when coordinating on roadmap items between multiple overlapping teams, so that PMs and individual developers know which member of a counterpart team they need to reach out to or work with on a particular item.
A couple of best practices I’ve seen distributed/remote product teams use are:
- Public, regularly updated roadmap documents – monthly/quarterly and annual, with annotated status markers
- Public sprint plans, with each updated as the team progresses. (Yes, you can just look this up in JIRA or whatever, but this sprint plan is summarized and written in plain English)
- Daily check-ins. This can be a standup/standown sort of meeting, and may be accomplished just as easily on Slack/Yammer as on a call
- Over-communication. Due to the asynchronous nature of digital communication, it’s useful for participants to err on the side of over-communicating their work.
- Weekly summaries. This doesn’t need to be an essay. Just a couple of lines, like the oft-used PACI format (Priorities, Actions, Challenges, Info), is a really helpful email to send out to your immediate or adjacent teams so that they know what’s on your plate.
One of my constant maxims about successful product management is that PMs need to be clear, concise writers. On distributed teams, that skill becomes even more paramount.
Forming working relationships
One often-touted advantage of co-located teams is that it’s hard for colleagues to form solid working relationships if they can’t collaborate in person. I think this is plainly false, as any Call of Duty clan, EVE corporation or the entire basis of Fortnite demonstrates. Personally, I have found the old-fashioned telephone – either direct calls, teleconferences or Skype – perfectly serviceable as a means for synchronous communication. Lots of people default to Google Hangouts or Zoom for video chat. This does add a layer of nuance to communication that I find sometimes useful and sometimes not.
To be honest, I’ve just never had that big a problem with forming functional working relationships over distance. This might simply be a personality trait – I really don’t know. Some real obstacles I have encountered include language barriers and unresponsive or reluctant counterparts. Those are issues that any team, regardless of its physical proximity to one another, will struggle with.
Many of the working relationship practices I relied on as a product manager on a distributed team were the same ones I used on a co-located one, and to some extent reflect personal preferences of my own. For example, I try to avoid setting up tons of recurring meetings. Even if we decide to cancel them when the time comes, they take up valuable calendar space and can crowd out “focus time.” The only recurring meetings I find really necessary are my managerial 1:1, dedicated time with my engineering manager (usually weekly), and sync-ups with marketing and sales teams as needed (~monthly, depending).
One assumption about this kind of meeting cadence is that it sits above a layer of more or less constant, lower-fidelity internal communication like IM or Slack. (Eg. If you’re only hearing from your engineering manager once a week, then something is probably off.) And hey, if you have one-off questions or something that needs clarifying, a three-minute Skype conversation is very easy to do!
I think it’s healthy and useful for distributed teams to meet up in person every now and then. Once or twice a year is probably sufficient, and that’s been roughly the average cadence that many fully distributed companies have chosen, too. These events are great for the “big picture” strategizing stuff, especially if they’re set in an inspiring location.
Growing companies need to distribute
Parse.ly’s CTO, Andrew Montalenti, explained their company’s fully distributed model really well in this slide presentation from December (I included it back in my last email update). In an extremely stripped-down summary, what he shows is that every addition to a company’s headcount increases its communication overhead non-linearly. As a company grows, it becomes extremely difficult for everyone in the company to always be on the same page. By contrast, organizing in small teams permits constant forward motion. And a distributed working model is perfect for that.
There are lots of reasons to go distributed – it’s not just better for employees, but for teams and growing companies as a whole. And distributed teams doesn’t just mean hiring engineers! There is simply nothing about product management that makes it any less amenable to remote working than engineering or other functions. Like resistance to remote working itself, it really boils down to inherited work cultures.
Most companies still prefer to co-locate product management today, but I think this is just because most companies themselves are still co-located out of cultural inertia. This is going to change – indeed, is changing right now. The economic pressures of hiring in unaffordable metros is just one driver. The ability to hire talent regardless of zip code is a force multiplier in any business that relies on human capital. Get ready to see more of it.
Related posts:
[mc4wp_form id=”185″]
Blair Reeves 