Slack: The Seminar: The Review

This is a critique of Slack, as well as a critique of a critique of Slack. Slack is a the popular instant messaging and team communications software launched in 2013 and quickly grown to prominence as one of the fastest growing startup, boasting one million users and a valuation of over a billion US dollars in less than two years since its launch.

Slack also happened to be our first group’s first choice. Had we done this presentation, I believe we would have done things somewhat differently.

One of the more interesting things mentioned during the presentation was the idea that Slack “causes” pain. In other words, to compel free users to upgrade to a paid plan, the software places certain artificial limitations on its functionality that pushes the user to upgrade. Contrast this with having paid features that provides enough additional value to the user such that it pulls them to upgrading.

This is by no means a new tactic. Anyone using software in the ’90-’00s would remember shareware - free software that are free to use and encourages users to share them freely with their peers, but place annoying limitations on their product like nag screens, time limits and locked away features unless the user pony up for a license. The problem with this business model has always been that getting the right mix of usefulness and annoyance - WinRAR being a prominent example of a software which almost nobody ever seems to pay for, yet still somehow making enough money to stay afloat after all this while.

Translating this business model into the web applications throws yet another wrench into the equation. While the marginal cost of each additional free user for shareware is free, that is not the case for web application. This means that each additional user actually becomes part of the costs of running the application, their usage subsidized by paid users. This cost can quickly add up, and it becomes difficult to wean these users off the free service without generating significant backlash. Slack managed to avoid this by being upfront about the limitations, and by targeting the enterprise market, where paying for services is more palatable compared to the consumer market.

As mentioned in the presentation, one of the biggest reason why users love Slack is the large amount of third-party services it integrates into it. This creates a positive feedback loop in that users get more value out of Slack the more time they invest in it by allowing groups and users to customize it for their own individual use case, extending Slack into more than a group communication app. In essence the app changes its nature and behavior to accommodate the need of the user, rather than the other way round. In addition to what the group has mentioned, Slack also provides some small and non-essential, but highly whimsical customization options in the form of custom emojis and loading screen messages. These don’t have real impact on the functionality of the app, but given their highly visible nature, it gives users a sense of ownership of their own rooms and groups.

There was also a smattering of complaints regarding the UI of the notification system, the number of on-screen buttons, and unintuitive privacy controls. While I’m certainly not dismissing these complaints (the snooze button should probably be renamed to mute to avoid confusion, the proposed hamburger menu solution seems unfeasible simply because of the number of items it would have, and the privacy controls should be improved), they seem to miss the forest for the tree.

Think about the problem Slack tries to solve. Back when it was launched in 2013, the question many asked was “why should I use it over IRC/Yammer/MSN Messenger/GChat/Skype?” Slack entered a crowded market, yet came out on top. What sets Slack apart from the other applications on the market was In My Opinion™ first and foremost its usability. In this sense it was very much like Dropbox. Dropbox didn’t strictly speaking do anything new, yet it won over users by simply being easier to use, by lowering the barrier to entry for cloud file storage down to the point where using it is as easy as managing files locally. Slack I believe did the same, creating a simple yet effective means of communication for teams, collapsing multiple communication channels down into one while maintaining a versatile yet easy to use interface.

Something not mentioned in the presentation, but may be of interest is the origins of Slack. Slack began its life as the chat component of Slack Technologies (née Tiny Speck) previous product, a beautiful and original web-based collaborative MMO called Glitch. You can see it on the right of the screenshot here.

While Glitch was revenue positive when it shut down, it was not growing at the rate that the founder, Stewart Butterfield, was hoping it was and was not converting enough of its players into paying customers.

With the benefit of hindsight, we can see clearly why their fates were so different: -

Glitch

• Problem statement: A MMO where people can be nice to each other
• Market: Casual gamers
• Monetization strategy: Optional subscription, cosmetic in-game purchases
• Front-end technology: Flash

Slack

• Problem statement: Group communication suck
• Market: Professionals working in teams
• Monetization strategy: Subscription
• Front-end technology: HTML5

The key difference we see here is that the problem Glitch was trying to solve is not clearly defined, and this reflected in the game itself. It combined features from 2D platformers, social games like Farmville, Harvest Moon-esque farming game, and complex crafting trees from games like Minecraft. This created a game that had a good deal of content, but shallow gameplay, creating an experience that was great for new players, but also one that quickly wears thin. The game was also built on sunseting technology (Flash), and its target market is averse to subscriptions, the way most MMOs monetize.

Compare that to Slack - a product with a laser-like focus on its target market that is reflected in every aspect of its product design and functionality. It came to market just as rich web applications was maturing both technologically and in consumer acceptance. Its target audience was willing and able to paying for the product.

In the end, we can see that no single factor lead to Glitch’s failure or Slack’s success, but rather the product of all of them together. Many of them were also out of the company’s control - the death of Flash on the web, for instance, seemed implausible even in 2009 when the game went into private alpha. The lesson here is to always remain flexible, and to have a clear vision of what the product should be before building it.