Preparing for launch

It was the fall of 2013.

Barack Obama was President.

Game of Thrones had finished its third season. The red wedding shocked us all.

WeWork was worth $440M, and Uber surpassed unicorn status with an eye-popping $3.7B valuation.

MoviePass let you see as many movies as you wanted in the theatre for $10/month.

Something called bitcoin was beginning to get more attention (from our #bitcoin channel at the time: “It’s going over $200 today. You should pick some up.”)

Blue Bottle Coffee still defaulted to dairy milk.

The financial crisis was in the rearview. Silicon Valley was revving up into its highest gear since the dot-com boom.

Our preview release was going better than we could have hoped. The response to our announcement kept accelerating, with new teams expanding week over week and seats within existing teams continuing to grow rapidly. Very few teams that became active were churning out.

We got an initial round of fainthearted press when we announced the preview release (“Stand aside Yammer, Convo, Socialcast, Hipchat and the rest, and make way for another hopeful in the world of enterprise social networking...”). However, it brought us a wider range of customers than we had reached to that point which helped broaden our customer base. Many were interested in what Stewart Butterfield – quiet in the public eye since shutting down Glitch – was doing next. Stewart used the opportunity to talk about the many ways workplace communication was broken, and why Slack or something like it was inevitable.

We hustled every day to respond to feedback, fix bugs, and add the integrations that our customers requested. At this point our customers were still largely in tech, so our integrations focused on the tools that software teams need: continuous integration tools, support for code repositories, alerts from live systems, log notifications, and so on.

Fortunately, these were also the tools we used, so there was a natural affinity for building them and making sure they worked well. Custom integrations started to take off, as engineers at our customer companies started gluing their own systems into Slack using our public API.

We began noticing teams in media organizations using Slack. Though we had not designed the app with newsrooms in mind, it turned out there was a good deal of overlap between software teams and news teams: heads-down creative work, collaboration across multiple disciplines to shape a finished product, disproportionate impact of a few people working on something, and a simple push to production getting that product into the hands of thousands or millions of people instantly. Our real-time integration with services like Twitter made Slack an incredibly good fit for fast-moving newsrooms parsing the latest reactions and online discussion. 

The Wall of Love

Twitter also became a viral word-of-mouth mechanism about the service, as early users tweeted out their appreciation (and we happily chatted back). This was a major driver of new teams – so much so that we began to collect and post these tweets to our own “Wall of Love” (this was back when you could easily embed tweets on your own website).

We used this as a place to share customer testimonials and social proof of Slack’s utility, but – with his typical knack for turning attention into an opportunity – Stewart conceived it as a place to recruit new people to join the company. Our need for new staff was growing rapidly alongside our new customers.

Welcoming new users

All this momentum only highlighted the amount of work we needed to do before launching to the public. The biggest gap we saw for new teams was the lack of coherent onboarding. For people joining existing teams of self-motivated colleagues things went fairly smoothly. They would join a bustling team and be invited to channels and learn from what others were doing. For those starting cold it could be a confusing mess.

Up until this point, enrollment was semi-manual and time-consuming. We needed to make it self-serve and scalable as we added more teams. We decided to use Slackbot for this purpose. 

Slackbot is a member of every Slack team, and everyone has a DM with Slackbot. We utilized this capability for two things:

1. Help a new user get their profile and preferences set up.
2. Give a new user a place to try things out in private, without fear of embarrassing themselves in front of their colleagues.

Within a few seconds of starting a Slack client for the first time, Slackbot would message you:

You would answer a short interactive script to fill out your profile, add a photo of yourself, and start inviting your colleagues. In the process, you would learn how to send messages, how to upload a file, and how the primary chat view of Slack worked.

People loved this. It felt like someone was there to welcome you into this new tool you were curious about. Someone with a cute little avatar that did its best to get you set up and handle anything it didn’t understand.

This was long before LLMs – Slackbot didn’t have any real smarts behind it other than the list of interactive prompts and fun responses that Myles Grant – backend engineer and all-time highest code contributor to Slack – programmed into it. Myles knew that people like to mess around with automated systems and tried to anticipate most of the things they might do. This resulted in a high number of delightful responses. such as various cheerful replies to pleasantries, and answering "Fuck off" with "Rude!"

Because its purpose was fairly narrow, this worked surprisingly well. You could set up your profile, update your preferences, or look up help about how to use Slack using a man-style `help topic` format: like `help reminders` to learn how to set reminders with the `/remind` command, or `help stars` for information on starring channels and messages for easy access.

Slackbot was weird (still is, to be honest). But it served an important purpose for early users, and as a place to move those users along their journey from trying Slack out to making it a part of their everyday work.

For example, we started all new users with notifications dialed up to the max: a notification for every message in every channel and DM. This was important in order to make sure people got their initial messages. But as a team matured past the first few users, we would prompt the user to switch to our Recommended Settings: a notification for each @mention of your name or each DM. A much more sensible setting for most people. This prompt came, again, from Slackbot. In the early years people became very affectionate toward this little feature. A quirky little R2D2 in your sidebar.

Moving work forward

This effort was a good microcosm of how we worked at the time:

• We saw or users told us about a gap in the product
• Stewart outlined how we would address it, usually in the form of a late night Google Doc
• We would talk it over briefly in-person or on Slack
• We’d build it

If something was more complex or required coordination across parts of the system (in particular, our messaging protocol), Cal would spec it out in a GitHub doc and implement a barebones version in our internal reference client. Then each of us across the message server, backend, API, and clients would plug in our pieces (mostly in our monolith webapp repo). Rinse and repeat.

As with initial prototyping, we were prioritizing our time around product iteration and answering customer needs, rather than drawn-out discussion, planning, or involved specification. The oxygen of user feedback was stoking the flames of our growth too fast to do anything else.

We kept track of assignments in a spreadsheet and – during this buildup toward our public launch – a burndown doc.

Our team, now more than doubled in size from 8 to 18 people, was incredibly efficient at tackling this work. Bugs were most often fixed immediately after discovery. Features were knocked out in days. Our founders led from the front, with Stewart handling all product, marketing, business and press, Cal captaining the engineering efforts, Eric blazing through all the ins and outs of the Slack clients, and Serguei steadily scaling up the messaging backbone of the service.

Everyone was working long hours, but the noisy, exuberant feedback of our early users made it joyful and purposeful. Looking back, this was among the most productive and fun periods of the company’s history.

Money

Stewart and the board had decided on our pricing plan early on: $9 per user per month, later amended to $8 (“because it felt better”). “Less than the cost of a catered lunch for your team, once a month,” Stewart would say to prospective customers.

Up to this point no one had paid for Slack. We needed to build the payment structure and necessary incentives into the service before we could launch our paid tier. We set to work building three interconnecting systems that would become instrumental to our early growth:

1. Fair billing
2. Referrals
3. Credits

Fair billing grew out of Stewart’s perspective on what was ethical to charge for the service. It worked like this: when a company signed up and added a credit card, we would begin charging them for their active members. Active members were determined by having logged into and sent a message on Slack at least once in the last 14 days. If a member of your team stopped using the service, or was manually deactivated, we would credit the team’s account with a prorated amount.

This was unfamiliar to many customers, as most services would charge up front for access (regardless of actual use) or would negotiate bulk prices ahead of time. We wanted to make sure that we only charged our customers for what they used.

This had two implications during this period: 

1. Reduce the commitment for signing up and build trust that we would only charge you if your team was actually using Slack.
2. Our revenue would increase as teams organically began to grow within a company.

Fair billing was based on a simple premise: Slack was valuable to the teams that adopted it, and we could charge money for the value it provided – no schemes or tricks necessary. This sounds like, perhaps, the most obvious lesson one might learn in business school about selling a product.

However, it was a breath of fresh air in an industry that (even in 2013) was struggling with the tradeoffs of growth vs. revenue, malicious data tracking and privacy infringement, and overpriced or user-hostile subscription services. It also spoke to our confidence in the product.

(Fair Billing has survived the many evolutions of the product and company since then and is still applied to teams paying by credit card)

Referrals took the form of a “Give $100, Get $100” program that Stewart conceived late in 2013. Based on the organic word-of-mouth growth we were seeing, we realized that people were keen to share their love of the product. We wanted to further incentivize that with paid referrals.

Each team was given unlimited referral codes. If another team signed up with that code, they would get an instant $100 credit in their account. If they became a paying team (by signing up for our Standard tier), the referrer would in turn get $100 in credit.

Both these systems  – Fair Billing and Referrals – depended on the third: Credits. This was just what it sounds like, “free money” to spend against your Slack bill. We had a number of automated systems to apply credits to a team’s account, including Referrals and an optional post-signup survey for $100.

Our mindset was that credits were essentially free to us as a company – the nominal cost of each user was very low to support – so we also applied them on an ad-hoc basis. We gave them away on a whim to teams that praised us online, sent in a nice note, reported an interesting bug, or experienced distress from an outage. Credits rained down from all sides, and our early customers loved it.

With this last piece of the puzzle in place, and our product refined and ready, we were prepared for our public launch in February 2014.