Technical Aptitude: What really matters for Product Managers
Background
One of my favorite things is finding someone who has the potential to be a great product manager that has either never heard of or considered the role before. I’ve written previously that opening up your search criteria to focus on what actually predicts success in the role will allow you to look beyond just engineering and support to find great candidates.
When I meet people who have heard of product management, but never considered ever pursuing a career in it, the usually reason I hear is “I never considered being a product manager because I didn’t go school for engineering” or “I’m not technical enough.” As we’ll discuss in this article, there certainly is a minimum bar of technical knowledge and appreciation that is required to do the job well, however it varies a lot by target customer and product. I would assert that more than half of the people ruling themselves out for not being technical enough actually would do just fine in the right setting.
What does Technical Aptitude for Product Managers Mean?
Generally this topic focuses on the details of the technology used to build the product itself. What software languages are used, what are their unique capabilities and constraints, where is the product deployed (cloud, mobile, etc) and what are the unique capabilities of those environments. All of this is of course very important, and to be a successful PM you need to have a handle on most of these topics.
However, I wouldn’t say understanding the nuances of development are even the most important part of technical aptitude for product managers. The other side of the coin is being technically fluent enough to fully understand your customer, the technology they use to do their job, and the pain points that presently exist for them. This one doesn’t get as much mention as the tech stack stuff, but I honestly think it’s a bigger deal for PMs. Let’s dig into both a bit more to understand why.
Understanding the Technology Used by Your Customer
It’s 2023, so whether you realize it or not, everyone uses a ton of technology to solve problems in their daily lives. The complexity and quantity of the technology ecosystem used by your customer does vary quite a bit, and primarily along two axes:
Target Customer Company Size (Consumer, SMB, Ent, etc)
What role does the customer have?
As you can see from the figure below there is a spectrum for both of these, with the least technically complex situations at the left and the most at the right:
They can move independently, so it really makes the most sense to lay them out together in a grid like this:
If you are trying to figure out whether you are “techy” enough for a particular PM job, you should really evaluate yourself based on the target customer you’ll be serving. If you are building for non-tech savvy consumers, then you probably don’t need to worry much (and the nuances of your front-end code choices probably matter more). On the flip side, if you are building for a developer within a large enterprise, you have an extremely technical customer that has to operate in one of the most complicated environments for security, privacy, access control, and compliance. Additionally, as you move up in company size you are more likely to have lots of point to point integrations between your app and others that you’ll need to stay on top of. Nowadays with awesome SaaS integration layers like Zappier, Vendr, and others, even small businesses may have 20 apps in their environment that you need to be aware of and play nicely with.
Understanding the Technology Used to Build Your Product
This one gets all the attention, and it is still important. I might veer slightly from the opinion mainstream PM thought leadership on this topic and say that you need to be interested in technology, someone who can learn new tools and tech quickly, and is able to build a functional model in their head about the technology choices the team is making to drive better decision making. Effectively, you need to understand what’s going on and why, and what’s possible, and why, but beyond that, knowing how to do it yourself isn’t an automatic edge.
You do not need to have a CS degree, nor do you need to have been a software developer in a prior life to be a successful PM. As we discussed in the prior section, it may help a lot, or even be required for some PM roles with technical customers. However I’ve also seen many people with technical backgrounds struggle to get out of the solution / implementation mindset and fully embrace understanding customer problems. It can also be hard for extremely technically savvy folks to empathize with a very non-savvy user. None of these statements are absolute, they are meant to be “things to look for” when evaluating yourself or someone else for a role.
What I’ve found actually matters are your understanding and ability to learn in 3 broad areas:
Software Development & Deployment
Analytical Tools
AI / ML
Your job as a PM is not to write the software, however you spend a lot of time with the people that do. Assuming your team is doing something approaching Agile, then feature work and architectural and tech debt work are all in the same backlog which you own. The trick is is understanding enough about the technology to be able to make your own judgment about the relative value and priority of technically-oriented projects your team takes on. Your job is to make the best decisions possible to drive value for your customers and the business as quickly and as cheaply as possible. If you don’t understand how your team builds software and where it’s deployed you won’t be able to make high quality decisions.
In terms of the development process itself, it is helpful to be up on the lingo and the specific advantages and constraints of the languages used by your team. Again, not because you’ll need to jump in, but because you’re looking for more context. Here’s a short list of things you should be thinking about as it relates to the languages used:
Is it a good fit for the use case?
Does it add complexity to the user experience?
Is it a modern supported language?
Can you easily find developers that can work with it?
How easy is it to test and maintain?
What’s easy and what’s hard to do?
Occasionally less-tech savvy PMs will get “snowed” by their developers and get fuzzy reasons for why something is needed. When I’ve seen these situations, a few things are often true:
PM is not technically savvy, but worse yet, has made no effort to learn or improve
The dev team has lost respect for the PM because they are making decisions without enough relevant context
In many cases the devs may have a better view of what to do as a result, so find ways to get it done anyways
Engineers have little to no patience for irrationality. If you are enjoying all the of the authority that comes with being a PM by shooting from the hip on important decisions or dismissing non-feature oriented stuff (e.g. not your ideas) as unimportant, something bad will eventually happen. Best case is that you just lose credibility, worst case something pops up and materially impacts the business or the customer.
Where is this going?
Software is not written in a vacuum, it is very much written with the “destination in mind,” by which I mean where the code will run. Is this a mobile app? Web app? Desktop client software that has to run offline? The big themes are usually trading off between a few elements:
What’s the most cost effective place to run this?
How fast can I go vs does it lock me in over time?
How is the performance for what I need and can I afford it?
If you are building a generic SaaS app, you have a ton of choices to answer the question above and in reality it depends a lot on your financial situation, the skills and availability of developers, and customer expectations. There’s no right answer, though there can be several wrong ones. As the PM you have dual roles as the voice of the customer AND the voice of the business. Engineering should have the freedom to propose what they feel is the best path to hit the goal, however if that involves making a choice that builds in a costly migration later or locks you in to a weird technology that no one else in the company uses, you need to see that those could be problems and raise them.
Be interested, but be interested from a business standpoint and if there is some way it may impact the user experience (laggy, slow, etc). Things you should be thinking about include:
Scalability and cost over time vs time and cost to switch later
Uptime and cost - how bulletproof does this need to be?
Security
Privacy
All of these factors above will have some impact on your sales and customer experience, and a direct impact on your gross margin in the near term. In the long term, if you’re not careful, you can give yourself a re-write down the road.
Analytics Tools
There are a ton of product analytics suites out there and at a high level most of them do the same things. Most let you instrument user flows, capture feedback, segment your audience, do A/B testing, etc. The short story here is invest in being a power user. Take extra courses, get training from the vendor if you company paid for it. Leave no feature of the platform your company is using unturned.
Beyond tools, PMs are expected to be analytical types that are good manipulating data. For a long time that meant being someone who knew all the Excel shortcuts (now Sheets). Today, there is usually a need to query databases directly for information that is not available in the product analytics suite, and I’ve never worked anywhere that had enough analysts. There’s always another backlog of reports to be built. Some product teams have embedded analyst and if you do you should be thankful.
In 2023 you really should be aiming to be self-sufficient for your reporting needs, which usually means being passable at SQL. If you can build your own dashboards without having to wait for someone else, you will be that much informed a lot faster. It will be a small super power over other PMs who can do everything else as well as you. Try not to be dependent on someone else to get to what you need and you will be set.
AI/ML and the Future of Everything
In the time I planned to write this article and then actually wrote it my point here was proven again, as ChatGPT came out and took over everything (justified or not). At this point you need to force yourself to be as proficient as you can be on the topic of artificial intelligence, how the different sub categories are used to solve different types of problems (personalization, computer vision, NLP, etc) and the basics of the technology behind them (machine learning, deep learning, etc).
Take a class, pay more than you normally would, get as hands on as you can. If there is a group in your company starting to use AI, try like hell to go work with that team. In the next 5 years I think it’s fairly certain there will be a divide within the base of experience PMs - those that have leveraged AI to achieve insanely awesome things and those who have not and that it will become an increasingly wide gap that locks people out of opportunities.
The other vector here is that AI will likely change how the job of product management is done is some fairly substantial ways in the same time period. An AI-assisted PM will be less likely to “miss stuff” and make bad decisions pulling in the full range of context. I don’t think we’re getting replaced yet, and it’s too early to guess exactly how things will change, but I can see where lots of junior and PO type roles could be automated, and even some smaller level UX optimization decisions could no longer need human input. You give your integrated A/B test and product analytics suite 3 pages in a flow and exit points and then it can reconfigure the layout of any given page, the wording, colors, icons, and even the order of the pages and content by itself to find the highest yielding combo without needing your help. That’s not that far off. Getting to a place where you write in Slack /prodBot “build me a purchase flow with cc and apple pay” and 2 mins later it’s ready to review in staging is not beyond imagination. It will be amazing, and also disruptive for our field - so best to stay on top of it!
How do I Improve?
The first step like most things is acceptance. As a PM, your mindset has to be that it is your job to understand and care about the technology context of your customer, as well as the technology choices made by your engineering team. Attention to detail in the product manager context definitely applies to technical details as well.
One of the best ways to get better here is just ask a lot of questions and stay curious. If you don’t understand how a customer is using some tech to do something that came up in an interview, go run that down, and use it for yourself. Ask them more about it in the call, it’s not just some random technical aside.
In terms of the technology used to build your product, invest in the relationship with your engineering team. If things come up that you don’t understand ask about it, and stop worrying about looking stupid. You’ll look worse if you confidently make a call they need to ask you to reconsider because you didn’t understand what they said. Ask people to go to lunch or coffee (over Zoom if necessary) to explain concepts to you that are too big and distracting to some other meeting. Most of the time engineers appreciate that you are trying to learn more about what they do and get better at what you do.
Summary
Like most things in this role, exactly how technically savvy you need to be as a product manager can vary, but you need to be at a minimum threshold to understand what’s going on and learn from those around you. Beyond that you need to genuinely be curious and continuously fill your knowledge gaps as it relates to the technology used by your customer as well as your engineering team. Beyond improving your decision making ability, you should try to future proof yourself by mastering analytics tools, being a self-service analyst, and throwing yourself into the promise and thrash of Artificial Intelligence.
