Been thinking a lot about this - right now I run eng for a pretty broad product in healthcare, and there is overlap between eng and product.
In your case, it sounds like you have crappy product leadership. This is _way_ too common.
You need a cohesive product vision from the top down (VP/head of product), which they communicate to their team of PMs. The head of product needs to ensure that their team can make the correct product decisions. This means guidelines on where the product is going, what the company prioritizes, and how products inter-play/work together.
With an actual vision from the top down, these calls which your PM team bicker on should become easy.
An engineering analogy: the CTO/lead architect sets the standard for the direction of engineering, its services, etc. This is followed by everyone in the engineering org (hopefully) with alignment and without bickering. This SHOULD happen for product, too.
Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.
You could probably reach out to your engineering leader and have them coach the head of product here. After all, that's the engineering leader's role - making sure their peers make the right decision and remove blocks from you, the engineer.
Regarding overlap, a good PM should amplify engineering. You might be a product focused engineer, but trust me: an engineering team cannot and should not be focused on writing user stories, performing research, and deciding the larger impact of features alongside their regular job of executing with code.
> Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.
To expand on this, there has been one defining difference in good companies and bad companies I've worked for.
In good companies, everyone has expertise. Your PM can talk about details. Your director can talk about details. Your VP can talk about details. They do this because it's culturally expected that they know this. So they spend enough time to familiarize themselves and do normal paper-pushing responsibilities.
In bad companies, that's just... not there. If you ask anyone of those roles about details, they don't know and can't speak intelligently.
Consequently, in the former, you get much smarter decisions from all players. In the latter, you get ignorant decisions because there's less shared knowledge.
The strangest thing is that it seems more cultural than training / education. Either the company has this expectation of its people, or it doesn't. If it doesn't, no amount of degree will paper over that. If it does, it doesn't matter if your people are sharp but lack degrees.
In your case, it sounds like you have crappy product leadership. This is _way_ too common.
You need a cohesive product vision from the top down (VP/head of product), which they communicate to their team of PMs. The head of product needs to ensure that their team can make the correct product decisions. This means guidelines on where the product is going, what the company prioritizes, and how products inter-play/work together.
With an actual vision from the top down, these calls which your PM team bicker on should become easy.
An engineering analogy: the CTO/lead architect sets the standard for the direction of engineering, its services, etc. This is followed by everyone in the engineering org (hopefully) with alignment and without bickering. This SHOULD happen for product, too.
Really, I've noticed that at upper management this is literally your job: ensure that people make the right decision, whether they're your team, your peers, or upwards to the CEO.
You could probably reach out to your engineering leader and have them coach the head of product here. After all, that's the engineering leader's role - making sure their peers make the right decision and remove blocks from you, the engineer.
Regarding overlap, a good PM should amplify engineering. You might be a product focused engineer, but trust me: an engineering team cannot and should not be focused on writing user stories, performing research, and deciding the larger impact of features alongside their regular job of executing with code.