In extremely regulated environments you would typically have someone with legal background to boil down the requirements into their absolute essence and give them to the dev team.
I work in one of those environments and we do have those people (lawyers). The next question is how should we prioritize solving for potential legal risk vs reliability risk vs new feature work. You’d expect it’s black and white, I promise you it’s not. The PM has to figure that out.
Good product managers I've worked with are better than me at navigating the domain and compliance worlds as tourists as they are tourists in the engineering side as well. David Ricardo was right, comparative advantage is a good thing.
If I consult a solicitor about data protection regulation and they tell me what I need to build to satisfy the requirements of soft opt-in under PECR, that does not make them a product manager!
No, but it's something a good product manager does for you, and with the economy of comparative and potentially absolute advantages. This let's you focus on the craft of delivery without encumberance of spending research into compliance.
I don't consider the engineering having a deep understanding of the domain and compliance to be a "encumberance". The more engineers get into the domain themselves, the more they can make deep decisions about how to build the most effective solutions.
> This let's you focus on the craft of delivery
I don't give a rat's ass about the craft of delivery! What a reductionist thing to think of engineers as "delivery machines". Me and my team mates are not a factory that simply takes input from a task master and produces code to their bidding.
I care only about one thing: solving the problem! That encompasses learning, understanding and, finally: delivery. To do that, I need to speak to stakeholders MYSELF, I need to see how they are using the product MYSELF, and any regulation I am gonna implement, I need to understand in depth. I don't need somebody to summarize findings for me, I can make my own damn conclusions.
Sure, I will ask the domain experts of their opinion, but me and my teams will decide what to build, when, and how, and do we will do it together, based on all our shared learnings, not based on what a PM told us.
The developer teams, of course. They are solving the problems, so why should they not prioritize them? They just need to have other parts of the org heard, but if you are solving it, you get to choose how to do it, in what order and with what priority.
If that's not to somebody's liking, they are welcome to prioritize and solve the problems themselves.
If the PM does that, the developer has no idea what part of the requirements is important, and won't be able to deal with it when the requirements unavoidably break each other or reality. The developer has to be there too.