4 ms·

Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this

Don’t you find that formulating requirements optimally often benefits hugely from, or requires, technical understanding of what might be possible, and that this understanding is usually absent, by definition, in a PM?

crdoconnor 9y ago
It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills). The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge. The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.
- Myrmornis 9y ago
  Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions. I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.
dragonwriter 9y ago
Formulating/eliciting requirements is aided by technical knowledge not so much in understanding the potential solution space (though that has some value) as in knowing what questions implementers are likely to need to have answered, so that you can both provide a good starting point (it's still going to be iterative) and avoid doing unnecessary work or overspecifying in a way which constrains implementation inappropriately. But if you have non-differentiated team roles, developers should be doing that, not the PM, and if you differentiate roles, analysts and not the PM should be doing it. Product (or project, either way) Management is a distinct skillet from business/system/domain analysis, and your PM has no more business doing the analysts work than coding. The PM has an oversight role and might ask questions to refine the analytical work product just as they might on a demo of a software product, but they aren't the person who should primarily doing the work.

crdoconnor 9y ago

It depends on the product, but probably not. If it's a very technical product where the customer is also technical then yes. If it's a user-centric product then I'd much rather they just had domain experience (and maybe UX skills). The best PM I ever had was non technical, had no UX but had significant domain knowledge, and was pretty clear on the limits of his knowledge. The worst PMs I've worked with are the ones that had a little bit of technical knowledge - just enough to be dangerous - and tried to direct the team to implement a half-baked solution where, more often than not, the actual problem they were trying to solve was shrouded in mystery.

Myrmornis 9y ago
Yes, it's that last scenario that I particularly have in mind. PMs are typically led to believe that they should acquire some technical understanding and furthermore that they will be better respected if they do. This leads, as you say, to poorly designed solutions. I'm not personally convinced that requirements-gathering is an inappropriate activity for an IC engineer.

dragonwriter 9y ago

Formulating/eliciting requirements is aided by technical knowledge not so much in understanding the potential solution space (though that has some value) as in knowing what questions implementers are likely to need to have answered, so that you can both provide a good starting point (it's still going to be iterative) and avoid doing unnecessary work or overspecifying in a way which constrains implementation inappropriately. But if you have non-differentiated team roles, developers should be doing that, not the PM, and if you differentiate roles, analysts and not the PM should be doing it. Product (or project, either way) Management is a distinct skillet from business/system/domain analysis, and your PM has no more business doing the analysts work than coding. The PM has an oversight role and might ask questions to refine the analytical work product just as they might on a demo of a software product, but they aren't the person who should primarily doing the work.