The Product Compass

The Product Compass

Share this post

The Product Compass
The Product Compass
The Remote Product Manager's Playbook
Copy link
Facebook
Email
Notes
More

The Remote Product Manager's Playbook

Best practices and advice from over 3 years of working as a remote Product Manager with product teams distributed across different time zones.

Paweł Huryn's avatar
Paweł Huryn
Feb 09, 2025
∙ Paid
88

Share this post

The Product Compass
The Product Compass
The Remote Product Manager's Playbook
Copy link
Facebook
Email
Notes
More
1
3
Share

Hey, Paweł here. Welcome to the free archived edition of The Product Compass Newsletter!

Every week, I share actionable insights and resources for PMs. Here’s what you might have recently missed:

  • Product Manager Onboarding: Your First 30/60/90 Days

  • AI Prototyping: The Ultimate Guide For Product Managers

  • The Ultimate ChatGPT Prompts Library for Product Managers

  • Free AI Agents For Product Managers

  • The Ultimate List of 147 Product Manager Interview Questions

Consider subscribing and upgrading your account for the full experience:


For the last three years, I’ve been working as a remote Product Manager, spending half of that time in a fully remote product company with teams and team members spread across different time zones.

I often get questions like, “Don’t you miss people?” or “How do you build relationships remotely?”

But I never saw it as a challenge. No significant struggles, no painful lessons. This way of working just felt natural to us.

Instead of focusing on problems, I’ll share what works for my teams and me:

  1. Canvases Supposed to Help You Build a Remote Team

  2. Five Essential Rules of Remote Communication

  3. How to Manage Knowledge When Working Remotely

  4. How to Manage Your Time When Working Remotely

  5. How to Plan Remote Meetings

  6. When Working Remotely is Not Enough

  7. Conclusion


1. Canvases Supposed to Help You Build a Remote Team

First, some might advise running a Team Vision & Mission or Team Charter workshop and filling out a canvas with a “team motto,” “skills,” “mission,” etc.

A Scrum Master might even kick things off by asking, “Why do we exist?”

If it’s a new team, I call BS.

Sure, documenting certain aspects like a team’s structure, key metrics, or product areas can be useful (more on that in point 3).

But to me, team culture doesn’t come from a workshop. It forms through hundreds of daily interactions, decisions, and retrospectives.

And your purpose? It’s simple: support the company’s vision and its objectives. Defining the "Why" separately isn’t just unnecessary, it’s dangerous as it can lead to misalignment.

So, let’s move past the templates and focus on how you actually work together.


2. Five Essential Rules of Remote Communication

I’d argue that communication is the most essential skill for a Product Manager. You must communicate the strategic context and turn chaos into clarity.

Here are five essential rules I follow in my work as a PM:

Rule 1: Real-time messaging over email

In 2024, there were probably more weeks when I didn’t send a single email than when I did.

In remote-first companies, over 90% of communication happens through real-time messaging, video calls, and collaboration tools (Slack, Zoom, etc.). Not email.

What’s essential for me is:

  • Knowing if my message was read without guessing if it got lost in an inbox.

  • Reacting to messages without spamming. Sometimes, all you need is 🙈🫥🎉🔥😈🤓 (or something way crazier). Emoticons are a cultural glue!

  • Using sub-threads to stay organized without endless reply chains.

  • Jumping to a quick voice/video call when needed.

Rule 2: Async over sync communication

There’s a saying, “Most meetings could be an email.”

I’d take it further: most meetings could be a simple message in Slack.

You don’t need a meeting to:

  • Ideate: Brainstorm asynchronously.

  • Read a document: That’s what documents are for.

  • Write a document: No live call needed.

Meetings should be reserved for:

  • Workshops: When everyone comes as prepared as possible to discuss complex ideas and solve problems, not listen to a presentation.

  • Retrospectives: A space to reflect on what’s working and how to improve as a team.

  • Informal chats: From the outside, they might seem like time spent on non-work topics, like movies. But I’ve noticed that some people need these conversations, and they help build stronger relationships. Usually, they are integrated at the start of existing meetings, such as bi-weekly syncs.

In practice, some all-hands meetings will still happen. But keep them to a minimum.

Rule 3: Video > Sound > Text

The more complex the issue, the richer the communication format should be. Video transfers more information per second than text.

I often:

  • Jump into a quick Slack huddle when a text exchange becomes too long or confusing. Sometimes without a camera.

    A 6-minute huddle instead of two hours of texting
    A 6-minute huddle instead of two hours of texting
  • Record a 3-minute Loom video with screen share and my face for stakeholders instead of sending documents or Figma prototypes (let’s be honest, most people don’t read them).

    A short Loom recording for stakeholders
    A short Loom recording for stakeholders
  • Follow up with a video call, if needed, only with those who need it.

Of course, in many situations, writing a few sentences is easier than recording a video. You will intuitively match the tool to the situation.

Rule 4: Horizontal and vertical communication channels

When using Slack or other real-time messaging tools, structuring channels effectively makes a huge difference. Consider:

  • Team & Department Channels: For ongoing discussions.
    Examples: #team-alexa, #engineering-product, #product-talks

  • Initiative-Specific Channels: For focused collaboration.
    Examples: #video-streaming, #stripe-integration (invite the stakeholders)

  • Cross-Functional & Cross-Team Channels: For broader collaboration.
    Examples: #production-incidents, #product-sales-talks, #team-alpha-beta

This helps reduce noise and ensure the right people are in the loop.

Rule 5: Camera on?

As a Product Manager, I keep my camera on ~80% of the time, especially in small meetings. Building trust and familiarity is key.

But let’s be real: hours of video calls are exhausting. So, I turn my camera off when:

  • Jumping into quick Slack huddles with close team members.

  • Attending large meetings (~20+ participants) unless I’m speaking.

More importantly, not everyone is comfortable on camera. And that’s okay. If your engineers, designers, or QA prefer to rarely (or never) turn theirs on, respect that.

That doesn’t mean they’re disengaged, and in my experience, it doesn’t impact outcomes.

At the same time, some might need to see others' faces. While I recommend that Product Managers, leaders, etc., keep their cameras on most of the time, I would leave decisions about camera use within remote teams to those teams. Discuss that openly.

Share


3. How to Manage Knowledge When Working Remotely

When working with remote teams and stakeholders, managing knowledge effectively is crucial. Here are three key tactics:

Keep reading with a 7-day free trial

Subscribe to The Product Compass to keep reading this post and get 7 days of free access to the full post archives.

Already a paid subscriber? Sign in
© 2025 Paweł Huryn
Privacy ∙ Terms ∙ Collection notice
Start writingGet the app
Substack is the home for great culture

Share

Copy link
Facebook
Email
Notes
More