Check out a free preview of the full Complete Intro to Product Management course

The "What a Product Manager Does" Lesson is part of the full, Complete Intro to Product Management course featured in this preview video. Here's what you'd learn in this lesson:

Brian explains a product manager, or PM is the glue that holds a team together. A PM ideates and organizes ideas from others, prioritizes work, creates plans/roadmaps, and does whatever a team needs to be effective.


Transcript from the "What a Product Manager Does" Lesson

>> So, what is the product manager then? A product manager manages product, full stop the end, we can just go home now, right? No, I would say the primary job of a product manager, if I'm just gonna like try and make some really broad strokes here, is determining what the team works on.

And that's gonna be via strategy, that's gonna be via writing product specs, meetings, those kind of things. And they just kind of figure out how to marshal the resources that are available towards projects that gonna be the highest impact, to move the company's goals forward. It involves what you're working on now, right?

So that's gonna be like going to the stand ups and the sprint meetings, and the backlog grooming and things like that, and kind of helping with prioritization. Prioritization is a massive part of being a product manager, it's a lot of research of like what are we soon going to be working on?

What's soon going to be important to us? There's some longer term like vision things as well, of like, what's way down on the horizon? Are we heading in the direction that we as a company wanna go? And then I've mentioned this a bunch of times but it also just feels gaps, right?

If you don't have a marketing manager, if you don't have a project manager, if you don't have a designer, if your team needs an extra developer for the sprint, I've done all of those things as a PM. Yeah, and I like this list here that I came up with.

So, some of it is going to be your ideas of stuff that you work on, but I would say most of the things that my team actually ends up working on either came from the engineering team, came from customers with something in the backlog from someone else, right?

So you do work on your own ideas, and you do make your own bets of things like, hey, I think this is gonna be a cool thing, we should probably try and get ahead of this. But it's also organizing ideas from your greater network of ideas available to you.

It's then taking those ideas and prioritizing them, as like, we're gonna work on this first. This is important, we have to ship this, we don't have to ship this. This is a nice to have. If you know as a PM if anything's nice to have means you're never gonna have it, right?

That's just how that works, cuz there's always something pressing. You create plans and roadmaps of the near future and the short term. Generally, that manifests as quarters. I would say most product managers think in quarters. In fact, today is the first day of my quarter for me, because Snowflake is off by a month.

It's incredibly annoying. I miss being on the normal quarters of January and April so on, and so forth. But here we are, you align your own team's goals to the company's goals. So for me, I work on a Python open source library, but I still have to ladder up my ideas to what Snowflake is working on, right?

So it's kind of keeping those things in alignment. And then the fifth thing is just whatever you have to do to get things done. That's kind of my vision of what a PM is. And I'm sure if you ask 10 PMs, you're gonna get 11 different ideas of what a PM actually does.

So, that's my general list, and I think I'm probably within rounding errors of what most people would say of what a PM does. Questions, concerns, profanities?
>> Have you run into any friction, and if so, how did you resolve said friction when your team's goals don't align with those of the organization or peer teams?

>> So, those are two very different things, and it's a good question. So, let's do the first one which is, what do I do when my team's goals don't align with my organization's goals, usually means I'm wrong, right? Because you work for that company, the company has a vision of where it's trying to go.

And if your team is going this way and the rest of the company is going that way, you need to have some serious answers of why you're running this way, because you don't want product teams doing that. This is actually, in my opinion, one of Stripe's biggest problems and I love working at Stripe.

But it's a little bit of product anarchy there, which is why they have 17 products, and they're all awesome, but they don't work together super well, right? And it's because they have a bunch of teams going slightly different directions, now that they're reading that in, they're working on it.

That's an acknowledgement that I've had for a long time, and I think from the outside you probably can't tell Cuz Stripe is still an awesome product, right? But it couldn't be better, right? And I was also in the muck with them and frustrated and whatever. You learn to criticize your own company in special ways.

So, generally, your revision needs to align with the organizational vision, and if you don't align with that you shouldn't help change the organizational vision. The second one is what if you don't align with sister teams, if they are laddering up to organizational vision and you're laddering up to organizational vision, I would argue that generally you are heading in the same direction, right?

Because you're both adhering to a vision. You're gonna have nuanced differences of why you think yours is better or different than theirs, and that's okay. You don't have to have perfect alignment because it takes too long to figure that out, right? Where it can come into some conflict if like, let's say I'm doing, and this happens to me quite a bit, it's like, I have this thing that I wanna build, but I need other teams to build things that allow me to accomplish that.

And we'll talk a lot about technical communication. This is called influencing without authority. Whenever you interview to be a product manager at a company, they're gonna ask you questions about how do you influence without authority? It's one of the critical principles of being a good PM. The short answer is like you'd find a way to frame your idea in their goals.

And so if you can convince them as like, by helping me, you're helping yourself, generally your stuff will have a much easier time of getting done. But, it's not always possible and it's gonna vary a lot by company. At Stripe, I had to convince them, because Stripe is very bottoms up.

And at Microsoft, I would go convince their boss, and then their boss would tell him to do it, right? Because that's how Microsoft works. So, you just kinda have to figure out what game of thrones or game of you know rolling off his chair that you're playing, right?

Yeah, Mark?
>> As a PM, are you generally taking in the technical roadmap and marrying it into the feature roadmap? Or do you have any other ways to negotiate things like paying down tech debt? How deep are you into the tech?
>> That's a good question. Me being the nature of that I actually care how they're implementing it.

I would say a lot of product managers just kind of say like, we're working on these things, I don't care how you do it. I actually do care cuz I'm interested and I like technology. So I work super closely with my engineering managers. Like I am glued to my engineering manager at Snowflake and Mateo's great.

So, our technical and feature roadmap are the same thing. And I make sure that we're always very in touch with where the engineers think that we are, so that we have enough space to make sure that we're paying down the tech debt that we need to. That's my product management style.

That's just driven by my interest in how we do things. We were in the middle of a Kubernetes migration kind of project, and I am very in the details of how are we storing secrets? Where are the secrets going? How are we routing traffic? Because I care, and I like those things, and I have a lot of experience in those.

You could also equally argue that I should be more off in feature led, and trying to, manage those kinds of things as well. I'm just going to come down to what's important to your team, and what's important to you? So, some companies will keep separate feature and technical roadmaps, engineering managers will define the technical and product managers defined the product ones.

I don't like that, I think they should be the same thing. So far the companies I've worked at they have been the same thing, but it's gonna depend on your company there. You just lean into your strengths, I guess. In me being a part of the technical stuff, it's me leaning into my strengths.

>> How would you tackle a company trying to push those product management responsibilities and roles on the developers?
>> It's a good question. It depends. That's my whole answer to the question. Sometimes it's just necessary, like as a tech lead, I've had to be a products manager before.

That's why I like when I jumped in these positions. It felt really familiar to me because in the absence of a product manager, it frequently falls to the engineering manager or the tech lead to product manage their product. It's necessary. I don't think I can necessarily apologize for your organization doing that to you, because if you don't have a product manager, someone has to manage the product.

And if you don't wanna do it, you should make that very known, make sure that someone else is doing it. Because otherwise, you're all gonna build weird things that don't fit together. I think product managers are necessary. That might be my own bias showing here a little bit, right?

So, it's gonna depend on, does your team have a product manager and your product manager is not helping enough? Is it that your team doesn't have one and it needs one? It's gonna depend. But I do see frequently engineers do have to act as mini PMs. I liked it when I was an engineer, and I think that's why I liked being a PM eventually.

But I liked having a lot of say in what we build as opposed to just being told what to build.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now