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

The "Hard Parts of Product Management" 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 shares some difficult aspects of product management. Meetings and communication are a significant part of the job. It can also be difficult for former engineers to feel productive since accomplishments are not measured in pushes to Git repositories.


Transcript from the "Hard Parts of Product Management" Lesson

>> Why you might wanna be a PM. So I'm gonna tell you what I like about being a PM and what I don't like about being a PM, and we'll start with what's hard about being a PM. If you do not like meetings and e-mail like me, then you probably are gonna have trouble with part of your job because a lot of your job is meetings and emails.

A good half of this course is going to be about how do we do meetings and email well? I'm not sorry that's a huge part of what this job is. You might follow up with a question as like, why the hell are you a PM if you don't like those two things is like one, I don't think anyone likes those things and if you do, What is wrong with you?

[LAUGH] That's probably strong language to say, but I don't think anyone enjoys like sitting in long meetings or having to write per my last email in an email, right? But generally like this is what it is, coordination and communication. And then this was actually probably my biggest struggle with moving from being an engineer to being a PM.

When I was a engineer, there's a little sense of accomplishment that every time you say git add, git commit and git push, that I did something. I took a piece of work and I did it, and then I pushed it, and then now I get to feel accomplishment because the mechanically, I stamped my work as done and sent it off, right?

And then I closed the ticket and that happens frequently, right? As a PM or sorry, as an engineer, I was committing work at least once a day, if not multiple times a day that was a constant button, I got to press, you did it. You did it, you're working and it feels good, and that feeling of productivity is like if I went a whole day without making a commit, I would feel unproductive, right?

And that happened a lot, when I had a heavy meeting day as an engineer, I would get to the end of it like I did nothing today. What's hard about being a PM is you have to find different ways of feeling productive. At least for me as an engineer, you don't get a sense of accomplishment when you send an email, you don't get a sense of accomplishment when you hold a meeting.

All of those things, it's much squishier in terms of when did I do something? When did I accomplish something? When do I get to claim work is mine? These are all questions that I really struggled with. And for my first little bit as a PM at Microsoft, I was like, I don't understand how to feel good about my job.

And so I had a PM mentor that helped me, my manager at Microsoft helped me quite a bit. And honestly still sometimes feels like I got a whole day of like back to back meetings like what did I even get done today. But when you start learning to recognize when steps are being taken forward and in your work and like okay we cleared this review, we got this doc approved, we finished planning, we had a good sprint.

We close to these issues, I started to recognize those things and okay, Brian, you can feel a little good about that right. And actually that dovetails nicely into the second part of this. Whenever I shipped work, I remember seeing, I shipped a new sign up experience for Netflix TV.

Where you could like sign up for Netflix using your tv, and I gotta look at that and I remember going and showing my mom, I was like, mom, I built that. And I got to feel, it was really easy for me to take that sense of accomplishment of like, look what I built, I wrote the code that does that.

Now, in retrospect, there was a PM that defined that work, there was a project manager that managed all of that, there was a designer that designed that whole experience, there was a QA engineer that went through and tested all of that. Did I mention that to my mom?

No, of course not, I built it, right? I don't know, but I never felt important to me because I felt like I did enough of that I can claim that as my work. Now when I see things launched as a PM, I'm much earlier in those cycles and I do help them kind of see him over the finish line, but most of the glut of my work came at the beginning of those projects.

And so all the final work and do it like a huge spike on this, to get everything defined to work and then it doesn't get done for like another six months. And so when I look at that, it barely feels mine anymore, right, and I know everything that went into it.

I know how much work the designer went and put into it, I know how much the QA. And so I had a hard time looking at and saying, I did that because I know it wasn't me, totally. So it took some time to rewire my blank is to say, it's okay, Brian, to claim still that you did that and that we did that, and it's okay to take some credit for that yourself.

But I also remember as a engineer being really annoyed at PMs and saying look boss, look what I did, and it's man, I did that. You didn't write any code for that so, I don't know. Taking credit for work was also hard for me, but I also witnessed one of my coworkers at Microsoft, Sarah Drasner, another teacher for front-end masters.

She did a really good job of saying, I did that and so did these people, they also did this. And so sharing that credit publicly also made me feel okay taking some credit for that work as well. So, I don't know, you might not have an issue with that, but it was a struggle for me after being an engineer for so long.

This is one that I don't necessarily struggle with as much, but I've definitely seen PM struggle with it, so I'm gonna talk about it a little bit. What to do next as a PM can be very unclear, you'll finish something and as an engineer you just go to the backlog you pull some another ticket off and you start working on it right.

If you don't know what to do next as an engineer your project manager probably effed up somewhere, right? As a PM, no one is really telling you what to do next and what you do next is really up to you. And it's an exercise in prioritization of, how am I gonna spend my time?

And what's hard is like you always have too many things to do and also sometimes it feels like you don't have enough to do. And that can simultaneously live in your chest and give you an anxiety attack, right? So it's a balance of what needs to be done now today, what do I have to ship today?

What am I gonna have to have done within the next week or two? And when do I have time to do strategy work for a longer term and you have to do all of those. And if you don't actually hold yourself to as I have to do strategy work for later you will never do it because there's always enough to do now.

So that can be very difficult for new PMs, learning how to spend your time correctly, and learning what to do when you finish something else.. And I would say of all of these. If this is hard for you and that's a very difficult thing to you might wanna consider not becoming a PM because it never gets better.

It's always kind of a struggle, like, what am I going to do next. Its always exercises, I have something on fire and I have something on fire, what fire is more important? And sometimes the answer is like they're both important and they both have to be done and you still gotta pick one, right, that can be hard.

Okay, questions? Anything about that about what's hard about being a PM? Those are the four that I kind of fell to talk about, but I'm sure there's more.
>> How do you balance advocating for what's best for the product, the team, and the company? And if they're in conflict, what's the communication like to the individuals that aren't gonna win that battle?

>> That's a good question, it depends. [LAUGH] So, I mean, this is probably another exercise in prioritization, right? So I would probably start asking myself, cuz I could see myself with, this seems really important for me, this seems really important for my team, and this seems really important to the company as a whole.

And I'd probably start trying to break it down, what kind of impact am I gonna have versus how much effort am I going to expend on this and do I have the resources to actually accomplish what I'm trying to get done. If I would say typically when you run into those kind of conflicts, one of those clearly wins, this is either gonna be huge impact or this is gonna be way too expensive.

And like those big bets are still appropriate but you have to kind of know how to marshal your social capital. When I say social capital, it's credit that you have with your friends, right, you do favors for other people to make withdrawals later. I mean, it seems transactional and that's because it's actually transactional but, Yes, some of those asks can be really expensive on your sister teams and your organizations, and making sure that you are doing the correct thing for all of those things because all of them are important.

So, yeah, generally try and break it down and see which one is the cost versus impact. And then if they're equal at that point, I probably err on the side of a corporate team mind. I would say that's a very weak bias, that I try not to get to that point.

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