People, Process and Product: A Product Leader’s First 90 Days | Notion CPO Madhu Muthukumar

Welcome to SaaStr Build. So thrilled to have Madhu Muthukumar, Chief Product Officer at Notion. He's going to be joining us and doing an incredible session on a product leader's first 90 days. We're so excited to hear all of Madhu's lessons learned. Without further ado, I'm going to pass it over to him. Take it away.

Hey, thanks, Taylor. Hey, y'all, I'm Madhu. I'm pretty excited to chat with this group. About people, about process, and just a little bit about product and truth. I'm excited to chat because I normally don't do this, but when they asked me to talk about the first 90 days of product leadership, it made a lot of sense because actually today is day 75 for me here at Notion. You'll be surprised to also find out that probably this is one of the biggest questions I get. It's one of the biggest questions I like to ask, which is, hey, how do you get started in a new job as a product leader? And so I'm going to try to do my best to walk you through things that I've learned and things that I'm doing very actively Uh, here's— I get started. Um, before we jump into it, here's a quick background on me. Uh, you can find a lot about me on the internet, but the stuff that you probably should know before getting into this is, um, I've been an operator. I've led product teams at a few companies, mostly on the consumer side. Spent a few years at Robinhood leading the product team there. I was at Oculus where I got to build the software side of VR, uh, and before that cut teeth at Twitter building consumer mobile, uh, both in San Francisco and in the New York offices. A lot of what you're going to hear from me today comes from those experiences, but also experiences as an investor, experiences as an advisor, and things that I've just seen from accelerators and peers of mine. So a lot of these are going to be my thoughts. They'll be informed by people that I've worked with, people that I admire, great advice that people have given me over the last 10+ years. Okay, so let's set some ground rules. What can you expect from this chat, because I think it's going to be a little different than a few other talks maybe that you've heard. The first thing is, if you're here to hear about product strategy, I got bad news for you. There are a lot of talks about product strategy and how to build a good product. That's not what I'm going to get into. And the reason is because this is very unlikely to be the thing that gets you on the wrong foot in your first 90 days. So if you're in for product strategy, I'm very sorry. I'll watch the participant number drop, but this is not the talk for you. If you're looking for tips on the right way to build something or the right way to lead something, I am not sure that there's such a thing. So if there is, I'm not the person. If there's not, you're not going to get it here. So I just want to be as honest and specific about my approach as I can be. That's, that's sort of what you can expect. If you want to hear specifics about one of those companies you just heard about, or maybe you've thought about a person who works there and you can't wait to hear a little bit of of juicy gossip. I'm going to be respectful. I'm not going to name any companies. I'm not going to name any people. But I am going to try my best to be as specific as I can be in talking about them. So those are things that you probably won't see. We are, however, going to have a few catchy stories and maybe, if you're lucky, a few catchy quotes. I'm going to try to cover a lot of ground. I'm going to try to do it quickly to leave time for Q&A at the end. But ideally, success for all of us here is tomorrow, you know, you're taking a shower, you're riding your bike, you're in between meetings, and one of these stories, you know, sticks with you. And then maybe the next day you think to yourself, you know, that was pretty good. I should get a tattoo of one of those quotes. All right, let's jump into it. Let's say there are these two orange circles. And for those of you in the room, you get to pick. Let's say they're an amount of money and you get to pick either the orange circle on the left or the orange circle on the right. Doesn't matter to me. You can take either one that you want, but you have to pick one. Which one would you pick? Okay, we're at a conference, so you know it's a trick, and you probably know the trick. This trick is called the Ebbinghaus illusion. It's been around since about 1900, and what it shows is the two circles are actually the same size. Why is this important? Well, it's because despite this reality and despite probably everyone in this room knowing this reality, it turns out that these other gray circles, the context that's sitting around them, the relative size of these circles still tricks us. It doesn't matter. As humans, we can't just accept reality. It's always shaped by the stuff that's around it. And I think maybe that's the first thing I want to dive into about getting started as a product leader. So at one of my stops, I was at a company that was trying to boost its growth. Nothing surprising. We brought in this fantastic product leader, confident, charismatic, someone who had led teams before. And we were very, very excited to have this person join the company. The leadership team had been really looking forward to someone who could come in and act as sort of the anchor, where we could do a lot more data science, a lot more modeling, a lot more research, and really start to explain the models of growth that would take the company to the next level. At the same time, a lot of engineers and product managers had transferred onto the growth team, and they were ready to have a leader, a manager, someone who could help unlock them to just do do more, ship more, go faster, and kind of give them the space to build an experiment. And when this leader came in, one of the first things they thought a lot about was, how do I change the culture? How do I get us to be building large, good products that change the kink of the curve for the company? And so about, I don't know, a month in, all three of these things started happening. We would have leadership meetings every two weeks to dive deep into the research and data that were very, very, very controversial, high debate. High output. At the same time, the growth team started unlocking tons of work— building, shipping, building, shipping, building, shipping— and this leader started conversations about having much larger projects for the team. Unfortunately, if you fast forward that a couple of months, these things just started to collide. Those biweekly meetings didn't really seem to be yielding anything. The teams that were building and shipping didn't seem to find themselves having a lot of support. There was no big project that was landing with the growth team, and you could sort of start to see the edges show up. And it wasn't much longer than that, maybe a couple quarters before really people started just being upset. You know, the leadership disbanded the biweekly meeting. This product leader realized that there wasn't going to be a big project. And actually, the team stopped shipping and people started leaving. And it didn't have to be this way. I think everyone was pretty excited. So what happened? Well, Mo Gawdat from Google X summarizes it this way, and I really like this. I think it's a short version of what probably happened here. Reality minus expectations is happiness. So reality, the actual things that happen, those orange circles, how people perceive those events, that's all reality. Expectations, the things you thought were going to happen, the way you thought you were going to feel, and the delta between those. How much better is reality than what you expected? That's going to be your happiness. That's gonna be how you feel about the situation. So why is this hard for new leaders? I'm not telling you anything you don't know. But for leaders in your first 90 days, there's something that's really tricky about this. The first is that this equation applies to you. You have a set of expectations. You have a new title, it feels great. Maybe you're the head of, maybe you're the director of, you're the group of, amazing. And you think to yourself, wow, I've worked so hard to get here. I can't wait, now I can do blank. But it's not clear if that's reality. That's not all. Your manager has a set of expectations, your manager has a reality, and they have been waiting for you to show up. They have a set of things they want done, they have a set of expectations that they want. And in fact, your ability to deliver in that gap is going to set their happiness. And as a leader, by definition, you also have a team, and every one of those people on the team has their version of their expectations, and reality. Will they get that reality? So all leaders face this. Nothing surprising. But for product leaders, there's a twist. Product itself doesn't ship anything. Breaking news, as a product leader, you know, we're kind of expendable. When you start a company, you don't need a product manager. In fact, engineers, designers, researchers, data scientists, marketers, salespeople, they're doing craft. Product manager's job is to bring that together. And so when you look at your time as your first 90 days, one of the things you have to realize as a product person is it's not enough It's not good enough for me to close that gap on managers. It's not good enough for me to close the gap with the other product people on my team. It actually matters how my peers feel, and it matters how my peers' teams feel. That's not it either. There's actually one other twist that's really difficult. It's that product means something different at every company. I wish someone had said this to me early in my career. When I first got it started at Twitter, I thought I was learning this amazing thing of how to build product. But across my career as I've built hardware and software, I've been in engineering-driven cultures, I've been in design-driven cultures. I've been in places that are well-resourced. I've been in small startups. What you realize is that everyone's mental model of what product is is different. So as you're going to all those stakeholders and you're trying to figure out— you, your manager, your peers, your peers' teams— in the back of their heads, those expectations are set from something slightly different. And that's a challenge. There's no way around that. OK, so here's what I'm doing. Again, like I said, I'm not sure there's a right way or a wrong way. These are just observations that I have. But here's what I'm up to, just so you see it cleanly. The first is like, I tell myself every day, my job is to close this gap. I don't want people to be surprised. I don't want people to be taken off guard. And I want to say the things that I'm about to do and then do them. So the first step for me was spending a lot of time listening and listening even before I got started. That meant spending time with the leaders of this company, the founders, and getting uncomfortably specific. What do I mean by that? I mean questions like, If a team disagrees with your decision, can I override it? If a pixel needs to move from here to there, can I do it? If you don't like a candidate and I like them, can I hire them? I find that people don't ask these questions because they're uncomfortable and because it's so much easier to just say to yourself, well, I'm now the head of, or I'm now the leader, this is great. So at least for me, I spent a lot of time doing this. I've been fortunate to be around leaders who are really, really open and direct. Okay, the second thing: when you get in, ask other people to tell you what your job is. I spent a ton of time when I got started here— I think I did 50 one-on-ones in my first 30 days— and one of the most important questions to me was, what exactly do you think I can do to help? And the reason is because I'm trying to hear from people what their expectations were. Maybe they're exactly in line and I need to meet them because I don't know the company's context. Maybe the other way around, what they're looking for is something that's superhuman or like much better than at least my capabilities would allow. And so spending a lot of time asking other people to tell you what your job is has a ton of positive effects. One of those effects is that it gives you the signal of where there's disconnect. It tells you, hey, what my manager wants is actually slightly different than what my peers' teams want. And you have an opportunity to then say those quiet parts that only you know about out loud. You can play back what you've heard. You can tell people, hey, we think we want this and we also want this. And then you can start to figure out your plan going forward. I was optimistic that I could actually share with you guys a few pieces and real tools that I'm using to do this. But given the current medium, I'll do my best to screenshot. And if you guys are interested in actual templates, I'm happy to share them after the talk. But here's two things that I've built in my first 30 days. The first is exactly that, what I said. It's a listening tour. I went and talked to a bunch of people across the company. I distilled it down into a few thoughts, nothing surprising here. And then I published it to everyone in the company. The second thing I did is I wrote a 90-day plan. Actually, I rewrote it. I sort of had an idea of what I thought I was supposed to do. But after those conversations, realized, hey, I can be doing more. Let's publish this. Let's show people what I'm going to do. I think it's important to be able to say you're going to do something and then do it. That is part, you know, of the equation of trust. And so these two things I'm happy to make available if anyone wants after the talk. OK, so you're in, you want to get started. What does everyone tell you when you first get started? At least for me, when I was an IC, the first thing that people said to me when I joined a company was, hey, it's great to have you here. I hope you'll be able to influence the team. Right. So here's an example of a really well-staffed team. We're not quite here yet at Notion, but we will be soon. Imagine that you're the product person, you're a designer, you're a PM. You've joined this team and, you know, your manager kind of gives you this advice. Oh, it'd be great for you to influence your peers. You know, we're an organization of influence. Controversially, I think this is bad advice. And the reason it's bad advice is it's the same thing as me telling you, you know, a good idea for you to do would be to open your laptop or use the internet. You don't have a choice. You're coming in and you don't have reports. There's not really authority in most of these roles. And so as we tell new people joining our teams, hey, come in and influence and grow your influence on the team. Yeah, they don't have any other alternative. That's not true for leaders. I think sometimes that can be a struggle. So I'll tell you another story. I was at a company that was growing extremely quickly. And again, we were looking for a seasoned product leader that could help sort of tame the chaos. We were hiring super fast. You know, every team was growing and just keeping tabs on how product and design and research and partnerships are operating was pretty tough. The founders came to me and said, hey, can you help us interview? I was very excited to do it. We found a candidate who was fantastic. And they came in with a ton of expectations, a ton. So what did they do? Well, they hit the ground running. They hired 2 or 3 people right off the bat. They did it super fast. They pushed them through the process, you know, made sure that new folks were on the ground right away. They reorganized teams quickly. You know, they knew that there were things that needed to be changed. They went fast in moving people around. None of this was a surprise, but it started to add up. This leader then changed all the meeting structures. This leader then changed all the documentation. They changed the when you talk to leadership, and they did it quickly and kept on saying to folks across the organization, look, my neck's on the line. I've got to do this. My neck is on the line. We need to be able to change. We all need to be able to get something done fast. Before you knew it, people were pretty unhappy, and it wasn't exactly clear why. Most of these changes were changes that people understood. I don't think that this is an issue of, oh, you know, I didn't think the meetings could be better. But as the meeting started adding up, as the changes started building, as small things started to slip— this leader would be late to a meeting or didn't read something that they asked for, or told everyone that we needed to do something a certain way— these grumbles really picked up, and they picked up fast. You often hear this advice as a new leader, don't make any decisions in your first 30 days. This was a lot of decisions. And people became pretty unhappy. So unhappy, in fact, that a bunch of product people left the company. And even our HR team had to intervene. All right, so what happened? I think as a leader, you come in and you have those expectations. And maybe you got the first part of this equation right. You knew what the reality was going to be. You knew what the expectations were. And you set it right. So you went fast. You thought, great, everyone's on the same page. Let me go quick. I'm this new leader, I need to be able to put a mark on something. And the downside is, if you got to this point in your career, you're probably pretty smart, you're probably pretty capable, and you trust yourself. And so you lean really heavily onto your authority to get things done. So if you take a look at new leaders in an organization, and everyone says, hey, don't do things in your first 30 days, I'm not sure that's exactly true, but I'll try to be a little bit more specific. So there's obviously this path, right? Come in, you have a role, whatever it is, just start making direct asks. Impose sort of your way of working, think about it, listen to people first. But there's actually other ways to influence groups. If you listen to Cass Sunstein, who's a professor at Harvard Law, he's a behavioral economist, he's worked for the government, he actually says there's 3 other ways that leaders can move teams forward. And I started to ask myself, how come people don't do these things? So I'll walk through each of them really quickly. This one's obvious. New leaders can use their own confidence, their charisma to try to kind of move a group in their direction, kind of win over people. I think this is bad advice because I don't really know how to frame it. Please be more confident. Please be likable. That doesn't really make a lot of sense to me. You can do it, great. Congratulations for you. The second thing Cass brings up is giving a group common goals and common motivations, right? Get rid of the constraints between people, give them all common goals and motivations, and they'll kind of go in the direction you want. The problem with this This is not fast at all. It takes time to build this, right? Like, if you want to get everyone on the same page, you have to sort of figure out what page they're on in the first place. And then secondly, this is not reliant on you. The first two are entirely in your doing. You can make the ask, you can be charismatic. But in this case, you actually have to align quite a lot of people to move forward. For me, the most important one, the one I think a lot about, is this last one, which is how do you create an environment of belonging? And in fact, this one takes the longest time, if you will. It's very, very hard to make people feel like you are in fact a team. This isn't about confidence and charisma. This is about people feeling like they're together and trusting each other in a group. What does this look like? This is a great question. Someone said, how do you know if you have this? And so, you know, it's a conference. I want to play a video for you. You don't really need a lot of background on this video, but I'll give it to you. The guy in red is the best basketball player of all time. This is the year 1989. He's just received a new coach that he does not like. He said it publicly. And this is a clip of how I think a great leader can belong. Well, there's the man, Michael Jordan. His brand new pair of Airs, that black look that he put on during the Cleveland series, and now even the coaches over on the sideline. One difference. Michael can afford to give away his after every game, which he does to a local charity. And Phil can't. Phil's got to wear his the rest of the way. Phil Jackson, I don't think I'd wear that on a Saturday night. All right, uh, maybe you caught it, maybe you didn't. Phil Jackson is the coach. Uh, he is responsible for determining which players go in the game. He determines what the plays are. He determines who gets the ball to some extent. Uh, and with all of that authority In his first year, he wears a suit on the sideline and puts on Michael Jordan's shoes and wears them to say, we're on the same team. They literally wear jerseys to say they're on the same team. And this man decides that a good way to lead is to say, hey, I'm on the same page as you. I'm doing this with you. Cut the story short, they go on to win 6 championships in 8 years. If you're a basketball fan, this is all legendary stuff. Belonging and influence are not natural things. I think they take time. Okay, that's true for all leaders, right? Every leader has this— has the same challenge in front of them. But I think actually for product leaders, there is a twist that is also hard. And that goes back to this diagram. We build product teams to be diverse. We build product teams to disagree and to dissent. We build product teams to have a lot of ownership. And I think when you have diverse teams, when you have strong, you know, operators who want to disagree because they know it's in the best interest of their product and their company, If you come along and just say, oh, hey, well, I can align everybody and I can just try to build belonging, it can be tough. Doesn't mean it's not possible. It can just be tough. And so I think a lot about that as I'm getting started in my first 90 days. Specifically, I think about these things. There's a saying in the airport in Johannesburg, in O'Rah-Tambo International, where I used to live, that says, if you want to go fast, go alone. If you want to go far, go together. And I try to remind myself every day that my job is to go far, not just to go fast. And so I think a few things that you can take with you. The first, start with what's working. So much of your time as a leader is going to be about fixing what's not working. When you get started, just spend your time trying to understand what is working. What's going great for this team? How can you plug in to what they're doing? I think the second part of that is to redefine the term of us. You want to be part of us. You don't want there to be leadership and team, or product and research, or New York and San Francisco. It is a difficult job to bring people together. It's natural, especially in larger organizations. But trying to redefine us to be a broad set of people will definitely help. The last— I just believe this truly as a personal philosophy— no double standards. Do what you ask for. If you want people to write an update, you write one yourself. If you want people to show up early, you show up yourself. If you want people to write documents, you write them yourself. And if you want people to edit them, you edit them yourself. No double standards, no privileges. Put on the same shoes. So here's two things again, happy to make them available at the end, but two things that I've been doing. Like I said, I do ask all product people to write a weekly update. So in return, I write one as well. I write it for the organization and I publish it broadly. I just think that that's my responsibility as much as anyone else's. And the thing on the right are my weekly priorities. I don't ask anyone else to write these, but I do write them and publish them to my team every single week so they can get a sense of what I'm doing. I think that's just a matter of fairness. And I do really want to be a part of the team. I want to set the expectation that we're all in this together and play that game over the long term. Want to go far, we want to go together. OK. Another thing that I was always given advice about when you get started is there's just too much work. OK, you got the expectations down, you've got the team in a good place. There's so much work. Those of you who are really like productivity enthusiasts will know this as the Eisenhower Matrix. And it's not really that difficult to explain. If something is really important and it's really urgent, you should do it. You should do it now. If something is not urgent, not important, you shouldn't do it. And then you can look at these striations. It's urgent but not important. Have someone else do it. And then, you know, if it's important but not urgent, you can just do it later. But I think there's an issue with this problem. The issue that I've kept coming to is how exactly do I know what fits into these things? Eisenhower, I think, is a much smarter man than I was. Or am, and he seemed to be able to put these things in the boxes much better than I did. Here's what I keep getting trapped on. There's only an amount of me, and there's only an amount of effort I have, and those things yield results. And so once I figure out what's urgent and important, they all go into the top box, and then I'm really pinned by just this, like my own capability and the amount of effort and time I have. I think this is true for other leaders as well, and you see them kind of do this. They change the equation a little bit. They're like, okay, well, if I just up the effort, you see, Then I can up the results. Everything will be totally fine. But it turns out that, you know, this doesn't work either. And I think many of you probably know that. But another story that's really quick. I joined a company that was growing really, really fast, and I joined because I thought the manager was going to be great. Manager had a ton of scope, had done some really impressive things in the past, and just was really charismatic and high energy. So I join, and in the first week, it becomes really obvious to me that the scope is just massive. Big, big, big, big scope. Managers running around, I mean, literally running around. You would see this person in the hallways jogging. And things would sort of get blocked on this manager a fair amount. Like, we'd write product specs, you wouldn't get any feedback from them. You'd have like a design or a mock, you wouldn't hear anything back. You'd make a request like, hey, can we unblock this? Can we get some time with leadership or the founders? And things wouldn't come back that quickly. Hiring decisions started to sit. And so, I wanted to join a high-growth company. And so I pulled the manager aside and said, hey, can I just take something off your plate? Maybe you can let me do X, or maybe I can help onboard someone, or maybe I can take this project. And this manager would think about it a lot. And then maybe 20% of things they would say to me, yeah, why don't you take this? But 80% stayed with the manager. And this kept going. This kept happening for a few months, the running in the hallway, the lot of work. And then something weird started happening. I started noticing that my one-on-ones with other people, they would bring up the same problem. They were like, "Ugh, this person's just running around. I keep trying to take stuff off their plate. They're not really giving it to me." And then it got worse. Then it got worse because those one-on-ones started turning into, "Do you think the manager trusts us? Do you think that they think—" We're not competent or that they're doing a better job? Do they think that this is sort of like the expectation on us is that we just wait for them to do things all the time? This isn't why we joined a high-growth company. And then maybe the worst comments of all were people saying, I really like this person, but I'm pretty confident they're going to burn out. There's no way around this. And as these started to pick up in the one-on-ones, I started pulling this manager aside, so did a bunch of other people, and saying, hey, we really like you, but this isn't working. You know, you really need to find other ways to do this. You got to trust folks. And for some reason, that didn't work either. Fast forward just a couple more months, and unfortunately, the manager was asked to leave the company. Why? This person was competent. This person was charismatic. It just kind of got stuck. And my why comes back to this. It comes back to the Eisenhower Matrix at least a little bit, because I think this manager was trying to do the right thing. And so there's this one odd part of the matrix that that I think it might just be a little bit off, respectfully. It's that if you look at the things that are not important, those are the ones that you delegate. Those are the ones in this matrix that you say, okay, either I don't do them or I give them to someone else. If you see that in the opposite, that means that anything you think is important, you yourself have to do, or you have to lead other people in doing. That gets really hard. And in fact, that misses some of the forest from the trees. This is what I think the equation actually should be. The equation should actually be, instead of you turning up your effort to get more results, you should turn up the number of people who can work on something in order to get results. And that doesn't just mean hiring. That means give people some of the important parts. So in the 1950s, there were a ton of these kind of on-the-shelf cookie mix, pie mix, pudding mix, cake mix. And this company, Betty Crocker, found that they weren't doing very well. They were selling cake mix, but no one was really buying it. And a few geniuses inside the organization had a theory. Their theory was called the egg theory, which was that no one liked the cakes because no one felt the cakes were their own. You were just kind of taking powder, putting water into it, and putting it in the oven, and out came a cake. So what if they took the powdered egg out, or they took out some of the powdered milk, and they asked people to do the work themselves? Crack a couple eggs, help yourself make the cake. Beyond that, they even marketed it. You add the eggs for that special homemade goodness. Because of course, eggs are special. So yeah, guess what happens? Cake Mix sales go through the roof. Like I said, geniuses, smarter people than I am. This is not how I would have fixed the problem. I think too often managers don't give other people in the organization important parts. They save the important parts for themselves. And they say to themselves, I'm doing it because it's important. I'm doing it because it's urgent. I'm delegating all the other things. We forget that labor can lead to love. You know, if you listen to Dan Ariely talk about IKEA theory, it's all the same stuff. It's that people value the things that they put their time and effort into. And leaders often forget, hey, I should let people do those things. I should let people be part of it. So why is it hard for product leaders? This is probably my first and most controversial take of this talk. Since I can't hear you booing, I'm going to assume that you're going to. But this is the biggest thing that I worry about for product leaders and for founders, is that not only are they unwilling to give up the eggs, not only are they unwilling to say, hey, other people after the important parts, they think of the mythos and they ask themselves, What would Jobs do? And when they think of that, they say, oh, he would look at every pixel. He would check every screen. He would never let any of these go. He would make sure that everything is perfect. And they would get themselves into the weeds. And they will— even the most mundane things. You're not even giving people the chance to open a box of cake mix. Forget about it. You're involved. And I think that that can be a real problem. It blurs the lines between manager and I see it blurs the lines between who's accountable for the environment and the outcome. And ultimately, I think people tell themselves this story, they show themselves this mindset of who they want to be, and it gets in their own way. Okay, so here's, here's what I'm doing. Again, not sure it's right or wrong, but here's what I'm doing. The first is I'm choosing to believe that scaling is urgent. It goes in the top right quadrant, that anything I can do that will increase scale is in fact the most important use of my time. And I am spending my first amount of time fixing high leverage process. Process. That sounds like a really cool term. It's mundane. It's hiring processes and how we interview. It's meeting cadences. It's setting standard templates. And the reason for that is because these things open up more time. And if I can trade 5 hours now for 500 hours later, I'm going to take that trade every time. The second is I'm going to give away the eggs. I'm going to give away more than the eggs. I'm going to let other people build the organization in places that make me deeply uncomfortable. I'm going to let them set the interview process. Not to say I'm not going to do it, but I'm going to let other people take that first step. I'm going to let them design our design crits and what our culture around critique is going to look like. I'm doing that because I think it's more important that people buy in and are part of the process than it is for me to do the, quote, management things. And the last, and the thing maybe I'm most proud of, the last places I've gotten to operate is to create a culture of peer accountability. I say this to my teams all the time. Some people play pianos. Some people move pianos. Your job as a manager is to move pianos. That is my job. And there are definitely times where I can give feedback to the team, and that's an important part of my job. But it's more important to me that the experts on the ground are talking to each other. Takes a lot of work, but you do want designers coaching designers, product managers coaching product managers, researchers coaching researchers, not just managers. Okay, scaling is urgent. Like I said, it's mundane. Here it is, fixing interview guides, fixing meeting cadences. It's what I believe it sort of has to get done. Who knows? I'll let you know if it works. The last thing I want to touch on— every time someone starts a new job or I start something, I almost ask people like, hey, what book should I read? And this book comes up more than most— High Output Management by Andy Grove. It's fantastic. I can't recommend it higher. I love it. It's eye-opening to me how much is still useful to me as a manager today from when this book was written decades and decades ago. And there's one part of the book that I really like. It's called the manufacturing triangle. But I can never really remember exactly how Andy lays it out. He sort of refers to it a couple of times. And so I Googled it to, to be able to show you in this, in this chat. And it goes something like this. You know, there's time and there's cost and there's quality. And then inside of them, there's an amount of scope. So if you reduce quality, you reduce scope. But if you keep Googling, actually, it might be this. It might actually be that quality is in the middle and that, you know, there's this scope and there's cost. If you keep Googling, there's a version, I guess, where people are in the middle and they're the thing that hold the time and cost together. Maybe it's safety with a big S, and then, you know, you put quality and performance together. It turns out, like, really, I don't think anyone's got what Andy was trying to get to. This one is my favorite one. I will choose two, but I don't know why it's in the middle of the triangle. And then I finally stopped here because once you start seeing bright colors and drop shadows, you know that the answers are absolutely correct. And so there's something here. There's some correlation. There's some rule between cost and quality and safety and people. And I'll tell you how I learned it. Um, in the past, I was working for a CEO. CEO was super demanding, unsurprising, um, and the company was growing and growing really quickly, but our ability to ship consumer-facing features started to slow down. There's no two ways around it. And the CEO would kind of bring this up with me, you know, every couple weeks. Hey, we're not getting enough stuff out, we're not getting enough stuff out. And so one of the things that they would do is they would just set more aggressive deadlines. And when that didn't work, they would set more aggressive roadmaps. And half after half, we would get even less of this planned work done. So we're scaling, you know, more customers, growth is going well, but then all of a sudden there's like more ambition, there's more aggressive deadlines, people are shaking their head, they're working harder. And, you know, when you went and talked to teams, they were saying like, I just don't think the CEO understands, like, we have to do this work for security, you can't see it. We have to do this work for infrastructure, you can't see it. We have to do this work for compliance, you can't see it. And, you know, the CEO heard these things and said, no, no problem, no problem, you can go and do those things. What about these new initiatives? I'll just kind of run with these. And so we started having biweekly check-ins, we started having investigations into the velocity of our teams. You know, we started really pushing things, and from time to time things would move a little bit faster. And one time in the hall, the CEO caught me and said, hey, could you imagine, could you imagine a world where I wasn't doing this? Could you imagine how slow we would be moving? And it really stuck with me. Because I couldn't figure out why the CEO still felt we were moving slowly. And then sort of bad news hit us. We had a couple incidents. And then before you knew it, we were really unable to ship anything. The biggest things that we wanted to get out the door were blocked by infrastructure. A few decisions that we had made in the last year stopped us from some of our biggest projects. And things weren't getting delayed by hours or days or even weeks. Things were starting to get delayed by quarters and years. And in fact, people just stopped believing. Across the organization, no date was really believed in. They were sort of thought of as like mascots. It's like, hey, we all have this date, we parade it around, everyone cheers. But in reality, you know, we're not the fighting catamounts. You know, that's just a thing that we show off to get us all rallied up. So what happened? This is my simplistic equation. I'm not Andy Grove, but this is sort of my version of it. There's only 3 things that you, that you can, you can track. There's scope, which is like, what would you like to get done? There's quality. How well is this work done? And then there's time. How long does it take? And if you haven't figured out by now, I used to be a math major. That's why all the equations are on the, on the table. Scope times quality will tell you about how much time there is. Why is this hard for new leaders? All leaders? Well, I think there's a twist here. Here's the twist. Everyone wants scope to go up, and everyone wants time to go down. So there's only one variable that you can't see. And if your math is good, and you want the left side to go up and you want the right side to go down, that means this middle variable has to go down a lot. And the problem is, it's really hard to see. You can see scope, you can see if someone has done a job, yes or no, is it there? You know, did I ask for a document? Did I ask for a cadence? Did I ask for a feature? You can see time. Did I get it on Tuesday? Did I get it next Tuesday? Did I get it this month? You cannot see quality that easily. Okay, that's true for all leaders. But why is this true for product leaders? And here's to prove to you that I'm not I'm not a hater, I actually love Steve Jobs. I think this is the right time as a product leader to ask yourself, what would Jobs do? And good news, we can just ask him. And here's a take that I think is really important.

Market share, which is sort of what we're getting at. There has been a suggestion that because of pricing and design, Apple tends to appeal to kind of a smaller elite, rather than that sort of mass customer base. And so I guess once and for all, is it your goal to overtake the PC in market share?

I tell you what our goal is. Our goal is to make the best personal computers in the world and make products we are proud to sell and would recommend to our family and friends. And we want to do that at the lowest prices we can. But I have to tell you, there's some stuff in our industry that we wouldn't be proud to ship. That we wouldn't be proud to recommend to our family and friends. And we can't do it. We just can't ship junk. So there are thresholds that we can't cross because of who we are, but we want to make the best personal computers in the industry.

All right, Magic. Did you hear what he said about quality in there? He didn't say it's important to him. He used words like, it's who we are. He made it part of the identity of the company. We can't ship junk. Not that we choose not to. We can't. We want to be proud of our work. We want to give it to our friends and our family, the closest people in our lives. That focus on quality is imperative. And I think it's super hard to do as a product leader, because you just can't see it. And I love that tie back into making quality so core that it's not a variable that moves. It's just intrinsic to the group of people that you have. So yeah, there you go. I love Steve. I think this is like an unbelievable quote, something I try to think of a lot. Here's how I'm trying to put it into, into work. We'll see if it, we'll see if it happens. First thing is my job, and most product leaders' job, is to hold the line, right? Hold that quality bar really high, make it part of the identity of the company, do everything you possibly can to make people believe that that is the variable that does not move. And if you can do that, then you'll probably get good things. The second is to remember that if you want to save time, the best way is actually to prioritize big things. It's not to try to speed things out the door or to cut small edges off of stuff. It's to choose what you work on and what you don't work on. This is obvious advice. It is exceptionally hard to do. And so instead of spending your time figuring out why that feature can't go out on Friday, should be really asking yourself the bigger questions. Does that feature need to be built at all? And the last is, if you are going to optimize and you are going to try to save hours on the edges or days on the edges, nothing wrong with that. Just pick the things that are small and repeated. They actually give you back the most. You saw in the last slides, you know, I'm trying to think through how to cut down meeting cadence, for example. And that's just because it is a small optimization, but it should give back a lot. And I think if you are going to optimize, which you should, you know, these are the good places to start. So that's my take. That's what I've been up to. If you've been tracking, here's your TL;DR. Hopefully some portion of this ends up in ink on your arm. I think these are the things that I'm focused on. For the math-inclined of you, the left-hand side. For the people who like text, the right-hand side. I think it's important that you're closing the gap between reality and expectations. You can do that with a lot of great conversation. I think it's really important not to default back to authority. I'm trying my best to use influence. It is hard every single day. I think I'm trying as much as I can to remember that scaling is in fact urgent. It goes in the top quadrant. It's important that other people can build this team alongside me. And the last is that my job in that equation of scope and quality and time is to hold the line on quality as much as I possibly can. I hope this has been even slightly helpful for a few of you. Again, like I said, if any of this is useful, I'm happy to share some stuff after the talk, real templates, things that we've worked on. You might have noticed all of it's in Notion. No surprise, we run the company on Notion, but that also makes it easy to share. So happy to Happy to share things after the talk. You've been a wonderful crowd. I couldn't hear your booing. I imagine there's a standing ovation going on somewhere. Thank you. Thank you. Thank you. On to Q&A. All right. I'm trying to pull up the Q&A feature on Zoom. There are 11. I'm going to start with the first one, which is from an anonymous attendee. How important is it for a VP of Product or CPO to meet and talk with customers when they start? Is it a flag if they don't start off there? I like this question. I think that it's very, very important for you to build intuition. So oftentimes a question that's asked is, hey, do you believe in data to make decisions? Do you believe in research to make decisions? Do you believe in you know, using your intuition. And Nobel Prize-winning economist Daniel Kahneman says something that I love: you use information, you use data to inform your gut, and then you trust it. And I think conversations with customers are absolutely important. Where are you going to inform your gut? You can guess, you can look at data, but part of it is going to be having conversations. So is this the only thing that you have to do? No, I think you should look at, you know, the, the core metrics of your company. You should ask people how it works, should pick and choose a few customers, you should pick a few non-customers But I would just go as deep as you can, trying to inform your gut. Look, by the way, the people who know a lot are actually inside the organization. Don't, don't think that you have to do this all on your own. Go talk to whoever leads your CX team and who leads your sales teams. They'll tell you a ton. OK, second one, when you are in a competitive space like Notion, how do you balance filling feature gaps with new innovative features, especially when sales is clamoring for feature gaps to be filled? I don't know, you're going to tell me the answer to this question. I've been here for 75 days. I can tell you how we've done this in other places. It's that you just stay focused on the customer. You just stay really, really, really focused on the customer. There are times where a new feature, new innovation is going to go a long way. And there's times where just fixing the core of what you have is going to go a long way too. It's a balance. It's about being honest with yourself. It's about looking and making sure that the things that you build and ship are having that impact. Super, super important. Something that, you know, you have to balance as a leader. Don't convince yourself that it's just feature gap filling. Sometimes more people use your product if it's easier. Okay, how do you drive alignment between product and engineering as you scale? How do you make sure engineering sees product as an ally and not too much of a battle point? This, this is a great question. This is so fundamental to me. I like to say that like great teams have blurry lines. And, you know, I think this is sort of counter to a lot of the career advice I was given, like, hey, everyone should have roles and responsibilities, there should be swim lanes. And even going back to one thing that I said inside this talk, like, you know, you want there to be common goals and common motivations. And I think sometimes we draw lines too, too closely. And so how do you build these relationships? As you share accountability, you share outcomes. So what does that mean tactically? Like, I really don't like hand waving, if you can't tell. If there's an incident, you got a SEV, PMs should show up. It's their decisions that led to the team not being able to work on tech debt. When you're doing a design sprint— and I'm an offender of this this week— but if you're doing a design sprint and you want to think about the future, engineers should be invited. When you're doing research, there should be an engineer on the ground. Blur your lines purposely. Have designers write PRDs. It's OK for a product manager to make a mock inside of Figma. Celebrate when people cross the lines, because what that means is they have the same goal. They definitely have different skills, but if you keep putting these people together, what's going to happen is empathy is going to arise. Like, I think you hear this from other people, you should travel the world. When you travel the world, you have more empathy for other people and other cultures. You know, you become a more well-rounded person. Yeah, travel your organization too. Sit down next to people and figure out what their job looks like. And I think what you'll realize is like they're doing something hard. It becomes so much easier for you to be allies, and it won't become a battle because you'll see it from their point of view. I think this is so fundamental. Love this question. It's like a meatball. I wish, I wish every Q&A started with this. You caution against the Betty Crocker effect in this presentation. Can you elaborate on how you and your teams have been able to continuously improve further your product and what this looks like in practice? Yeah, so I think managers often forget that, you know, their job is just a different job. There was a slide in here that I cut that was really more basketball-focused. I tried not to go too deep into basketball, but it was like, you know, when you look at Phil Jackson, this amazing coach, and you look at Michael Jordan, this amazing player, and you compare their statistics as players, it's like night and day. Michael Jordan's clearly a better player, and Phil Jackson is clearly an inferior player, but it doesn't matter because Phil Jackson's job was to be the coach, and a coach's job is to set up the environment for success. And I think managers often forget this. Set up the environment. Dance your job. Move the piano. Let the piano players play. And I think we do this wrong for a lot of reasons. We promote people who are great individual contributors into management roles. We don't value people management as much as we probably should. There's a long list of reasons. But I think that is part of the reason why it's so hard for managers to let go of what they think of as management jobs, right? So I'll give you an example. At Robinhood, almost everything on site in the product team was designed by a PM. Very little of it was actually designed by me. I guess maybe the meetings were, but how we interviewed, what the interview questions were, what onboarding looked like, what social events we had, you know, how we pitched and closed candidates, even the role description of what is a product manager was written by an individual product manager at the company. There's nothing wrong with that. I just feel like managers think like so hard about like, hey, how do I act as this leader? And that's just not necessary. You'll continuously improve yourself if you can get to the place where other people feel like they can contribute. The second piece is very tactically. Um, I see this too often, like someone writes a doc and then they send it to their manager for approval. Why? Why? Send it to your peers. I have only one advantage, um, in my day-to-day job compared to the people on my team, which I have context. Right. I get to see a lot of different functions and a lot of things happening at the company. But the people on the teams, they have depth. They know the content better than I know it. They spend more of their time thinking about the problems. So when you start looking at folks who are going to like review work, look to your peers first. Every single PRD that we shipped at Robinhood, and we do it at Notion as well, goes into a channel that your peers are expected to comment into. And this is fantastic. It's great for people early career to see what rock star, you know, great performing ICs look like in design or in product. It opens up a culture that's built around merit and not built around hierarchy. And if I'm doing my job right, frankly, there's going to be a bunch of Michael Jordans on this team, and I'm going to be Phil Jackson. I hope I'm not even half as good as the PMs who are on my team. How do you cultivate an environment of strong peer accountability? I think I touched on this a lot. I think I'll try to put a little edge on the top of it. One is celebrate what you see. So I grew up as a second-generation immigrant. My parents are both from South India. The way that they like to parent is what I would consider negative reinforcement. I didn't know that this was a term. I just thought this is the way that people grew up. And it wasn't until maybe I was like 25, maybe 25, 26, I met my wife's family and I started hearing them say things like, you've done such a good job. And I thought to myself like, wow, how condescending. But then I realized that there's actually this other loop that exists for other people, where when you tell them something is good, they do more of it. So as a leader, trying to work this into my repertoire, it's not natural, but I do think it's valuable and important. So when you see good things, you know, you see a comment from one designer on another designer's work that's both respectful and kind, but also direct and difficult, celebrate that. Hey, great job. Call it out in public, call it out in private. You know, tell people that the thing is super good. The second is, you know, wait. Here's a really weird one. When someone presents something, just wait. Let other people give their thoughts first. It's not about going last. It's about building the muscle where peers are thought of as accountable. Another piece of advice I've been given in the past is just say the quiet parts out loud. You saw that in here. One of the quiet parts is telling people that you want peer accountability. Saying it out loud is helpful. So, you know, definitely, definitely a good— there's a good suite of ways. I'm sure many of you know better, better ways to do that. OK, I'm going to keep running. I am skipping questions that are about Notion specifically. I just want to say this out loud because I've been here for 75 days. I'm not a credible source on exactly what Notion did and it would be secondhand. So I am skipping questions that are specifically about the Notion product. Also sort of in line with the talk more about you being a product leader. OK, another anonymous attendee. How helpful is it for product leaders to be engineers or to have some engineering background? There are so many views here. Yeah, I agree, anonymous attendee. There are so many views here. Let me think a little bit about what I believe. I do believe it's easier for people who are engineers. I think that's controversial, but I think it's because so much of the job is working with engineers that, you know, you sort of have that empathy right off the bat from, from being an engineer. But actually, I think the product is not a real job. I mean that respectfully because I'm in that job. But I guess what I mean by that is all other functions have a craft. You know, designers have a craft. They go to school to learn to do wireframes and work and flows and visual and motion and animation and all these amazing things, graphics. You know, if you look at engineers, they write code. You look at data scientists, they run analysis and build models. These are all craft skills. And I think product's job is actually very different. It's horizontal. It's to bring experts together and then get the most out of that group. And so I think that background can be very different as long as you're kind of curious, you're good at keeping a team together, you're willing to do some grunt work, you know, you're great at communication. I don't think you have to be an engineer at all. And the best product manager, the one that I admired most— I shouldn't say best because you're always dealt a different set of cards— but the product manager I admired most was a woman who used to work in a factory. And her team loved, loved working with her. And one of the things she said to me that I still think about a lot is she's like, oh, you think this job is hard? Try getting people to punch a clock, come in, make shoes, and punch a clock and leave. These people are smart and they care. They want to work. This is the easiest job I've ever had. So I think about that a lot. Yeah. Is it easier to be an engineer? I think so. Maybe a little bit. You can learn it though. I think if anyone wants to pick up their learning on being technical and act as the glue for the team, they can probably do it. Um, okay. Johan asks, do you think that a technical team building the product should report to the CPO or a technical leader, CTO, for example? Follow-up: what if the CPO is coming from a technical background like yourself? Does that change your answer? All right, this is a fun question. Um, I'm not technical. I like— I guess not in the traditional sense. I've worked on machine learning, I've worked on I've written some code in my life. I have a stats degree, but I also went to law school. So, you know, I'm not, I'm not that technical. I don't believe in any organizational hierarchy rules. I think every company is different. I've been fortunate to work on hardware, and the way that you have to run a hardware company is very different than the way you have to run a software company. I'm here 75 days at Notion, and I'm learning that there's different ways that you can run a company that's B2B SaaS than compared to a consumer company. I think what's most important is that you realize that you're setting up an organization because that organization creates environments. I'm sort of a one-trick pony here. Managers' jobs are to set up environments. That's their job. And so I think if you can set up an environment of success by having your marketing team report to your data team, do it. If you can set up an environment of success because your data team reports to your marketing team, do it. This sounds insane, but I used to think that there were rules for this. I'm not confident that they are. Put great leaders in great positions, put great individual contributors in great positions, ask people, challenge them to learn, and don't make it so much about the reporting. I think it's easy for me to say in the role that I'm in now, but I never really worried about the reporting. I always tried to figure out how I could try to do my best in the situation that I had and what it would take to change that situation. That's sort of my advice. I love the question. Thanks for putting your name on it. Relatedly, one more question that's here. I'm going to try to wrap it in 5 minutes. I'm looking at Taylor, and she says we can keep going. For those of you who aren't C-level and maybe don't have the authority, how can we use some of these principles to affect change and prevent the issues you spoke to? Good question. I'm not sure there's anything specific about being C-level. I know that it makes people feel good. It certainly makes me feel good. But I'm not confident that that separates jobs. And the reason I say this is sort of my mental model of how great companies work is that they don't just kind of like grow into a bigger blob. Most of them sort of spin out little satellites and think of people inside some of those satellites as sort of leaders. And I don't like the term mini CEO because there's not a board and there's not the same accountability, but I think you can lead from any position. And I think this is true for PMs as well. I said there was this bad advice, which is come in and influence people. The reason it's bad advice isn't because it's not a good thing to do, it's because you don't have a choice. And I think especially early in your career as a designer or as a product manager or as a researcher, one of the things that you should be asking yourself is like, how much am I influencing change? How much am I influencing it directly on my team? But in truth, as your career expands, one of the truest ways to know that you're getting better is that you're able to influence outside of your team. You know, you're able to influence how other people are building. That has nothing to do with being C-level or not. You know, one thing I didn't touch on in, in this talk that I think is sort of important as you join a company is that there's like also an unofficial org chart everywhere. You know, there's a set of people internally inside the company who are just revered for their attitude, their culture, their contributions. And those people are really, really important to go and find, and very few of them have a C-level title. They're just very influential. Because of who they are and what they've done. It did hit the cutting room floor so we could get to some Q&A, but I think that that's maybe the best example. You can think back to maybe your own career, where there are people who you went to for advice, or you knew others went to for advice that had nothing to do with the chart. And I think you should aspire to be those people. I don't use names often, but I'll use this name because I just respect this person so much. I haven't worked with him for a long time, and this talk makes me think about it. But early in my time at Twitter, there was this one person who led data, uh, Kaley Torgerson. And I used to joke that Kaley was the chief common sense officer. He didn't have any title, but you always knew that good decisions were being made when people went and dropped by Kaley. Like, it was just bizarre. I couldn't explain it why. Like, it had nothing to do with data. It would have to do with org. It would have to do with, are we making a good strategy decision? That was the type of leader that I hope I can become. And that's the type of leader you should try to aim to be. Regardless, C-level, group lead, IC, I think nothing stops you from being that person. It's a little bit harder, in truth, when you've got a plateful of work to do, but it's definitely possible and something to aspire to. Okay, I've hit the end of the questions. I've bored all of you deeply. The standing ovation has probably tired your legs. It is 8:57 AM here on the West Coast, and so I've got a full day ahead of me. For those of you who have less of a day, ahead of you. Thank you for spending so much of your valuable time with me. It is an honor for me to get to speak to this group. I really do enjoy it. If you've got feedback, please send it to the folks at SaaStr. They are fantastic and helped put this together, and we owe them a ton. And if there's anything else I can do, you know, find, find, uh, find the ways to get to me. I'm happy to share a lot of this stuff. So thank you for your time, appreciate it. Jason M. Lemkin noted something really funny: come back at day 365 and tell us what I got right and wrong. Absolutely, I'd love to. Thank you, thank you, thank you so much.