I was at a product meetup a few weeks ago and someone asked the question that never dies: "Should product managers learn to code?" The room split predictably. Engineers said yes. Designers shrugged. PMs gave diplomatic non-answers. A woman sitting next to me leaned over and whispered, "Wrong question." She was right.
The role barely existed ten years ago
It's easy to forget how fast this happened. Five years ago, product management was widely described as misunderstood and understaffed, a function with nebulous responsibilities that most organizations couldn't quite place. Now it's one of the most in-demand jobs in tech. Salaries have climbed steadily. Every startup wants one, and every enterprise is hiring five.
But the surge in demand has outpaced clarity about what the role actually requires. Too many job descriptions still read like a wish list: technical enough to talk to engineers, creative enough to talk to designers, strategic enough to talk to executives, and somehow also the person who updates Jira. That's not a role. That's four roles wearing a trench coat.
Systems thinking is the actual differentiator
The PMs I admire most in 2019 aren't defined by whether they can write Python. They're defined by how they see the product.
They think in systems. They notice that a change to the onboarding flow will affect activation metrics, which will shift how customer success prioritizes their queue, which will change what feedback gets escalated to the product team. They see second-order effects before they become second-order problems.
I learned this the hard way at a previous job. We were redesigning our notification system, and I was focused on the user-facing piece: frequency, copy, channel preferences. Clean project, well-scoped. What I missed was that the notification system was downstream of three different teams' event triggers, and nobody had aligned on what constituted a "meaningful" event. We shipped a great notification experience on top of a fragmented data layer. Users got better-designed interruptions, but more of them. It took a systems-level conversation, one I should have started weeks earlier, to untangle it.
Data as a decision-making input, not a reporting artifact
The other shift I'm watching is how PMs use data. Product cycles are getting shorter. The tools for experimentation are more accessible than ever. And the PMs who are thriving treat data as a way to make faster, sharper decisions, not as a dashboard they review on Mondays.
This sounds obvious, but the gap between "data-informed" and "data-presented" is enormous. I know teams that run dozens of A/B tests a quarter but struggle to articulate what they've learned. The experiments run, the numbers get reported, and then someone senior makes a gut call anyway. The PMs driving real impact are the ones who can translate a test result into a strategic recommendation, connecting what the data says to what the team should do next.
The question that actually matters
So, should PMs learn to code? If it helps you understand your product and communicate with your team, sure. But coding is a tool. Systems thinking is a lens. And in a world where product ecosystems are getting more complex, where stakeholder alignment is a first-class challenge, and where the distance between a feature decision and its downstream consequences keeps growing, the lens matters more.
The PMs who stand out in 2019 aren't the ones who can write SQL. They're the ones who know which question to run.