HR Case Study: How Slack Becomes A Place For Optimal & Fun Work

Slack isn’t merely the fastest-growing SaaS startup in history; it also achieved what seemed impossible in just five short years: making work enjoyable. By extensively testing Slack within its own development team over an extended period, the software development company gained invaluable insights into how people were utilizing its product long before its public release. This foresight provided Slack with a crucial competitive advantage, propelling it to unparalleled levels of success.

Let’s look at:

• How Slack was created out of necessity and allowed the company to pivot from a confused gaming product to a popular, profitable productivity tool.
• How Slack’s understanding of how people used the tool before launching was a major strategic advantage.
• Why building an ecosystem and platform around Slack was such a smart move

To understand how Slack came to be, we need to examine the circumstances surrounding its development.

Slack Case Study: 2009 – 2013 Is The Death of Glitch and the Birth of Slack

Being the fastest-growing startup in history isn’t the only thing that makes Slack unique. Its product development process was unorthodox. Slack was actually born out of a gaming company called Tiny Speck. Butterfield and his team didn’t intentionally set out to create a SaaS product for the workplace. They built a tool for themselves. They only realized their tool’s commercial potential later on.

Video game developers might not seem like the most logical group to make a sticky, engaging communications tool for today’s workplace, but Tiny Speck’s expertise in gaming was a major competitive advantage. Butterfield and his team already knew how to make repetitive tasks fun and engaging, as this is core to the gameplay experience of the MMORPG genre. Making work-based communication fun and engaging would be the secret sauce that made Slack so wildly successful.

In 2009, Flickr co-founder Stewart Butterfield and his company, Tiny Speck, were hard at work on an MMORPG called Glitch.

It’s unclear precisely when and how Butterfield made the decision to pivot from Glitch to what would later become Slack. What we do know for certain is that Tiny Speck began developing Slack in earnest in early 2013. By March, the company had a rough but functioning prototype of Slack that the team began using extensively.

However, while Tiny Speck was using Slack internally for several months, the team using it still consisted of just a handful of people. To keep improving the product, Tiny Speck needed more users. Butterfield and his team started asking around and calling in favors from friends at other companies including rental management software Cozy and music streaming service Rdio.

“We begged and cajoled our friends at other companies to try it out and give us feedback. We had maybe six to ten companies to start with that we found this way”. – Stewart Butterfield

Butterfield quickly realized that although Slack had served his small team well internally, the dynamics and experience of using the product changed dramatically as the teams using the product grew larger. Functionality that worked fine in a small team of three or four became unwieldy among teams of 10 people or more. Butterfield and his team listened to the feedback of the early adopters carefully, tweaking and refining the product as they went.

Many startups focus all their energy on growing as rapidly as possible. By contrast, Slack focused on growing steadily. Each time the company received new feedback on Slack, they would not only address or implement changes based on that feedback, but they also invited more large teams to try the product. This iterative approach to development helped Tiny Speck build a solid product based on how people were actually using it and progressively expand its user base.

There were two factors that made Slack practically irresistible:

• Transparency: Before Slack, there was no way for an employee to see what other people on other teams were working on, besides getting up and walking over to a colleague in another department. Slack changed all that by allowing teams to not only see what they were working on, but to access a lasting record of all communications surrounding projects, teams, and even entire departments.
• Centralization: The second element that made Slack so popular was that it simultaneously centralized communications while insulating users from distractions. Rather than using Slack to chat, Dropbox to share files, and Outlook to send email, users could now rely on Slack for all three of these functions. This eliminated the distraction of switching between multiple programs and limiting notifications to just one app.

Although much of the feedback that Slack evaluated was qualitative, Butterfield and his team didn’t ignore quantitative metrics. It didn’t take long for Butterfield to find his North Star metric: messages sent. 2,000 messages, to be precise. The Slack team knew that it took time for teams to start seeing Slack’s potential value. If users sent a certain number of messages through Slack – a total of 2,000 messages across an entire team – Butterfield and his developers knew with confidence that the team had really put Slack through its paces.

The real revelation, however, was when teams surpassed the 2,000 messages sent threshold, retention skyrocketed.

In 2013, Slack was finally ready for its big reveal. Tiny Speck decided to brand Slack’s beta release as a “preview release” out of concern that the term beta implied the product would be buggy and unstable. Similar to Spotify, Slack opted for an invitation-only growth model. On the first day of Slack’s preview release, 8,000 people requested invitations to Slack. A week later, more than 15,000 people requested access.

Slack’s “preview release” wasn’t a beta. The product was essentially public at that point. They had spent time building Slack behind closed doors and away from prying eyes, giving them space to focus solely on the product. That period of early development was crucial to Slack’s early popularity and incredible initial growth.

Butterfield and his team knew Slack worked before they revealed it to the world, and they already knew a lot about how their customers were using the product. By the time Slack went into its preview release, the company was finally ready to start scaling aggressively.

2014 – 2016: Public Launch, Rapid Growth

Slack had taken its time to develop a strong product behind closed doors. By 2014, time was a luxury Slack could no longer afford if it hoped to maintain the momentum it had established. Slack needed more users – and it would attract them by leveraging the freemium model to expose it to as many people as possible.

Achieving ambitious growth wasn’t as straightforward for Slack as it was for other SaaS companies. Unlike similar products, Slack didn’t just have to convince individual users to try it out – the company had to convince entire teams. To further complicate matters, no two teams have the exact same needs. A feature that might be essential for one team might be completely superfluous to another.

Yet another challenge for Slack was overcoming individual objections. If eight engineers on a nine-person engineering team love Slack, but one lone holdout hates it, it’s highly unlikely that the team will adopt Slack. That critical weakness, combined with the unique pressures of selling Slack to entire teams rather than individuals, necessitated buy-in from everyone on a team. That meant carefully listening to all user feedback to ensure that the product was as useful – and sticky – as possible.

“For most companies, the hard thing is making the product work well enough to convince a single person at a time to switch to it. We have to convince a team, and no two teams are alike.”

Another complication Butterfield and his team faced was how people perceived chat messaging. According to Butterfield, roughly 20-30% of Slack’s users migrated to Slack from another messaging system, such as Campfire or HipChat. The remainder didn’t even see chat and messaging as a distinct category of software. Butterfield knew these users had to be using something to communicate internally, but they didn’t even know they needed a centralized communications system.

This was a significant hurdle for Slack to overcome, but it also represented a huge business opportunity. If Slack could not only create an entirely new category of B2B software but also position itself at the top of this new category, Slack could effectively seize an enormous share of an emerging market before anybody else.

The key to Slack’s rapid, consistent growth was how the company approached adoption. Butterfield and his team were keenly aware of the difficulties in selling a product to teams as opposed to individuals. To combat this, they reduced as much friction as they could from the adoption process by virtually eliminating risk and keeping financial costs to the bare minimum.

If it was popular with a team, Slack’s paid plans were so inexpensive that managers could expense Slack just for their own team, even if the company wasn’t yet ready to adopt Slack at an organizational level. This made it easy for teams to use Slack for free, and there were just enough limitations in the freemium product to make Slack’s paid plans more enticing.

On another hand,  what really sold investors on Slack, was the pace at which the company was converting free users to paid seats. By the time Slack entered its Series D round, Slack had more than 73,000 paying users – an increase of more than 386% in just six months – and more than $1M in monthly recurring revenue.

From the beginning, Slack had listened carefully to its users, evaluating virtually all customer feedback. However, Slack wasn’t just listening to its users about product features. Unlike many startups, Slack already had a small customer experience team of three people working full time at launch to support new users. This wasn’t merely a ploy to increase retention, but another example of how Slack took the time to really nail the user experience to drive growth. 

Slack approached user retention very cleverly in two ways. The first was to encourage user investment in Slack by leveraging the “Hooked Model”. With every action a user takes in Slack, they become more invested in the product. Every message sent, every file uploaded, and every gif response shared drives user buy-in. The more someone uses Slack, the more invested in it they become. This is, in part, what made 2,000 messages sent such a crucial metric early on in Slack’s development. Combine this gradual user buy-in with the intermittent reward of social validation from one’s peers, and Slack becomes increasingly addictive, significantly improving retention.

The second way Slack cleverly managed retention was to avoid gating premium features behind its paid plans. In contrast to other enterprise communications tools, there is almost no meaningful difference between Slack’s freemium tier and its paid product. The only real differences are the number of messages that can be indexed and searched, and how many integrations teams can connect to.

By making the vast majority of Slack’s functionality available to freemium users, Slack becomes significantly more appealing to small- to mid-sized teams interested in trying the product, while Slack’s inexpensive paid tiers made upgrading from freemium to a paid plan almost trivial from a cost perspective.

2016 – Present: Slack Goes Mainstream, Builds a Bot Ecosystem

By 2016, Slack had not only successfully created an entirely new category of software but also positioned itself at the forefront of this emerging market by making a product that delighted users. However, as Butterfield and his team soon learned, even an amazing product will only carry you so far. Everybody loves Slack. When people love something, they copy it.

Recognizing that hitting a saturation point was inevitable, Slack began to devise ways it could drive further growth without relying solely on user growth. In a somewhat ironic twist, it would do this by getting back to its Web 1.0 roots by allowing users to create custom bots, just as hardcore IRC users did back in the early ’90s.

Slack had first experimented with bots shortly after its public launch in 2014. Finding himself in need of a way to take notes for later review, Butterfield began writing a program that would send his own notes as messages to a private channel that only Butterfield could access. This program became Slackbot, one of Slack’s most popular and commonly used functions. Butterfield later said that the idea for Slackbot came from the pet rock featured in Glitch, a friendly, helpful non-player character that offered players hints and tips on how to advance quests and navigate Glitch’s game world.

In hindsight, Slack’s transition from product to platform was inevitable. In 2016, however, the idea of Slack becoming a platform for automated bots was a decidedly risky proposition. On the one hand, Slack was giving users the ability to make Slack more extensible. On the other, this approach relied on people and companies to integrate with and build new products on top of Slack – something that was beyond Slack’s control. Despite the risks, Slack is betting big on its app and bot ecosystem. The company’s Slack Fund, an investment fund managed by Slack and some of the company’s leading investors, has already invested more than $80M to encourage the development of new bots, apps, and Slack integrations.

• 2016: In March, Slack introduces voice calling. In September, Slack is ranked #1 in Forbes’ Cloud 100 list. In October, Slack partners with IBM to apply the cognitive processing of IBM’s machine learning supercomputer Watson to Slack’s collaborative tools and bots, including Slackbot. In December, Slack rolls out video chat.
• 2017: In January, Slack introduces Threaded Messaging, a long-awaited feature that makes it easier to search and contribute to nested conversations across different channels. Later, Slack announced native support for French, German, and Spanish language options. Shortly afterward, Slack introduces cross-company communication, another immensely popular feature.
• 2019: Slack announced its latest innovation – Workflow Builder to automate routine tasks and processes in 2 minutes. Slack’s visually-driven Workflow Builder is a simple way to automate manual, repetitive processes without requiring any coding knowledge at all.

03 Lessons We Can Learn from Slack

Slack may be among the most mythical of Silicon Valley’s already legendary “unicorn startups,” but there are still plenty of lessons entrepreneurs can learn from Slack – without pinning all their hopes on inventing an entirely new category of B2B software.

a/ It’s never too early to focus on your customers

In the race to reach product-market fit or scale as quickly as possible, many startups fail to understand the value and importance of focusing on your customers from Day 1. This laser focus on how customers actually used Slack was fundamental to the company’s rapid initial growth.Take a look at your current product roadmap, then ask yourself the following questions:

Are you getting the information you need from your usage reports? Slack might not have acted on every single piece of feedback it received from early adopters—but it did evaluate almost all the feedback it received when developing its early product. Are you making the most of your usage data? Are you trying to convince users they need the new features you’re building, or are you giving your users what they’ve told you they want?

Is the messaging surrounding your product prescriptive or responsive? Put another way, who’s really driving the development of your product – you, or your users? Early on, Slack spent months really examining how its users were interacting with early builds of the product – and this was after a year or more of the Slack team eating their own dog food. This responsive approach to product development allowed Slack to quickly iterate on user feedback as it grew, which, in turn, allowed it to invite progressively larger teams to try the product as it improved.

b/ Know when to pivot

Imagine if Butterfield and his team had forged ahead with Glitch instead of acknowledging the flaws in their project and moving onto something else. Slack would never have been built, and it’s a toss-up as to whether Butterfield’s company would have survived.If your product is struggling, it’s time to ask yourself some difficult questions.

Are your product’s problems intrinsic or extrinsic? Put another way, is the problem with your product (intrinsic) or a broader factor beyond your control, such as an oversaturated market (extrinsic)? If your product is struggling because of intrinsic difficulties, you have more options, such as an organizational restructure or renewed focus on other aspects of the product. If your product’s problems are extrinsic, however, it might be time to start thinking hard about your next move.

How much of your current project is salvageable? When Tiny Speck shuttered Glitch in 2012, it had already built a functioning prototype of Slack that the company had been using internally. This made the decision to pivot from a failed gaming product to a commercial communications tool much easier. Take a look at your current product. Now let’s say your company is failing. How much – if anything – could be salvaged from your current product? Could any of your product’s more popular features work as standalone products?

c/ Double-down on product

Just as it’s never too early to start thinking about your customers, you should be relentlessly focused on developing the best possible product you can build. Slack didn’t just identify a gaping hole in the market – it also focused on making the very best possible product. Think about your product or service and ask yourself the following questions:

What features of your product do your users really love? For Slack, its extensive range of integrations, its list of commands, and its support for gifs and emoji replies are all beloved by Slack users. Which aspects of your product do you think people would be excited to show their friends? And how can you make these features even better?

Which aspects of your product are good enough to steal? Everybody loves Slack, so it was inevitable that many other companies would ape (or outright steal) features of Slack to incorporate into their own products. Which features of your product are good enough that another company might be tempted to “borrow” your idea? How can you make them even better – and protect yourself from imitators in the future?