Ask HN: What problem did Slack solve?
Some investors will ask you what problem you're attempting to solve. So I'm curious about Slack. What problem exactly did it solve?
If one answers that with just "workplace chat messaging", Slack looks redundant and unnecessary since the world already had IRC, ICQ, AOL AIM, Yahoo Chat, Skype, etc.
E.g. in the early Facebook years (~2005), Zuckerberg and his team used AOL AIM as their chat system at work because Slack didn't exist. Early Twitter is another example where Jack Dorsey and coworkers used AOL AIM for workplace chat. (Indeed, Jack even said he got inspiration for Twitter from AIM's "away status" feature)
So we have to find the differentiator of Slack that attracted businesses to adopt it instead of just using IRC or Skype:
- Slack lets people subdivide the chat space into "virtual rooms" or "channels" as a 1st-class concept. This is something that the older AOL AIM, Skype, Pidgin client, etc didn't do. This feature is helpful for businesses because you have multiple projects or teams where multiple people collaborate with various subsets of employees. The older chat systems enabled 1-to-1 messaging based on userid but not on "topics" with 1-to-many participants.
- Slack userids are scoped to the company which is more acceptable for private chats within the business. In contrast, the userids in AOL AIM were global ids and therefore not constrained to the particular company's communication. (Slack added ability to chat outside the company recently in 2021: https://www.google.com/search?q=slack+chat+with+other+compan...)
- IRC had topic channels but corporations don't want to hassle with admins setting up internal IRC servers and plain IRC doesn't have desired features such as chat history without additional effort (i.e. IRC bouncer). In contrast, using Slack for workplace chat is just a few clicks in the cloud.
In short, Slack had a combination of some extra useful features and near-zero admin (cloud).
Back in roughly 2015-2016, some of friends were using Slack at their company and were making fun of how antiquated and uncool HipChat was — even though HipChat had all the same functionality. HipChat had the advantage of being a fast, native app, while Slack was a slow Electron wrapper around a web page. But Slack nailed the UX. It had the aesthetics of a generation of "post-Web 2.0" apps that were coming out that were more real-time and shipping as Electron apps. HipChat just looked old school. Pretty soon my company was on Slack, too.
It also helped that Slack quickly got support for a much richer set of integrations with other apps. HipChat had a bunch, but I think Slack realized this would be the number one way to beat the competition, and they spent a ton of effort on building out this side of the platform. Slack, of course, also had the advantage of focus; HipChat was made by Atlassian, who had a lot of different products to spread their focus more thinly.
Around the same time we saw a similar battle between Google Hangouts and "old school" apps like WebEx and GoToMeeting. The latter were/are native apps, rock stable, but fundamentally uncool. Hangouts was browser-based and super flaky, but somehow cool because they were the latest generation of web UX.
What's interesting right now is that Zoom, a thoroughly clunky and uncool native app (very similar to WebEx or GoToMeeting in that sense) has somehow gained enormous market share, despite the existence of decently mature web-based alternatives. Maybe because Google managed to mess up its chat/videoconferencing so badly.
No log-in required — just enter the 10 digit code and your name.
And I think Zoom beat Hangouts because you could invite someone to a meeting and they didn't need to create an account to join.
- Horrible text editor compared to slack (no inline code, no syntax highlighting, lists barely worked, undo barely worked) - notification preferences (per channel) we’re lacking. - no threading support - UI was laggy compared to slack. - there was an very limited set of emojis. - no good mobile app. - few and limited integrations (notably I use GitHub, Jira, and Outlook integrations for slack).
Still hipchat was far better than Teams is today.
Particularly due to the choice of the word "understate."
In my opinion this is very much a double-edged sword. At my organization we have one person (maybe self-appointed) who, when seeing a question asked on a more general channel, invariably responds with something along the lines of “have you checked #super-niche-channel-probably-only-useful-in-this-exact-case?” When I see one of those questions pop up, I usually try to guess the particular sub channel that he’ll try to redirect the asker to but am rarely successful.
But my org may just be using slack wrong. We do have thousands of channels and the same order of magnitude employees. Maybe guidelines about the granularity of channels would be helpful.
Or maybe Slack is just not for me: e-mail is my preferred method for asynchronous comms and I prefer phone calls for synchronous comms because I think the slight friction in having to pick up a phone to make a call helps limit throughout and improves quality of requests. And for info repositories I prefer a curated wiki page to discussion threads for both search and comprehension.
This point is so important.
Some folks seem to think that chat threads can serve properly in this role but in my experience both Slack and MS Teams are nearly useless in the role of "info repository."
I know for sure that AOL[1] and Yahoo [2] had enterprise messaging services available for some time, but I think they had both shut down that option because of lack of uptake before Slack was started or at least before it rose to promenence. I'd guess MSN had that feature too, but I don't specifically remember. Segregated scopes being the only option makes a big difference though, and timing is also important; Yahoo was making cool products and killing them because there wasn't enough traction only for the market to show up later for years before Google made that cool. Startup idea: look through old Yahoo new product press releases for ideas that worked but were before their time; if Google did it years later and abandoned it, then it's been shown that an independent team can build it, so you probably can too.
[1] https://www.crn.com/news/channel-programs/18829405/aol-final... https://www.computerworld.com/article/2564773/aol-phases-out...
[2] https://www.internetnews.com/enterprise/yahoo-extends-im-to-... https://www.cnet.com/tech/services-and-software/yahoo-soups-... https://www.cnet.com/tech/services-and-software/yahoo-scraps...
Sadly I think Slack was largely marketing and timing: federation was nontrivial (unlike email).
First of all, before Slack real-time chat in a company setting was a novel idea. Your sysadmin may have been born in IRC, but non-tech people probably never used it. "Why would you chat online when you can in real life!?"
Setting up a chat was full of hurdles and questions without clear answers. Do you use XMPP? IRC? Which clients, which servers? Back then it was still common to have on-premise physical servers, so spinning up a server there was suddenly a big deal. Bigger companies did not appreciate "going rogue" with potentially sensitive company information they may had obligation to secure and archive. It was a lot of friction for something that people weren't convinced was a good idea in the first place.
Slack made it accessible, polished, and corporate-friendly, at a time when SaaS and web apps were catching on. You didn't need to get people install an XMPP client, which was designed for 1:1 chats and had awful afterthought UI for group chats, with different capabilities in each client on each platform. You didn't need to explain to anybody how to keep an irssi session alive. File transfers worked with pretty drag'n'drop without having to open ports.
There was a Microsoft Linq back then, but it was awful, and it was an ICQ clone, not a group chat.
Fun fact: Slack was salvaged from a group chat feature of a failed MMORPG "Glitch".
Slack led the markets with best execution (maybe?) and good funding. Until Microsoft came around with its own unique non-replicable assets and skills.
AIM, Yahoo, Bloomberg, etc were very commonly used I'm finance before slack.
Never met anyone I worked with well who thought that, even in the 80s (I ran a BBS (on a MSX2 by the way, written in Pascal) to communicate with my teammates and my business partner; he was sales and he loved it). I preferably only ever work with engineers so that might explain something. The real great thing about this day and age is that now you can just demand it from anyone; I have noticed that other roles in the company also prefer it vs 'real life' because there is a record of everything. So 'minutes of meeting' is copy/paste/export instead of writing from your very bad and biased memory; the latter is basically built in for many (especially corporate in my experience) people who insist on calls and face to face; it's easier to fudge the details and deflect blame for failure ('but I told you this when we had this little meeting a couple of weeks ago remember?'). And that happens basically all the time; it's nice that you can just search an archive and say ; 'you said x, we did x, x didn't work, own it please, now back to work'. Only in case of deflection or blaming of course; everyone does stuff, no-one needs to be called out but if someone calls someone out while being wrong, it's good to get the facts.
And also to monitor all communication on it. No more of those pesky P2P-encrypted XMPP messages.
AOL or Microsoft could've owned this space in the 90's... if they thought about it.
Clean & simple Web UI, Drag'n drop file sharing, rich multi-line text, beautiful colors/branding, session & history handling, search functionality etc. are just some of the thing that come to my mind. IRC had no consistent experience, you just needed to know what the best client is and setup bunch of other things.
Functionally Slack might not have offered much over IRC at least for techies, but UX-wise it was a leap forward. It made chats approachable.
And ofc the timing was right.
I was in mIRC for years before, and my company had our own channel on freenode, as did some other tangential companies and OSS projects, but we couldn’t get some less technical people to use those and they didn’t feel confident in privacy on IRC.
Slack solved all that: pretty, private group chat anyone can use.
I guess one other thing about Slack is that I can completely ignore it after work. Like having work inside a single app that is for nothing else. For some godawful reason Go and Kotlin decided to use Slack, but that just means we can safely ignore those places.
Not sure how you could monetize that but hopefully the Slack staff doesn't know either.
We had chat systems before like IRC, Hipchat, Campfire, Flowdock (We have used them all), but with Slack it was the first time I felt a push from other departments to use it.
I'm still sad about the implementation of threads that Slack went with, Flowdock did this much, much better, every new post into a thread were also posted in the channel view but with a unique colour, the interaction can be seen here: https://youtu.be/BxRE5GUbFes
I also liked that Flowdock had the concept of an "inbox", so every channel had their own inbox for integrations that wouldn't post a message and notify everyone, but you could still chat with your team about a certain item in the inbox.
Slack had a mobile client that was exactly as good as the desktop client. That client showed image and document previews.
This means executives, who never have computers but always have phones, could be in chats. Before slack they always called or emailed.
Let's be honest IRC is pretty bad experience.
And clearly there was a place for textual instant communication inside teams and between them. Now just provide easy enough and simple enough UI and setup and you have something to offer.
Although to me holding your chats hostage is unique to Slack afaik and I don't think it has e2e which is a major issue personally but not so much in a corporate setting.
The key problem they tried to solve was to keep distributed teams in sync, according to the above link, and for that it really does work, I think because it has the Channels concept and also because it isn't some "crazy open source hacker thing".
Nothing that IRC doesn't have, but they sold it better.
Google Chat is still my favourite just because it integrates nicely with Google office apps. Teams is pretty buggy. Skype is largely dead. But the killer feature of Google Chat is that you know it is private, whereas you always get the feeling that Slack is not.
Regarding IRC, I don't remember having e.g. threads or reactions. It's difficult to add features like that when the messages don't even have an id.
I think that's really underselling Slack, between threads, attachments, code snippets, reactions, etc.
For example a Slack pattern I've seen multiple times is teams offering an help channel for their internal users, with one thread per question, and using reaction icons to track which have been answered. It works amazingly well even with thousands of users. I like IRC, but I think it would be really chaotic in comparison.
Personally I love IRC, but at the same time I've not used it seriously in many many years. Slack? It has problems, but I've used it daily across multiple companies.
My biggest "win" with Slack is going offline for an hour, or more, a day, to avoid the notification-fatigue.
It is more accessible being in the browser so non-technical people can adopt it more easily.
Yes, they added bells and whistles like threading, emojis, and snippets that made the experience even better.
As an aside, I think slack huddles are superior to every other screensharing method out there. Being able to draw on the screen is a killer feature when collaborating.
2) user experience - IRC existed for decades before Slack and does most of the same functionality, but the UX is cumbersome for your average user. What client do I use? What server do I join? What channels do I join? How do I use /commands? How do I get it on mobile? Slack "just works", you sign in with your work account and everything is there, ready to go.
The problem resolved by Slack is providing an excuse to waste computer resources (RAM, storage, CPU cycles). Reinventing the wheel on Electron (and charging for it) does that admirably.
If you meant functionality, you already had XMPP or other messaging platforms.
It didn’t solve a problem that hadn’t been solved. It’s just that all the existin solutions were quite stale. They provided an up to date solution to replace the old regime.
My use case was to have all events/messages/etc come under the "same roof". To have services tell me of failures, etc in our chat rooms directly.
I'd argue there are better platforms for this, and IRC still does it better depending on what you're after, but that was the idea.
Slack did that for us. Until their idiotic pricing plans came into play.
Almost no one needs synchronous comms in general. Getting work done inevitably requires you to disable notifications or quit the app.
My current theory of synchronous comms is your company should work like a pod of whales, and surface for air together, sync as necessary, then return to the depths for deep work.
So Slack was the tool for developers, with a lock-in effect, and other departments just followed (-> product -> marketing -> sales).
Branded SaaS chat platform with SLAs is also more appealing to business than open standards.
Slack also had SAML, near feature complete web interface, and an easy to swallow onramp cost in 2017.
That said, the Slack vs Microsoft Teams numbers go to show the power of ecosystem integration and a widespread network of existing customers.
The integrations also allow Slack to become a dashboard of sorts. Key external events can be logged in Slack. You don't have to find them, they find you.
Not a Slack fan per se. Just trying to answer the question.
I muted email notifications on the first day and then forgot about it :)
TLDR: Friction around a user having and controlling multiple identities.
In collaboration platforms (email, chat, web sites) the user typically controls and administers the client; crucially and inescapably the user may select a client which conforms to the underlying protocols, and this includes clients which support multiple personas and intermediation of the visibility of those personas to each other.
Utimately, through a variety of self-organizing mechanisms this gives rise to: work and personal email; chat personas; throwaway HN accounts. It also produces its own sorts of frictions / countermeasures: surveillance capitalism / surreptitious device tracking; the tension about work apps installed on personal devices; Uber spying on their competitors' businesses via drivers' phones.
- What problem does this tech solve?
- Whose problem is it actually?
- If there is a problem solved by this tech, what other problems are created?
The main problem here is the expectation of synchronous communication. In email, async is sort of built in - nobody expects my answer 5 seconds after they clicked "Send". With Slack, they get nervous if they have to wait too long.
Slack can be both a tool that gives slack and takes it away. Given its critical mass, the latter seems to be more prevalent given the instant gratification people are expecting.
In my experience, workplace chat apps were either instant message apps with really bad rich text support and no search/file upload support, or document stores like Lotus Notes that were more like internal file storage that you could add comments to.
I think Teams will really win out as it’s IM, collaboration tools, real-time tools, and transcription services are the best IMO.
Paul Graham wrote of it in 2012:
"Email was not designed to be used the way we use it now. Email is not a messaging protocol. It's a todo list. Or rather, my inbox is a todo list, and email is the way things get onto it. But it is a disastrously bad todo list.
I'm open to different types of solutions to this problem, but I suspect that tweaking the inbox is not enough, and that email has to be replaced with a new protocol. This new protocol should be a todo list protocol, not a messaging protocol, although there is a degenerate case where what someone wants you to do is: read the following text.
As a todo list protocol, the new protocol should give more power to the recipient than email does. I want there to be more restrictions on what someone can put on my todo list. And when someone can put something on my todo list, I want them to tell me more about what they want from me. Do they want me to do something beyond just reading some text? How important is it? (There obviously has to be some mechanism to prevent people from saying everything is important.) When does it have to be done?
This is one of those ideas that's like an irresistible force meeting an immovable object. On one hand, entrenched protocols are impossible to replace. On the other, it seems unlikely that people in 100 years will still be living in the same email hell we do now. And if email is going to get replaced eventually, why not now?
If you do it right, you may be able to avoid the usual chicken and egg problem new protocols face, because some of the most powerful people in the world will be among the first to switch to it. They're all at the mercy of email too.
Whatever you build, make it fast. GMail has become painfully slow. If you made something no better than GMail, but fast, that alone would let you start to pull users away from GMail.
GMail is slow because Google can't afford to spend a lot on it. But people will pay for this. I'd have no problem paying $50 a month. Considering how much time I spend in email, it's kind of scary to think how much I'd be justified in paying. At least $1000 a month. If I spend several hours a day reading and writing email, that would be a cheap way to make my life better."
Source: http://www.paulgraham.com/ambitious.html
I think there's a lot of power in the emojis as a callbacks. When you send someone something important, you need all of them to acknowledge the change. But every "Noted" was a waste of attention. Emojis just quickly replace that with almost no overhead.