Should Product Managers Code? Here's What I've Learned

Code literacy is product sense.

Key takeaways

• The skill is reading how your corner of the product is built. Enough to hold a real conversation about how a feature could be built, without writing production code or taking on-call.
• An AI agent is the fastest on-ramp there has ever been. Point one at your own codebase and ask how a thing works, how you would build your feature, and what the other two ways are.
• Ask five questions before you write the spec. Start with what else reads or writes the data your feature is about to touch.
• Sharper acceptance criteria are the payoff. An agent will not fill the gaps a good engineer used to fill with taste. It guesses and moves on.

For most of my career, the advice to product managers was the same, and it was good advice. You don't need to code. Learn the domain, talk to customers, write a clear set of requirements, and let engineering own the how. I gave that advice. I believed it.

It wasn't until I went to a really big tech company that I got reminded. Get too specific about the "how," and the dev team pushed back, politely or not. Stay in your lane. PM owns the what, engineering owns the how, everyone's happier for the fence.

Except the fence was never really there, not for good feature design. There are always a dozen ways to solve a problem, and some are cheap, and some will eat your whole quarter, and which one you pick depends on things a spec never sees. Complexity. Tech debt. The shape of the architecture. The bug backlog. Who's actually free to build it. I designed plenty of features that looked clean on paper, then walked into the sprint where we'd build them and watched the story count balloon as the devs dug in and realized it wasn't going to work the way I drew it.

I still remember a compression feature I owned back at Microsoft. Simple, I thought. Another team already had a component with all the libraries we needed, so we'd just use theirs. I had no idea what I was walking into. The org's politics didn't allow that component to be shared between the Office and Windows teams, and no amount of clean product thinking was going to move that wall. So we ended up choosing between building our own thin version of it or leaning on a piece DevDiv already owned and hoping their roadmap didn't drag ours down with it. That was a real tradeoff: cost against risk against timeline, and it had nothing to do with the feature spec. I only found out any of it because a dev walked me through it. That was the job. You always needed someone who knew the terrain to keep you from designing a feature that couldn't exist.

What changed isn't what everyone thinks changed.

Everyone says AI made building fast, so PMs can finally move faster. Sure. That's not the interesting part. The interesting part is how decisions multiplied and landed on your to-do list. Do you build the component, lean on open source, or reuse something the platform already gives you? Where does this code live? What part of the product does it touch? How does it behave once it's in there? An agent will happily answer any of those for you, and it will spew code wherever you point it, whether or not that's where the code should go. So you need some sense of how the thing is put together before you change it or bolt something new onto it. Otherwise you're not designing a feature, you're placing a bet blind.

And the same tool that raised the stakes dropped the cost of learning to almost nothing. The dev who used to walk me through the minefield is now sitting in your editor. Point an agent at the codebase and ask it how a thing works. Ask it how you'd build your feature, and what the other two ways to build it are. Then ask the question that actually saves you a quarter: has something like this been built here before, and what happened to it. Was it the clean one nobody ever had to touch again, or the one that generated three months of bug reports? An agent that can read the commit history and the incident channel knows that answer, and most PMs never think to ask. Talk to it like you'd talk to a smart engineer who has all day and no ego. That conversation is the fastest on-ramp to understanding a system that has ever existed, and most PMs aren't using it.

So I've changed my advice. Not "learn to code." Learn how the code is put together, and learn to ask good questions about it. Different skill, and that difference is my whole argument.

What code literacy actually means for a PM

I'm not asking you to become an engineer, take on-call, or push code to production. That's a craft, and it isn't really yours. What I'm asking is smaller. Learn to speak the language of your engineering team. Enough to understand how your corner of the product is built, and enough to hold a real conversation about how a feature could be built instead of handing over a wish and hoping.

You don't have to learn that language the hard way anymore. Ask the AI to teach it to you, in the context of your own feature. Have it explain how the current code handles the thing you're about to change. Have it lay out two or three ways to build what you want and the tradeoffs of each. Now you walk into the room with options instead of a demand, and you can prompt toward the how that makes the what better. That's what drives a good feature. It always was.

If you want a place to start looking, start at the bottom, with the data. The data and the data structures are the foundation, so understand those first. Then follow the flows: when things move, where they go, how they get there. Then the seams, the APIs and MCP servers and whatever else wires the pieces together. Then map all of it back to what the business actually does. What logic lives close to the data. What has to happen inside a single transaction. Where the flow hits limits. Where security and privacy put up walls you can't design around. The more you can empathize with how the application actually works today, the sharper your instinct for building things that fit it instead of fighting it. Learning to read a technical spec gets you most of the way there.

Five questions to ask an AI agent about your codebase

You don't need to read the whole codebase. You need to be dangerous about the part your feature touches. Here's where I'd point an agent, in order, the next time I owned a feature in an area I didn't know cold.

What else reads or writes this data besides my feature? Your change never ships in isolation, something already depends on the table, the field, or the object you're about to touch. Skip this question and you find out about the dependency when someone else's feature breaks the week after yours ships, not before you committed to the sprint.

Has something like this been built here before, and what happened to it? This is the one most PMs never think to ask, because the answer lives in the history around the code rather than in the code itself. An agent that can read commits and tickets can tell you whether the closest analog was clean and forgotten or a steady source of bugs. That tells you whether to copy the pattern or run from it.

Walk me through what happens end to end when a user does this. Trace the actual flow for the specific action your feature changes, not the abstract architecture diagram. You're looking for the step nobody mentioned in planning, the webhook that also fires, the job that also kicks off, the cache that also needs to know.

What's the contract here, and who else is relying on it? APIs, MCP tools, internal interfaces, whatever the seam is called where your change meets everything else. A "small" change to a contract is only small until you find out three other things call it. This is how you catch that before you ship, not in the incident review after.

What would the cheap version cost me later, versus the properly integrated one? This is the question that turns understanding into a decision. Get the agent to lay out both paths in plain terms: what's fast now and expensive in six months, what's slower now and doesn't come back to bite you. That's the tradeoff engineering used to walk you through. Now you can walk in already knowing it, and defend the call instead of asking for it.

Ask these five before you write the spec, not after engineering pushes back on it. That's the whole point of asking them.

Why technical judgment matters for PMs now

The roles are blurring, so lean in. The team ratio is getting smaller, and everyone's job is bleeding into everyone else's right now. That's not a threat, it's permission. Build the thing, open a PR, and let the team tear it apart. You'll learn more from one brutal review of your own code than from a month of reading about clean architecture. We published a piece a while back arguing AI makes every software engineer a little bit of a product manager, because once the machine writes the code, the human's contribution is deciding what's worth building. This is that same story from the other chair. Engineers are getting pulled up into product judgment. PMs are getting pulled down into technical judgment. Both are landing in the same spot, the place where a spec turns into working software, which used to be a handoff and is now a shared room. You don't have to love it. You do have to be able to stand in the room and follow what's being said.

Your prototypes get better. When you understand the terrain, you don't just prototype the what; you prototype it with a point of view on the how. You show up with two or three ways it could be built and a real question for the devs about which one is smart. That's a better prototype and a better conversation than a polished screen with nothing thought through behind it.

Evals stop being optional for you. You can't tell whether an agent's output is right if you don't understand what right looks like in this system. Judging the work instead of the demo means understanding the shape of the thing well enough to know where it'll break. Nod at a clean demo, and you're not reviewing, you're rubber-stamping. I've done it, and found out later the thing worked in exactly the one path we showed and fell over everywhere else.

Better definitions mean you get more done. This is the unglamorous one that pays the bills. Reading the code is also how you learn what a real acceptance criterion looks like. Once you've seen how the system actually behaves, you stop writing "the user can filter the list" and start writing the criteria that pin down what happens at zero results, whether the filter survives navigation, what the empty state does, which used to be the gaps a good engineer filled with taste. An agent won't fill them, it'll guess and move on. So the sharper your acceptance criteria, the less ambiguity you hand off, and less ambiguity is the whole ballgame now that the thing reading your spec won't stop to ask what you meant. When you understand how the system works, your definitions have fewer holes, which means higher quality, fewer stories exploding mid-sprint, and cleaner handoffs. Assuming you still run sprints. Either way the math is simple. Less rework, more shipped.

How to build code literacy this week

None of this needs a bootcamp. It needs reps, and the tools are already on your machine or a click away.

Point an AI at your actual codebase and make it teach you. Cursor, Claude Code, whatever your team already runs. Ask it to explain how a specific feature works, then get more specific, then keep going until you hit the bottom. There's a nice open-source project called Understand Anything built for exactly this, walking you through a codebase you've never seen. Run it on your own product.

Just stare at it a little. Read your team's pull requests, even the ones no one asked you to look at. You'll get a lot more than you may expect. Sit in on a code review and listen. Record the code review, then spar with your favorite AI on the topics discussed. Read the tests first, always, because the tests tell you what the code is actually supposed to do.

The instinct has to run all the way down

For a long time, a PM's instinct for whether something is right stopped at the edge of the code, because the code was someone else's problem. It isn't someone else's problem anymore. The instinct has to run all the way down now.

That's a real ask for a PM already carrying the outcome, the context, the definition, and the metrics. It's also the reason to want one place where the spec, the context, the evals, and the readiness of the work all live together, so your judgment has something real to work with instead of a demo to nod at. That's what we're building Product Studio to be. If you're a PM who's tired of signing off on things you can't see into, come find me on LinkedIn or take Product Studio for a spin.

Frequently asked questions

Do product managers need to know how to code?

No. You need to know how the code is put together, which is a different skill. You're not writing production code or taking on-call. You're learning enough to hold a real conversation about how a feature could be built.

How much coding should a product manager know?

Enough to understand your corner of the product. Start at the data and the data structures, then the flows, then the seams where the pieces connect, then map it back to what the business does.

Should a PM learn frontend or backend to talk to engineers better?

Neither, as a course of study. Point an AI agent at your own codebase and ask it to explain the feature you're about to change. That's faster than any curriculum and it's grounded in work you actually own.

What technical skills make a product manager stand out now?

Writing acceptance criteria with no holes in them, and being able to judge an agent's output instead of nodding at a clean demo.

‍