Insider's Guide To Building Great Product w/Merci Grace, Slack's First Head of Product

I'm Malin Yen. I'm one of the co-founders of Saastr. Thanks for coming to the Saastr co-selling space. I am so thrilled that Mercy Grace is here to talk to us today. And the background is that one of the questions that I've been getting a lot recently from founders is, How do you scale product, frankly, once the CEO is kind of out of capacity? So after referring about 5 different companies and founders to Mercy, who all raved about her, I decided to gather 100 of our nearest, dearest friends together so that we can talk about it all together and hear from Mercy. So Mercy was employee number 50 at Slack, and she was the first head of product after Stewart Butterfield. So what you may not know is that like all great product people, She majored in fiction writing at USC and was destined for— we got another one there— and was destined for a career in Hollywood with a studio when she had been designing a game because she was a Dungeons Dragons aficionado in her youth. And somebody offered her $500,000 to say, hey, do you want to start a company? It's always that easy, isn't it? And so she launched her first company and her first game, which was the Nether—

did I say it right?

The Nethernet? Nethernet? Nethernet. And apparently it just missed out on being the MMO of the year, but lost to World of Warcraft. Does anyone else here need to look up what MMO was? Am I the only one? Do you know what it is? Okay, everyone else knows.

Good.

Massively— I'm sorry, yeah, massively multiplayer online. That's what it is. So then Mercy went on and focused on engagement and paid conversion at Couchsurfing and Gigwalk before joining Slack in 2015. And so while at Slack, she ran their growth team as director of product and took the company from 500,000 daily active users to over 5 million. That is quite some growth. Congratulations. Okay, so Mercy, you actually met Stewart through the gaming community. And so what— how does it— how does being a game designer translate into a product lead, and how does that influence Stewart? You, and clearly perhaps you and Stewart were two birds of a feather coming from the same background.

Yeah, our shared gaming background, I think, well, that's how I knew Stewart, and then it really helped us think about product in the same way. So the games industry has been doing something called playtesting for a really long time. Has anyone heard that term before? So it's kind of usability testing, except what you're really looking for is the emotional response to the game, because fun is an emotion, you know, having enjoyment of something, having a reaction that the game designer wanted you to have. And great consumer and enterprise products actually elicit the same thing. People don't make purchasing decisions because they have really, you know, logic-ed it out in their mind, even though we'd like to pretend that that's the case. Virtually all decisions that we make are really emotional in nature. And so, a game design background really helped both Stuart and I think about how is someone going to feel when they're using this product.

And in fact, one of the things that I've heard you talk about is feeling or pretending like you're a human being, right? Tell us a little bit about that. Does that come from a game design background, you think?

Yeah, so that's a Stewart Butterfield-ism. So I don't know how many of you are PMs, but one of the most harrowing times of a product manager's life is when you're doing a review with your CEO. So imagine that that CEO is one of the world's best product thinkers. So you come into this product review with Stewart at Slack. I often would be taking him through either a prototype or a deck, and you know that you really mucked up when he turned to you, and this happened to me several times, and he said, "Close your eyes." And you're like, "Oh great, now it's coming. This is great." So you close your eyes, kind of wincing, and he would say, "Pretend you're a human being. Now open your eyes." And he was asking you to look with fresh eyes at the thing that you had just shown him, always because he felt like you had gotten into the persona use case dead land of product design and away from thinking of, who's this real person who's going to use this? Is this providing value for someone in their actual life? Or is this just, I think that I want people to take this action, and not, this is something that people really need to do?

Well, of course, when you closed your eyes and pretended you were a human being, You actually did not pretend you were Mercy Grace.

Right, yeah. Yeah, I had a particular person, this guy Juan, who I would pretend to be because different race, different gender, it's good to sort of put yourself into someone else's body, imagining that I was sort of like a mid-level person at some different company, and I'd had a fight with my wife the night before, and then traffic was really bad, and then I'm sort of rushing in, sitting down my boss who like is a dick. He, you know, he walks by me and he's starting to tell me about like, where's the Harrison file? And so I open up Slack and I'm like, "Where is the Harrison file?" Right? How am I supposed to find it in kind of like this mess that I'm looking at right now? And that's sort of the— deeply influenced by my passion for role-playing games. Let's just have it out that I would build these sort of characters in my mind, and then I created a product process out of this with my team as well, where when we were probably 30 people on the growth team, One of the really difficult things about always working on onboarding is that you need to constantly put yourself in the mind of someone who doesn't know how to use your tool yet. And as you can imagine, Slack Slack is insane, and people use the shit out of it. It's like every power user of Slack actually works at Slack at this point. And so we knew a ton about the product, and it was really hard to put yourself in that beginner's mindset. So these character sheets would be very helpful to people. We'd pair, a designer and an engineer together. They would come up with a company that they were working at, and a circumstance in real life in which we'd heard from users, mostly doing user research, that this is how people came to use Slack. And then they would go through the new user experience that they had built as these new people. And we got incredible insights from doing that. It's sort of like role-playing user research. And the fact that it was people who were cross-functional and we had a very diverse team, I think, also really helped.

And in fact, when you first joined as employee 50, you were brought on primarily to do user experience to start, right, before you ended up broadening and taking over product. So take us back to your joining. Now, you know, 500,000 users is nothing to sneeze at, but tell us a little bit about what you inherited, what you stepped into, what your goals were, and what some of the challenges were, and maybe even some things that were you thought were challenges that weren't the challenges, and things that, you know, shouldn't have been but were?

Yeah, so I think, you know, one of the assumptions that I came into Slack with was that I had been using it as head of product at this company I was at before, so I was like, "Oh, I know all of the features that are in Slack," and I was very wrong about that. I spent the first couple of weeks of my time there, I was hired without there being a team ready for me to inherit, because obviously everything is kind of getting slapped together, So I was hired as the new user experience PM, and that was a role that Stewart and I decided on really because of my games background, that I had built really great onboarding experiences. And there's a whole thing that he really believes in, which is that games are basically onboarding experiences forever until the game is over, because you're always learning something new. So we very much had that similar mindset around games, so he thought I would be a good person to come in and totally revamp onboarding. Most of you probably used the onboarding that existed in 2014, given that founders tend to be early adopters. And it was broken in a lot of ways. And one of the ways I found out it was broken is that I spent the first few weeks just listening to users, both talking to people, but really answering a lot of email on Zendesk. So going through and using that as a way to learn how to use the product, and I would get screenshots from people who had been in the beta group, and people who had been using Slack for 4 or 5 months, and they would, in that screenshot, still have the little throbbers, which were the indicators of somewhere to click, that were a big part of the new user experience that was out at that time. So, I was like, "Oh, shit. No one is seeing these." That's the interesting tension between product and design, is subtlety is beautiful, but the point at which subtlety becomes invisibility is something to keep your eye out for. So these had verged into invisibility, and we were getting these power user screenshots with those in. So I put together a design sprint with the team at Google Ventures, and we built prototypes and tested our existing onboarding against a couple of other ideas. One that Stuart was really into that was beautiful, but I think just too complex, and one that was very simple that ended up being our new onboarding, which then we released and optimized all throughout mostly 2016, which you can see the effect of in our DAU charts.

And how long did that process take with Google Ventures?

The actual thing itself is like a 4-day.

Oh, OK. And then you take all the work and figure out what to do with it.

Yeah.

So when you came on board, there wasn't a team that you inherited. So you did a lot of hiring.

Yeah.

How much hiring did you do? Any tips for how to hire great PMs?

Oh, man. So I think for hiring great PMs, always have them do work. And then I think the other thing is they really need to— PMs, it's such a weird, kind of maladapted role in so many ways, where they're filling in kind of the gaps. And they become a communication and prioritization mechanism for your entire company. So who that person is is incredibly important, and cultural fit really needs to be there. I had hired about half the PMs who worked at Slack at the time that I left, so I don't know, 14 PMs or something like that. User researchers, including the person to manage the team, UI writing, and then I helped out building up the data teams. And one of the things about PMs is that a lot of people feel like they're unqualified to interview PMs, and chances are at a 20-person company, you have 1 or maybe 2 PMs. But giving them a real problem to work on that you actually already have and asking them to solve it, asking them to go broad, show a couple of solutions, and then pick one and defend it, and then say, "Okay, what would you do to build this, and then what would you do after launch?" can reveal a lot of really interesting things, including whatever tools or data they're accustomed to having, especially if they're coming from a larger company, that your small startup just won't have. So people who— this is one of my controversial opinions, as Melon was noting, I have apparently a lot of these. But I have seen just hard fails from people who kind of like have that Silicon Valley passport that you're looking for. Oh, 3 years at Google and then 4 years at Facebook, fantastic. Not for your 20-person startup. That person, especially people from Facebook that I interviewed were often very reluctant to make a decision without data, especially in enterprise when you have low-volume parts of the funnel that are incredibly important, like conversion to paid. And especially for startups, you're just not going to have, there's no such thing as a 5% test. There isn't a 1% test. There's all of your precious potential customers and nothing else. You should be very conscious of protecting their experience and not just sort of flippantly testing things. People who have worked at large companies are often not aware of the amount of tooling that has been built over the last decade for billions of people and really time-tested. Then when they come in and they're asking for all of this data, it's hard for that person, not impossible, but hard for that person to transition to, "Okay, let's just spin up Amplitude or spin up Mixpanel and get some initial data and then I'll run some usability or playtests." sessions or do some customer interviews on my own. And bridging that gap can be really difficult, which is why I think just startup experience is actually one of the key things that you should look for, even if it's not a startup that you necessarily recognize. [Speaker] So you mentioned that you give little problems or tests, right, to people.

Maybe not tests. But do you do that— let's dig out a little bit. When you do that, do you make them do it on the fly there, or do you let them take it home with you?

I let them take it home. Yeah. And then, you know, you're always— I don't know why we do this, but someone in recruiting told me that I should do this. I'm like, I believe you because this is your job. They said, you know, like, you should timebox it, only give them 3 days to do it. But then, you know, people would write in and ask for more time, which we always gave them. And we always set the expectation that, oh, this should only take a few hours. But if someone is really motivated to be at your company, it's okay if they spend 10 hours on it because that's actually a great signal that this is someone who really gives a shit and is really gonna, is a craftsperson who really cares and is gonna put a lot of time into it.

Speaking of user testing, you don't wanna necessarily use your users and give them a bad experience. Some people use outside user testing. I know you have some thoughts about that as well.

Yeah, I think one of, The things that I strongly believe is that first of all, people often are dismissive of qualitative data. They're like, "Oh no, I want quantitative data. That's just qualitative data." But the truth is that the human body is an incredible information processing machine for the data of other people. We have evolved for a very long time to understand what a little shift in tone means, or a little flush of color, or a small a twitch of your eye. User researchers are this incredible resource for you to put as a listening device in front of people who are just spewing information all the time. I think one of the things that people often want to do is to say, "Oh, well, but my sales guys are bringing back information to HQ." But they're not really listening, they're selling. They're listening for the name of the competitor, for the problem that matches the use case, because they have that great line about this feature, which is awesome. That is their job. But it's not their job to just be listening for things that potentially you don't even want to hear. It's incredibly important to work with user research early on. You don't necessarily even have to hire someone full-time to do that. Do it. And then we were talking about things like user testing, and not to hate on that specific company, but I found that resourcing people to participate in these tests is very important. It's important that it's not just like this every person, especially early on. It should be your early core customer. Especially for enterprise companies, it's going to be someone who's pretty specific. It's very worth your time. To go trolling on Reddit and in Facebook groups and on LinkedIn and in places where people who really care about their careers are hanging out. And you would be surprised how people open up. Everyone just wants to be heard. And they'll tell you everything that they've ever thought about their job if you just give them the space and are silent and listen to them.

I'm giving you notice here. In about 2 questions, I'm going to open up for your questions. Get them ready, raise your hand, and we will try and get to as many as we can. I have a couple more questions. What product is not out there that you wish were out there?

For product managers, I really wish that there was something that made this resourcing for user research much easier because that's one of the— are the sort of key blockers that I see. And then I've been doing angel investing, particularly around sort of blue-collar, pink-collar work tools, because I think that something like Slack is going to emerge for pink and blue-collar workers. And then I think that the massive opportunity for that company is going to be in flexibly deploying these workforces into other places. You imagine a future where I'm a sous chef, and I've worked at California Pizza Kitchen, I can probably take on a shift at, you know, a cute little place in the Mission District because I have a good work reputation, I know what I'm doing, I've worked at Starbucks, I can also work at Pete's. For most of the working population, there isn't this sort of work reputation that follows them around to say, "Oh, this is a reasonable person, she's already passed a background check." And businesses of all kinds need flexible work, especially as flexible work becomes just the norm, and you're competing against things like Uber or Lyft, where if someone just puts in more time, they can earn $10,000 a month if they need or want to.

And are there particular areas that you're focusing on with angel investing and/or advising companies?

Yeah, mostly, you know, so things that get into the hands of end users at the end of the day is one of the things that I tend to specialize in, both because of my understanding of product metrics, but also how important the product experience is. Then anything that's a self-service adoption as well.

So, two questions, two more questions. One is, you founded a little group a couple of years ago, or maybe 3 years ago now, called Women in Product.

Yeah.

I think you started it by just posting a LinkedIn post. Is that what happened? Or tell me a little bit about that, but it's grown to over 5,000 women now. Yeah. So what motivated you, and how did you start, and what's the focus, and how might some people get involved?

Yeah, I had been thinking about doing something like that for a while. So before I joined Slack, I had been working as a product manager and a founder for almost 10 years at early-stage startups because I'm a startup kid, and that's also where the outsized returns are, right? If you get in before the B or the C at a company, then you get to be an early employee, which is a life-changing experience. So that was what I was consciously looking for, and I realized that in that time before joining Slack, I had worked with one other female product manager, and I was often the only girl in my company, and I can hang. I literally designed games, which is like a very kind of boy thing to do. And I like D&D, and I like science fiction. I should note that the production company I worked at was Bad Robot, which made Star Wars and Star Trek, so I was like, I've only worked at like really cool companies. But it's a, you know, I often found that I was negotiating this really fine line with the guys that I worked with, where it's like, you know, friendly but not too friendly, assertive but not bitchy, and it's a kind of claustrophobic place to find yourself in. And now, only really in the last 5 years, it's become okay to be a woman, okay to be like out as a woman. So when I was raising money, I often talked to women who were, you know, 10, 15, 20 years older than me, who wanted nothing to do with being a woman. And they would explicitly say to me, "Listen, I'm not going to join the ghetto of women's issues." And now things are different, thank God. And I realized that there wasn't any sort of place for me to find other female product managers. And I also had kind of an open question for myself because I'd worked with so few women in product. I was like, "How many of us are there?" Is this really the kind of outlier that I think that it is? So I invited, I started a Slack group, which I got a Slack group for free at Slack, which was a nice employee benefit, and I invited a few people, and then actually, this guy on Twitter, men on Twitter can be helpful, suggested to me that I write a blog post and put up an application and everything, and I was like, okay, that's a great idea, thank you, I will do that. So I did that, shout out to that guy, and then people just, started hearing about it and really flooding in. So now there's 5,000 people all over the world, some really fire channels.

You guys have conferences, you have gatherings.

Yeah, there's a different group who started a nonprofit around the same idea and started a conference, which I've never been to, but seems very cool.

Great. So I'm going to save my final question for a little bit later. So we're going to go ahead and open it up for questions for about 15 to 20 minutes. Do we have any questions? I see one over there. Actually, do you mind speaking into the microphone? Thank you.

Whew. That was close.

Thank you for your insightful talk. If you're trying to develop a product that hopefully by the end has a lot of features, but you have really limited developer resources, how do you go about deciding which features to develop first and allocating your resources so that you're not building product that may or may not be useful to the end user.

One thing, can you introduce yourself and maybe what you do in your company?

Oh, sure. My name's Rebecca. I am the founder at the startup Flowdesk, and we're working on a way to make email marketing super simple for the end user and focus on design and templates rather than on super geeky logic and flows that confuse a lot of people. So we're just trying to simplify a process that's previously been very difficult.

Great. Well, it sounds like you know who your early core customer is, which is, I think, step zero for anything. Having a very clear idea of who's this human being that you're building for and what is their actual life like is really important because you'll keep coming back to that as you are successful or fail to make other features stick. And then I think the other thing for you to consider is before you even think about something like product metrics, the first thing to think about is when someone is using your product, what is that like for them? So if you imagine a woman who is using your product and she's going through it, like, what are the key things that she does in it? And not what are the key things that, like, someday it would be cool, but what is just the absolute nuts and bolts that she would have to be able to do? And then write that out on a list. And then as you are speaking with your early core customers, even in the prototype stage, and this could be— people will respond to anything. It's sometimes shocking. But even drawing out a little wireframe on a paper or whatever and saying, "Oh, what if this did this, and then what would you do next?" and asking a bunch of open-ended questions can be very revealing to you. Because what you're looking for is, what is this core loop that people are going to come in and do over and over and over again? And it's probably just 2 or 3 features. You're going to need more to sell into enterprises and things like that, but ultimately, for Slack, for instance, you come in, you can talk with other people, and you can add files. And there are so many more Slack features than that, but that's the core loop of Slack, right? Cheers.

Hi there, this is a great talk. Thank you. I'm Tim Murray. I'm from the sales side of the software house.

Yeah.

And you had mentioned earlier working with enterprise sales organization. So could you just talk through best practices that you've established and how you've built a strong relationship between product and sales? Because I've seen good, I've seen bad, and it sounds like you've developed really good ways to work amongst these two groups, and I'd just love to hear your thoughts.

Yes, you know, sales always have feedback, which is great because they were often in the types of companies that we weren't in. So Slack is a self-service product, and there's also the enterprise product, enterprise grid product. Those are two different users, and people who work at Slack have very little experience usually, even being the type of person who works at something like IBM or Comcast, very similar job, but the network effects and the way that people socialize with each other and things that they need are hugely different. The other thing that we did was we added in some segmentation and onboarding in order to give our sales team better and better data. Because then they would often go into sort of the C-suite of this larger company and be able to say, "Oh, hey, we'd like to sell you Enterprise Grid. By the way, did you know that you have 100 paid teams at your company already?" And it's just, everything, I think, gets easier when there's that insane amount of product-market fit.

Oh, thanks. My name is Fred Shu. I'm a founder of a company called Squad. We do feedback for feedback insight research for fast fashion apparel brands. So your comment about the onboarding thing was just really fascinating to me because that's what I'm trying to figure out.

Great.

But like you said, you don't have a lot of users. You don't have a lot of testing. Capabilities. Do you have some Cliff Notes for just in terms of process for thinking about onboarding?

I mean, isolating the few things that people really need to know about your product is really important. Oftentimes the onboarding flows that I've seen fail are ones where people are like, "Let me show you everything," and they're like, "Oh, and this thing," and then you're on Step 8. And it's easy to look at someone else doing that and be like, "Noob," you know, but like, we've all been there. You really need to have just 3 things ideally. So people can remember kind of up to like 5 or 6 things, but like, they can, but it's harder. So just make it easy on their brain. And then I think that one of the other Cliff Notes that is something I picked up in games that goes really underappreciated is when you're looking at the screen, mimic what a person is actually doing. We always have these big displays and our high-res computers and our fast connections, and our shit is full screen. No normal person is using your product full screen. They're certainly not scanning around for anything interesting happening. We are very much directed by movement and by our reptilian brain. Another thing is if you have someone in this lower part of the UI and you've given them a hint about, "Oh, this is how you open this menu down here," they will not see something that happens outside of roughly a coffee cup-sized area around it. That's often a case where you're like, "Oh, but I need to show them this part of the UI that's over there." It's like, one, this should make you consider whether if those things are really so interlinked that they should be that far away from each other. Then two, you just need to actually move the person over there, even if it's with some sort of light animation or something like that. People get really zeroed in on actually pretty small areas of the screen, and this is true even for mobile apps.

[Speaker] Can I just follow up, ask one more question? One of the things I'm always thinking about is should we say it, or should we just copy? The most popular app that does that one thing we're trying to do, like let's say upload a photo?

In terms of a UI pattern?

Yeah, in other words, should we say upload a photo, or should we just make it look as much like Instagram as possible? Because then people are just, they're automatically visually triggered. Do you ever?

Yeah, I mean, people definitely try to invent things for the sake of inventing things, which I strongly disagree with. You should just make it, it's like just, It's like, let's not be too clever here. Make it look like upload if that's what it is. It's also good though, oftentimes we think that a glyph is really understandable when it's not. A great thing to do at the beginning when you're still in black and white prototyping stages is to get very specific about the language. And then that's the thing to really hone because people don't read, but people read actually button text and then headlines. Read that shit out loud to yourself, show it to everyone that you know, make sure that it's very, very crisp, and then the rest of the visual design will follow that. But get tight on language first. Yeah.

Thank you. On a related note, what sort of process—

Oh, sorry.

Bernard Sled. I'm here with Voxit in in business development. A related question on the competitive analysis. What sort of processes do you put in place? Microsoft Teams just released a new version. You've got an open source project. And so this is a moving, even though Slack is the most visible, prominent, and best product, it's a moving and dynamic environment. What sort of processes do you put in place to track what's happening and what do you do with that?

Definitely ignoring everything else. That's happening is the best thing to do. Competition can be very distracting, and it's easy to look at someone else and sort of assume that, like, they're more successful than you are, or that the flow that you went through is working for them. So back to the Throbber thing that I took out because it obviously wasn't working. During the few months it took us to develop the new onboarding experience, I saw 5 or 6 products that we're mimicking our onboarding. It's not this one feature you mimic and then it'll be fine, or even your one feature. Products are a whole experience that include sales, they definitely include your support team, they include the language on your website, and that's how real people experience them. So I think I wouldn't pay too much attention to the competition. Someone was recently congratulating me on, "Oh, you guys officially beat HipChat, and we beat HipChat a really long time ago by never caring. And when I joined Slack, I, like a lot of early users, had this irrational love for the product, and I really wanted to be a part of this team that I thought must be so special because they built this incredible thing. And then someone was saying, "Oh, why are you joining them? But look at Flowdock and look at HipChat, and there aren't any features that are different." And in fact, both of those products had more features, and they had things like replies that we would consistently hear from people. But it's not just one thing, and it's certainly very distracting to spend a long time looking at the competition.

Hey, my name is Suraj. I run product at a software company called StellaService, and we do employee success software for call centers. [FOREIGN LANGUAGE] And I'm curious to hear sort of as you have buyers who are making decisions about using your product with their teams versus users who are actually then using it, how you think about prioritizing and building or not building features that you're getting asked for maybe specifically from the enterprise side or from larger businesses that are sort of saying like, well, we need this thing in order to buy. And then building for your users versus your buyers?

Yeah, if you are selling to both enterprise and SMB, then I think just like anything else, nail the hell out of SMB first before you try to scale up into enterprise, because that is actually where the truism of, oh, just follow the end user and don't pay too much attention to what the C-suite is saying that they have to have is really true. People at those giant companies will have already adopted your product, probably, right? Because people who are high performers are always looking for ways to optimize their team, especially something like that. So, you will get to the point when you're selling into the enterprise that you do need certain levels of compliance, you need SAML, you need all of that kind of stuff. And that's a real and immovable but really knowable list of things. But ultimately, if it's not something that's getting ravenously used by a lot of people, then it doesn't matter if you built that stuff, and it can definitely get you ahead of your skis.

Hey, so I'm Sharon. I'm a growth marketer at Varo Money. We're a mobile banking startup. So as you scaled the number of users in the product at Slack, how did you work together with marketing, and it could be product marketing or growth marketing, to do that together? And what were some of the things that were product-specific versus something that you collaborated on?

Yeah, so we, by the time, I guess by this is early 2017, that's when we first really, and kind of late 2016, that's when we first really had a substantial marketing org going. They had done, the existing marketing team had done a bunch of brand marketing, and then the product marketing team helped the product team launch specific features. And then on the growth team, we added a performance marketing team, and then we also had a sort of product marketing team that was focused on email campaigns, and they took over Slack.com as well. And then how we really worked together was we were all part of the growth team together, along with the growth marketers, and one of the most important things that we did was the way that we designed our goals. Was around activated teams. So those are teams that have reached a certain number of users and a certain number of messages within a certain period of time. And we had found sort of end of 2015, early 2016, that if we increased the percentage of teams coming in every day who were hitting that metric, they just stayed. So cohort after cohort, they would retain better, they would convert to paid better. And so we knew that, okay, this is our, like, 7 friends in 7 days or whatever the urban legend about Facebook's metric was. And they were gold on that same metric, so they weren't incented at any time to push in a bunch of people who were not the profile of user and then have us deal with decreased numbers later. And the same thing too for all of the PMs on our team as well, that everyone had the same goal because it's one team. And that's one of the most important things that you can do. I mean, it's a little bit of the game design thing, but think about the behavior that you're incenting, the good behavior and the bad behavior, and you'll actually be able to kind of predict how people will respond with an assistant like that.

Hi.

Hi, my name is Kay. I work at a company called BuildZoom on the product Slack team. My question is, so I, at my company, we use Slack on the desktop. I also have it on my phone. What happens when it comes to feature parity? When you think about a feature that really works on desktop, is there a different mobile team? Do they have to figure out how to work it into the mobile app? How are your teams structured in that sense?

[Speaker] Yeah, so Slack, as you probably have noticed, or maybe not, has really gone for parity on the mobile app. To an extreme is one of the things that I disagreed with. I felt it should be more of an alert inbox and not something that was fully fleshed out. But for the people who like to use Slack almost exclusively on their phone, so people who would otherwise be in email, like executives and VCs and consultants, they're really using it on their phone. I feel like there's a lot of downsides to that, it's much harder to manage everything. But anything that touches the database, anything that touches the core loop, you do need to have parity on. Hi, Martha with Flowdisk here as well. What are some— so for onboarding Specifically, whether it's games or companies, what are some of your top favorite sources of inspiration? Playing games is great. Let me think. Monument Valley is particularly good. It's super simple. Mario games are great. Nintendo has just nailed this time and again. A lot of the Zelda games are also really good. And that is primarily what I push people toward, in part because they do things that you can't directly copy. And so you're less likely to go for, "Oh, let's do this little explainer about the keyboard and just the way that Bitmoji does it, because it seems like it works for them." Because again, you do not know what works for them. And just because something's in the product doesn't mean that it's working.

As an early employee at multiple startups, how do you decide when it's time to leave?

Hmm, when I get bored, I guess. That's when I go. I mean, if the culture becomes toxic or I get bored. That's been historically what I've done. And yeah, yeah, usually when I have something else going on too.