Product Management Defined - For Non Product Managers
I’m often working with people who are interested in becoming a Product Manager, who are new to working with Product Managers, or who are relatively new to Product Management as a discipline. In these cases, it’s useful to have a clear concise description of what a Product Manager is/does to share - the mission of the Product Manager and their core job duties.
The Mission
I’ve always liked the description from Marty Cagan, a founding partner of Silicon Valley Product Group, “The job of a Product Manager is to discover a product that is valuable, usable, and feasible.” As far as mission statements go, that’s a pretty good start. It focuses on the act of discovery and less so on the creation. Implied is the understanding that the act of creation is a form of discovery. Still, I think we can do a bit better.
The Missing Key Risk
There are key four risks we deal with in Product Management: user value, usability, feasibility, and viability. Our first mission modification is to make sure we acknowledge all four of these by adding that the product we discover is viable.
The Context of the Product
The product itself is usually bounded by the constraints of the company that creates it. The company may have a particular overall vision or mission. There may be specific goals that the problem is meant to help the organization achieve. Even if the company is founded out of a particular product, that product is meant to address a particular market, dealing with particular problems. Products aren’t everything to everyone. And so, in a practical sense, most Product Managers do not have the freedom or mandate to find any ol’ product that is viable, valuable, usable, and feasible. So let’s make sure we acknowledge that the product we want to build is aligned to our goals; at least when it comes to working on someone else’s dime.
For Whom we Advocate
If you know anything about Product Management, you probably know that they are the official user advocate. Sure, there may be other folks who advocate for the user - Product Managers don’t have a monopoly!
Brief Aside: You’ll often find guidance that a Product Manager should be “customer centric” or is the customer advocate, rather than the user advocate. This is not strictly correct. There are plenty of products built where the customer isn’t the user. I’ll write a separate article on this, as it’s more nuanced than appropriate here. Suffice it to say, when the people who pay you are different from the people who use the product, your customers are not your users. Similarly, when your product’s means of generating revenue isn’t the users of the product (ad driven products or data plays), your customers are often not your users. Product Managers must advocate for the user - even at the occasional expense of the customer; this is a matter of professional ethics for the Product Manager.
We want to make sure our mission includes for whom we are advocating, and for whom we chiefly work. After all, there can be little ethical value gained for a business without value provided to the users.
A Risky Perspective
Finally, there’s a little bit of reversal to be done. In many circumstances, Product Managers work on products not of their own making or design. In those cases, there may simply not be a truly successful product to be made. And so, Product Managers must take the perspective that they are reducing the risk that a given product or concept might not be viable, usable, valuable, or feasible.
Compiling our New Mission for Product Managers
We’ll take our four risks, our focus on discovery, our context, and our user focus to arrive at the mission statement.
Product Managers are chiefly responsible for discovering a product that is viable, usable, valuable, and feasible. They do so through the lens of the business mission and a focus on improved user outcomes to continuously reduce the risk that the product isn’t viable, usable, valuable, and feasible.
The Job
So now we know the mission of the Product Manager; but what do they actually do? Let’s try to answer this with a relatively succinct description. The truth is that a Product Manager is often a bit of a polyglot. They can do a little bit (or a lot) of many different domains of the execution work involved in building products. This often means they’re asked, or feel compelled, to do that work. At best, that’s sometimes necessary non-core work for a Product Manager. At worst, it’s a trap and a distraction letting teams focus on building the wrong things beautifully instead of staying on mission.
The Core Work
So what is truly core? In a non-exhaustive nutshell, this is it…
Defining and refining product vision, strategy, and objectives.
Overseeing the build/test/learn cycles.
Consuming and coordinating inputs from users and stakeholders (everybody and the mayor) to determine the right problems to solve, the right ways to solve them, and then continuously improving on those solutions.
Maximize user outcomes (valuable, usable) while optimizing (not minimizing!) the difference between output cost & impact value (feasibility, viability).
They set a direction and break down how to get there. They collect insights and inputs from everyone who matters to the product and then use that information to prioritize the right problems that maximize our chance at success. They do this as optimally as they can, ideally through some mechanism for continuous feedback.
Putting it all Together.
When we combine the Mission statement with our core work, we end up with a fairly concise and surprisingly complete description of what a Product Manager should be doing. Of course, you’ll see a fair amount of variance based on individual understanding, preferences, team make-up, team needs, and the occasional wildly ill-informed manager or leader. Still, this should be your north star for Product Managers. If you’re aspiring to be one, this is what you’ll be and do. If struggling with your identity or focus as a Product Manager, I hope this gives you a solid base to reorient your work and focus. And, if you’re new (or old) to working with Product Managers, I hope this gives you a clearer picture of what they’re really there to do for / with you. Everything else is debatable.
A Few Misconceptions about Product Management.
There are boundaries on the space the Product Manager may work in, such as an existing product, an existing vision or mission, or other constraints of the company. This means that some ideas of what a Product Manager is/does and what makes a good Product Manager should be re-examined.
Idea: Product Managers are only successful if their products are successful. This is ridiculous. There’s a not so small part of me that thinks this is perpetuated by the ego of whomever had the underlying idea for the product. Good Product Managers minimize the risk a product will fail, but they can’t prevent it. There are plenty of failed products built by great product managers. Success for a Product Manager isn’t actually product success - though this is desirable.
Idea: Product Managers are idea generators. This may be true, and certainly helps. But a more correct understanding here is that Product Managers are curators of ideas. They’ll operationalize the collection and prioritization of ideas that are vision and mission aligned. There is no requirement that the idea comes from the Product Manager for a Product Manager to be successful.
Idea: Product Managers Exclusively coming up with new products. Instead, they spend a lot of time refining and improving existing products. For many Product Managers, this is most of their time.
There are many more misconceptions I could list, but these three are fairly strongly misaligned with our new understanding of Product Management and are worth special mention.
All those other titles…
Given that we’ve just finished clearly defining what a Product Manager is/does, I want to mention that not all roles that mention Product and Manager in the title are actually Product Manager roles. Actually, quite a few JDs I see that are titled for a Product Manager aren’t written for Product Managers either. Look for a post on that soon.
