Should Product Managers Know How to Code? My Honest Answer

A couple of years ago I posted a one-question poll on this site: should product managers know how to code? I deliberately didn't share my opinion at the time. I wanted answers from a broad enough audience that the results would mean something, and posting my own view first would have skewed it.

Enough time has passed. Here's what I actually think, with the benefit of two more years building software and hiring PMs.

The short answer

A PM doesn't need to write production code. A PM does need to read it, change it, and understand what an engineer means when they say a thing will take three weeks.

That's the whole answer. It's also the kind of answer that's easy to nod at and hard to act on. The interesting part is what "read it" and "understand" mean in practice. Both have changed a lot since I first heard this debate.

What "knowing how to code" actually means in 2026

The debate as I hear it is usually a vibes argument. Someone says "PMs should code", someone else says "no, PMs should focus on strategy and customer research", everybody walks away unconvinced. Neither side has actually defined what they mean.

When I look at the PMs I've hired and the ones I've replaced, the working definition I use has three layers.

Layer one is fluency in the data. Can you write a SQL query against your product's database without asking an engineer? Not a perfect one. Just enough to answer your own funnel question on a Wednesday afternoon. The PM who files a ticket every time they want to know how many users finished onboarding last week makes worse decisions, slower, than the PM who can pull the number themselves in five minutes.

Layer two is fluency in the system. Can you read a pull request your team opens, follow the change in context, and ask a useful question in the review? You don't have to spot the bug. You have to be able to say "wait, this changes the assumption we made in the kickoff doc about how we handle null", and trust your team to take it from there. That's not a coding skill. It's a reading skill. Reading code is much easier than writing it.

Layer three is fluency in trade-offs. When an engineer tells you "this is a two-day change, but properly it's a three-week change", can you tell which version your roadmap can absorb? When a junior engineer wants to introduce a new dependency, can you ask whether anyone will own it in a year? You don't need the answer. You need to know the shape of the question.

If a PM gets to all three layers, I don't care whether they write code on weekends. If they can't do layer one, I lose patience fast.

When coding actively hurts a PM

I've worked with engineering-leaning PMs who couldn't stop themselves from designing the solution. Customer describes a problem, PM is already drafting the schema. That's a different failure mode and it's expensive.

The signal I watch for is whether the PM lets the engineer be the engineer. The PM with too much code in their head will overspecify. The discovery doc shows up with API contracts already written. Engineers either reluctantly build the wrong thing or push back, and the cycle adds two weeks. Either way the team learns to route around the PM, which is the long-run damage.

So the position I argue for is this: enough code to ask good questions, not so much code that you stop asking them. Engineers moving into PM roles have to actively unlearn the urge to draft the solution. The good ones figure that out in their first year. The ones who don't end up running a one-person product team next to a frustrated engineering team.

What I look for when hiring

The interview signal I trust most is what happens when I ask a PM to walk me through a recent decision. The good ones reach for a number within the first two sentences. The number doesn't have to be precise. It has to exist. "About 14% of our trial users converted after we shortened the onboarding from seven steps to four" tells me they had access to the data and used it. "Conversion improved" tells me they didn't, or they did and didn't bother to look.

The second signal is whether they ask me a technical question about the engagement we're discussing on the call. Not to show off. To narrow the problem. A PM who doesn't probe the technical surface of a new domain takes everything an engineer says on faith later.

The third signal is reading code in the open. I've started asking candidates to read a small open-source pull request with me during the interview. I don't ask them to spot the bug. I ask them what the PR is changing and why. The answers split the room. I've written more about what I look for in PM interviews elsewhere; the coding piece is one of three or four signals I weight heavily.

What this means now that AI writes most of the code

The AI angle is the part of this I've been rewriting in my head most. When I first ran the poll, GitHub Copilot was new and most PMs treated ChatGPT like a toy. Now any PM can paste an error log into a chat window and get a plausible explanation in 30 seconds.

That's shifted the bar in two directions at once. The cost of layer one (data fluency) went down. Tools like Hex, Cursor, and the SQL agents baked into most data platforms mean a PM with reasonable analytical instincts can get usable SQL out in minutes, not hours. The bar for "I can answer my own funnel question" is much lower than it was in 2020.

But the cost of layer three (trade-off fluency) went up. AI tools make it trivially easy to generate code that looks right and is subtly wrong. PMs who can't read code well enough to smell that gap will ship more broken work than ever, just faster. The downside of "anyone can code now" is that the work of catching what's wrong falls more heavily on the people who can read carefully.

For PMs working on AI products specifically, this matters even more. The AI product manager who's overseeing an agent build needs to be able to evaluate the agent's outputs in context. That's a reading skill. It's exactly the muscle the no-code PM never built.

The bar I'd set for a new PM today

If I were giving advice to someone moving into a PM role in 2026, I'd skip the coding bootcamp and learn three things in order.

Learn SQL well enough that you'd be embarrassed to ask an engineer to pull a basic number for you. A weekend course is enough. Mode and Hex both have good free tracks.

Learn to read code in your team's main language well enough that you can follow a PR. Pair with an engineer for an hour a week for a quarter and you'll get most of the way there.

Learn how your AI tools fail. Use Cursor or Claude Code to write a small CLI script, then force yourself to debug it. The exercise teaches you, fast, where AI-generated code lies to you. That's the calibration a 2026 PM needs that a 2020 PM didn't.

That ordering is deliberate. The PMs who get to layer three having skipped layers one and two are the ones I've watched do the most damage. They have opinions on architecture without the reading skill to spot when the architecture is fragile, and the team builds around their certainty.

A note on the original poll

The original poll embed lived on this page for a couple of years before I rebuilt the site. Responses split close to 50/50, which tells you the practitioner community hasn't reached consensus either. The disagreement is real.

The part I'd push back on is the framing. "Should PMs code" is the wrong question. The right question is whether a PM can do the three things above. If the answer is yes, the debate about syntax doesn't matter. If the answer is no, no amount of coding tutorials will save them. The PMs I've seen succeed in technical environments aren't the ones who write the most code. They're the ones who ask the right question of the engineer in the standup and then get out of the way.