Normally the question I focus on in my work and in my writing is “How can we leverage the best practices of the very best companies in order to give ourselves the very best chance for continuous innovation?”

While there are many practices that are important and contribute to this, I have long been a champion of the power of the co-located product team.

This Jeff Bezos quote sums up my experiences quite well:

“At Amazon, a product team has a clear mission, specific goals, and needs to be cross-functional, dedicated, and co-located. Why? Creativity comes from people’s interactions; inspiration comes from intensive concentration. Just like a start-up, the team huddles together in a garage, experimenting, iterating, discussing, debating, trying and retrying, again and again.”

I don’t think it’s an accident that Amazon is the most consistently innovative company in our industry.

All that said, for many companies, today the question has changed.

Now I’m being asked, “How can we leverage best practices to give ourselves the best chance at innovation, in the scenario where the product team is distributed and each person is working remotely?”

Addressing this important question is the subject of this article.

There’s no need to discuss the well-understood tools and methods that distributed teams have adopted to communicate and manage their work. I will assume you are already familiar with the range of cloud-based collaboration tools, and video-based communication services.

Instead, we’ll dive deeper into the nature of cross-functional product teams, and discuss where you should focus your attention to continue to make forward progress as a team.

First, there are really the two major types of activities in every empowered product team: discovery and delivery.

When people talk about the magic of co-location, they are mainly talking about innovation and discovery, as in the Amazon quote above.

In delivery, it’s more of a trade-off. Communication is of course easier when sitting together, but so are unwanted interruptions. Overall, I find teams with remote employees can do quite well in delivery, occasionally even better than when the team is co-located.

The real challenge of remote employees is when we consider the discovery work.

The overall methods and mechanics are not really very different when working remotely versus co-located for discovery work.

I’ll discuss more of the impact on discovery techniques in a future article, but for now, we still have many product ideas, and we still try them out quickly, usually by creating a prototype, and then testing on real users either qualitatively or quantitatively.

Obviously our qualitative testing is not likely to be literally face-to-face, but we can and should make up for that with increased video-based testing, which of course is better than ever.

The important differences impact the dynamics of how the product manager, product designer and tech lead collaborate to discover a solution worth building.

There are three serious problems that I consistently see, and any of these three can meaningfully damage your ability to innovate.

Artifacts

As soon as you separate the product manager from the product designer from the tech lead, a very common anti-pattern arises.

Instead of the three sitting down together to discuss the question “how do we solve this problem?” there is a nearly gravity-like pull to start producing artifacts for each other.

The product designer asks the product manager to write down some type of “brief” or requirements or constraints.

The tech lead asks the designer when she can provide some wireframes so the engineers can start planning.

The product manager asks the engineers for estimates.

Very soon, the new remote work process has reverted back to waterfall-like passing along of artifacts, and not only will innovation suffer, but the entire discussion will quickly move back to output, rather than outcome.

This is a tendency that you have to continuously fight. It may feel less efficient to discuss these topics in a video-call between the three of you, but it’s essential that you return to the “how do we solve this problem?” discussion.

During discovery, the main artifact should be prototypes.

Now, it’s true that once you do decide to build something in delivery, the engineers that are now remote will likely not be as up to date on the latest prototype, so you will need to spend some time describing in sufficient detail what the engineers need to build and QA test. But that’s only after you believe you have a solution that is valuable, usable, feasible and viable.

Trust

Discovery in general and innovation in particular depends on this concept of psychological safety – which essentially means that the members of your product team feel respected and their contributions are welcome and valued.

I’ve written earlier about how even one asshole on the product team can destroy this dynamic. Fortunately, most people are not assholes, at least not in person. Unfortunately, it’s no secret that when people are separated from one another, and you’re not speaking directly to someone’s face, the normal filters and sensitivity can fade.

More than a few people have shared with me that they are seeing a different side of their colleagues, and it’s not always a good look.

This is where coaching is so essential. In my experience, most people don’t intend to be cruel or insensitive, they just don’t have as many of the social cues to go on. A good manager can coach the employee on their online interactions with the rest of the team, and help them realize where they can improve.

Also, it may seem like it would be more efficient to send an email or slack message, but if a poorly phrased message breaks the trust and requires hours of damage control, it maybe wasn’t so efficient after all.

When working remotely, it’s always better to handle anything that might be interpreted as sensitive over video. It’s not as good as in-person, but it’s still much better for including the facial expressions, tone of voice, and body language that are so important to developing and maintaining trust.

Time

For some people, they have a work from home environment that is largely insulated from interruptions, and they find themselves feeling more productive than ever, especially when it comes to quality time to think through hard problems.

However, for many others, especially those that have found themselves suddenly forced to deal with child care or homeschooling obligations, they yearn for the ease of going into the office where they could escape the burdens of home life, and get work done again.

The reality is that not all members of your product team will likely have the same amount of quality time to meaningfully contribute. Getting even an hour a day of uninterrupted time might be very difficult.

My main suggestion here is to try to be flexible. Let’s suppose your product designer has young children, and can only manage a solid hour of uninterrupted time at an early or late hour. If the product manager and tech lead can find a way to accommodate that, it’s worth doing.

I realize that none of these three items – artifacts, trust, or time – are easy challenges to deal with. They’re not.

But if you find your team no longer delivering the results you once did, I would not be surprised if it was due to one or more of these three problems.

With the members of the product team being aware of the potential for these problems, and with the managers providing coaching on avoiding or dealing with these problems, you can manage to do good product discovery work in a remote employee environment.