Without me, developers would not know what to build. It is all industry specific, driven by business as well as compliance requirements - in several distinct regions, worldwide.
When programmers build stuff for that hey will use themselves, yes, a product manager's value is debatable. but there is a lot of stuff out there a normal coder will never use, but still has to build.
The job you describe here would be infinitely better suited to a UX engineer that has experience and knowledge necessary to build great user experiences, and a lead technical engineering architect.
The idea that engineers/UX designers can't translate business/compliance requirements into engineering/UX requirements is laughable. The truth is that they're the ones best suited to do so, because they're entirely capable of understanding both the business/compliance requirements and the constraints under which they must be implemented in UX/engineering.
our devs are centralized, whereas our product management is out there, on the ground, from the US to china, europe, japan, etc.
wanna understand sampling compliance in Italy? expense reporting in Germany? order management in Spain? EPPV in Japan? do you know what EPPV means?
there are no coders out there to cover this broad level of business knowledge.
i started in consulting, with a background in coding as well as business. worked myself up the ladder, was a system architect for global systems. then became a "product guy" - because I have all this knowledge and experience now, in my head. which you can't simply learn or read up. only years of experience can give you that.
The programmers are the ones least suited to figuring out what the product should do because they aren't the ones who are going to use it. They approach the problem from a programmer's perspective on the technical requirements of implementation, not on the user's functionality (PM) or usability (UX) requirements. Product Managers design the product from a standpoint of actual domain experience for the end customer to use.
(I say this as someone who has been both a PM and a SE.)
Essentially, yes. But with a few caveats:
- The customers doesn't communicate in "requirements". They communicate in "I want to achieve X". When they do seem to communicate in requirements, it's always because they want to achieve some X, and there might be a better way of doing that. Uncovering X and mapping it to something that's feasible and coherent with the direction the application is going is an essential part of the job.
- Ensuring consistent communication, including providing a single point of entry for the customers. Making sure that customers always receive either a firm commitment or a firm non-commitment. No "I'll look into that" which is interpreted as "It's done". No playing developers out against each other ("But your colleague promised me, I really need this tomorrow.").
- Responsibility for the big picture. If keeping the big picture is trivial, you probably don't need product guys. But after a certain degree of complexity, being able to tune out everything but the task you're working on is good for developer productivity.
- The buck stops here. A while ago our team wanted to remove a screen from the product because it carried some legacy dead weight. They went to the PMs and got the go ahead. Now, it turned out that PMs were wrong, and the screen had to be put back in after some loud calls from users (which went to client managers and PMs, not developers). Developers were held free of responsibility (and PMs did a root cause analysis). I imagine that if developers were held responsible for this error, it would increase friction as everybody would scramble to make sure they have their back covered whenever something changes.
i than build and design product that will a) fit their needs b) be useful for all other customers we have or c) won't disrupt existing customers workflow.
If that is true for your team (and I'm highly dubious) then I'd have to say you have mediocre to downright incompetent developers (being able to code does not immediately qualify someone to design and build good software). Understanding the use cases, business requirements and the user are all part of designing great software. If none the developers can manage to accomplish this, then they are going to build mediocre software regardless of what BA or PM they have on the team.
For my part I've met very few good developers who were not capable of developing a fairly deep domain understanding even in complex domains.
product management does not interfere in technical decisions. that's what the coders do. pm acts as the one, single client to the devs. they build for us.