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

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

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

Noah Weiss: 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, you know, 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, you know, down an incremental path. 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, I don't think you can just rely on data as a total crutch for. But I, 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.

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

Noah Weiss: It's a good question. I mean, we were literally having a product review yesterday. We're working on a entirely new kind of user interface and visual design and 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 four steps to two 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, in a series 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 gonna take things strategically, you can definitely run an experiment and make sure you're not shooting yourself in the foot cause you like forgot to add a button for inviting people.

But you're not gonna 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 own 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, you know, 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 changes, and definitely for most early products, you don't even have the scale to actually be able to say, we ran a test. We 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.

Brett Berson: 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.

Noah Weiss: Yeah. What I would say is the kinda beginning of any project begins the same way, which is what is the problem we're trying to solve for customers and, 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 gonna have to learn about through other means? I think an unhealthy Approach sometimes, and, and you can see this often with growth teams, is that you become so addicted by like 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 wanna 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 gonna measure the impact is the right sequence of things.

Brett Berson: 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? 

Noah Weiss: 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 hold back. 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 wanna understand whether customers love.

We're gonna use data to inform that, but we're gonna make a more gut intuition and strategic decision whether we decide to ship it.

Brett Berson: Are there any examples that popped 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 could be much more data driven, or something that seemed quite data driven, but you found the optimal strategy is to lean on judgment.

Noah Weiss: A good example of the latter, which is that, this is probably mid 2020, we had actually done a ton of, I mean, really great data-driven work to really think about the optimization of that kind of initial new user, new team, sign up 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 a, 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 trying to do 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 cause we couldn't kind of walk our way down and back up pretty 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.

Brett Berson: Do you think taste and judgment and intuition can be taught? Or PMs either have or they don't?

Noah Weiss: I mean, this is maybe my, 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. You know, 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 problems, spaces to like build up that intuition yourself. so I think you can definitely build it a hundred percent. I don't think anyone's like innately born with it. I dunno if it's like 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, you know, two decades.

Brett Berson: 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?

Noah Weiss: 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, you know, the book is a really, I think, good example of it where you kind of wonder like 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 the same area for a while to force you to step back and bring fresh eyes to it.

And then, you know, 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.

Brett Berson: 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.

Noah Weiss: I think it's definitely true and I think, you know, when I started my career at Google in search, it was kind of this like unbelievably perfect garden for letting a hundred 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 wanna make sure, I mean, I'm paraphrasing a little bit, the 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, that was the idea.

And it turns out you can decompose that problem into a hundred 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, like 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, like 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 two 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 three year strategy internally. 

So that's kinda what people are aligned at at a high level. But then at a more tactical level, we have these product principles, which really started probably five 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, 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, they've stood the test of time and we've only maybe swapped one over the last couple 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.

Brett Berson: In, in this sphere of, intuition led product building, what, 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've imagined. maybe you still haven't quite figured it out.

Noah Weiss: 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 gonna 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 connected tissue that ties hopefully your entire organization together with each other and also hopefully all the tools that you use since this very open platform and ecosystem. And I think, you know, to be honest, one of the things that we've really debated is obviously Slack is not gonna 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, uh, 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 a new area that we wanna invest in. There's always a hard and tricky debate.

Brett Berson: 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 you think that most people can flex in most directions. 

Noah Weiss: 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, you know, key competencies that we look for when we hire people, we think about, you know, product strategy, driving for impact, execution, technical and data ability.

No one person we hire looks like a perfect sphere. So what we look for actually is people who have clear spikes on one or two of those axes and also is well-rounded, but what are their superpowers? It's one of the things we talk about when we bring someone to 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.

You know, so for example, just to pick two 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 wild.

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.

You know, 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 a application perspective, are very different between those two 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 you know, where's the place, I wanna 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.

Brett Berson: 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.

Noah Weiss: That's a good question. So what I would say, I think especially in this hybrid or remote world, whatever you wanna 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, you know, 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 should we be moving 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, you know, 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, you know, the last thing I would say is we talk a lot about the vibe of a team at Slack. 

Brett Berson: Very, Very, Gen Z 

of you. 

Noah Weiss: Yeah. For 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 know, you can't all do it in the same physical place, it was much easier when you're 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 like 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 uh, softball one as well.

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

Noah Weiss: Yeah. I mean, maybe the last part is harder to answer cause 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, you know, a lot of people talk about being, customer obsessed.

Well what, what does that even mean? And I think at Slack, we have kind of two 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 like focused on crushing their competitors and, oh yeah, we wanna 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 our competitors kinda sensibility.

But customer love we've always had is 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, and to your point, maybe this is counter to what most enterprise CPOs do, focusing on how do we generate more customer love? How do we build that consumer great 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, 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.

Brett Berson: 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 passed this test.

Noah Weiss: You know, 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, all in the world of SaaS, obviously everything consumer looks like what I just described primarily.

you know, I think if you look at Shopify and 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, you know, these companies are all early on in their life cycle.

I think give it another decade. And I think, you know, the companies that are a 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. 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, 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, you know, 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 gonna 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 like end users and FP&A love your software.

I don't think that would be a great strategy. 

Brett Berson: Why do you 

think that 

is? 

Noah Weiss: 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 gonna 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, you know, 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 of the ICs in the organization who are interacting with it very frequently. Making them love the software is not gonna create advocates on the buyer side. And so I think that's probably, if I was gonna 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. 

Brett Berson: 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. 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 changed 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.

Noah Weiss: Absolutely. In some ways, to your point, the 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 two together? 

So you have a 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, you know, we've obviously figured out, a, 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 two 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, the 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, you know, that product principle, prototype the path.

We always thought 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 'til you've built confidence that this is gonna 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, see, they had this huge reinforced 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 to 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 that'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, opened my eyes to what it looks like. And then you are like, by the time they're on stage, they're 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're so confident that's gonna stick, not cause they're just winging it, they've actually de-risked it, invalidated every step along the way. So that, 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.

Brett Berson: 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.

Noah Weiss: Yeah, I would say from a marketing perspective, we've pretty closely integrated the orgs. They're still a, 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. You know, 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 kinda live together as a suite if you will, products that are integrated but fairly independent. I would 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've flowed 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, you know, I dunno, 77 of the Fortune 100 use Slack and probably a hundred 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.

Brett Berson: 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.

Noah Weiss: It's interesting. I remember at an executive offsite, this must be like six 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 was 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, you know, asking the most naive questions because most of us had never worked on enterprise software before. And I think we'd maybe asked him how do you think about pricing for the enterprise? And he says, you know, 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 is 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 two 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 the initial 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, you know, 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 skew. 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 to the early days of our learning journey there and figuring out how to take some of their best practices and apply 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.

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

Noah Weiss: 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 p-, 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 organize 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 back stopper, 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 like, 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 a pre-read. If we're reviewing a design, we'll often have people wind up sharing like a clip which is a 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 gonna be reviewing let me explain the why behind it. And, you know, honestly, as someone who's gonna 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, you know, watch it on your time when it's convenient for you. And then everyone comes in to 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 presentation.

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 deal that happens is that you get just like carte blanche approval for everything and it's all about check boxes 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, this is 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.

Brett Berson: 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?

Noah Weiss: I think one of the, biggest things I think that'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, you know, 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 wanna 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 know, 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, I would say, see a team with a really good vibe, here's some of the 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 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 like 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 like you can kind of just tell.

I would say when there's a team that is like 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, I actually ask PMs when I do like 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 like, what's the latest of your deliverables or anything like that. It's how much fun are you having? Like is the team having fun? Like 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 everyday.

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, I don't know, command and control environment where, that doesn't work. Or maybe at a hedge fund it's, 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.

Brett Berson: 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 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, the decision was poor.

And the problem is if you, if you don't recognize the quality of the decision that's poor, bad things happen cause you take the wrong lessons from it. The lesson there would be drinking and driving is totally fine. And you could 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.

Noah Weiss: Yeah. No, it's a great topic. I was just thinking back to that the last thing you were saying, which is, Annie Duke has this really good book, I think it's called like Thinking in Bets. I'm a real crappy poker player, but you know, the book is accessible and, you know, she talked 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, you know, the final cards hit the table and you happen to take the whole pot.

So definitely I think when you look at quality decision making, you, 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.

You know, when I think about pace and quality decision making, I think to why is that never a complaint for a small startup? You, you almost never, hopefully, you would know better than I would actually from the investing side, but, but if you talk to folks or when I was at a very early stage startup back in the day, you know, it's 10, 20, 30, 40 people, no one even knows whether you're making quality decisions cause you may not even have a product in the market. You know, people are generally saying, I'm working like crazy, I'm doing seven different jobs and I just wish we had more people, but we know exactly what we need to do. So what's different then?

To me there's maybe two or three key ingredients. So one, I think there is a tremendous amount of shared context that 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. Two, 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 in 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 org that's struggling on 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 or whatever it is they're trying to decide? The answer is almost always no.

Brett Berson: Why, why is that?

Noah Weiss: 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 like present a three 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, 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, you know, exec at the very top between those two 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 the what could happen if you make the wrong decision and it becomes paralyzing. And so the natural, I think, inclination is then I don't wanna personally risk making a decision that is wrong, to your point about looking at the outcomes and then getting an 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, you know, 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 gonna be personally attributed, then I think you can start driving the pace and quality of execution and decision making a lot more.

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

Noah Weiss: 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 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, you know, 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 gonna 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, with trust.

I think it's, it's that knowing that that's gonna happen, that's the expectation within the organization. And then the risk taking, I, I think that is tractable. Amazon has this kinda delineation between one-way door and two-way door decisions. We borrowed 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's can be 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 in focus group testing and everything else so then no one person feels like I came up with a tagline and it didn't work.

But that is an incredibly easy to reverse decision, to change, to update. And so, you know, 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 they actually, you do need to have the slower pace of decision making.

You do need to be more judicious. You wanna 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 gonna 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, you know, we talk a lot in engineering about this idea of like a blameless post-mortem, which is, you know, there's an incident and an outage, whatever it might be.

You wanna do a post-mortem 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 results 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 you know, 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, is 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 gonna be wrong a good portion of the time anyway.

And that's okay.

Brett Berson: Is there anything else you do specifically to get people to make big bets? Do you think about it as a portfolio where you wanna 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 like 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, you know, similar to I think venture investing end up building like the next pillar of the business.

And any thoughts on like managing for that?

Noah Weiss: Yeah. It's one of my favorite things to think about because it's hard and the inclination over time is to have have you know, a localized team where you're really focused on a subset of the feature space and you have one or two KPIs, and in any given quarter, you know, you feel like success for you, for the team is, you know, 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 five or six 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 a thousand 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, uh, 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? You know, not every team should have the same allocation in terms of, low risk versus high risk, long-term versus short-term, certain versus uncertain type 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 it as, you know, 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, you know, 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? 

Brett Berson: 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?

Noah Weiss: 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/2 /3 or something like that. but then we have certain organizations that are maybe more 30/40. You know, across the board, I would say we probably look, my, my hunch that I haven't actually like 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 kinda make it less scary about taking these swings is we, we have this idea, we kinda talked 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 like hill climbing machine learning sense of it, but if there's a mountain scape 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 gonna spend the next five 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 could be a multi-year bet into something that incrementally improve 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.

Brett Berson: In this theme of decision making and operating, I'm super curious, given you've been at Slack for almost eight 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 eight years to see maybe a few different chapters of of Slack, are there things you think of maybe in the realm that you're most involved with that you've had to like meaningfully change your mind? Not kind of the generic sort of stuff, but maybe you were hearted in one way and you realize 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.

Noah Weiss: No, that's a great question. I was just thinking back over the years of the biggest examples of this. And I'll, I'll give two that are both sides of the coin that you just said in opposite direction, which is kind of interesting cause it kind of mirrors our evolution as we scale the company. I, I first joined Slack the very beginning of 2016, and I remember it must have been a couple 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 came over 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, uh, 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. Uh, and to really kind of build more of a, enterprise grade organization that wasn't purely product led. 

So that, that was one obviously which worked. I, you know, I think we got to, I wanna say $80 or $90 million in the ARR before we hired a head of sales. 

And it'll probably be much bigger now cause 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, three times a year, and we get to test the releases before they even go out the door. And you know, 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 rotate the organization on focusing on those enterprise blockers, really slowing down the pace of, you know, core product momentum. And that was a trade off. It was somewhat explicit. But I think what happened is after a certain period and it really turned around in 2020, I think the move to hybrid remote created this new imperative from our customers that they suddenly had, you know, 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 you know, the reality, I think if you're, you know, to your earlier kind of discussion, a multi-billion 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 kinda original DNA and founding culture, six or seven years after launch and I think that's what's kind of propelled this last chapter of the last couple years at Slack.

Brett Berson: When you look at those pivot points, when you or the executive team changed 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?

Noah Weiss: I, I mean, I don't know if I would say there's repeatable organizational practices that let us do that. And 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 like 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 of turning points came from. But as we get bigger, you know, I think over time it becomes harder to make those shifts. The way of working becomes a little bit more endemic. So, you know, I definitely think it was easier to start hiring up a sales team when we were, a couple hundred people, uh, than it was to change the culture of how we build product for enterprise grade versus, product innovation when we were a thousand people in the product and engineering org. Uh, so those changes, yeah, just inevitably become harder as the ship gets bigger.

Brett Berson: 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 three, four, or five hours exploring this topic and it's 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 their 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 up market, 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?

Noah Weiss: Yeah, I, I can think of awful lot of conversations the last couple 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 up market? Is it the right time? Because it can be a huge amount of investment in distraction, not just in the product side obviously, but also in 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? I'm not saying 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 an enterprise sales motion. So I, 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 two 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 two ways I would assess that is one, are you just getting a lot of inbound from a large enterprise 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 a lo- larger 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, yeah, I think some of them are obvious now, but definitely for us, I think took a while to figure out. So, one, you know, 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 or a salesperson, it gives you a tremendous amount of leverage to lend your sales team. So, you know, if you switch to the sales world, you start thinking about, you know, account exec productivity, you know, 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 headstart 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 or that you're standing up. So having the data visibility into bottoms up adoption and usage based metrics, having the ability to qualify those leads.

Having some amount of marketing or 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, and they're like horrified, they didn't even know that was the case. And we say, no, no, no, it's okay. We actually just wanna see how we can help you figure out, you know, can we make the people 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.

Brett Berson: And do you think you often see people when they think about enterprise, they think about outbounding 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.

Noah Weiss: 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 set is, but I know when we went public, we had a set, I think it was 85% of our enterprise deals by the time we went public at our IPO, uh, 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 popular 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.

Brett Berson: What about one other topic that is re- 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? 

Noah Weiss: 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, leading up a function, and the CEO before they were the CEO, that function is an 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, cause that person will be able to be world class and push you the hardest. And also it's probably the most fraught. You know, thinking back to Foursquare and obviously Slack, both that had product founder CEOs, I mean, a couple things stand out. I mean, obviously there's all the basics that you wanna build, mutual trust, and kind of a shared understanding of how to operate in each other's proclivities and frustrations, all that kinda stuff.

But I think beyond that, what I would say is, is two 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 division and the strategy, not just for the next quarter, but for the couple 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 like 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 up 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, you know, back to Slack, like when we were working on huddles.

You really wanna focus in the beginning with the team and with the founder. You know, do you have agreement about what are the goals? Why are we doing this? Why do you think we're gonna be successful? What does the competitive dynamic look like? What is the impact we're gonna 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, very end, and again, it depends on the founder, but you know, 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 wanna get them an opportunity at the very end of the project to be able to like 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. You know, again, this is the point about how do you make it constructive and not a review or launch, decision meeting, but working with the team in a early 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 four or six 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 par.

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 taking a look at it and they say, no, I don't think this makes sense.

We should've never shipped this. And it's just the most deflating thing ever. So, figuring out what is gonna 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 healthier relationship.

Brett Berson: 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 like the specific ideas or way in which you work or behave that you picked up from them?

Noah Weiss: 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, you know, get a, I dunno, certification in product management or anything like that. It's something that most people kind of stumble into at some point.

And, I, I was the same and I was pretty fortunate to stumble into it, you know, on an internship in, in college. But I think throughout my career, and I, I, I feel like this is me, I try to emulate myself is there were a lot of folks who took bets on giving me a runway that I don't think were at all clear I was gonna be able to work with, but were betting on kind of the trajectory of, 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, you know, 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, 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 you know 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 kind of 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 kind of telling the org about. Like, tell me what you think. And for me at least, I don't know, I'm a pretty maybe talk it out kind of person. I find it so, 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'd definitely, I'd definitely rethink that. Or, uh, have you thought about this other approach? But who aren't necessarily directly on, on the team. So they have a different perspective. They're, 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, not just in her personal life, but even bringing that to work.

And I think I definitely show up in my working life in a way that is much less kind of maybe maniacally about impact and productivity and velocity, that 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 of those softer things and, the vibes, if you will, and caring about those two.

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.

Brett Berson: Awesome. Good place to end.