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 ways. 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, 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 have talked about? Or are you mostly working on setting direction and looking at the larger picture of how the business is operating? You're still a product manager here but you're also a PO. Then on the business facing versus engineering side, are you more out with business people, if your internal or a customers and stakeholders, if external or are you more working with engineers and you're working a lot on that feasibility dimension that technology infrastructure? Let's look at a few examples of the types of PM's that might fall, and how they might fall on this spectrum. There is 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. 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. If you are managing a third party developer program and you're this generalists PM that looks after the whole thing, you're operating at a high-level of abstruction 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? 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, and you're going to be working with business people at a low-level of abstraction. The engineering part might be relatively straightforward, you have a very flexible enterprise software environment. But there's a lot of details about how you make this work for the user. And then finally, if you're working on a developer platform internal or external to the company, you're working on a specific API then you're probably, relatively engineering facing at a low-level of abstraction. 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.