By Priya Shankar
Every few months, someone tweets: "All PMs should learn to code."
I disagree. But I understand why the argument exists.
PMs who understand code make better decisions. That's true. Code literacy matters. But that's different from "learn to code."
Let me explain the difference.
Why The Argument Exists
A PM proposes a feature. The engineer says it's impossible. The PM believes them and axes the feature. Later, the engineer realizes it was actually possible—they just didn't think about it at first.
If the PM had pushed back with code knowledge, they could have forced a real technical discussion instead of accepting "it's hard."
Or: A PM makes a roadmap decision that the engineer has to rework later because the architecture doesn't support it. If the PM understood the architecture, they could have made a better decision.
Both are true. Code literacy would help.
But literacy isn't the same as ability to write code.
Literacy vs. Writing
Code literacy: understanding how systems work, what's feasible, what's constrained. Can you read code and understand what it does? Do you understand what "API" means? Can you see an architecture diagram and understand the dependencies?
Code writing: being able to author code. Knowing syntax. Knowing frameworks. Being able to implement features.
You need literacy. You don't need to write code.
The mistake is conflating these. "Learn to code" means spend 6-12 months becoming a mediocre developer. That's bad ROI. "Learn to read code and understand architecture" means spend 4-8 weeks understanding your specific system. That's good ROI.
Why You Shouldn't Learn to Code
Your job is product strategy, not engineering. You have limited time. You can: become a mediocre engineer, or become an excellent PM. Not both.
Choosing to learn coding means choosing to divide your focus. Your engineering team doesn't need another junior engineer. They need a PM who understands product.
You'll understand generic programming, not your codebase. Learning to code means learning Java or Python. You won't understand your specific system. You won't know why your team chose monolithic architecture. You won't know the technical debt in your critical path.
A junior engineer with 6 months of coding experience won't ship features in your codebase without mentorship. So what was the point?
Your engineers will resent it. If you start writing code, your engineers will have feelings. Either they feel threatened (you're taking their territory) or they feel annoyed (a PM with bad code is worse than no code). You're not a closer collaborator. You're just a distraction.
Why You Should Understand Code
Understanding your codebase is non-negotiable.
Why? Because you're making decisions that affect the codebase. Feature prioritization affects architecture. Roadmap decisions affect technical debt. You can't make good decisions blind.
But understanding doesn't require writing.
You need to know:
- What systems exist and how they connect?
- What's the critical path for your product?
- Where are constraints? (architecture, technical debt, external dependencies)
- What's feasible in your current system vs. what requires rework?
- What's the team's knowledge distribution? (Are critical systems single-person dependencies?)
- Where's technical debt? What's it costing?
None of these require writing code. They require asking the right questions and understanding the answers.
How To Actually Build Code Literacy
1. Spend time with your architecture team. Have them explain: What are the major systems? How do they connect? What's the critical path? Why is it built this way? This conversation is worth more than a coding course.
2. Read your code. Don't try to understand every line. Read the high-level structure. How is the folder organized? What's the main entry point? What's the data flow?
3. Ask questions, specifically. Not "how does the payment system work" (too vague). Ask: "If I want to add a new payment provider, what code changes? Who would do it?"
Their answer tells you about modularity and knowledge distribution.
4. Understand your critical failures. When something breaks in production, understand why. Not every line of the fix, but: why did this break? What does this tell us about the architecture?
5. Use tools to extract understanding. With Glue, you can ask questions directly: "What payment providers do we support?" "How modular is our architecture?" "What integrations are we missing?"
Instead of spending 6 months learning to code, spend 4 weeks learning your codebase.
The Real Question
The real question isn't "should you learn to code?" It's: "Should you understand your product?"
Yes, absolutely.
And understanding your product requires understanding your codebase. Not as a programmer. As a strategist.
But that understanding doesn't come from learning syntax. It comes from asking questions, reading code, and using tools that translate code into product insights.
Why This Matters
When you understand your codebase:
- You ask better questions
- You make better roadmap decisions
- You earn credibility with your engineering team
- You understand constraints and can work with them instead of fighting them
- You move faster because decisions are informed by reality
When you don't:
- You make roadmap decisions that the architecture doesn't support
- You miscommunicate with engineering
- You lose credibility
- You move slower because decisions need rework
The stakes are real. But the solution isn't "learn to code." It's "learn your system."
Frequently Asked Questions
If I don't understand code, won't engineers manipulate me? Possibly, but understanding code syntax won't prevent that. Understanding architecture and asking probing questions will. "Why would that take 8 weeks when Feature X took 2?" is a good question whether or not you can write code.
What if I really want to learn to code? Fine. Do it on your own time. But don't do it expecting it to make you a better PM. It won't. It'll just divide your focus.
How do I know if I'm understanding the codebase well enough? You can explain key features and systems to a new PM without reading code. You understand the tradeoffs. You can predict what'll be hard. If you can do those things, you're good.