Slack’s Engineers Reveal Shared Channels and Desktop Rewrite (Full Transcript)

[00:00:00] Speaker 1: Please welcome co-founder and CTO at Slack, Cal Henderson. Good morning.

[00:00:10] Speaker 2: Hi, I'm Cal Henderson, CTO and co-founder of Slack. And I'm thrilled to be here with you all today for the second day of our annual spec conference. You are the core of the Slack community. And you've helped us make really big strides over the past year. We now have more than 1,800 apps in the Slack app directory. And more than 600,000 active developers. And recently we surpassed 12 million highly engaged daily active users using Slack every single day. You've expanded the reach of Slack with exciting new features that you'll hear about today. Such as shared channels and a completely rebuilt desktop app. I'm grateful to the contributions you've all made in helping us reach these milestones. But I'm even more excited about what comes next. Because that's what spec is all about. Spending time with you, our core community, to talk through how we can chart the next phase of our shared progress together. Slack has succeeded in large part because it's an enterprise product but built with a consumer mindset. It means that instead of building it for the CIO, we've been building it with the end user in mind. And from our earliest days, you've really been our partners in realizing that vision. Making Slack a solution that our users truly love. And we know that our users see the most value in Slack when it works hand in hand with all of the other tools that they use to get their work done every day. And you help make that happen. We also know that our users rely on us to continue to improve the product and push into new areas. Delivering bold new solutions to the problems that come up every day. And again, you're helping us make that happen. That's why yesterday we showed you how we're doubling down on our partnership with you. The new Slack app toolkit is all about making the process of building on Slack easier, more seamless, and making it easier for our users to discover and deploy the apps that you build. Today, we'd like to go deeper by pulling back the curtain to show you some of the things that we've been working on building the core of the Slack platform and application. So this morning you're going to hear from three of our engineering teams about some of the most exciting things we've worked on this year. Since Slack is the front end for the apps that you're building and deploying, we need to make sure that it runs as smoothly as possible and as seamlessly as possible for our users. So these talks are designed to show you how we're doing that. First, you'll hear about how we built our new shared channels feature, which allows teams using Slack to communicate with each other between different organizations. Then we'll show you how we've completely rebuilt our Slack desktop and web app, dramatically improving speed and efficiency. And more importantly for some people, enabling dark mode on the desktop. And finally, we'll show you how we're ensuring that new users, new to Slack, get up to speed quickly and start realizing the benefits as soon as they can. So thank you all for your continued partnership and thank you for being here today. And now it's my pleasure to welcome to the stage Mike Demme and Yingyu Sun to walk through building of shared channels. Thank you.

[00:04:01] Speaker 3: Hi, everyone. Welcome to this first session of How Slack Built Slack. To kick us off, we're going to talk about what it took for us to bring shared channels to market. One of the most exciting and transformational features that we've done in the Slack ecosystem in a long time. Because shared channels changes so much of the fabric of how users communicate with each other in channels in Slack, we wanted to share some of how we approach this problem, what some technical implications are of that, and then how this impacts some of you as developers.

[00:04:31] Speaker 4: So hopefully all of you have used Slack before. And since you're here, I would even guess that you might have even built some apps on top of Slack. So you're probably not too surprised to know that Slack was originally built to be a collaboration hub with all of the tools you need to get work done within your company. We saw more and more people start using Slack. And more importantly, as the network of companies using Slack for internal work grew, we saw a lot of value in allowing different companies to work together in one channel. So we started building on this idea of shared channels. A shared channel is a channel that connects two different organizations. They're a better way to use Slack to get work done with people outside of your company. Now shared channels look and work the same way regular channels do. They show up in your Slack workspace, under the channel browsers, and you can send messages, upload files, all as expected. This means that now, a team from Acme Incorporated can create a shared channel with their external partners at Global News Incorporated and start working together on their next big project, send messages, updates, loop and write people from their company, and make decisions all from the same place in Slack. About a month ago, we released shared channels out of the beta. Yeah, super exciting. And they're now available to customers on all paid plans. So if you were ever wishing that there was a way to get work done with your external partners, now you can create a shared channel with them and get right to work on your next big launch. Now to most users, shared channels look the same way and work the same way that a regular channel does, but there is a lot of work that we had to do to make that experience possible and to make shared channels a reality. So today, we want to start by talking about what Slack was like before shared channels. Then, we're going to talk about some of the technical decisions we made building it and the implications that those decisions left behind. And finally, we're going to share what shared channels mean for you as a developer.

[00:06:41] Speaker 3: So before we get into how we built shared channels specifically, we wanted to take a quick overview of how Slack works at a high level. This is a simplified architectural diagram of the Slack system. Our clients, both web and mobile, interact with our back-end systems using two different flavors of APIs. Our web-based request-response API and a WebSocket-based real-time push system. As an example, when a client sends a message in Slack, sorry, when a user sends a message in Slack, it sends a web request to our back-end systems that process that request by storing the message in our database, enqueuing a job for asynchronous processing of things like push notifications, resolving links into unfurled messages, indexing for search, and other things like that, and then sends a request to our real-time message server system that is responsible for fanning that message out to all connected clients in real time, which is how that message shows up on all the different clients nearly instantaneously. Now, from the earliest days of building the Slack system, we organized all of these product features around a concept called a workspace, formerly called Teams. Workspaces are the container for all different objects in a Slack system. Users belong to a workspace, channels exist in a workspace, and messages in those channels are in the workspace, and emojis, and apps, and files, everything was contained inside this concept of a workspace. And this was a great organizing principle for us to build our clients and our servers around in order to scale and build the Slack system. And as we built more and more on top of this concept of a workspace, it became more and more deeply embedded in all of our code and all of our systems. Anyone who's interacted with our APIs might have seen a team ID or two in an API response, because this was a principle around which we've organized all the different concepts to segment users, to make sure that users from one company could not access channels from another company, and furthermore, it was the way that we built our scale-out backend systems to be able to onboard more and more customers. As one example, our database servers were organized horizontally in a way that when new customers onboarded to Slack, that team or workspace would be assigned a particular database shard at startup time. That meant that as we brought more and more customers onto the system, we could add additional database servers and send those new customers' traffic to those servers, allowing us to support Slack's growth over the time since the company has been around. This was a great way for us to simply and effectively manage both security and privacy and scale-out for performance. However, it was fundamentally incompatible with this idea of sharing a channel. We had built the whole system around the idea that a user from one workspace could not access a channel from another workspace and had a bunch of simplifying principles around finding data related to that workspace, but for shared channels, we needed to rethink all of that. So, let's take the example of two entrepreneurs that want to work together on a big launch project and we want to build a channel between them. The simplest thing we could have done was keep the workspace model in place with a rigid boundary between them and find some way to just copy the content back and forth. This would have been nice for some things. We wouldn't have had to revisit all of these assumptions that we had before, but there are downsides. As all of you probably know, using Slack is more than just sending a stream of messages. Users can edit messages, add reactions, spin off threads, upload files. The content of a Slack channel is very dynamic and we wanted that to appear simultaneously in real time for all connected parties regardless of team. So, doing that with two sets of message history would have been challenging for us to maintain the performance and the experience that we expect from a Slack channel. And furthermore, although shared channels today are restricted to collaboration between two organizations, you can imagine a future in which 10, 100, maybe 1,000 different organizations could collaborate in the same channel. If we had gone with the approach of keeping the rigid workspace boundary, we would never have been able to build upon this fabric for future, more interesting types of collaboration.

[00:10:48] Speaker 1: And so instead, we took the more difficult

[00:10:50] Speaker 3: but ultimately more scalable and better experience approach of having one single channel that was accessed by users from different companies in different workspaces. This means that no matter how many organizations eventually can collaborate in the same channel, there's one set of message history, one common thread of real-time events going over to the connected clients, and so we could get that experience that we want, supporting the future scalability and get the behaviors to work in the way that we expected. However, that meant that we had to go through all of the code that handled channel privacy checks and say that instead of just blocking a user from one workspace from accessing all content from any other workspace, we had to make that a little more nuanced to say that that user might be able to access that channel if it's a shared channel between their two workspaces. And furthermore, we wanted to make shared channels have the same contents but have certain attributes that were different depending on the different sides. For example, the two different workspaces can set different names for the channel for how it shows up on their sides. They can set different privacy types. It might be public on one side or private on the other. So we had to evolve our systems to be even more nuanced. Not only did we allow this user to access this channel from a different workspace, but we had to make sure that we applied the right privacy checks, show it with the right name, make sure that the history is synchronized. All of that required us to go through and rethink a lot of the assumptions that we had built the system upon. And so all of the systems in this architecture diagram had to adapt for shared channels. Everything from our clients down to our databases now had to be aware of the fact that this nice, tidy principle of a workspace that we had built everything upon now needed to be nuanced a little bit to allow some cross-workspace collaboration and bring this exciting feature. Now we're going to expand on this a little bit deeper as Ian goes into two of these aspects in more depth. First, how we implemented channel privacy so that different sides of a collaboration in a shared channel might have different privacy controls. And then what we can see from the standpoint of which users can access other users in the Slack system and how some of the concepts of user visibility also needed to be expanded for shared channels. Thanks, Mike.

[00:13:02] Speaker 4: Let's start by looking at channel privacy. Before shared channels, we had a really rigid distinction between public channels and private channels, which we called groups at the time. And so because they were these two separate objects, they had different ID prefixes. You can see C for channels and G for groups. They were stored in separate database tables and they used different APIs. You might be familiar with the channels and groups APIs. And this was good for a couple of reasons at the time. We were guaranteed no mix of data between public and private channels and it was easy to tell what the privacy type was just by looking at the ID encoding.

[00:13:39] Speaker 1: Now with shared channels,

[00:13:41] Speaker 4: Mike mentioned that we wanted to allow each workspace in the shared channel to pick whether that channel would be public or private. We also wanted to allow them to choose different channel names, topics, and purposes. But since we made this technical decision to have one channel object, we needed to find some way to allow the same channel to appear as both public and private. Our solution was to have all shared channels use the same ID encoding and store them in the same database table, regardless of its privacy. And since we have one channel with one ID, we can no longer just look at the ID to determine whether it was public or private. Instead, we added the IsPrivate field to the channel object and in the same way, the workspaces can modify the channel name, topic, and purpose by looking at that channel object.

[00:14:32] Speaker 1: And these changes were part of our larger goal

[00:14:34] Speaker 4: to make everything in Slack a channel. And since channels are the fundamental fabric of how Slack works, we needed to make sure that these changes wouldn't break for existing clients and for the existing apps that you've built. So we introduced the Conversations API to replace the previous channels and groups API endpoints and it acts as a wrapper that can take in any channel-like object and process it appropriately.

[00:15:00] Speaker 1: The next technical challenge

[00:15:02] Speaker 4: we faced with shared channels was the issue of user visibility, which refers to how and when users can interact with members of other organizations. Now, before shared channels, we knew that you were only interacting with members of the same organization. So let's take, for example, Mike and I are in the same Slack instance as our CEO, Stuart, and he sends me a DM and it contains an at mention of Stuart's name. You'll expect that when I click on Mike's profile and when I click on Stuart's at mention, I see the same type of profile. I can see their full profile with their name, avatar, or presence. I can also message and call them because we're all in the same organization. However, shared channels allow you to interact with members of other organizations, and so we call those external users. Now we needed some set of rules to determine when and how you can interact with them. And so user visibility needed to extend in two ways. First, we should be able to see members of other organizations in your shared channel. And second, we needed to figure out what happened to members of other organizations in your shared channel. Let's take an example. Imagine Project Slack Corp is a shared channel between Slack and one of Slack's vendors. Mike and Ann from the vendor are in the shared channel together, but Stuart isn't. And let's say Mike again sends a message that has an at mention of Stuart's name. You'll remember that I was able to call and message Stuart because we were in the same organization, but this isn't the same case for Ann. She's not in the same directory to an external organization. So instead, she sees a stranger profile. So we introduced the concept of a stranger, which is a minimum user profile that you can see but not necessarily interact with. So you'll see when she clicks on Mike's name, she sees an external user profile with fewer fields than the usual one that you're used to seeing, but still the ability to call and message because they're in a shared channel together. And then she goes up as a stranger profile with some of the same fields like the name and the avatar, but no way to interact with them because they're not in a shared channel together. So these changes led to some changes to our users info API call. Now before, we just checked if two users were part of the same team. Now we have to go one step further and check if two users might be in a shared channel together. And if so,

[00:17:41] Speaker 1: then we have to go one step further

[00:17:43] Speaker 4: and check if two users aren't in a channel together. We'd also have to check if their two organizations might share a channel, in which case we return a stranger profile. And we added the is stranger field to the user object to show that. So you can see that the way we decided to build shared channels with a single channel object combined with some of our product decisions led to a lot of technical changes beyond just how our database model worked and how the user objects looked. It also changed how our edge cache service sent that user information to clients and it also introduced some interesting scalability issues as we start loading

[00:18:27] Speaker 1: several hundreds of external users on your Slack workspace.

[00:18:31] Speaker 3: So we've gone through a few of what it took for us to build shared channels, some of the approaches that we considered and some of the technical implications of those approaches. So let's start with the developer community. The first thing we want to say is that shared channels are here to stay. During our limited beta period, over 20,000 organizations created and actively used shared channels and that number has continued to go up day after day. And so we're really excited to build upon this as the future for the way companies can get work done between them using Slack. And as was mentioned during yesterday's keynote, shared channels are also a great way to build on the fact that when I run a shared channel in which an app is in active use by members from a different organization, I can see that app as it's actually used in the wild and then that gives me a little bit

[00:19:25] Speaker 1: of an insight and intuition

[00:19:27] Speaker 3: to get that app installed on my own workspace. And so we want all of you to build for shared channels. There's so many exciting opportunities and ways that apps can be built to enhance the experience of sharing shared channels. This does mean a little bit of technical complexity. You should make sure that you're using the Conversations API, as Ying mentioned before. If you're not yet, please do that. But also be prepared that you might see users from other organizations and how your app is going to handle

[00:20:03] Speaker 1: the fact that some users

[00:20:05] Speaker 3: might be part of the team or workspace that owns the channel and others might be in this room that you can talk to. People also go to slack.com slash shared channels. We have a bunch more information about it. We're really excited to have brought shared channels to market and to see what all of you can build. Thanks so much for listening. I'd now like to introduce Johnny Rogers and Mark Christian

[00:20:30] Speaker 1: to talk about how they've rebuilt Slack for the desktop. Hey, everyone. It's great to be here with you today. This past summer, we released a faster,

[00:20:42] Speaker 5: more efficient version of Slack for the desktop. Two of us are representing an amazing team of people who helped bring our new

[00:20:52] Speaker 1: desktop client to life.

[00:20:54] Speaker 6: We're excited to share a bit about how we did it

[00:20:58] Speaker 1: and some lessons that we learned

[00:21:00] Speaker 6: along the way. Building Slack for the desktop experience is foundational to everything that we build. Almost all of our users use Slack on the desktop alongside their mobile device. Of course, it's also essential to how your users experience the apps that you build for Slack. Since our clients are the front end for the apps that you build for our customers and teams, we want to make sure they run as smoothly and efficiently as possible.

[00:21:29] Speaker 1: A few years ago,

[00:21:31] Speaker 6: we wanted Slack to be faster to boot, switch channels, and perform common tasks like making calls. We also wanted Slack to run much more efficiently, especially for users who are

[00:21:45] Speaker 1: signed into multiple workspaces.

[00:21:47] Speaker 6: And we wanted to modernize our tech stack and take advantage

[00:21:51] Speaker 1: of up-to-date software development

[00:21:53] Speaker 6: techniques. As everyone here probably knows, software rewrites of existing software are hard. It takes a lot of time and energy. We wanted to share a bit about our thought process of deciding that we needed

[00:22:09] Speaker 1: to do a rewrite and then

[00:22:11] Speaker 6: how we pulled it off. So a lot has changed since we started building Slack back in 2013. We originally built the product with teams of dozens or maybe hundreds of people in mind, not the tens of thousands or hundreds of thousands who are using it today. We're moving fast and finding product market fit. And of course, web technologies have changed dramatically in the last six or seven years. At the time, we chose tools like jQuery, signals, and handlebars as some of our core technologies,

[00:22:51] Speaker 1: not tools that you would use today.

[00:22:54] Speaker 6: Any web developers in the house use jQuery in anger? From 2014 to 2016, the scale of our customers rose rapidly, both in the number and size of those customers. We introduced the enterprise grid tier, which pushed the size of Slack teams much larger than we originally anticipated. And all the while, we were adding new platform and product features to help improve the product experience. So in other words, we were rapidly adding

[00:23:25] Speaker 1: a lot of new complexity to the desktop experience

[00:23:28] Speaker 6: that we were building. And we realized that something had to give. By about 2017, we realized that we needed to make sort of a fundamental reinvestment in the desktop architecture. There were some assumptions baked into the client experience that were hard to change incrementally, that we needed to change in a more dramatic fashion. We recognized definitely that rewrites are hard and, like I said, prone to failure. And we thought we could succeed if we spent enough time up front planning and thinking through and doing R&D to set

[00:23:55] Speaker 1: ourselves up for success.

[00:23:57] Speaker 6: So we started out by writing an overall architectural plan. We spent about three months, and we started with the big ideas and worked our way down into the finer technical details. We tried to answer as many questions as possible, recognizing the time that we spent up front would save us time down the road. It resulted in a 15-page document that we could pass around to the company. In addition to answering the key technical questions, it gave an idea of the sort of scope of the effort and allowed our team and our executive stakeholders to align on the investment needed to pull it off. In this technical plan, we identified our three big ideas. These were the major improvements that would make the whole project worthwhile. We wanted to have a data-driven UI built into React, an incomplete, lazy-loaded data model, and all workspaces in a single web renderer process. So let's take a look at the architecture to dig into each of those big ideas. So here you see the old client on the left and the new client on the right. The biggest things to notice are that in the old client, we had one renderer per workspace, so each team that you signed into, each running in its own copy of the app, whereas in the new client, all the workspaces run in one renderer with just a separate datastore for each workspace. Additionally, in the old client, UI was kept up to date manually with signals and manual DOM updates.

[00:25:23] Speaker 1: In the new client, all

[00:25:24] Speaker 6: UI is built in React and driven directly by data changes in Redux. So that's all workspaces running in a single web renderer and data-driven React UI, two of the big ideas. The third one was a lazy-loaded, incomplete data model. So in the original Slack client, all the data you needed for your workspace was loaded at boot time, big boot payload, and we kept that data up to date with events over the WebSocket.

[00:25:51] Speaker 1: Over the past several

[00:25:52] Speaker 6: years, we've been eliminating that pattern, and in the new client, we were able to assume that all data would be incomplete. Now we fetch data on demand as it's needed by the user's actions, and then we let that data go stale if the user isn't looking at it anymore. This decreases memory usage, network transfer, and overall load on the client and Slack servers, resulting in a faster user experience. So we had our big idea and our architecture planned out, but getting the technology part of a rewrite figured out is only one part of the puzzle. A big lesson we learned as we developed our ideas was the importance of storytelling and later of project management. So technical foresight and skill is obviously necessary for a successful software rewrite. However, in the course of a large, cross-functional project, the technical skill required is sort of roughly constant over the duration of the project.

[00:26:49] Speaker 1: We learned instead that

[00:26:50] Speaker 6: the investment you must make in storytelling up front is significant to gain alignment and momentum. We had to answer the why question for others in our company. Why this project? Why this architecture? And why now? It's always a tradeoff against other things you

[00:27:05] Speaker 1: might do, right?

[00:27:07] Speaker 6: As the project gained traction, the need for storytelling decreased. People understood why we were doing the project. Instead, the investment needed for effective project management scaled up, peaking near release. This was our way of answering the how question, how to build, coordinate, and ship our new client to the world. So thanks to our storytelling, we got buy-in from leadership, and it was time to build a team. We needed two types of engineers, architecture experts who understood these big ideas and how the new client architecture would hold

[00:27:38] Speaker 1: together, and product

[00:27:39] Speaker 6: experts who knew how all the many user-facing features should work. Finally, we needed a strong core of managers to help coordinate and set the pace over the course of a long-term project. So all told, we had about 30 people working on the project at its peak. So this photo, my favorite of the summer, always makes me smile. This is our team celebrating the final sprint of our project on a boat in our office in Vancouver last June. These people represent a big cross-section of our different project engineering groups, and when we finished our rewrite, many of these folks went back to their original product teams, taking back applied knowledge of how the new client worked as long as well as a healthy new set of interpersonal connections to others in the company. Doing this project made Slack engineering stronger. Mark's now going to talk about how we executed and delivered our new client to the world.

[00:28:34] Speaker 5: Thanks, Johnny. So our team had about 30 people on it. That's a lot of brains to put to work, and a lot of hands to put onto keyboards. Whatever we did, we needed to make sure that we broke the work into manageable pieces. So we subscribed to the pickle jar theory of project management. Let's imagine that our schedule is a pickle jar, and we have a bunch of pebbles and rocks that we want to put in the jar. If we put the pebbles in first, then we won't have room for the big rocks to fit. But if we put the big rocks in first, then the pebbles fit in no problem. The same idea works with engineering projects. Given a finite amount of time, or a jar, identify the big items first. Make sure those most important things are complete at the right time, and then you can fit the smaller work around those big items. We identified two types of work. The big rocks were new infrastructure or complex features, things that other things would be built on top of. Most of these were big enough to have a design doc that we passed around and commented on. Our pebbles were uncontroversial pieces of work that just had to get done, rebuilding parts of the UI in React and that sort of thing. For us, most of the big rocks mapped pretty closely to the big ideas from earlier. These were the important concepts that were fundamental to this rewrite and made it worth doing in the first place. These were enabling the React user interface, loading the data on demand, and squeezing multiple workspaces into a single process. Our key strategy as we went was to release our work incrementally. It's one of the ways we avoided some of the pitfalls of big rewrites. Since our new code lived in the same Git repository as our old code, we could share parts of them together. We put strict rules in place to make sure that the new client could only use the new code, but we made it possible for the old client to use that new code, too. There wasn't much to share at first, but we still shared it where we could. What this meant was that over time, more and more of the old client was actually being built using the new code. We couldn't get all the benefits of the new architecture, but at least we could share the implementation. By the time the new client was ready to go, a big part of the old client was already built using that new code. Come release day, there was a relatively small amount of totally new code being released to our users. And since we had minimized user-facing changes in the new client, many of our users didn't even notice. They just woke up one day and had a version of Slack that worked better. So how did we do? Let's go back to the original goals that we set out for ourselves. We made significant performance improvements, reducing boot time by a third, or even faster for some people. And we also thought about this famous tweet a lot while we were rolling things out. The new client uses about one-third less memory on average, which really adds up when you imagine all the people around the world using Slack every day. We saved enough RAM for 483 billion moon landings. In particular, we dramatically reduced memory usage for people who are signed into more than one workspace. Before, the more workspaces, the worse it got. The new client is a lot more consistent. This slide always makes me smile.

[00:32:14] Speaker 1: Finally, we also managed to build a modern tech

[00:32:16] Speaker 5: stack for our internal developers. Using modern JavaScript with React for the user interface and Redux for the data model is a very reasonable contemporary architecture for an app like ours. This new stack is faster, both for our users and for our team.

[00:32:33] Speaker 1: This has enabled some exciting new features.

[00:32:36] Speaker 5: For example, just a month after our shiny new client was released, we were able to build a new dark mode, a feature our users have been asking about for years.

[00:32:51] Speaker 1: So the future is bright,

[00:32:52] Speaker 5: or dark, depending on personal preference.

[00:32:57] Speaker 1: We learned a lot over the course of this project.

[00:33:00] Speaker 5: First of all, rewrites are about more than code. Figuring out your big rocks ahead of time means that you can tell a story, and that's how you're going to get buy-in and come up with a plan. Finally, and most importantly, elevate the people on your team, because they're the ones who are going to bring your project to life. Sometimes projects require

[00:33:18] Speaker 1: monumental technical changes to be successful.

[00:33:21] Speaker 5: Other times, incremental change and refinement is the key to success. I'd like to invite Shivani and Zinzi onto the stage to talk about the experimentation behind how we're helping new users get started. Hello.

[00:33:38] Speaker 1: Hi there. I'm Shivani. And I'm Zinzi. And together, we lead the team at Slack that is

[00:33:44] Speaker 5: focused on helping new users and new teams get

[00:33:47] Speaker 1: up and running on Slack.

[00:33:50] Speaker 7: We're here to help you get started. We're here to help you get started. We're here to help you get started. We're here to help you and your teams get up and running using our product for the very first time. Our mission is to make sure that every team is successful from the very start. That means ensuring that users see the benefits that Slack can bring to their work, so they keep coming back day after day, week after week, and successfully using Slack long-term. Why does this matter to you? It's probably obvious, but more users using Slack means more people discovering the apps you all build on our platform. But it's also a two-way street, because we know that when users discover apps for the first time, it can be one of those real aha moments, where they see the magic of Slack, and they're therefore more likely to keep coming back and really be successful using the product. The thing is, as Slack has grown, the demographic of our users has expanded beyond early adopters. Frankly, Slack users today look a lot less like Slack employees or Slack developers than they did five years ago. Our users now include people across a wide spectrum of job functions, industries, and countries around the world. So how do we go about building a product that works equally well for a developer here in the Bay Area as it does for a salesperson in Tokyo or an accountant in Frankfurt? That's exactly what we're here to talk about. We're going to start by talking about how our team uses a portfolio approach to validate hypotheses we have about what might improve the new user experience. This lets us make sure that the projects that we're working on really have the impact we expected, even when we're building for users who don't look or act like us. Then we're going to talk about how we pull everything together to make bigger bets. And Shivani is going to give you a preview of a feature that we're actually building as we speak. And finally, we're going to talk about how even when we're making those really big bets, we like to break problems down into smaller pieces so that we can both build quickly and build for scale. Let me just start with a few definitions because I'm going to use these terms throughout our talk. There are two ways a user can start to use Slack. They're either the person who creates the Slack workspace. We call these folks creators. Or they're someone who is invited to join an existing workspace. And we call these people joiners. Until this year, our team had really focused on the creator experience. But there are actually ten times as many joiners as there are team creators. And joiners are a little bit of a different audience. These folks are likely to be a little lower intent. They may not know what Slack is about. They just have to use it for work. So we knew there was a lot that we could do to improve the experience for these users. Help them get oriented and help them see the value of Slack right away. Like I said, this was a set of users who we just hadn't really focused on that much before. So how do you go about solving a problem in a totally new space like this? This is where our portfolio approach came into play. We started out with a set of core hypotheses. These were ideas that we had for what might improve the new user experience. These came from analysis, from user research, and from feedback that we hear from users all the time. For example, we thought, let's make the account creation flow simpler. Let's just remove as much friction as possible, get people into the product, and they'll see how cool Slack is and keep using it. We thought, maybe if we helped users download Slack for their smartphones or as an app on their desktop, they'd see how convenient it is to use Slack and they would keep coming back. Or maybe if we just helped them get into conversations faster, if we got them talking with their colleagues, seeing how transformative channels can be as a way to interact, then they'd really see what the magic of Slack was. Then we went about testing these hypotheses by building features and running experiments to see if these features had the impact that we expected. With a portfolio approach, the goal is to build a wide range of features and learn from each of them, rather than making one really big bet right out of the gate. This approach let us figure out which features and which hypotheses actually had an impact on improving the new user experience. And if something worked, we could double down, invest more, and reprioritize the rest of our list based off of that new insight. But if it didn't work, it wasn't that big of a deal because we hadn't spent a ton of cycles on the project and we could move on to the next thing on our list, hoping it would have a bigger impact. So here's an example of a hypothesis that actually turned out to be wrong. Originally we thought it would be super helpful to just make the account creation flow faster. We cut the number of steps in half, from four steps to just two. But what we found is that about the same number of users ended up in Slack at the end of the day. So this just didn't have the impact that we expected. And that was okay because if we had poured a ton of resources into a big bet around this, we would have spent tons of cycles on refining the UI. We would have built this on iOS, on Android, and on desktop. But instead, we'd done this quickly. We'd done a quick experiment just to validate if it had the impact so when it didn't have an impact, it was okay and we could move on. To projects like this one, which did have an impact, it turns out it really is important to get folks into a conversation quickly. So how did we do this? Well, we launched a new feature called new users. This is a new feature that allows new users to send a direct message when they land in Slack. It used to be that when you joined a new team on Slack, you'd start in a direct message conversation with Slack bot. But a few months ago, we changed this behavior so that now new users land directly in a channel. And we encouraged them to send a direct message on their very first day in Slack. And as a result, we saw an increase in the number of users who are coming back to Slack another day and another day and another day after that. So those were a few examples of how we tested these different hypotheses using a portfolio approach to really make sure we're working on what matters for improving the new user experience. All of this work laid the groundwork for some of the bigger bets that we're working on now. Shivani is going to talk to you about how we pulled all of this together into a new joiner onboarding experience called the get started page, which you see here. And this is really a peek behind the curtain. Because as I mentioned, it's something that we're actively developing as we speak.

[00:42:01] Speaker 8: Thank you, Zinzi. So while we launched several individual features successfully, we learned from user research, from our customer support feedback, and from our experiment data that our users wanted and would benefit if we tied everything together into a unified new user onboarding experience. This get started page is Slack's new home base for new users. And it's the first page of its kind in Slack today. There were three things that we learned that our users valued. Above all, users wanted autonomy. From user research, we learned that our participants preferred a dedicated space because it let them choose their level of engagement. It caters also to different learning behaviors. Some people want to go through all the onboarding, some people want to pick and choose, and some people don't want it at all. A dedicated place lets them all do what they want. Second, users wanted to be able to stop and resume learning at their own pace. They expected education to be persistent and easy to find and also return to. With a dedicated space, we offered a lobby concierge for onboarding. It leads you to where you should be, but it disappears when you no longer need it. And third, users want to know why. They look to educational content to understand why they should use Slack. Therefore, the get started page is value focused and not feature focused. When it came to build the get started page, we had to strike a balance between building and defining a perfect modular design and engineering system versus speed of execution. A modular design and engineering system is important. It provides a consistent look and feel for the product for when we continue to iterate or if other teams also want to build a page like this in Slack. It also does provide the building blocks to achieve that high speed of execution, but not at the beginning. The speed of execution is important, specifically in the beginning to get results so that we can get learning sooner. Because for the first release, we need to validate whether we can go deeper and whether this is a good return on investment, just like as Zinzi explained with the portfolio approach. So we had to test that first. So we had to strike a balance between building that perfect modular design and engineering and design system versus speed. And we decided it was best to take an iterative approach. We were still learning what material was going to be on the page that was going to be most valuable to users, and because of this, there was no point to finalize this system for the first release. Here's how our say hello design and engineering components have actually evolved over three iterations for the get started page. As you can see, they're quite different. But with each evolution, we thought of them as one system from a design and engineering standpoint. One more important investment that we made to maximize on our speed of execution was actually building a logging library. This library could be incorporated into the individual front-end components with just a few lines of code that captured an impression when a component is visible in a user's viewport when they scrolled on the page. And this minimized our turnaround time because we could launch an experiment, collect thorough data on how users were interacting with the page, and also analyze the results and determine learnings to iterate for that next version. And now that we've rewritten our client, as you heard from Johnny and Mark, there's more auto logging that we can invest in our client today. So from the engineering side, the get started page can be modified to add, remove, change positions of components on the page, along with all the logging with minimal engineering effort. And we're just at the very beginning. We're going to continue to iterate on what's included in the get started page. So imagine a future how we could use this page to show users how to transfer their day-to-day workflows into Slack, or imagine how we might introduce users to apps to more effectively streamline their work. We know how important apps are. Like Zinzi said, they are integral to users having the aha moment that makes them understand what Slack is really about. And they're more likely to be successful long-term. So what's next? We're working on extending the get started page beyond new users and new teams to also establish teams that are already using Slack, as well as the teams using our enterprise grid product. So that all users, not just new users, get the benefit of our product improvements. For the people that create Slack spaces, we plan to extend the page to provide users a little bit of handholding with some contextual guidance to get them up to speed quickly and to prevent any missteps when they're setting up Slack for others to join. So our key takeaways for de-risking and building a new green field area in a product is to formulate hypotheses and take a portfolio approach to validate them. Go deeper with user research, then invest in areas of opportunity. And third, design for iteration from the start to continue to improve the feature and then extend to ever larger audiences. Thank you. And now I'd like to welcome back Cal to the stage to tell you all about what we have in store for the rest of the day.

[00:47:38] Speaker 2: Thank you, Zinzi and Shivani. So from our onboarding experience to the new desktop app and to the launch recently of shared channels, we're incredibly optimistic about what's next for Slack. We're also really excited about the contributions that all of you can make and all of you will continue to make. And that's why we're working hard to make it easier for you to build on Slack and especially for our users to discover and use your apps. The remainder of day two is going to cover topics in our plan and build tracks. So coming up next in this room for the plan track is a session about delivering continuous improvement to delight your customers. And downstairs in the build track we'll have a session about functional testing for your apps. But please be sure to stick around for this afternoon's closing session featuring Randall Monroe, the author of XKCD. He'll be talking with Slack's very own Anna Picard about creativity, curiosity, and how to tackle big, complex problems. Again, thank you all for being here at spec and thank you for being part of the Slack community. Let's have a great rest of the day.

[00:48:55] Speaker 1: Thank you. . .