Do I need to be technical to be a Product Manager?
One of the top questions I get from aspiring Product Managers is “do I need to be technical?”
Many say yes. Ken Norton mentioned it as these second thing he looks at in how to hire a Product Manager, with a good explanation of why. Microsoft and Google also tend to look for CS grads for PM roles. Industry leaders saying yes mean that many startups say yes, too.
Historically, I’ve erred on the side of “I’m not the best person to answer that question.” I hold an Electrical & Computer Engineering degree, so I don’t see what it’s like to be a “nontechnical” person. But honestly, you wouldn’t want to hire me as a Software Engineer. In fact, compared to many of the PMs I’ve worked with, my skill set is softer, despite the degree. I often feel like I checked the “technical” box by getting my degree, but it hasn’t been necessary to do my job.
But, I’ve changed my mind. I have an answer. You don’t need to be technical to be a PM. You just need to wish you were. If you’re asking me the question because you’re nervous about getting a job and learning everything at once, you’ll be fine. If you’re asking me because you want to avoid code at all costs, you should pick another field.
I’ve come to this conclusion during my time at HBS. I have whiplash here. Before, everyone was more technical than me. Suddenly, the people around me have a completely different skills. We examine income statements. We talk about feelings. We present strategies.
When we do need someone to talk about something technical, I’m the one to do it. Experience purchasing 3D printers? Me. Experience using milling machines? Me. Experience building circuit boards? Me. The only person who thinks it’s fun to sit and make the same circuit board for eight hours? Still me. I haven’t changed. My context changed, and I went from being a “soft skills” person to a “technical” person.
Simplified, it looks and feels like this like this:
I started thinking of this as “technical” and “fluffy” sides of the continuum. Neither are meant to be pejorative, but I’ll admit I have an internal bias towards valuing technical things.*
So the first part is that I’ve realized is that in the great scheme of things, I’m more technical than I thought. So are many of the PMs that don’t have CS degrees and consider themselves “non-technical.”
The second part is I’ve gotten a chance to see a bunch of “non-technical” people work. We did a simulation earlier this week where we made circuit boards. The point wasn’t learning about circuits — it was simulating process in a factory operation. Most people had never made a circuit board before.
Still, some of the people around me were curious about the technical pieces. What are these things called? What does a capacitor do? What changes if the LED is on or if it’s blinking? Why does it matter which direction we put it in in? What is this chip? Why do things go in this way? How does it work? Some of the people around me weren’t as curious.
There’s no value judgment on this. We couldn’t have run a factory without people figuring out our cost flow and break even. We couldn’t have run a factory without people coordinating our process, and delivering components. Every team needs many roles, and not everyone should be into the technical details.
But if I were a PM hiring manager, I’d look at the people who were curious about how the components worked. First, they weren’t trying to be in charge, they just wanted to get the job done. Second, they’d ask the same questions about code that they asked about circuits. “Why do we have this bug?” “Why is this the right architecture?” “How can I check in my own changes?”
I don’t think it matters how far down the “technical” line you are when you start. I think it matters how curious you are about the technical things. That curiosity will continue to drive you down the line. Someday, you’ll hit whatever place we’ve defined as “technical” — or at the least you’ll hit the place you need to do your job well.
That sort of curiosity led Emily from Kickstarter’s community team to Engineering team. The same curiosity led Kickstarter team member Ian to start writing his own code, even though he could have moved to the Product team without it. That curiosity means Joshua wants to learn how to code and do small projects, even though he could just invest in “PM” skills.
So, no. I don’t screen PMs based on if they’re “technical” or not. I screen PMs based on if they’re curious about how things work. They’ll be “technical” soon enough.**
* I think this could be generalized into “ideas focused” to “implementation focused,” outside of the technical context. For those who don’t know, Olin is my undergraduate institution.
** The converse of this is it also betrays who I don’t want to hire. I’ve talked to Management Consultants who want to get into PM, but “don’t want to have to learn the technical things.” If you aren’t curious about it, you won’t be good at PM.