The Path to a Better Slack
Building a unified experience with Slack instead of trying to replace it all at once
In my previous post I wrote about the problems with Slack and why it doesn’t scale. I’ve spent a few weeks thinking about what could be a better solution and the path to get there. I’ve written about it below. As always, please share your thoughts and feedback with me.
Chats vs Posts
Chats are great for conversations that require quick responses or immediate action. However, the experience begins to break down when discussing things that require more thought and time to evaluate. For example, let’s say you’d like to discuss your team’s roadmap for the upcoming year. Discussing the topic in a channel with many people will quickly grow out of hand as multiple conversations occur at the same time. It is also be more difficult to refer back to the conversation at a future point in time (for example if you’d like to look up why a particular decision was made).
On the other hand, Posts (think of Facebook- or Reddit-style posts) are a much better format to have these discussions in. All the relevant information is contained in a single place and people can reply within the same context. The result is that the discussion is not easily lost or buried within other messages and you can build better features around discoverability of important information (such as newsfeed or search). This approach is also more conducive for teams working across time zones as it allows for everyone to read and respond in their own time — as opposed to chat where if you don’t respond immediately you’ll likely not be able to contribute nor keep up with a long discussion.
Using posts is actually how we communicated at Meta using Workplace, so I’ve experienced first hand how much better this approach is and how well it scales. That doesn’t mean we didn’t use chats (in fact we used them a lot). Deciding to use chats or posts depended on the urgency or purpose of the discussion.
Why It’s Hard to Replace Slack
So let’s say I built a really great product that’s 10x better than Slack. It has a great chat experience, integrations, intuitive UI and superb posts feature for discussions. Despite this, I still think it’s going to be really hard to replace Slack inside a company. I mentioned this in my previous post, but I think it’s worth diving into a more detailed example here:
Consider a company like Deel. They have 1000 employees, are fully remote and are heavy users of Slack. Even if the CEO and executive team loved my product and wanted to switch away from Slack, they would have a hard time successfully making the change. I imagine the attempt to change would play out something like this:
CEO and exec team make announcement that they want to change away from Slack to my product.
They’re not going to turn off Slack and move all at once since this is primary way they communicate. So the plan is for the two products to exist together for an interim period while everyone gets used to the new product.
Some people use the new product but the majority still keep using Slack since this is what they’re used to.
The result is now that information is split between the two platforms. To make sure no-one misses any important announcements or updates, these are shared in both apps.
People are annoyed there are now two apps for communication. No-one’s really sure when to use which app. The company decides it’s not worth the hassle of switching and reverts back to using Slack only.
The above scenario is something I’ve seen happen to a few companies that tried to adopt Workplace from Meta. They were using both Slack and Workplace but it wasn’t clear to people when to use either app. People stuck to what they were familiar with and kept using Slack. Eventually, companies decided to get rid of Workplace. Even for companies that had no intention of replacing Slack and wanted to use Workplace for its posts feature (and for not chat), the result was the same.
The Path to Replacing Slack
I think a better path to gain adoption within a company is to build a product with the idea in mind that it will co-exist with Slack for a period of time. This means building a unified experience with Slack instead of trying to replace it all at once. This will allow for a smooth and organic adoption of the product, instead of a forced one.
And so with the above in mind, I’ve come up with a product roadmap of what I’m going to build. Naturally, I’ll be open to making changes along the way as I prove or disprove my assumptions and hypotheses.
Phase One: The Individual Experience
I want to first build something that a single employee can use on their own. To do this I’m going to build a product which makes the Slack experience more manageable for them. Ideas I want to test around this are:
A newsfeed for Slack. A pain point that came up in my research was that people were missing important information and discussions in Slack. A newsfeed with an easily digestible UI can solve this. To build this UI, the newsfeed would live in a standalone website and not inside the Slack app
An ‘organizer’ for Slack. Group your Slack channels by project and then these channels are continuously scanned for important information (e.g. Figma links, Notion links, Google Docs or even just important Slack messages). This information is then grouped into easy to find sections. A mockup of this can be found here.
A ‘smart reminders’ feature. People frequently lose track of requests they need to respond to in Slack or even of requests they’ve made from other people that they haven’t followed up on. This integration would automatically remind you if you may have forgotten something. This is different to Slack’s reminder feature as that requires you to manually set the reminder, whereas my feature would do it automatically.
Phase Two: The Team Experience
Once the user has an established habit of using the app on their own, I can then add features that make it better to use with one or more coworkers. These will begin to move in the direction of posts that I mentioned earlier. Ideas I have around this are:
Better discussion features. Building on top of the above-mentioned newsfeed and organizer ideas, we can make having nuanced discussions in Slack threads much easier by adding features such as inline-commenting (like in Google Docs) or grouped replies (like Facebook has for comments in posts). The limitation of the Slack app means that these would not be viewable in this nice format in the Slack app but only in my product. In the Slack app these would appear as regular replies in threads.
A powerful posts editor with templates. Much like Notion’s editor. This would let you create beautiful and engaging posts that can be shared inside of Slack. Once again, due to the Slack app’s limitations, the viewing experience will better in my product rather than inside the Slack app (but it shouldn’t a broken experience in the Slack app).
Phase Three: The Company Experience
Once enough teams are using my product and the product has a critical mass of adoption inside the company, I can then think about features which allow for its full deployment inside a company. I can also then think about competing with Slack’s core features head on, such as Chat and Integrations.
Thanks for reading! Please do share your thoughts with me.
I do think smart reminders would be interesting as things get lost in context switching between priorities. On the flip side, it might create more noise from low/no priority things that would normally fall by the wayside.
Regarding that latter, one of my issues with slack is it's viral nature within a large company. Someone @'s me in a channel, and I answer. Activity on the channel causes others to click on the channel, and ask more questions. Inevitably, the combo of these things serves as a reminder to ask me about something via DM or e-mail, and all these come in a short time frame. It's kind of like having a desk in a high traffic area causing you to get the unscheduled drop in.
I like this idea. There are some significant downsides that you’ll want to keep in mind though:
1) Your addressable market becomes just those who use Slack. This is a lot, but still a niche.
2) Slack is quite expensive. If you don’t have a clear path off Slack, this is likely to put a cap on your price.
3) You become subject to changes in Slack - pricing, technical or even then building enough of your product that you don’t have one.
4) Phase 3 is really hard. Building a good Slack replacement can’t be done easily or quickly.
Could you perhaps consider building your product so it could run on top of more messaging platforms, to reduce some of those downsides?