Slack has become synonymous with collaboration tools, but its beginnings were simply a journey from idea to code. The team already recognized the utility of the functionality of IRC (Internet Relay Chat) and other chat apps, but their challenge was to build all of this functionality into a unified software that the average user could understand and use. Early development was about proving that channels, DM (direct messaging), file integration, and search were superior to email for team communication.
Slack's MVP consisted of three main features: 'channels', 'messages', and 'members'. These were the basic requirements to be able to see at a glance what users can read (channels), what is being talked about (messages), and who is involved in the conversation (members). In particular, the 'read receipts' feature tracked how far users had read, making it easy to see which channels had new messages.
During the development process, the Slack team actively utilized user feedback. To this end, they introduced the '/feedback' command within the app to make it easy for users to submit feedback. This feedback played a vital role in the development team's ability to review and improve in real time. This process was a crucial factor in Slack's growth into a product that meets users' needs and expectations.
Based on insights and user feedback from early prototypes, Slack has made improvements such as making the message list more conversational. It also introduced the “unfurls” feature, which provides rich visual information when sharing links, to enrich communication. Adding files and searching features have also been designed to make it easier for users to share and find information.
Slack’s early development history demonstrates the importance of improving products through user-centered design and continuous feedback. Starting with the basic requirements of the early prototype, Slack has grown from a simple messaging tool to a platform that presents a new paradigm for collaboration and communication, through adding and improving various features that reflect the needs and expectations of users. This approach explains why Slack is loved by people from various industries and roles beyond its initial user base.
An MVP must be like an MVP.
Below is a chronological summary of events in Slack's growth story.
Period
Case
February 1, 2013
Development of Slack began. Stewart Butterfield and his team set out to develop a new communication tool that would go beyond IRC. 7 people
February 14, 2013
The Slack team creates an MVP, stops using the old IRC, and starts using Slack in earnest. The beginning of dog food.
2Q - 4Q 2013
Slack started getting early alpha testing from other startups and acquaintances. This phase was focused on gathering user feedback and improving the product.
February 1, 2014
Slack officially launched. The number of users and the size of the team grew rapidly.
2015~2019
Increased the value of the company through multiple rounds of investment attraction and exceeded 10,000 companies using it
2019
Listed on the New York Stock Exchange (valued at approximately 3 trillion won)
2021
Officially acquired by Salesforce (acquired for approximately 30 trillion won)
A memorable moment for me was February 14, 2013. The Slack team had a web-based MVP with channels, members, and conversations in two weeks and started eating dog food. At the time, CEO Stewart reportedly made it a rule that anyone who had a conversation anywhere other than Slack would be fined $500. (Of course, it was a joke and no one actually paid it.)
Dog Fooding This term may be a little unfamiliar to some, but it refers to the act of using a product that you have created yourself. The goal is to do QA yourself and make sure that the product is comfortable for you to use.
The story that follows is Slack's magical growth story, so those who have always been interested in the IT field or who were in a startup or IT industry at the time will probably have felt it firsthand. I think the reason Slack did so well, when there were various products that were released to replace IRC and Skype in the beginning, was that it simply included only the necessary features and left out other features so that they could be added. I also realized once again that it doesn't matter if an MVP is sloppy or weird. I think that an MVP that is too hard or has too many features attached is nothing more than self-satisfaction rather than validating the market or seeing if my hypothesis is actually correct.
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. Would you like to be notified when new articles are posted? 🔔 Yes, that means subscribe. haebom@kakao.com
