Shapes of Product Management
When people ask me how to get into product management, I often ask them what they mean by product management. The answers vary from PM being “CEO of product” to the “function between business and technology”
Product management, the way I define it, is essentially solving problems by creating products.
Other roles also solve problems, but those problems are solved by creating processes or organising people, not by creating products. These days, the term has come to mean only digital products but the actual ambit is much wider.
Consider a work chair. It exists to serve a specific purpose - to help you sit and do work. It is designed differently than a lounge chair, which exists to help you relax. This is also often referred to as the Jobs-to-be-done framework.
So all the products that you see around you, from a nail to aeroplane, have been through a ‘Product manager’.
When outsiders often talk about product management, they have a fixed view of what a PM does - write PRDs, influence people, say no to most things and irritate people etc. While these are mostly tactics, this is best understood at a different abstraction layer.
At an abstract level, PM requires understanding
User
Engineering
Design
Data Science
Data Analysis
So it is natural to assume that the skill graph may look like this -
Meaning - you have to know some bits of the surrounding technical domains and a lot about the user.
However, this is not true. In reality, there are different graphs here based on the product.
If your product is an experience heavy product, like a game or an app like Duolingo where a lot of things are happening on the UI, you need a good design sense. AUS refers to analytical user understanding and QUS refers to qualitative user understanding. You need both to understand the user well. The other domains aren’t that important here.
If your product is technically intensive, like designing the best quality video experience, you need a basic knowledge of the engineering and its constraints behind it, as well as user expectations and constraints (network speed, device quality etc.)
If your product is algorithmically driven, you need to ‘roughly’ understand how algorithms behave and what is the user expectation from it (e.g some users want more similar content vs new content).
As the shape of user expectations changes, the shape of your skillset also changes. This is also why the PM role requirements are very different across these buckets.
This also means flexibility to choose the kind of PM one wants to become. If you are more inclined towards a particular domain (e.g. DS) vs other, it makes sense to index more on those kind of PM roles.
If you are interested in knowing more about PM, reply to me with your questions and shall write a post on it. Here’s another post on PM that you may like.