First of all, I think that the title "product manager" is not a very good one, and is actively harmful. While it is technically correct, the word "manager" in most people evokes the idea of managing people, and there is a very short step from there to seeing PMs as ones who "manage" everyone involved with the product development. "Product owner" is not much better either.
But we don't have a much better term, so PMs it is.
For all practical purposes, the amount of features a software product can have implemented is virtually unlimited. In reality, features can only be added over time, and the role of product managers is to guide the prioritization by making product decisions. Long time ago, in a talk at a startup event, I compared PMs with the people being quartered in medieval times [0]: the product development process is pulled in different directions by various "horses" - groups more or less directly involved in the development and use of that product, and the PM's role is to balance those horses and prevent any one of them of dragging the whole thing in its direction. (I have identified those horses as, respectively: sales, marketing, end users and engineering. This is a common arrangement, but others are possible in some environments.)
Ultimately, the PM should have enough understanding of particular interests of each of those groups to be able to make informed decisions. Sometimes, the priority will be to make the product easier to sell (e.g. add this feature this potential customer is asking for); at other times, the priority will be to resolve some technical debt to make deployment faster; and so on. Obviously, that understanding does not come from vacuum; it requires talking to the representatives of the all of the "horses" and gathering all the necessary information.
In practice, it is common - as some other comments have mentioned - for the PMs to succumb to the pressure of the "business" side of the equation (sales and marketing). As a technical lead, I have always made a point of working together with the PMs and help them keep that balance.
In my ideal world the role would be called something like "product developer" with the responsibility to develop and articulate a clear vision for the product (with a holistic understanding of "product").
"Product Designer" is becoming a more common role at big companies these days, and tends to have a similar role to a traditional PMs. Usually from a designer background.
Product developer (or Product Engineer since we use the word engineer everywhere). Compare team A = {software engineer, product engineer, design engineer, qa engineer}, and team B = { software engineer, product manager, design engineer, qa engineer }. Team A screams "all team members collaborate the same way when it comes to build a product". Team B screams "there is 1 manager, and the rest are not"
Does "Product Lead" evoke similar (negative) thoughts for you? I find that title (and anything "... Lead") carries the least connotation.
And IME, in an org that has PLs, PM becomes "one who manages PLs" - otherwise, if there are PMs but no PLs, I get the impression they are mostly Project Managers, rebranded to Product Managers, but without any of the Product responsibility or thought.
> at other times, the priority will be to resolve some technical debt to make deployment faster; and so on
It's interesting you mention this. In my experience, PMs have only owned end-user experience, they come up with end-user project prioritization. The consolidation of asks from various departments was instead done by dev managers/directors/VPs. So for example, a dev manager decides between a customer-facing feature and some tech debt to make deployments faster - contrasting short term deliverables with long term velocity of the team.
> they come up with end-user project prioritization
Then they have failed from the beginning. Technically, everything you do affects end-users - including faster deployments - although in some cases that effect is more obvious than in others.
In a perfect world, each product (or, in a complex system, a well defined subset of features within a product) should have a dedicated representative of each of the "horses", who should agree on the priorities - with the product lead (thank you @Jenk!) guiding the process and helping resolve the conflicts.
> Technically, everything you do affects end-users - including faster deployments - although in some cases that effect is more obvious than in others.
I agree with this. This is why the dev managers/directors/VPs own the _delivery_ of the business goals for the year. They balance the customer-facing improvements with internal improvements which affect development velocity (deployments, ops, how easy is it for new employees to onboard onto a code base, how easy is it for someone with <2 years experience on a codebase to ship a feature, etc.).
So PMs in collaboration with dev managers own _what_ customer-facing improvements to deliver, and the responsibility of _how_ to deliver and the actual delivery falls on the dev managers.
I'm not proposing this as a new model, I'm saying this is what I've seen been followed in some companies.
First of all, I think that the title "product manager" is not a very good one, and is actively harmful. While it is technically correct, the word "manager" in most people evokes the idea of managing people, and there is a very short step from there to seeing PMs as ones who "manage" everyone involved with the product development. "Product owner" is not much better either.
But we don't have a much better term, so PMs it is.
For all practical purposes, the amount of features a software product can have implemented is virtually unlimited. In reality, features can only be added over time, and the role of product managers is to guide the prioritization by making product decisions. Long time ago, in a talk at a startup event, I compared PMs with the people being quartered in medieval times [0]: the product development process is pulled in different directions by various "horses" - groups more or less directly involved in the development and use of that product, and the PM's role is to balance those horses and prevent any one of them of dragging the whole thing in its direction. (I have identified those horses as, respectively: sales, marketing, end users and engineering. This is a common arrangement, but others are possible in some environments.)
Ultimately, the PM should have enough understanding of particular interests of each of those groups to be able to make informed decisions. Sometimes, the priority will be to make the product easier to sell (e.g. add this feature this potential customer is asking for); at other times, the priority will be to resolve some technical debt to make deployment faster; and so on. Obviously, that understanding does not come from vacuum; it requires talking to the representatives of the all of the "horses" and gathering all the necessary information.
In practice, it is common - as some other comments have mentioned - for the PMs to succumb to the pressure of the "business" side of the equation (sales and marketing). As a technical lead, I have always made a point of working together with the PMs and help them keep that balance.
[0] https://media.hswstatic.com/eyJidWNrZXQiOiJjb250ZW50Lmhzd3N0...