Skip to 0 minutes and 2 seconds One of the things you’ll hear about the product manager role is that it varies a lot. There’s so many different kinds of product managers. And that’s true. But they also have a lot of things in common. And they tend to vary in some relatively similar systematic kind of ways. So what I thought we would do is take a minute and talk about the dimensions along which the role of product management might tend to vary. And then, we’re going to talk about how these different methods you’re going to learn how to use this week may apply to those different takes on being a product manager, different roles that you may have. These are the dimensions I chose.
Skip to 0 minutes and 35 seconds They’re not necessarily the absolutely only dimensions that you could use to describe the role, but I thought that they were useful and practical. This idea of abstraction is, are you in there working with the team every day on the details of the implementation? In which case you’re also probably acting in that product owner role we talked about. Or are you mostly working on setting direction and looking at the larger picture of how the business is operating? So this is, your still a project manager here, but you’re also a PO. Then on the business facing, versus engineering side, are you more out with business people. If you’re internal, or customers and stakeholders.
Skip to 1 minute and 17 seconds If you’re external or are you more working with engineers and your working a lot on that feasibility dimension, that technology infrastructure. Lets look at a few examples of the types of PMs that might fall on and how they might fall along this spectrum. There’s this idea of a growth PM, which means that you are overall responsible for growth, revenue growth, user growth across a particular product or market or interaction sort of channel with the product. And so here your job is primarily business facing you’re looking at how the product is used and how it’s sold and explained, and you’re operating at a relatively high level of abstraction in that sense.
Skip to 2 minutes and 2 seconds If you are managing a third party developer program and you are this generalist PM that looks after the whole thing, you’re operating at a high level of abstraction, but you’re primarily working with probably both internal and external engineers on what are we providing these third party developers? How are they using it? Is it working for them? What kind of results are we getting?
Skip to 2 minutes and 25 seconds Let’s say that you’re the product manager for a specialty piece of enterprise software, or a specialty use of a piece of enterprise software. Then you’re going to be primarily business facing, understanding this particular set of users. Like, let’s say, we have a piece of enterprise software that helps with financial compliance, that you’re going to be working with business people at a low level abstraction. The engineering part might be relatively straight forward. You have a very flexible sort of enterprise software kind of environment. But there’s a lot of details about how you make this work for the user.
Skip to 3 minutes and 0 seconds And then finally if you’re working on another development platform internal or external to the company, you’re working on a specific API, then you’re probably relatively engineering-facing in a low level of abstraction. Now these are some ways to look at where you should focus. And that’s why I thought it might be useful for us to step through this. So as we proceed, we’re going to look at what are the focal points that are particularly important depending on generally which one of these quadrants you’re in.
What kind of PM are you?
In this video, Alex introduces a spectrum where the job of product manager may fall– somewhere between high and low abstraction, and in a position that is more engineering-facing or business-facing. In preparation for moving forward in this week’s classes, which quadrant do you find yourself in?
© Copyright Rector and Visitors of the University of Virginia