I’ve been asked repeatedly over the last decade if having a technical background is required to be successful as a product manager. The answer is no. But it has certainly helped me to be more effective. This is a personal and situational question which has no crisp answer—but sharing some of my experiences may help you to work more effectively with, or as, a product manager with a technical background.
I don’t know if I went to school for engineering because of how my brain was wired, or if Carnegie Mellon rewired my brain for me—but I always say it is where I “learned how to learn.” How I approach learning, and how I apply different analytical techniques to synthesis, situational analysis and development of insights is driven by how my brain is wired. In product-management speak, the way I learn things is a distinctive competence, and it makes me objectively better as a product manager. I would argue that this is because of my technical background. I would expect people with similar backgrounds to have similar advantages.
The Inside Track
I tend to work most frequently with businesses that incorporate software development into developing solutions for their customers. I happen to have also spent several years developing software—and eventually leading teams which were developing software. This arcane knowledge of the secret handshake has helped me develop effective working relationships with the team members who are actually creating the product. When you do something, you learn it more viscerally than if you only read about it. Building on this deeper level of insight, which only comes from doing, is one way to develop camaraderie with the team of people creating your product.
The Temporary Crutch
In terms of what you already know, a technical background only helps for a short while. Eventually, the information you acquired will become irrelevant—and eventually it will mislead. Imagine trying to apply pre-SQL database perspectives to conversations about NoSQL and distributed data storage architectures and the ensuing release-planning activities. You can also, of course, have a bundle of technical knowledge, which is not relevant to your problem domain. Bernoulli’s equation is not going to help me increase conversion rates on a website, or help me assess the value of continuous integration.
My approach to applying the things I already know—or used to know—is to leverage that knowledge for shared context in conversation, pattern recognition when being exposed to new-to-me information and generally applying the principles of learning to whatever is in front of me. I do not try to apply the knowledge to solutioning, beyond using it to guide some directed questioning or to help with hypothesis formulation.
One of the phrases I remember from Pragmatic Institute’s training was a question from my instructor: “If you are going to do their job, who is going to do your job?” That very question helps me walk away when I start to get too far down into the weeds in discussing how we’re going to solve the problems. It is a slippery slope, especially when you really enjoy technology and secretly wish you could be coding away (or designing or testing) with the rest of the team.
Helpful, with a Twist
The crux of it is that the benefit of having a technical background does not come from participating in the technical work, but from how it helps you collaborate with the technical team. Collaboration is a soft skill, and it is the one that is broadly helped by having technical wiring.
Sometimes, we work on products that are helping our customers to solve problems in a technical domain. In these cases, being technical can help quite a bit—and may even be genuinely required—in developing an understanding of your market.
Consider, for example, developing the staffing schedule for a large hospital. You need to be able to synthesize technical problems, combining the abstract mathematical problem (the nurse-rostering problem is a classic computational conundrum) with the business appreciation for defining the “good enough” solution. In my opinion, developing insights about how to compete in this market requires you to be able to appreciate the mathematical complexity of the value proposition, so that you neither assume it is trivial nor intractable. This is a problem that people will pay to solve. It is also a problem that requires a combination of technical solution and business perspective.
At the end of the day, if you’re developing a product that is addressing a particularly technical problem, I don’t believe you can be effective without sufficient “technical wiring” in your brain to be able to fully appreciate the challenges (and opportunities) in play. One of the better (and very technical) product managers I have worked with happens to have a degree in history, but his brain was absolutely wired to be able to think technically. Demonstrated success in a technical role (or education) is a likely indicator, but an imperfect filter.
In a Nutshell
Having an existing body of technical knowledge in your head is of limited and suspect utility. Limited because it is more useful in application than in collaboration, and suspect because it will become irrelevant or even wrong faster than you will expect. I think of this as a circumstantial outcome of having a technical background—not an asset that can be directly leveraged.
But even when you’re creating products that are not “technical,” having a technical perspective can help you significantly in the process of creating those products. And that’s not because it helps you do any of the technical heavy lifting, but because it helps you work more effectively with the people who are doing the technical work.