Long, long ago there were times when product managers were only thinking about ‘what’ and left the ‘how’ to project managers and tech leads. Well, in some companies a separate role of project manager still exists, but it won’t be too wrong to assume that project management and some part of technical management merged with product management.

What I mean here by ‘project management’ is mostly the responsibility of controlling milestones and deadlines. Ther are other tasks within this role, but now I won’t talk about them.
Old-fashioned product managers introduced a new product idea along with design to the development team and retreated to think about some more new ideas, while the team was struggling to deliver in time. The responsibility of controlling the milestones belonged to the project manager, or sometimes engineering manager, or sometimes technical team lead. But can all these people say that what’s been done by the deadline is exactly what needed to be done? I’d say not, as their main goal is to implement the specs, and they have no previous context, history of research, knowledge of the idea’s evolution.

So, a modern-day PM — are they allowed to shun from close-to-the-ground processes and artifacts in order to stay good PM?
Let’s look at it from this point of view: let’s say the team is coming close to the launch deadline, their product is ready as close to the specs as was possible, but it turns out exactly NOT the product intended from the very beginning. Whose fault is it?
PM’s, of course. Our job is not just to present the idea and leave all the rest to engineers. Part of our job is to keep close to the team and look at every smallest deliverable, be it somewhere at the developer’s stand or testing environment. Part of our job is to validate the result — at the earliest possible moment, and make sure the material result (app, web site, whatever) really is what we want to have.

As I put it: if I wasn’t understood right (by my own opinion), it’s my fault, not the fault of those who tried to decipher what I was trying to tell them. It is my responsibility to control every step — not to demand how the steps are to be made, but to make sure we’re moving in the right direction.

So yes. I say the PM has to be as close to the development process as possible in the environment. Not to sit on top of the engineers’ heads but to help, correct and elaborate what hasn’t been expressed right previously.

Oh, and yes, some product details have to changed right in the process of development, don’t they? Because of the framework limitations, newly discovered discrepancies in the design etc. So stay close. I do.