Sign In

Are you using Slack?

Haebom
While Slack is now synonymous with collaboration tools, it actually began as a simple transition from idea to code. The development team already understood the utility of IRC (Internet Relay Chat) and other chat apps, but their challenge was to bring all these features together into an integrated software that any user could easily grasp and use. In the early stages, they aimed to prove that channels, DM (direct messages), file integration, and search made team communication better than email.
Slack 초기 MVP 화면. IRC의 대안을 만들었기에 ZeroIRC나 당시 잘나갔던 IRC의 느낌이 묻어난다.
Slack's MVP was built around three main features: 'channels', 'messages', and 'members'. These were the basics needed to see at a glance what users could read (channels), what the conversation was about (messages), and who was involved (members). A key feature, 'read status', helped users track how much they'd read, making it easy to spot channels with new messages.
Throughout development, the Slack team made active use of user feedback. They introduced the '/feedback' command inside the app so users could easily submit their thoughts. This feedback was vital—it allowed the development team to review and make improvements in real time. This whole process was a key factor that helped Slack grow into a product that truly matched user needs and expectations.
Using insights and user feedback from the early prototypes, Slack worked on improvements like making the message list feel more conversational. They also rolled out the 'unfurls' feature—which shows richer previews when sharing links—to enhance communication. Features for adding files and search were also designed so users could easily share and find information.
Slack's early development process highlights how crucial it is to improve products through user-centric design and constant feedback. Starting with the basic requirements of the earliest prototype, they added and refined features in response to users’ needs and expectations. Through this, Slack evolved from a simple messaging app into a platform that introduces a new paradigm for collaboration and communication. This approach explains why Slack is beloved not just by its initial user group, but by people from a wide range of industries and roles as well.

An MVP should be an MVP.

Below is a chronological overview of the events in Slack's growth story.
Period
Event
February 1, 2013
Slack development began. Stewart Butterfield and his team set out to create a new communication tool to go beyond IRC. 7 people
February 14, 2013
The Slack team built an MVP, stopped using the old IRC, and started using Slack in earnest—the start of dogfooding.
Q2 - Q4 2013
Slack began early alpha testing with other startups and acquaintances. This phase focused on collecting user feedback and improving the product.
February 1, 2014
Slack officially launched. The number of users and team size increased rapidly.
2015~2019
With several investment rounds, the company’s value rose and more than 10,000 companies started using it
2019
Listed on the New York Stock Exchange (valued at about 3 trillion won)
2021
Officially acquired by Salesforce (for around 30 trillion won)
Personally, the most impressive moment was February 14, 2013. In two weeks, the Slack team built a web-based MVP with channels, members, and conversations, and began intense dogfooding. Reportedly, CEO Stewart introduced a rule that anyone who had a conversation anywhere other than Slack would have to pay a $500 fine. (Of course, it was just a joke and no one actually paid.)
💬
Dogfooding
This term might sound a bit unfamiliar, but it’s simply about using a product you made yourself. By doing QA firsthand, you make sure the product is comfortable and hassle-free to use.
The magic of Slack’s growth story is something that anyone interested in IT or working in a startup or tech industry at the time will remember firsthand. In the beginning, there were a lot of products coming out to replace IRC and Skype, but what set Slack apart was how it started with only the essential functions, keeping it simple, and left space for more features to be added later. I was reminded once again that it’s really fine if an MVP is rough or weird. An MVP packed with unnecessary features or built with too much effort isn’t about testing the market or seeing if your hypothesis holds up—it’s just self-satisfaction, nothing more.
Subscribe to 'haebom'
📚 Welcome to Haebom's archives.
---
I post articles related to IT 💻, economy 💰, and humanities 🎭.
If you are curious about my thoughts, perspectives or interests, please subscribe.
haebom@kakao.com
Subscribe