Responding in comments

Reminds me of that old saying about wrestling with a pig - you both get dirty and the pig likes it.

That’s exactly what happens in document comments. Nobody wins, but somehow everybody keeps diving back into the mud.

Every PM has been there - you’re putting together the quarterly roadmap deck, or the strategy update, or whatever slice of PowerPoint hell you’re currently inhabiting.

Someone leaves a comment. And then… it happens. The COMMENT RESPONSE.

  • “Actually, this bullet point was specifically requested by…”
  • “Well, we thought about that, but…”
  • “The data shows that…”

Comments on documents? They aren’t a chat room. They aren’t Slack. They aren’t your chance to defend your thesis to your dissertation committee. They are feedback about your content.

When someone leaves a comment, you have exactly two options as the author:

  1. Change the content
  2. Don’t change the content

That’s it. Those are the choices. Notice how “start a comment thread to prove i’m right” isn’t on that list?

But a lot of PMs (and let’s be honest, a lot of other people too - looking at you Devs) love to turn comments into their own personal Thanksgiving dinner argument.

You’ve seen it:

  • Comment: “This section isn’t clear - what’s the actual timeline?”
  • Response: “Well, actually, if you look at slide 4…”
  • Reply: “Yes, but that doesn’t address…”
  • Response to reply: “Let me explain why…”

And suddenly your document looks like a Reddit thread.

Here’s the core problem - and this is the part that should keep you up at night as a PM - If you’re having to explain your ideas in the comments, your ideas are not clear.

Your deck, your doc, your PRD, your user story, your whatever-it-is should stand on its own. If it doesn’t, that’s not a comment problem. It’s a content problem. It’s a YOU problem.

GitLab puts a name on this: high-context versus low-context communication. The lazy default — especially for PMs who grew up in colocated environments — is to write as if everyone in the room shares your context. The discipline is to write as if they don’t.

From the GitLab handbook:

"At GitLab, we communicate assuming others have low context. We provide as much context as possible to avoid confusion.

The goal of low context is to be considerate of the people or audience you're speaking to. It's important to recognize that what you write — either internally or externally — may be read in the future, or by someone who is coming into the conversation at a time after the initial thread began.

This is one of the more challenging elements to master, particularly for those coming from careers in colocated spaces. In colocated environments, high context communication is the default. High context is less direct with an emphasis on human relations, and it's more sensitive to non-verbals and the feelings of others.

Getting oneself in a low context frame of mind can be useful. Start by assuming that recipients of your communication do not know anything about the topic at hand, and wish to learn as much as possible in as little time as possible.

It's easy to imply your experiences with text communication, but remember that not everyone has similar life experiences to relate to, hence the need to be precise.

By being specific, you're forcing yourself to think through what you're saying. In general, there is value in taking the time to be deliberate about communications. Re-read communiques before sending, particularly if they may be perceived as negative or inflammatory to certain parties. The ability to self-edit before sending is a boon to text communication. Vocalized words cannot be unsaid once uttered.

Aiming for precision in communication requires you to put yourself in another person's shoes and try to understand their current perspective and worldview. It's important to view text communication not as a way to impose your will, but as a means to listen, understand, and collaborate.

This isn't suggesting that your communication should be cold or soulless. In the GitLab #thanks Slack channel, for instance, we encourage team members to be specific about what they are thanking someone for, such that you do not need prior context to understand how a value was being lived."

GitLab Handbook — Effective Communication

A comment trail is the evidence that you wrote in high-context mode when low-context mode was needed. The fix is upstream of the comment thread.

When someone leaves a comment, they’re telling you one of two things:

  1. Your content isn’t clear enough
  2. They disagree with your content

Neither of those problems gets solved in a comment thread. Ever. In the history of comments.

So what should you do instead?

If the content isn’t clear: Make it clearer

If they disagree: Either change it (take the feedback) or don’t. You are the PM, it’s your call. Ultimately, you have to stand by the decision.

Then close the comment and move on with your life.

Every comment thread you start or let fester is a tiny failure. It means your content wasn’t good enough to speak for itself. And no amount of “well akshully” is going to fix that.

Last updated:

Next in The PM craft Ship More →