What is Product Management?

“What is Product Management?” is a question I will ask a PM candidate early on in an interview. Reason being “Product Management” is one of those terms that gets thrown about a bunch and generally people sort of agree what Product Management is, but never fully agree on what it is.

To arrive at my definition I want to break it down between “Product” and “Management”, and this is specifically a digital product.

Product – what you are selling and (for the most part) what people are buying¹. For a digital product in 2024 this is typically a SaaS web product, a data product or a AI product.
Management – the Webster definition – “the conducting or supervising of something”

And putting it back together Product Management is the act of conducting/supervising a “thing” that customers will buy. Which admittedly is still a fairly generic thing to say, however I think it gives some more concrete ideas to hook more specifics to.

Note: no where above does “Product Management” refer to:

project management
one specific person
roadmapping
resource allocation
and other typically product management tasks

I think it’s important to call that out as Product Management isn’t just what is on a typically job description/posting. Those for sure can be part of product management, just not the holistic definition.

To me one of the most important parts of product management that typically gets missed is the product has to solve a customer need or set of customer needs. This is an important framing as it allows for creativity and flexibly in what is delivered.

Sometimes that is taking a set of customers’ problems and boiling down to key feature sets that need to be in the product that solve the most pressing problems for all (aka going wide)

Other times it’s being nimble and delivering a narrow solution for one customer that isn’t even in the product.

As a fairly generic example let’s assume you have a product that can do “really cool things” with customer data and the “really cool thing” is valuable for the customer, however there is still the problem of getting that customer data. In order to solve that research will need to be done on customer tolerance for manual data entry, internal capabilities to offer manual data entry services, security and compliance concerns, cost/value of engineering an automatic solution, the list can go on and on. Some of that is done “in product” other times it’s a negation with the customer and/or other internal groups (like customer success or sales).

Now I’ll admit my views on Product Management have evolved through a [Software] Engineering lens. Which is also something I wanted to tackle here – both Product Management and Engineering Management have been going through changes as of late.

I don’t want to delve into “Product Management” vs “Engineering Management” if you are interested in that read Segment’s excellent article on
PM & EM: Rules of Engagement.

What I do want to tackle is recently I’ve seen Engineering abdicating some responsibilities to Product and vice versa I’ve seen Product excluding Engineering where Engineering really should have a voice. To be clear I think this is typically coming from a desire to stream line things, “[Product] is really organized best let them tackle [task]” or “[Engineering] needs time to build best not distract them”, however I think there tends to be a lot of false choice in there.

People are not binary and not every person in the same role is equally skilled at the same tasks and in the same vein not all similar tasks require the exact same people. Even if the people/tasks were interchangeable (again, they are not) the environment/timing is also a factor in who can and will do what.

If we take the above example of “a product that can do ‘really cool things’ with customer data” possible situations could be:

Customer wants to brainstorm possibilities – may make sense to include Engineering to get a broader sense of what is technical feasible.
- But maybe Product has done similar things a different companies
- Or maybe Engineering is all hands on deck with a critical bug
Customer is subject to regulations maybe makes sense for Product to hunt down requirements before bringing in Engineering
- But maybe the is already an Engineer who developed to that regulation
- Or maybe there is a compliance org that best do leg work first
Decision is customer success will help with data entry – presumable customer success was involved with that decision maybe Engineering should be there is help with internal streamlining
- But maybe there is someone in customer success who is looking to break into Engineering that can help
- Or maybe there is already an item on the roadmap to help with streamlining and that bumps it up in priority.

I’ll be amiss if I don’t mention two things that really get into the thick of Product and Engineering

Project Management – this could be another article, anybody can do it, it can be an engineer, product manager, or a myriad of other role titles.
Engineering Strategy – this has to be part of the Product roadmap, if the Product is too heavy Engineering there is not enough customer value being unlocked, if too heavy Product you open up to risk of catastrophic failures (be it bugs, privacy leaks, or engineering velocity dropping to crawl)

What I hope people get out of this is Product Management isn’t just one person’s job and in fact a specific Product Management role isn’t needed to make a successful product (although good Product Managers invaluable when it comes to successful products and a secondary take away I want people to get out of this is Product Management is hard and to be a good Product Manager is a challenging and rewarding career). It takes a team to be successful and things are not always clearly delimitated cross roles.

I think it’s an exciting time to be building products as we are in the mists of changes in the industry and I expect Product (and Engineering) will continue to evolve, especially in light of glut of AI/GenAI tools we currently have (although that’s a topic for another day)

Additional Resources:

Really people are buying help to solve a problem, however for the intent of this article we can ignore that. Also this can be applied to internal products, just the currency may be easier to articulate in terms of time and tradeoffs vs dollars and cents. ↩︎