Do you need to be technical to be a PM?
Exploring perhaps the most misunderstood question about becoming a Product Manager (& then succeeding as one)
I am really interested in the field of Product Management. However, I keep hearing that Product Managers spend most of their time working with Engineers/Data Scientists, and generally need to be quite technical. Is this actually true? My background is in X, and I don’t think of myself as a very technical person, so this keeps me worried.
This is one of the most commonly asked & perhaps the most misunderstood questions about careers in Product Management. I’ve previously discussed a few aspects of this as part of the Q&A: Building A Career In Product Management, but I thought it’d be good to explore this topic in more detail.
I want to begin with a short & definitive answer to this question. The answer is a resounding ‘No’, you absolutely don’t have to be technical to be a successful PM.
That being said, there are a lot of nuances to unpack here, so let’s dig deeper.
What type of a PM do you aspire to be?
First of all, it’s good to have at least some idea of what kind of a PM you want to be. This includes a few things, such as:
Industry focus: e.g., are you interested in financial services, cloud, productivity tools, marketplaces, etc?
Target audience: do you want to work on B2B vs. B2C vs. B2G products?
Functional specialization as a PM: do you aspire to be a Data PM, vs. Growth PM, vs. UX PM, vs. Platform PM?
It should probably feel intuitive that the level of technical depth needed to be an ML PM working on building productivity-enhancing tools for developers (e.g., something like GitHub Copilot) will be quite different from a UX PM working on consumer-facing part of a B2C marketplace (e.g., Airbnb).
More specifically, however, there are two aspects that matter the most here, namely:
You need to be capable of understanding (& being able to clearly articulate) the technical details & context at a level that would matter to the end user/customer;
You need to be capable of navigating the technical aspects of the product you are working on insofar as there are product decisions that depend on those.
As long as you can meet the bar for both of these requirements, you’ll be fine.
What exactly does it mean? A real-life example
To give you a concrete example, I’ve spent a few years at Microsoft building deep learning-powered enterprise search for SharePoint (you can learn more about my personal journey here, or on LinkedIn, if you’re interested).
In that role, it was critical to understand the general capabilities & limitations of the underlying tech, since a) that’s what the customers cared about, and b) you needed to understand those in order to make product decisions on what to focus on, etc.
That meant learning about things like vector encoding & NLP ML models, how search retrieval works, search ranking basics, etc., as well as learning how to set up, run & analyze the results of the experiments, and so on.
What that job didn’t require, however, was knowing all the details about models’ evolving architectures, the details of how search back-end infrastructure was set up, knowing what the key codebases were, etc. In fact, getting too involved with decisions concerning any of the above would probably have been a very bad idea, even if you had had a natural inclination/interest in those areas — the main reason being, the latter were the areas in the purview of Engineers/Data Scientists that primarily required sound Eng/DS decision-making (and Microsoft certainly had the top-tier talent to make those decisions — as do other big tech companies & many startups), whereas the former areas shaped the product & thus depended on PM input.
Prioritization is always key for PMs, as is the ability to acknowledge when your input isn’t needed and trust your engineering partners to make the right choices. That’s not to say that you shouldn’t be involved at all in the areas primarily owned by your Eng/DS counterparts (it’s always good to learn about those, etc.) — but if you think you can make better decisions than your engineers on things like how to design & train an ML model, architecture choices, etc., chances are, either things are very broken at your company/division/team, or you don’t really understand the point of your role as a PM, and will only get in the way of your Eng/DS team & frustrate them to no end by doing so.
Going back to the question of how technical you need to be, the things mentioned above in my example (understanding how vector encoding works, how search retrieval works, search ranking basics, how to run & analyze experiments, etc.) that you’d need to know & have opinions about in order to add value as a PM on such a product certainly fall into the ‘technical’ bucket.
At the same time, those aren’t things that require a deep technical background — you only need ‘101/201’ knowledge for most of those topics, which can be easily picked up from a few online classes / books (and practice!)
That’s not to say that, for instance, having a technical undergrad won’t be helpful — it certainly will be — but not having it doesn’t have to be a disqualifying factor.
In fact, in my case, I credit most of the practical knowledge I have to either the online classes / books, or to the classes I took in business school (which, ironically, was a lot more useful for e.g., learning applied statistics & the intuition behind it, than my 5-year combined MSc/BSc in Math ever was).
And, of course, learning on the job is a big part of it too — Product Management in general requires continuous learning, and so you should be ready for (and hopefully excited about) that.
Different flavors of PM jobs come with (very) different requirements
To re-iterate, the types of skills you’ll require as a PM will vary widely depending on the type of PM you want to become, the surrounding context, etc.
The example above highlights that to be a PM on a highly technical product, you will indeed need to acquire some technical skills. Still, I hope it also conveys the point that even if you want to work in a product area that is widely regarded as being quite technical, the lack of formal technical background doesn’t have to be an issue you can’t get past. Instead, you can gain most of the necessary knowledge on your own, and the level of depth you need to get to should be achievable for anyone sufficiently interested in the field, and with a bit of time on their hands, within 3-12 months (depending on where you start / how much spare time you have), regardless of their previous background (note that I am, of course, assuming that anyone interested in PM roles possesses a certain level of raw intelligence expected of a successful college graduate here).
For a lot of other types of PM roles, having technical background would be even less important or useful, compared to some of the other skills (e.g., knowing how to do user research, understanding the nuances of scaling a product, etc.) — in which case, you should focus on identifying, and fixing, the gaps in your knowledge / experience wrt those, instead of trying to become more technical just for the sake of it. That’s especially true if you believe you don’t possess good communication or writing skills, in which case, I’d suggest prioritizing working to improve those above everything else, since without those skills, even if you somehow get a job, it’ll be very hard for you to survive & thrive on the job.
Where are you in your career?
In one of my previous posts (Breaking into Product Management: key 'entry points' into the field), I discussed various common entry points into the field of Product Management.
Perhaps a bit ironically, the timing of when you decide you want to become a PM can have an outsized influence on how important (or not) being technical is going to be.
Associate Product Managers
One of the common entry points into the PM field these days is becoming an Associate Product Manager right out of college, and growing as a PM from there.
At that level, companies are mostly looking at smart, driven individuals with good fundamental education that they can teach how to be great PMs.
Obviously, as a new grad, you don’t have any ‘specialization’ yet — and that’s completely fine from the APM programs’ perspective since those programs are looking for people who can be trained as generalist PMs first (and then in a few years, some might develop a specialization, while others might remain on the generalist PM track).
Note that APM programs can be very competitive. So, if you pose a question of whether having a CS degree from Stanford can help you get hired as an APM at Google, the answer is going to be ‘yes, of course’.
But again, remember, those programs are not bringing you in for your specialized skills — and also, people who run them are very much aware of all the different types of PM roles (& the corresponding skills those require) that exist.
What this means is that in every APM class, you probably see people from a wide variety of backgrounds: some will have Engineering majors, while others will come from Econ, Business, or Liberal Arts backgrounds (even Google in its heyday of focusing on PMs being technical used to periodically hire people with BA in Philosophy, and similar degrees, as APMs).
Overall, I am going to argue that being technical is absolutely NOT a prerequisite for joining an APM program right out of college.
Joining Product Management field as an experienced hire
Compared to joining an APM program out of college, the situation becomes a bit different if you are trying to break into Product Management as an experienced hire.
At this stage, you are inevitably competing against people who already have several years of PM experience under their belts — and so, it becomes important to prove that you can do the job well, as well as to demonstrate a clear interest & commitment to the field you’re trying to break into (by field here, I don’t mean Product Management in general, but rather something a bit more nuanced — e.g., you want to be a PM for FinTech products, etc.)
Depending on the product/area you’re vying for, this can mean that having technical background / demonstrating technical proficiency can become a good differentiating point.
As mentioned, it’s likely that you’ll be competing against at least some experienced PMs at that level. Chances are, however, that some of those folks will have functional experience, but not area-specific experience (e.g., they worked as a PM before, but in a different product area). If that’s the case, you can demonstrate your interest & commitment by taking extra steps to acquire some area-specific knowledge.
Above, we discussed that a lot of PM jobs don’t require you to be technical in general; this remains true, so if you are after UX-focused or Growth PM roles, it’s unlikely that learning how to code or learning about ML would help you there. Similarly, it’s possible that you already have some useful skills from your prior jobs that would be useful & allow you to differentiate yourself from the competition.
That being said, I’d argue that for experienced hires, the benefits of becoming at least somewhat technical are higher than for e.g., college hires, if only because many non-technical people won’t be focusing on that & also because it can be a good way to demonstrate your commitment to the field of your choice.
Here, I’ll again use a personal example as an illustration. After graduating from business school, I originally joined a 1-year rotational program in Microsoft Azure’s Product Marketing. After 6 months, I knew that I wanted to transition to Product Management though, so I took a few online courses around AI/ML to develop some basic understanding of technology and tried to build a few simple things / wrote some articles of my own.
While none of these activities made me particularly proficient with AI on their own, they served as a very useful demonstration of my interest in the field. I then used that to network my way around Microsoft, scheduling informal coffee chats with various hiring managers working on AI products, until I found a team that was willing to interview me & ultimately extended me a job offer.
The interesting — and often overlooked — nuance here is that even for experienced hires looking to become more technical, the bar to do so doesn’t have to be set too high. In many cases, taking a few classes, or reading some articles / books might be sufficient to get a basic understanding of the space, after which you can leverage that newly acquired knowledge to start having discussions with various folks working in the field, and hopefully, eventually, find your way in (and then continue learning on the job).
And as for the folks with completely non-technical backgrounds, taking the effort to do some of the above (or perhaps going beyond that & taking a few college classes or doing a Master’s at some point, if you want to go all the way in) can be even more impressive & can often provide you with an excellent & durable differentiating factor. In my career, I’ve encountered quite a few people who studied things like English Literature at college and are now working as PMs at top-tier tech companies, and I can tell you from experience, that people around are always impressed by those examples, and can certainly appreciate the effort & determination it takes to make a hard turn in one’s career.
The key point here is this: as an experienced hire looking to break into the field of Product Management, you still don’t have to be particularly technical — but spending time learning the space & acquiring some technical skills can go a long way to help you prove your interest & ultimately secure a job.
Summary
To re-iterate, the answer to the question ‘Do you need to be technical to be a PM?‘ is most certainly ‘No, it’s not a hard requirement’.
So, if you’re currently a sophomore in college who has a vague interest in Product Management as a career, but you aren’t sure if you are ready to commit to a CS major, that’s perfectly ok. There is more than one path to becoming a PM, and while having a CS degree will certainly help, a person with a degree in Liberal Arts but also a genuine interest in technology (which can be demonstrated in a variety of ways), great communication & writing skills, and a bit of persistence, will likely have an easier time recruiting for PM jobs, compared to someone who believes that just having a CS degree from a top-tier school automatically entitles them to a job in the field.
Similarly, if you’re looking to break into Product Management space as an experienced hire, you don’t need to go back to grad school for an MSc in Computer Science/Statistics/etc. Rather, your time will be better spent on assessing your strengths & weaknesses, thinking through why you want to become a PM & what types of products you want to be a PM for, and then focusing on showing a clear interest in your chosen area (filling in specific gaps as needed — which might, or might not, have anything to do with technical skills) & networking your way in.
If you’ve been previously wondering if being technical is a critical condition of becoming a PM, hopefully, this post helps alleviate your concerns a bit and also provides you with some food for thought.
And as always, if you have some anecdotes from your personal experience or any other feedback/questions you’d like to share, let me know in the comments section below!