Slack has already proven to be integral to our internal team communication; I wanted to extend this amazing platform to our users. Here’s what we’ve learned along the way, and some ideas for creating your own Slack community.
There are already many channels of communication we’ve opened with our users: email, support, Intercom in-app messaging, surveys, comments from blog posts, and our support forum. These are all great for direct communication and soliciting feedback from users, however, they don’t lend themselves well to open and free discussion about your product.
In our case, we wanted to give our users a meeting ground to exchange ideas, offer each other support, work together, and give feedback to us in an open forum where anyone can participate.
I found a great project called Slackin on Product Hunt that will provide the foundation for you. We’ve implemented it into our app as a button that includes a badge of current logged in users. Clicking on the button will automatically trigger an invitation email to the Slack Community.
At Tutum, we’ve always wanted to create a greater sense of community. We’ve known that our users are highly vocal early adopters of technology and this has always led to spirited debates and working out best practices together in a new technology (Docker), where everyone seems to be solving various problems in new and creative ways.
Of course, the number one killer of a community is having no active participants! We’ve been weary of starting a forum or IRC channel specifically because we didn’t want to have another channel of communication just because. If we had to monitor and upkeep this channel, it had better be useful to both us and our users.
Many technical products use IRC as the meeting ground for interested parties and members of the product team. However, with a little research I found that some companies had already implemented Slack communities, replacing IRC, and have seen more engagement, membership and activity in the Slack communities.
Since lack of participation was our biggest fear, it made sense to go with the platform that would be most likely to have active participants. We also liked the idea of a Slack community since we were already spending our entire work day inside of Slack. It’s also extremely user-friendly and easily one of the “coolest” products currently available, which I thought would appeal to more people than IRC would.
Once we knew we had a handful of very active and vocal community members (observed through forums and emails), we opened up the Slack community and engaged them personally. We also knew that we could help seed the community with our own participation, which we did.
One of the early mistakes we made was participating too much in the Slack community. It ended up turning into a direct line to our engineers for support. We already had a support system through Intercom, so not only did this require us to split our attention, but Slack messages seemed more urgent than support tickets since it was out in the public.
We also made a choice to identify ourselves as Tutum staff in our usernames, which also turned out to be a mistake. While I don’t think you want to pretend to not work for your company, it made us an easy target for Direct Messages where people had the expectation of one on one support.
We found ourselves absorbed in the Slack community and our pace of development slowing down for our product. Not a good position to be in!
We decided to change our usernames and remove the Tutum identifier. We also made sure to tell people who contacted us personally that our time was better spent developing our product than delivering one on one support. We also suggested that all “solutions” and “use-case” questions were proposed and discussed with fellow Tutum community members and to submit all support requests through our in-app support system.
We also decided to limit the time we spent in our community channel. Instead of hanging out inside the channel all day, we would go and check in for 10 to 30-minute spurts. Our CEO will now announce when he’s around and what topics or questions he’ll be answering i.e. product roadmap, a new feature, etc. This sets the expectation of our availability and gives the discussion direction and purpose.
I joined a few other Slack communities by other companies to do a little reconnaissance and I noticed that creating too many channels in the very beginning was a recipe for low participation. I think there needs to be at least a handful of very active users that are willing to participate in any given channel before you should open one up.
If anything, I think it’s better to err on the side of caution with opening up new channels. We started ours with just a single channel, #general.
Another obstacle to channel adoption is the lack of visibility for new channels. It’s not very obvious there are additional channels to join, and someone new to using Slack may not ever find them.
A general guideline for opening up new channels is only when there is repeated high demand. This usually comes in the form of users reaching out asking for us to create that specific channel.
It also makes sense to announce the new channel to the entire community so they’re aware of it. I usually just do this a couple of times in the general channel during different times of day to let people know what the new channel is and its purpose. I’ll also set the “group topic” for #general to an announcement for the new channel.
I would avoid making large announcements that hit your entire user base. I think using @channel or @everyone should be spared for only the most important announcements, like a game-changing feature announcement or major change in the product. However, I think using @channel for specific interest channels like the ones I’m about to describe is okay as long as people had to opt-in to the channel.
The channels we currently have are: #beta_feature_opt-in, #feature-requests, #general, #github-notifications, #pricing, #request-content, and #tutum-buttons.
We use #beta_feature_opt-in as a channel for users to voluntarily opt-in for what we call “superpowers,” which are rights to access features ahead of general availability.
Our #feature-requests channel is pretty self-explanatory and has the added benefit of the community seeing other people’s requests instead of them coming in isolation through our support system. Now if a feature is wanted by many people, they will usually chime in or leave reactions on the post so we know what features resonate with a larger audience.
The #github-notifications channel has an integration set up with our GitHub account, so people can stay up to date with comments, commits, and pull requests on our public repos.
We haven’t released our final pricing model yet, and this is one of the most frequently asked questions we receive – so we opened up a #pricing channel, posted our tentative pricing model and pinned it to the channel for people to view and discuss. This has opened up a whole other can of worms, as we’ve quickly learned that there will never be a pricing model that pleases 100% of your users.
The #request-content channel falls in line with one of our growth strategies of creating educational content for current and prospective users. We figured the best way to see what our users want to learn more about would be to let them tell us!
We actually used the #tutum-buttons channel as a mini-contest. Anyone who integrated our new single-click Deploy to Tutum buttons in their Github repo and posted it to the channel would receive Tutum swag.
Remember under Team Settings you can set what the default channels are. These channels will be the ones new members will automatically join. This will ensure you have an active membership to your most important channels.
Another interesting tip when it comes to organizing the names of channels is to take a page out of Product Hunt’s playbook and use underscores at the beginning of larger broad interest channels. Since channels are organized alphabetically, the underscore will ensure those channels stay at the top and separated from the other more specific interest groups (like location based ones).
I think giving users an outlet to talk about your product is invaluable for a multitude of reasons. As Seth Godin would put it, creating a tribe and being the leader of that tribe is very powerful. It gives users a chance to help one another with difficult and time-consuming questions that we’re unable to address.
We also notice that we have a very large number of support questions that are related to use-case and general Docker questions, as opposed to technical issues on Tutum’s part. These questions are also some of the most difficult to answer, since they’re usually individual and use-case specific with certain technologies we may not be familiar with.
We can’t afford to take away our developer’s time to look into these use-case questions that are outside of “support” so it’s great to be able to point our users to our Slack Community to seek answers instead of just leaving them out in the cold.
This was one of the main reasons we created the Slack Community – to create a living support system that would scale with our user base far more efficiently than we could internally. By the nature of our product and the ecosystem, it tends to attract a lot of early adopters that are eager to both learn and teach. Many of our users maintain blogs and constantly refine processes and best practices surrounding Docker and Tutum.
This same group of users tend to be the ones that help out beginner and intermediate users when they get stuck, while also participating in higher level conversations with other advanced users out in the open for all to see and learn from.
From a retention perspective, it lets our users stay connected to our product even when they aren’t using it. It’s a fantastic way to keep your product top of mind for users, especially through notifications from the Slack group when mentioned. It’s a great notification system because they don’t mind receiving them. If we were to send our users that many notifications it would probably be met with criticism and unsubscribes. Now people can still keep abreast of all things Tutum while waiting in line, commuting, and anywhere they can use their mobile device which is a boon for a product that’s primarily confined to desktop web browsers.
I think this could easily backfire if you have a product people dislike; you would get free opposite-of-evangelism and lots of it. We get quite a bit of love on Twitter from excited and happy users, and that’s great for extending our reach to their circle of followers. But what I think is even more powerful is when you have your user base being exposed to other users that are ranting and raving about the product.
There are three outcomes when a user sees another user espouse how much they love Tutum:
If someone likes the product, it confirms their belief that they should like the product and now makes them that much more likely to chime in and agree with the person; at the least, it will strengthen their resolve in their choice of product (we happen to be in a fairly crowded marketplace with many competing products).
I think some people are pre-disposed to holding off on recommending products in fear of coming off as “pushing” the product on someone else. Once someone sees that there are many people that share their opinion of the product, it gives them the extra confidence to tell others about your product. They may no longer view it as an inconvenience for those on the receiving end, but actually a favor; something that they should do.
When someone who’s on the fence and hasn’t yet had the “aha” moment, but sees other users profusely claiming their love, it can make them give the product another shot; and maybe this time they’ll push further into the experience willing to put in time to push past obstacles and finally reach the “aha” moment.
Our Slack Community is also a great source of feedback for us. Another bonus is that the feedback is mostly from people who are actively using Tutum. This provides a wealth of information, especially in our #feature-requests channel where we can see the features people want, and which ones when requested, rally support behind them.
I think this is still virgin territory and there are a lot of avenues to pursue to increase the quality and camaraderie of the community. I think with the recent explosion in AMAs (ask me anything), it would be great to bring AMAs of key influencers to our community and later releasing it as a piece of content for all of those that couldn’t make it as well as for those outside of the community.
Also, I haven’t used it too much, but I think private groups could be very powerful. Especially creating a private group for all of your best evangelists and giving them a private outlet to talk to and engage with the company on a more personal level could be interesting.
There are some administrative duties you should carry out right away before you start inviting anyone to your community.
Integrations: make sure you set all of the integrations you want with all of your channels, because anyone can add integrations (and you’re limited to 5 per channel)!
Custom Emoji: our users love using emoji, so we have plenty of emoji related to our ecosystem.
Custom welcome messages: just something small that can put a smile on your users faces when they first login to the community.
Don’t forget to set your Default Channels and change your Messaging Restrictions so only team owners and admins can message @channel/@group/@everyone.
As awesome as Slack is for our entire community, it’s still meant for smaller teams. The 10,000 message limit starts to rear its head more and more often as your user base grows, and there are still limited administrative functions like concealing user’s email addresses from one another. Another big one is the 10,000 person limit. In a recent blog post, I saw an open-source community use Slack and run up against the limit and were told to create multiple Slack Communities and that Slack runs smoothest with only 500 members.
At the time of writing this we’re only at 1,524 people, but I could see us approaching the 10,000 person limit sooner than I’d like, and maybe sooner than Slack will address this issue. An alternative service that’s similar to Slack and that will handle a larger audience is Gitter. It looks like they are focusing on this public chat community demographic, as their free plan has unlimited chat history, unlimited integrations, unlimited public rooms, and unlimited private rooms (limited to 25 users per private room).
Hard to go wrong with that plan, although I’ve only briefly tested Gitter. The appeal of Slack is that it’s the same platform we use at the workplace, so checking on the community is as simple as switching teams and it reduces the cognitive overhead on the whole team when they don’t have to learn another chat platform just for the community.
I’m hoping Slack increase their 10,000 member limit and releases some features for large public communities in the coming months.
An Open Road
I think the options and the opportunities are endless when it comes to forming a community around your product. Slack has proven to be a fantastic tool for us and we’ll continue to explore what it has to offer. I’d love to hear your experiences with creating a community: what tools you’ve used, if you’ve had experience using Slack, and any opportunities you think we’re missing out on. Thanks for reading!