In an office, a lot of product context spreads without anyone trying. You overhear a conversation about a customer problem. Someone sketches an idea on a whiteboard and three people join in. A quick question gets answered on the way to lunch.
Remote, none of that happens by accident. If something isn't written down or said in a meeting, most of the team never hears it.
My role at WiZR was fully remote, working from Mumbai with people in different places. It made me much more deliberate about how product information moved through the team. Most of what I changed came down to writing more and meeting less, but meeting better.
Write decisions down
The single most useful habit is writing every significant decision down where the team can find it. What was decided, why, what alternatives were considered, and who decided.
| Decision | Date | Why | Alternatives considered | Owner |
|---|---|---|---|---|
| Launch summary feature on web first | 12 Mar | Easiest to roll back, most users | All platforms at once | Product |
| Defer bulk export | 15 Mar | Access requirements unclear | Build basic version now | Product |
These examples are illustrative. A simple log like this answers most "why did we do that?" questions without a meeting. It also helps people in other time zones who missed the discussion.
Default to async, meet when it helps
Status updates, simple questions and most reviews can happen in writing. Meetings are better for:
- Decisions with real disagreement.
- Brainstorming early ideas.
- Difficult conversations.
- Building relationships, especially with new people.
GitLab's all-remote handbook is probably the most detailed public guide to working this way, including how they handle async communication and meetings. 1
Make written updates useful
A good async update is short and easy to scan. I usually use something like:
- What changed since last time.
- What's next.
- What's blocked and who can help.
- Decisions needed from the reader, if any.
Put the important bit first. If someone reads only the first line, they should get the key point.
Respect time zones
When people are spread across time zones, meeting times are always a compromise. Rotate the inconvenient slots so the same people aren't always on late calls. Record important meetings and share a short written summary.
Give async discussions enough time. A decision that needs input from someone eight hours away can't be made in the same afternoon.
Keep context in one place
Remote teams suffer when information is scattered across chat, email, documents and different tools. I try to keep a single home for each project: the PRD, the decision log, key links and the current status. Chat is for quick conversation. Anything important gets moved to the project home.
Over-communicate the why
In an office, people pick up the reasoning behind decisions informally. Remote, they mostly see the decision. Explaining the why, in writing, helps people make good decisions on their own when you're not online.
This connects to the first 90 days post. When I joined a remote team, the written history was how I learned why things were the way they were. Where it was missing, I had to ask a lot of questions.
Make time for people
Remote work can become very transactional. Every interaction is about a task. Make some time for informal conversation, like a few minutes at the start of a meeting or occasional calls with no agenda.
People who feel connected to each other are much more likely to raise problems early, which is one of the most valuable things a product team can do.