Should Product Managers Learn to Code? (A Better Question)

By Priya Shankar, Head of Product at Glue

Type "should product managers learn to code" into any search engine and you'll find a decade of debate. Some say yes, absolutely, it builds empathy with engineering. Others say no, it's a distraction from the PM's real job. Both sides make valid points. But after years of working at the intersection of product and engineering, I think they're answering the wrong question.

The better question is: what do PMs actually need from technical knowledge, and what's the most effective way to get it?

The "PMs should code" camp argues that writing code builds empathy, helps PMs understand trade-offs, and earns respect from engineering teams. There's truth in this. When you've written even a simple application, you start to appreciate why "just add a button" might actually take two sprints.

The "PMs shouldn't code" camp argues that time spent learning Python is time not spent on user research, market analysis, strategy, and stakeholder management. Also true. Product management is already a job that sprawls across too many responsibilities. Adding software development to the list seems like a recipe for doing everything poorly.

According to a 2023 survey by Product School, fewer than 15% of product managers write code regularly, even those with computer science degrees. The skill atrophies quickly when you're not using it daily, which means the investment has diminishing returns over time.

Here's what neither side talks about enough: the real need isn't coding ability. It's codebase understanding.

A PM who can write a React component is interesting. A PM who can tell you which services the checkout flow depends on, who owns the recommendation engine, and why the last release took three weeks instead of one? That PM is effective.

The distinction between writing code and understanding code is where the whole debate falls apart. They're treated as the same skill. They're not.

Let me be specific about what technical knowledge makes a PM better at their job.

Architectural awareness. You need to understand how your product is structured at a systems level. Not the syntax, not the implementation details, but the shape of it. Which services talk to which other services? Where are the boundaries? What's shared and what's isolated?

Dependency literacy. When someone says "that feature touches three services," you should understand why that matters. Dependencies create complexity, risk, and coordination overhead. Knowing the dependency graph of your product changes how you scope and prioritize.

Change context. Code isn't static. Understanding what changed recently, who changed it, and what the ripple effects might be is critical for managing risk and setting expectations. A PM with change context doesn't get blindsided by "unexpected" delays.

Ownership clarity. Knowing who owns which parts of the system helps you route questions, plan collaborations, and identify single points of failure. If one engineer wrote 80% of a critical service, that's a risk factor for your roadmap, not just theirs.

None of these require writing a single line of code. All of them require visibility into the codebase that most PMs don't currently have. For a deeper exploration of how PMs can build this kind of understanding, see our guide on software architecture for PMs.

This is where I think the conversation needs to shift.

Code literacy means a PM's personal ability to read and understand code. It's valuable but limited. It takes time to develop, it's specific to certain languages and frameworks, and it doesn't scale. A PM who's literate in Python still can't parse a Kubernetes deployment config or trace a microservices call chain by reading YAML files.

Code intelligence means having access to a tool that understands the codebase and can translate it into terms anyone can work with. It's not dependent on the PM's personal technical background. It scales across languages, frameworks, and system complexity. And it stays current as the codebase changes.

Think about it this way: code literacy is like learning enough French to order coffee in Paris. Useful in that specific situation, but limited. Code intelligence is like having a fluent translator with you at all times. You can have any conversation, about any topic, in any context.

The practical difference shows up every day. A code-literate PM might be able to read a pull request and follow the logic. A PM with code intelligence can ask "what will this change affect?" and get an answer that includes downstream services, affected teams, and potential risks, without reading the PR at all.

Research from McKinsey's 2024 developer productivity report found that cross-functional teams with shared technical context ship 20% faster than those without it. That shared context doesn't have to come from everyone learning to code. It can come from tools that make the codebase transparent to the whole team.

I'm not arguing against code literacy. If you enjoy learning to code and have the time, go for it. But if you're asking "should product managers learn to code" as a strategy question, the honest answer is: there are faster, more sustainable ways to get the technical understanding you need.

If coding isn't the answer, what is?

Ask better questions. The gap between PMs and engineers often isn't about technical knowledge. It's about knowing what to ask. Instead of "how long will this take?", try "what are the dependencies?" Instead of "can we just do X?", try "what would X require us to change?" These questions signal that you're thinking about the system, not just the feature.

Use visual system maps. Architecture diagrams, dependency graphs, and service maps are worth more than a thousand lines of code for a PM. If your team doesn't have current ones, that's a problem worth solving. Static diagrams go stale quickly, though, so look for tools that generate them automatically.

Read changelogs, not code. You don't need to understand every line of a pull request. But reading PR descriptions, release notes, and commit summaries gives you a sense of what's changing and where. Over time, patterns emerge that sharpen your technical instinct.

Invest in code intelligence tooling. This is where tools like Glue fit in. Instead of building personal technical skill over months or years, you can get instant access to codebase understanding through natural-language questions. Ask what a service does. Ask who owns a component. Ask how a feature is implemented. Get answers in seconds, not after a 30-minute engineer walkthrough.

The PM-engineer trust gap closes faster when PMs have independent access to technical context. Not because PMs become engineers, but because they stop operating blind.

Pair with engineers intentionally. When you do sit with an engineer, make it count. Don't ask them to explain everything from scratch. Come in with context from your code intelligence tool, and use the pairing session to go deeper on the areas that require human judgment and nuance.

"Should product managers learn to code?" is really asking: "How do I close the gap between what I know and what I need to know to do my job well?"

The answer isn't one-size-fits-all. Some PMs will thrive with a coding bootcamp. Others will get 90% of the benefit from a code intelligence platform and a habit of reading architecture docs.

What matters is that you're not flying blind. Your engineering team is building something complex, and your job is to make strategic decisions about that complexity. You need a way to see it.

Glue gives you that visibility. It connects to your codebase and makes it queryable in plain language, so you can understand your product's architecture, ownership, dependencies, and history without opening an IDE. It doesn't replace the relationship with your engineers. It makes that relationship better, because you show up informed.

The answer to "should PMs learn to code?" is: learn to understand your codebase. How you get there matters less than the fact that you do.

---

Should product managers learn to code?

Learning to code can build empathy and technical intuition, but it's not necessary for most PMs to be effective. What PMs actually need is codebase understanding: knowing how systems are structured, what the dependencies are, and where complexity lives. This can come from code literacy, code intelligence tools, or a combination of both. Focus on the outcome (better technical decisions) rather than the specific method.

What technical skills do PMs need?

The most valuable technical skills for PMs are architectural thinking (understanding how systems connect), dependency awareness (knowing what's upstream and downstream of a change), and change context (tracking what's been modified recently and why). These don't require programming ability. They require access to codebase information and the curiosity to engage with it. Many PMs also benefit from understanding basic concepts like APIs, databases, and deployment pipelines at a conceptual level.

How can non-technical PMs understand the codebase?

Code intelligence platforms like Glue let non-technical PMs ask questions about the codebase in plain language and get clear, accurate answers. You can ask what a service does, who owns a component, what changed recently, and how features are connected. This gives you the same situational awareness that a technical PM would get from reading the code, without needing programming skills. Combining a code intelligence tool with regular architecture reviews and intentional pairing sessions with engineers creates a strong foundation.