Product managers should not learn to code in the traditional sense — learning programming syntax (JavaScript, Python) provides almost no leverage for PM work. Instead, PMs should invest in understanding their codebase architecture: which systems exist, how they connect, where complexity lives, and which modules are fragile. The highest-ROI time allocation for PMs is customer understanding (10 hours/week), business metrics (5 hours/week), and codebase architecture awareness (1–2 hours/week). Technical credibility with engineers comes from asking good questions and respecting the discipline, not from syntax knowledge.
At Salesken, I worked alongside product managers daily. The gap between what PMs needed to know and what they could actually see in the codebase was enormous — and it cost us weeks of misaligned sprints.
I spent three months doing coding tutorials.
I learned JavaScript syntax. I built a to - do app. I understood what a for - loop was. At the end, I could write a small program that worked.
It was completely useless for my job.
Here's the nuanced answer to "should PMs learn to code": it depends what you mean by "learn to code."
If you mean "spend enough time learning to ship production code" - no. That's not your job. Your time is worth more spent becoming better at product strategy, at understanding your customers, at building relationships with engineers.
If you mean "learn enough to read code, understand a stack trace, and recognize what a refactor means" - yes. That's a worthwhile investment, but not in the way most coding tutorials teach it.
What I Actually Learned From Learning to Code
Halfway through my coding tutorial phase, I realized something. The syntax wasn't the valuable part. Understanding what a database schema is and why changing it is scary - that was valuable.
That changed my perspective on engineering conversations. When an engineer said "we need to refactor the schema," I used to nod. Now I think "that's a structural change to how we store data, which affects every service, which is why they're worried about it."
I didn't learn this from JavaScript tutorials. I learned it from understanding one big concept: structure matters more than logic.
Similarly:
- Understanding what a test is changed how I think about technical risk
- Understanding what a dependency is changed how I think about complexity
- Understanding what a deployment is changed how I think about release management
These are not coding concepts. They're system concepts that happen to live in code.
The Three Things Worth Understanding
If you're going to invest time in technical knowledge, focus on these three things. None of them require you to code.
1. How to Read a Diff
You should be able to look at a code change and understand what changed and why it matters.
This doesn't mean understanding every line. It means:
- Spotting when a change is bigger than it needs to be
- Recognizing when a change touches more files than expected
- Understanding why a small feature requires touching three services
- Seeing when a change includes complexity that shouldn't be there
Learn to read diffs. It takes a few hours. It's incredibly useful.
2. How Your Stack Actually Works
Not the syntax. The structure. You should be able to draw a diagram of:
- What services you have
- How they talk to each other
- Where data lives
- How requests flow through the system
This is not a coding concept. It's an architecture concept. A good engineer can explain this in 30 minutes without you needing to code.
3. What the Tradeoffs Are
Every technical decision involves tradeoffs. You should understand the common ones:
- Speed vs. correctness (we could ship faster if we don't test everything, but we'd have more bugs)
- Flexibility vs. simplicity (we could build a flexible system that works for ten use cases, but it's complex)
- Reusability vs. isolation (we could share code between services, but then they're coupled)
Understanding tradeoffs changes how you negotiate with engineering. Instead of "can we ship faster?" you ask "what would we trade to ship faster?" Now you're in a real conversation.
What Doesn't Help: Learning to Code
Here's what I've seen happen. A PM learns Python or JavaScript. They can build a small app. They think "maybe I should review more code" or "maybe I can catch bugs better now."
Neither of these helps. Code review isn't your job (engineers should review code). Catching bugs isn't your job (that's QA and testing). The things that got better - understanding what a for - loop is - doesn't change your job.
The time you spent learning syntax is time you didn't spend understanding your customer, reading PRDs, or building relationships with your engineering team. And those things are what matter.
The Real Question: What Makes You a Better PM?
I've worked with PMs who code and PMs who don't. The best ones shared a common trait: they understood their codebase.
They could ask smart questions about what was possible. They could assess technical feasibility. They could explain tradeoffs to stakeholders. They could prioritize thoughtfully between features and technical work.
Most of them did NOT write production code. One of them had written code years ago and still remembered principles. One of them spent 15 minutes a week in the codebase understanding how things worked.
They weren't better because they could code. They were better because they understood structure, dependencies, and tradeoffs.
The Alternative: Learn to Read Your Codebase
Here's what I recommend instead of coding tutorials:
Block 30 minutes a week. Read code with an engineer. Pick a feature. Ask "show me how this works." Let them walk you through the code. Ask "why did you do it this way?" and "what would happen if we changed this?"
This teaches you more in 30 minutes than a month of tutorials.
Use tools that make the code more readable. This is why I'm invested in code intelligence. Instead of struggling to understand code because it's opaque, use tools that make it transparent. You can see what changed, who changed it, why it was changed. You can drill into dependencies and ownership.
Ask your technical co - founder or lead engineer to explain the architecture in 30 minutes. Bring a whiteboard. Have them draw the services, the dependencies, the data flow. Ask "where would we be slow?" "where would we break?" "where is the knowledge concentrated?"
None of this requires coding.
The Confidence Problem
I think a lot of PMs learn to code because of imposter syndrome. I was guilty of this. I felt like a fraud not knowing code, so I tried to learn.
But coding didn't make me a better PM. Understanding the codebase made me a better PM. And I could understand the codebase without coding.
The insecurity goes away not when you can code, but when you develop a framework for understanding what you don't know and how to ask good questions.
An engineer respects a PM who says "I don't know how the authentication system works, can you explain it?" more than a PM who tried to code, gave up, and now pretends to understand systems they don't.
The Edge Case: When Coding Helps
There is one scenario where learning to code is genuinely useful: if you're an early - stage founder thinking about whether to stay technical.
If you're wondering "should I write code or focus on product?" - write some code. Understand what you enjoy about it. If you like building things with code, great. If you prefer thinking about what to build, also great. That clarity is useful.
But if you're a PM at a scaling company and you're considering learning to code because you feel inadequate - don't. That's insecurity, not a real gap.
The Glue Perspective
We built Glue because we believe the future is PMs who understand their codebase without needing to learn to code. That's the real productivity gain.
Instead of asking a PM to spend three months on Python tutorials (a bad investment), we're building tools where PMs can understand code by reading it. You can see what changed. You can understand why. You can see who owns what. You can follow dependencies.
That's how you get technical understanding without the coding distraction.
How to Actually Spend Your Time
If you care about being a better PM, here's the real investment priority:
- Understanding your customer (10 hours per week) - talk to them, watch them use your product, understand their problems
- Understanding your business (5 hours per week) - know your metrics, your unit economics, your key drivers
- Understanding your codebase (1 - 2 hours per week) - keep pace with the architecture, follow the major changes, know where the complexity is
- Building relationships (ongoing) - coffee chats with engineers, design, marketing, leadership
Learning to code? That's time you're not spending on any of these. And these things matter infinitely more to being a good PM.
Frequently Asked Questions
Q: Doesn't coding make you better at estimating?
A: Not really. Estimation is about understanding complexity and code dependencies, not about code syntax. A PM who understands that adding a new payment method touches the billing system, the reconciliation system, and the compliance system — visible through dependency mapping — will estimate better than a PM who can code but doesn't understand the architecture.
Q: What if I genuinely enjoy coding? Should I learn?
A: Sure. If you get joy from it, that's reason enough. But do it as a hobby or side project, not as a career development strategy for your PM role. The time investment isn't worth it relative to other things that make you better at your job.
Q: How do I gain technical credibility with engineers if I don't code?
A: By asking good questions and respecting the discipline. Engineers respect PMs who understand that technical problems are complex and who listen. They don't respect PMs who think learning Python makes them equals. Be curious, be humble, and actually try to understand. That builds more credibility than syntax knowledge ever will.
Related Reading
- AI for Product Management: The Difference Between Typing Faster and Thinking Better
- The Product Manager's Guide to Understanding Your Codebase
- AI Product Discovery: Why What You Build Next Should Not Be a Guess
- Cursor for Product Managers: The Next AI Shift Nobody Is Talking About
- Product OS: Why Every Engineering Team Needs an Operating System
- Software Productivity: What It Really Means and How to Measure It