Recently, the CrankyPM was in top form with her post about the 6 Types of Software Engineers. That kicked up an interesting response from a developer, who attempted to classify the 4 Types of Product Managers. The response post re-raised the age old Product Management qualification question: “How Technical Should a Product Manager Be?”
There are two big philosophical battles for Product Manager qualifications: level of technical competence, and level of domain expertise. Arguments for more technical include:
- Less likely to be B.S.’d by development
- More easily builds rapport with development
- Understands what is possible
Arguments for less technical include:
- Won’t be tempted to get “in the weeds.“
- More outside-in than inside-out focused
- Doesn’t filter requests to development based on own biases of what is possible
I actually started my career as a developer. To the point of the article linked above, I wasn’t a “guru,” but I sought to get out of development because I didn’t want to always be implementing someone else’s vision. I am thankful for that experience today because I do feel like it enables me to speak with developers more on their terms and relate to the challenges that they face. I’m not just a PHB saying “here’s the date – make it happen!” It helps, and as a PM having a good relationship with your team is important. However, it also leads to one of the biggest myths of Product Management…
“Being Technical Enables me to Know When Development is B.S.ing the Schedule.” It doesn’t matter how good your relationship with development is, you don’t know if they are padding the schedule (or rather, how much). Most development teams have no idea of how long a feature will take to build. Even if they did know exactly, unless you are in the code and are familiar with everyone’s workload and skills you’re not going to know.
There are at least two ways around this problem: Evidence based scheduling, which looks at past performance against projected schedules as an indicator of how much to trust a developer’s estimate, and Agile, where you can lock in dates and flex scope instead (which just shifts your problem from dates to scope).
The other knock against being too technical is that you will filter requirements into development based on your own biases of what is possible. A Product Manager should not know or care about how a solution is implemented, only the time and cost to fulfill the requirement. If the requirement is “The lawn shall be cut to 2.5 inches above ground level every 2 weeks” do we care if the solution is a lawn mower vs. a billy goat vs. 75 developers with scissors? No!
It is the job of development to tell us how much something costs, and our job to go into the equation assuming anything is possible. “Man on Mars?” Sure – 100 Trillion dollars and 35 years! “100 MPG car?” 15 Billion dollars and 7 years. “Invisibility cloak?” OK, some things aren’t currently possible (yet). But put in the requirement, because developers get off on a challenge!
Another way to get accurate info from Development is trust. If you have a good relationship with the Alpha Dog developer, they will tell you how confident they are in an estimate or how much they are padding. But beware – I’ve seen junior PM’s turn around a give this info to management thinking that it will get them recognition. Worst. Decision. Ever. The VP hears that the schedule is padded 3 weeks, trims the timeline by the same, and your bridge with Development gets burned down. Poke and prod for details, but keep it “in the family.”
A final note on the “technical” product manager: every minute you spend talking to a developer is a minute you are not spending listening to a customer or potential.
How technical do you think a PM needs to be?