When you work with remote product teams, you want to have a shared understanding about the problem you’re trying to solve and what your solution is supposed to look like. You want to be able to effectively collaborate with everyone on the team to make sure everyone keeps heading in the right direction and makes decisions that are aligned.
Many people would claim that the best way to do that is to have the team collocated.
At the same time, you want to make sure you have people with the right skills to solve the problem, and you’d like to have the most skilled people you can get. Those people aren’t always located in the same place, so there can be value to not having everyone in the same place.
Then there are always the times when you don’t have a choice but to work remote like we’re currently living through. My guess is that once social distancing is no longer required there is going to be a shift to more remote working, even by product teams that normally would work quite closely together.
With that in mind, I thought I would take an in depth look at how product teams can work in a remote fashion even when they have a choice not to.
Let’s start off with some key underlying principles that can lead to remote success. These are behaviors and attitudes that you want to strive for when you have a remote product team.
All are remote, or none are remote
If you’ve ever been the sole person who has called into a meeting when everyone else is in the same room together, you’ll probably understand this. The people sitting in the room together will often forget that there is someone on the phone, they’ll talk over the remote person, they’ll talk in a manner that the remote person can’t hear.
The people in the room aren’t trying to exclude the remote person on purpose, at least most of the time. It’s just real easy to slip into an out of site out of mind mode of working.
And that’s just when you’re talking about explicit meetings. There’s also all the spontaneous side conversations that can happen during the course of the day that never seem to make their way back to the remote person.
The working agreements I talk about later can help here, but only to a point. You’re really relying on everyone on the team to take extra effort to keep the remote person in the loop and vice versa. It can be done, but it does place an additional burden on everyone.
If you find you’re going to have more than a couple of remote people for an extended time, it’s almost easier to keep everyone in touch if you are all remote.
When the entire team is remote, you have no choice but to use tools (ie Slack) that enable virtual communications. You tend to remember the other remote people because you’re all in the same boat (if not the same place).
Start together to succeed apart
When your team knows you are going to spend most of your time working apart it can be very helpful to start off working together for a short time and to follow that up with periodic occasions where you gather back together.
You want to start together and have these periodic gatherings to build shared understanding, and perhaps more importantly to remind each other that you work with a group of other people. Other people with rich backgrounds and experiences and interests outside of work.
When you have the option, I’ve found that a great way to get started with a new product team is to do some or all of your discovery sessions face to face, especially the sessions where you want to build a shared understanding around outcomes.
Use the rich communication channel of face to face discussion to work through the uncertainty that comes with starting a new effort. Make sure that you take some time to interact in a setting where you can learn more about each other outside of work. That understanding about each other as people will only help your collaboration when you’re working apart.
I think the reason my current product team is so effective working remotely is because we started out working collocated and made an explicit effort to understand each other as people. We tend to celebrate people’s personal wins outside of work as much, if not more, than our wins on the product.
If you’re in a situation where you can’t start working face to face, don’t let that stop you from getting started. There’s still some value in getting together in the midst of the project. You may just need to be a bit more intentional about having some non work related conversations while you work remote and have some explicit discussions about working together.
I used to work with a team for a non profit that was completely remote. We formed over time as additional people gradually started working with the team. Although we didn’t kick off our efforts face to face, we did look for opportunities in the midst of our work to get together.
The chance to periodically spend some time face to face, some of it working, some of it just being people around each other by going out for dinner really helped to improve our collaboration when we worked remote.
You realize that everybody on your team has a life outside of what you’re doing on the project. You get to get a better understanding of how they operate either due to cultural influences or just due to everyone’s different personalities.
It also helps to reinforce trust.
Trust your product team
One of the most commonly cited arguments for not working remotely is that it is more difficult to keep tabs on everyone on your team to make sure they’re working.
It is true that when everyone on a team is spread out it can be more difficult to know whether they are working. And it completely misses the point.
Instead of coming up with all kinds of convoluted mechanisms to monitor your team you need to instill the most powerful remote work policy: We trust you.
Establish a shared understanding of the outcome you seek.
Provide sufficient guardrails for them to make decisions.Provide the team an environment in which they can be successful.
And trust that your team will do what needs to get done in order to make that outcome happen. Instead of worrying that your team won’t do anything, you may just find that you have to throttle them back and little bit and remind them to step away from work to stay refreshed. (I write that mostly to admonish myself more than anything).
Unfortunately not everyone in your organization will follow that philosophy. Especially if your organization is new to remote work.
You may have people ask you to keep your video camera on all day. You may see additional meetings pop up on your calendar to “check in” and see how things are going. At the very least you’ll have people trying to have all the meetings that would have happened if you were all in the office.
Don’t do any of these things. Instead, listen to this episode of the Rework podcast where Jason Fried and David Heinemeier Hansson of Basecamp answer questions about remote work. Their view is that remote work is not like working in an office, nor should it be.
If you act like you don’t trust your team you will end up with a team that you truly can’t trust.
Take this opportunity to change some of the behaviors you see teams practice in offices that might get in the way of being as effective as they can.
Don’t recreate bad in person working practices
I’ve had the opportunity to work remotely and be colocated with a team and have experienced the benefits and disadvantages of both modes of working. My piece of advice when comparing the two modes – don’t try to replicate what you do in an office setting when working remote. Namely, don’t replace all of those in person meetings with video conferences.
Use this opportunity to take a long hard look at those meetings and decide which ones are actually relevant and useful.
If they aren’t useful, or the purpose of the meeting can be accomplished through other means, try those other means out.
How to successfully work remote
Establish shared understanding of your outcome
I mentioned above that you need to trust that your team will make the right decisions that will keep you progressing toward your desired outcome. To make sure they are successful with that, you need to make sure that they understand the outcome.
And I mean really understand it. To the point where everyone can pretty much describe the outcome in roughly the same way.
You want everyone to understand the problem you’re trying to solve and why. This is why it can be helpful to do some or all of your discovery sessions in person.
I like to use a couple of different techniques to guide the conversations about outcomes – the problem statement and the opportunity assessment. I generally do use these techniques for face to face discussions during discovery sessions, but you can make some slight modifications to do them remotely.
You have these conversations so that you can give everyone a chance to verbalize their current understanding of the desired outcome, then have a structured conversation to come up with what the outcome should really be.
Including people in a discussion about the outcome is more powerful than asking them to read about the outcome.
If your team members are involved in a discussion about the outcome, they can think about it in terms meaningful to them, then can gain clarity, and they have a better guide to decisions they need to make on a day to day basis.
When you work remote, it’s helpful to have clarity around who is going to do what. This is important for the entire product team, but it’s especially important if there’s more than one product person involved with your product.
In those cases you need to decide if you should have more than one product person, and if you do, who is focusing on the needs of the market and your customers, who is going to make priority decisions and who is going to do the work to understand business processes, rules and data.
There’s four different models for structuring the product people in your organization:
- A single product person
- A product manager and a product owner
- A product manager and a business analyst
- A product manager, product owner, and business analyst.
There’s not necessarily one best approach to structuring your product team. It really depends on your particular context.
Take a look at the models, determine which situation you’re in, and which seems to be the best fit (they may not be the same one) and then consider who you’d expect to do what based on the model you select.
This also means that you come to an agreement on who is going to make what decisions. It’s helpful to have clarity on that regardless if you’re working remotely or not, but it’s especially important when you work remote. When you know who is going to make decisions ahead of time, that will prevent the discussions about who should decide when a decision comes up. It also prevents people from stepping on each other’s toes.
My current product team is collocated, pair programs quite frequently and has become very effective using conversations in the team room to solve problems and help each other out.
When it became more and more likely that we would be working remote sooner rather than later we had a discussion about how we wanted to handle it. The main practice we adapted was to have an open voice channel on Slack during our core working hours. We all agreed we didn’t need video, and most of the time, everyone stays on mute.
We’re not using the voice channel as a means of keeping tabs on everyone. For a lot of quick questions, the team members message each other via text, and only jump on the voice channel when a discussion makes sense. It’s not to monitor the team to make sure they’re working, it’s to recreate the advantage we had working in the same room.
This approach works because the team trusts each other. When we discussed how we wanted to proceed, we didn’t talk about whether people were going to do their jobs, we just focused on what would work best given the situation.
Your product team needs to be clear about how you expect to communicate with each other. That includes how you’ll handle quick questions, what tools you’ll use, where you’ll record different types of information and how you’ll want to handle different interactions.
The next section describes the tools and techniques i’ve found helpful for the usual interactions you’ll see on a product team.
Because many agile coaches insist that face to face is the only way for a team to interact, I explore how each of the ceremonies from the Scrum framework can be done remote.
Please don’t read this and quote the Scrum guide chapter and verse back at me, these are techniques that my team has tried and found to work.
If you’re working remote, then you are more than likely using a backlog management tool such as Jira or MIcrosoft Azure DevOps (I only mention those because they are the tools I have experience with lately.)
Regardless of the tool, I find it helpful to visualize the backlog in a couple of different ways. I like to visualize the progress of backlog items in the team’s refinement process using a discovery board. If you’re using Jira, you can create a separate board (using the Kanban Board functionality) to make a discovery board. If you’re using Azure DevOps, you can establish your discovery board columns as part of the board view.
Some of the columns I have on my current discovery board include a Refinement column that I use as the agenda for refinement discussions with the team, a sizing column that acts as the agenda for sizing discussions and Ready for Sprint Planning that we use as a holding column for our sprint planning.
As backlog items progress along the discovery board, they get more refined, and get more information behind them. I find it helpful for a team to come to an agreement on what information needs to be in a typical backlog item and we encapsulate that agreement in our definition of ready.
We do our refinement session using the open Slack voice channel I mentioned earlier. I’ll share my screen showing our backlog board, open up the top item in the Refinement column and briefly describe what the backlog item is about. Then the team asks questions, provides comments, and we discuss things that may be a little unclear. All along I’m making notes in the backlog item based on our discussion.
When we size backlog items, we follow the same routine, but we’ve replaced planning poker cards with the team members writing their sizes on the screens using the marker functionality. If you’ve ever heard of adult coloring books, you’ll understand the attraction of using the drawing feature. In fact my team said the last couple of sessions where they were drawing their sizes on the screen was the most enjoyable sizing session they had been involved with.
If we have several items we need to size we’ll do bulk sizing inspired by Steve Bockman’s Team Estimation game. When we do bulk sizing remotely I put the list of backlog items to size on a Google Sheet or spreadsheet and share it through the Slack Voice channel. Then we follow the same approach as the Team Estimating game where each person takes a turn sizing the next item, changing the size someone else suggested, or pass.
Each team’s discovery board and definition of ready will be different based on their particular context and need. One team I worked with was comfortable sizing items before they had been fully described. The team I’m working with right now prefers to size a backlog item once it’s fully described.
For us, fully described means that we’ve got the information identified in our Definition of Ready captured in our backlog item tool. When the backlog item has a UI component, we’ll often have a user interface prototype created in Figma linked to the backlog item. If the backlog item includes a new database table, we’ll have a data dictionary for the table included in source control.
We’ll also record acceptance criteria and for backlog items with particularly complex logic, we’ll also include a set of examples.
These agreements evolved over time and we regularly revisit what we record as we learn about what is enough or too much to record in the backlog items.
When I work with teams that do sprint planning, we’d fire up a Zoom meeting since Sprint Planning is open to people outside of the immediate team. I’d share our backlog tool and focus on the Ready for Sprint Planning column.
We start by getting agreement on what we want to accomplish in the sprint. Next we discuss our anticipated capacity for the upcoming sprint.
Then we discuss each item in the ready for Sprint Column briefly. I’ll ask the team if they feel they feel comfortable including that item in the sprint. If so, we’d move that item over to a ready for dev column and move to the next item. We’d continue that process until the team feels that they’ve “filled up” the sprint.
When I work with a team that uses a flow approach we generally don’t have an explicit planning session since items flow across the board.
When I bring new items into the Ready for Development column that jumps some things that were already there I make it a point to mention to the team and check that they are ok with the change in the order of what’s next. I’ll usually ask the team that during Stand Up along with an explanation of why the order changed.
For stand ups, we’ll share the backlog tool and focus on the items that are in active development or testing. I refer to this as the delivery board. We start at the items that are being tested and get a quick update, and then walk backwards to get quick updates on the items that are under development.
After that, I ask if there are any “standupy” items to discuss. This is when members of the team will bring up any obstacles they’re running into or let us know if they will be away from their computers for a bit during the day.
We went away from the questions three because it felt too much like a status report, and it didn’t necessarily guarantee that we’d discuss every item that was in progress.
For sprint reviews, we use Zoom because there are people included who are outside of the team involved. We’ll put together a few slides providing an overview of where the project is, mainly due to a request from the organization we’re working for right now.
After sharing a few key pieces of information I’ll demo any new user facing functionality the team produced. Then we’ll open things up for discussion.
When we do retrospectives, we follow the action focused retrospective approach I wrote up in a recent technique brief. When we do our retrospectives remote, we’ll use the Slack remote channel and then share a tool that allows for team members to write anonymous notes in one of the four typical questions.
My current team uses Azure DevOps, and it has a Retrospective feature that does a good job of mirroring the various steps in our action focused retrospective approach.
If you don’t use Azure DevOps, you can use Google Docs as a good replacement.
How and when is it effective to do remote meetings with video screen sharing?
Does it really add value and in what cases does it bring stronger cohesion and relationship building? How do we get team members to not be hesitant to do show video and make it more status quo only if it helps and can stay focused on the task work at hand?
There are a lot of people who suggest that you turn on your video when you’re in a remote meeting. There are good reasons and not so good reasons to do this.
Among the good reasons is that people communicate through many more channels than what they say. Having video provides additional insight into what the other people are trying to communicate, which can be invaluable.
But some argue that you should have video on so that you can tell whether people are paying attention in the meeting. I’d suggest a different perspective on this reason. If you need to make sure that people are paying attention in a meeting perhaps, just perhaps, they don’t need to be in that meeting.
Then there’s the idea of having people keep their video cameras on all day so you can keep in touch with your other teammates and recreate working in the same room. That can also be interpreted as keeping tabs on your team.
Then there’s also the thought that if you’re an extrovert you really miss that face to face connection and would like to have connection through seeing your teammates. If, however you’re an introvert (like I am) you may not need that visual connection with your teammates all day every day.
I find the audio channel on Slack to be fine, but don’t see the need to have video on all the time.
On top of all that there are some people who are working with less than optimal broadband where video calls can often drag down network traffic. For that reason, I tend to not turn my video on unless it’s a conversation that requires the visual communication channel.
At the end of the day, have a conversation with your team about your expectations around video, understand why you do or do not want to have video and decide accordingly.
How do you deal with different cultures and personalities on your team?
It’s extremely important to understand the different cultures on your team. (Frankly that’s something that applies whether you’re remote or not.)
When you’re in a remote setting, you need to make sure that you aren’t asking people to do things at certain points in time during the day when their culture indicates that they should be doing something else.
If you’re talking with a substantial time dilation of more than four or five times zones different, you’re inevitably going to be in a situation where you’ve got people having to either stay up late or get up early or both in order to have any kind of synchronous communication.
I usually approach this by sharing the pain. So if one group of people has to be up early one time , switch the timing of the discussion so a different group has to get up early or stay up late the next time. Allow everyone to have interactions during their regular working hours at least some of the time.
The other thing to remember about accounting for different cultures is to remember that you are working with people who have hopes, dreams, fears, and concerns just like you do.
What type of remote worker are you?
Are you a connector, a talker, an observer, an explainer, an improver, a driver, a promoter, or do you exhibit some or all these traits at any given time?
Nicole Wosje takes a look at the 7 types of remote workers and explains why you need to embody a bit of each archetype depending on the situation.
How can you be an effective remote product manager?
Ron Yang shares his 5 tips for remote product managers based on his experience working with Aha!, an entirely remote organization.
- Show the purpose
- Show visual plans
- Respond super fast
- Jump to video
- Celebrate the team
How to deal with time dilation, relatively speaking
In an ideal world your team would all be in the same building sitting in the same areas and able to have spontaneous in depth conversations when you need.
In the real world, you aren’t always able to get people with the skills you need to set up shop in San Francisco, London, Sydney, or even the Silicon Prairie. You may find that getting the skills you need requires you to have a team that spans multiple time zones. Maddy Kirsch shares 6 tips to manage a product team that spans time zones. Follow these tips to reduce the impact of time dilation for your distributed team.
Your Basecamp doesn’t have to be at the office
“As an employer, restricting your hiring to a small geographic region means you’re not getting the best people you can. As an employee, restricting your job search to companies within a reasonable commute means you’re not working for the best company you can. Remote shows both employers and employees how they can work together, remotely, from any desk, in any place, anytime, anywhere.
You can be agile and remote
If you would like to use all or parts of the Scrum framework, but are concerned that you can’t because your team is distributed, you may want to check out the Distributed Scrum Primer.
The primer outlines practices that can help distributed teams excel, and highlights some of the common pitfalls that teams encounter, along with ways to respond to these challenges. The primer outlines:
- practices which can help overcome the challenges that come with a distributed team, first in enabling communication and then in building trust
- useful tips for implementing the Scrum roles, meetings, artifacts, and technical practices
- common pitfalls to avoid
6 Tips for effective product ownership at a distance
Effective product ownership allows you to focus your team on outcome over output, build shared understanding, and make sure decisions get made. These activities are key to building the right thing and not building things that aren’t needed. When your teams are separated from each other, or your Product Owners are separated from your teams, those activities become more difficult, and more important. This webinar I recorded with Luke Hohmann includes six tips you can use to practice effective product ownership in a distributed situation.
The Suddenly Remote Playbook
Put away your fancy tools: running remote workshops for humans
I’ve seen a lot of conversations about the bet collaborative tool to use for online interactive sessions. Sometimes the simplest tools are the best. Here’s how to do the online version of post it notes and sharpie markers.
Remote Work Doesn’t Have to Mean All-Day Video Calls
Marco Minervini , Darren Murph and Phanish Puranam describe the remote work practices of the tech company GitLab to explore what it might look like if companies break their employees’ chronological chains as well as their ties to the physical workplace.
11 tips for better workshops with virtual whiteboards
Eric Provost has been running virtual workshops for almost 2 years now, using Miro as his canvas for collaboration. Miro is a virtual whiteboard that can be used for a lot of things, and he realized that it was also very good to run workshops – as long as you use it right.
Here’s a list of things Eric learned to make the most of Miro to optimize virtual workshops. You’ll see that these tips can easily translate to other virtual whiteboards.