How technical should a product manager be?
Addressing technical competence in product management
Marty Cagan has a framework for risk that I really like. It goes like this:
Product managers are responsible for value (do customers buy it / use it) and business viability risk (does the solution work for our business).
Product designers are responsible for usability risk (can users figure out how to use it)
Product engineers are responsible for feasibility risk (can we build it with the resources we have
This might lead you to think that each individual should independently solve for these risks.
You’d be wrong.
Marty talks a lot about how collaboration requires each member of the team to bring their skills forward to create a solution that solves for these risks. It’s a team effort, where engineering, product, and design may have insights that cross over domains.
So it’s clear that Product’s role is to add unique value in solving for value and business viability. And yet, we still seem to ask - “How technical should a product manager be ?”
I’ve found that frameworks from product influencers and experts don’t seem to match up with the day-to-day experience of people working in product.
I think the reason for this is that we can underestimate how little technical knowledge some folks have.
Before, product management was typically a role you landed in mid-career, where you’d previously worked as an engineer or a customer-facing role like support or account management. In these roles, you are exposed to the fact that you’re working on a software product.
You help customers get set up on your API
You log a ticket for engineering that is resolved through database updates
You logged a feature request with an explanation of the behavior you want
You worked in QA and tested releases before they moved to production
Now, product management is a career path you can start straight from a business degree. Worse, you can find many posts online that tell you that PMs don’t need technical knowledge. After all, that’s what engineers are for, right?
I’m firmly in the camp that every Product Manager should understand enough about how their product works to be an effective collaborator on the team.
Let’s break down what this means:
You should understand how software works generally (clients, servers, databases) because your customers interact with you through software
If you have an customer-facing API, you should understand how APIs work
You should understand the basics of how databases work and how the data in your product in structured
You should understand what it means to have scalable software if you’re planning to support a large number of users or transactions
If you’re working on a product or feature that’s dependent on machine learning, you should understand the basics of machine learning
Why? Because this is the bare minimum necessary to effectively communicate with technical stakeholders. This includes your own engineers, but may include engineers on other teams, security, legal, and even customers.
Without this knowledge, you can’t even communicate about one of the big four risks. When an issue is raised to you, you have no context. You constantly need engineers to translate to terms you understand, rather than understanding them where they are. You can’t help them unblock - you can only ask them for new estimates when things are moving slower than expected.
I’m not saying you need to be an expert. But you do need to know enough to not be a roadblock.
By the way, the same is true of design. You should be able to think about user experience, spot issues in the customer’s workflow, and collaborate effectively with design to manage usability risk. This seems less controversial though - many PMs have no problem leaning into design and UX.
I wonder why?