3 ms·

programming skills are primarily useful to a Product Manager as a communication technique Huh? This whole article is a bunch of semi-circular fluff. Having a

programming skills are primarily useful to a Product Manager as a communication technique Huh? This whole article is a bunch of semi-circular fluff. Having a PM who can't code is akin to having a college-fresh MBA running a factory. Will it get the job done? Yes. Is it wise for the long-term health of the company, the fluidity of operations, and the happiness of the workers? Probably not. A PM who can't code is a PM who doesn't understand why feature A takes an hour, while feature B takes three weeks. Do you want your engineers spending stressful hours upon hours explaining how and why things are, or do you want them working?

wnight 15y ago
You can have a completely non-technical PM, I've found, as long as they still get to know their teams, the problem domain, etc... The type of person who proudly professes their ignorance of something is not cut out to be a PM. But much of what a PM does is take the bookkeeping off the backs of the developers so they can go to the issue manager and just read what pertains to them. A good programmer should never need to lie to his PM to push-back. Knowing how to put your foot down is an important part of delivering a working product. And a good PM should never need to browbeat or threaten the team. If, for instance, they feel a quick release is essential but the developer feels the product isn't stable (race conditions under customer-levels of load) neither is flat-out wrong. Even with the CEO yelling at the PM yelling at the developer they shouldn't bend - if the developer can't deliver what they been asked for they shouldn't pretend they can. But this tense situation can be solved by working with the developer to clarify requirements. Perhaps a lite-version could be released that was hard-limited below the danger zone, or with a problem feature left out or set to use offline processing to avoid the race conditions.

wnight 15y ago

You can have a completely non-technical PM, I've found, as long as they still get to know their teams, the problem domain, etc... The type of person who proudly professes their ignorance of something is not cut out to be a PM. But much of what a PM does is take the bookkeeping off the backs of the developers so they can go to the issue manager and just read what pertains to them. A good programmer should never need to lie to his PM to push-back. Knowing how to put your foot down is an important part of delivering a working product. And a good PM should never need to browbeat or threaten the team. If, for instance, they feel a quick release is essential but the developer feels the product isn't stable (race conditions under customer-levels of load) neither is flat-out wrong. Even with the CEO yelling at the PM yelling at the developer they shouldn't bend - if the developer can't deliver what they been asked for they shouldn't pretend they can. But this tense situation can be solved by working with the developer to clarify requirements. Perhaps a lite-version could be released that was hard-limited below the danger zone, or with a problem feature left out or set to use offline processing to avoid the race conditions.