Should PMs learn to code?
Today the debate is about hands but it should be about what happens when the middle of the PM role disappears.
There’s a debate happening right now in product circles that keeps getting louder. Should PMs learn to code? (Or whatever code will become in the next years)
One camp says yes. AI tools like Claude Code and Cursor have made it possible for PMs to build working prototypes themselves. English is the new programming language. PMs who can code will move faster, depend less on engineering, and have more autonomy over what gets built.
The other camp says no. AI is handling more of the execution layer, which means PMs should go deeper into strategy, business outcomes, and problem understanding. The last thing the role needs is more scope. It needs more focus.
I run a product organisation of over 100 people at Wise. I’m watching this play out in real time. And I think both sides are asking the wrong question.
The debate is about hands, not about the role
Both camps are arguing about what PMs should do with their time. Should they spend it coding prototypes or should they spend it on strategy and stakeholder work? Should they expand into building or contract into thinking?
But the question I ask myself is, what happens to the PM role when the entire middle layer of product work gets compressed?
Think about what a PM actually does today. At the top, there’s a decision, what problem to solve, what to build, and why. At the bottom, there’s a quality check: does the thing we built actually work, does it solve the problem, does it hold up in the real world? And in the middle, there’s everything else. Writing specs. Creating tickets. Drafting roadmap documents. Preparing stakeholder updates. Summarising research. Aligning teams. Translating decisions into artefacts that make the organisation feel in control.
AI is compressing that middle layer fast. The question is what the role looks like when the gap closes.
One PM at the top. Automation in the middle. Quality at the end.
Here’s what I think is actually happening, and what I’m starting to see in practice.
You need one person at the top making the real decision. What is the problem? Who has it? Why does it matter? What are we going to build and what are we deliberately not going to build? This is the conviction work. It requires deep understanding of the customer, the business, the market, and the technical constraints. No AI tool does this well. It requires judgment that comes from experience, and it requires the willingness to commit when the evidence is incomplete.
In the middle, you need far less human involvement than before. The spec can be drafted by AI. The tickets can be generated. The stakeholder update can be summarised from a meeting transcript. The roadmap document can be assembled from the decisions that have already been made. Most of this work was never the valuable part of the PM role. It was the administrative cost of operating in a complex organisation. AI makes that cost close to zero.
And at the end, you need someone checking the quality. Does the thing that was built (partially or completely by AI) actually match the intent? Does it work for the edge cases that matter? Does the experience hold up for real users in real conditions? This is where hands-on product sense matters. Not coding the prototype, but understanding whether what was shipped actually solves the problem it was supposed to solve.
That’s the shape of the role going forward. Decision at the top. Automation in the middle. Quality at the end.
Why “PMs should code” misses the point
I understand the appeal of the “PMs should code” argument. If you can build a prototype yourself, you move faster. You don’t wait for engineering to validate your idea. You have more control over the early exploration phase.
And that’s true, up to a point. Being able to vibe-code a quick prototype is useful. I’ve done it myself. My teams do it. It’s a great way to make an idea tangible before committing resources.
But the argument breaks down when people start treating coding as the core skill PMs need to develop. It’s not. The core skill is still judgment. Knowing which idea to pursue. Knowing when to kill a project. Knowing which problem matters most. No amount of coding ability replaces that.
If anything, PMs who get excited about coding risk falling into the same trap that has always existed: doing the comfortable, tangible work instead of the uncomfortable, ambiguous work. Building a prototype feels productive. Sitting with a problem for three weeks until you truly understand it feels slow. But the second one is almost always more valuable.
The danger of “PMs should code” is that it gives PMs a new way to look busy without making the decisions that actually matter.
Why “PMs should stay strategic” also misses the point
The other camp isn’t wrong about the direction, but they’re wrong about what “strategic” means in practice.
When people say PMs should be more strategic, they usually mean PMs should think bigger, own business outcomes, influence the roadmap at a higher level. That’s fine as far as it goes. But “strategic” without being hands-on is just opinion-having.
The best PMs I work with are strategic and close to the detail. They understand the business outcome they’re driving and they also know exactly why a specific screen has a 40% drop-off. They can present to leadership about the quarterly strategy and they can also sit with a designer and spot the interaction pattern that’s confusing users.
If “be strategic” means “stay away from the detail and let AI handle it,” you end up with PMs who have opinions about everything and understanding of nothing. Strategy without proximity to the problem is just storytelling.
What I actually look for now
When I’m assessing PMs on my team or hiring new ones, I’m not asking whether they can code. I’m also not asking whether they’re “strategic thinkers.” I’m looking for something more specific.
Can they form a clear view on what the right problem is? Not just identify a problem from the data, but develop genuine conviction about which problem matters most and why. This is the decision at the top. It requires analytical depth, customer understanding, and the courage to commit.
Can they use whatever tools are available to move fast? Whether that’s AI for drafting specs, vibe coding for prototypes, or just writing a sharp Confluence doc. The tool doesn’t matter. The speed of going from conviction to something the team can act on is what matters.
And can they tell when something isn’t right? Can they look at a shipped feature and know it’s not solving the problem, even when the metrics are ambiguous? Can they spot the edge case that will break the experience for a segment of users? This is the quality check at the end. It requires product sense that goes beyond data and into genuine understanding of the customer’s world.
That’s the PM I want. Not a coder. Not a strategist. Someone who makes the right call, moves fast through the middle, and holds the bar at the end.
The role is compressing, not expanding
The PM role is not expanding to include coding. It’s not expanding to become more strategic. It’s compressing.
AI is removing the middle. The administrative, artefact-producing, alignment-maintaining layer that occupied the majority of most PMs’ time is shrinking rapidly. What’s left is the top and the bottom. The decision and the quality check. The conviction and the verification.
That means the role gets harder, not easier. Because the parts that are left are the parts that require real skill. You can’t automate judgment. You can’t automate the ability to sit with ambiguity and form a clear direction. You can’t automate the instinct that tells you something is off even when the data says everything is fine.
The PMs who thrive in this world won’t be the ones who learned to code or the ones who rebranded themselves as strategists. They’ll be the ones who were always doing the hard work: understanding the problem deeply, making decisions with conviction, and holding the bar for what gets shipped.
My book, Navigating the Product Galaxy: A Practical Handbook for Product Managers, is available now on Apress, Amazon, Walmart, Apple and Google Books. If you’re building your PM career, it covers everything from strategy to stakeholder management to leading teams.