On Hiring Technical PMs
I’ve actually come a ways on this. I used to think it felt overly prejudicial to require PMs with technical backgrounds. But as with most things, the more PMs I’ve hired and worked with, the more Ken Norton’s advice on How to Hire a Product Manager strikes me as dead on. #2 is the relevant point here:
product managers with technical backgrounds will have more success conveying product requirements to engineers and relaying complicated details to non-technical colleagues and customers
I’m not snobby about degrees, and a PM will spend ~0% of their time writing or reading code. (Although I had a good time ribbing a few years ago ribbing our engineering manager when it came to light that in the past year I’d submitted more CLs than he had. A little part of an engineering manager always dies when he’s finally forced to admit he’s more manager than engineer.) Still, having spent time writing actual product code gives you a real appreciation for how things are built and what kinds of things are easy or hard. This enables you to describe what needs to be built more precisely, as well as to ask the right questions to inform both product planning and execution.
For example, it’s invaluable to be able to look at a feature or bug and have a sense of whether it’s a 2–3 day, 2–3 week or 2–3 month effort. Not because you’ll ever generate work estimates yourself (unless you want to be exiled by your engineering team), but because if you think it’s a 2–3 day thing and an engineer says it’s a 2–3 month thing, you’re able to have the right conversation about it.
The right question is never “can you get it done faster?” It’s more like “okay, got it, 2–3 months… can you explain to me what you need to do?” Most of the time, you have an interesting conversation and you walk away better able to explain (eg, to management) why something that looks simple is in fact difficult. Some of the time, however, you learn that the thing that takes all the time and effort is not a hard requirement, and you come up with a much cheaper alternate solution. “Oh, we don’t actually need perfectly synchronized caching in this case, we can handle a couple of minutes of inconsistency.” And you just saved someone two months of work.
By the way, since the PM:Engineering relationship is usually the closest (at least at Google) and engineering is usually the hardest thing to talk about for those who haven’t done it, technical backgrounds get all the focus. But the same general concept goes for design, marketing, or really any discipline. Reading up on fonts or HCI theory (not to mention spending time wireframing and building mocks yourself) goes a long way toward being able to effectively work with a UX team.
