#75 – What is Product and what does a Product Manager do? (Sam Corcos & Lenny Rachitsky)

What exactly does a product manager do? People at different companies might give you different answers. Levels CEO and co-founder Sam Corcos set out to get some clarity on the subject. In this episode, he sat down with Lenny Rachitsky, one of Level’s investors and an early team member at Airbnb. Lenny has since gone on to build a community centered on product growth. Sam and Lenny deconstructed the idea of a PM and what the typical role looks like at any startup or tech company.

05:34 – Tasks of a product manager

A product manager’s task can be broken down into three things: shape the product, ship the product, and sync the people with all of that in order to drive business impact.

So unpacking those a little bit, shaping the product basically means somebody has to do this thing, somebody has to take insights from customers’, stakeholders’ data and use that to identify and prioritize and build the things that you need to build to make your product successful. Somebody needs to do that. Shipping the product, somebody needs to make sure that people are hitting deadlines. Everyone’s got a sense of when things should ship, when customers should expect things and that the things are coming out, they’re awesome. And then there’s another third bucket is synchronize the people which is just make sure everyone in the company, or if they’re just focused on a team, everyone on the team is aligned on a vision, a strategy, a goal, roadmap, priorities, all these things, so that you’re not wasting a lot of time. And then all of that to make sure that the team is always working on the highest ROI stuff that will drive the most impact. So those are the three buckets. Somebody has to do these things. Sometimes designers can do them, sometimes engineers, but that’s basically what a PM does, those three.

09:45 – Develop a product sense

Some skills are things that develop over time. Product managers often develop a product sense for what decisions need to be made and when.

So what are the skillsets of PMs outside of the project management component which is just coordinating and timelines and things like that? It’s kind of a vague art more than science kind of thing, but there’s this bucket of skill called product sense which one way to describe it is just like you’re more often right about product changes and how the impact they’ll make whether something’s going to work out or not. So there’s a sense that you build over time, the more you build product, that product managers that are great end up being really good at. Then there’s just skill of working with product functions, I’d say, just experience working with engineers and knowing what’s important to them and knowing how to communicate and motivate engineers and then same with designers. So that’s a unique product management skill.

12:24 – Refocus priorities and get soft and fuzzy

PMs need to keep their team focused on the right priorities, but that requires soft skills like knowing how to motivate and set clear expectations.

Basically, what you’re doing is you’re teaching someone to be a product manager that’s like a new product manager without calling them PM. They will struggle absolutely and the things they’ll struggle with mostly is something you need the PM to be really good at is just continuing to refocus the team on what is the highest impact work, we can be doing, ruthlessly prioritizing and bringing people back to the problem they’re solving over and over and over and over, so that designers are pushing the right direction. So that you’re focusing on metrics you’re trying to move versus just making beautiful product that feels good. So those are things that PMs are really good at, and over time, you learn to get good at that and how important that is. Somebody that hasn’t had experience in that and is put in that role is going to forget about those things and drop those things. I don’t know, I’m just jumping to all the things that are probably happening that you’re trying to fix. Another is just keeping people on time and motivated without pushing them too hard and causing morale issues and also setting clear expectations. It’s always like a soft and fuzzy, warm things that PMs learn over time.

17:07 – A great PM makes life easier

Designers and PMs can split up duties, but a great PM will take the work off everyone’s plate to make their jobs easier.

So depending on the kind of designer you have your company, you can sometimes just somehow divvy up responsibility where product is responsible for defining the problem and making sure everyone agrees. You can make it 80/20 and then 80/20 in the other way. So 80% PM responsible for defining the problem and aligning everyone behind a strategy and then the designer 80% is responsible for coming up with a solution and then 20% everyone else contributes and has their say. That’s a simple way of approaching it. In my experience, great PMs, everybody loves them on the team because they just make everybody’s life easier and they take work off your plate that you don’t want to do. So designer that is very product strategic vision thinking person. If they’re working with a bad PM, they’re going to have a really bad time. They’re like, “Get out of my way. I know what we need to do.” But if they’re awesome PM, the PM will give them space to think about the solution, ideate, give them all the information they need, make sure engineers are building the things they wanted them to build those kinds of things.

21:37 – Pave the road for the team

It seems like a lot of admin tasks, but those tasks are actually guiding the team or company and paving the road for them.

There’s a lot of that like taking notes, scheduling meetings, road mapping. So there’s a deceiving piece to that and that the thing that everyone works on, you’re in control of what the team is doing by managing the roadmap. It’s you’re paving the road, everyone’s going down. So a lot of times, it may feel very trivial, but basically, they’re guiding the entire team and possibly the entire company doing these very seemingly simple things. So there’s like a deceiving power to that. Also a lot of the job is those things. The things you probably aren’t seeing is thinking about strategy and starting to defining craft, the strategy which again is like the thing that determines what everyone’s going to be working on and it may seem like admin-ey, but it’s like the stuff you’re doing and determine what everyone’s going to be doing.

30:41 – Get up to speed through repetition and a good mentor

Lenny was dropped into a PM role and had to learn through doing the job over and over. He now has a PM course for people who are transitioning into the role.

I’d say it was a combination of just doing it for over and over and over and over and seeing what works and what doesn’t and there’s no way to avoid that. And then two, I actually had a really good mentor who taught me a lot about the role. He’s my manager for three years and that was the fastest ramp in my career. And I got promoted a bunch and all these good things happened on that one person. So I think, generally, those two things are how you get better quickly and then have this PM course that you know about. The goal of the course is to give people that in three weeks, but I didn’t have that early on.

34:35 – Gradually bring in engineers

Engineers don’t need to be in every meeting from the beginning. Start looping them in early, but in a gradual way.

The way I think about it is give people a chance to contribute at every stage of the process, but not make them come to all these meetings that you’re having about everything. So there’s like these big milestones. You have just a rough idea, then you have a spec. I call it one pager just like an overview what the project is going to be and then there’s designs. So what I usually do is just like, “Hey, engineers, here’s the roadmap for, the whatever, this quarter. Let me know if you disagree with anything here prioritization-wise. It’s just like simplifying it.” Then when you have a one-pager or PRD of a project, just send it to the person that’s probably going to be working on it and give them a chance to review it and then talk about it in person if you want to. And then as design starts, just keep them up to date. And then once design is over, then you get more serious and meet and talk through everything. So continue keeping in the loop and giving them a chance to participate, but not like, “Hey, I need you in this meeting we’re having about this project from the beginning.”

38:43 – Keep your eye on the problem

During the designing and scoping phase, a PM should always be checking in to make sure the problem the product is solving is staying top of mind.

So high level, the most important thing is that you’re solving the problem that you set out to solve which sounds obvious, but it’s oftentimes what goes wrong at that point. And so just like a pro tip there is any time a designer is sharing designs, always start with, “Here’s the problem we’re solving.” Just remind them, “Here’s the problem we’re solving.” That’s the most important thing. The other is, I guess, just off the top of my head, making sure it’s within the scope of what you’re trying to do. There’s like a million things you can build in. “Is this the size of project that you’re hoping you’d be? Are you making the tradeoffs you should be making?” I guess if you’re asking the most important things, those seem to be the most important things.

40:54 – Act as moderator

Designers need to think big and engineers need to focus on execution, so it’s PMs who need to come in and find ways to simplify things and moderate the scope.

So this is stuff that PMs help with, is they stay on top of that kind of stuff and make sure the engineer takes the time to review all the stuff, often sees the things that are going to take a month versus a day. So these are the kinds of skills that you need for that person to have that’s in between. Because designers, you really want them to think big and think creatively and push the envelope and that kind of thing. You need somebody that’s not necessarily the engineer that’s always going to be, “How do we make this less complicated?” to be this middle moderator. So those are the kinds of things that DRI/PM should do for you. But it still happens. Things still fall through the cracks. Until you start building, you never really know what’s going on.

Lenny Rachitsky (00:06):

Great PMs, everybody loves them on the team because they just make everybody’s life easier and they take work off your plate that you don’t want to do, so a designer that is very product strategic vision thinking person. If they’re working with a bad PM, they’re going to have a really bad time because like, “Get out of my way. I know what we need to do.” But if they’re awesome PM, the PM will give them space to think about the solution, ideate, give them all the information they need, make sure engineers are building things they wanted them to build those kinds of things. So that’s a rough way to think about it. And basically, if you’re designers have frustrated you, you don’t have a great PM.

Ben Grynol (00:45):

I’m Ben Grynol, part of the early startup team here at Levels. We’re building tech that helps people to understand their metabolic health and this is your front row seat to everything we do. This is a whole new level. Almost every startup will have product as one of their core components that is a tech company that focuses on product. Levels is a product, the app we refer to as product. And this is synonymous with every startup that is tech focus. Their product is some piece of software that they’re building. If you’re outside of the tech world, a product is usually something that you can hold, it’s tangible. A product is a car. A product is a walking stick. A product is a running shoe.

Ben Grynol (01:40):

Well, the same goes with technology. The product, it just happens to be digital. And so how do you actually go about building that? Well, Sam Corcos, cofounder and CEO of levels, he sat down with Lenny Rachitsky, one of our investors and an early team member at Airbnb. Well, Lenny since left then, he’s now built a community around this idea of product and growth. He has a very engaged Slack community, a weekly newsletter, not surprisingly called Lenny’s Newsletter, and the community is made up of different people who have a lens on product growth community. And so Sam sat down with Lenny and deconstructed this idea of a PM, a product manager. It is a typical role at any startup or tech company.

Ben Grynol (02:21):

What exactly does a PM do? If you ask people across different companies, well, they all might have different answers because the implications of product at one company might be more design driven and at another might be more technical, more data driven in the way that they build that product out. So Sam and Lenny rift on this idea of product, “What does it mean? How can we think about it at Levels? And what are some of the implications of having PMs across a company? Can you build them from the ground up? It’s a great conversation and here’s where they kick things off.

Sam Corcos (03:01):

The main reason why I wanted to chat with you is something, I’ve come to the sudden and concerning recognition that I don’t know what product means. I thought I knew what it means, and the deeper I dig into what product as a function is and is responsible for, the less clear it is to me. So I guess I’ll open with just asking you what products means and then I can go into some of my more specific questions.

Lenny Rachitsky (03:32):

So when you say product, are you thinking like the role of product management or are you thinking broader like a product team or just getting good at product?

Sam Corcos (03:40):

I think I would say product management is probably what I would start with. The specifics of where I’m confused is I ask people what a product manager does when they describe it, they describe certain functions and then I say, “Oh, okay, so then you’re responsible for this?” And they say, “Well, no, that’s actually a product designer.” “Okay, so then what you’d actually do is this,” like, “Well, no, that’s more of a project manager.” And up in that, it’s that scene from Office Space of like, “So what is it that you do here exactly?”

Lenny Rachitsky (04:15):

“I’m a people person,” which is not so far from it. Got it. Cool. So one of my favorite interview questions for product managers is, “What is product management?” and something you learned is everyone has a different definition. So let me share how I think about it and that’s something a lot of companies ask and we could talk about actually Airbnb’s experience on this because they had questions around this too. So the first thing I’ll say is there’s nothing like specifically unique about a product manager and the things they know and the things they do that nobody else can do. A lot of the value product manager brings is they have time to do the things that somebody has to do and they’ve done these things for a long time, so they’re really good at it.

Lenny Rachitsky (04:54):

So there’s these sets of activities that somebody has to do. A lot of times these activities gets spread across design and engineering and the CEO and other functions. And a lot of times, companies don’t need a PM for a long time because those folks are doing those things and it’s going great. So you don’t always need a product manager and there’s nothing like magical about the things that PM do, but they have time to do these things that have to be done. So what are the things that have to be done? A really simple way that I’ve thought about it that is memorable is these three jobs to a product manager. Their job is to shape the product, ship the product and sync the people and all of that in order to drive business impact.

Lenny Rachitsky (05:34):

So unpacking those a little bit, shaping the product basically means somebody has to do his thing, somebody has to take insights from customers, stakeholders data and use that to identify and prioritize and build the things that you need to build to make your product successful. Somebody needs to do that. Shipping the product, somebody needs to make sure that people are hitting deadlines. Everyone’s got a sense of when things should ship, when customers should expect things and that the things are coming out, they’re awesome. And then there’s another third bucket is synchronize the people which is just make sure everyone in the company, or if they’re just focused on a team, everyone on the team is aligned on a vision, a strategy, a goal, roadmap, priorities, all these things, so that you’re not wasting a lot of time. And then all of that to make sure that the team is always working on the highest ROI stuff that will drive the most impact.

Lenny Rachitsky (06:26):

So those are the three buckets. Somebody has to do these things. Sometimes designers can do them, sometimes engineers, but that’s basically what a PM does, those three.

Sam Corcos (06:34):

One of the functions that we have, not really sure this is a function as much as it is a designation, it’s a concept of a directly responsible individual. They are the person responsible for delivering an outcome for a project. And I’d say roughly out of the conversations I have with PMs, it just is that same definition. Is that accurate or essentially accurate?

Lenny Rachitsky (07:01):

So at Airbnb, we had DRIs, we had GMs and then we had PMs. And oftentimes, PMs are just really good. DRIs, they’re just naturally the DRI of the team, but it doesn’t have to be. At Airbnb, we had designers that were also often responsible for an initiative. Airbnb, we moved to DRI and GM meaning the same thing eventually because the idea of a GM is basically they manage every function within an org. So they manage the product manager, the designer, engineer, things like that. So I guess the simple answer to your question, they’re not the same thing and we can talk about why, but a PM is most often a natural DRI because there’s a metaphor like these PMs are like the captain of the team.

Lenny Rachitsky (07:40):

So if you think about like basketball teams and soccer teams, there’s like a team captain. They’re all the same. They’re all players on the team, but one player has this unique designation that the teams have decided they’re the captain and we’re going to look to them to guide us a little bit and so PM is kind of that on the team. We’re a natural leader and the de facto leader, and oftentimes, DRIs lead to that, but a DRI is just they’re on the hook for making this thing happen. It doesn’t mean they’re great at all of these things that a PM should be doing.

Sam Corcos (08:11):

Can you elaborate a little bit on why? It sounds like you had three definitions which collapse down into two. Why don’t they just collapse down into one? What’s the designation there?

Lenny Rachitsky (08:24):

Between DRI and product manager? So one simple difference is sometimes not everything is product. And so if you have an ops program or something like that, you don’t need a product manager responsible for that. Sometimes you could just have a head of ops that’s the DRI for something. So it’s just like a really simple difference. By definition, DRI, like all you’re saying is they’re responsible for this whole thing. It doesn’t mean they’re going to be good at building product. That’s a simple way to think about the difference there. And that’s also not a function, right? You’re not going to hire, “We’re hiring DRIs,” so usually you pick one of the existing skillsets and functions to be a DRI. And I guess what I’m saying is PMs are just like really good at often because they’re naturally a DRI for a team.

Sam Corcos (09:07):

So let’s take the distinction between a DRI and a PM. This is just something that we’ve been trying to suss out internally is what are the things that distinguish the two other than saying some sort of what feels like an ambiguous understanding of like, “And their DRI but they’re also good at product,” is somewhat circular in that regard? Is that they’re good at product design? Is that they’re good at making business tradeoffs? Is that they have intuition around complexity and resourcing? What does it entail?

Lenny Rachitsky (09:45):

Like the products component of product management/DRI? Got it. So what are the skillsets of PMs outside of the project management component which is just coordinating and timelines and things like that? It’s kind of a vague art more than science kind of thing, but there’s this bucket of skill called product sense which one way to describe it is just like you’re more often right about product changes and how the impact they’ll make whether something’s going to work out or not. So there’s a sense that you build over time, the more you build product, that product managers that are great end up being really good at.

Lenny Rachitsky (10:18):

Then there’s just skill of working with product functions, I’d say, just experience working with engineers and knowing what’s important to them and knowing how to communicate and motivate engineers and then same with designers. So that’s a unique product management skill. I’m trying to think of the slice of skills that are outside of the stuff you’re talking about. Those really are the two big ones.

Sam Corcos (10:37):

Let me take that second one. It feels relevant to anyone in a leadership role. It’s motivate and coordinate people. If you’re running the support team, you have to be able to do that, right?

Lenny Rachitsky (10:48):

Just maybe zooming out, is the question you’re trying to get to is like, “Do you need product managers, and in that world of not needing product managers, can you make a head of design or engineer, the DRI?” Is that what you’re trying to do?

Sam Corcos (11:01):

We’ve run some experiments. As you would expect, we’re trying to experiment with org design and figure out what the best way of operating when you have an unusual culture we have of fully remote and asynchronous. And so we tried things like putting somebody with no product experience at all as the DRI for a product initiative, just see what happens. There are … Following along on some of these projects, we’ve done this several times now, there are clearly gaps in the functioning of that project, but they feel so ambiguous, and when we try to drill down into it, when we find one specific thing, it always feels like that thing can just very easily be taught. It’s like, “Oh, they just need to know how to translate designs into tickets. That’s not that hard. They should just do that.”

Sam Corcos (11:57):

And a lot of the PMs that I talked to are like, “No, no, no product, they can’t be taught. It’s like a magical thing that requires [crosstalk 00:12:07] a lot of them.” They-

Lenny Rachitsky (12:10):

[inaudible 00:12:10].

Sam Corcos (12:10):

Yeah. When we get down into the specifics of what the gaps are, they all seem very achievable and surmountable by people with just better training.

Lenny Rachitsky (12:22):

Right.

Sam Corcos (12:23):

That’s where I’m struggling.

Lenny Rachitsky (12:24):

I see. Basically, what you’re doing is you’re teaching someone to be a product manager that’s like a new product manager without calling them PM. They will struggle absolutely and the things they’ll struggle with mostly is something you need the PM to be really good at is just continuing to refocus the team on what is the highest impact work, we can be doing, ruthlessly prioritizing and bringing people back to the problem they’re solving over and over and over and over, so that designers are pushing the right direction. So that you’re focusing on metrics you’re trying to move versus just making beautiful product that feels good. So those are things that PMs are really good at, and over time, you learn to get good at that and how important that is.

Lenny Rachitsky (13:00):

Somebody that hasn’t had experience in that and is put in that role is going to forget about those things and drop those things. I don’t know, I’m just jumping to all the things that are probably happening that you’re trying to fix. Another is just keeping people on time and motivated without pushing them too hard and causing morale issues and also setting clear expectations. It’s always like a soft and fuzzy, warm things that PMs learn over time. I totally agree anyone can learn these things, not everyone but most people and the benefit of having a PM is they’ve done these things again and again and you don’t have to teach them.

Lenny Rachitsky (13:35):

But yeah, I don’t think there’s anything magical really unless you want to be like a Steve Jobs and visionary product thinker. You don’t need that for most PMs.

Sam Corcos (13:43):

One of the things that does seem maybe the hardest to teach is the idea of product intuition which is understanding how to make tradeoffs and how to change scope the things. I’ve been in the software world for long enough to know when somebody proposes something, they’re like, “Hey, we want to do this. It’s going to be six weeks.” I can look at that and say, “Why don’t you just do it this way and it will take three hours?” And I’ve done this enough times to know how to make those tradeoffs. I could see that as something that’s hard to teach only because it comes from years of experience and scar tissue from mistakes made in the past, but it seems like for most things when there’s a reasonably well-defined project, I guess I would ask how much of what you think of as the work of a PM is primarily project management and coordination?

Lenny Rachitsky (14:41):

The more junior they are, the more of their job is just execute, ship on time, keep people aligned and it’s less big vision strategy, incredible insights into product direction, but the more senior you get, the more you manage other teams and other PMs. More and more your time goes into that. So imagine that the need that you have, that’s not going to be a big in big part because you’re there and your team is there and you don’t want, as a founder, to feel like you’re just this new random PM that joined, is just telling you what to build. It rarely works out that way and it’s not good for the company. And it’s often actually why a lot of PMs at early stage startup struggle because they’re just stuck between the founder having a clear, a strong opinion and the team just that has to build it.

Lenny Rachitsky (15:25):

So they don’t need a ton of that, in my opinion early on, unless the founders are not that product focused, but clearly you guys are. So going back to your original question, I think a lot of it is project management and just coordinating and aligning. That’s a psyche job for a lot of people and so it’s a tricky role to be like a new PM at a small company. So you have to set those expectations and then start to build trust so that they can take on more and more of that.

Sam Corcos (15:49):

So I wonder in the context of a product org, relative say in engineering org, I assume you would put designers and PMs within the product org. Is that right?

Lenny Rachitsky (16:05):

It depends. You could do it in all kinds of ways. You have designers that have a head of design report up to you and head of product and head of engineering. There’s three functions. Other times, design rolls up to that product. It works in many ways. I don’t know if there’s a right way to do it. I think it probably depends on how important design is to your experience and whether it this should be a high top level function or not.

Sam Corcos (16:27):

And when you think of design, what does that mean to you in relation to product?

Lenny Rachitsky (16:32):

There’s a lot of overlap. At Airbnb, actually, at the beginning, Ryan was actually in a similar place you’re in, didn’t understand why you need product managers because he went through design school. And what they teach you in design school is your job is to solve problems, identify opportunities, solve problems, ship the thing, “That’s what we’re doing, why do we need product managers?” And it took a while for him to see the value, but eventually they came around and there’s like hundreds of product managers now at Airbnb. So the core Venn diagram overlap is designers are trained to solve problems and figure out creative solutions.

Lenny Rachitsky (17:07):

So depending on the kind of designer you have your company, you can sometimes just sort someone divvy up responsibility where product is responsible for defining the problem and making sure everyone agrees. You can make it 80/20 and then 80/20 in the other way. So 80% PM responsible for defining the problem and aligning everyone behind a strategy and then the designer 80% is responsible for coming up with a solution and then 20% everyone else contributes and has their say. That’s a simple way of approaching it. My experience, great PMs. Everybody loves them on the team because they just make everybody’s life easier and they take work off your plate that you don’t want to do.

Lenny Rachitsky (17:47):

So designer that is very product strategic vision thinking person. If they’re working with a bad PM, they’re going to have a really bad time. They’re like, “Get out of my way. I know what we need to do.” But if they’re awesome PM, the PM will give them space to think about the solution, ideate, give them all the information they need, make sure engineers are building the things they wanted them to build those kinds of things. So that’s a rough way to think about it, and basically, if your designers are frustrated, you don’t have a great PM.

Sam Corcos (18:14):

It’s interesting because part of the function of a DRI is to make sure people are sufficiently resourced to get their jobs done and reduce friction and make it really easy for people to do work. So you’re picking up slack, you’re making sure everyone’s on the same page, working on things. It’s interesting, my experience as an engineer, this is my first non-engineering role and it has certainly been my experience that many of the projects that I’ve worked on a lot of other engineers that I know that have an aversion, maybe some scar tissue from product. I feel this ominous cloud of like process and JIRA arbitrary documentation and ticket grooming and all these words that just trigger me, a very negative way.

Lenny Rachitsky (19:01):

I get that. A lot of people have that trauma from product managers. And actually, Joe at Airbnb, the other cofounder, actually for a long time, he was very resistant to process and avoided any kind of product development process. And I think it really hurt the company early on because there was just like a lot of random shit happening and a lot of disorganization. So the question is not, “Should there be process?” It’s just, “What is the process that you’re happy with that doesn’t trigger you?”

Sam Corcos (19:28):

I would love to know if you have any insight into what was it that changed Ryan’s mind going from no PMs to hundreds of PMs.

Lenny Rachitsky (19:36):

I was adjacent to that happening, so I wasn’t in the meetings, but I think it was basically one thing the impact that the specific PMs that we hired to had on the team, they led really important projects and led them super well, communicated really well to Ryan, kept everyone on track, made it clear it was happening and thought things out. They showed through impact, “Look at this person has done and imagine them not be here.” I think that was the core of it. Two is think, I don’t know who you’re making these DRIs. It sounds like there’s just a junior person who’s just doing the DRI job. If you’re doing like-

Sam Corcos (20:12):

Some of them are quite senior. Depends on the product.

Lenny Rachitsky (20:15):

Do they have another job too? Is it a designer also DRI or is it just DRI?

Sam Corcos (20:19):

Occasionally, the engineer responsible for it is the DRI, somebody that I guess you would put is like a GM person.

Lenny Rachitsky (20:27):

Got it.

Sam Corcos (20:27):

The head of some functional area, it’s their main project.

Lenny Rachitsky (20:31):

Got it. In some sense, maybe they are just a PM with a different title. In another sense, another thing that triggers you to hire product managers is side things become a full-time job of just staying on top of everything. Give us an engineer, for example, and they just start to hate life because they’re in meetings all day, coordinating, checking in on timelines, reviewing the roadmap. I imagine that’s part of why Brian realized like, “Okay, these designers in theory could do this, but they won’t have any time for designing. They’re going to be meetings all day.” So I think that was probably part of it, but I think the core of it is just showing the impact that awesome PMs can have. And again, a great PM makes everybody better. They’re like a lever to help the rest of the team perform if you have a good one, so that’s how it should work.

Sam Corcos (21:15):

Because I wonder with a lot of these things, because I’ve always perceived product managers to be a pretty senior and important role. And oftentimes, when I look at what PMs do, they seem like they’re basically admins. A lot of what the time is spent on is admin work. This is not meant in a derogatory way.

Lenny Rachitsky (21:37):

Yeah, there’s a lot of that like taking notes, scheduling meetings, road mapping. So there’s a deceiving piece to that and that the thing that everyone works on, you’re in control of what the team is doing by managing the roadmap. It’s you’re paving the road, everyone’s going down. So a lot of times, it may feel very trivial, but basically, they’re guiding the entire team and possibly the entire company doing these very seemingly simple things. So there’s like a deceiving power to that. Also a lot of the job is those things. The things you probably aren’t seeing is thinking about strategy and starting to defining craft, the strategy which again is like the thing that determines what everyone’s going to be working on and it may seem like admin-ey, but it’s like the stuff you’re doing and determine what everyone’s going to be doing.

Sam Corcos (22:23):

Where I’m going with that is it seems weird to me, I think that people should be working on the thing that is the highest and best use of their time. And so if you’re an amazing product designer and you’re spending half your time taking notes and being like team therapists …

Lenny Rachitsky (22:41):

Right.

Sam Corcos (22:42):

… that’s probably not the best use of your time.

Lenny Rachitsky (22:44):

Right.

Sam Corcos (22:45):

So this comes down to the original question of, “So what does a PM do?” “Well, we do these things.” “Okay, so you do these things,” like, “Well, actually, that’s the project manager or the technical program manager.” Each of these things seems to be carved out for a different person. I’m just trying to understand the Venn diagram there.

Lenny Rachitsky (23:04):

So those two functions, you don’t need until you’re like a big company like Microsoft or whatever. Project management is within the role of a product manager. So you definitely don’t need both for a long time. And then these other things, you definitely don’t need for a long time. So the PM role contains a bunch of stuff. It’s like this, I don’t know another way people describe it, you’re the glue that gets everything working and so there’s a lot to it, but it does fold in a lot of stuff that other people don’t really like to do. It is a weird role. That’s why everyone has a different definition. Also different companies expect different things from the role, so that adds to the confusion, but yeah.

Lenny Rachitsky (23:41):

A lot of companies didn’t hire … I think about Stripe they didn’t have a PM until they had 200 employees and Snapchat didn’t have a PM until they had 200 employees. So it’s definitely doable. I think you have to be in a specific place like with Stripe is. They’re an API company, so you don’t need as much brainpower on the user-facing product. And then Snap, from what I hear wasn’t run very well. It’s like a shit show to work there. And so looking at that stat, it’s not like, “Here’s what you should do,” because they didn’t know it’s the right move. And then their designers are [inaudible 00:24:13] product managers, so it is doable. But I think the thing to think about is just, “There are these things to do. Who’s the best person to do this thing?” It could be one of these DRIs that you’re picking, but it could just be an awesome PM that you hired that has done this a long time.

Sam Corcos (24:24):

One of the experiments that we’re running, we’re probably going to run a few more of these, we have several people on our team with deep product experience. The analogy that I would give is when you do pair programming, you always have the person who’s being paired with as the driver on the keyboard, instead of just having senior person doing the typing and then maybe occasionally out loud saying something. You need the person who is being paired with to be the driver, so that necessarily all of the necessary information gets transmitted to that person to do it effectively.

Sam Corcos (25:03):

We’re trying experiment now of not allowing anyone on the product team to be responsible for any product related things. Just to try to surface, they’re more like an advisor on the product things. They’re giving inputs. They’re helping people come to the right decisions, but my hope is that I can understand a little bit better, “What are the things that product solves for that isn’t that missing Venn diagram overlap that I don’t currently see?”

Lenny Rachitsky (25:35):

And then what do you do with that once you have that?

Sam Corcos (25:37):

My hope is that we’ll end up with a list of something like 15 core competencies and we can find ways of, I don’t know if it’s like an internal training course or something to be able to level people up. Maybe one of my assumptions is that we’re a consumer software product and I think that it is important for people on our team to have some baseline product knowledge. And the difference between zero product knowledge and table stakes is night and day in terms of how you think about approaching problems. So my hope is that we’ll be in a position where we have a more, I don’t know if generalizable is the right word, but maybe a more generalist skillset on the team that understands the core problems that we seek to solve and potentially focus more effort.

Sam Corcos (26:33):

This is what I meant by it feels weird to me that PMs which are very capable, generally quite senior people are spending so much of their time doing what feels like admin work.

Lenny Rachitsky (26:45):

But it’s because that’s the stuff that most contributes to the team’s success, unblocking engineers, making sure everyone’s clear on exactly what’s happening. It looks trivial, but that’s the stuff that you need somebody to be on top of that causes these problems like people being misaligned spending time on the wrong thing, but I get what you’re saying. There’s a lot of menial work, and ideally, you can have less than your people doing that kind of stuff. What I find is that you need all that context to do the bigger stuff, pick, prioritize, make sure no one’s forgetting something. There’s not like a loose thread that hasn’t been closed, those kinds of things, but I like your first principles thinking here. I feel like there’s a trauma of having that product manager.

Sam Corcos (27:30):

Probably.

Lenny Rachitsky (27:32):

I fear you’re going to go around this and then come back to, “Oh, we should just hire an awesome product manager that I love.” It’s cool to experiment with other approaches. I respect that.

Sam Corcos (27:41):

That’s probably true. That is what has happened on a lot of the hires that we made, but when it happens, we at least know why we’re hiring that person and what we’re hiring for.

Lenny Rachitsky (27:51):

It makes sense.

Sam Corcos (27:53):

Because probably we hired an inside counsel much earlier than I think an average startup does. I think he was, I remember, 25 to 30, somewhere in that range. And I thought it for a long time. Outside counsel is a very normal thing and you don’t need someone on your team to do that. I just started keeping a list of all of the things that we needed someone to do, and at a certain point, we definitely need an inside counsel. This is ridiculous that we have all of these things and these external firms are charging us so much money, and no matter how many times we explain to them what it is we do as a company, they never figure it out. It’s like we start from ground zero on every conversation.

Sam Corcos (28:36):

So we should have done it 12 months earlier than we did, but if we had hired that person without really understanding the pain that we felt, I think it would not have gone nearly as well as it did.

Lenny Rachitsky (28:47):

I love that approach. I think with product it’s going to be less clear cut because there’s just little things aren’t going as well and a good PM or somebody avoids those things that are happening. Your job is to build this well-oiled machine that executes well and it doesn’t execute on these little small ways. So it’s going to be a little trickier thing to make a list of like, “Here’s the jobs,” other than ship awesome stuff that drives your business and make sure everyone’s happy, but that’s how it all boils down, but I’m excited to see this list that you come up.

Sam Corcos (29:18):

Some people keep telling me … I had another conversation with a PM this morning to try to understand it a little bit better. What is interesting is that his company was acquired and he had no product experience and they were like, “You’re a PM now.”

Lenny Rachitsky (29:31):

That’s exactly the path I went through.

Sam Corcos (29:32):

He’s like, “But I don’t know what a PM means. I don’t know anything about product.” They’re like, “Great. You’re a PM,” and he just figured it out as he went.

Lenny Rachitsky (29:42):

That’s exactly what happens and then you learn and you spend like five years getting pretty good at it. Like I said, there’s nothing like magical about product. It’s just people that have done it for a while have learned things that seem to work and then they have time. Engineers don’t have time to think about strategy, vision, research and all these things, so that’s a big part of it. Again, there’s nothing magical about it, but somebody needs to do these things, whether [inaudible 00:30:06] or someone else.

Sam Corcos (30:08):

I guess to that point, why it feels strange to me is when I talk to PMs about it, most of the time they started out as a PM with no product experience and also they believe that it’s unteachable, that there’s lots of intangibles. These things seem at odds to me. So when you were thrust into the role of being a PM, what were the things that helped you learn how to be a good PM along the way? Was it having a mentor? Was it just reducing the scope of what it is that you did? How did you manage that?

Lenny Rachitsky (30:41):

I’d say it was a combination of just doing it for over and over and over and over and seeing what works and what doesn’t and there’s no way to avoid that. And then two, I actually had a really good mentor who taught me a lot about the role. He’s my manager for three years and that was the fastest ramp in my career. And I got promoted a bunch and all these good things happened on that one person. So I think, generally, those two things are how you get better quickly and then have this PM course that you know about. The goal of the course is to give people that in three weeks, but I didn’t have that early on.

Sam Corcos (31:14):

We need a version of that. So we need you to do a content at some point.

Lenny Rachitsky (31:21):

We’ll see. Let’s see where-

Sam Corcos (31:24):

For sure. So we’ll take an example that we have upcoming very soon. We have a project, we’re looking for who we want to be responsible for it. Let’s assume that we’re going to pick somebody with limited product experience. What would be the first thing that we should do with that person and makes it so they’re successful?

Lenny Rachitsky (31:44):

To help them succeed. And again you’re picking someone with limited product experience in order to learn what problems they have. Trial by fire, got it, so how to help them succeed. Oh, man, there’s books they should probably read that will give-

Sam Corcos (32:02):

Which ones? I’m going to write it down.

Lenny Rachitsky (32:04):

Oh, man, on the spot. Because what’s interesting is you’re looking less for like the career of the PM, more like the practical sales of PM. So let me send you an actual … I’ll give you a few right now, but I’ll send you a list that’s more thought through. Continuous Discovery Habits by Teresa Torres would be really good. It’s all about how to do user research really simply and quickly and then how important that is. It’s a new book. There’s a book called Cracking The PM Career by Jackie Bavaro, but it’s about the career which isn’t as useful here, but it gives you an overview of all the elements of product management that you got to focus on.

Sam Corcos (32:40):

Helpful.

Lenny Rachitsky (32:42):

This guy, Marty Cagan wrote two really important books in product management, but they’re also about big company and PM career stuff, so I would not recommend that for this person, but just for your notes, they’re called Inspired and Empowered that Marty-

Sam Corcos (32:56):

[inaudible 00:32:56] Inspired.

Lenny Rachitsky (32:58):

Cool. It’s like big company stuff. Those are the ones off the top of my head.

Sam Corcos (33:01):

That’s interesting like the Continuous Discovery Habits, this maybe ties them to where some of the ambiguity is. I would imagine those are very much within the scope of product design. From the designers that I’ve talked, they had user research and problem definitions and those kinds of things. Most of the designers that I know very much view that on their domain and maybe there’s just overlap there and that’s fine.

Lenny Rachitsky (33:30):

There’s definitely overlap there. It’s totally fine. It’s awesome when designers are really good at that. Sometimes they’re not. It’s often a collaboration between design, product and research if you ever restructure, but that’s definitely within the overlap. And if you’re a PM, if a designer is awesome at the stuff and doing it, “That’s amazing. Great. Go do it. I have more time for other stuff.”

Sam Corcos (33:50):

Another one that we’ve been trying to figure out, I fear what the answer is, which is that … I fear that the answer to this question is that every answer is the wrong answer, but we’ve been trying to figure out the best way for product and engineering to coordinate. And it seems like if you bring in engineers early, the project is not sufficiently well defined. If you bring in engineers too late, then they wish they were brought in earlier to help define it. It seems like no matter which one we do, if we bring them in early, we brought them in too early. If you bring them in late, we brought them in too late. And I don’t know what your experience has been on when the right time to loop in engineering with these things.

Lenny Rachitsky (34:35):

The way I think about it is give people a chance to contribute at every stage of the process, but not make them come to all these meetings that you’re having about everything. So there’s like these big milestones. You have just a rough idea, then you have a spec. I call it one pager just like an overview what the project is going to be and then there’s designs. So what I usually do is just like, “Hey, engineers, here’s the roadmap for, the whatever, this quarter. I don’t know if you disagree with anything here [inaudible 00:35:03] wise. It’s just like simplifying it.”

Lenny Rachitsky (35:05):

Then when you have a one pager or PRD of a project, just send it to the person that’s probably going to be working on it and give them a chance to review it and then talk about it in person if you want to. And then as design starts, just keep them up to date. And then once design is over, then you get more serious and meet and talk through everything. So continue keeping in the loop and giving them a chance to participate, but not like, “Hey, I need you in this meeting we’re having about this project from the beginning.”

Sam Corcos (35:31):

Got you. And let’s talk about in terms of engineering, resourcing and assignment. I see lots of different ways that this is done. I think it would largely just depend on personnel and interests of the team, but some teams have multiple weeks, on the order of 10 weeks of the product and design team without really any engineering participation, define the problem, do the user research, so they scope it, they define it and then they bring in engineering and then they say like, “Hey, how practical is this thing? Help us scope this even further.” And that seems fine and also I’ve seen other projects or companies where their process, every engineer is on the product from day one. They’re part of the process from the very, very beginning.

Lenny Rachitsky (36:21):

Right. [crosstalk 00:36:23]. The way I’d approach that is try to predict who is going to work on it. Every project should have an engineer that you think is probably going to take it. And if that ends up being generally right, then you’re awesome. If not, then you just pick a representative of engineering that’s involved …

Sam Corcos (36:40):

Sure.

Lenny Rachitsky (36:40):

… the rest of the team trusts and they’re like, “Cool, they’re going to stay throughout and so it’s all good.” Sometimes that’s like the head of engineering or somebody like a senior manager. So it doesn’t have to be like exactly right every time that the same person that’s going to build it as involved, but they need to feel like engineering was represented from the beginning a lot of times. And so I would just pick someone and just they’re nominated to be the person for that project.

Sam Corcos (37:03):

The senior engineer or eng manager makes a lot of sense because we’ve tried a few different patterns for this and this is a feedback that I’ve gotten from our engineering team, just about 15 people now is that it’s really frustrating when you’re an engineer assigned to build something, but you’re also a stakeholder in this other project and you’re supposed to advise them that the context switching between projects can be really a lot more costly than I think most people realize. And so we’re trying to figure out how much context switching is reasonable for engineers. So we’ll pick a hypothetical. Let’s say you expect the scoping phase of Project X to be four weeks and you put an engineer on that as a stakeholder. Do you also give them other projects fill up their time or do you just … What do you do in that situation?

Lenny Rachitsky (37:54):

And when you’re saying scoping meaning like design?

Sam Corcos (37:57):

Yeah.

Lenny Rachitsky (37:58):

Yeah, definitely. That’s not a full-time job for an engineer, so absolutely. I don’t think an engineer has to be deeply involved in that period. The designer goes off and design some new mocks and shares it with the engineer and then they have like a meeting for half an hour maybe once a week. So it doesn’t take that much time. But if you’re finding that’s a problem, yeah, I think the senior engineer nomination also works great. As long as someone is there capturing things. That’s the most important part.

Sam Corcos (38:28):

In the designing and scoping phase, what would you say are the most important thing is to solve for in that phase?

Lenny Rachitsky (38:36):

From an engineering perspective or in general?

Sam Corcos (38:38):

From a product perspective or it gets handed off to engineering.

Lenny Rachitsky (38:43):

So high level, the most important thing is that you’re solving the problem that you set out to solve which sounds obvious, but it’s oftentimes what goes wrong at that point. And so just like a pro tip there is any time a designer is sharing designs, always start with, “Here’s the problem we’re solving.” Just remind them, “Here’s the problem we’re solving.” That’s the most important thing. The other is, I guess, just off the top of my head, making sure it’s within the scope of what you’re trying to do. There’s like a million things you can build in. “Is this the size of project that you’re hoping you’d be? Are you making the tradeoffs you should be making?” I guess if you’re asking the most important things, those seem to be the most important things. Is there anything else you’re thinking there that you’d run into?

Sam Corcos (39:26):

No, I’m thinking about some of the projects that have gone well and some of the projects that have gone less well. And a lot of the ones that have gone less well seem to suffer from scope creep. I’m not sure how much of that could have been solved by better initial setup. I wrote a memo recently thinking about why it is useful to spend more time than some people think is reasonable, writing out thoughts in long form before assigning engineering to it. Because engineers are, for most software companies, the primary constraint. If your decision is going to cascade into 25 weeks of eng time, that’s actually pretty consequential. And if you’re spending an extra five days thinking about it or would have mitigated, even one week of eng time, it would probably be worth it.

Lenny Rachitsky (40:19):

So it sounds like it probably because you’re having designs end up being a lot more complicated to build than people think?

Sam Corcos (40:26):

Different projects that have different failure modes. Some of the issues are there’s a problem and then the problem is reasonable, but then the solution proposed, it’s like solving it for a very distant future state that we could just solve it in a day or we could build just really intense way of solving it for all possible future states. So finding that tradeoff, I guess, is maybe part of it.

Lenny Rachitsky (40:54):

I never had that experience. So this is stuff that PMs help with, is they stay on top of that kind of stuff and make sure the engineer takes the time to review all the stuff, often sees the things that are going to take a month versus a day. So these are the kinds of skills that you need for that person to have that’s in between. Because designers, you really want them to think big and think creatively and push the envelope and that kind of thing. You need somebody that’s not necessarily the engineer that’s always going to be, “How do we make this less complicated?” to be this middle moderator. So those are the kinds of things that DRI/PM should do for you. But it still happens. Things still fall through the cracks. Until you start building, you never really know what’s going on.

Sam Corcos (41:38):

An interesting case study is a lot of times it’s actually been our engineers who have been the best at helping to reduce scope where we had one particular project that was originally … When it came from product and design, it was scoped for four eng weeks which is reasonable. And the engineer said, “Hey, if we do it this other way, it’s only going to take one week.” That was great and so we simplified the implementation. They got it shipped a lot faster. So I would imagine if the engineer was involved, even earlier in the process, it would have saved more time, but again, I guess you do the tradeoff of, “What is the [crosstalk 00:42:14]?”

Lenny Rachitsky (42:15):

It’s always going to happen. You’re never going to not have those problems and opportunities, but yeah. When you think the engineer would be involved, if they spend half an hour on this a week, you feel like that’s too much context switching?

Sam Corcos (42:27):

I guess I would have to try to measure or ask them how much time they were contributing previously. I think they were probably spending a lot more than that, would be my guess.

Lenny Rachitsky (42:35):

And they still didn’t catch that kind of opportunity until they saw it?

Sam Corcos (42:38):

It’s probably more 10 minutes a day every day. With the context switching, you don’t really get deep enough to understand what it is.

Lenny Rachitsky (42:48):

Got it.

Sam Corcos (42:48):

Just basically catching up on things and being in the information firehose. That’s my guess.

Lenny Rachitsky (42:55):

It feels like not a problem spending 10 minutes a day checking on another project that’s happening behind the scenes. It shouldn’t distract engineers in my opinion too much. They’re not sitting there all day eight hours straight coding things and I imagine it’s like fun to think about someone else for a little bit, but maybe not.

Sam Corcos (43:13):

Well, I don’t know. We’ll figure it out. I guess the last question I would have is around the one piece of product that seems the least tractable to me in terms of how you would define it or go about teaching it is this product intuition concept. Is that something that you touch on in your training course?

Lenny Rachitsky (43:33):

I don’t. This is what I would … If I had another week in the course, I would touch on it. I don’t actually know the answer. I actually have a guest host coming all about this topic of things you can do to build your product sense and product intuition. And most of it just comes down to doing this for a while, watching customers use your product and many products and just becoming aware of where they had problems, where they enjoy, what goes well, what doesn’t go well and then just running a bunch of experiments and then constantly being surprised about the thing that works and doesn’t work. So it’s not something you just sit down three weeks later and got this figured out. It’s so long. It’s a tough one to build. So that’d be a great idea for a course, just like Matrix-style product sense jacked up.

Sam Corcos (44:18):

Will pay for it if you do it.

Lenny Rachitsky (44:20):

All right.

Sam Corcos (44:21):

It just has to be in content. We don’t do a lot of things live.

Lenny Rachitsky (44:24):

Got it. All right. Good tip. Good tip.

Sam Corcos (44:26):

All right, well, that’s all I have in terms of questions.

Lenny Rachitsky (44:28):

Sweet. Maybe a thought to leave you with is a point at which it feels like you probably need a PM or someone that has done pm for a while is when you’re just noticing a bunch of misalignment or a bunch of bottlenecks that just continues to happen or it’s also good for just take this thing and go run with it like a mini-SAM and help launch this thing. Those are three signs that you probably want someone that’s like been a PM for a while.

Sam Corcos (44:56):

It’s funny you say that because we have one of those situations right now. And I was talking to Scott who’s our head of product who also is an experienced product person and the answer that we all came to is like, “If we had an experienced PM on this, it would probably be solved,” but you could also say that about every engineering project you’ve ever had. It’s like, “Well, if only we had our most senior engineer working on every problem, then things would be great.” Well, of course, it would.

Lenny Rachitsky (45:24):

But I think it’s clear like the PM skillset would be good there, right? So I think that’s just coming back to your like, “Why do you need PMs?” There’s set of skills that’s very useful in specific situations, so that’s one.

Sam Corcos (45:34):

It feels like we’re juggling swords and the PM is really good at that, but the question is like, “Why are there swords and chainsaws in this equation?”

Lenny Rachitsky (45:44):

I think the swords and chainsaws are amazing products and features and pushing to grow the business.

Sam Corcos (45:49):

I suppose, but they could just be juggling balls and then it would be [crosstalk 00:45:53].

Lenny Rachitsky (45:56):

But I think it’s because you’re growing a massively huge successful company and the stakes are high in this case. You could be building an ice cream shop and you’ll have juggling balls and no swords.

Sam Corcos (46:08):

Sure.