Let’s skip right to the punchline: Yes, if you’re a product manager or hoping to begin a career in product management, particularly in a technical industry like software, having a technical background or at least a familiarity with the engineering side of things will probably benefit you significantly in your career.
But do you need to be technical to succeed as a product manager in a technical field? No.
I’ll discuss some of the many benefits of being technical as a product manager, but I first want to point out one massive red flag facing any technical product manager if she’s not careful.
One big possible pitfall of the technical product manager
A technical background is a very common path to a product management career. Many new PMs come directly from earning a technical degree—Computer Science, Electrical Engineering, Mechanical Sciences & Systems, Software Applications, and so on. Others who have already spent time in the workforce come to product management after stints in technical roles—as design engineers, for example, or software coders.
But as much as this technical proficiency can work for a product manager, it can just as easily work against her.
“Technical proficiency can be an asset for a product manager, but it can just as easily work against you if you get stuck in the weeds with your engineering team.”
We often assert here at the ProductPlan blog that one of the most important characteristics of a successful product manager is the ability to balance the often conflicting and competing aspects of her role. We even wrote an entire post on this topic, called What Makes a Great Product Manager, where we pointed out the need to maintain a balance between, for example, focusing on the tactical details of product development and keeping a watchful eye on your product’s larger, strategic objectives.
So, if you consider yourself a technical person, and you’re interested in becoming a product manager in a technical field like software, you need to ask yourself whether you want to assume the full, complex product management role—or if you’re really attracted to the idea of “going deep” into the weeds with your engineering team.
This happens more often than you might think. A technical product manager—perhaps even hired by the company on the strength of his impressive technical background or because he impressed the engineering team in his job interview—becomes too focused on the technical side of the product, because that’s where he feels most comfortable. As a result, he loses focus on his many other responsibilities, which are at least as important for delivering a successful product—responsibilities such as getting to know his user persona, communicating his product’s strategic plan to a team of executive stakeholders and keeping those stakeholders informed and enthused throughout the process, compiling and analyzing user data and industry research, etc.
As a product manager, you will need to maintain this complex balance at all times. You will need to carve out time and energy to focus on tactical matters, strategic matters, personnel and resource issues, research and data analysis, communicating with various teams and stakeholders—and, yes, delving at times into the technical details of your product.
But you need to keep the tech stuff in check, and not allow your interest in working on interesting development or engineering problems to distract you from your other equally mission-critical responsibilities as a product manager.
5 benefits of being a technical product manager
Okay, now that I’ve given you my major warning about not allowing your technical side to crowd out the rest of your PM role, let me talk through some of the reasons that being a technical product manager can greatly benefit both you and your company.
1. It makes you generally better-informed about your products and how to manage them.
Automattic, the web-development company behind WordPress, has an interesting policy for new employees. Regardless of the role the company hires you for, you have to spend your first three weeks working full-time in customer support.
Why do they do this? The company points out that it’s the best, fastest way to get new employees familiar with their products the way customers actually use them. That makes sense: Answering dozens of real-world questions or complaints sure seems like a better way to gain a deep understanding of your company’s products than just reading their marketing literature.
But the larger point here is that Automattic is helping to quickly make its new employees more well-rounded, more familiar with the company and its impact on the market than they would if they let their new employees jump immediately into their departmental silo. (Oh, and that brings up a related part of this policy: You’ll have to spend another week in customer support every year.) This experience will no doubt help these employees in their own jobs at the company, whatever they are—accounting, HR, software design, sales.
The same is true about understanding what’s under the hood in your company’s products. It gives you a more well-rounded view and can help you better identify potential issues or insights you’d otherwise miss if you had only a superficial knowledge of your product.
2. It helps you better understand development timing, resource requirements, how to prioritize your roadmap, and how to set your stakeholders’ expectations.
Another benefit to having some technical knowledge as a product manager is that it will give you a more accurate view into what will be required to build your product according to the strategic plan you’ve set out in your product roadmap.
If you understand how your product works only from a marketing or user standpoint, a lot of that product’s development will always remain a mystery to you—a black box—and you’ll have to rely on your engineers or coders to advise you on how long each component will take to build, how many people will be needed, what budget you’ll need to secure, etc.
This means you’ll often need to consult with your company’s technical teams before you can realistically craft your product roadmap or figure out how many and which epics or features you can expect to deliver in a given timeframe. That’s a huge disadvantage.
But as a technical product manager, a PM who can actually go deep and who knows what’s really involved in creating the backend details, you can get a lot closer to a realistic roadmap and plan without needing to defer to your technical department.
Speaking of which…
3. It helps you better identify when your engineers or developers are wrong (or even exaggerating a bit) in the planning or resource estimates they give you.
Let’s say you’re a non-technical product manager responsible for a technical product like software, and your development team tells you that a theme or new feature you’re asking for will take them three months to code, or will require four dedicated development resources (more than you can access right now), or that they can’t even begin for weeks because of something else they’re working on. And let’s further say you’re unsatisfied with whichever of these answers they give you.
What can you do?
If you’re not technical, you won’t know if they’re correct in their assessment. You won’t know, either, if they’re telling you a bit of a tall tale because they want to give themselves some more buffer between projects or if they’re simply negotiating with you for more time.
But if you’re technical, if you have even a general sense of what’s involved in coding the functionality you want—how long it takes, how many people, what level of skill is needed, etc.—you’ll be able to sniff out these problems and show your developers that there’s probably a way to get it done. And if they know you’re technical, they’ll be a lot more likely to hear you out.
Which leads to yet another benefit of being a technical product manager…
4. It will earn you the often critically important respect of your technical team.
As a product manager, a lot of your role will involve negotiating with various teams to get things done for your product. When it comes to development, you’ll have to advocate for your technical teams to get as much done for your product as quickly as possible.
And if you’re not technical—if you don’t know the gory details behind how the product is actually built, upgraded, what if any dependencies are involved, etc.—then your development teams are much less likely to respect you or take seriously what you’re asking of them.
They might assume they know better than you how to build your product. And they might be right.
5. It helps you better understand your market, your industry, and the new technologies and threats that are always on the horizon.
If you’re a software product manager and you repeatedly hear rumblings in your market about, say, NoSQL databases, you’ll want to know if this new technology affects your products. Maybe it has nothing to do with your product portfolio; maybe it represents a powerful new database methodology that you and your team should be looking into right now because it could become a potential competitive advantage.
Having some technical knowledge here will be valuable. You will be better equipped to spot technical developments in your industry—opportunities as well as threats—that might affect your products and your company’s bottom line.
As we’ve pointed out in lots of blog posts on this site, including this post about a product manager’s main responsibilities, as a PM you will serve as a central product information hub for people across your organization. That means you’ll need to stay as informed as anyone in your company about the competition, user feedback, market trends, and other factors that might affect your products. One of these ongoing factors is how your industry is reacting to and adopting new technologies—mobile platforms, encryption protocols, data analytics tools, etc.
The more technically savvy you are, the more comfortable you are reading your industry’s tech magazines and blogs, the more prepared you will be to properly react to these new technological opportunities and pitfalls.
What if you’re a product manager who’s not technical?
Having made a case for having some technical bona fides as a product manager, I can imagine that you might be thinking: Well, that sounds nice. But I didn’t get a technical degree in college and I don’t have any experience working in a technical field. Won’t I be at a huge disadvantage as a software product manager?
Not necessarily.
That’s because today it is easier than it’s ever been to learn technical skills yourself, without putting yourself through a formal education program or gaining tech experience on the job.
Today you can take full courses online, in your spare time, to learn mechanical engineering, software development, even product creation. Which means that if you find yourself as a product manager responsible for a technical product, and you’re feeling out of your depth in your technical meetings, you can teach yourself a great deal of the information you’ll need to walk into those conversations with far more knowledge and confidence.
Moreover, in a recent post, Product Manager Career Paths: 3 Myths Debunked, we recounted several of our interviews with product executives at highly technical companies—who came from completely different educational and professional backgrounds, some of them not technical at all.
Bottom line: It’s not necessary to have a technical background to become a successful product manager in a technical field. But it will help, often significantly, if you can display some technical prowess in your PM role. And the great news is that, even if you have no prior technical experience or training, you can pick it up yourself today more easily than ever.
[Editor's note: This article was originally published on ProductPlan's blog.]
