Remote and Asynchronous Product Management

How to thrive as a PM when working from anywhere

I am currently Head of Product at RevenueCat. Our team of roughly 60 people is globally distributed, fully remote and async-first. This is my first fully remote position, and in this article, I want to share a few lessons I have learned to be effective in this context.

Before diving into my detailed advice, I wanted to share my personal perspective. Different people have different opinions and preferences when it comes to working arrangements, and I don’t believe that what works for me works for everyone else. That said, I am very happy with the flexibility that the remote and async-first work environment provides me. I usually work in the mornings until the early afternoon, then get to spend the afternoon with my kids, and then work another couple of hours in the evening when the kids are asleep. There is simply no way that a full-time office job, or even a more synchronous remote job, would allow me to spend as much time with my family, and I cherish this a lot.

With that out of the way, let me dive into my eleven tips for remote and asynchronous product management:

1. Resist the waterfall
2. Build shared context through documents
3. Create requests for comment
4. Make most meetings async
5. Reserve synchronous interaction for high-bandwidth discussion
6. Prefer 1:1 meetings over team meetings
7. Invest in team building
8. Make offsites mostly social
9. Use available tools
10. Document communication expectations
11. Find balance, disconnect if you need

Resist the waterfall

One anti-pattern to avoid when working asynchronously as a product manager is following too much of a waterfall process, where you spec everything out in detail and then just have designers flesh it out and developers implement it. It’s an easy trap to fall into — after all, that can be done completely asynchronously! However, the discipline of product management has spent the last 20 years becoming more iterative and collaborative, so we don’t want to throw that out of the window.

The key to resisting the waterfall is deliberately building in iteration and collaboration throughout the process. Some more concrete points follow, but overall the most important piece of advice is to alternate deeply working on something and sharing it for feedback and alignment. One of the nice aspects of async-first work is having few meetings and a lot of time for deep work. So use that to meaningfully evolve your thinking around a topic, then share it for feedback. This can easily be done every couple of days.

Build shared context through documents

One of the most important ways to avoid the waterfall is ensuring that the whole team has shared context for the opportunities being pursued and the solutions being designed. The best way to do that asynchronously is through shared documents.

I have found it very important to use very concise documents to share the most important context, because it vastly increases the likelihood of them being read widely and completely.

Two specific types of documents I like to create and share are one-pagers and interview snapshots.

One-pagers concisely (in literally a single page) frame in opportunity that could be pursued. The opportunity could be an unmet customer need, a business objective, or even a technical or usability need.

One-pagers could have different sections, what we’ve landed on at RevenueCat is the following:

• Context and (customer) problem
• Why (now)
• Potential measures of success
• Assumptions and risks
• Solution options

The last point is particularly important because it encourages framing the opportunities in a solution-agnostic way.

Interview snapshots are an idea I’ve taken from Teresa Torres’ fantastic book “Continuous Discovery Habits”. They summarize the key takeaways from a conversation with a customer in a visual way. It looks like this (in contrast to the original template, we’ve omitted the customer journey because it’s a bit trickier to put it together quickly, creating additional friction to sharing a snapshot):

There are a few things I particularly like about this template. Firstly, it is a condensed template that is easily shared as a screenshot on Slack. It’s tough to parse through someone else’s interview notes, and people often don’t find the time to watch interview recordings, and this snapshot provides the most important takeaways at a glance.

Secondly, the photo makes the results more “real” and contributes to building empathy. Thirdly, the memorable quote helps generate excitement for the opportunities that came up in the conversation — an actual quote makes the value of pursuing an opportunity much more tangible than a paraphrased bullet point.

Create requests for comment

In synchronous work environments, formal documents are often the last step of a process, the process output, after the most important points have been ironed out in meetings. In an asynchronous environment, documents should be treated as inputs, as starting points of the process. Accordingly, they should be shared as requests for comment — as initial drafts with the encouragement for others to provide feedback, questions, comments, and improvement ideas in the form of comments.

The ability to comment directly on individual words and paragraphs that modern productivity tools like Google Docs offer has made this kind of communication effortless — it’s pretty straightforward to manage multiple different conversation streams about different topics with different sets of participants all within the same document.

Make most meetings async

This perhaps goes without saying, but one of the keys to working fully remote and async-first is making most meetings asynchronous. This includes the regular team “ceremonies” such as standups. Teams can decide how exactly they want to organize themselves, or course, but we’ve found a lot of success with only conducting retrospectives synchronously (and even those have asynchronous preparation where everyone collects and shares their retro items before the meeting). All other ceremonies, including standups, planning, and refinement, are conducted asynchronously.

This does mean that the processes take a little bit longer, as measured by calendar time. For example, refinement might start a week before the respective sprint starts and take 3 days, followed by planning taking 2 days, to allow for some asynchronous back and forth. However, that doesn’t mean that overall time spent on these processes is higher — in fact, it could be less, since in these ceremonies often only a subset of participants is actively engaged at any given point in time.

Reserve synchronous interaction for high-bandwidth discussion

When should you revert so synchronous interaction then? Whenever you require high bandwidth discussion. High bandwidth here means a discussion in which there is rapid back and forth and exchange of complex ideas.

Holding such discussions asynchronously not only takes longer (because every back and forth incurs waiting time) but also requires additional context switching for every message that is received. In a synchronous interaction, participants only have to build up the context once at the beginning of the meeting.

Prefer 1:1 meetings over team meetings

As a corollary to the previous point, 1:1 interactions are ones where I would more often recommend a synchronous meeting than for team meetings. There are several reasons for this: firstly, team meetings are hardly high bandwidth for everyone — most often, there is only a subset of participants actively engaged at any given point in time. Frequently, at any given point in time, one person is broadcasting to the rest of the audience, and broadcasting is something that can be done asynchronously quite effectively. Secondly, globally distributed teams make scheduling team meetings extra hard, whereas for 1:1 meetings it’s often much easier to find a time that works for both participants. Lastly, the added benefit of synchronous interaction is the ability to read non-verbal cues, which is again much easier in a video call with one person than trying to discern facial expressions of 10 tiny Zoom pictures in a team meeting.

Bonus tip: turn off your own camera view so that you can focus on the other person — you would never bring a mirror to an in-person meeting and put it next to the other person so that you can also see yourself!

One additional point that should be mentioned: some high-stakes conversations, e.g., performance feedback, should always be had synchronously (and these tend to be of the 1:1 variety, anyway).

Invest in team building

A product manager is only as good as their team, and a team requires more than just talented individuals to show high performance. Therefore, it is of utmost importance to invest time in team building. In an office setting, some of that happens organically — a small chat while walking to a meeting, grabbing lunch together, meeting at the coffee machine, etc. While there might be some company-wide rituals in place for people to get to know each other, remote product managers should also consciously build their own teams.

There isn’t one tried-and-true formula for making this work, and in the end every product manager has to find a solution that works for them, but here are some ideas:

• Ensure to start any meetings that you do have with some social chit-chat, don’t get straight to work. If you do have team meetings, you could try some icebreaker questions.
• Make time getting to know team members individually; probably, have regular 1:1s with each of them.
• Consider some regular “fun” activities, like playing online games together. Make sure you respect your team member’s non-work lives and other obligations, though, and ensure you don’t accidentally exclude someone.
• Remote work can be lonely, see if there can be (open) collaborative or pairing work sessions.

Make offsites mostly social

Many remote teams regularly (but infrequently) meet up in person. At RevenueCat, we had our first post-COVID formal offsites (one in Europe, one in the US) in May. We spent most of the time at the offsite with non-work conversations, with very occasional work stuff sprinkled through. Looking back, I actually think that is the right recipe — it’s much harder to bond and get to know your coworkers socially online, whereas the more “transactional” work can be done quite effectively through modern collaboration tools.

For the work conversations that you do have, consider making them either something that requires intense collaboration (like joint whiteboarding sessions), or conversations that are on the “meta” level, e.g., talking about people’s longer-term plans and ambitions. These conversations can feel more natural if you’re able to actually look the other person in the eye.

Use available tools

Over the past few years, the world has seen an explosion of tools for remote work. Make sure to experiment and stay on top of what is happening. Do not limit yourself to Zoom and Google Docs — that will likely mean you end up mimicking the in-office work style.

Just scratching the surface, here are some ideas:

• Whiteboarding and collaborative sketching solutions like Miro or FigJam
• Meeting recording tools like Grain or Vowel
• Asynchronous video tools like Loom
• Collaborative data analysis tools like Hex

Document communication expectations

One of the most frustrating experiences working remotely can be getting stuck, and not knowing when someone will be able to help you out. In an office environment, you can walk around and try to find someone to help. In a remote and asynchronous environment, you can try and ping people, but it might take some time until someone is available.

That problem can of course never be fully solved, but one thing that helps is clearly documenting communication expectations, especially within the cross-functional product team. What are the channels being used (e.g., Slack (which channels?), email, Jira, GitHub)? What is the expectation for what topic gets discussed where? What are the general expectations about responsiveness in each of the channels?

Clear expectations help avoid miscommunication and long waiting times.

Find balance, disconnect if you need

As a product manager, it is easy to feel the urge to constantly be on top of everything that is happening in the team and in the company. In a globally distributed company, something is always happening — there is not ever a time where everyone goes home and nothing happens until the next day (except maybe for the weekend). Trying to be “there” for all of it is a surefire path to burnout. So make sure to disconnect in a way that works for you, and use the flexibility of asynchronous work to your advantage. Talk a long lunch walk. Go to exercise classes in the middle of the day. Spend time with your family. Disable notifications when you’re not currently working and/or don’t install work apps on your phone.

I hope you found this article useful. If you did, feel free to follow me on Twitter where I share thoughts and articles on product management and leadership.