11 time-tested processes to manage remote product teams

I began working remotely for the first time about 2 years ago.

I was previously managing a product team developing software solutions for external clients, and I felt like I spent most of my day trying to overcome problems.

Given how difficult it was managing a team in a physical office where we could all talk face to face, I was a little worried about my new adventure in remote work.

Fortunately for me, I was about to start with Process Street, whose raison d’etre is to help companies improve their internal organization in line with business process management philosophies.

So, I was entering into a very self-critical company striving to learn about its own processes so that it could better provide process assistance to its users.

This was great for me.

Over time, I began to see why things had struggled in my previous role and what mistakes I’d made in the past. I had the opportunity to see how central communication and documentation is to any business and why sometimes remote companies end up being better organized than fixed ones.

Today, I’ll look at a couple of key topics:

How taking a remote mindset spotlights mistakes
The benefits of asynchronous communication
11 free process templates, and how we use them

Let’s dig in.

The challenges of working remotely

When you have a set physical space which you all share, it can be easy to take certain things for granted. If I need to know how customer success undertakes calls with users, then I’ll just get up and walk over to Blake’s desk and ask him a few questions.

The thing is—this isn’t always the best way to operate.

I’m distracting myself from my work. I’m distracting Blake away from his work. And what if Blake isn’t there? How do I find the answer now?

When you’re working remotely, it’s much harder to do these things, so you create documented systems and processes to streamline and make things easier.

At Process Street, if I want to see how Blake manages a user call, I’ll open up the process he uses within Process Street for that call, and I can analyze each step—I can take a nice deep gulp of our own champagne. I can then look at the previous times he’s followed that process and begin to understand how it works in practice and what kind of feedback users give.

I can walk away from this investigation with a good knowledge of how he operates without distracting myself or him. If I have follow up questions, I can formulate them in an informed way and he can answer when he’s good to respond.

Working remotely presents challenges, but those challenges are simply spotlights on process failures or poorly functioning systems. They are opportunities to improve areas of your business which you may not have realized you needed to improve.

Asynchronous communication is important to keep teams moving

I can’t always contact everyone in the company. Time zones are a thing.

But people shouldn’t always need to be physically together to get things done. And even if you are all in the same building, people are often in meetings or off visiting clients.

The point is, people aren’t always available right at that moment you want them.

For this reason, asynchronous communication is vital in remote teams and often underappreciated in non-remote teams too.

Synchronous communication is your typical back and forth where you talk ‘live’ with someone. It could be a real life conversation, a video chat, or an instant message discussion. It’s convenient—and in the age of Slack—increasingly common at work to figure simple issues or update people.

Asynchronous communication, on the other hand, is managing communication where someone might not be able to reply immediately.

It could involve shooting out a detailed email for people to respond to whenever they have time. It could be uploading a video in a Slack channel of a screen-recording of you describing a task you want other people to do. It could be moving a Trello card into a different column to let other people know you’ve completed that part of a task.

I like to imagine documented processes as a form of asynchronous communication, too. They show other people what you do, how you do it, and what the results are when you do it.

With software like Process Street, you could dip into someone else's process and watch them completing it in real time. This communicates their progress to you without them having to ‘click send’ or some other action which acknowledges the process of communicating occurring.

In this sense, using Process Street, Trello, Jira—or whichever task, process, or project management software you like to use—allows you to communicate with your team without thinking.

This is a kind of automated asynchronous communication process.

When working remotely, you realize very quickly that you need these kinds of systems in place to avoid the pitfalls of not being able to contact one-another.

At Process Street, we have a rule: All communication must be asynchronous communication.

Even meetings done over video or voice call—an inherently synchronous mode of communication—are recorded so that others would be able to gain value or use for reference. We’re currently trying to improve our systems for managing this, but I think it’s the most extreme example of trying to make everything function asynchronously.

The easiest example, however, would be the insistence of using public Slack channels rather than direct messages to communicate with other people. That way, other members of the team can review the conversation and add to it—or learn from it—later.

If you message our CEO something along the lines of “Hey Vinay” because you see he’s online in Slack, he will send you our article on asynchronous communication instead of a handy reply.

An image of a laptop and monitor that says, "work hard anywhere"

How Process Street manages a remote product team

As an inherently process-oriented company, we have a general rule: Make a process for any task you have to do more than twice.

This philosophy bleeds into our operations as a result of this outlook. Process Street is specifically designed to handle recurring processes and does so through a checklist-based system where a process template is run as a checklist every time a process needs to be followed.

Simple.

Over time, we’ve added features on the basis of what customers have requested and on the basis of what we’ve found we need internally. This includes things like task assignments and due dates and carries on to stop tasks and conditional logic.

People need to know what they’re meant to do, when they’re meant to do it, and what tasks will be required next. These things are extra important when in a remote team.

Processes ensure consistency and quality if used correctly but work best when they can be collaborative and tie together team actions.

Below, I’ll lay out 3 key areas where our product team utilizes agile processes to keep everyone on track.

How we run agile organization on the team

Our product team operates, as many teams do, with a system largely built around a Scrum methodology.

We have sprints, standups, and retrospectives.

Anyone who has worked in a Scrum team knows the importance of keeping these meetings brief, effective, recorded, and acted upon.

A lot of time can be wasted when meetings go off track. A lot of meetings can be wasted by people not remembering what was decided. A lot of decisions can be wasted by people not acting upon them.

Organizational problems often arise in these simple moments. People not doing the little things well results in the big things going wrong. I’ve covered this in more detail before in posts about normalization of deviance within organizations.

As the academic Diane Vaughan noted:

“Social normalization of deviance means that people within the organization become so much accustomed to a deviant behavior that they don’t consider it as deviant…”

It’s not just that small mistakes lead to big mistakes, but that the acceptance of small mistakes results in big ones.

That’s why we follow the following processes in our team organization:

A portion of Process Street's daily standup meeting checklist

How we keep quality assurance high

Quality assurance is a fairly typical use case for process management applied to product teams.

You need to maintain consistency and work through a series of steps to approve or reject whatever has been submitted.

At Process Street we’ve connected a number of our processes together. You’ll see, if you click on the daily standup meeting checklist linked above, that there’s a section for making sure all pull requests are accounted for.

This becomes a very easy thing to check as linked below is the checklist for pull request procedures. You can use one checklist to review the performance of team members within other checklists.

Our quality assurance processes include:

How we effectively train remote staff via processes

A further key use case for process management is in recruitment and onboarding. These are areas where you want to make sure a new hire has been shown all the important things they should be shown.

This is especially true of a product team—you’re putting the company’s baby in their hands.

If I make a spelling mistake in an article, no one is really going to care too much. But one bad line of code can disrupt your users’ experience of the product at what could be a crucial moment for them.

These are some of the internal processes we use to make sure people know what they’re doing and don’t mess everything up:

Use processes to both communicate and follow recurring tasks

We made these 11 processes public precisely because these were tasks which appeared to have high error margins. There are a host of other processes we use in-house, but these—when optimized over time—really helped to ensure quality and consistency of approach.

The key for our product team is to have all documentation and information available for devs to find whenever they need it. They can follow the processes when they undertake the task and know that they’re doing things properly.

Crucially, by interacting with the processes regularly, the product team can then design the processes—pointing out weaknesses and recommending changes to improve it.

If everyone is clear on how tasks are meant to be done, then we can work together to improve those standard procedures and improve everyone’s output in turn.

It isn’t just that remote teams need great systems and processes, but that working remotely shows you where you lacked systems and processes before.

Remote work shines a spotlight on process deficiencies. If you don’t believe me, why not try it for yourself. Enforce remote forms of communication and discover how reliant you might have been previously on interrupting each other!

Give it a try for a week and come back to me. Less distractions, better documentation, more independence. What’s not to like?

How do you manage your remote product team? When do you use processes and when do you use other approaches? Let us know on Twitter by mentioning @Appcues.