It’s a common struggle for product managers, especially when they’re new to the problem area of this company. It can be articulated in several ways:

• “I can’t always follow the dev team conversation”
• “I don’t know why one technology choice is better than the other”
• “I can’t demonstrate as well as the sales engineers can”
• “I’m not sure how to triage bugs”
• “I can’t review code changes”

Why do these questions come up? Because they’re causing friction. The product manager is being asked for input and can’t provide it, which causes self-doubt and fails to assist the team. That of course leads to the team seeking answers elsewhere, and next thing you know the PM isn’t leading anything.

I do think that a PM should strive to be able to do most of those things, but it’s not reasonable to expect immediate perfection. Instead, the PM should work to attain the level of technical expertise that they are comfortable with.

Let’s start with setting some goals and terminology. First, the word “technical.” All too often, it is used as a gatekeeper’s wishy washy feeling. (Side note, if you’re ever part of a hiring process and see this in negative or positive interview feedback, I strongly advise going to that interviewer for an explanation.) “Technical” means “having special and usually practical knowledge especially of a mechanical or scientific subject” according to Merriam-Webster. That’s a reasonable starting point: as a PM you need to have enough practical knowledge to handle the questions we started off with.

Another useful definition of “technical” is in the off-road sense, such as trail running or mountain biking: “trails with rocks, roots, and other tricky bits.” I think this is a more useful definition to have in mind, because the way to handle a technical trail is wholly practical, not at all special. You don’t have to know the geology and botany of how that stretch got to be a rocky, root-filled mess. You have to judge in a split second if you’re going to run over it, slow down and hike through it, or search for a way around it.

That decision is a high speed metaphor for the product manager’s technical knowledge attainment choice. For each challenging area, are you going to learn enough to whiteboard, learn enough to participate in coding solutions, or avoid the area?

Whiteboard knowledge is my favorite way to answer that question, the equivalent of running across the rock tops of a nasty trail. It goes like this: read the documentation that exists, such as it is. For a new project, that might just be a design proposal, or there might be public documentation and field enablement materials. Read them, and ask your dev team questions about whatever you need. Then draw a diagram of how the system works, and ask the dev team where it’s wrong. Correct and repeat. Make sure it’s clear that this diagram isn’t just for you… I use these heavily. Technical enablement, conversations with other teams, customer conversations, conference presentations… the system diagram is something I’ll have open in a tab as long as I’m leading this product.

Learning enough to participate… in my opinion, this is usually going too far.
You need to show competence at product management, not software engineering. Since I became a product manager, I have only rarely used source code access, and then only for documentation. I’ll do proof of concept scripts, I’ll do metadata searches, but I won’t review source code. I have been around long enough to have reasoned opinions and some subject matter expertise about branching strategy and monorepos, but it’s not my area of responsibility. I would not say this is strong opinions loosely held, but rather a little bit less than whiteboard ability. All that said: PMs absolutely exist who are preeminent subject matter experts in the problem area and have written working code for solving it. There may be a number of excellent reasons why they’re not off founding their own companies, but that’s neither here nor there. If you find yourself in this situation, it can be reasonable to get down into that special and practical knowledge of how the code works.

Another option, particularly when you’re new to a project or carrying too many projects, is to avoid and delegate. I prefer to use this technique in situations that I am actually experienced in because I can still judge if they’re going well. For instance I have been a sales engineer, so I’m very confident at identifying people who are better than me at it and asking them to handle all the demos while I listen and take notes. I’m less confident if I don’t know enough to triage the bugs, and that’s a situation I’m going to act to fix ASAP.

Returning to our list of concerns, let’s consider with the way I’d answer them in a new project:

• “I can’t always follow the dev team conversation” – a mix of delegation and whiteboard is the answer here. Most of what they’re discussing in a conversation that veers away from customer-facing solutions is probably not your problem, but it’s useful to learn enough about the process that you can say why you don’t need to know.
• “I don’t know why one technology choice is better than the other” – whiteboard is the answer. You do need to know why decisions are being made and what they mean to the product market fit of your solution. You don’t need to know the variable and function names.
• “I can’t demonstrate as well as the sales engineers can” – it’s okay to start with delegation here, but participation is ideal. A PM should be good at showing customers why they’d want the product. Practice is the way to get there.
• “I’m not sure how to triage bugs” – again participation is the ideal, and again I firmly believe in on-the-job training. Try to replicate the bug. Ask the reporter for help if you can’t. If you can replicate it, ask what the likelihood of it occurring is, and what the impact to a customer is. High likelihood, high impact, that’s a critical bug. Your decisions may not be correct, especially at first, but you’ve made it so much easier for the dev team by showing that it can be replicated and taking an initial stab at setting priority.
• “I can’t review code changes” – delegate all the way, unless you happen to be an expert in this problem or a trained software engineer.

One last critical item to watch out for… do you really know what you think you know? The approach I’ve outlined here is not a one-and-done, you have to keep reassessing. False knowledge is a huge risk, and the answer is to bring humility to every conversation. Maybe what you know has gone stale and you need to re-assess. Worse, it’s not enough to wait for others to correct you, especially as you grow more senior; you might need to correct yourself. If this happens, do yourself a favor and fix it quickly, loudly, and thoroughly. That means correcting documents, adding notes to tickets, and notifying affected teams.

Assess what you need to know, how deeply. Get that knowledge. Refresh it regularly.