The Product Manager’s Guide to Slack Channels

The PM's Guide to Slack Channels.png

Most product managers use Slack to communicate with teammates and stakeholders. But, few product managers are trained to optimize their Slack usage. In fact, most product managers don’t realize that they’re misusing Slack channels, which causes them to not get the results they want.

So, I’m writing this Product Manager’s Guide to Slack Channels to enable you to do better work. But before we dive into how to best leverage Slack channels, let’s first talk about why it’s so hard for people to intuitively know how to use Slack for maximum efficiency.

Why is it hard for people to use Slack effectively?

For the purposes of our discussion, we’re going to focus on your company’s Slack workspace. We won’t discuss how to use Slack product management communities like Product Buds or Mind the Product.

Most human beings don’t naturally know how to use Slack, because that’s not the way we typically interact with the people around us. In the physical world, we rely on subtle physical cues and societal traditions that enable us to communicate effectively.

That means that using asynchronous remote communications like Slack is something that’s not innate to human beings. So, the vast majority of people don’t know how to effectively use Slack to communicate, because there are no clear societal rules or rituals to help guide people.

Let’s change that together. First, I’ll define what the different kinds of Slack channels are. Then, I’ll dive into an analysis on when to use each kind of channel. Once you know how to best use each type, you can then model the appropriate behavior at your company.

As a quick sidebar, many of these best practices are also applicable to Microsoft Teams, which also has similar concepts of channels and direct messages.

So, don’t hesitate to abstract this knowledge to other instant messaging platforms!

What are the different kinds of Slack channels?

I classify Slack channels into the following four types:

  1. Public channels

  2. Private channels

  3. Individual direct messages (DMs)

  4. Group direct messages (DMs)

Public channels are accessible by anyone within your company. That means that anyone can view or join the public channel, and any messages or files that are shared in these channels can be found through Slack’s search functionality.

Private channels can only be accessed by the people who are already within the channel. While you can add more people to the channel, these private channels cannot be found by others who don’t have permissions.

On top of that, any messages or files in these channels won’t appear in Slack search, unless the person who’s searching is a member of that private channel.

An individual direct message is a one-on-one conversation between you and one other person. The messages and files that you share with each other are strictly private, and no one else can see them or find them.

On top of that, every time you send a direct message, the recipient will receive a notification ping, so that they know that you’re reaching out to them.

A group direct message has attributes of both an individual direct message and a private channel. Like individual DMs, group DMs will ping everyone in the group whenever someone replies. And, like private channels, group DMs are searchable by anyone who’s within the group.

However, unlike private channels, when you add a new person to a group DM, you actually create a totally new group, which means that the new person cannot access previous conversation history.

Now that we know the four kinds of Slack channels there are, let’s discuss best practices for when to use each type.

When should I use public Slack channels?

Public Slack channels are best for establishing context across the company, whether it’s status reports, achievements, or key risks to an initiative.

By providing this transparency, you give people the opportunity to use that information to drive their decisions, and you invite them to have the chance to engage you more deeply on the topic.

In general, you should default to using public channels in Slack, because that way everyone is operating under the same shared context.

Shared context is the best way to keep the business moving forward, so try to push yourself to make as much information public as possible.

In fact, any time you’re writing a direct message (DM), first ask yourself whether this is something that other people would find valuable.

If so, go ahead and move that DM into the relevant public channel instead, and just tag the other person in your message so that they know you’re directing it to them specifically.

Not only will the company benefit from your use of public channels, but you’ll also reap a couple of valuable side benefits:

  • You’ll typically write more thoughtful messages in public channels, since now everyone’s got eyes on your message

  • If the people you tag in your message don’t respond, you now have evidence that they didn’t respond, and the entire company can see where the bottleneck is

Since public Slack channels don’t send notifications to people unless they’ve been tagged, don’t worry too much about information overload!

In a later article, I’ll discuss when to tag people in public Slack channels - but for now, just know that messages in public Slack channels don’t usually notify people with push notifications on their phones or with popup notifications on their computers.

When should I use private Slack channels?

Sometimes public channels aren’t the right place to put information. That happens when the topic is sensitive, or when the topic may not make sense without a specific set of context.

As an example, you generally should not expose “software development conversations” in public channels because

  1. It’s really noisy sometimes as you hash out the implementation details and tradeoffs

  2. Sometimes go-to-market teams will use your internal estimates as an external commitment date, and that’s not good for your customers or for your teams

So, in general, you should keep software development conversations in private channels.

The downside with a private channel is that you have to proactively add people to it. Many times, there are key stakeholders that you don’t know about, and they can’t find the right channel to coordinate with you.

So, only use private channels if you’re absolutely certain that you’ve got the full set of stakeholders in that private channel, or else you’ll wind up with a ton of duplicative private channels where you have different subsets of stakeholders.

Here’s a real example.

We had created a private channel for product managers and legal/compliance to coordinate with one another. The thought was that we could hash things out at a broader initiative level or spec level, without needing to involve people in engineering or design.

But, over time, we started finding that some kinds of compliance considerations required us to work through prioritization. That is, we needed to understand how much engineering effort it would take to implement a feature one way vs. another.

So, we had to invite engineers into the channel. But, confusingly, the private channel was named #product-legalcompliance, so newly-added engineers didn’t understand what the channel was for!

Then, on top of that, after another few months we found that designers had questions about particular product specs, and they wanted to coordinate with legal/compliance directly.

So, now there were #design-legalcompliance private channels on top of our #product-legalcompliance channel (which now had engineering in there too).

At the end, we finally brought engineering, design, product, and legal/compliance together into the #product-legalcompliance channel and deprecated the separate #design-legalcompliance channel, so that we could drive better information flow and visibility.

Another problem with private channels is that Slack doesn’t give you the ability to turn a private channel into a public channel. In other words, your decision to make a channel private is irreversible, so make the decision carefully!

One mistake I commonly see is that people will start project-based channels as private channels. This is problematic because more and more people want to learn more about the project, and so more and more people get added to the private channel.

Sometimes, I see private channels that have more than 50 people in them! At that point, it’s not really valuable to have the channel be private.

Whenever you have more than 20 people in a private channel, consider starting a new public channel where you invite all of the all of the private channel attendees, and then archive the private channel.

To recap: whenever you’re creating a project-based channel, make sure that you start it as a public channel! If you really do need to have a smaller subset of people, consider using a standard naming convention for the smaller private channels.

For example, I have a #personal-loans public channel for my day-to-day work at Blend, but then I use the prefix “pl” to stand for personal loans. I then have separate private #pl-devs channel and #pl-gtm channel to work through more targeted conversations around software development and around how to go to market. 

Note that not all subset channels should be private!

As an example, I have a #pl-metrics channel that is distinct from #personal-loans, but that channel is public because I want anyone to be able to see it.

Similarly, I have a public #pl-questions channel for anyone to ask me questions about the product.

And, I have a public #pl-updates channel with a Salesforce integration, so I can see how all of my personal loans customers are progressing. If I see a concerning update from one of our accounts, I can reach out to the customer success manager in the #pl-updates channel directly to gain a better understanding, and that information is then accessible to the entire company.

When should I use individual direct messages?

Think of individual direct messages like text messages. They’re fast, informal, and highly noticeable by the recipient. People will know immediately that you’ve DM’d them.

DMs are really helpful if you’re trying to coordinate with a single person in real time.

For example, if you’re on a call together with a customer and you need to have a sidebar, DM’ing the person can be really helpful.

DMs are also best for personal conversations. Whenever you’re chatting with friends about their weekends or commiserating over a difficult project, you probably don’t want to put that into the public eye.

You can also use DMs to bring someone up to speed privately, before pulling the conversation back into the broader channel. This is helpful whenever someone new is joining the conversation but is missing key context.

For example, if you’re about to tag someone into a public channel to ask about resourcing and estimates, you probably first want to set the stage privately with an individual direct message.

“Hey, I’m going to bring you into the public channel because the CEO is looking for updated estimates on our initiative. Anything that you need from me before I tag you in the channel?”

By privately aligning with the participant upfront, you ensure that you have their opt-in agreement, and your counterpart won’t feel caught off guard in a public channel.

Don’t hesitate to coordinate with people first in individual DMs, and then pull them into the relevant public channel once they’re ready!

As an aside - if you’re looking to strengthen your ability to influence others and manage stakeholders, considering joining the Product Teacher PM Masterclass. We teach product managers both hard skills and soft skills, and students have used our Masterclass to break through obstacles and secure promotions.

When should I use group direct messages?

Group DMs are almost never the right call. Here’s why.

If you use a group DM, the conversation quickly becomes unfocused between all of the participants. You’ll find that people will have side conversations within the group DM, or you’ll find that people will spin up additional group DMs with new subsets of people. This causes information to become fragmented across the company.

So, whenever possible, if you need to communicate with more than a single person at a time, try to tag all of the relevant people in public channels. And of course, if the topic is too sensitive, then pull them into a private channel to discuss the matter.

The other problem with group DMs is that they ping everyone for every single message that gets sent. Private channels only ping people if they’re specifically tagged, which is a more compassionate way to communicate.

I’ve seen hundreds of thousands of messages on Slack. I’ve only seen two use cases where group DMS are genuinely valuable.

First, if  you have the same group of people coordinating across a variety of different topics, and managing all of those topics as separate private channels is too tedious, then it may make sense to use a group DM. That said, all participants need to be careful about context switching - make sure to preface a new topic accordingly, or else folks will get lost.

Second, if you’re tackling a specific topic with only 3-4 people, and there’s a known time bound, it may not make sense to create a public channel.

As an example, if you’re transferring PM responsibilities from one person to another and you need both sets of managers to have visibility, it doesn’t make sense to have a dedicated private channel to drive this PM responsibility transfer. 

But, these two cases are quite rare. So, the easiest thing to do is to try to stay away from using group DMs. I can’t tell you the number of times where we thought we could use a group DM, but then it became unmanageable and we had to move into a private channel.

Setting things up correctly the first time pays dividends!

Closing thoughts

Product managers are responsible for ensuring that the right information flows to the right people at the right time. Since more and more software development organizations use Slack to coordinate, it’s crucial for product managers to know how to most effectively leverage Slack.

One of the highest-leverage Slack skills to learn is to understand when to use each of the four kinds of channels.

Public channels are great for sharing context across the entire company. Do your best to default your messages into public channels. If you have a specific set of subtopics to cover and you don’t want to clutter up the main public channel, use a prefix and create new dedicated public channels to cover the subtopic.

Private channels are great for group conversations that may be misinterpreted by other stakeholders. The most common use for private channels is for development teams to talk through updates and timelines, without others intruding to try to ask for timelines, make demands, or ask about unrelated questions.

Individual DMs are great for coordinating with a specific person in real time. These are typically informal - think of them like text messages.

You should almost never use group DMs. Instead, consider whether you can use a public channel or a private channel to drive the same purpose instead.

As you implement these Slack channel best practices, you’ll find that your teammates, colleagues, and stakeholders will become more effective over time!


Thank you to Pauli Bielewicz, Goutham Budati, Markus Seebauer, Richard Heathcote, Alina Ha, Juliet Chuang, and Natalie Kwong for making this article possible.

Previous
Previous

Masterclass: Internationalization

Next
Next

Masterclass: Context Switching