The PM Superpower: Learning to (Read) Code
A reflection on why today’s PMs should care about syntax, terminals, and typos.
As a Product Manager, getting this far without learning to code can feel like proof you don’t need a Computer Science degree to succeed. And in a world where AI can spit out working code in seconds, it feels even less necessary.
But here’s the catch: AI hasn’t removed the need for understanding code. It’s raised the bar for PMs who want to stay ahead of the curve.
On a recent podcast about AI product management, Aman Khan put it simply: “being able to read code is just a key skill.”
This reinforced something I’d been thinking about for a while, and hearing it framed in the context of AI product management was the push I needed. So I did what any PM with questionable time-management skills would do: I signed up for Harvard’s free CS50 course. Because clearly the best way to relax after a week of product meetings is to dive into memory management in C.
Here’s why I thought it was worth the time: if AI can generate code, then the PM superpower becomes knowing enough to understand it, debug it, and communicate better with the people who live in it.
So what does a PM actually learn from diving into C?
Lesson 1. My Brain Likes Visual Problem Solving
My first test wasn’t ‘what is code?’ or ‘how do computers work?’. It was figuring out how my brain likes to solve problems.
The CS50 course starts you in Scratch, which was the right medium for me. Scratch is a visual programming tool where you snap blocks together like puzzle pieces instead of typing syntax, making the logic feel visual and tactile.
But moving quickly from Scratch to syntax, tested my problem-solving. How do you translate puzzle-piece thinking into lines of instructions a computer can actually run?
Sometimes I’d solve a problem the clunky way. First I’d sketch out the logic in plain language (that’s what “pseudocode” is), then translate it into actual code — and ask Claude Code (an AI coding assistant, like ChatGPT but tuned for programming) to suggest a cleaner version. Other times, I’d start with an AI-generated answer and work backwards, breaking it down into puzzle pieces until I understood how it fit together.
I also noticed that pseudocode has its own rhythm: it usually starts sprawling and wordy, then gradually compresses into something that looks and feels like real code. It mirrors the learning process itself. Messy at first, sharper with practice.
🧠 PM Tip: Don’t assume there’s one “proper” way to learn technical skills. If your brain works best in puzzle pieces, start by drawing diagrams. If syntax clicks first, start by writing out the logic. And if you’re not trying to become an engineer, don’t be afraid to “cheat”. The point is insight, not purity.
Lesson 2. Getting Comfortable in the Environment
The next big hurdle was getting comfortable in the space where engineering actually happens: the terminal (the text-based command line), the IDE (your coding workspace), and the error messages (those cryptic red lines that pop up when something breaks). They look terrifying at first, until you realize most are just pointing to something small — like a missing semicolon.
Take my vibe coding experiments. At first, I’d just rely on the chat window telling me an error had occurred and then I’d ask it to fix it for me. Now I feel confident going into the Code tab, scanning the file myself, and asking the LLM to isolate and fix just the broken part instead of regenerating everything. It’s a small shift, but it changes the way I interact with the tools.
That shift means I can actually debug my vibe coding projects. And yes, finally understand why my typos trigger such visceral reactions from engineers.
💡 PM Tip: You don’t need mastery to gain leverage. Just enough familiarity with the environment helps you:
Use AI coding tools effectively, instead of being intimidated by them.
Catch your own bugs and actually debug them.
Empathize with the effort behind every “small change.”
Lesson 3. Any Side Project Needs a Good PRD
This one should have been obvious before I started. But during the first two weeks of the course, I caught myself falling into a classic trap: aiming for perfect code. I’d spend hours rewriting a problem set or obsessing over the best design.
But that wasn’t my goal. I’m a product manager, not a software engineer.
So I wrote myself a Product Requirements Document:
Vision: Learn to read code well enough to debug and interpret.
Non-Goal: Become an engineer.
Success Metric: Understand what the code is doing, even if my implementation is ugly.
The PRD was a useful sanity check. It reminded me that it’s okay to “cheat” to polish my code, as long as I understood why my rough version worked, but also why it wasn’t the best-designed solution.
And I’d come back to that PRD and tweak it from time to time, making sure it still aligned with the reason I was learning in the first place. Just like any project, the vision and scope had to evolve a little as I went.
📝 PM Tip: Treat learning to code like a product problem. Define the why. Define what good looks like. Don’t accidentally scope yourself into building a compiler.
Final Takeaway
Here’s the truth: with AI tools everywhere, there’s often an unspoken assumption that you already understand the “engineering” legacy they’re built on. For PMs without a CS background, that can make you feel left behind.
But that’s exactly why learning to read code matters. I didn’t switch careers; I just picked up a new lens. Harvard’s CS50 gave me the confidence to peek under the hood without having to rebuild the car myself.
So, fellow PMs: if you’re serious about being a 100x PM in the age of AI, don’t ask whether you should learn to write code. Ask how quickly you can learn to read it.
Very helpful!!
Very insightful read for PMs!