The specialist PM is having a bad year
AI is multiplying decisions and shrinking the pieces they come in. The single-domain career was built for neither.
Sunday morning I opened my laptop expecting a victory lap.
I’d spent a few weeks building an AI app — the rolodex reimagined for people who want help maintaining relationships, not another social network to feed. By the second week I had auth working, password resets wired, and a rudimentary AI agent producing qualified output against a contact database. Work that would have taken weeks a few years ago, and required multiple specialists, had taken a few days.
I made coffee, sat down, and found a longer to-do list than I’d started with.
The V1 worked, and that was the problem. With the core shipped, the next layer of questions moved to the front of the line: prompt injection, jailbreak hardening, token gating so a single curious user couldn’t run up a four-figure bill against my account in an afternoon. None of these had been on the list a week earlier. All of them needed a decision.
Having a backlog wasn’t new. Any seasoned engineer will tell you the work is never done — there’s always a queue of new requirements stacked on a standing backlog of bugs, and shipping one thing only surfaces the next three. What had changed by using AI was the speed: the backlog emptied and refilled before I could catch up with it. The hours AI saved on coding hadn’t returned to my calendar. They’d gone somewhere else: into deciding what to build next, what to harden, what to defer, and whether the thing I’d just shipped was actually safe to put in front of a stranger.
This is the part the trending takes on AI and product management are missing. Doomsayers claim AI is coming for product management — that as engineering velocity rises, fewer product decisions are needed, and by extension, fewer PMs.
I don’t see it. The decisions didn’t shrink. They first reshuffled, and then they multiplied.
And it isn’t just one person’s Sunday. The broader 2026 data points the same direction: PM openings are at the highest level in three years, the demand for builders is rising, and the work is multiplying with it. What I ran into that morning — the work expanding to fill the time the tooling saved — is showing up across the discipline.
There’s an obvious objection: PMs are getting laid off right now, in large numbers. But those cuts are a balance-sheet story, not a verdict on the work — and as I’ve argued elsewhere, the roles cut by mistake tend to come back. The signal is in fact running the other way: the work that survives demands more judgment per hour, not less.
There’s a 19th-century version of this phenomenon.
In the late 1800s, William Stanley Jevons studied steam engines and expected efficient ones to reduce England’s coal consumption. What he found was that the technology did the opposite. Cheaper steam meant more factories, more rail, more uses that hadn’t been economical before. Efficiency expanded the market rather than shrinking it.
Cheaper engineering is doing the same thing to product work right now. Categories that barely existed as line items two years ago — prompt regression testing, agent reliability, token budgeting, abuse detection — have moved from “out of scope” to “ship-blocking.” Making one bottleneck cheaper shifted the bottleneck to whatever it was complementing. In software, the thing engineering was always complementing was judgment.
Walk through any tech company’s PM staffing strategy from the last decade and you’ll see the same pattern. Growth PM. Payments PM. Onboarding PM. Each specialization made sense when the unit of work was large enough to sustain a focused career — when “Growth” meant a quarter of experiments and “Payments” meant an eighteen-month migration.
In the generalist era, the speed of backlog throughput is skyrocketing. As a result, there is more work — yet work no longer arrives in chunks big enough to occupy a single-domain career. Previously, an onboarding specialist might have had months of work queued up; OAuth alone might run six weeks, and the PM thought about onboarding strategy while engineering built. When OAuth takes a day, that window collapses. Now they have a day, then they’re idle in their domain while five other domains pile up. The volume went up; the contiguity went away.
The market is already picking this up, though it files it under a different name. The pattern getting reported across 2026 is a K-shape: hiring demand surging at two poles while the mid-level middle hollows out. Read quickly, that looks like a story about specialists winning. But look at what both surviving poles have in common. They’re organized around judgment: deciding what to build at one end, deciding where to route at the other. The role hollowing out in the middle is the single-domain PM whose work used to arrive in contiguous blocks. The bifurcation is the symptom. The collapse of the contiguous block of work is the cause.
The specialist model didn’t arise in a void. Anyone who’s spent real time in software knows the pattern: management likes to move people between products like interchangeable checker pieces, and the experienced ones know it doesn’t work that way. Specialized knowledge is earned. The case for deep expertise is real — complex domains require it, and a generalist who knows a little about everything can ship something dangerous in a domain they don’t fully understand. Payments compliance isn’t something you skim a doc and decide on. Neither is agent safety. The risk of the generalist era isn’t that work slows down. It’s that work speeds up past the point where anyone notices what’s been waved through.
The new generalist can’t be a dilettante.
In the generalist era, the specialist doesn’t vanish. They stop being the default way you staff a team and become the depth a generalist knows when to reach for. The generalist who emerges from this era has to be someone who knows what they don’t know, fast enough to call in the right specialist or AI agent before shipping something they shouldn’t. The skill isn’t breadth over depth. It’s the judgment layer sitting above both: knowing when the work needs breadth or depth, and switching cleanly.
Delegate, decide, dig in. That triage is the job. The functions are interchangeable; the call about which one to make is not.
The closest analogue isn’t another kind of PM. It’s a small-org CEO — not in span of control, which is a separate conversation, but in the fluidity of knowledge required to operate. A CEO pulls from multiple disciplines at once. They don’t need to know engineering as deeply as a CTO or finance as deeply as a CFO, but they need enough fluency across functions to recognize, in real time, when to delegate, when to decide, and when to go deeper.
The measure of a good generalist PM in 2026 isn’t how much they already know. It’s how fast they can come up to speed on an unfamiliar domain, how well they can work with the AI agents now doing first-pass work, and how reliably they can decide whether to ship, push back, or escalate.
If the decisions multiply and judgment is the binding constraint, the headcount math runs opposite to the doomsayer’s prediction. The work calls for more people who can make the call, not fewer. The doomsayers counted the decisions that got cheaper and missed the ones that got created.
This rewrites the hiring question. “Give me examples of your last projects and how you succeeded” is a specialist question, built for an era when projects ran long enough to be told as stories. The question now is closer to: “Walk me through the last unfamiliar domain you came up to speed on, and how you decided what to ship.” It’s the instinct behind the case-study interview — drop someone in front of unfamiliar territory and watch them navigate. But the case study as most teams run it has drifted into pattern-matching against consulting frameworks, and the candidates who do well are the ones who’ve memorized the moves. A question that actually tested the new cadence would throw an unfamiliar domain at the candidate halfway through, and grade the switch.
The PMs worth hiring in this market are the ones who can walk through that without flinching.
The backlog isn’t dead. The specialist might be.
Leif, well put. I look at this as the era of the super-generalist. Everyone is looking for the team member who brings specialist knowledge of every domain. There maybe a few polymaths who possess the such deep knowledge. But the realistic solution, is team members who have the breadth of knowledge to identify the traits of a specialist solution in a given problem domain.
What puzzles me is why the ability to write more code quickly hasn't resulted in more pair coding or pair prompting, as the risk of not defining the solution correctly grows with the speed to market.