Lessons from Slack on decision making, product-led growth, and taking big swings | Noah Desai Weiss

The other thing that we talk a lot about to kind of make it less scary by taking these swings is we talk about this idea of getting to the next hill. And the idea there is for any sufficiently large area, it can be really daunting. And what you realize is you don't have that much visibility yet when you're at the very beginning. You don't know what customers will want, what will resonate, what will be frustrating to them, what the market will react to. So I think thinking about how do you literally get to the next hill and then look around and see what the rest of the terrain looks like, and then you can decide how do you want to course correct or calibrate or de-risk in the future. You decompose what could be a multi-year bet into something that, you know, you can incrementally prove along the way in some sense. I think that helps teams get comfortable taking bigger swings because it's not one swing. You get a couple and they hopefully compound on each other.

Welcome to In Depth, a show that surfaces tactical advice founders and startup leaders need to grow their teams, companies and themselves. I'm Brett Berson, a partner at First Round, and we're a venture capital firm that helps startups like Notion, Roblox, Uber, and Square tackle company building firsts. On the In Depth podcast, we share weekly conversations with startup leaders that skip the talking points and go deeper into not just what to do, but how to do it. Learn more and subscribe today at firstround.com.

For today's episode of In Depth, I'm thrilled to be joined by Noah Weiss. Chief Product Officer at Slack. Noah oversees the product team strategy and development and has been instrumental in building Slack into the productivity platform for millions of customers. Over the course of his 7-year tenure, he's run several parts of the product business, leading everything from new product capabilities like Huddles and Clips to running the self-service SMB business. In our conversation, I get the chance to pick Noah's brain on everything from the challenges of scaling a horizontal product like Slack to the most underrated qualities in the people he works with. We start with one of Noah's contrarian takes on data-driven results and why he doesn't view metrics as the end-all be-all for product teams. He continues by walking us through his approach to setting a product strategy and how he weighs the quality of a decision against the quality of an outcome. Noah then breaks down his quality decision-making framework, which involves 3 key tenets: shared context, trust, and risk. We end with why Slack's newest product principle is taking bigger, bolder bets and what that looks like when translated into a product roadmap. There are tons of useful tactics that Noah covers in our conversation today that product leaders can try tomorrow. And now my conversation with Noah.

So maybe to kick things off, I can sort of throw out some different things that pop to mind for me.

The first is, what common product building advice do you disagree the most with?

One of the things that we talk a lot about at Slack, which is very in contrast to my early days at Google, is about not being data-driven with every decision that you make. What we used to actually say early on was data can help solve easy problems, but it doesn't actually solve the hard problems. And hard problems are ones where you can't actually just experiment your way down incremental paths. You actually have to figure out, here's a big swing I want to take. How do you know that's the right swing? It's intuition, it's data informed, it's product sensibility, it's understanding where the market's heading. Those are the really hard strategy problems that I don't think you can just rely on data as a total crutch for. But I think in the field of product, it's become very fashionable to say everything can be empirically answered by data unless you're running everything as an experiment, you're doing it wrong. And I would disagree gently with that.

How does that map to what your product process looks like?

It's a good question. I mean, we were literally having a product review yesterday. We're working on an entirely new kind of user interface and visual design navigation for Slack. And we were talking through a lot of these trade-offs ourselves. And What I think it comes down to is there's certain types of product features that you're working on that are really conducive to experimentation, and then there's a whole class that are not. And so things that are really conducive to it are things where often you're making isolated changes. So smaller changes, like you've got a checkout page and you're trying to consolidate from 4 steps to 2 steps. That's a great place where you can empirically answer, does that increase conversion rate? There's no other things that you're doing. It's one stage in a series. Yeah. And the objective function is very clear. I think conversely, I would say if you're trying to redesign an application, you're trying to future-proof it for where you're going to take things strategically, you can definitely run an experiment and make sure you're not shooting yourself in the foot because you forgot to add a button for inviting people. But you're not going to have a single metric that tells you this design is positive or this design is a failure. Empirical data becomes an input, but as does your product sensibility, Qualitative feedback internally and externally, and then deciding, is this a bet that we want to take? Which is more of a judgment call than a, the experiment came back green or red. So I think if you generalize from that, I would say looking at things where you're making incremental self-contained changes that have a single objective measurement of success, that's great for experimentation. And assuming you have enough scale of usage to actually get significance. But for many types of change, and definitely for most early products, you don't even have the scale to actually be able to say, we ran a test, we're going to run the test for a year before you get statistical significance. You have to use intuition, judgment, strategy a lot more. So it depends is, I guess, the simple answer.

When you think about all the feature work that's going on, in this case at Slack, and the net new builds that are going on at Slack, does the process begin by articulating which bucket that thing falls into, and then there's sort of some consequences of that?

Yeah. What I would say is the kind of beginning of any project begins the same way, which is, what is the problem we're trying to solve for customers, and which customers are we trying to solve that for? The next level is, why do we think this approach would actually help them? And then the third bit, which gets to what you were just saying, is what impact do we expect this to have, whether measurable or immeasurable? And depending on that impact, you can decide, is this something that you can test as a hypothesis or is this something that you're going to have to learn about through other means? I think an unhealthy approach sometimes, and you can see this often with growth teams, is that you become so addicted by the velocity of experimentation that you stop actually thinking about the why behind what you're doing and you more just start thinking, well, we have these 10 pages and we want to constantly try different things, so let's just experiment like crazy. and hope that we get to a better place. I think focusing on the customer change, the why you think it'll matter, then the impact, and then how you're going to measure the impact is the right sequence of things.

So at any given point in time, what percentage of the work that's being done do you think is sort of data-driven or quantitative versus taste or intuition?

Here's what I would say is of smaller feature work, I would say it's probably 75% data-driven where we'll actually run an experiment or run a release with a holdback. For larger, bolder new features that are net new capabilities, I would say it's maybe the inverse. 75% of that is taste-driven. It's maybe informed by data, obviously in many different ways, but it's something that we want to understand whether customers love. We're going to use data to inform that, but we're going to make a more gut intuition strategic decision whether we decide to ship it.

Are there any examples that pop to mind where you flipped sort of your thinking on that? Meaning you sort of thought the work had to be intuition-driven and actually it could be much more data-driven, or something that seemed quite data-driven, but you found the optimal strategy is to lean on judgment?

Good example of the latter, which is that it's probably mid-2020. We had actually done a ton of really great data-driven work to really think about the optimization of that kind of initial new user, new team signup and onboarding funnel. But what we had seen is that we kind of reached a plateau. And this is, I think, often a good sign that you need to stop relying on experimentation and step back, which is that every experiment wasn't really positive or wasn't really negative. It was really just neutral. And it became increasingly hard to figure out what's going on where we can't make any positive or negative effect, which kind of suggests to me that we had reached at least a local optima with the overall kind of end-to-end experience. And so what we wound up doing, kind of understanding that we had reached that plateau, is really taking a step back. And we had this project that we called Day One, where we overhauled the entire first-day experience from the moment you land on the website or the mobile app through creation, onboarding, inviting your first few teammates, getting to that initial conversation. And because that was so many different things we were changing at once, there wasn't a way to decompose this into 20 different experiments, obviously. And it was one of those things where if you think about it, kind of like this mountain range, we were at the top of one hill. We knew there were other bigger hills. We knew that we had to figure out how to leap there because we couldn't kind of walk our way down and back up very easily. And then when we got to this new hill that we landed on, we were like, We're higher up than before, and we see that there's a lot more that we could still climb. And so that then opened up a period where there was a lot more experimentation we could then do incrementally once we got to that new, overhauled baseline experience.

Do you think taste and judgment and intuition can be taught, or PMs either have it or they don't?

I mean, this is maybe my new dad brain thinking, but my honest kind of feeling is that almost everything can be taught. That teaching may be more informal. It may be more observational. Product design, product intuition, I think, is really about seeing what great looks like and being part of the process of creating something that is great over and over and over again, working with lots of different types of people on lots of different teams and lots of different problem spaces to build up that intuition yourself. So I think you can definitely build it 100%. I don't think anyone's innately born with it. I don't know if it's being gifted at music or being tone deaf at music. I don't think that's what product taste or judgment is from what I can see. But I do think it takes repetition. I think it takes getting your hands really dirty, and I think it takes working in a lot of different problem spaces so that you can have that calibration and that kind of creative spark that you can borrow from instead of just being single-threaded in one area for 2 decades.

Could you talk more about that? Let's say someone on your team comes to you and is like, I want to develop my product taste. What specifically would you tell them to do?

It's something I think you learn much better by actually working side by side with folks who have really strong product taste and sensibility and not by reading a lot or taking some classes or I don't know what it might be because it's something that is inherently hands-on and creative. There's a book which is by one of the early Apple engineers, Creative Selection is the name of it. And I think the book is a really, I think, good example of it where you kind of wonder what does the creative process at Apple look like? And what they get into is it's not some magical. Someone walks in over the weekend with an idea, they sketch on the whiteboard, and aha, there is the iPhone fully baked with a keyboard working and everything else. It is an incredibly iterative, painful, messy process. And the only way to build up your creative product ability is to actually get your hands dirty and work with other people who can push you side by side. So going back to the question, I would say to the PM is like, let's make sure that you're on a team with folks who are really good at prototyping, are really creative, who can push your own thinking. And let's get you working on a different problem space if you've been kind of working in the same area for a while to force you to step back and bring fresh eyes to it. And then focus on developing your sense of craft and what great looks like and do that with other people who know what that looks like that you can learn from bit by bit.

How do you think about scaling intuition or judgment across a product org? I think the nice thing about being more metrics-driven is it tends to lend itself to something that can scale relatively well and you can roll it up and down the org. But I think when you start to move into the world of judgment and taste and intuition, there's kind of thorny problems of getting a whole org to kind of move in that direction or a subset of the org, particularly with you as a chief product officer that can't possibly be involved in sort of every one of those decisions.

I think it's definitely true. And I think When I started my career at Google in search, it was kind of this unbelievably perfect garden for letting 100 different teams kind of all experiment independently with a couple different objective functions you're optimizing for. And to be honest, back then, I don't know if there was a strategy doc. I mean, this is like me out of college, but I never read a strategy doc about what we were doing in search and why it was you want to make sure, I mean, I'm paraphrasing a little bit, that links we return at the top get clicks, and when people click on it, they're happy and they don't return to try to find other results. That was the idea. And it turns out you can decompose that problem into 100 different technical steps and then have a bunch of teams working on that all in parallel. And it is a pretty well-oiled machine. So I do think, to be clear, if you can find parts of your product that you can decompose into that way, that you then have objective functions that what you measure directly corresponds to the value you're trying to create for customers, that's a great thing. But to the question of, well, what do you do for things where that isn't the case? I think at Slack we focus on 2 different approaches. So the first is really just about making sure that we have everyone really aligned and energized around our mission, our vision, and our kind of what we call our 3-year strategy internally. So that's kind of what people are aligned at a high level. But then at a more tactical level, we have these product principles, which really started probably 5 years ago when we tried to figure out how to scale Stewart's product sense and intuition as the founder when he couldn't be in the room. with most of the teams most of the time. And so we developed these principles, which are all kind of simple and almost glib when you hear them, but when you unpack them, there's a whole set of stories and examples around them. But things like, don't make me think. How do you make Slack feel effortless and intuitive? What does it mean to be a great host, as we call it? Because we view Slack as this digital environment that's kind of the closest thing to your physical office, but in the software space. So what does it mean for us to be great hosts, to be caring and considerate of the people who are spending their days there? And then things like prototype the path. Which gets into how we at least approach a lot of what we do by not getting stuck in long product debates or endless design reviews, but actually figuring out what's the fastest path to being able to actually touch the software with your own hands and then get that into the hands of users. And there's more than that, but I think those principles created a shared language within the product org for not just our values, but how we apply those values for things where it is more subjective. It is more about taste, and I think they've stood the test of time, and we've only maybe swapped one over the last couple of years. But I think the combination of vision, strategy alignment, and then having principles that the whole org can really understand, that's the combo that's worked for us, at least.

In the sphere of intuition-led product building, what are the thorny things that you still sort of wrestle with? The corner cases, the things that in reality are more complicated than you would have imagined. Maybe you still haven't quite figured it out.

There's a lot. It's Really hard. The world is changing really quickly. So I think figuring out, especially for things that are larger bets, how do you know that this is going to be one that's worth taking? I think for us, one of the biggest challenges has been that Slack is really this horizontal product, right? It's a thing that's a connective tissue that ties hopefully your entire organization together with each other, and also hopefully all the tools that you use since it's a very open platform and ecosystem. And I think, to be honest, one of the things that we've really debated is, Obviously Slack is not going to stay static in time. That would be a bad thing. Our customers want more and more from us. But what are the adjacencies that make sense for us to go into in terms of needs to help customers with that otherwise couldn't really be met with other products or couldn't be met as well with other products? If you think of Slack as that horizontal collaboration productivity layer, what are the obvious adjacencies where customers really want this from us and we think we can uniquely solve some of their needs because It's deeply integrated into the product. I've heard Patrick Collison talk about this as what is our right to win? He uses that phrase quite a lot in terms of almost everything is an adjacency to the core payment business. But what is Stripe's right to win? I think the way we think about that is what is our right to serve customers when there is a whole set of tools outside of Slack that they could also be using? So that's one of the areas, again, at more of a strategic level that we're constantly debating. And I don't know if there's any set of rules we could write down that makes that decision black and white when we are debating, is this new era that we want to invest in. It is always a hard and tricky debate.

When you think about that spectrum of more data-driven or metrics-driven product development to intuition-based, do you think certain PMs spike in each one of those and you think about subdividing work and giving certain things to certain types of PMs? Or do you think that most people can flex in most directions?

I think over time, if you work in enough different environments, I think people can develop all kinds of skills and abilities. But Definitely. When we think about hiring and even career development, one of the things that we like to think about with our product org is that if you imagine that we have a couple key competencies that we look for when we hire people, we think about product strategy, driving for impact, execution, technical data ability. No one person we hire looks like a perfect sphere, right? So what we look for actually is people who have clear spikes on one or two of those axes and also Who's well-rounded, but what are their superpowers is one of the things we talk about when we bring someone to the work. And I would say we definitely try to pair people whose superpowers are really well suited for the type of problem space that they're in. So, for example, just to pick 2 very different teams, we have a team that's focused on more of the self-service business, this new user, new team journey, product-led growth. That team, I would say 95% of what they launch, they launch as an experiment. It's incredibly data-driven. You can do most of those things as things where you can learn from actual experimentation in the And then the total other end of the spectrum, we have our enterprise team, which is focused on the needs of the Fortune 1000, the CIOs, the chief security officers. And you know what they don't want you ever to do is run an experiment. They don't want you to run an experiment of, hey, here's one way of doing securing your data at scale, or here's another way. So those PMs are ones who are typically much more focused on really being immersed with the customers, being in the field, working closely with product marketing and sales and customer success. And from a product development perspective, they're working on projects that are much longer, often much more technically complex, sometimes a little bit more waterfall-y in nature. They have more of a sequence to how they get rolled out. And the types of PMs who would thrive both from an enjoyment and from an application perspective are very different between those 2 parts of the org. So definitely I think we try to match the superpowers of the PMs that we're hiring with the right parts of the product org. But I also think over a long enough career, people should work on different types of problem spaces to develop those skills and then figure out where's the place I want to have that contribution? But as you're developing early on or middle of career, I think it's really great to try out totally different types of domains. And that's a good example of it.

Maybe kind of taking a slight turn, what do you think are the most underrated qualities in the best people you've worked with, just writ large?

It's a good question. So what I would say, I think especially in this hybrid or remote world, whatever you want to call it, the ability to actually write really well matters an incredible amount. And by that I mean, can you write succinctly, clearly, persuasively? Can you do it quickly? And can you figure out how to influence or align an organization in a way that's much more scalable through writing versus endless meetings that you otherwise might be in? I think something that I see a lot of folks do too is thinking about how do you Really drive the pace and quality of decision-making. At most organizations, as they scale, the number one complaint people say is, why do we move so much slower now? Shouldn't we move faster? And most of the reasons why you're moving slower is because decisions start grinding to a halt. You have a consensus-based kind of model. Everyone gets a voice. You don't have a framework for how you actually get to resolution. And so I think there's not one-size-fits-all kind of model. It depends on the organization, depends on the scale, but driving that pace of high-quality decision-making. And the last thing I would say is we talk a lot about the vibe of a team at Slack.

Very Gen Z of you.

Yeah, very Gen Z. But I think actually vibe, like the feel of a team, is this a place that is actually borderline fun, at least really enjoyable, and hopefully kind of inspirational to actually do work? I think that matters a ton. And I think leaders can really set that in many different ways. And again, not every culture is the same, but I think in this world of hybrid where you can't all do it in the same physical place, it was much easier when you were all cohabitating in the same physical environment to have a sense of place, belonging, engagement. I think doing that in hybrid is a lot harder. So leaders who can figure out how to facilitate a good vibe on a team where work doesn't feel like work every day, I think that's one of the biggest unlocks for actually driving all the more objective, measurable things like productivity, pace of execution. So yeah, maybe that'd be my last very Gen Z softball one as well.

How do you think you work as a product leader or chief product officer that's differential from other great chief product officers?

Yeah, I mean, maybe the last part is harder to answer because by the nature of things, you don't actually see how others operate. But I think one of the things certainly at Slack that we have always done from the very early days is a lot of people talk about being customer obsessed. Well, what does that even mean? And I think at Slack we have kind of 2 maxims that we talk about a lot. One is that we're customer obsessed but competitor aware, which I think is very different than a lot of companies who are focused on crushing their competitors. And oh yeah, we want to make sure we serve our customers. And then we talk a lot about how do we generate customer love? And we actually use the word love. So maybe we are really soft and Gen Z at Slack. I actually think it's that most of our co-founders were Canadian, so they had more of that sensibility opposed to an American, like, let's go crush crush our competitors kind of sensibility. But customer love, we've always had as kind of core to our success as a company. And it's because Slack started at the very beginning with this idea of, could you build a product for people at work that they love as much as the products they get to use in their personal life? Now, I think we call that more like, can you build a consumer-grade product for the enterprise? But we spend a lot of time in material point of view, this is counter to what most enterprise CPOs do, Focusing on how do we generate more customer love? How do we build that consumer-grade experience? And we absolutely, of course, spend time understanding the needs of the CIO and the central decision maker and making sure that they're feeling well and heard. But from the product perspective, we really, I think, maybe in a contrarian way, focus on if we can delight the end user, if we can make a team feel more engaged and connected and productive, then long term, the rest will take care of itself. Because what we're delivering with Slack isn't a set of administration controls or security checklists. Those are blockers to adoption. What we're really delivering is hopefully transformation to your organization so that you can take teams and make them the best performing teams in the world enabled by software.

What gives you such confidence that that's the right strategy? I guess put differently, I feel like Slack is maybe the only company or one of the only at-scale companies that has proven this way of thinking potentially works. If you look at any company that's doing more than a billion in recurring revenue, basically none of them pass this test.

Again, this is where it's harder for me to put myself in the shoes of those other companies, but I would say companies with a similar sensibility from talking to executives there, I would say all in the world of SaaS, obviously everything consumer looks like what I just described primarily. I think if you look at Shopify in e-commerce, if you look at Atlassian and developer tools, I don't know the latest revenue numbers on Figma, if it passes that billion-dollar test, but Certainly, I think Figma on the design side. And then I think kind of the next generation of companies like Notion, Airtable, and so on. These companies are all earlier on in their lifecycle. I think give it another decade and I think the companies that are $1 billion or $2 billion might be $10 billion in revenue. But I do agree it is a new, much more consumerized way of looking at building enterprise software. And I don't think it's for every category of enterprise software either. There are definitely certain classes. If you look at maybe more on the infrastructure side, for example. I don't know if Snowflake or Databricks, for example, is focused in the same way, nor should they be. They have a very different buying cycle, very different customer segment. But I think if you're building tools that fundamentally are used by people at work and that the people who are using it are at least often the initial buyer, that's why I talk about teams, right? The initial buyer of Slack is almost always a leader on a team, a manager, maybe a group division head or whatever it might be, then I think this approach can really work. Now, conversely, I think if you're focused on building, let's say, an HR system or a system for the CFO or something like that, that is always going to be a top-down purchase decision. I think if you're trying to build, I don't know, a new version of NetSuite, let's say, I wouldn't focus on how do you make the end users in FP&A love your software. I don't think that would be a great strategy.

Why do you think that is?

Because That is a category where the person whose opinion matters the most is the person who doesn't actually use the software. There's a misalignment in that sense where the CFO is looking at the output, but they're not going to be using it. I mean, I'm making this up. I've never used an ERP myself directly, but what I can imagine, or if you look at, since I have to use it for work, like HRIS system, those are primarily designed for the HR and finance orgs to be able to have all the rules and compliance and processes and workflows in place that you need. That's the buyer. The end user, as in the managers or the ICs in an organization who are interacting with it very frequently, making them love the software is not going to create advocates on the buyer side. And so I think that's probably, if I was going to delineate, is figuring out this approach works best when you actually have an alignment between the end users and the people who at least can make the initial purchase decision. And definitely works the worst if you have something which is a very top-down executive-driven purchase where that executive probably won't even be using the software themselves.

My guess is that when you think about Salesforce, a company that you, I'm sure now know quite well, my guess is that their product philosophy and orientation is quite different than yours and is obviously unbelievably successful. But I'm curious, given it seems like you've both built spectacular companies and I assume see the world potentially in different ways, or at least in certain contexts, Are there things that you've learned from Salesforce that have caused you to update your thinking or change the way that you're doing things? Not in like a, we're integrating Slack into Salesforce go-to-market or any of that type of stuff, more like the way that they build and distribute software.

Absolutely. In some ways, to your point, that kind of premise, if you will, of the acquisition was if you can take the company that pound for pound is probably the absolute best at enterprise sales and marketing in the world, As in Salesforce, and you can take the company that has built probably one of, if not the most beloved product in the enterprise space. What happens when you pair those 2 together? So you have an enterprise go-to-market machine, which is what Salesforce has built, and just understanding it up close and just seeing how they run their sales organization, their customer success organization, their marketing, their field events. It is a machine that is incredibly efficient and runs at scale, which we had, I would say, early bits of at Slack, but not nearly that level of maturity or sophistication. And then you take Slack, which we've obviously figured out an approach to building product, a cultural DNA. We built a brand, we built a product that is beloved, and we've also built a kind of business model that is much more of a hybrid SaaS model where that self-service bottoms-up adoption both within the SMB space and also within large companies can then feed an enterprise business. You take those 2 things and you pair them together. Well, you figure out how to best pair them together, and that could be a pretty magical pairing. So that was the, I would say, premise of the acquisition. Outside of just having appreciation for what it means to actually run that type of scaled enterprise go-to-market, one of the most interesting things that I've seen from their leadership is how we think about that product principle, prototype the path. We always talk about that in the context of software. How do you kind of incrementally build a low fidelity prototype, refine it, get feedback, scale it out to more people, get more feedback till you build confidence that this is going to be something people love? They do that with their marketing and positioning in the world with customers. So one of the things I find amazing is they have this huge re:Inforce conference, right? A couple hundred thousand people go every year. They're working on What is the positioning, the framing, the narrative that ties what's happening in the world together with their software roadmap? They're working on that for most of the previous year as they kind of progressively workshop it with customers and they see what resonates and they get feedback and they prototype it. So it's something, honestly, I mean, maybe it sounds obvious, maybe we should have been doing that all along, but they approach marketing in an iterative prototype-driven way, the way that we've always approached product. And that was a huge kind of open my eyes to what it looks like. And then you are like, by the time they're on stage, they are so confident that the way that they're talking to their customers, have empathy for what their customers are struggling with and how they tie that to their product roadmap, they are so confident that's going to stick. Not because they're just winging it. They've actually de-risked it and validated it every step along the way. So that's probably one of the more incredible things, at least I've observed. and slightly participated in that we've learned a lot from.

Do you take those ideas and apply it into your world of Slack, or is it now much more unified? And so Slack slots into that vision, and so you draft off of or integrate in or collaborate closely with that. So you're not developing that competency kind of in the world of Slack.

Yeah, I would say from a marketing perspective, we've Pretty closely integrated the orgs. There's still a head of marketing for Slack, but they actually report functionally into Salesforce. So I think how we tell the story to the market, we try to do in a really joint unified way. Salesforce itself is almost like the Berkshire Hathaway of SaaS, if you will. Like they're a conglomerate that has many different product lines. So they definitely have a single voice as a corporation or an umbrella brand, but all their products kind of live together as a suite, if you will, of products that are Integrated, but fairly independent. I'd say on the product side, I think it's still primarily actually still driven by our own sense of what customers want, where the market's heading, what our strategy is that accomplishes our mission. The place where we've probably done the most kind of integration work or where maybe we flow the most from Salesforce is trying to figure out how to make the experience of using Slack and Salesforce together dramatically better for customers who are customers of both products. And the reality is 77 of the Fortune 100 use Slack and probably 100 of them are Salesforce customers. And so figuring out that joint intersection of how do we drive more value if you use both products or both sets of products together, that's where that affects the product roadmap.

What about anything on pricing specifically? Has that sort of evolved in a big way? Or, I mean, I assume it's just such an enormous sort of way in which Salesforce, I'm sure, obsesses.

It's interesting. I remember at an executive offsite, supposed to be like 6 years ago now, Marc Andreessen came to do a fireside chat. I swear this will come back to Salesforce in a second. And, you know, this is probably right when we were first building out the beginning of our enterprise sales team. Maybe we had like 10 salespeople or 20 salespeople, and we were just asking the most naive questions because most of us had never worked in enterprise software before. And I think we'd maybe asked him, how do you think about pricing? For the enterprise. And he says, with a very straight face, he thinks, and then he says, think about what you think you should price the product, then double the price. And we're all like, whoa, that would be so much. And then he says, then double it one more time. And he's like, that's probably the place you should start. That's not where we started. I think Slack maybe, I think historically probably has underpriced the product versus the value we've created for customers. Part of that, I think, is one of our maxims from the very early days is we focus on value creation, not value extraction. And so I think when given the 2 options, that's kind of always where we've biased. Ignoring literally the sticker price of the software, I think the thing that we've still tried to build additional muscle from, but Salesforce is definitely world-class at, is how do you think about decomposing a product suite into a number of different product lines that you can then have many different ways of packaging, bundling, et cetera, together. Where it can be a better buying experience for customers because they're getting the pieces that they want, but also getting a good deal the more that they buy. And also as a business, obviously you can figure out how to actually monetize adjacencies instead of including it all in one single SKU. I think realistically we're still pretty early days there, but I think if we were an independent company, that was something that we had struggled to kind of build that muscle and DNA for. And I think Salesforce from a Pricing and packaging perspective, they are one of the most sophisticated organizations on earth, and they have one of the most complex, wide-ranging product portfolios. So it kind of makes sense that they're paired together. And we're still in the early days of our learning journey there and figuring out how to take some of their best practices and apply it to Slack, and also figure out how, frankly, to integrate Slack into some of their packages that they already sell to their existing customers so Slack can be bundled in that. same enterprise motion that they already have.

So zooming back into the tactical, how specifically do you run design or product design review meetings?

It's definitely evolved over the years, obviously. I mean, I think back in the very early days, it was a super informal in-person discussion, usually with Stewart and maybe the whole— I think when I joined, it was like the whole product team. We'd all just get together in a room and just Go through, here are the open releases, and all sit around one table. I mean, that was kind of how it started. Fast forward to now, we organized our product organization into what we call product pillars. So there's pillars for the enterprise organization or for all of our new audiovisual products or the self-service business and so forth. Those pillars wind up doing reviews internally for more of the smaller scale feature development or refinement or experiments. That's very empowering. And the leads for those pillars then wind up playing the role of kind of executive backstop or the person who's pushing the quality bar. For our own product reviews, what we typically do now, and again, it's changed, I would say, since COVID for sure, is we do a lot of actually kind of pre-work and pre-reading. So often, let's say if we're reviewing a strategy doc, that'll always be something that's shared ahead as pre-read. If we're reviewing a design, we'll often have people wind up sharing like a Clip, which is recording in Slack where you can narrate over a screen share. So you actually have the designer walk through, hey, here's this flow that we're going to be reviewing. Let me explain the why behind it. And honestly, as someone who's going to be in the review, it's an amazing experience where you just play a couple of these, you lean back, you have your coffee, and it's watch it on your time when it's convenient for you. And then everyone comes into the meeting with all of the feedback, all of the questions already there. So you're not wasting that time in the meeting with a one-to-many presentations. And then if it's a prototype, ideally people share a link to the demo build and you can actually play with it yourself. And that's the same kind of experience. Again, going back to vibe, I really prefer for reviews not to feel like this is like the team versus the execs. And the ideal that happens is that you get just like carte blanche approval for everything. And it's all about checkboxes and rubber stamps and everything else. And it winds up being a very like kind of contentious kind of vibe. To me, it's a group of people who bring different perspectives who are working together to figure out what is the best path to take to delight our customers. And so I don't know if we always succeed at this, but I think as much as possible, we try to have these reviews feel more like coworking sessions. Obviously, sometimes there are key decisions that we have to make when people don't all agree, and we'll make sure we cover those before the meeting ends. But more than anything, usually there's a very collaborative working session, hopefully on a real prototype, at least on a design, where we try to give guidance, fodder, and feedback to the team and make sure that any critical one-way door decision is unblocked. And then we do all the follow-ups in Slack after that. And Rinse and repeat.

The comment about the vibe of a team, what are the inputs to that? Or if you think about a team that you think has a good vibe and a team that doesn't, what's going on in one that's not happening in the other?

I think one of the biggest things, I think there's something that PMs can really be responsible for, is there maybe was this myth or there was this meme, I don't know which way I would call it, many years back where it was like, oh, the PM is the mini CEO. Of whatever the team that they're on. And maybe a lot of people heard that and they're like, oh, I want to be a CEO one day. I should be a mini CEO to start. And then they decide to go into product management. I will tell you, the people who take the approach of being a mini CEO for a team are the ones who their teams wind up saying, why do we have to have a product manager on our team? Can't we do it without them? Because you can wind up accidentally being a tyrant or overly controlling or thinking that your job is to come up with every idea or to make every decision. Conversely, When I would say see a team with a really good vibe, here's some traits I would say, and this is off the top of my head, but thinking about the teams at Slack that look like this. One is that it's incredibly inclusive of who participates in the discussion. It's not one or two people who are the leads and everyone else is just observing. It's people bring their expertise into the discussion and it's a very kind of flattened environment in that way. Two, you can see the enthusiasm in the pace that the team is working. So when you see a team where it's not like, okay, we had this discussion, well, let's check back in in a month. Instead, when it's, we had this discussion, let's see how much we can get done in a week and let's get time next week to review this prototype no matter how rough it is. So that kind of pace and urgency, I think you can feel a lot in, is this team riffing off each other? Are they taking the collective creativity of that group into account and you can see that based on where the ideas are coming from. The other thing is you can kind of just tell, I would say, when there's a team that is somber and disengaged versus a team that is bouncing off the walls, saying they're having a blast, really engaged. And then you, I think, see that translate into the productivity and efficiency of that team. One of the things I actually ask PMs when I do skip levels, let's say, maybe it's a weird question, but one of the first things I'll ask isn't, How are you doing on target for your OKRs for the quarter? Or what's the latest with your deliverables or anything like that? It's how much fun are you having? Is the team having fun? What's holding that back? Because I really do believe this is not just like a Gen Z thing. I'm not in Gen Z anyway, but that if a team, if an individual who is setting the tone of a team is actually feeling like work is energizing, work is fun, work doesn't feel like work every day, Then you'll see that in the pace of the team, in the execution of the team, and then the impact they drive for customers in the business. And on the converse, if every day feels like drudgery, if it feels like you're filling out TPS reports and you feel like you're just dealing with process all the time, even the most motivated, talented people on earth will eventually run out of steam. So I don't know, maybe it's different at different companies. Maybe there's more of a command and control environment where that doesn't work, or maybe at a hedge fund it's different, but definitely in the world of the art and science, the rigor and the creativity of product development. I feel pretty strongly that the vibe matters.

A little while ago you mentioned sort of a topic that I think a lot of folks wrestle with, which is pace and quality of decision-making, probably at any scale, but particularly as you're growing a team or you're growing a company. I'm curious sort of what you've figured out on that topic, and we could go in a bunch of different directions, but one is maybe, do you try to disambiguate the quality of decision with what the outcome ends up being. And so like an example is, you know, you drink a lot at dinner, you drive home, you don't kill anyone, you get home safely, you had a great outcome, but you would objectively say that the quality of the decision was poor. And the problem is if you don't recognize the quality of the decision that's poor, bad things happen because you take the wrong lessons from it. The lesson there would be drinking and driving is totally fine, and you can see how that would be problematic. But I think a lot about that in the case of company building and product building and those things. But curious what comes to mind for you in pace And quality of decision-making, maybe specifically in the context of product?

Yeah, no, it's a great topic. I was just thinking back to the last thing you were saying, which is Annie Duke has this really good book. I think it's called Thinking in Bets. I'm a real crappy poker player, but the book is accessible. And she talks about this idea, I guess it's called resulting, which is that if you look at how the hand played out, opposed to how you played the hand when there was uncertainty, You can take away lots of really bad lessons about how to play poker because you got really lucky when the final cards hit the table and you happened to take the whole pot. So definitely I think when you look at qualitative decision-making, you have to obviously use the outcomes over time in aggregate as a signal. But I think trying to evaluate yourself or a team based on a single outcome at a single point in time, I think is likely to draw a lot of spurious conclusions. When I think about patient quality decision-making, I think to why is that never a complaint for a small startup? You'll almost never, hopefully, you would know better than I would actually from the investing side, but if you talk to folks or when I was at a very early stage startup back in the day, it's 10, 20, 30, 40 people. No one even knows whether you're making quality decisions because you may not even have a product in the market. People are generally saying, I'm working like crazy, I'm doing 7 different jobs and I just wish we had more people, but we know exactly what So what's different then? To me, there's maybe 2 or 3 key ingredients. So one, I think there is a tremendous amount of shared context that group has in every direction about the mission, the vision, the strategy, about the customer, about what they're trying to achieve. That shared context is the common language that you use as you're trying to make decisions. 2, I think there's usually a really high degree of trust. And with that trust, because it's a small group that works really closely together, I think you can actually then wind up pushing each other's thinking more. There's a high degree of appreciation for each other so that you can actually push on ideas and not feel that that's threatening in any way. And then I think the third thing is it's easier to act without fear when it's that early on. You have less that feels at stake, you have less that feels risky. So let me compare that to a large organization and how do you put that into practice? One, I think almost always when I look at a team or part of the organization that's struggling with a decision and there's different views, the root of that almost always to me starts with, does everyone have the same shared context? Does everyone have the same knowledge and information? Is everyone using the same backdrop to actually be able to weigh the pros and cons of whatever it is they're trying to decide? The answer is almost always no. Why is that? Because communication is hard and alignment is the fundamental challenge of almost every large company. And People are just busy and people are doing different things and they're rowing in different directions. I mean, we talked about this at Slack. If you can keep an organization aligned and focused, it's like a superpower for velocity. But alignment isn't static. You don't get to do it once. I mean, this is even if you present a 3-year company strategy, if you don't talk about it over the next month, most people will have forgotten it by then because that's not what their team is doing every day. So yeah, I think maintaining and preserving shared context to have alignment and to have a shared perspective of the backdrop that you're making the decision is number one. I think number two, I think this is why it's so hard to make decisions at big companies, is if there's not trust, it's really hard for there to be conflict, healthy conflict. And if there's not healthy conflict, it's really hard to get to great resolution. And so this is not about any single interaction at a large company like Salesforce or at Google, but I think when people complain about organizational politics, I think what they're usually saying is there are different parts of the company where there is no trust between those parts of the organization. And so it becomes almost impossible to make joint decisions without escalating it to whatever is the exec at the very top between those 2 parts of the org, which often turns out to be the CEO. So trust. And then I think the thing that happens as your company gets larger, and it makes sense, is that decisions become more fraught. You understand all the downsides, you understand what could happen if you make the wrong decision, and it becomes paralyzing. And so the natural inclination is then I don't want to personally risk making a decision that is wrong. To your point about looking at the outcomes and then getting attributed, I put my neck out there and maybe it was the right decision with the input that we had, but it came to the wrong outcome. And then suddenly people are looking at me and saying it was Jimmy's fault or Jane's fault or whoever it was. So I think people become paralyzed with fear. You then have a consensus kind of driven approach because no one person wants to take ownership. Consensus is really hard and then things slow down again, or you make the most vanilla neutral possible decision and it's a bet that then winds up not working because you didn't do something with high enough conviction. So yeah, I think if you can get shared context, if you can build trust, And you can figure out how to give people the confidence to make high conviction, bold bets without feeling that if the outcome is off, they're going to be personally attributed, then I think you can start driving the pace and quality of execution decision-making a lot more.

For each one of those, how does it translate into rituals or systems? How do you operationalize them?

I think shared context is probably the easiest. Which is to say culturally and also in the software we build, I think the key there is just transparency and repetition. I mean, transparency and obviously sharing everything you can to help people have the same set of inputs. And I think repetition, meaning that we keep grounding back in the, what is the context that matters for the decision that we're making so that everyone has that in their head at any one time. So I think those are the two there. I think trust Trust is hard. Trust is hard, especially as you scale. It's harder even when you're not in the same place. I think one thing there is the classic kind of vulnerability builds trust, I think is really true. I think getting people to be able to do things that allow them to be vulnerable with each other so you can build a level of kind of trust between people outside of the context of any work decision that you're trying to make. And I think one of the big things is Repetition. And here, I forget which board member said this back at my old company before. They said, you know, the best leaders say what they're going to do and then do what they said or let you know why that wasn't possible. And I think that's one of the things to me about what does it mean to have repetition with trust? I think it's that knowing that that's going to happen. That's the expectation within the organization. And then the risk-taking, I think that is Tractable. Amazon has this kind of delineation between one-way door and two-way door decisions. We borrow that and we have a saying at Slack, which is you should walk confidently through two-way door decisions. And what we mean by that is don't be paralyzed by things that are easily reversible. So for example, I'm making this up, but it's true. It can feel very fraught to figure out like, what should the new tagline on the homepage be or something like that? It's very prominent, very visible. You could spend months debating and focus group testing and everything else so that no one person feels like I came up with the tagline and it didn't work. But that is an incredibly easy to reverse decision, to change, to update. And so that's the kind of thing where teams should feel comfortable walking through that. One-way door decisions, which are much harder to reverse, can have longer-term repercussions, are hard to de-risk. I think those are the ones where you do need to have a slower pace of decision-making. You do need to be more judicious. You want to figure out how to de-risk it more ahead of time. So I think as an organization, getting really good at delineating between one-way door and two-way door decisions and then making sure that the teams know that most decisions you're going to be making are two-way doors and only moving slowly on the one-way door ones that truly are hard to actually turn back on. And then also I should say, making sure you have a culture that is— we talk a lot in engineering about this idea of a blameless postmortem. Which is, you know, there's an incident, an outage, whatever it might be. You want to do a postmortem to learn from it, but it'd be blameless. So there's no individual accountability because it's an organizational failure that this software got to the place where it fell over or whatever might have happened. To avoid a culture where people become petrified of having high conviction and feeling like they were wrong because the result didn't work out, I think you really have to have a culture where you're not putting individual blame. When outcomes go in the wrong direction. Now, I guess if you're wrong all the time, at some point then you have enough data points and maybe this is not the right area for you to be having high conviction in. But I think on any individual decision, any individual launch, whatever it might be, I always like to say to teams, it's like optimize for the pace of learning and the impact will follow. So if you can quickly learn and try again and refine things, that matters a lot more than being really slow, really deliberate, and you're probably going to be wrong a good portion of the time anyway, and that's okay.

Is there anything else you do specifically to get people to make big bets? Do you think about it as a portfolio where you want to be making a certain number of big bets, some of which will pan out and not? I feel like in any sort of product strategy, there's obvious things to nail down or do. There's a lot of those things, but there's often really big step function type projects that both require a lot of effort and will likely fail. But a subset of those, similar to, I think, venture investing, end up building the next pillar of the business. And any thoughts on managing for that?

Yeah, it's one of my favorite things to think about because it's hard, and the inclination over time is to have a localized team where you're really focused on a subset of the feature space and you have 1 or 2 KPIs and In any given quarter, you feel like success for you, for the team, is incrementally moving that KPI that you're directly responsible for. That obviously is kind of antithetical to what you just described, which is very important, which is how do you take these huge swings that can be transformative for the business, even though the chance of success might be much lower? It's so much a struggle, I think, that we actually created one of our 5 or 6 product principles is literally the term take bigger, bolder bets. That is literally one of the product principles. And I was talking to someone the other day, they're like, well, that's so obvious. Why is that a principle? I'm like, well, you go check out an organization of 1,000 people in product development and see if that's so obvious for people to do. There's a lot of laws of gravity, I think, as an organization scales that prohibits you from doing that. So I think things that we do to then encourage that besides just call it a principle, one is when we're doing kind of reviews of teams' roadmaps, To your point, we actually do look a lot at what's the portfolio and how is it diversified. Not every team should have the same allocation in terms of low risk versus high risk, long-term versus short-term, certain versus uncertain types of projects. But I think it's important to kind of look both within a larger team and even across the organization of, are we balancing our portfolio? Are we taking enough swings that actually, even if they have a low chance of success, The upside for transforming the product for the shape of the business is there. When I was at Google, they used to have this model they called 70-20-10, and I think they kind of classified as 70% should be that first category you said, like low-hanging fruit, obvious wins, incremental. 20% should be kind of extending the new bets that are already taking off. I don't know, back then it was maybe Gmail and Google Maps had a lot of momentum, like keep investing in those even though they're not at full scale yet. And then 10% were self-driving cars and Android and AI or something. Google has a luxury to be able to, I think, allocate like that. But I think being deliberate about what does your allocation look like and how is that changing over time?

If that's sort of the Google allocation, even if you don't have an explicit allocation, what would you say it is for Slack, or would you break it into different groups?

Yeah, I think it depends on the group. We have a huge portion of our team that's focused on infrastructure reliability, quality, security, and performance. They're like 95 to 3 or something like that. But then we have certain organizations that are maybe more 30, 40. Across the board, I would say we probably look— my hunch, though I haven't actually done the math on it, is we probably look a little bit more like 60, 35, 5, if you will. Not quite as many fully speculative things, but maybe focus a little bit more on the new adjacencies. And we don't have as much of the business that's so mature that it's just purely incremental. But I think within teams, the other thing that we talk a lot about to kind of make it less scary by taking these swings is we have this idea, we kind of talked about a little bit in terms of this like hill or mountain metaphor in the beginning, but we talk about this idea of getting to the next hill. And the idea there is for any sufficiently large area, it can be really daunting. And what you realize is you don't have that much visibility yet when you're at the very beginning. You don't know what customers will want, what will resonate, what will be frustrating to them, what the market will react to. So I think thinking about what are the sequence of hills, I don't mean this from a hill climbing machine learning sense of it, but if there's a mountainscape and you're at a valley and you can only see what's directly around you in the space of possibilities, how do you literally get to the next hill and then look around and see what the rest of the terrain looks like? And so for any one of our large product areas, a lot of what we talk about when we're making big new investments is you have this grand vision. Okay. We're probably not going to spend the next 5 years building this out and then ship it and see, do customers like it? How do you decompose that into a set of hills that we can get to? It gets fuzzier and wider, the space of uncertainty in the future. But as you get to each new hill, you learn a tremendous amount from customers, from the market, and then you can decide how do you want to course correct or calibrate or de-risk in the future. So I think this idea of kind of picking a next milestone that you can actually learn from in public, that you can then get more visibility into where you should go next as you decompose what be a multi-year bet into something that incrementally proves along the way. In some sense, I think that helps teams get comfortable taking bigger swings because it's not one swing. You get a couple and they hopefully compound on each other.

In this theme of decision-making and operating, I'm super curious, given you've been at Slack for almost 8 years, what do you think are the things that ended up working in spite of the things that you were doing? And maybe what are the things that you think served you in a given chapter, but you had to unlearn? So like an example would be like back in the early days of Google and some other companies, they believed that you should never have any managers. And so I think at one point they had 200 engineers reporting to an engineering leader of sorts. And maybe that helped Google become what it is, or maybe Google became what it is in spite of the insanity of having 200 people report to one person, for example. And now that you've kind of had 8 years to see maybe a few different chapters of Slack, are there things you think of maybe in the realm that you're most involved with that you've had to meaningfully change your mind? Not kind of the generic sort of stuff, but maybe you were heartened in one way and you realized that either it was just blatantly wrong, or maybe it's just, okay, we're in a new phase and I'm totally changing what I thought before.

No, it's a great question. I was just thinking back over the years of the biggest examples of this. I'll give 2 that are both sides of the coin that you just said in opposite directions, which is kind of interesting because it kind of mirrors our evolution as we scale the company. I first joined Slack the very beginning of 2016, and I remember it must have been a couple of months after that, Stewart, who is the CEO, had this interview where the headline was Stewart Butterfield says we will never hire salespeople at Slack. And, you know, it was a little sensationalist, but what he was getting at, I think at the core, was our goal with Slack is to make software so good it sells itself. And at that point, without many enterprise customers, it was so good it sold itself. Now, I think if you talk to a lot of the folks who led our sales organization over time, you know, obviously one, when we hired Bob Frati, who was actually coming from Salesforce, you know, his first all hands, I think he literally took a picture of that article and said, well, I guess, I guess maybe you hire one. Let's see if we can hire some more. So it was kind of an open joke that that was the origin story. But I do, I do think actually early on it set the tone a little bit of the culture to be extremely product led. to maybe not value the role of sales and customer success and enablement as much as we should have. And I think it took a long time to kind of correct for that, I would say, and to really kind of build more of an enterprise-grade organization that wasn't purely product-led. So that was one, obviously, which worked. I think we got to, I want to say, $80 or $90 million in ARR before we hired a head of sales. And it'd probably be much bigger now because, you know, the SaaS world was smaller then. Now, conversely, and this is something that we then had to unlearn, you know, we made a pretty hard pivot, I would say, 2017 to 2019, where we started hiring this huge sales organization. I think that was good. We started talking to large customers a lot more. That was good. And what we heard from them all was basically, oh my God, Slack is already so powerful. We don't need any new features. What we want is tools for security administration, controls, compliance, and we actually want you to ship products less quickly. We're used to the world of enterprise software where maybe there'll be a release once or twice or at most 3 times a year, and we get to test the releases before they even go out the door. And we never actually quite went that far, though. We figured some of the things out to be able to do that. But I think we really rotated the organization on focusing on those enterprise blockers, really slowing down the pace of core product momentum. And that was a trade-off. It was somewhat explicit. But I think what happened is After a certain period and really turned around in 2020. I think the move to hybrid remote created this new imperative from our customers that they suddenly had, they always relied on Slack, but now they lived in Slack. And so that created a whole new set of expectations. But I think it took a while for us to kind of build that muscle on building an enterprise-grade version, a carrier-grade version of Slack, and then to rebuild the DNA from those early days of, well, what does it mean to then start increasing our product velocity in new areas and pushing the boundaries of what Slack could be, moving to adjacencies like Huddles and Clips and Connect and Canvas to expand the capabilities of the product and expand what our customers expect from it. I think we had to kind of rebuild a little bit of that DNA and culture because we had so kind of corrected towards that enterprise side. And the reality, I think if you're, to your earlier kind of discussion, a multibillion-dollar company and you're building this hybrid SaaS model, you actually have to be good at both. You can't just choose one lane. And, and we had to kind of refine that part of our kind of original DNA and founding culture 6 or 7 years after launch. And I think that's what's kind of propelled this last chapter of the last couple of years at Slack.

When you look at those pivot points, when you or the executive team change their mind, does it end up looking quite organic where you're reflecting and you're like, ah, this isn't quite working, we gotta move in this direction? Or are there structures or ways in which you work together That allow you to kind of diagnose these things and really meaningfully go in a different direction?

I mean, I don't know if I would say there's repeatable organizational practices that let us do that. What I would say more than anything is one of our cultural values at Slack, not within the product org, but within the whole company, is humility. And when we say humility, obviously we mean certainly the opposite of being a braggart or being arrogant. But when we unpack what that means, we really mean Being introspective, being comfortable being self-critical. And we don't mean that just as an individual, we mean that also as an organization. So I think one of the things our company has always at least been pretty good at is applying humility to how we're structuring how we work, to the strategy we're taking on, to not assuming that the momentum from the past year is guaranteed to continue forever into the future. So I think without being self-flagellating, we are pretty self-critical. And I think that's where those kind turning points came from. But as we get bigger, I think over time it becomes harder to make those shifts. The way of working becomes a little bit more endemic. So I definitely think it was easier to start hiring up a sales team when we were a couple hundred people than it was to change the culture of how we build product for enterprise grade versus product innovation when we were 1,000 people in the product and engineering org. So those changes, yeah, just inevitably become harder as the ship gets bigger.

Before we get into the last couple things I wanted to dig into on this theme of bottoms-up and top-down or mid-market and enterprise, I'm sure that we could spend 3, 4, or 5 hours exploring this topic and something that I think you've spent a lot of time on. Are there any insights that you've picked up or very tangible advice you would give to, call it a company that tends to be more bottoms-up or PLG, call it they're at $30 million in recurring revenue and they're thinking a lot about enterprise that might be helpful? And, and I think it's such an important topic because it is mostly done Incorrectly. And I would say just damages companies in profound ways. And it's always tantalizing, right? It's like we're in the mid-market and that's going pretty well. Growth is slowing a little bit. Let's go enterprise. And I feel like in this macro environment, most boardrooms are encouraging the company to go upmarket, which intellectually makes sense. And I think in reality is dramatically harder than most people would imagine. And so kind of in that theme, any crystallized insights that you have or when a CEO or a chief product officer at that company that's doing bottoms up and is at $30 million comes to you for advice, what the advice tends to be.

Yeah, I can think of a lot of conversations the last couple of years that were exactly that kind of juncture for folks. The first thing I would say is understanding where the maturity of your business is in terms of how much of the market that you think is easily addressable that you've actually penetrated. And do you actually need to go upmarket? Is it the right time? Because it can be a huge amount of investment and distraction, not just on the product side, obviously, but also on the organizational side. So if you look, there are a number of companies that have built companies worth tens of billions or hundreds of billions of dollars only going after SMBs. Right. And I think that's also the right solution. But if you look at Intuit or Square or HubSpot, for a very long time, those companies basically never built out enterprise sales motion. So, you know, first question, is this even the right time? How do you know? And I think the way that you know is twofold. One is, do you feel like you've massively penetrated the maybe SMB or mid-market for your product category and the kind of most obvious audience that you're going after, whatever that looks like? And then 2, I would say, is are you seeing embers of organic demand from large enterprises that you feel like you're just letting drop on the floor? To me, the 2 ways I would assess that is one, are you just getting a lot of inbound from large enterprises that you literally are just neglecting or letting sit in a support queue? And then the other is, are you actually seeing organic usage within smaller parts of the large organization, but you haven't figured out how to uplevel that conversation to an enterprise level. So that would be kind of where I would start. I think in terms of kind of building more of that hybrid motion, I think going back to some of the things that we learned over the years that maybe, you know, I think some of them are obvious now, but definitely for us, I think took a while to figure out. So one, you know, it was our earlier discussion is certainly when your end users and your buyers can often be the same person, I think focusing on building that consumer-grade experience so that even within a large company, you can actually land within a team without needing handholding you're a salesperson, it gives you a tremendous amount of leverage to then your sales team. So if you switch to the sales world, you start thinking about account exec productivity. What is the ACV per sales rep that you have ramped? I'll tell you, the best way to ramp that up is by making sure that those AEs are only talking to companies where there's already a lot of traction without ever needing a person to help them in the first place. So that number will always go down over time, but giving that a head start is a great thing. I think figuring out, especially early in the customer journey, how to focus on increasing comprehension of what this new tool is and then for why you would bother to bring it to your organization. Again, those sound pretty obvious, but I think most fundamentally in the beginning where most drop-off happens is people don't either understand what this thing is or they don't get why they should bother to put the effort in to convince their team or the company to use it. Making a really robust paid trials experience and probably a freemium model as well, especially if it's a more usage-based product and really kind of tuning that over time. That has been definitely one of the things that we've kept tweaking and refining and has always been obviously a pretty high leverage point. And then I think really having a clear way of establishing the funnel that goes from the more mature self-service motion where you've landed within pockets of a large organization to where does the handoff happen to your enterprise sales org that you're standing up. So having the data visibility into bottoms-up adoption and usage-based metrics, having the ability to qualify those those leads, having some amount of marketing organization where at least you can do some scalable outbound, and then being able to walk into those customer conversations with enough insights into what the organic adoption looks like, that discussion becomes a pretty obvious one, which is to say, at least early on, I mean, this is what it was at Slack. We'd go in and say, hey, did you know that you have 700 people using Slack every day at your company? And maybe this company has 10,000 people. They're like horrified. They didn't even know that was the case. And we say, no, it's okay. We actually just want to see how we can help you figure out You know, can we make the people who are already using it happier, more productive? Are there other parts of the organization that might want this? Let's work together to help this fire that's already started. Can we help you spread it if it's working for people and you didn't even know about it? There's a lot of pieces there, but that's definitely a place I would start.

And do you think you often see people when they think about enterprise, they think about outbound and starting net new conversations versus going super deep with where there's already kind of a little bit of pull for the product already?

I would say starting off with building out a huge BDR team to do inside sales for cold leads feels like if you already had a product-led growth motion, not the right place to begin. Because I think without a doubt, the best leads aren't ones that you cold emailed or that you sent a LinkedIn note to. It's the ones that there's already some ember of usage and traction within that organization. I don't know what the latest stat is, but I know when we went public, we had a stat, I think it was 85% of our enterprise deals by the time we went public at our IPO had started off as paid customers through self-service, meaning that they literally got to the point where they actually paid with a credit card before they ever talked to a salesperson. Now, that obviously means that the majority of what our enterprise sales team went after were customers who had already got to that point of maturity, at least within a pocket of their organization. And talking to many other companies that had more of this, self-service or hybrid SaaS model. I think that is a very, very common approach that is pretty tried and true.

What about one other topic that is related to what we were just talking about, which is you've worked with a couple founders very closely who are also effectively the head of product. Anything you can kind of share on what it looks like to do that well as a product person coming into a very founder-centric, product-oriented company?

Yeah, I mean, more broadly, to your point about advice, what I would say to folks is if you're thinking about joining a startup, bleeding up a function and the CEO before they were the CEO, that function is the area that they worked in. So that's their kind of superpower. That's their passion, whether it's product or marketing or sales or whatever it might be. What I would say is there's probably the most upside for what you can learn because that person will be able to be world class and push you the hardest. And also it's probably the most fraught. Thinking back to Foursquare and obviously Slack, Both that had product founders, CEOs. I mean, a couple of things stand out. I mean, obviously there's all the basics that you want to build mutual trust and kind of a shared understanding of how to operate and each other's proclivities and frustrations, all that kind of stuff. But I think beyond that, what I would say is 2 main things. One is to our earlier discussion about why is alignment so hard? I think you need to figure out how to be fully aligned together on the mission, the vision, and the strategy, not just for the next quarter, but for the couple of years to come so that you can then align the entire organization and be completely lockstep. So that's one. And the second, I think, is making sure that, and it can evolve over time, that you have an operating model with how you bring the CEO into product discussions, product decisions that works for both of you and for the organization. And the thing that I've at least found for the environments that I've worked in, and this may not apply everywhere, Is if you think about a major product initiative, not an experiment, but something more significant that's like this big kind of bet. And you think about the x-axis is kind of the time that goes on from the project starting to maybe launch. And the y-axis is the level of involvement that you want from this product founder CEO. I think the ideal setup from where I've worked at least is that it looks like a U. And that's to say, I think it's really important. Let's say you're taking on something like Back to Slack, when we were working on Huddles, you really want to focus in the beginning with the team and with the founder. Do you have agreement about what are the goals? Why are we doing this? Why do you think we're going to be successful? What does the competitive dynamic look like? What is the impact we're going to see? What is the nature of the experience we want to build? Where are we getting inspiration from? All that. And then that's kind of the bit of alignment that you start with, with the team, so that you can then not have to have Constant check-ins or readjustments in course throughout the project. And then at the very end, and again, it depends on the founder, but I think at the end of the day, the CEO is the person who is ultimately responsible for the level of craft and the quality of the product that you put into the market, and they'll feel that deep down. So you want to get them an opportunity at the very end of the project to be able to actually taste the soup. Is it missing ingredients? Is there too much pepper? Is there too little salt? Did we go too meat heavy? Is there not enough vegetables? Whatever it might be. Again, this is the point about how do you make it constructive and not a review? Or a launch decision meeting, but working with the team in a really collaborative way to be able to say like, hey, it's not the day before launch and now I'm throwing your plan off track. It's maybe the 4 or 6 weeks before we think we're launch ready. Can we have an opportunity to do that final soup tasting to then figure out does the recipe need a little bit of refinement? And I think if you do that, it's both obviously, I think, good for the founder's involvement. They feel like they're involved early on in strategy and they're involved very late in making sure the quality is up to But it also really works for the teams. I think one of the most demoralizing, sapping things that can happen to teams is when they feel like they are in either endless cycles of exec reviews and they're like, I don't even know if we're building for a customer anymore. We're just really building for the opinions of execs or the CEO. Or the absolute worst thing, and this happens at Google all the time, they were notorious for this, is like launch readiness review, something or other. And you did all this work, you maybe worked for years as a team, and it's like finally you have one of the executives take a look at it and they say, no, I don't think this makes sense. We should have never shipped this. And it's just the most deflating thing ever. So figuring out what is going to be the operational cadence and almost the social contract between the founder CEO and the product teams and being really explicit about that, I think that is a really big unlock for making a really healthy relationship.

So I wanted to wrap up with the question that I normally do, which is when you think about your role as a chief product officer, who are the folks that have had the most outsized impact on you? And what are the specific ideas or way in which you work or behave that you picked up from them?

For me, when I think kind of early on, as far as I know, maybe it's not true anymore. No one used to go to school to get a product management degree or to get a certification in product management or anything like that. It's something that most people kind of stumble into at some point. And I was the same, and I was pretty fortunate to stumble into it on an internship in college. But I think throughout my career, And I feel like this is something I try to emulate myself, is there were a lot of folks who took bets on giving me runway that I don't think were at all clear I was going to be able to work with, but were betting on kind of the trajectory of how I could grow and how I could stretch, opposed to literally who I was at that point in time. And I think that's probably the single thing that if you're looking at your own career is finding environments where the organization or the leaders in that organization are willing to make bets on people who obviously aptitude, but also hunger and creativity and willingness to stretch and grow. I think throughout every company I've ever worked at, that's been a super lucky and common part of when I feel like I've been able to kind of accelerate my own development or accelerate my own career. I think at a company it can be harder as maybe you get into more senior roles to feel connected to people who can just be like a sounding board for you because How you need to lead when you're leading an organization is very different than when you're obviously an IC early in your career. And there's a number of folks without mentioning specific people from really honestly adjacent functions to product where they become the person that you can just DM or hop on a huddle with or whatever it might be and say, hey, I've got this half-baked idea. Can I just use you as a sounding board for a minute? Or here's what I'm thinking about doing, or here's something I'm thinking about telling the org about. Tell me what you And for me at least, I don't know, I'm a pretty maybe talked out kind of person. I find it so helpful to have that small network of people inside Slack where I can rely on them as trusted sounding boards, where we have enough trust that they can also tell me, they're like, that's a really bad idea. I definitely rethink that. Or have you thought about this other approach? But who aren't necessarily directly on the team, so they have a different perspective. They're not so immersed in the details. So that's been pretty amazing. And then my wife Monica has been, I think, throughout someone who has forced me to be much more, I think, introspective and reflective and frankly kind of just like emotionally connected, not just in our personal life, but even bringing that to work. And I think I definitely show up in my working life in a way that much less kind of maybe maniacally about impact and productivity and velocity, though those things are all very important, and much more, I think, in a way, hopefully that is a little bit more kind of balanced and taking in all those softer things and the vibes, if you will, and caring about those too. So I think she's pushed me to kind of bring a more holistic version of who I am outside of work to work. And I think that's changed a lot about how I actually operate as a leader at Slack.

Awesome. Good place to end.