Complete Intro to Product Management

Reasons to Become a Product Manager

Brian Holt

Brian Holt

SQLite Cloud
Complete Intro to Product Management

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

The "Reasons to Become a Product Manager" 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 the exciting aspects of product management. Developing strategy, working with a wide range of people from engineers to end users, and the variety of work are reasons a person maybe be drawn to product management.


Transcript from the "Reasons to Become a Product Manager" Lesson

>> I'm gonna talk about why I like being a PM. Hopefully I've sufficiently scared everybody now. It's, well, maybe PMing sucks, maybe it does, I don't know. [LAUGH] I'm still finding out. But let me tell you what I do like. I like determining the what of what we work on.

So I saw this quite a bit at Netflix. Netflix does a really good job of getting their engineers involved early in projects where the engineer actually gets to say how we're gonna build and what we're gonna build. And that was really exciting to me. At Reddit, I kind of just determined everything that we were gonna work on, cuz I didn't have a PM, and I also didn't have a designer, and I was employee 29 at Reddit.

So, that was kind of all of it all in one. But I liked that Netflix helped me in a big corporate environment get to be able to say what we're gonna work on. And I've been the code monkey before where they basically say, all right, code monkey, go do that, right?

It's fun too, cuz I like writing code. I just enjoyed the acts of writing code. But I also got really into, what are we gonna build, why are we building this, who are we gonna build it for? One of my favorites experiences at Netflix is how much UX research we got to do.

And I actually got to go watch people use my product and then we got to adjust our product based on customer feedback. I really like this, right? And so that's one part about being a PM that I like, is that now I get to call the shots. For the most part I am the product owner of my organization and it's not I get to dictate to them you must do this.

But I get to organize everything and I get to insert my opinions and my own flavor and my own strategy on all that. And that's my favorite part of being a PM is determining the what. It is people, people, people so you get to, that's gonna get distracting, so I'm gonna scroll up a little bit, it's people all the time.

It's who you work with, what they're working on, who you're building it for. We're gonna talk a lot about users throughout all this course because being a PM means being in tune with what your users are doing and what they want and what they're failing with and what the problems they have.

It's a very empathetic position. And if you're not interested in being empathetic both on solving business problem and just an emotional level of how do people respond to what you're building. I like it, that's one of my favorite parts about being a PM is you get to focus on people all the time.

This kind of sounds weird, but I like being wrong. Going back to that Netflix example, I remember the very first time I went into that UX lab and I got to watch someone use my product and I had built this really cool thing. I remember it was the first time I ever shipped Redux, which probably has nothing to do with this course, it's just something that stands out to me.

And I was so excited about the technology that I had used to build this. And it was this really cool experience. I had this anticipation that they're gonna do this, then this, then this, then this. And I watched them and the person clicked on it and then it's, what is this?

I don't understand what you want me to do next. It was very unclear to this person then I realized I was so focused on the technology of how I built this. And all of the cool things, the blog posts that I could put on the tech blog about this, the conference talks I could give about it, because objectively it was very cool technology.

I had missed the entire damn point, which is people are gonna go use this, right? When I saw them using it, I was like, my god, I'm so wrong and that's so cool, right? I kind of felt like this, right which is why I put this GIF in here.

You build this thing and you have some anticipation of how people are gonna use it and then when it's actually given to someone, they use it some entirely different way. So, some of you might have seen this picture before. This is called the desire path, right? You build this sidewalk here, and you have this anticipation of people are gonna go do this.

And then people always find, it's, I actually just want to solve my problem, right? I don't wanna go through your cool wizard. I don't wanna go through your process that you set up for me. I have an intent when I arrive with on your product and I want to achieve my intent as fast as possible.

And you will discover these desire paths, right? It's not a term I made up, it's a term that actually exists. And people will carve that through your product either intentionally or unintentionally. And it's your job as a PM to recognize the music, I'm wrong, I did this incorrectly, I was not in tune enough, or my bet or my experiment didn't work.

And now if you're a PM, you would go pave this, right? Because now you have a concrete, people actually just wanna go here. So, I love it, I find it exhilarating, it's my favorite part, because when you're wrong you're learning. And I love to learn, and I love to kind of go in and I love to experiment, right?

I love to come up with a hypothesis of, I'm gonna try x and see if y happens. And in reality, z happens and I was that's so cool I now know more about this than I did before. I read a book about this recently that my executive coach recommended to me called, Think Again by Adam Grant.

If that resonates with you, that I'm learning something and I'm wrong, and that's a lot of fun, I recommend it cuz he actually goes into the science of, why that's cool for some people. And then the variety of work. I get to write code still fairly frequently. I still write code on a probably weekly basis.

I'm not shipping a lot of code. I don't think I've shipped any code at Snowflake other than to the docs. But I do say it's a lot of meetings and emails and it is a lot of meetings and emails. But it's also writing content, it's a lot of marketing plans, it's a lot of coordination, it's a lot of working across a variety of products and projects rather than just on the one that you're working at the moment.

So the variety of work also keeps me interested in the work as well. Any other questions about what's fun about being a PM? Yeah.
>> So, [COUGH] I taught professionally for many years and I know that human factors, size of jobs, some people really enjoy that part of the job.

And you can have what are very bad days and go home, go to bed, wake back up and go right back to conversations without really remembering that you were in a lot of arguments the day before. Other people that is not so much their preference and this is very much a human factors, jobs.

How do you manage those dynamics where it's not just about the objectives, it's also about the personalities and many times you're being stonewalled for personal reasons. Projects you're talking about kind of offline, there's some disconnects that you know you just run into walking in. How do you manage your own kind of backend on that coming in levelheaded making sure you're making the right kind of advocacy?

>> Sure, it's a good question. I think I have several answers to that. One of them is taking care of myself, right? Making sure that after work hours, I make sure that I try and work relatively 40 hours a week. I really try hard not to work much more than that these days.

And then filling my cup at home, right? Making sure that I'm exercising, eating well, taking care of my family, that kind of base of security helps me a lot when I get into work that I'm happy to deal with the people that I'm gonna be dealing with. I'm generally trying to associate mostly at work with people, they don't have to be my buddies I'm gonna go get beers with but people that I can get along with, right?

And if I work with a PM that I don't like, and there's anotherPM in that organization that I do like, I'll probably just try and work around them, right? It's not always possible, right? So there's frequently that you do have to deal with jerks. And then, at some point, you just have to recognize that I'm doing the right thing or I think I'm doing the right thing.

And if you have confidence in that, working around or through someone becomes less of an issue for me. I generally don't care what people think about me. I think if you watch me make an idiot on camera fairly frequently, that becomes fairly obvious. So having a little bit of a thick skin of, I'm gonna do what I think is best and at the end of the day, if this person is upset by that, then kinda their problem, not mine, right?

>> So you have direct reports or does the product manager generally not have direct reports.
>> That would be a product group manager, is what you would call that position. I probably should have put that in there. They're the people that would manage a group of product managers.

So a product manager typically is an individual contributor. So I don't have any reports at Snowflake. But a product group manager, just to delineate that a little bit. Generally they kind of set the strategy for their whole area and then they let their individual products managers kind of make their own strategy of their little part.

So, I think that's why I would say I think that's a pretty cool position. Because then you work mostly on strategy and people and those are two of my favorite things about being a PM. But you get into a whole different thing of what it means to manage someone.

Which is an entirely different skill set that we're not talking about at all about today.
>> So just to drive that clarification home with a specific example. Would a product group manager set the strategy for something like a suite of products like a Microsoft Office? And then have dedicated product managers that report to them for Word and Outlook and Excel and things like that.

And maybe those products are bad examples cuz those products alone are quite large.
>> Yeah, so you got it. Then yes, I was about to say, well actually Word has like 30 PM.
>> Right.
>> You can imagine word having a PM group manager. And then each one of those will be managing the spellcheck and the formatting and all that kind of stuff.

So yeah, exactly, and it's gonna depend on company. Some companies, those PM group managers really only worry about the people and don't worry about the strategy. There's other companies were the PM group managers set all of the strategy and all the PMs are just executing on their strategy.

So there's gonna be some spectrum there. Yeah, Mark?
>> Where do product owners fall in the hierarchy, at least in the works that you've been a part of?
>> Yeah, product owner. That's another term that probably bears talking about. In my experience, it's not actually a title, it's kind of like a duty.

So, for example, I would be the product owner of Streamlet Community Cloud, which is the product that I actually manage myself. But it's not my title product owner it's just it's a thing that it's, what would you want to call it, an aspect of my job, right? I think that is a title at some companies.

And I think it would be like a vice president, would be a product owner, right? Where they own the entire product and then they have people that report up to them, that work on it, but it's a very ill defined job description. And it's gonna be very different based on companies.

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