I'm a dev, having moved into product management quite recently.
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.
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.