# Slack CPO Noah Weiss on How to Master Product-Led-Growth The Biggest Mistakes Founders Make When Scaling Into Enterprise & What Needs to Change with your Product, Team and Processes when Scaling From PLG to Enterprise 20Product · Jun 16, 2023 · 52 min · 10,694 words Speakers: Noah Desai Weiss, Harry Stebbings Source: https://www.996.fm/episodes/20vc--ep-58b5ea86/ ## Cold open **Noah Desai Weiss** [0:00]: The most important feature by far for any product is actually speed above all else. That's like the oxygen for a good product experience. I think we're good at talent integration. I think we struggle at product and technical integration. **Harry Stebbings** [0:14]: This is 20 product ## Intro **Harry Stebbings** [0:15]: with me, Stebbings. Now 20 product is the monthly show where we sit down with the best CPOs in the world to hear how they start, scale, and manage the best product teams in the world. And we have the incredible Noah Weiss, CPO at Slack in the hot seat today. Now over his seven years at Slack, Noah has led various parts of the product talk, including the self-service SMB business and the PLG growth engine, the Virtual HQ team that launched Huddles and Clips, and the search and machine learning teams. And prior to Slack, Noah served as SVP of product and analytics at Foursquare, and he started his career at Google, leading the structured data search team and working on display ads. But before we dive into the show today, ## Sponsor read **Harry Stebbings** [0:53]: this episode is brought to you by Linear. Let's be honest. The issue tracker you are using today, it's not very helpful. Well, Linear is different. It's incredibly fast, beautifully designed, and it comes with powerful workflows that streamline your entire product development process from issue tracking all the way to managing product road maps. Linear is designed for the way modern software teams work. Its powerful workflows let you customize and automate processes to fit your team's unique needs, and they have integrations with your favorite tools like GitHub, Slack, and it takes just minutes to set up. Linear is the default tool of choice for high performance teams from startups to a wide range of large established companies like Vercel, Retool, and Cash App. So see for yourself what makes Linear magical. Visit linear.app/20vc to try for free with your team and get 25% off when you upgrade. That's linear.app/20vc. And speaking of tools we cannot live without, I need your input on the '20 v c Miro board about new guests we should feature for 20 v c in 2023. Just head on over to miro.com/20vc. Miro is a tool I consider to be truly game changing. It's a visual collaboration tool packed with the right tools, tech, and templates to help you think of and create that dream product. That means you can brainstorm the perfect product with your team, vote on the best ones, and explore with your customer journey road map all on a Miro board. Whatever you need, Miro's infinite whiteboarding capabilities help you get there. It acts as your team's single source of truth. And now I'm using it to hear from you. Go ahead and add your suggestions for 20 VC guests on our Miro board at Miro dot com forward slash two zero VC. And finally, you have to try Epo, the next generation AB testing and feature management platform designed to help you run reliable and powerful experiments. Epo saves you time across the entire experimentation workflow. Planning tools help run experiments scenarios beforehand. Best in class diagnostics mean you spend less time debugging issues. Their cutting edge status engine helps you reduce experiment run times. Plus, Epo sits directly on top of your data warehouse and your North Star metrics, so it gives you this real confidence in the experiment performance and the ease in conducting follow-up deep dives. No more extended analysis cycles to understand results. And that's why companies like DraftKings, ClickUp, Momentive, and Cameo all rely on Epo to power their experiments. Get access today at getepo.com. That's getepo.com. You have now arrived at your destination. ## Conversation **Harry Stebbings** [3:31]: 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, Harry. I've been a long time listener and 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 starting as your career starting as PM at Google, what is the single biggest product lesson you took from the two to three years at Google, and how did that impact your mindset? **Noah Desai Weiss** [3:56]: I think the thing that struck me the most in backroom, they used to have this model. They called it the seventy twenty ten model. 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 kinda 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 Android before Android existed, the building a web browser. And I think the thing that stuck out to me was the combination of deliberate approach to what the portfolio looked like. And whatever your ideas you bring to them, what would 10 x a bigger scale look like? So I I think that caused a level of ambition for product thinking at Google that it's kinda hard to afford at mid to early stage startups, but I think it's aspirational to bring to every company. Do you do the seventy twenty ten at Slack? We do talk a lot about kind of the portfolio and diversification within different product areas. So, you know, we might ask it to you. When you think about the breakdown of your roadmap for the next two quarters, where 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? We don't call it 70 to twenty ten, but it's definitely part of how we'll look at the structure of product team road maps and track 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 seventy twenty ten. They might look like ninety five five. It's a interesting framework, but I don't think it is something that is like a perfect ratio to apply in every context. **Harry Stebbings** [5:37]: 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? **Noah Desai Weiss** [5:44]: 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. When everything's going up into 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, basically, 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 in the social side of it, and then also the world changed. Understanding how competition changes the backdrop with with Instagram coming out, really shifting how people viewed what it meant to share experiences in the real world. **Harry Stebbings** [6:50]: 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? I think if you **Noah Desai Weiss** [6:59]: look earlier stage, 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. 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 wanna solve it for me, and hopefully other people want it too. Slack, obviously, was was two 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, 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 the product for who look fundamentally different from you. And how do you make that leap as an organization, as a culture, as a frame of reference where you are your next customer? That's a huge leap and I think really hard for most companies to do. **Harry Stebbings** [8:02]: How do you do that? And how much do you listen to your customers versus independently progress on your own research and thought processes? **Noah Desai Weiss** [8:11]: Yeah. I think you have to get even deeper into your customers' lives and better understand. So, you know, in that 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 five to 50 people. The initial conception of Slack was after 50 people, this thing probably won't scale. No one's gonna wanna work this way. So let's just design for the 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. We had to spend it was this probably end of twenty sixteen, 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, 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. **Harry Stebbings** [9:30]: Now before we move into that kind of scaling up into enterprise, you mentioned that the five to 50. I do just wanna touch on kind of the foundation as being in a product principles. And you said before the show to me that your organization needs product principles. First, what are product principles? And what did you mean by this? Yeah. Product **Noah Desai Weiss** [9:45]: 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 qualitative assessments of the level of craft of the product. And so for Slack, I think the why behind why we created these was as a company was scaling and the average person who's working 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 fiber and DNA of how the product was initially built into teams that were further away from that origin. And so what we realized was you couldn't just have Stewart 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 prototype the path, and take bigger bolder bets, and we can unpack any of them. But **Harry Stebbings** [10:45]: Let's unpack them. I'm I'm gonna be deliberately contrarian. They're all quite general. Bigger, bolder bets. I get it, but kind of nuanced. If I'm gonna come with an idea that's like bet the company, you're telling me to take bigger, bolder bets. Help me understand this because they seem pretty challenging. **Noah Desai Weiss** [11:00]: Yeah. I would say, I think they mean something to the context of the organization. When you unpack these, what we may only say, take bigger, bolder bets. As a company scales, I think there's a tendency towards incrementalism and kind of local optimization. And you have bigger and bigger organizations. You have feature teams. The feature teams may have a similar KPI that is the one thing they feel directly accountable for. And the natural tendency is 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 point 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 our customers. **Harry Stebbings** [11:58]: What do you think are the biggest mistakes startups make with product principles? **Noah Desai Weiss** [12:02]: Most companies wait too long to introduce them. Whether they call them principles or maxims or design guidelines, it doesn't really matter. It's really hard if you're a product founder and you're a founder led company. But I think one of the hardest things winds up being when do you give up enough control that the organization starts building things that you're already even aware of? And then how do you have enough trust that the people building it are gonna build it up to the standard and approach that the company was founded on? That's the leap. But I think most companies wait far too long, and then the organization starts going slower and slower and then the CEO starts complaining, why are things slower when we have twice as many people? I would say probably waiting too long to trying to culture in a way that can scale. **Harry Stebbings** [12:47]: You said there about kind of speed with scaling teams. I had Gustav Soterstrom, the CPO 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 products, 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? **Noah Desai Weiss** [13:15]: Fundamentally, I think depends on the type of thing that you're debating. I think it's Amazon maybe that was kind of famous for the two class of decisions. Like, there's the two way doors and one way door decisions. 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 the entire kinda 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 in my mind at least. How **Harry Stebbings** [13:57]: do you do product reviews? How often do you do them? Who's invited? What do they look like? Yeah. It's **Noah Desai Weiss** [14:02]: 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 restructure now is there's basically product pillars, which are teams of teams that are responsible for areas of the product. So there might be an enterprise product team or the Virtual HQ team as it runs for Huddles and Clips and so on. 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 there, a 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 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 road map 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? How did they change in a world of hybrid? The biggest change was they became more inclusive, actually. Because what used to happen I mean, you probably know this dynamic. Right? 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 kinda felt like you had to set a hard cap. I don't know if it was eight 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 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, actually, 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. 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 a context immediately instead of the typical trickle or cascade of information. In that way, I think it's actually been a real beneficial change. **Harry Stebbings** [16:31]: You know you're the only product leader who said a positive about it being in hybrid. Every single leader said it gets worse. The quality of discussion is worse when it's not in person. It's harder as an **Noah Desai Weiss** [16:41]: executive. It's less fluid, but I think the team I and even 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 six 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. I 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, 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 when people do asynchronously on their own schedule. How do you do that? Is that with mirrored boards? Is that with what does that look like? Yeah. 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. 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 three or five 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 let me, you know, the classic meeting otherwise is a 20 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 watched 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. **Harry Stebbings** [18:18]: What's the biggest broken process part of product building today for you in Slack that hasn't yet been resolved? What is actually **Noah Desai Weiss** [18:26]: 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? We wind up solving this like most people do. At the at the end of the day, we 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 a kinda operational cadence to the quarter. But that's a solution 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's too **Harry Stebbings** [19:11]: 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. But I do wanna ask, we've managed, obviously, Stack so many times. You are the masters of PLG. You've been building one of the iconic PLG products the last, you know, five plus years. Yeah. How do you preserve simplicity with scale and with time? **Noah Desai Weiss** [19:31]: One of the things when you go to the actual mission and vision of the company to make people's working lives simpler, more pleasant, and more productive. And so I think everyone here, when we're thinking about how do we build, what do we build, what does the quality of Craft Bar look like, it does always come back to, is this simple enough? Are people gonna 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 had never worked at enterprise software before. Is simple always better? Simple from a, it's easy to understand. That is always gonna be an important and good thing. 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 you'll say, okay. You know, we wanna remove as many clicks as possible or remove as many options, give less control. But I actually think in enterprise offer, 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. You're helping people feel like they have a master of the software that they're using and feel confident in what they're doing. Simple is about how understandable something is, how comprehensible it is. It isn't necessarily how streamlined or how seamless it is. **Harry Stebbings** [20:47]: When you review many of the product decisions you made with regards to, like, the product led growth features at Slack, 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? **Noah Desai Weiss** [21:01]: I'll do two because one is not specifically necessarily PLG, but I think kind of affects the the motion there. So the most obvious PLG one is that Slack always had a really generous freemium model. Like, you know, you have free a free plan. You can use it as long as you want. There's no cap on users. They're really only significant cap is just on how many messages you have access to, how many files you can upload, and so forth. 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 we learned this in user, even this maybe sounds obvious in hindsight, 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 we're not banging you over the head with it in inside Slack. And then kinda just was like, their conception of what Slack was had all the limitations of the free plan. And so they almost viewed as, oh, it's meant to be ephemeral. Like, you know, the conversation disappear. You know, this is back when maybe Snapchat was really taking off. So people kinda 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, how can you make sure you're getting the value out of it. And that was probably, 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? I think for a long time, we have 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 reviewed this and we kind of wrote Maximus, what we wanna do is give people such a great taste of the full Slack experience that they never wanna go back. And that's a change. Instead of assuming that they'll discover it on their own, 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, oh my god. I would never wanna go back to the free plan. Like, this is so powerful. This changed my entire organization. So I think that that was a big change there. The other thing which I was gonna mention, not strictly PLG, but I mean, this product capability called Slack Connect. 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. We have Slack Connect channels with every one of our customers to do customer success and support. Stripe's head of sales famously said, you know, once we're the Slack connect channel with a customer, I know the deal is gonna get done. The thing that I think we were, you know, maybe overly cautious on is we were really, really slow and deliberate about 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. 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 I think we probably had it in beta for about two years. Took a really long time to bring to market. Frankly, especially given the competitive backdrop there, I think if we had 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 the ubiquity of Slack was something that felt like maybe inevitable, this could have created enough gravitational pull where existing customers who love it just forced the rest of the world to come use it with them. And I don't think they 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 it to market earlier. **Harry Stebbings** [24:31]: You mentioned speed there. I'm asking it 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? **Noah Desai Weiss** [24:47]: Where I was most true was 2018 to 2020. Back then but that's when we really made this kind of hard rotation on focusing on the enterprise buyer, the enterprise organization. We did prioritize for a while kind of scalability and solving those really complex 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, pushing the boundary of what this category could be forward. 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, but also now have all these other needs. And can Slack fill these needs, or do I need to look in other places for them? Based on the end of twenty twenty through now, I would say, and this is not a rebuttal, but my perspective of this is that I think that the pace of innovation has kind of increased pretty dramatically. You know, you have Huddles, you have Clips, Canvas, which was just **Harry Stebbings** [25:43]: launched, you have a workflow. And that is because you have clarity of understanding who you're building for, be it the enterprise buyer? **Noah Desai Weiss** [25:49]: I think what it actually is is that we 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 gonna say no unless you have DLP and EKM and IDR. I'm I'm not gonna go through all the three letter acronyms that will be blockers. But once you do all those, then you start realizing what we felt all along, which is you wanna 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, that pandemic and the shift to this hybrid world, I think it kinda gave us almost a new level of meaning and urgency to 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. **Harry Stebbings** [26:45]: Noah, you mentioned those three 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? **Noah Desai Weiss** [27:04]: It's hard because, honestly, a lot of the work is really kind of removing blockers. And I think they're what I would really recommend, honestly, is, like, that's where you wanna hire people who have domain expertise. You don't want a bunch of folks who worked at 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 for ourselves is over rotating on the enterprise buyer where you think that yeah, they're inherently more conservative. They they don't want features to be shipping every single day to end users because they're, in fairness, trying to 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 attention. And I think if you over rotate, 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 the core and the fiber that got you to build a product that people in the enterprise want in the first place. **Harry Stebbings** [28:33]: How do you know when is the right time to move into enterprise? **Noah Desai Weiss** [28:36]: I think there's two paths, and there are some product categories where you need to start in the enterprise because there isn't an SMB buyer. Things in the, like, security, compliance, infrastructure space, those buyers, for good or for bad, are gonna be the CIO or the the CISO at an organization. Just start with enterprise is often the answer, and don't sweat that you don't have a bottoms up motion or a PLG motion. I think if you start with SMBs, I think the thing to look out for 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 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 paid for it with their corporate card. 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. **Harry Stebbings** [29:47]: How do you determine where to focus? 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. As a product leader, which customer do you serve when you have two? **Noah Desai Weiss** [30:02]: Our answer 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 ten 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 gonna tell their coworkers, they're gonna tell their boss, they're gonna tell their friends, and they may even advocate for us with IT. That's SMB. Not so I would say, actually, 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, you know, customers of over a thousand users started in self-service. They started by signing up on slack.com, 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. Fundamentally, if we have to choose, we choose the end user who lives in Slack all day. But I think we do it balancing what we know are the needs of the organization, the administration, the buyer who sometimes isn't the end user, obviously, the larger company. But I think just fundamental to our DNA, build a product, customers love enough to tell their coworkers and their friends, and the rest will take care of itself. **Harry Stebbings** [31:15]: 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 best generative AI introductions, you name it. How do you think about that balance? **Noah Desai Weiss** [31:33]: Yeah. I mean, it skews back a little bit to the very beginning of the discussion, right, with the Google seventy twenty ten 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 other latter category. What do you think you've done this in the 10%? In that 10% bucket would be the entire Slack platform and kind of workflow automation system that exists on top of it in that ecosystem, which didn't exist when I first started Slack. Building network on top of this walled garden that existed with Slack Connect. **Harry Stebbings** [32:04]: I think Slack **Noah Desai Weiss** [32:04]: Connect is so interesting. Did you disagree internally? We definitely debated the benefits would be outweighed by the complexity that it introduced. And also, you know, email is we joke about it. It's kind of like your your post. It is the lowest common denominator. Mean, 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 audio visual 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 a just primarily 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. **Harry Stebbings** [32:49]: How long does it take for you to know a new product works? **Noah Desai Weiss** [32:52]: The thing that we do, which I think has become a playbook for us at least, 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, our people are 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 would 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 or 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, refine the product, and then increments and increase the pilot. And usually by the time that we're launching something that's really big and new to a 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 gonna be something that all our customers love. **Harry Stebbings** [34:28]: What did you notice as 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 **Noah Desai Weiss** [34:36]: back, wanna say this must have been 2018, 2019. We 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 WYSIWYG document composer in Slack, and it called hosts. We were like, well, obviously, you would need hosts 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. It never really grew. And I think what we realized, actually, this goes back to one of the things I think Google really 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 documenting 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. 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're 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. **Harry Stebbings** [36:09]: I'm fascinated. You said there about that acquisition on post. From a product leader mindset, you're a massive voice in acquisitions, especially so product centric acquisitions. How do you think about that buy versus build? And respectfully, why buy when often the price is very high? **Noah Desai Weiss** [36:24]: To be honest, and this is maybe colored more by our experience at Slack, 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. 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 while your ambitions are outstripping your ability to scale your organization, you sometimes think, okay. This whole area that we're excited about, can we just buy a team here? I'll say you have the, you know, equity or the dollars to do it, and will that be a faster time to market to kinda 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 kinda 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 when 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 learned for more small scale acquisition. I think it's different if you're a large company buying like a multibillion 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 Google, there's a reason why they have an entire m and 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 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. **Harry Stebbings** [38:14]: Noah, why are you weakest as a product leader? When you do a self reflection, me and you, whiskey at the end of the year, why are you like, I really need to improve here, and what are you gonna do to improve there? **Noah Desai Weiss** [38:24]: I think it's really hard to create a team environment within a product manager 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 gonna be the engineers and designers that they work with. Those are the people they work with every day that they have the closest connection to. And and I'm still trying to figure this out. 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 that's part of the reason why maybe there's so much hunger from PMs to kind of learn externally, to learn from podcasts, to learn from newsletters, to learn from other communities because it is hard to foster that connection internally. **Harry Stebbings** [39:17]: What about a North Star metric, and how do you think about effective North Star metric setting? **Noah Desai Weiss** [39:22]: Yeah. I think that that works. It's harder to do, I think, in enterprise and consumer because, really, the metric we care about is, are people willing to pay for the product? But most of the things you do in a 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 most PMs are wired to really care about impact above all else. So, like, that's the thing that motivates them. Impact to the customer experience, to the product experience in the business. And Nordstrom metrics help with that. It's kinda like head, not heart. When they think about it, when they obsess about them, different than how you feel connected and energized by your team. What piece of conventional product wisdom do you think is BS? A lot. The biggest, I don't know if I would say mistake, but there's been like a professionalization of product management over the last five to ten years. And by that, I mean 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 no. Not 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. To me at least, it's much more of a combination of the arts and the science, the head and the heart, knowing things that are like frameworks, but not really applying them parapleunch. I think where the role started, my impression in twenty 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, that's gonna be longer term than the next release, and from an operational perspective, kind of being the glue, being the the multiplier for everybody else. And I think that's an inherently very fluid definition. What I always kinda see with PMs is I think you have 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. Take a more expansive view of what product can be. Take a less rigid view of copy and pasting frameworks and advice and figure out what the team needs, figure out what the customer needs, and focus on that. **Harry Stebbings** [41:40]: No. I could talk to you all day, but I do wanna move into a quick fire round where I pepper you with questions again, but we just relatively time bound it. So it's not too dissimilar to the last half an hour. But I say a short statement. Ready to rock and roll? Let's do it. Okay. So when is the right time to hire a CPO? **Noah Desai Weiss** [41:56]: 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 locking 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. **Harry Stebbings** [42:25]: What other function does the CPO have the most tension or conflict with? I think in a poorly **Noah Desai Weiss** [42:31]: functioning organization, I would say engineering or design. In a well functioning organization, they should be your best friends. I think at a 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 because that's that's kind of the same dynamic. **Harry Stebbings** [42:49]: Which product leader outside of Slack do you most admire and why? Julie **Noah Desai Weiss** [42:55]: 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. **Harry Stebbings** [43:12]: 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? **Noah Desai Weiss** [43:18]: 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'd say eighty twenty science art. If you're an early stage company or at a really early part of the product development life cycle 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 it to optimization mode. **Harry Stebbings** [43:52]: What would be your biggest advice to a PM who wants a promotion today? **Noah Desai Weiss** [43:56]: Deliver impact. That's it. 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, that is the single most silver bullet you can have for a promotion process because everything else is an input to delivering that impact. **Harry Stebbings** [44:13]: 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? **Noah Desai Weiss** [44:26]: 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. Focus on team after that because I think you have to spend a lot of time to 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 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. **Harry Stebbings** [45:11]: You can be CPO of any product other than Slack. **Noah Desai Weiss** [45:14]: Which one would you be CPO of? Not that I would do it necessarily, but I think the most interesting company right now that's an independent company that's not like a behemoth, I would say is OpenAI. And that's forget even the technologies out of it, I think strategically for them right now, there's just an incredible exponential set of pathways in front of them. I know those would be really interesting questions to try to think through in a industry that is rapidly changing. So let's say OpenAI. **Harry Stebbings** [45:40]: Forgetting all constraints, financial, hierarchical, legislative, if you could change anything about Slack, what would you change? **Noah Desai Weiss** [45:47]: 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 the kind of, like, work adjacent and work use cases while at the same time. I think every year in our history, we've always just had that that wasn't something we could pursue and that market has become more saturated. But that would be my answer. **Harry Stebbings** [46:05]: Penultimate one, navigating and building in the age of generative AI. **Noah Desai Weiss** [46:09]: It's a new space. It's changing really quickly. It reminds me a lot of the early days of mobile back in whatever that was, 2008, 2009, where 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 three months. Keeping close pulse is one of the I would call it product principle actually from Google back in the day as it relates to kind of ML and and search related products that I 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 these products are promising a lot to people. If you trust them blindly, you're gonna 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 gonna be really important for organizations to figure out. **Harry Stebbings** [47:16]: Now a final one. What recent company product strategy did you look at and go, that was smart. Like, well done. **Noah Desai Weiss** [47:23]: OpenAI, realizing that 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 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. Seeing them execute on that. And then, obviously, I think, you know, Google has been playing catch up. And I think actually now for us to be coming doing a good job at that. The space has evolved very quickly, but I think OpenAI kinda realizing there's something magical here and forgot the the smallest possible product packaging of that to then give the consumer world a glimpse of what the future could look like. I think now the question now that space will evolve is, you know, between the consumer product side, which I think there's not gonna be so many different variations that are gonna win, and then you have in the platform and the infrastructure side, how do you enable every other company to integrate AI into their products? I think that's gonna be the most interesting thing to play out over the next twelve to eighteen months. **Harry Stebbings** [48:29]: Noah, you've been unbelievably patient. I've just gone pow pow pow on peppery with questions. I love conversations like this though where it is totally natural. 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. I mean, what a fantastic guest to have on the show. If you wanna see more from us behind the scenes, of course, you can by going to YouTube and searching for 20 VC. But before we leave you today, ## Sponsor read **Harry Stebbings** [48:55]: this episode is brought to you by Linear. Let's be honest. The issue tracker you are using today, it's not very helpful. Well, linear is different. It's incredibly fast, beautifully designed, and it comes with powerful workflows that streamline your entire product development process. From issue tracking all the way to managing product road maps. Linear is designed for the way modern software teams work. Its powerful workflows let you customize and automate processes to fit your team's unique needs, and they have integrations with your favorite tools like GitHub, Slack, and it takes just minutes to set up. Linear is the default tool of choice for high performance teams from startups to a wide range of large established companies like Vercel, Retool, and Cash App. So see for yourself what makes Linear magical. Visit linear.app/20vc to try for free with your team and get 25% off when you upgrade. That's linear.app/20vc. And speaking of tools we cannot live without, I need your input on the 20 v c Miro board about new guests we should feature for 20 v c in 2023. Just head on over to miro.com/20vc. Miro is a tool I consider to be truly game changing. It's a visual collaboration tool packed with the right tools, tech, and templates to help you think of and create that dream product. That means you can brainstorm the perfect product with your team, vote on the best ones, and explore with your customer journey road map all on a Miro board. Whatever you need, Miro's infinite whiteboarding capabilities help you get there. It acts as your team's single source of truth. And now I'm using it to hear from you. Go ahead and add your suggestions for 20 VC guests on our Miro board at miro.com/20vc.c. And finally, you have to try Epo, the next generation AB testing and feature management platform designed to help you run reliable and powerful experiments. Epo saves you time across the entire experimentation workflow. Planning tools help run experiment scenarios beforehand. Best in class diagnostics mean you spend less time debugging issues. Their cutting edge status engine helps you reduce experiment run times. Plus, Epo sits directly on top of your data warehouse and your North Star metrics. So it gives you this real confidence in the experiment performance and the ease in conducting follow-up deep dives. No more extended analysis cycles to understand results. And that's why companies like DraftKings, ClickUp, Momentive, and Cameo all rely on Epo to power their experiments. Get access today at getepo.com. That's getepo.com. As always, I so appreciate your support, and stay tuned for an amazing set of episodes next week.