Is there a more controversial topic in business today than whether or not employees should be allowed to work away from the office?

Just throw the question out there for discussion. Pretty soon, everyone will be raising their voices—and not because they’re in different offices.

Staunch proponents of remote teams will tell you (often with a raised voice) that given today’s cloud-based communication and collaboration tools, you’d be a fool to cut yourself off from the majority of the world’s talent pool and limit your company only to those employees within driving distance of your office.

Tweet This:
“You miss out on most of the world’s talent pool by only hiring people within driving distance of your office.”

Opponents will shout back that it’s not possible to develop the chemistry and team cohesion a company needs to be successful if that “team” is just a bunch of faceless emails and disembodied phone voices scattered all over the world, communicating asynchronously at all hours of the day and night.

So who’s right? Indeed, is there really a right answer to the remote-team question?

Read From Product Manager to Product Leader ➜

We at ProductPlan admittedly come to the subject with a bias. We believe strongly that remote product teams can develop successful, game-changing products just as well as those teams whose members are all working under the same roof.

Our bias comes partly from seeing time and time again how effectively distributed product teams are able to use our web-based roadmap software to work together to advance a successful product strategy—even if those teams are comprised of people on several continents.

The rest of our bias comes from the fact that we ourselves operate a highly distributed cross-functional team.

How do we make it work? And how have so many users of ProductPlan made it work?

Based both on our research into remote teams and our firsthand experience as a distributed team ourselves, here are four suggestions for making your remote product team a success.

1. Hire the right people.

One important insight we’ve gleaned from interviewing product executives for our Product Lessons Learned series is that smart leaders know how to prioritize the skills and strengths in the product managers they hire based on the specific needs of their companies.

Some place a premium on curiosity when hiring a new product manager. Others have told us they value passion above all other traits. Still other product execs have said that when they’re interviewing product managers, they’re looking first and foremost for an entrepreneurial mindset.

But do you know what we haven’t heard as a key trait in a product manager—not from a single one of the product leaders we’ve interviewed? The ability to be at a specific desk, in a specific building, during a specific set of hours each day.

You already know this intuitively, but it’s worth underscoring here if you’re considering developing a remote product team, or if you’re already a part of one and want ideas for how to make it more successful. If you’ve hired the right people for the right roles, and those people are bringing the characteristics to the team that you value most—passion, problem-solving ability, empathy, etc.—where they work won’t really matter so much.

2. Start slow as you develop your remote product team.

In The 4-Hour Workweek, author Tim Ferriss offered a brilliant suggestion to a would-be remote worker who hadn’t yet gotten permission from her company to take her job out of the corporate offices and start working at home (or Starbucks).

Because shifting to a remote-work arrangement would represent such a dramatic change in culture for a company that didn’t already allow it, Ferriss suggested starting small—very small, perhaps asking for just one day a week to work remotely. (Maybe even a day every other week.)

Then, Ferriss suggested, on this day the remote worker should make darn sure she’s highly productive—delivering more than her typical day’s amount of work, all while being accessible at all times to the team back at the office.

Ferriss’s plan is obviously to offer a proof-of-concept—this remote-work thing actually works—before asking for more time away from the office. If you reverse-engineer Ferriss’s suggestion, you can use the same strategy to learn for yourself if it can work—and, if so, how to make it work—for your remote product team.

Just start with a small step or two in the remote-team direction. Maybe allow part of the team to work from offsite for a couple of days, then gradually build to a point where everyone who wants to can be working from anywhere, as long as productivity doesn’t suffer.

Here’s another way to dip your toe into the remote-team waters: For your next hire, try a contract-based team member who’s out of state (or in another country)—so you can learn whether you can fully bring a remote worker onto your team.

3. Make sure there are no gaps in productivity or support.

In their book Remote: Office Not Required, authors Jason Fried and David Hansson explain that the software firm they founded, 37signals, was a remote company from day one. Indeed, the co-founders launched the business with one partner in Chicago and the other in Copenhagen. Two people; two countries. You can’t get much more remote than that.

At the time of the book’s publication, 37signals had grown to several dozen employees spread all over the world. The authors pointed out that their flagship product—Basecamp—was by then serving millions of customers, including users in just about every country.

In this instance, having a remote team actually helped the company cover its service and support needs across all hours of the day. As long as they had staff somewhere in the world able to cover the Help Desk during business hours, they didn’t care where that support staff was located or what their hours were.

At the same time, as long as the Chicago side of the team that had to deal with their counterparts in Copenhagen was able to be accessible to those team members, did it really matter if they worked odd hours?

One of your tasks when operating a remote product team will be to make sure that the people who need support—whether members of your team or customers—can get it when they need it. Once you’ve worked that out, the specific hours that people work, and where they are while they’re working, shouldn’t be an issue.

Or, as the Remote co-authors succinctly put it: Thou Shalt Overlap.

4. Communicate, communicate, communicate.

One possible drawback of remote product teams, even ones that run extremely smoothly, is that individual team members can sometimes feel isolated, adrift on their own, cut off from all of the important stuff happening on the Mothership.

And if you run an entirely remote product team, at one point or another everyone might feel this way—because there is no Mothership.

The best way to address this, our experience has taught us, is by bringing the team together for regular communication—maybe even more often than you think is necessary.

This is what we do, and it truly does help keep the team cohesion, shared sense of purpose, and enthusiasm levels high.

Tweet This:
“Frequent communication among remote teams is key to maintaining team cohesion and shared sense of purpose.”

When everyone on your team is confined to the same office every day, and long-winded meetings eat into a great deal of a typical day’s productivity, your staff will understandably treat new meeting requests with suspicion, even dread.

But when those same team members are set free to work in the environment and at the times they feel the most productive energy and clarity, then jumping on a video call every few days to pow-wow with the rest of the team won’t feel like such a productivity-sapping inconvenience.

So, hold virtual meetings with your remote product team. Often. Have robust discussions about product strategy. Review the product roadmap. Pop open your project management tool to discuss daily progress. Cover whatever ground you think is worth reviewing as a team.

And then set them free again to do their work.


Do you have suggestions for remote product teams? Please share them in the comments section.