Noah Weiss: How to Master Product-Led Growth; Scaling PLG to Enterprise at Google & Slack | E1026

The most important feature by far for any product is actually speed.

Noah, I am so excited for this. I've really been looking forward to this one. So thank you so much for joining me today.

Thanks so much for having me, Hari. I've been a longtime listener, excited to finally join.

Well, that is very, very kind of you. Now, I wanted to kind of chronologically unpick your career before we dive in, and start as your career starting as PM at Google. What is the single biggest product lesson you took from the 3 to 4 years or 2 to 3 years at Google? And how did that impact your mindset?

Yeah, I mean, Google is definitely where kind of I started my career in product and was the most formative part of my kind of journey there. And I think the thing that struck me the most, because back then I worked on a feature team within search, but you kind of saw how the executives viewed product strategy. And back then they used to have this model, they called it the 70-20-10 model. And it's actually a pretty fascinating way of thinking about just a product roadmap and the distribution within it. So 70% of the product teams were focused on what are things that are known valuable things for our customers that are in some ways more incremental. 20% were new product areas that had already kind of taken off, but they were trying to further refine and incubate. So, you know, after Gmail took off, how do you scale it to a billion users? And then 10% were the far-out bets, the self-driving cars, the, you know, Android before Android existed, the building a web browser. And I think the thing that stuck out to me was the combination of that deliberate approach to what the portfolio looked like and the constant kind of Larry and Sergey refrain of whatever your ideas you bring to them, what would 10x a bigger scale look like? So I think that caused a level of ambition for product thinking at Google that it's kind of hard to afford at most early-stage startups, but I think it's aspirational to bring to every company.

Can I ask, do you do the 70-20-10 at Slack?

You know, it's funny, I feel like it almost became so well-known from Google that it would feel a little bit cargo culting to bring it exactly. But we do talk a lot about kind of the portfolio and diversification within different product areas. So, you know, we might ask a team, when you think about the breakdown of your roadmap for the next 2 quarters, Where is it allocated? How much of this is maintenance, performance, and quality? How much of this is refining and kind of customer delight? And how much of this is you're incubating new ideas, you're trying out new levers? So we don't call it 70-20-10, but it's definitely part of how we look at the structure of productivity roadmaps and try— and every team is different too. You know, even at Google, I would say that was at the corporate level, but take a team like AdWords, Their allocation didn't look like 70/20/10. They might look like 95/5. So I think it's an interesting framework, but I don't think it is something that is like a perfect ratio to apply in every context.

Can I ask, you then go to Foursquare and you spend 5 years plus at Foursquare, I think 5 years and 1 month according to the trusty LinkedIn. What's the biggest product takeaway for you from Foursquare? It's a fascinating product actually to have the experience you did on. And how did that impact your mindset?

I mean, the thing I would start off by saying is I think you wind up learning a lot more. It doesn't matter what your role is when you're actually faced with a lot of headwinds. And when everything's going up and to the right, you think everything you're doing must be brilliant. You know, you throw something against the wall and the metrics keep rising. And so I think it's really hard. And I think this is a knock on, I think sometimes folks who have only worked at large companies is you have so much tailwind, you have so much momentum, you have so much distribution. You don't learn how to manufacture that from scratch, or you don't learn how to turn things around when things go sour. Within the context of Foursquare, and I've done so much soul searching and reflection and introspection, including a lot of the folks who were there early on, you know, I think when I joined right at the end of 2010, for the next 2 years, the level of product market fit that Foursquare had in the early days of mobile, in the early days of social and location on mobile, was incredible. I mean, you go to Austin for South by Southwest and like the whole city feels alive. You feel you're seeing a version of the future where like you can have this map of everyone or everything and everyone around you. You're like, wow, it'd be amazing if everyone on earth used this thing. But I think the thing I took away was that product market fit, people talk about it like it's a binary thing. You unlock it and then you have it forever. And I actually think a much more accurate model is that you unlock product-market fit, you get to maintain it for a while, but you have to keep renewing it as your audience changes and as the world around you changes. So I think with Foursquare, we definitely had to go past the early adopters who were so motivated by discovering the world, seeing new places, novelty, and the social side of it. And then also the world changed. And that's really, I think, you know, another part of the story with understanding how competition changes the backdrop with Instagram coming out. And really shifting how people viewed what it meant to share experiences in the real world.

Can I ask, I totally agree with you in terms of like the need to renew product market fit with the changing of company scale. What are the biggest challenges to doing that?

You know, I think if you look earlier stage, I think the single biggest challenge, because I think the first time you hit product market fit, almost every company, they're designing for themselves in some way. I think if you look at the founder story, you know, when people talk about like, what's the founder's right to compete in this market? What's their founder, you know, market story? It's almost always, I have this problem in my personal life, or I see this problem in my work life, and I want to solve it for me, and hopefully other people want it too. And so if I look at Foursquare, that was definitely the case with Dennis. His DNA was, I want to try going to every single place in New York City. I want to have this map of the world and my friends all superimposed together, and I hope other people want it. And it turned out at peak, 50 million people in the world wanted this too. Slack obviously was 2 stories of that. You know, the first was trying to build for this game that they wanted that didn't take off. The second version was, hey, we built this amazing tool internally. Maybe other people might want it too. Let's hope that there's a big enough market. Once you saturate that market, if you are lucky enough to saturate it and that other people do want the thing, I think the biggest first leap is, How do you have the self-awareness, the humility, and then the intellectual curiosity to learn about what is the next audiences that you should be kind of designing a product for who look fundamentally different from you? And how do you make that leap as an organization, as a kind of culture, as a frame of reference where you aren't your next customer? That's a huge leap and I think really hard for most companies to do.

How do you do that and how much do you listen to your customers versus independently progress on your own research and thought processes?

I think the easy answer or the straightforward answer is I think you have to get even deeper into your customers' lives and better understand by customer, the next set of customers who aren't using your product. So, you know, in the case of Slack, I think it was initially if you read the initial pitch deck, which they shared when they pivoted the company, It said Slack is a product for teams of 5 to 50 people. The initial conception of Slack was after 50 people, this thing probably won't scale. No one's going to want to work this way. So let's just design for those small, medium-sized teams and companies. And I think the biggest change was when we realized, just looking at the data, that actually small teams at large companies were loving using Slack in all these different pockets as they were springing up. But to actually make Slack work at a scale of thousands or tens of thousands of people, The needs of that type of company looked very different. The end users wanted the exact Slack product, but the organization wanted something very different. And so I think, you know, we had to spend— it was probably end of 2016, 2017, really immersing ourselves in the world of like enterprise controls, scale, security, compliance, talking to executives at companies instead of just being the insurgent and getting closer to them. Not because everything they said we should take literally, but because we weren't designing for ourselves because we were only maybe 200 or 300 people back then. So you couldn't know what a 30,000-person company actually wanted. You have to actually go talk to them and find out and then incorporate it into your view of how to evolve the product.

Now, before we move into that kind of scaling up into enterprise, you mentioned that the 5 to 50, I do just want to touch on kind of the foundation as being kind of product principles. And you said before the show to me that your organization needs product principles. Can I ask first, what are product principles and what did you mean by this?

Yeah, you know, I think product principles are a way of enshrining the culture and beliefs of your product organization into a common language that everyone at the company can easily refer to as a shorthand for making quick decisions and for making kind of qualitative assessments of the level of craft of the product. And so for Slack, we don't have to walk through all of them, but I would say probably, I want to say maybe 5 years ago, so a couple of years into the company, what we realized, I think the why behind why we created these was as a company was scaling and the average person who's working in product development is kind of further away every day from working with Stewart, who is the founder, CEO, and very product-led, it became harder to figure out how to instill the kind of fiber and DNA of how the product was initially built into teams that were further away from that origin and further away from the founder. And so what we realized was you couldn't just have Stuart spend all day in meetings with every single product team. How do we scale the culture and how do we make it easy and memorable to reference? So we came up with a couple things like don't make me think and be a great host and Perfect the path and take bigger, bolder bets. And we can unpack any of them, but Okay,

let's unpack them. I'm gonna be deliberately contrarian. They're all quite general and like bigger, bolder bets. I get it, but kind of nuanced. Like if I'm gonna come with an idea that's like bet the company, you're telling me to take bigger, bolder bets. Why should I bet humanity? Do you know what I mean? Like help me understand those 'cause they seem pretty challenging.

Yeah. I mean, I would say none of those, if you said them, allow, would someone be like, wow, that's a totally contrarian idea. You know, what are you talking about? But I think they mean something into the context of their organization. So for example, when you unpack these, what we mean when we say take bigger, bolder bets is as a company scales, I think there's a tendency towards incrementalism and kind of local optimization. You know, you have bigger and bigger organizations, you have feature teams, The feature teams may have a single KPI that is the one thing they feel directly accountable for. And the natural tendency is, you know, I view my success, my team's success to move this single metric. The easiest way to do that is incrementally with very small experiments. So I can say, hey, we move this metric by 0.6%. And that's kind of antithetical to if you're saying, hey, actually our product is much earlier in its journey. We're defining an entirely new category. No one else has created this space. We're the ones who are creating this space. Yes, we need to do things that are incremental and refinement, but we need to balance that with taking huge swings to push the concept of this category for customers.

But because I'm, I'm like, in Product Principles— sorry, we're having a great discussion. I like this. Product Principles were like, the best communications are the easiest. If we have that as ours, every single person knows that whatever decision we're making, we're optimizing for ease. Now, that may not be speed, it may not be rigor, but ease of customer communication. That is something that every decision can relate back to, whether you're doing Clips, Hangouts, Messages, ease of send.

Yeah, I think the one that— the 2 that are most like that for us is be a great host. And don't make me think. So be a great host. The story that we tell with that is, you know, have you ever been to a friend's house or an Airbnb or wherever it is, and you go to your guest room and you're kind of looking around and the bed's made and you go to the bathroom and you're like, there's towels hanging, but are these towels used? Are these new? Did someone set these towels aside for you? Like, how do you know the towels are actually meant for you? And the simple thing of folding the towels, putting them fresh on the bed, so you know that like these towels are literally meant for you, that effort of being a great host, making the bed, tilting your umbrella, kind of rounding every corner, that level of care and consideration of the focus on kind of craft and being a host, because Slack itself is an environment people spend their day in. It's just a digital environment. I think that probably is that single manifestation of what it means for us to build an incredible product experience for people who just happen to be at work. So that's probably the most along the lines of what you were saying.

What do you think are the biggest mistakes startups make with product principles?

My hunch is that most companies wait too long to introduce them, whether they call them principles or maxims or design guidelines. It doesn't really matter. But I think it's really hard if you're a product founder and you're a founder-led company. I mean, there's all types of things that are hard as you transition and scale the organization. But I think one of the hardest things winds up being when do you give up enough control that your organization starts building things that you aren't even aware of? And then how do you have enough trust that the people building it are going to build it up to the standard and approach that the company was founded on. And I think that's kind of the leap, but I think most companies wait far too long and the organization starts going slower and slower, and then the CEO starts complaining, why are things slower when we have twice as many people? That, I think, is usually the process that happens. So, I would say probably waiting too long to enshrine the culture in a way that can scale.

You said there about kind of speed with scaling teams. I had Gustav Söderström, the CPO at Spotify, on the show recently, and he said, talk is cheap, and so we should do more of it. Meaning we should have more internal discussion, more debate around product, and that leads to better outcomes. I bluntly disagree. I think speed of execution is everything, and you should move as fast as humanly possible on non-core items. How do you think about internal product debate and whether it should be fast, slow, and what to get the most out of it?

I think I'm in more your camp, but I would say it fundamentally, I think, depends on the type of thing that you're debating. So I think it's Amazon maybe that was kind of famous for the kind of 2 classes of decisions. Like there's the 2-way doors and one-way door decisions. And the 2-way door being, I launch this thing and I can unlaunch it and there's no harm, no foul. The majority of things you're building as a product organization fall into 2-way door kind of decisions, especially things you can experiment with and then unrelease. One-way door decisions, I think, are very different. One-way door decisions are things like, The pricing and packaging model for your company, the brand that you're bringing into the market, if you're launching entirely new product categories and making a multi-year investment, those are one-way door decisions. So what I would kind of say, I think the thing that we've learned over time is separating the two and trying to empower teams who have context, understand the strategy, have principles to make as many two-way door decisions as possible locally. and not having to have a lot of talk and debate. And then on the flip side, really being clear, what are one-way door decisions that actually do need, in many cases, the entire kind of executive team's buy-in to actually make that call, make that investment? And then I think talk is cheaper than a bad decision, but that should not be the vast majority of product discussions, in my mind at least.

How do you do product reviews? Now, I'm fascinated. How often do you do them? Who's invited? What do they look like?

Yeah, it's evolved a lot over time. I would say where we are now, and, you know, for context, Slack has probably around 1,200 people across product design and engineering. So it's a pretty, you know, sizable team. Where we kind of are structured now is there's basically product pillars, which are kind of teams of teams that are responsible for areas of the product. So there might be an enterprise product team or the virtual HQ team that's responsible for huddles and clips and so on. Yeah. And what we've figured out works pretty well is that we have those pillars, the leads for those pillars do product reviews or product workshops on a weekly basis within the team. So the leads can kind of weigh in and give feedback and unblock feature developments that's happening. And then what we wind up doing is usually on maybe a biweekly or depending on their monthly basis, an exec review with the leads of each pillar, the PD kind of executive leadership. So the head of design, the head of engineering, the head of product, And try to focus those discussions less on, okay, let's run through the 15 features that might launch in the next couple of months and instead be like, what are those one-way door decisions that we need to really focus on? What are things around the product roadmap and the portfolio that we need to refine? Or if it's a really major launch, let's go taste the soup. How's it feeling? Is it up to the bar? What's broken? Where do we need to push on the quality bar? So that's kind of the cadence that we found, which I think works pretty well at this point.

How did they change in a world of hybrid?

I think the biggest change was they became more inclusive, actually, because what used to happen— I mean, you probably know this dynamic, right? It's everyone is familiar. You're in a room, and once the room gets to a certain size, it feels like you're not in a collaborative discussion. It feels like you're in a performance. And so back in the day when it was all in the same physical meeting room, it kind of felt like you had to set a hard cap. I don't know if it was 8 or 10 or something like that where you're like, okay, this is a single discussion. And so I think what changed in hybrid where, you know, you could have a much larger room but not feel like you're doing a performance as much is that the reviews, which I tend to love actually, is, you know, if we're reviewing a key product area, we have one right after this today about the new information architecture that we're working on, kind of a redesign of the Slack navigation. We're, I'm sure, gonna have many of the tech leads, some of the design leads, multiple PMs working on this project, all there in one place. And that doesn't mean that it's completely a chaotic discussion. We're still mostly having a review, but I think the beauty of it is it's more inclusive and people can have the context immediately instead of the tr— you know, typical trickle or cascade of information. So, in that way, I think it's actually been a real beneficial change.

You know, you're the only product leader who said a positive about it being a hybrid. Every single one, every single leader said it gets worse. The quality of discussion is worse when it's not in person.

I think it's hard. So, what I would say is it's harder as an executive. It's less fluid. But I think the team, I'm viewing it from the team's perspective, I think they actually can enjoy it more and get more out of it instead of the typical, it's a closed door, it's 6 people in a room. Definitely this is not true of hardware. Talking to friends, for example, at Apple, I think as soon as it was physically safe, they need to be in the physical environment to actually touch the thing. But, you know, also I would say the other thing that's really changed is we do much more of what typically was in a synchronous review asynchronously now. ahead of time. So whether it's pre-reading or people record clips of demos that people pre-watch, so then the actual review is the part that needs to be synchronous discussion. But so much of the work that used to be in the meeting can actually be split off and people do asynchronously on their own schedule. I think

that's actually— How do you do that? Is that with Miro boards? Is that with— what does that look like?

Yeah. I mean, I'll hate to confess, but obviously, you know, we use Slack for a lot of these things. But what I would say is the most typical flow would be someone will write a doc that kind of frames what the discussion is, the key context decisions, you know, whether they use Google Docs or Notion or Canvas, which Slack just released. But I think the big thing that's actually happened is designers and engineers now will record clips with screen sharing in Slack. And it'll be a quick 3 or 5 minute clip. And if it's a designer, they'll be like walking through a prototype in Figma, or if it's an engineer, they'll be doing the same but with real live code. And they'll actually show you the thing instead of say, hey, let me, you know, the classic meeting otherwise is a 20 minute presentation. Everyone's sitting there being like, okay, I wish I could just go through this quickly on my own. Now it's everyone pre-watch this thing and then come in with your perspective, your ideas, your feedback so you can get straight into the discussion. instead of having half the meeting be a presentation. So I think that's made a big difference, honestly.

Can I ask, what's the biggest broken process part of product building today for you in Slack that hasn't yet been resolved?

I'm trying to think of something that's going to be more general for other folks as well. I still think, you know, we love using Slack for building Slack, obviously, but I think the thing that is still hardest to see is kind of that bird's eye view of what is actually the latest state of the world for all the major areas going on at the company. And I think Slack itself definitely doesn't solve that. Like, yes, you can be in all the channels, but for me, if I just open up a random team channel, it's gonna be really noisy. It's gonna be hard to know like, what is the actual latest? Should I be reviewing this thing? Is this just team discussion? You know, we wind up solving this like most people do at the end of the day, use spreadsheets. So we have a Monday meeting, PD Monday meeting as we call it, where like literally we just review in a spreadsheet, super manual process, but the top priorities for the quarter and latest updates. And it gives that kind of operational cadence to the quarter. But that's a solution that, that is not very elegant and is not very software. It's about as old as spreadsheets. But I think a lot of organizations rely on that and software is too rigid often to be able to solve it.

Dude, the enemy of most SaaS companies is the spreadsheet. So I think you're not alone in terms of that. I do, I do want to ask, we've mentioned obviously Slack so many times. You are the masters of PLG. You've been building one of the iconic PLG products for the last 5+ years.

Yeah.

What does it take to build great PLG products? Well, what works? What doesn't?

I mean, the really funny thing to me about all this is I think Slack is often, you know, to your point, you refer to this as one of the original companies who kind of started building in this space. I'm pretty sure at least that I definitely had never heard of the term product-led growth when I first joined Slack 7 and a half years ago. And I think the term of art kind of became something far after Slack started working and using techniques that maybe the term became associated with. So definitely I don't think anything that we did was a playbook that we were taking that, you know, we read that we were applying. I think it was more innate to how we built software. By far, I mean, this is going to sound really touchy-feely, but I think by far the most important thing is thinking about building a real consumer-grade experience for people. The people just happen to be working instead of in their consumer life. And what we used to say a lot is, you know, why does someone at work deserve a software experience that feels so much more painful than what they use nights and weekends? You know, why is approving an expense report or doing something in your HRIS system harder than filing your tax returns every year? It doesn't have to be that way.

How do you preserve simplicity with scale and with time?

One of the things, you know, we have product principles, but I think when you go to the actual mission and vision of the company, it hasn't changed, I want to say, for at least 8 years now, which is to make people's working lives simpler, more pleasant, and more productive. I mean, that truly is literally like— I mean, you could probably Google it. That's the mission of Slack publicly. And so I think everyone here, when we're thinking about how do we build, what do we build, what does the quality and craft bar look like, it does always come back to is this simple enough? Is this delightful? Are people going to be more productive or more confused by the complexity that we're introducing? And I think the other way that we do is through hiring. You know, the vast majority of people who have worked at Slack on the product and design side had never worked in enterprise software before.

Is simple always better?

I think simple from a— it's easy to understand and easy to comprehend. That is always going to be an important and good thing. No one wants something that they feel dumb or confused by when they try to use. But I don't think simple— and we talk about this a lot internally— simple doesn't always mean fewer clicks. So for example, I think in a lot of consumer, you'll, you'll say, okay, you know, we want to remove as many clicks as possible or remove as many options, give less control. But I actually think in enterprise software, often more clicks can be okay because you bring people along. So a guided flow where you're only making one decision per screen can actually perform a lot better. I'm not worried about drop-off. This is not a conversion funnel. You're helping people feel like they have mastered the software that they're using and feel confident in what they're doing. So I think simple is about how understandable something is, how comprehensible it is. It isn't necessarily how streamlined or how few clicks it is.

Can I ask, when you review many of the product decisions you made with regards to like the product-led growth features at Slack, What are the biggest— if you were to choose actually a biggest PLG product feature mistake, what was that and how did that change how you think about product today?

I'll do 2 because one is not specifically necessarily PLG, but I think kind of affects the motion there. So the most obvious PLG one is that Slack always had a really generous freemium model. Like, you know, you have a free plan, you can use it as long as you want. There's no cap on users. The really only significant cap is just on how many messages you have access to, how many files you can upload, and so forth. That, that was great. I wouldn't take that away. But what we didn't do for many, many years is actually never gave people a rich, valuable trial experience of what the paid product looked like. And when you learn this in user— this maybe sounds obvious in hindsight, but in user research, what we realized was that many people had habitually used their free plan and didn't even realize a paid product existed because we're not banging you over the head with it inside Slack. And then kind of just was like their conception of what Slack was had all the limitations of the free plan. And so they almost viewed it as, oh, it's meant to be ephemeral. Like, you know, the conversations disappear. You know, this is back when maybe Snapchat was really taking off. So people kind of thought that was the point of it. And so we wound up building a really robust in-product trial program, many ways to flow into it, a guided experience to help you make sure you're getting the value out of it. And that was probably, I mean, honestly, the single biggest thing we did on top of the freemium model to really push that self-service-driven paid conversion.

How did it change your mindset? Like when you reflect on that, how do you think differently as a result?

I think for a long time we had the perspective that if you use Slack for long enough, you'll eventually decide to pay for it because it'll be obviously valuable to you. And I think what changed— I mean, I remember when we kind of reviewed this and kind of wrote the maxim is What we want to do is give people such a great taste of the full Slack experience that they never want to go back. And that's it. That's a change. Instead of assuming that they'll discover it on their own and that they'll have the intentionality, it's actually how do you give people a taste of that? How do you walk them through it? How do you make sure they fully utilize it? And then once that ends, they're like, oh my God, I would never want to go back to the free plan. Like, this is so powerful. This changed my entire organization. So I think that was a big change there. The other thing which I was gonna mention, not strictly PLG, but I, you know, we have this product capability called Slack Connect, and the whole idea is take a channel, now you can share it across multiple organizations. So we could use Slack Connect between companies working on a project together, between vendors. You know, we have Slack Connect channels with every one of our customers to do customer success and support. You know, Stripe's head of sales famously said, you know, once through the Slack Connect channel with a customer, I know the deal is going to get done. Amazing. Customers love it. It's great. But the thing that I think we were, you know, maybe overly cautious on is we were really, really slow to deliver, bringing that product to market because we were really worried that people's mental model of Slack was very much that it was this walled garden for my organization. You know, there was no external notion in Slack. It was whatever was in Slack was just fully internal. And we were really anxious, frankly, about breaking the walls of that garden with this idea of Slack Connect channels that could connect you to other organizations. And then to your point about simplicity, does people's mental model what Slack is get more blurred? And we took a really— I think we probably had it in beta for about 2 years. It took a really long time to bring to market. And I think frankly, especially given the competitive backdrop there, I think if we had not rushed it but expedited it into market back before there were more products that, you know, people were starting to use or get for free as defaults, and back when I think kind of the ubiquity of Slack was something that felt like maybe inevitable, this could have created enough gravitational pull for our existing customers who love it just force the rest of the world to come use it with them. And I don't think we missed that moment, but I do think that moment was delayed enough that maybe we missed some of the more like exponential return to having brought that to market earlier.

You mentioned speed there. I'm asking a tough— I used to be so nice on the show when I was younger. I'm asking the tougher ones. If we're honest, I'm sure you hear what I hear. People say the speed of innovation at Slack is slower today. What are the biggest bottlenecks to the speed of innovation in Slack?

Yeah, I mean, I think where internet was most true was 2018 to 2020. And I think I would— I think we would fess up to it entirely because back then, you know, this is again, I don't know if we could have done it differently. You're a small company, you can't do everything at once. But that's when we really made this kind of hard rotation on focusing on the enterprise buyer, the enterprise organization. And I think we did prioritize for a while kind of scalability and solving those really complex, you know, Fortune 500 use cases and compliance and security needs. And I think we did take the eye off a little bit that core pace of product innovation, of pushing the boundary of what this category can be forward. I think in some strange ways, like COVID was a real wake-up call for us because suddenly even our existing customers were coming to us and saying, oh my God, I'm living all day in Slack. That's amazing. But also now I have all these other needs and can Slack fill these needs or do I need to look in other places for them? And so I think starting the end of 2020 through now, I would say, and this is not a rebuttal, but my perspective at least is that I think, and our customers are feeling this as well, that the pace of innovation has kind of increased pretty dramatically. You know, you have Huddles, you have Clips, you have Canvas, which was just launched, you have Workflow Builder.

And that is because you have clarity of understanding who you're building for, be it the enterprise buyer?

I think what it actually is, is that we, I think, got to the place where we realized there was diminishing returns for focusing the majority of our efforts on the enterprise buyer. Once you get through a lot of the blockers that are just, hey, the CIO is going to say no unless you have DLP and EKM and IDR. I'm not going to go through all the 3-letter acronyms that will be blockers. But once you do all of those, then you start realizing kind of what we felt all along, which is you want to keep pushing the capabilities of the product for the end users, for the teams who are trying to work in a more productive, delightful way. And those teams need new things. And it felt like, honestly, and Stewart said this publicly too, the pandemic and the shift to this hybrid world, I think, kind of gave us almost a new level of meaning and urgency to the work that we were doing, because the level that people were depending on Slack, the expectations they had for what Slack could do, had just grown incredibly, basically overnight, because you couldn't be in the same physical place. So how do you replicate or how do you at least facilitate that sense of connection you have in the office, the sense of awareness and visibility? How do you do that in a way that feels native to Slack and doesn't feel like just like recreating the physical space? Those things became huge imperatives for our customers and thus for our product team.

Now, you mentioned those 3-letter acronyms. Most people have no idea what they mean because generally most people don't have to scale into enterprise, but many startups do. And many startups actually, I think, Respectfully don't understand quite what it takes. What do you think are the biggest mistakes that startups who start in SMB make when they scale into enterprise?

Yeah, it's, it's hard because honestly a lot of the work is really kind of removing blockers. And I think there, what I would really recommend honestly is like, that's where you do want to hire people who have domain expertise. You don't want a bunch of folks who worked at an early stage startup, had never worked in enterprise before, to be like, let me try and figure out from, from first principles what like electronic key management is and why the chief security officer of a Fortune 100 company cares about it. This is not a place where you should reinvent the wheel. You should not take a novel approach. But the biggest mistake I think people make, and it's a little bit kind of reflecting even for ourselves, is I think over-rotating on the enterprise buyer where you think that they're inherently more conservative. They don't want features to be shipping every single day to end users because they're, in fairness, trying to, you know, centrally run an organization where they have enablement and education and so forth. And I think you can introduce— to your point about speed, it can introduce a level of cultural conservatism because the enterprise buyer will say, hey, I have these blockers. unblock them, and please stop shipping things so quickly. And then the small and medium-sized business will say, I don't even know what those acronyms are. I don't care. But what else can your product do? And by the way, I'm very value conscious, so I'd love your product to do more for the same price. And I think that becomes a tension. And I think if you over-rotate your product org on, let me serve for the enterprise, let me serve for that mentality, you can lose some of that speed that product innovation DNA. And I think that's the thing to watch out for the most is not losing kind of the core of the fiber that got you to build a product that people in the enterprise wanted in the first place.

Can I ask, how do you know when's the right time to move into enterprise?

So I think there's 2 paths. And, you know, I talked to folks at lots of different companies, lots of different SaaS companies, and I think there are some product categories where you need to start in the enterprise because there isn't an SMB buyer. So I think typically things in the like security compliance infrastructure space, you know, there are exceptions, there are open source projects that get adopted bottoms up that then become commercialized. But I think often those buyers, for good or for bad, are going to be the CIO or the CISO at an organization. And so just start with enterprise is often the answer and don't sweat that you don't have a bottoms-up motion or PLG motion. I think if you start with SMBs, I think the thing to look out for is— and it's funny, I don't think we were deliberate about this early on, but eventually obviously we saw in the data— is are you seeing pockets of teams or subsets of an organization that are starting to use your product kind of independent of each other? And if you start seeing that— so for example, I can imagine where I've heard interviews too and talked to folks at Figma You know, they started seeing different pockets of a large organization start adopting Figma. This is very similar to Slack's story. And then once you see that, you're like, okay, maybe we don't have all the control and administration that a large company needs, but we have that organic demand that obviously people at large companies are getting value. And so that's where you start saying, well, let's go talk to the CIO at Uber. You already have 300 people using it. They pay for it with their corporate card. You know, what if you run an enterprise-level agreement? And then they'll tell you the 17 things that are missing, and then that begins your enterprise journey.

How do you determine where to focus? Sorry, I'm just thinking back to your question. It's like, it's so fucking hard because you've got SMBs wanting speed, new products. I want this iteration, that iteration. Your enterprises who want security often, who want compliance, who want reporting. As a product leader, Which customer do you serve when you have 2?

I'll give you our answer. I'm not going to say that should be everyone's answer. Our answer is that if we have to choose who we're serving above all else, it's actually the end user who's using the product and living in it for 10 hours a week. Because if we can make something that they love, that they feel like actually makes their working life, you know, simpler, more pleasant, more productive, they're not only going to tell their coworkers, they're going to tell their boss, they're going to tell their friends, and they may even advocate for us with IT. I think

that's SMB, that, that, that's not

so. I would say actually independent of SMB or enterprise because actually that's the magic of how Slack spreads at most large enterprises. So, you know, I think we've said this publicly, but over 85% of our enterprise customers, so customers of over 1,000 users, started in self-service. So they didn't call up our sales team, our sales team didn't call them. They started by signing up on slack.com, like just like an SMB. Sharing it with some coworkers, just like an SMB, putting a credit card down, just like an SMB. But at some point that grew enough that they then had a discussion with our sales team about becoming an enterprise-level customer. So I think fundamentally, if we have to choose, we choose the end user who lives in Slack all day. But I think we do it with balancing what we know are the needs of the organization, the administration, the buyer who sometimes isn't the end user, obviously at a larger company. But I think just fundamental to our DNA, and again, I wouldn't say every company should carte blanche do the same thing, is build a product customers love enough to tell their coworkers and their friends, and the rest will take care of itself.

Can I ask you, how do you think about the product decision of short-term product feature improvements And shipping a little bit of what delivers revenue today, in all honesty, versus longer-term strategic bets, generative AI introductions, you name it. How do you think about that balance?

Yeah, I mean, this goes back a little bit to the very beginning of the discussion, right, with the Google 70-20-10 model, which is like one way of thinking about it. Because I think there, if you just apply that, you'd say 70% are the first category and 10% are the latter category.

What do you, what do you think you've done that's in the 10%?

So I think for us, I mean, in the context of Slack, what I would say would be in that 10% bucket would be definitely the entire Slack platform and kind of workflow automation system that exists on top of it in that ecosystem, which didn't exist when we first started Slack. Building the network on top of this, you know, walled garden that existed with Slack Connect.

Did you disagree? I think Slack Connect is so interesting. Did you disagree internally?

We definitely debated whether the benefits would be outweighed by the complexity that it introduced. And also, you know, email is the most, you know, email is, uh, we joke about it. It's kind of like your, your post, what is it called? The post box, a mailbox. I don't even remember what it's called, but like it is the lowest common denominator. Everyone can be reached by email. So What would Slack Connect be 10x better than email for? And could you actually deliver on that? Because you do have the post mail that everyone can send. So yeah, we did. We debated a lot. I think the AV stuff was another audiovisual with huddles and clips and some of the newer coworking capabilities we've been introducing. I think for a long time we thought Slack was just primarily a text-based product and adding dimensionality to it Moving to a space that has a lot of other competition incumbents, I think that was a huge bet to take.

How long does it take for you to know a new product works?

So if we're talking about larger products like that, the thing that we do, which I think has become pretty much a playbook for us at least, is we start off always with an internal prototype of something that's big. But we make it rough, we make it ugly, it's unpolished, and we see internally before we do all the refining, the polishing, the scaling, the performance work, are people like, wow, this is super interesting. Like, this could change the way that we work internally. Okay, if you do that with a small group, then okay, refine it a bit, scale that to the rest of the company, and then you start actually looking at data of like, What percentage of Slack is using it every day? What percentage of those people are using it the following week and the week after? What's the depth of usage? Are those things growing? And then the big leap that we do long before we launch things is that we have a really just rabid customer base, many of whom want to pilot new features before they're ever out in the wild. And most of the new capabilities that we launch can't be experiments at a user level because they're social features, right? You can't sit in a huddle by yourself. You have to be able to use it with the rest of your organization. So we have this whole pilot champion network that we use of companies of every customer segment size in basically every country in the world. And we do these progressive pilots where we'll roll out these new capabilities, we'll measure with surveys by talking to folks, and also by looking at kind of adoption metrics as well, and refine the product and then incrementally increase the pilot. And usually by the time that we're launching something that's really big and new, to 100% of the world, we're pretty confident because of the diversity of pilot customers who hopefully became totally smitten with this new capability, that it's going to be something that all our customers love. So that's the process.

What have you launched that's big and new that you thought passed all internal checks and then didn't hit with the public? And what did you learn?

If you go back, I want to say this must have been late 2010s, in late 2018, 2019, we had bought this company that was kind of a lightweight wiki text editor, maybe almost like an early Notion-y kind of product before Notion existed, very early on. And we tried to incorporate it as a very basic kind of WYSIWYG document composer in Slack. It was called Posts. And we were like, well, obviously you would need posts in Slack. It's like a message, but it's richer, more formatted, more visually appealing. For many reasons, this seemed obvious. And yet when we launched it, it really got very low adoption and it never really grew. And I think what we realized, actually, this goes back to one of the things I think Google really kind of instills in you, is that the most important feature by far for any product is actually speed above all else. That is like, that's like the oxygen for a good product experience. And it turns out to build like a rich document editing experience, if it takes a couple seconds to load, if there's latency on the key presses, if moving objects around takes longer than you think, you're gonna just say, well, I'm just gonna go back to the thing I use every day in some other browser tab. And I think it took us a long time. And obviously we've launched Canvas recently, or we're rolling it out actually now. And it's a different take on the same space. But I think what we realized was that the bar for just speed and quality for something that is as ubiquitous as a rich text editor was much higher than we were able to hit. And our customers, we could see in the data, like, this seemed obviously valuable. And at the end of the day, they didn't use it because they had good enough alternatives. And that was humbling but valuable to learn.

I'm fascinated. You said there about that acquisition on posts. From a product leader mindset, you are a massive voice in acquisitions, especially so product-centric acquisitions. How do you think about that buy versus build? And respectfully, like, why buy when often the price is very high?

Yeah, to be honest, and this is maybe colored more by our experience at Slack, I think we've struggled to buy a product that we can then repurpose and incorporate that was faster at the end of the day than if we decide to build it from scratch. And I think every time, you know, the reason— so the question is, well, why does that happen? Why do you do it? I think the reason is often very simple, which is you look at your existing organization, and then you look at your ambitions. And when your ambitions start outstripping your ability to scale your organization, you sometimes think, well, Okay, this whole area that we're excited about, can we just buy a team here? Let's say you have the, you know, equity or the dollars to do it. And will that be a faster time to market to kind of realize some of the vision that otherwise we just don't have the capacity for? And I think it's just fundamentally very, very hard, especially if you're a hyperscaling kind of company, to be able to do acquisitions of products, not teams. Teams are very different. Like we've done a lot of talent acquisitions and those have worked out amazingly well. But whether we're trying to actually buy a product, I think you're right. I think, I think often the thing we've learned is that it doesn't actually decrease time to market. You might bring in expertise and that's a good reason to do it, but that's at least what we've learned for more small-scale acquisition. I think it's different if you're a large company buying like a multi-billion dollar business or Salesforce buying Slack. That's a very different proposition.

Do you think you're good at integration?

I think we're good at talent integration. I think we struggle at product and technical integration. And this is another reason I think if you look at a large company that's very acquisitive, like a Salesforce or a Google, there's a reason why they have an entire M&A division that isn't just about purchasing the company, it's about actually integrating the company after. And again, that's where I think at least Slack, when we were still independent for most of our, you know, life, We didn't have the capacity. We weren't doing acquisitions regularly enough to build that muscle internally to become great at integration. It was always a one-off, and it's hard to get great at one-offs.

Noah, where are you weakest as a product leader? When you do a self-reflection, me and you, whiskey at the end of the year, where are you like, I really need to improve here? And what are you gonna do to improve there?

I think the thing that I think a lot about And I'm passionate about, but I don't think I figured out how to crack, to be totally honest. And we're actually planning a product org offsite for 2 weeks from now, so it's very top of mind. I think it's really hard to create a team environment within a product management organization where people feel really connected to each other, where they feel energized by each other's work, where they're pushing on each other, where they have a lot of shared context. Most product organizations the PMs feel like their primary team is going to be the engineers and designers that they've worked with. Those are the people they work with every day that they have the closest connection to. And I think, you know, I'm still trying to figure this out. I'm still trying to crack it. It's like, how do you make a PM organization feel less isolating? How do you create connection between people who work on very different parts of the product to learn from each other, to push on each other, to build product with each other? I've yet to work at a place that has cracked this, and I think it's part of the reason why maybe there's so much hunger from PMs to kind of learn externally, to learn from a podcast, to learn from newsletters, to learn from other communities, because it is hard to foster that connection internally.

What about a North Star metric, and how do you think about effective North Star metric setting?

Yeah, in terms of kind of the PM team,

Yeah, like unify them around.

Yeah, I think that that works and it's harder to do, I think, in enterprise than consumer because, you know, really the metric you care about is, are people willing to pay for the product? But most of the things you do in the product don't directly affect that metric. So it's a little bit harder than I think in the consumer world where it's more of a direct one-to-one. But I think, you know, most PMs are wired to really care about impact above all else. Like, that's the thing that motivates them— impact to the customer experience, to the product experience, to the business. And North Star metrics help with that, but it's still a little bit, uh, it's kind of like head, not heart, you know? Like, that's like what they think about, what they obsess about, but it's different than how you feel connected and energized by your team. So, you know,

can I ask, what piece of conventional product wisdom do you think is BS?

A lot. I mean, honestly, I think the biggest— I don't know if I would say mistake, but there's been like a professionalization of product management over the last 5 to 10 years. And by that I mean kind of coming up with what is a very like rigid idea of what the role of the PM is and all the frameworks that you could be applying. And I think there's no knock on that. I think it's great to have education inspiration and get that from many different areas. But I think a lot of PMs early on in their career, I think you look for all these kind of shortcuts that are like, okay, this is the framework I can use for a product strategy document, or this is the framework I should use for understanding customer feedback. And I think to me at least, it's much more of a kind of combination of the arts and the science, the head and the heart, knowing things that are like frameworks, but not literally applying them kind of carte blanche. So I think where the role started, my impression, you know, 20 years ago or so, is that kind of started by filling in the gaps in a product development organization where who was the single person who felt responsible for defining the why behind the product, the understanding of the customer, the strategy that's going to be longer term than the next release. And from an operational perspective, kind of being the glue, being the multiplier for everybody else. And I think that's an inherently very fluid definition. And what I always kind of see with PMs is I think if you have a very rigid definition of the role, I do this, the other roles do that, or I apply this framework, this is the only framework I should use. I think you miss a lot of opportunity to have impact and even just enjoy the job. That's my little touchy-feely kind of answer, but that's definitely the thing for me that I would encourage people to do is take a more expansive view of what product can be, take a less rigid view of, you know, copying and pasting frameworks and advice and figure out what the team needs, figure out what the customer needs and focus on that.

No, I could talk to you all day, but I do wanna move into a quickfire round where I pepper you with questions again, but we just relatively time-bound it so it's not too just similar to the last half an hour. Um, but I say short statement. Ready to rock and roll?

Let's do it.

Okay, so when is the right time to hire a CPO?

I think I would hire, first of all, a head of product before CPO, because it's always better to start with fewer titles when you're small. And I think the right time to do it is when the product founder, CEO, presuming that they are a product founder, feels like The teams are now blocking on them for high-quality, fast decisions of direction. So when the development team starts slowing down because the CEO becomes the bottleneck, you probably need someone who can serve as a de facto head of product to start accelerating the organization.

What other function does the CPO have the most tensional conflict with?

I think in a poorly functioning organization, I would say engineering or design. In a well-functioning organization, those should be your best friends. I think at an enterprise software company, the answer is always gonna be sales because what you promise to customers and what you can deliver to customers can often be at odds. At a consumer organization, it might be marketing 'cause that's kind of the same dynamic.

Which product leader outside of Slack do you most admire and why?

Julie Zhao, who is I think she was actually a designer by training, but was at Facebook for many years. I think she is the most incredible thinker and writer about product craft, product design, the nature of working between a product development team. I love everything she does. She's great.

Love that one. Is product more art or science? What's the ratio? And if you were to put a number on it, what would it be?

Here's my somewhat equivocating answer, which is on a really mature feature area, it's more science than art because it's about optimization and you have so much data and scale. So there I would say 80/20 science/art. I think if you're at an early stage company or at a really early, you know, part of the product development lifecycle for a new feature or new product capability, I would say it's like 75% art, 25% science. And you can be informed by the science and the measurement, but there's so much art in the curation, the editing, the creative approach, the vision that you have to focus on before you have enough scale to get into optimization mode.

What would be your biggest advice to a PM who wants a promotion today?

Deliver impact. That's it. I mean, I think for a PM, everything else is an input. If you can change the trajectory of the customer experience or the business and you can point to what you did, not you personally point to what your team did, but you were helping lead, that is the single most, you know, like silver bullet you can have for promotion process because everything else is an input to delivering that impact.

You can call up a CPO who's starting their role the next day. This is the night before your first day as CPO at Slack. Yeah. And you can give them any advice knowing what you know now. What do you call up that CPO-to-be and tell them?

The most generic advice I would say is no one's looking to you to make any rash decisions. In fact, they actually want the opposite. In the beginning, what you should really focus on is understanding the team, the culture, the customers, the vision, the strategy, focus on the things initially that are guaranteed accelerators to the velocity of the product development organization. Those are the lowest hanging fruit, the things that are about process execution and so on. Change kind of team, focus on team after that, because I think you have to spend a lot of time to get to understand the team and the culture, where there's holes, where there's gaps. And then I would focus on changing the fundamental strategy or mission The last, because that's the thing where you have to have a lot more context and understanding to be informed enough to have a good perspective.

You can be CPO of any product other than Slack. Which one would you be CPO of?

I mean, as a as a new dad right now, my my brain is all in baby devices, and I think like there's some company in the baby tech space that between like the Nanit and the Snoo and all these new kind of AI enabled. baby hardware software devices. That would be fascinating. I don't think any one of those companies is that necessarily compelling. You know, not that I would do it necessarily, but I think the most interesting company right now, just where the world is, that's an independent company. That's not like a behemoth. I would say it's OpenAI. And that's not a particularly controversial statement. But I think forget even the technology side of it. I think strategically for them right now, there's just an incredible kind of exponential set of pathways in front of them. I don't pretend like I would even know the answers, but I know those would be really interesting questions to try to think through in an industry that is rapidly changing. So let's say OpenAI.

Forgetting all constraints— financial, hierarchical, legislative— if you could change anything about Slack, what would you change?

I think if I could change one thing about Slack without any constraints is we've always kind of ruled out the Slack use cases outside of the workplace. So for more communities or for kind of people who are doing shared purpose work, but not strictly social, I wish that there was a way to have both the bandwidth, but also the kind of divergent product experience where we could build for both that kind of like work adjacent and work use cases while at the same time. I think every year in our history, we've always decided that that wasn't something we could pursue and that market has become more saturated. But that would be my answer, I think.

No, I love that. Penultimate one, navigating and building in the age of generative AI. Over to you.

Yeah. What, so I think I mean, it's a new space. It's changing really quickly. It reminds me a lot of the early days of mobile back in whenever that was, 2008, 2009, where I think you need to keep such a close pulse on how the fundamental technology and platforms are changing that are enabling new types of products to be built. And that changes every 3 months. So keeping a close pulse is one. I think one of the— I would call it a product principle actually from Google back in the day as it relates to kind of ML and search-related products that I still think is really relevant. Now, especially now, is this idea that I think the prominence and the promise that you put into the product experience needs to match the underlying quality and confidence in the data and in the model. And I think that's actually the thing that is hardest right now, the whole issue of hallucination and everything else. But I think these products are promising a lot to people. If you trust them blindly, you're going to get burned. And I think figuring out how to have a little bit more of a symbiotic experience where you feel like this is an assistant, but not one that you should trust unconditionally, and that it's more transparent with you of, here's what I think, but you should check this, or you should modify this, or you should give me feedback on this. I think that's going to be really important for organizations to figure out.

Now, a final one. What recent company product strategy did you look at and go, that was smart, like, well done?

Yeah, I mean, maybe it's duplicative with the previous question, but I would say I think OpenAI, with realizing that this thing that was in research labs, this thing that was in a bunch of academic papers, which was the large language models, that the proof of concept, which isn't that much more sophisticated, you know, from a consumer experience, it's just actually making, you know, input box and a text output box. That there was something magical there that would help people envision a world that was a very different model of interaction between people and machines and seeing them execute on that. I mean, obviously, I think, you know, Google has been playing catch-up and I think actually now for such a big company doing a good job of that, the space has evolved very quickly. But I think OpenAI kind of realizing there's something magical here and figuring out the smallest possible product packaging of that to then give the consumer world a glimpse of what the future could look like. And then I think now the question of how the space will evolve is, you know, between the consumer product side, which I think there's not going to be so many different variations that are going to win. And then you have on the platform and the infrastructure side, how do you enable every other company to integrate AI into their products? I think that's going to be the most interesting thing to play out over the next 12 to 18 months.

Noah, you've been unbelievably patient. I've just gone pow, pow, pow on peppering you with questions. I love conversations like this though, where it is totally natural. Uh, I've so enjoyed having you on. Thank you so much for doing it, and it really has been awesome.

Thanks so much for having me, Harry. I had a great time.

You are a hero, my friend. Thank you so much for that.