A few things to note before you start reading:
Firstly, I wrote this piece almost two years ago but didn’t publish it because I thought it wasn’t very good. But then I read it again yesterday and thought it to be quite well-written! My past self was highly critical and insecure about my writing. I guess my present self has learned a lot about writing like no one is reading.
Secondly, a lot has changed about the enterprise collaboration market since I wrote this. Slack went public and is trying to become an enterprise social network (?) and Teams seems to be crushing it by using the Microsoft sales machine to prevent Slack from getting into the enterprise and investing in their own dev platform.
And to top it all off, Zoom is entering the chat. Like literally. They’re apparently building more robust chat features that will inevitably compete with Slack.
So if you’re looking for a current take, stop reading! I don’t want to waste your time. But if you’re interested in a snapshot of my thinking circa October 2018, go right on ahead. To be fair, I still think classifying Slack apps into Essential, Internal and Ecosystem apps still makes a lot of sense, and the number of companies primarily building for Slack has only grown since I wrote this post.
To build a sustainable moat, Slack is trying to become the connective tissue of the modern workplace. The Slack API is the lynchpin of this strategy.
Slack’s explosive growth over the past 4 years stole market share from HipChat, resulting in Atlasssian shutting down the product and selling it’s IP to Slack in exchange for a stake in the company. Slack is now dominant with a 70% share of the team chat market.
But what got Slack to its leadership position won’t help it stay there. User experience is not sufficient to build a sustainable moat and certainly not one that justifies a $7 billion dollar valuation. The competition is coming at Slack from all sides. On one side, it is threatened by startups like Flock and Chatwork and more established SaaS companies like Zoho looking to expand into team chat with Cliq. They’re competing with Slack primarily on price.
On the enterprise end, it’s competing with Microsoft Teams and Facebook Workplace. Microsoft is pushing Teams by using existing relationships and contracts and by bundling it into Office 365. They’re also likely to come after Slack’s bread and butter – mid market companies, with their deep pockets, larger sales teams and distribution partners.
To their credit, Slack realized this pretty early on, launching the App Directory in 2015, only two years after the company was founded. From the Verge article that reported on this announcement in 2015:
Slack built all of its initial integrations itself, starting with Google Docs, Github, and a bug tracker, among others. The team’s insight then, which helps explain its meteoric rise, is that those integrations fueled all-day usage of Slack. “The more information you pushed into the messaging system, the more people paid attention to it,” says Stewart Butterfield, Slack’s founder and CEO. “It was a virtuous circle. We didn’t realize how strategic it would be as a business deal until after Slack had launched. And then suddenly it was just very obvious — the more apps we get people to install, the more likely they are to keep using Slack.
In the last 3 years, the Slack API has been used by 200,000+ devs to build 1500+ apps in the directory. While increasing usage and retention may have been the goal of enabling third-party integrations in 2015, I think this thesis has changed considerably since then. The Slack API may have started as a growth hack. Today it is a critical component of the company’s product strategy.
Slack has an intensely loyal user base — most employees would revolt if IT tried to take away their Slack. But sustainable and defensible businesses can not be built on product loyalty alone. They are built by products that excel at locking in customers. These products do more and more jobs for their customers over time, gradually absorbing their customers’ workflows and processes. The more bespoke their implementation becomes, the harder it is for them to churn. Conversely, requiring a bespoke implementation for customers to start seeing any value can be a barrier to adoption. The most successful products are therefore easy to adopt, show value immediately after adoption, and can grow into the organization. They get adopted by more people, customized, inserted into more workflows and ultimately become a critical component of their customers’ operations. Salesforce is a prime example of this. It will never win any awards for design, and with the extremely confusing new Lightning experience, probably not for user experience either. But with the Salesforce APIs, the App Exchange and with products for almost every department and vertical, Salesforce excels at increasing lock-in.
Judging the strength of Slack’s lock-in involves taking a look at the types of apps that are being built with the Slack API. I think they can be divided into three broad categories — Essential Apps, Ecosystem Apps and Internal Apps.
Essential Apps
These are integrations with other staples of the workplace like Google Drive, Zendesk, Salesforce, Github and others. A lot of these are built and maintained by Slack itself, driven by that original insight that pulling in information from other systems people use frequently increases their Slack usage. People often spend more time in these apps than they do in Slack. Making Slack the way users collaborate when using these applications ensures that they still use it even when they’re not actively using Slack. Using the Google Drive integration to create and share docs with colleagues and responding to comments ensures that collaboration on documents happens inside Slack. Adding the JIRA or Trello integration to a Slack channel means project management workflows are driven by Slack, which is used to create, discuss and track new tasks. Slack is becoming the collaboration layer for these applications, even though a few of them have native collaboration features, like Salesforce with Chatter. These apps are essential to make Slack the place where work happens.
Ecosystem Apps
The majority of the 1500+ apps in the App Directory belong to this category. These are integrations with products that use Slack’s reach to acquire users and it’s popularity in the workplace to drive usage. Some of these apps are also being built exclusively for Slack. Take Donut for example, a Slack app that helps employees with on-boarding and building stronger personal connections with each other. It’s particularly useful for remote workforces, using Slack to pair up two random employees each week, making up for the lack of serendipitous interactions that take place when everyone is in the same building.
Developers are an extremely creative bunch. By allowing anyone to build an app, Slack is increasing the chances they use Slack APIs as the outlet for their creativity. I can see a future where an app comes along for Slack that is so unique and valuable in the experience it provides, that people install Slack just to be able to use that app. Platforms benefit when they make it possible for third parties to build highly differentiated apps.
It also allows Slack to observe trends in ecosystem app development in great detail. This provides valuable signals regarding what their users want. If Slack sees a certain type of app gaining adoption with users, they can decide to build it as a feature or even acquire a company if its strategically important enough. Hit applications tend to come from out of the blue. Having an ecosystem is essential to participate in this creative process.
Internal Apps
There are likely orders of magnitude more apps running internally within different teams than the 1500+ apps in the App Directory. They can be as simple as a Zapier integration or as complex as a custom built incident management workflow. I think these types of apps tend to have the most lock-in value. They tend to be highly customized and are proof that Slack has become so integral to the operations of a team that they are willing to invest developer resources to build custom software around it. Once in place, these integrations are extremely difficult to displace. Employees get trained to use them and grow accustomed to them. Companies also want to minimize the developer resources they invest on non-revenue generating software. Prioritizing building a replacement, either outside of Slack or on a competitor is always hard to justify. Having custom integrations in each department effectively compounds this lock-in — there’s more people to convince and more code to replace. While Slack hasn’t made any data on the state of internal integrations publicly available, its clear from their latest positioning that they’re emphasizing the value of building internal integrations.
Conclusion
The Slack API allows anybody to build an app for Slack. It has great documentation, tutorials and best practices. Initiatives such as this public roadmap for the Slack platform and a new developer conference are indications that the company is serious about developer relations.
I think Slack has the opportunity to shape the very nature of work. It’s already well on its way to becoming the collaboration center of the modern workplace. The next step is to create an entirely new category of products and experiences for the workplace, one that can only be built and delivered over Slack. I don’t know what this ultimately looks like, but I can see early signs of this. More and more products like Donut and Niles, which adds chats to a team wiki, making it easier to document tribal knowledge, are being built that are (for now) unique to Slack. Locking-in users is ultimately critical because business applications are playing a zero-sum game. Users have a finite number of jobs-to-be-done, and a finite amount of time to do them. Every minute a user spends in Slack is a minute not spent using another product.
Developers are an even more scarce resource than users. Investing in documentation, education and developer relations is the right start, but won’t be sufficient in the long run. Slack needs to provide them with business models to successfully monetize their applications. This is the final piece of the puzzle in my opinion. Allowing developers to build sustainable businesses on top of Slack is critical to making it a true platform.
Dysposition 