How to Succeed with Remote Development
As a product manager, you might work at a product organization that works with remote teams. For example, I’ve worked with software development teams based out of India and China.
On top of the typical challenges of product management, remote development poses its own unique set of challenges to navigate.
Let’s talk through 1) why remote development can be beneficial, 2) what the challenges of remote development are, and 3) how to mitigate these challenges.
Why Remote Development?
One of the largest costs for any software organization is the salaries that they pay. After all, the business model for software basically converts human time (a fixed cost) into software (an asset), which is then monetized through various means such as advertising and licensing.
Organizations may elect to use remote development teams for a couple of different reasons. The most obvious reason is price: generally speaking, remote development teams are much cheaper per person versus their United States counterparts. This factor is especially critical for small -ups, which may not have sufficient financial runaway to use developers.
Furthermore, organizations may use remote development teams if they seek to provide an international product. It makes sense to use developers who already understand the culture and language where one might want to launch a product – for example, if you wanted to launch a shopping mobile app in Vietnam, you’d likely want to hire Vietnamese resources who can then provide a user experience that best fits the Vietnamese market.
As globalization continues to progress, barriers to using remote development teams will continue to drop. With the advent of video chat, shared repositories, and other core technologies, executives can be more flexible in where they want to hire.
Challenges of Remote Development
As a product manager, you must work with your stakeholders and developers, no matter where they might be located. Therefore, as executives continue to globalize their talent, the likelihood that you will need to work with remote counterparts will only increase over time. Below are some of the challenges I’ve personally faced when doing so.
First off, when working with remote teams, you will face longer response times than with co-located teams. This is especially true with working across multiple time zones. Any question you ask during one team’s non-working hours will necessarily be delayed until the next day.
With remote teams, you also face reduced visibility and accountability. For example, part of the power of standups is that each team member visibly commits to work in front of a team, and each team member can be quickly unblocked when needed.
Your teammates may also feel a lack of product ownership and lack of domain expertise. This is especially true where your teammates are working with business models or industries that are entirely foreign to them. For example, the Indian real estate market operates completely differently from how the U.S. real estate market works.
Nuances and complexity are harder to convey. Much of human communication centers around nonverbal cues, and these cues get missed when people interact asynchronously – that is, when you’re not sitting right next to a person, it’s sometimes difficult to convey meaning or nuance. Experienced product managers know the struggle of trying to share a product requirement without being able to voice over and explain details on the fly – this difficulty is magnified with remote development teams.
And finally, time zones present a real challenge to coordination and work-life balance. If you happen to work across more than 2 time zones at once, you’ll find that nearly everyone needs to make sacrifices around scheduling. I’ve had days where I started at 8 AM with one team, then stayed online so that I could chat with another team at 10 PM.
Best Practices and Mitigations
My teams and I iterated over the course of 15 months to identify how to best work together. Here’s what we found effective.
1) Take the time to know each of your team members personally. Humans are social creatures, and we need to bond with our colleagues to work effectively together. As a product manager, you need to know how your team members want to grow, what career goals they have, and how they prefer to communicate.
Some of my teammates want to become engineering leaders. Others want to become product managers. Some want to focus on visual design, and others want to focus on data and architecture.
Some prefer lots of clarity and instruction, and others prefer more ownership and less guidance.
As for communication, some of my team members love video chats, because we can then record the session for later reference. Others prefer communicating through WhatsApp about both personal life and professional work.
By keeping these details in mind, product managers can ensure that they meaningfully tailor work to each individual and that they continue to strengthen the interpersonal bonds that make up the team.
It’s best to bring your team under a single platform and community, like the Product HQ.
2) Set clear expectations upfront about working together, and make sure you get clarity on how they expect to work with you. Remember that you’re working with people from different cultures, some of which may not be as upfront in setting expectations, and others of which may be more hierarchical than desirable.
As a product manager, it’s your responsibility to ensure that your team is running smoothly. Ensuring alignment from the start can save you significant amounts of time and heartache.
3) Constantly communicate priorities. Your teams may not fully understand decisions made by your executive team, because they did not have the full context by virtue of being remote. As a product manager, you need to provide sufficient context and guidance on how to best achieve organizational goals and product goals.
4) Communicate frequently. Use both 1:1’s and full team meetings to communicate about vision, product strategy, customer needs, shifts in competitive trends, changes in priorities, roles and responsibilities, team expectations, and changes in timelines.
Just because people don’t ask for your time doesn’t mean that they don’t need your time. This was one mistake that I made far too often.
Consider holding office hours a couple of times each week, or continuously offer seminars and working sessions. For example, if one teammate didn’t fully understand the user flow of a particular product requirement, we would schedule 30-60 minutes later for me to run through the user flow, and for them to ask detailed questions and use cases. This saves your team lots of time over the long run.
5) Be completely open to new ways of working and to constructive criticism. My teammates may already have worked together for years, and I’m stepping into their existing processes. These processes work for a reason – by being open, I’ve found new ways to operationalize our product development.
This may sound weird, but you should also encourage criticism and push-back. Developers are domain experts, and they may have a better way to achieve the outcome of your product requirement than you previously thought. Encouraging criticism is especially important when working in countries where seniority and hierarchy are highly valued – team members may feel scared or intimidated to provide their perspectives, which means that your product winds up being created in a suboptimal fashion.
6) Write up documentation or meeting agendas before work meetings. Too often, I’ve run into problems where we as a team would verbally commit to something, then completely forget what we committed to. It helps to have a set of documents that everyone can refer to later as the single source of truth, as it reduces miscommunication and misalignment.
Sending out pre-reads also helps to ensure that teams have full awareness of what future work is scheduled in the pipeline, and enables them to be proactive in asking questions.
7) Turn on webcams on both sides. Connecting faces to names helps with camaraderie. Everyone on the team is going to be making sacrifices, and it’s a lot easier to be patient and selfless with someone whom you’ve bonded with.
8) If possible, visit one another in person. When you visit your remote teams, you’ll pick up on a lot of nuance and context that you would never have seen before – where the team sits, how they communicate, how they work. When your remote teams visit you, they’ll pick up on context that they could never have possibly grasped – how stakeholders interact, what the broader organization looks like, what the culture is like.
Summary
Many organizations have succeeded and continue to succeed by using remote teams to develop their product offerings. You’ll likely be working with at least one in the future, and you can ensure success by being empathetic, patient, and relationship-driven.
You’ll find that by working with geographically diverse teams, you’ll be exposed to entirely new perspectives and ways of working, and you’ll accelerate your personal and professional growth by doing so!
Have thoughts that you’d like to contribute around working with remote teams? Chat with other product managers around the world in our PMHQ Community!
