#001: What Is Product Management?
And what's the role of a product manager?
In this post, we will look at three key aspects that are necessary to understand what a product manager does:
First, we’ll look at the environment a product manager operates in.
Then we discuss a product manager’s areas of responsibilities.
In the end we will look at the high-level skills a PM should bring to the job to be effective.
The product manager is responsible for the end-to-end delivery of a product.
She builds the product on behalf of the user and is responsible it gets shipped.
A product manager (a.k.a. “PM“) does not manage a project nor people (even though it is possible a PM also has people management responsibilities).
Instead, she manages “product”.
So don’t make the mistake to think a product manager is “just“ a project manager (and then assign a project manager with the task of building the product).
And since every product is different also the jobs among different PMs differ.
Yet, there are a lot of similarities across the various PM roles.
1. The environment of a PM
Let’s first understand the setting a product manager operates in.
Side note:
For startups in the early stage the role of the PM at the beginning is typically carried out by the technical founder or the visionary founder, whoever the “product person“ at the startup is.
Dedicated PMs are hired later.
In general, a PM does not necessarily have hierarchical power in a company and yet is responsible to ship the product.
Thus, a PM must work with a variety of stakeholders inside an org such as engineers and their managers, design, marketing, sales, research and customer support, legal as well as management.
Note: Here we assume we are talking about a product where the users are outside your org.
There are also PM roles to build products that are only used inside your org such as an admin panel, internal APIs, middle-ware, and others.
With those products - even though they might be equally challenging to build - the marketing and sales aspect does not apply.
That’s a lot of stakeholders to depend on to get a PM’s job done!
One thing a PM should not have to deal with is business development.
For instance, the very time-consuming tasks of negotiating and signing contracts or establishing partnerships and the like should be entirely owned by other roles or even the management in case of a smaller startup.
(You are doing a disservice to the product team which may negatively influence the quality of the product if your PM is also charged with business dev tasks.)
How does a PM deal with all dependencies and stakeholders?
Consider that - especially in a big corp - different stakeholders will all have different priorities and other interests than helping the PM with her (possibly not even yet existing) product.
Thus, a crucial skill set of a PM is stakeholder management.
But before we look at the necessary skills a PM needs to be equipped with, we first dive deeper into a PM’s areas of responsibility and accountability.
2. The responsibilities of a PM
In short, a PM must do a lot of decision-making with incomplete information in order to execute against the product roadmap.
In other words: prioritizing in an environment full of ambiguity and different opinions from different stakeholders.
However, depending on the stage of the product (e.g. building phase, just after launch or during scaling) the ambiguity comes in different flavors.
And so does the incomplete information to take decisions.
One way to think about it: a PM needs to manage ambiguity through de-risking in each of a PM’s responsible areas.
De-risking does not mean a risk goes to zero.
It rather implies that a risk can be estimated and controlled in such a way that it is worth taking it.
Looking at the challenge in this way there are a few risks from Marc Andreessen’s Onion Theory of Risk that the PM is heavily accountable for or possibly completely owns:
Product risk: Ensure that the product can be built with the available team.
It includes establishing and owning the product roadmap. Depending on the seniority (and thus, responsibility) of the PM she also needs to ensure that the necessary engineering resources can be allocated to build the product or feature.
Distribution risk: Building the product and how it is distributed are two heavily related aspects in product management.
If scaling your product requires a network effect for massive distribution or the integration of a virality feature then those aspects must be deeply thought through when building the product.
Whether you implement product-led growth (PLG), for example, for a consumer or freemium B2B SaaS product or sales-led growth (SLG), distribution is as important as the product itself.
If you build a product as a PM without understanding how it will be distributed you risk that it cannot be distributed at all.
First-time startup founders / PMs often make the mistake to believe their product is so awesome that it will (magically) distribute itself.
On the other hand, first time corporate innovators often think that developing the product does not require much attention and can just be delegated to whoever “knows how to write code”. Then marketing will make sure the product (magically) gets distributed.
In both cases, no magic is going to happen for sure and if one expects magic one will fail.
Always remember: The world is not waiting for you to launch your product.
So a PM must always apply first-principles thinking:
In product management this means, first understand the customer or user and then think backwards to figure out the product.
In the case of distribution it means thinking through the customer journey to understand how a user will go from discovery to user to paying customer.
Thereby it is okay not to have figured out yet every detail of the customer journey before building the product.
But being aware that there are missing parts is not the same as dismissing them by believing they will resolve themselves.
(I’ll write more on that in another post regarding bottom-up vs. top-down go-to-market strategies).
Marketing risk: How do you cut through the noise? Again, how will your customers discover the product, at what point will they pay for it and how does the overall customer journey look like?
If any of above questions must involve marketing to find an answer (which usually is the case), then distribution risk and marketing risk are very much related.
A lot of marketing is actually product-building, especially when looking at marketing through the CAC (= “customer acquisition cost“)-lens.
Then you are already playing the funnel optimization game, which means increasing conversion by reducing friction until you register dollars.
Ensure end-to-end tracking from when a user clicks on an online ad until he upgrades to a paid plan.
Or boost team-network effects of a B2B product (think about Miro or Figma) to drive down CAC. In other words UX-work and product feature implementation.
Technology risk: Can the product be built? Do we have access to the technology, resources and legal framework to build what we want to build?
Imagine you want to build a product for radiologists that automatically detects cancer in brain MRI images.
If the radiologist can only analyze his patient’s MRI image by uploading it to the cloud because you’ve built a SaaS product that requires the AWS MLOps infrastructure, you might end up with no customer at all.
That’s because most hospitals generally restrict patient data to be uploaded to the cloud.
Market risk: Will there be a market for the product? Will anyone want it? Will anyone pay for it? If yes, how much will they pay for it? How do we know?
As a PM you are not in charge of figuring out the pricing of the product but you must understand why which kind of customer will pay for it and at what moment?
Think about Linkedin as a product.
It is essentially free for consumers but you can upgrade your account to “Premium“. As a business you might be interested in the paid B2B products “Recruiter“ or the Linkedin advertising framework.
All theses products and features have been built by PMs (including the touch points of conversion) with the help of designers, marketers, engineers and many more people.
Competition risk: Who is already doing what you are doing and where are they going next?
How will your product be differentiated from what other startups or incumbents offer or build?
Is it a feature, a different target customer, the price, a differentiating partnership, access to an eco-system?
A PM needs to be aware of the market, competing actors as well as potentially new evolving competing technology.
Hiring risk: A PM is not responsible for all the hiring around the operation.
Yet, as an accomplished PM you may need to hire other (Junior) PMs to manage certain specific aspects of product management.
Also, when establishing product roadmaps a PM generally needs to team up with her engineering counterpart (be it the lead engineer in a smaller startup, head of engineering, engineering lead, a staff engineer, VP engineering, etc) to ensure the engineering resources to build the product are allocated.
The same goes for design and potentially research.
As you can see, this is a highly diverse set of (co-)responsibilities a PM owns.
Now let’s dig into the skills a PM needs to have to be able to execute against these responsibilities.
3. The necessary skills of a PM
There is no such thing as a degree in product management. There are certificates and some kind of diplomas but let’s face it:
Nowadays, you can get a diploma for almost anything and I have yet to find a study that proves a correlation (let alone causation) between the success of a product and the involved PMs having a “PM-diploma”.
So forget about diplomas and let us just focus on skills.
In general, to build a successful product there are three high-level requirements that need to be fulfilled by the product team (btw this is equally true for hardware and software products):
Product (building) knowledge: General know-how on how to build products and experience about the commonalities, frameworks and processes which are always similar (on a very high or even abstract level) regardless of the product.
Domain knowledge: Knowledge about the specific industry or market where you are going to launch the product.
For instance, the distribution process, supply-chain mechanisms, regulation or customer behavior can be very specific for certain industries.
Without such insider knowledge the product might be dead even before you started building.
Technical knowledge: Somebody on the product team needs to understand the technical details on how to build the product.
A PM certainly needs to have the first skill, i.e. product knowledge.
The second skill (domain knowledge) can be acquired on the job if she is new to the industry and has somebody around her who already has deep domain knowledge.
The third skill, i.e. technical knowledge, depends on the product.
If you are building a very technical product, say a new blockchain with a specific product on top of it, then you surely need to have technical know-how about blockchains.
But if you are building a product that, for example, auto-generates “terms & conditions“ for any specific company’s website using AI such as Chat-GPT, then it might be sufficient to understand what an API is without having profound know-how on deep neural networks.
But in any case a PM needs to understand how technical teams work and function.
So experience in working with technical teams over an extended period of time can be enough to build technical products.
Personally, it helps me a lot as a PM that I have programming and engineering experience.
For example, knowing what it means not being able to sleep over an entire weekend because of searching for a nasty bug until I solved it helps me a lot to sympathize with engineering folks when they seem to be shipping late.
So to conclude, if you have people other than the PM who have profound domain knowledge and technical knowledge, then by far, the most important ability of a PM is product building knowledge.
I will discuss some details of this particular skill set in the next post.
If you’d like to learn more, there are 3 ways I can help you:
Subscribe to this newsletter if you want to get actionable tips on software product management.
Email me at danielschmitter@substack.com to provide suggestions about blog topics.
Follow or connect with me on LinkedIn here.