Building Slack with Noah Weiss

LinkedIn News.

I've always been curious.

Always looking for patterns in society, how people navigate and find their way.

You always need some level of conflict to initiate that dialogue.

It's never a straight line.

I'm Tomer Cohen, Chief Product Officer of LinkedIn, and this is Building One.

Product-market fit is not something you earn once. and have forever. It's something that you have to keep renewing as your company matures.

That's Noah Weiss, the former chief product officer of Slack. He's sharing about a key lesson that informed his approach to continuously innovating as the company grows. We're going to get into that and so much more, so stick around. I learned about Slack similarly to how I learned about many other products. Somebody just invited me to it. The main difference is that all of those other products were consumer products and Slack wasn't. It was a workplace collaboration tool, what's often called a B2B product. Slack was one of the pioneers in the consumerization of enterprise solutions, essentially bringing the craft and frictionless experience of consumer products into the enterprise, a product domain basically known for feature-rich complexity, but not simplicity. In that way, Slack was groundbreaking. That's why I'm excited to share my interview with Noah Weiss. We sat down and spoke several months ago when he was the Chief Product Officer at Slack. The insights Noah shares remain as relevant today. In this interview, Noah shares lessons about how to maintain continuous pursuit towards rediscovering product-market fit. And what does it actually mean to rediscover product-market fit? Some of the unique core building principles they employ at Slack, how he leverages his own curiosity as a leader, and how he fosters that in his team. And finally, how Slack aspires to win within a very crowded field of collaboration tools. Let's get into it. Noah, I actually didn't know much about product management roles until I arrived to the Valley, but you actually started early with product management roles.

Yeah.

But you also worked as an engineer and designer across multiple companies from large to startups. So curious, what inspired you to you a career in product so early?

Well, first off, I feel like talking to the head of product at LinkedIn, there's probably no one who's more calibrated on what all these journeys look like than you. So I'll share my story, but as you know, it's like everyone has a very different journey. So I mean, when I was in high school, I was totally fully down the engineering track. I was kind of overloading on computer science. I was doing every, you know, AP class, side projects, side hustles, And frankly, I overloaded on it and I felt like I wasn't very well-rounded coming out of high school. I had kind of gone way too deep down that path. And when I got to college, I was very deliberative. I don't want to just do computer science. I want to learn about other things that I'm just passionate about, that I'm curious about. And that's been pretty much a through line my entire career, just following that curiosity and see where it leads you. So I started doing design and economics and psychology and obviously computer science as well. And they all kind of intersected and I didn't know what would come of it, but I thought, you know, following that path, we'll see where we wind up. I started doing engineering internships, actually did like a social entrepreneurship investing internship one year. I then went to Google actually as a, what they called a UX designer back then, because my advisor in undergrad was an advisor to some of the Google folks. He's like, oh, you'll love it. They really care a lot about human-computer interaction design, which is what my focus was. And I show up at Google, I do an internship for 10 weeks, and I will tell you, back in 2006 or whenever that was, Google did not highly value people doing design work. And it was very apparent within a couple weeks that I might be passionate about this job, but this is not a job that is worth doing at Google. And so I kind of actually had a pretty rough summer. I enjoyed the company, but I kind of hated the work and the role. And at the end of the summer, and it was such an amazing thing someone did for me, is the head of engineering for the team I was on, which was actually back then the Google Suite team or the Google Workplace team now, said, hey, do you want to come just sit with our team, just the engineers, and just help us spec out a bunch of new features in your last 2 weeks of the summer? And I said, sure, I don't really have anything else better to do. And I just, that's what I did. I moved in with the engineering team. I didn't know exactly what the work was. He's like, just help us figure out exactly how we should build this. We know the problems, we know the feature we want to build. We don't know how to build it or how to quickly get something out the door. And so that's what I spent 2 weeks doing. At the end I said, is this a name of a job at Google? He's like, yeah, it's called product managers. I'm like, great. Can I— kind of do that job full-time? And he's like, yeah, let me introduce you to someone who can like get you an interview for it. And that's honestly how I stumbled into it.

That's amazing. So you were on the APM program, the one that Google pretty much brought into the Valley?

Yeah, like the one Bret Taylor was in and a lot of those kind of old school folks. So yeah, I started in, I guess, 2008, loved it for a couple years and then got the startup bug and went on from there.

For folks who have less context of the Associate Product Management program, In many ways, it was designed to actually bring people who care about building products and really train them on the role because there was no such program to train them outside of companies. And then it was adopted. We have our own LinkedIn APM program and so do many other companies as well.

Yeah, that's right. I think Marissa, who was employee number 10 or 11 at Google and the first product manager officially, No one in the early days had been a product manager before. Everyone came from a more technical background and they learned to do what Google thought of as product management. So they thought, what if we turn that into a program and let a bunch of other folks who have no experience in product management learn how to do it on the job? And so it was a fresh take and definitely I was a big beneficiary getting to immerse myself right outta college in that kind of way.

Wonderful. I wanted to shift a little bit into what is a little bit of your superpower. A skill that you've built or quality that made you successful in many ways? I've been privileged to work with many amazing product builders. And if you ask me what's unique about them, I think I can narrow it down to like, oh, this person is— their attention to detail is unbelievable. They're incredible visionaries. I think in many ways, the best people over-index on something. What do you think that is for you?

I mean, I think the through line honestly would be just having an insatiable curiosity and excitement about whatever it is I'm working on. And that's both been something for literally just pulled me in my career, but also when I think about what I've done on the job, you know, back early on when you're a PM on a feature team, I think being incredibly intellectually curious, seeing how far down deep you can go into understanding the technology, understanding what the world looks like outside of your team, especially if you're at a larger organization. Following that curiosity and being very genuine about it is a superpower that I think is valuable and folks kind of overlook. You think you leave school and you're done learning. If you always have that more kind of learning mentality and following your nose there, I think it's really important. And then I think kind of later in your career, I like to think a lot about like, what is the quality of questions that you're able to ask, especially as you move into more senior executive roles, being able to ask the right questions when you only get to ask a few, you're in a product review, you maybe see a team once a month. Channeling that curiosity in a way that can help push the team's thinking, can help facilitate stronger, more informed decision-making. I think that's more how it manifests at this point in my career. But really, it's been like that since I was a little kid. My mom jokes when we used to go on road trips, you know, I could ask questions for 3 straight hours between point A and point B. And it's pretty much the case now. I just don't have hours with every team, unfortunately.

And do you try to build that for talent you grow on the team? Sounds like it's more natural for you, but is there a process to bring it into the team's thinking? When

we think about from a career development perspective, I think one thing that we like to do a lot is give people lots of different exposures to different types of problems and different teams in their career at Slack. So, you know, I think some organizations you wind up having folks who spend 10 years and they're on the same team and they're the expert of whatever that domain is. I think if you wanna build a product organization that has that intellectual curiosity baked into it, where you have people sharing and mixing experiences and lessons learned and scar tissue in every different direction, encouraging a lot more internal mobility is really critical. So that's something that I've always really cared a lot about. And some of my favorite stories of people's careers at Slack are when people kind of go from one domain to a totally different domain and then they flourish because they're bringing a perspective that no one else who normally works in that kind of area has. So I would say that's the main way that we try to encourage it internally.

Yeah, it's a wonderful point. You had a remarkable ride being the head of product for Foursquare. And for folks who are less familiar, Foursquare pretty much pioneered the idea of location-based discovery via social. And I'm sure you had incredible learnings from this one. So I'm curious which one you brought with you into Slack and how you operate it.

I mean, I think the single biggest thing I would say is that product market fit is not something you earn once and have forever. It's something that you have to keep renewing as your company matures. And for those who don't know the history of Foursquare, I'll say there was a moment in time when I was actually first starting there in 2010 to 2012 where Foursquare and Twitter and Instagram were all kind of in the same cohort of consumer social networks that are mobile first and taking off in all these different directions. I won't do the rest of the story, but there was many ups and lots of downs along the way. And I think the thing that we had to do that in the end we weren't able to completely pull off was understanding the product market fit you get with one audience, especially an early audience, is not necessarily the thing that's going to fuel you to get to the next level of scale. Now, you don't want to ever discard that user base. It's really important to keep those early fans, but often what got you obviously to where where you were isn't going to get you where you need to be. And I think there are stories obviously that are counter to that. Like, I don't know, Google had a white homepage with a text box and a search button for 20 years and built a trillion-dollar business. So product-market fit obviously does scale. You don't have to change the model for every company. But I think most products that don't have some underlying technology that no one else can build, do need to think about renewing that. And for Slack, the initial focus was really on small teams building technology. That was like the core audience, teams of 5 to 50 people who are also building software themselves, and then expanding to teams in other domains, and then eventually to medium enterprises and to the largest enterprises in the world. And each step along the way, I think we had to really rethink how we understood the customer base. rethink how we approach what the product needed to look like while preserving as much of that customer love from the early fans as possible, because you want to bring them along on the journey.

I love that insight. Product market fit is a prerequisite for success, but it's not a guarantee for scaling or sustaining your success.

Yeah.

And I think some, some would argue that while the Google homepage stayed the same, the responses did not. Like I see Google as more of like an answering machine today than a an index of some sort, but they really nailed the how do you have access to the internet in a way. They're like the gateway to the internet for so many.

Yeah.

I heard you also talk about principles, which is something which is dear and near to my heart because as you scale to large organizations, it's a phenomenal way to align people. And you talked about this as a common language.

Yeah.

A common language that helps you work with your CEO and your founders, but a common language that helps you work with your team. What are those for you at Slack?

I would say a couple years into the journey, we started realizing we needed to enshrine the way in which we built product and the way in which we thought about what great software looked like into the culture. And that's where the initial set of product principles came from. They've evolved a little bit over the years, but we've got a separate set of business principles or the pricing and packaging principles, which are also an interesting set of topics, but very different than the product side. To me, I think the ones that stand out the most that are the most used though, when you hear them at first, they sound very simple and universal, but there's actually some tension in all of them. The 3 that we talk about the most is don't make me think, be a great host, and then seek the steepest part of the utility curve, which is the most abstract. I can explain what that one means, but don't make me think. When we say that, and we often say, what does that not mean? Don't make me think. It definitely means Slack should be intuitive. It should be effortless. It should be easy to comprehend. It should be easy to grok and to learn. But what it doesn't mean, and this is where folks coming from consumer often initially think, is it doesn't mean that you need to reduce every click possible. It doesn't mean that if a job takes 7 steps, that 3 steps is better. We talk a lot about comprehension and understanding, and especially in enterprise software, different than consumer, building to bring people along on a journey who are living that software all day long, who have a high degree of intent, but also who, if you walk them through things, they can actually learn to master and get to a level of proficiency that people typically don't in the consumer world. How do you lean into that? So don't make me think Yes, it's effortless, simple, but it's also about bringing our users along, helping them mature their usage, helping them become experts over the years in which they'll be using Slack.

I love that. I really love your point around don't make me think is a little bit more sophisticated than people tend to give it credit for.

I think the like classic example of that we always talk about in our design reviews is everyone loves buttons that are just icons. It's simpler. There's less to look at. The interface is less busy. I will tell you, if you ever add a text label to a button, immediately people will think less and they'll probably click on the button more if it's actually useful. It doesn't look as good, so sometimes you can't do it. But I mean, as just a simple example of legibility, comprehension over just the form of things.

Completely agree.

The other one, be a great host, which is maybe kind of simpler. We talked about it via story usually, which is if you ever have gone over to be a guest at someone's house or stayed at an Airbnb, you know that moment where you walk into a bedroom or the bathroom and you see the towels and they're hanging and you're just not sure whether those are the towels meant for you or were those just towels that happened to be there and not actually fresh towels versus the very simple act of fold, towels and put them at the very foot of the bed. Those towels never wound up there by accident. As soon as you see that, you know those are fresh towels for you. It was a small little thing that someone did to be a great host so that, you know, you're coming into something and it's like perfectly set up for you. And so we talk a lot about that in software. We think about Slack. It is a digital manifestation for a lot of folks of their physical working environment, right? For companies that You use Slack, you know, the average person is in it for 10 hours a week. And so we take a lot of responsibility and a lot of obligation with what does it mean to be a great host in that digital environment? What is the places where we can round the corners? And I don't mean visually, but like round the rough edges where we can fold the towels, uh, ways in which we can be conscientious of the time and attention people are putting into the product. And so that is something that we talk about a lot as well. Part of the mission, one of the words, there's 3, is pleasant, making people's working lives pleasant. And the pleasantness is tied into the product development via this principle of being a great host.

Yeah. And this translates into a lot of things, I assume, right? Like craft and feeling comfortable, feeling you can trust your space. So there's a lot of derivatives that come out of this principle.

For sure. Okay. The last principle, this idea of a utility curve.

This is seek the steepest part of the utility curve.

Yeah, which is definitely just a weird Slack concept, but has become very important to how we build product. If you imagine on the x-axis is the level of investment you've made in an individual feature, and it just goes up over time. The idea is that on the y-axis is the level of behavior change that you see from customers or an end user. Hopefully the more effort you put in, the more behavior change you see. And so what this principle, seek the steepest part of the utility curve, means is the idea that you need to put enough investment into a feature from a capability comprehension, being a great host, not making people think functionality perspective, where you reach the part of the curve where that work starts to produce kind of an exponential change in behavior or increase in utility for the customer. This all maybe sounds obvious in some ways, 'cause you're like, well, obviously, why would you stop working on a feature before that? But I think if you look at most companies, especially larger companies, what you wind up seeing is that people typically decide to stop working on a feature long before it ever reached that exponential return. And you decide, okay, this isn't actually worth investing in. And then you have a bunch of features that are basically kind of orphaned in the product. And then when your users use it, they feel it. And then conversely, you have to know when you reach the other side of the curve, which is to say, all right, there's no more capabilities we can add to this. It is as fast as possible. It has reached its fullest conception of itself. Now's a good time for us to kind of put this thing more in a maintenance mode. So it's knowing how to get to the exponential part and then knowing when you're reaching the point of diminishing returns.

Oh, we can spend an hour on this one. Like I used to see people kind of getting obsessed with launches. I launched this and I launched that, and I never really understood what's the kind of excitement around the launch if nobody's actually using it, if it's not like a really valuable experience, if it's not really taking off, if you really haven't crafted it yet. We're going to take a quick break, but don't go anywhere. When we come back, Noah is going to explain how Slack succeeds within the crowded world of collaboration tools.

How we've always viewed Slack is less about Trying to win in every category and more about how do we make all the tools that your company's already buying and using that much better because they have this connective fabric of Slack.

All right, we're back and I'm speaking with Noah Weiss, the former CPO of Slack. I want to shift us to something which I think Slack is really known for, the idea of consumerization, bringing the craft of building consumer products into B2B products. You being very much a consumer-oriented leader coming into what is a B2B company, I'm sure was a great fit in that sense. But I'm curious for you, what do you think consumer companies can learn from the B2B side? What is something that surprised you or you think, wow, that would be wonderful for their career and for their products?

Yeah, it's the inverse of what typically folks ask, honestly. Having worked on both sides, I think the best aspect of the B2B world, if you really throw yourself at it, is that you can focus on building something that people love enough so much they'd actually pay you for it. And obviously when you're selling to businesses, sometimes you just start with what would people pay me for? And then I'll try to build some functionality. I sold them something, it doesn't even work the way that it sounded it would, but now I'll build all the features people ask me for. But conversely, I think on the consumer side, especially more on the mobile side or on social as well, it's usually like if you build it and you get to enough scale, eventually you'll figure out, you know, can you throw ads in it? And I think that model has stopped working a long time ago. There's, you know, an oligopoly, if you will, especially on the ad tech side. So I don't think it's a very viable strategy, but you still see so many companies doing it in these consumer products wind up being more toys than actual tools. I mean, I found it incredibly freeing to actually work in a world where obviously you care a tremendous amount about the end user, about customer love. I mean, that's the consumerization of the enterprise side, but also that you can measure your success of, are we building something valuable that customers feel it's obviously worth paying for? Even at Slack, we talk a lot about where we want to push the product. It's all about Think about whatever that next audience is gonna be for Slack. How do we make Slack so obviously overwhelmingly valuable that the choice to pay for it is a trivial one? And I think bringing that same mindset to the consumer world is a great thing to do. And frankly, a little counterintuitive, especially if you come from more of a mobile or social background.

It's a wonderful insight and one that tends to be pushed aside by consumer builders. because they assume, to your point, that they can monetize once they reach a certain scale, almost assuming that what happened to 3 companies will happen to them as well.

Right.

In the space of collaboration and communication, and this is interesting because you wrote to me that you're using Slack a lot more than email, so you're slow on email and you're fast on Slack. I'm curious, in this space, there's so many tools, and unless you work at Slack, I don't think there's one dominant way to work, right? I look at LinkedIn, Email is still very strong, and whether it's Office 365 or G Suite or Slack or Teams or Zoom, even like phone messaging. So when you think about it as a product builder, this is not a winner-takes-all strategy. This is not how do I get them off other products to join and use Slack? How do you think about who you're building for and what is kind of that persona or job to be done that you have in mind?

I'll give you a A macro answer, a principled answer, and then what our actual audience is as we think about it. So the macro answer I think is if you look over the last decade in the world of enterprise software, the only constant has been that every year companies are using more software than the year before. I think the last I checked, the average Fortune 500 company has over 1,100 unique vendors of software that they use. And I'm sure if you talk to the procurement department of Microsoft or Salesforce, they'll say that number is probably 2 or 5x that, right? So one, I think it's just the macro thing. It's not just in the world of collaboration or communication. I think it's in every single crevice of the knowledge worker kind of day that you're seeing this explosion of both horizontal and specialized job-to-be-done style tools. But I think the beneficiary is obviously people in their working lives have incredible amount of leverage that they're getting from software they didn't used to get before. Okay, that's one. Second, and I can promise you this is one of our principles, Slack seeks to be the 1% of your software spend that makes the 99% that much better. And when you ask that, what do we do about this world where it is not winner take all? From the very early days, like literally the first version of Slack in beta, one of the killer features, if you will, was that there was 45 out-of-the-box integrations with all of the top tools that small teams who built software needed. You know, it was like GitHub and Jira and G Drive and whatever. And now there's, I think, something like 2,600 applications from third-party vendors in the app store. So basically you pick a software provider, they have an app in the app store. And I think that honestly is how we've always viewed Slack is, Less about trying to win in every category and more about how do we make all the tools that your company's already buying and using that much better? 'Cause they have this connective fabric of Slack that helps tie your tools, your data, and your team all together in one place. Last thing, audience. And I think this is a little bit also unique to Slack and it is a little bit the origin of the company is we are very much focused on the primary audience is a team. Even at large companies, we think about an atomic unit of a team and how do we make their working life simpler, more pleasant, and more productive. I think maybe sometimes through the sugar end of our enterprise sales team, we are never gonna look at the CIO as the primary audience for Slack. They may sign the contract, they may be the person who gives the list of here's all the checkboxes that are unchecked, or here's all the diligence we need to do. But fundamentally, the motion that has made Slack successful is that someone on a team says, I wanna work in a different way. I'm tired of the old way of working. And they've heard about Slack and they create literally a team in the product. They invite a couple teammates and they see, is this for them? And if you're at Amazon or Netflix or Disney, some of our big Fortune 1000 companies, or you're at an SMB, it always gets started in the same motion. And so for us, the fundamental thing is, can we make that team more productive? Can we reduce the level of context switching and mundaneness in their job? And let's focus on above all else, an audience and a buyer at the atomic level of a team instead of an organization.

This is great. I love it because it's different. I think if you ask many product builders, who are you building for? They'll try to describe a person. I think it's rare for people to come back with like, my atomic unit is not a person, it's a team.

Yeah.

And this sounds like that's how you build internally. You're not thinking about a specific person. Another process that you do is looking at other products and trying to dissect them. And this is not necessarily a competitive analysis, but it's more around how can we build better products?

It's very hard to be really honestly self-critical of the features you build yourself, right? Because you have a lot of vested interest in ego and everything in the mix. And so sometimes I think teams can get stuck. It's hard to look at it with fresh eyes. Obviously user research and other things can help, but we came up with this, we call it internally a complaint store, but we mean complaint in like the positive sense of like find things that are worth complaining about to get inspiration. And what we'll do is as a team exercise, so the whole product design engineering group, pick a product, not from a competitive perspective, it could be from a totally different space, but that is solving a similar problem that the team is working on. So let's say you're the onboarding team and you're like, let's do a complaint storm about the Peloton onboarding and unboxing experience. One person drives, everyone else is jotting notes and complaints down the side. And then the idea is you're getting inspiration from a totally different domain to bring back to your own product area with hopefully fresh eyes. Not because, to be clear, setting up a Peloton has anything to do with setting up a Slack team, But because people can get stuck in that onboarding space, just as an example. And as a group, it's doing this kind of critical thought exercise, if you will. And that winds up being just a really useful tool. Probably periodically, maybe every quarter or 2, teams will sometimes go through this exercise or do kind of like a teardown of an interesting new product that just came out.

Yeah, this ties back to your superpower, your curious mind. And I think you can learn a lot from how others are doing it, even if it's a whole different domain. Because it could really spark ideas and curiosity. Okay, it's hard to end the podcast today without talking about the future, especially with AI. So obviously early days, I'm sure years from now we'll kind of laugh at what we thought about the future would be and how it changed dramatically. Yeah. But I'm curious how you think about the future, the next kind of 3 to 5 to 10 years with AI or without AI in the space of collaboration, communication, your space, your area of expertise, how will that change or not change in your opinion?

Yeah, I think it's interesting to think about how much this will change over the next 5 years because since 2008 when I worked on the ML team within Google Search, I've been following the space of 15 years.

And you were brought into Slack as the AI machine learning product leader, correct?

Right. Yeah, that's how I kind of started. So I both have a tremendous amount of scar tissue from the last 15 years, but a tremendous amount of optimism for the turning point I think we're in right now. So a couple things, and these are hot takes, these are predictions, these are not representative of our corporate position or anything like that. One, I think inevitably we're going to have to see the model sizes for these LLMs go down so that eventually, for at least specific purposes, you can run them locally device side, because right now the bottleneck in terms of everything effectively having to run in the cloud, lack of GPUs, and also you have all this computing capacity on everyone's mobile and desktop device that's going underutilized. I think that's going to have to happen. What that will enable, I think, is that every text box at an OS or browser level is going to have the basic ability to expand or compress text. Which is kind of the basic of what people are doing with LLMs, right? You're either going from a kernel and growing it, or you're going from a very long thing and compressing in different ways. And I think that idea of summary or synthesis at a text box level is going to be embedded in the operating system, just like spelling and grammar correct is now. No application developer is building spell correct into their application because the operating system takes care of it. So then I think you're going to say, well, okay, well, what are people going to be doing instead? And I think it's going to come back to the 2 things that have always mattered in the space of AI, which is the data your application has and the intention you have from users. I'm not betting on conversational, not conversational, proactive, not proactive, but I think we're going to go to a world where the basics of the text compression or synthesis is going to be at the OS level. The application level is going to have much cheaper models that run much more performantly, probably a mix of open source and closed source, but at a much different price point than today from both a hardware and model perspective. And I think what won't change, just to back up the question, I think how much customers and end users care about trust, privacy, and security, that is the opposing force right now. I think in this world of generative AI, especially in the enterprise space, when you actually talk to any enterprise customer, the questions come back to, how can I trust this? Will it produce accurate and real results? What is the security model? What happens to my data? And I think on the consumer side, frankly, what we've learned is people don't really care as long as the thing is really useful and really cheap. The enterprise space is very different, and I think that will not change over the next 5 years.

It's a great point. I think sometimes it tends to be assumed as regulation. In this case, companies care tremendously. It's their IP. In a way, that IP makes the teams better because in a conversation, a team collaborates in an ideal form. New data is being created. New data fuels AI to become better. So just the conversation part inside of Slack or a place for collaboration should make the application much, much better, which is unique to a company because that's basically their IP.

Totally.

I think there's something really special there. That's really insightful. Noah, this has been great. I've learned so much. I have notes here all over my desk. Thank you for joining me, and thank you for helping us learn more about how you work.

Thank you so much for having me. It's been a blast.

What a great informative interview. There certainly was no shortage of takeaways. So let's get into them. First one, stay curious. Noah prizes intellectual curiosity, and one way for an organization to foster that is by encouraging a lot of internal mobility. That way, teams can share and mix their experiences and lessons from many other different domains. That kind of mobility builds a mix of perspectives that then can cross-pollinate and kindle innovation across the whole organization. Second, product-market fit is a prerequisite for success. But not a guarantee for the future. You need to think about how you will expand beyond your initial user base while retaining them as well. For Slack, this meant first focusing on small teams in the software domain before expanding outward into other domains and then expanding upwards into progressively larger enterprises as a whole. Each step required reevaluating the customer base and their product needs while preserving much of what worked in the earlier days. This makes product-market fit a moment in time, not a continuous baseline. Third, I believe it is extremely important to align your team along some common principles or beliefs to make sure your product is built and expressed in consistent ways. Noah shares some great principles about how they build at Slack. The one that stood out for me was about seeking the steepest part of the utility curve. Product teams, especially in large companies, are notorious for launching new features or experiences and then leaving them half-baked, underdeveloped, or abandoned. At Slack, they believe you need to put enough investment into a feature such that you reach the point where that work starts to produce a large change in behavior or utility for the customer. You only stop when you reach a point of diminishing returns. Next, while Slack is one of those poster childs of bringing consumer product mindset into the enterprise, it was great to hear Noah talk about what consumer product builders can learn from enterprise development. And that's the viability of your product. Figure out what customers would love enough that they would actually be willing to pay you for it. Instead of relying on scaling first and then figuring out monetization, Ask yourself, what would people value at the beginning? Lastly, know the breakdown of who you're trying to appeal to. That might not even be a specific person or audience. Slack's primary audience are teams. They're not necessarily trying to appeal to the Chief Information Officer. Instead, they're trying to rally adoption from those teams who will be the most frequent users. That's how I got my own invitation to join Slack early on. When you think of this conversation, What guiding principles or beliefs would you introduce into your product or organization to better serve your customers? Remember, strong principles have teeth. They voice a clear opinion that is not always widely accepted. Let me know on LinkedIn. I'm Tomer Cohen. Thank you for listening. I learned a lot from this conversation, and I hope you did as well.

We'll be back in 2 weeks with with a new interview with the CPO of Cerebral, Alexandria Streed.

Folks who went to 3 therapy sessions in their first month were more likely to stay past 6 months.

Can't wait 2 weeks? Then tune in next week for our rapid-fire question round with Noah, where we get to know him better.

I mean, my headspace is completely in the baby gear world.

Building One is a LinkedIn editorial production. Our host is Tomer Cohen, LinkedIn's Chief Product Officer. This episode was produced by Max Miller and Lolia Briggs. It's engineered and mixed by Asaf Gadran. Enrique Montalvo is our executive producer. Dave Pond is head of news production. Courtney Coop is head of original programming. Dan Roth is the editor-in-chief of LinkedIn. Thanks to Alicia Mann and Jenna Kaplan. If you know of a product leader we could all learn from, send us a line at pitch@linkedin.com.