One of the most frequent questions that I am asked as a product manager - is what exactly do I do. In our 2+ hours of free lessons, you can find out exactly what a Product Manager is as I define it. In this post, I provide a sneak peak into the type of content that our courses deliver and how you should expect the format to be delivered. This course content is free, and you can sign up right now to find out the rest of how I think about product - start here now.
OK this first course is going to be a big one - so strap yourself in and lets do this. This content should be totally useful for new, and serve as a refresher for existing PMs, again, I’d love your feedback on everything you see here, please do that in the forum or via [email protected]
So, what is a PM?
The traditional thinking of what is a PM was really created in a diagram around 10 years ago by Mindtheproduct
It looks something like this. A broad scale interaction between UX, Technology and business. I’ll note that this course is really focused on *Technology* product managers - there are PMs for non-technology products but that really is the focus of this course, although some of the material might be relevant to that user group as well.
A PM is really sitting right here in the middle - at the common point of intersection.
So what does a definition look like: “A product manager drives their team and company to develop and ship the right product to people who want it.”
Lets highlight a few key terms that matter here. I would say they are “drives, team and company, ship the right product, people who want it” - that’s the essence of the Product Management role.
When we talk about User Experience: it doesn’t just must mean “User Interface”. That is, how things look or the experience you have when interacting with an app, website or your mobile phone.
Its about focusing on developing human centered user experiences.
And making a product usable, functional and ideally simple.
For technology: PMs have a strong curiosity for technology and how it works.
You will need to understand how technology products grow, something that we cover in-depth in Product Management I course.
You will also need to be technical enough to lead and speak with the the engineering team on your product. If you can’t understand some of the tradeoffs to what you are building, you can’t lead effectively.
Lastly, for business: you need to understand the fundamentals of how businesses operate and how they are structured.
This includes everything from economic modeling through to organizational structures.
And undoubtedly broader macro economic trends and distilling that down to local optimums.
So again, the idea here is that you at this intersectional point where you are looking at user Experience, Technology and Business colliding in the middle. While this diagram tends to make the world look balanced - its usually very different in reality. The space represented here is rarely in this perfect balance. In fact, its usually NEVER in this balance in reality.
For PMs, this perfect balance doesn’t exist. The reality is so very different. The world isn’t as static as those circles make out.
Firstly, I would argue, the state of your intersection is completely product dependent. Those circles don’t remain like that across different companies, products or even across different PM roles. They ebb and flow drastically.
As a practical illustration, this is how being a PM looked in my startup company
In the beginning, it was mostly figuring out what the hell users wanted, was there a real business here and how could we produce the fastest possible prototype to get it up and running.
As we were still early, we needed to continue to iterate very quickly and ensure that the feedback customers were giving us was valid. As we got more confident - we then starting focusing more and more on getting the product working from an eng perspective. Outside of the economics and setting up the company (which is a heap of work in the early days) - there wasn’t really a lot more to business at this point than slide decks and hypotheticals.
As the product started to get real traction, we needed to continue to scale the technology really rapidly and start firing up more components of the business part of the triumvirate.
At an extremely abstracted level, this is how it looked in ads & shopping as a Google PM
At Google - the business model was much clearer, it had been around for 15+ years when I joined, but what wasn’t was Are we building something that users actually want ? How can we validate that as quickly as possible to reduce downstream engineering costs.
As a huge organization, Google has a lot more complexity to it than your typical startup. Most large companies in technology will look more like this than less like it when you start deep diving into each respective area. So relevant to the “startup” - although the “business” side was seemingly less - it was actually much larger and this is why you really need a better way to “normalize” the circles that were illustrated in the first diagram. So relatively - “PM” in startup land is radically different to “PM” at large technology companies. The former is all about recalculating and maximizing risk to find product market fit, the later is all about recalculating and optimizing to ensure you don’t blow something that’s working, up.
Again, at a very meta level, this is how it looks in machine learning frameworks as a Product Lead
In machine learning, there is much more time spent on the technology - its a developer focused product so this would make sense. But a lot of time needs to be spent on the UX as well - what is the API surface like, are users happy with it and so on. Developer products obviously all have users as well and you just need to change the perspective on how you look at the user experience.
Either way - its a highly dynamic role and it can change rapidly depending on the type of PM you are and what product and company you are working in. We talk about different types of PMs in a later module. You have to rapidly change your time prioritization depending on what your team needs to ship the product.
Some days you are the dreamer . Figuring out the product vision & what success means.
You’re tossing around crazy ideas & how to quickly prototype them with your entire team and other PMs.
You’re focused on trying to determine if there is really a market for your idea A, B or C.
Some days you are really just the messenger. Getting feedback from users & communicating that to the team.
You’re selling the vision, strategy, roadmap & product offering to anyone that will listen.
Or you’re taking down notes & assessing priorities.
Some days you are the storyteller. Meeting people all day to push your agenda, persuade them & get their feedback.
Some days you do the critical job of storytelling. You evangelize the product through user stories to get your product & priorities prioritized.
You work with marketing, business development, legal & sales to develop the right product positioning.
Some days you’re all of these (& more) The key goal is to develop a generalized set of principles that will enable you scale yourself across any product or problem that you work on.
Being a PM isn’t easy - you get minimal congratulations when things go right, you have to accept responsibility when things go wrong and retrospections will often tell you that all the excuses in the world wont get you very far. You could have always spoken to more users You could have always done more to convince your organization or your leaders You could have always tried to influence others You could have told a better story Sometimes you just cant do these things, and sometimes there are other factors at play that just wont work with you. We talk about this more in the next module.
Get a free account & join our mailing list to receive the latest news and updates. Your information will not be shared.