I can actually kinda sorta agree with that person - but only under several conditions.
First, in keeping with this article, that "product guy" shouldn't have any programmers reporting to him. I can absolutely work with a product guy on my team, even when that guy has no technical background , assuming that he's someone who works alongside me - and not someone to whom I report.
Second, the less technical a PM is, the more I expect them to defer (within reason) to the programmers and other "tech types". If I tell them that a task will take all week, I don't mind them asking me for a high-level explanation. But once I've given that high-level explanation, I don't wanna hear them continually challenging why this takes so long and continually asking me if it couldn't be done a little faster. Also, if someone is truly non-technical, then they need to be more aggressive about pulling in the tech guys whenever planning is being done. In other words, don't come back from a big quarterly-planning meeting, held with tons of senior leadership and no technical people, and then tell me exactly what the tech guys are gonna accomplish in the upcoming quarter.
Third, non-technical product guys are only appropriate in certain environments. For example: If we have a large, mature app with many features to be learned from the front end, I don't so much mind a non-tech type being that person who knows all the features in-and-out and knows all the client's priorities - but doesn't know anything about the technical underside of the project. But if we're doing a big new greenfield project, perhaps creating some kind of functionality that goes beyond your "standard" web/form-based UI, then it's gonna be a lot more difficult to deal with a product guy who has no idea what it takes to put such things in place.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
100% agree with this. I was aghast when, during my interview for my current position, I asked a product guy:
"So I assume you're from a technical background, right?"
to which he answered to the effect of:
"Nah, that's not necessary for product roles"
Yikes 😳
I can actually kinda sorta agree with that person - but only under several conditions.
First, in keeping with this article, that "product guy" shouldn't have any programmers reporting to him. I can absolutely work with a product guy on my team, even when that guy has no technical background , assuming that he's someone who works alongside me - and not someone to whom I report.
Second, the less technical a PM is, the more I expect them to defer (within reason) to the programmers and other "tech types". If I tell them that a task will take all week, I don't mind them asking me for a high-level explanation. But once I've given that high-level explanation, I don't wanna hear them continually challenging why this takes so long and continually asking me if it couldn't be done a little faster. Also, if someone is truly non-technical, then they need to be more aggressive about pulling in the tech guys whenever planning is being done. In other words, don't come back from a big quarterly-planning meeting, held with tons of senior leadership and no technical people, and then tell me exactly what the tech guys are gonna accomplish in the upcoming quarter.
Third, non-technical product guys are only appropriate in certain environments. For example: If we have a large, mature app with many features to be learned from the front end, I don't so much mind a non-tech type being that person who knows all the features in-and-out and knows all the client's priorities - but doesn't know anything about the technical underside of the project. But if we're doing a big new greenfield project, perhaps creating some kind of functionality that goes beyond your "standard" web/form-based UI, then it's gonna be a lot more difficult to deal with a product guy who has no idea what it takes to put such things in place.