How technical does a product manager really need to be in 2026?

You don't need to write production code. You need to read a system well enough to name the tradeoffs in it — and in 2026 that bar now includes some AI fluency: reading an eval, knowing what an agent does, understanding why a model behaves the way it does. How far past that you go depends on your product and your company. The durable part is the same as it ever was: thinking in systems and tradeoffs.

This is the debate that never dies in PM communities. One camp says you must code to earn engineers' respect. The other says a PM who codes is a PM doing the wrong job. Both are overstating their case. Here's the honest version.

Do product managers need to code?

No — not production code, and not as a job requirement. Writing code that ships to customers is a full-time craft, and the PM who tries to do it part-time usually does it badly and neglects the actual PM work: knowing the customer, sequencing the roadmap, making the call when two good options conflict.

What you do need is different. You need to read a system: follow one user's request through the parts, and at each part say what it does and what it costs. That's a reading skill, not a writing skill. It's the difference between being able to review a contract and being able to draft one from scratch — you can catch the bad clause without being the lawyer.

So when someone says "good PMs code," push on it. Ask what decision coding would have changed. Usually the answer is a decision that reading the system, not writing it, would have caught just as well.

What does "technical enough" actually mean?

"Technical enough" is not a fixed amount of knowledge. It's a job: you can hold a conversation about how the product is built without needing every word translated, and you can spot when a technical choice is quietly a product choice.

Concretely, a PM who is technical enough can do four things:

• Follow a feature from the tap the user makes to the place the data lands, in plain words.
• Name the cost of a choice — slower, pricier, or more likely to show the user something wrong — not just the benefit.
• Ask what breaks for the customer when one part fails.
• Ask what a choice costs to undo later.

None of that requires a language, a framework, or a terminal. It requires knowing that every "faster" has a price and being the person who asks who pays it.

Has the bar risen in 2026? Yes — and here's the part that's new

It has, and the new part is AI. Products now ship features that call a model, and that changes what "technical enough" covers. You don't need to train models or write the inference code. You do need to read and define the things around them:

• An eval — short for evaluation, a test set that scores whether the model's output is good enough. If your product uses a model, you'll be asked "is it good enough to ship?" and the answer lives in the eval. Being able to read one, and help define what "good" means, is now table stakes.
• An agent — a model that can take actions in steps, not just answer once. Knowing roughly what an agent does, and where it can go wrong, lets you scope a feature honestly instead of promising magic.
• Model behaviour — why the same model gives a different answer twice, why it sometimes makes things up, why "it worked in the demo" is not "it works". These aren't bugs to be fixed once; they're costs to be managed, which makes them product decisions.

Treat this as an extension of the old skill, not a new one. An eval is just a way of naming the cost of a model being wrong. An agent is just a system with more boxes and more ways to fail. The habit is identical: read the system, name the tradeoff.

It depends — on what, exactly?

Honestly, the right level is not the same for every PM. A few things move it:

• A developer-tools or infrastructure product pushes the bar up. Your customers are engineers; you can't name their tradeoffs if you can't follow their system.
• A consumer product with a simple backend pushes it down. More of your edge comes from knowing the user than from knowing the stack.
• An AI-heavy product pushes the AI part up sharply, whatever the rest looks like.
• A small team pushes everything up, because there's no one to translate for you. A large org with strong engineering partners lets you lean on them more — though leaning on them is not the same as not understanding them.

The mistake is "more technical is always better." It isn't. Time spent going deeper on the stack is time not spent with customers. The question is always what the extra depth buys you for this product.

How do you build the skill without pretending to be an engineer?

Not by taking a coding course. A coding course teaches you to write, and writing is not the skill you're missing. The skill you're missing is reading systems and naming their costs, and you build that by doing it on real problems and getting feedback.

That's what PMLabs is for. You get a problem and a blank canvas, drag the parts of a system on, wire them together, and write one line on why each one is there — including the AI parts, when the problem has them. A rubric scores it in about 30 seconds, so you find out what you missed while it's cheap to miss it. You go simple first, then harder, so the reasoning builds instead of the vocabulary piling up. Sessions run about 15 minutes. No code.

One honest note: the scoring is AI against a rubric, so treat it as a sparring partner, not an architecture review or professional engineering advice. It won't replace your engineers, and it isn't trying to. It gives you the reps, so the next time a technical choice is quietly a product choice, you're the one who catches it.

If you want to start, Module 1 is free, no card: pmlabs.app. If you'd rather have the one-page version first, the cheat sheet covers the parts you'll meet most.

For the questions this turns into in a real review, see the system design questions PMs actually get asked. And if diagrams are where you freeze, start with how to read an architecture diagram without coding.