# Product management is splitting in two

- Author: Geoff (geoffsdesk)
- Published: 2026-10-24
- Canonical: https://www.geoffsdesk.com/human/blog/product-management-is-splitting-in-two
- Tags: product-management, ai, infrastructure, product-engineer

> Pragmatic Marketing drew the PM job as a spectrum from market problems to sales enablement in 1993. For thirty years the industry hired people to stand in the middle of it. AI is pulling that middle apart, and I picked the engineering end.

The first time I sat through Pragmatic Marketing's introductory course the thing that struck me wasn't any one box in the framework. It was the shape of it. [The Pragmatic Framework](https://www.pragmaticinstitute.com/product/framework/) runs 37 activities across seven columns, starting at market problems and win/loss analysis on the left and ending at launch plans, sales tools and channel training on the right. Even the name told you which way it leaned. The company renamed itself [Pragmatic Institute in 2019](https://www.pragmaticinstitute.com/about-pragmatic/), but the framework is still a map of product marketing with requirements bolted into the middle.

What the framework never had a column for was the other pull on the job: the one toward engineering, architecture and the systems the product actually runs on. That pull was always there. I've been lucky enough to work at both ends of it, carrying a sales pipeline on one side and arguing over API shapes and control plane internals on the other.

I've ALWAYS believed product management needs an anchor. Either you sit on the marketing end and carry a number the way a salesperson carries quota, so your work is tied directly to revenue, or you sit on the engineering end and are accountable for the system itself and for the experience of using it: how it runs, what it costs, what it feels like in the user's hands and what happens when it fails. Domain depth still matters on that end, for now, but its weight is shrinking, and I'll get to why. The PM in the middle, who translates between customers and engineers and writes the document that connects them, has always been the weakest position on the spectrum. AI is now taking that seat away.

## The two anchors, before AI

The marketing anchor at scale looks like Airbnb. The internet version of the story is that Brian Chesky fired his PMs in 2023. His own version, on [Lenny's podcast that November](https://www.lennysnewsletter.com/p/brian-cheskys-contrarian-approach), is more precise: inbound product management was folded in alongside outbound product marketing; program management went to dedicated program managers; the team got smaller and more senior. That is a company deciding that the PM's anchor is the market and the message. Period.

The engineering anchor at scale was harder to find a decade ago, but it existed. Gergely Orosz described the [product-minded engineer in 2019](https://blog.pragmaticengineer.com/the-product-minded-engineer/) as the person who challenges the spec, proposes the alternative and ends up the PM's most valued partner. PostHog went further and [hired for it](https://posthog.com/careers/product-engineer): their product engineers originate ideas, talk to users, ship to production, own pricing and do support rotation (hold the pager), and the handbook says plainly that [engineers lead product teams](https://posthog.com/handbook/product/product-team). Linear ran with [a single PM](https://youtu.be/4muxFVZ4XfM?t=1001). Ramp got to $100M in ARR with [fewer than five PMs and fewer than fifty engineers](https://www.lennysnewsletter.com/p/how-ramp-builds-product), and only hires product once it's clearly the velocity bottleneck.

None of that needed AI. It needed small teams and founders who refused to pay for a translation layer.

## What AI changes

Translation is exactly what the models do. The spec used to be the PM's unit of output because a spec was cheaper than code. That inverted. A working prototype is now cheaper than a well-written document about one, and the prototype doesn't need a meeting to be understood.

The numbers are moving fast, so don't get hung up on the decimals. Look at the direction. Mike Krieger said in June 2025 that [around 90% of Claude's code was being written by Claude](https://lennysnewsletter.com/p/anthropics-cpo-heres-what-comes-next), and that the bottleneck had moved to deciding what to build and getting it merged. Two weeks later Andrew Ng told YC's AI Startup School that [one of his teams proposed going from one PM per four engineers to one PM per half an engineer](https://www.youtube.com/watch?v=RNJCfif1dPY&t=1026s), because coding had sped up and product decisions had not. He wasn't sure it was a good idea. Neither am I, but the direction is right.

On the PM side, Lenny Rachitsky's [December 2025 survey of 1,750 people](https://www.lennysnewsletter.com/p/ai-tools-are-overdelivering-results) found PMs using AI mostly for PRDs (21.5%) and prototypes (19.8%), with 44.4% naming prototyping as the thing they want to do next. The spend tells the same story from the other side: Cursor passed a [$4 billion run rate in June 2026](https://dealroom.co/news/134107-cursor-tops-4b-annualized-revenue/) and Anthropic closed its Series H in May 2026 at a [$965 billion valuation](https://www.anthropic.com/news/series-h) on a run rate past $47 billion, three months after Claude Code alone was [past $2.5 billion](https://www.anthropic.com/news/anthropic-raises-30-billion-series-g-funding-380-billion-post-money-valuation). There's a [VC-sponsored survey](https://finviz.com/news/357390/2026-cpo-insights-report-predicts-product-managers-will-disappear-by-2030) claiming "product builder" roles grew tenfold in a year while traditional PM roles fell 30%. The same report has PMs gone by 2030. I don't think anyone thought that one all the way through. This is headliner shit, but it points the same way the real surveys do.

Userpilot called it in May 2026: the generalist PM is [splitting into a Builder-PM and an Integrator-PM](https://userpilot.com/blog/product-management-trends/), with the integrator drifting toward product marketing and the middle shrinking. That is the bifurcation, and it's the same two directions I saw in the shape of the Pragmatic framework the first time I sat in that classroom: the market columns on one side, the engineering work that never got a column on the other. Marty Cagan called the middle [product management theatre](https://www.youtube.com/watch?v=9N4ZgNaWvI0) two years ago: PMs who are really project managers, running standups and writing tickets. That is the part of the job a model does first and does without complaint.

## Where the moat goes

Knowledge is becoming abundant, and the moats built on it are going with it. Two cases from outside software make the point better than anything inside it. In September the founder of a pedal company published [Firmware freedom](https://playtaurus.com/blog/firmware-freedom), pointing out that the amp models are open source, the capture libraries are free, and a $4 ESP32-P4 now runs two full-size models at once and out-does the proprietary DSP chips, so the only closed part of a guitar pedal is the firmware, and it stays closed because it's the only thing left to close. The Klon was a moat for twenty years because the circuit was gooped. Nobody goops anything anymore. In April, researchers at Calif [gave Codex a foothold in a Samsung TV's browser](https://calif.io/research/samsung-tv) along with the matching source tree. It found a kernel driver that let user space map physical memory, scanned RAM for the browser's credential structure, zeroed it and spawned a root shell. The humans steered it with short prompts.

Reverse engineering was always possible. Klon clones existed long before anyone said the word agent. What changed is that the cost of doing it fell to roughly the price of the tokens, and the skill floor fell with it. A model will now explain any system to anyone. So knowing how a system works isn't an anchor either; it has a shelf life. The moat moves to whatever stays expensive to copy when the knowledge is free, and in software that is two things. On one side, distribution and trust: you still have to get the thing in front of the buyer and get them to believe you. On the other, operation and cost: you still have to run it, cheaper than the next person, without it falling over. I argued earlier that [the token is the kilowatt hour](https://www.geoffsdesk.com/human/blog/token-economics). The moat was never the physics of electricity. It's owning the grid.

Over the past year I've tossed an informal thought experiment at a bunch of industry leaders, and a pattern emerged. Give the CEO five points to spend across the primitives of the business: their edge or alpha, their operations, their customer acquisition with retention and service rolled in, and the substrate the business runs on, whether that's a cloud, a manufacturing line or a fleet of trucks. Most of them load up on alpha. Most put about half a point on substrate. The half point is sane. The entire pitch of a cloud or a contract manufacturer is that you get to under-spend on substrate; that's the deal, not a mistake. But look at it from the provider's side. It spends four of its five points on exactly the thing its customers spend half a point on. The relationship is codependent and asymmetric, and the real terms aren't in the SLA. They're whatever the provider can't buy enough of this year.

![Where the CEO spends five points, today and where it is heading: alpha 3 to 1.5, acquisition and service 1 to 1.5, ops 0.5 to 1, substrate 0.5 to 1](/images/ceo-five-points.svg)

Two things follow. Alpha is mostly knowledge, which means the points spent there buy less every quarter while the half point on substrate buys more. That allocation made sense when knowledge was scarce. And the half point is about to stop being half a point, because the alpha now runs on inference. A CEO who thinks they're spending on their edge is spending part of it on tokens, accelerators and the network between them, which is the grid. They're re-weighting toward substrate without having decided to, and nobody on their side of the table is watching the line item.

Map the four primitives onto the PM spectrum and the split is already drawn. Acquisition, retention and service is the marketing anchor. Operations and substrate are two separate points, and both belong to the engineering end. Alpha is the middle, and the middle PM had neither of the durable things; they had knowledge of the customer and knowledge of the system, and both just became cheap.

![Where PMs sit today and where they end up: a spectrum from quota to the metal, the middle emptying into the marketing anchor on one side and the engineering anchor on the other](/images/pm-spectrum.svg)

## What a product engineer actually owns

A product engineer holds decision rights over what gets built and over how it gets built at the layer that matters: the API shape, the data model, the tenancy boundary, the failure modes, the user experience. That is a different job from a PM who vibe codes a demo or an engineer who was handed the roadmap. They do the discovery, talk to the people who use it, make the architecture call, build the first working version, write the evals that prove it does what it claims, know its cost and latency per request, and carry it into operation. The distance between a demo and something that survives production traffic is where the value lives, because it's the part the models still get wrong and the part a customer actually pays for.

The expensive input to software used to be the code. Now it's the decision, and the verification of the decision. Jeremy Freeman at Allstacks [collected the historical ratios](https://www.allstacks.com/blog/rethinking-the-pm-to-engineer-ratio-for-the-ai-era) and forecasts compression to one PM per three or four engineers. I think that undersells it. Each handoff between a PM, a designer and an engineer was a tax we paid because no single person could hold the whole problem. When one person can, the tax goes away, along with the headcount that collected it. There's a cost on the other side of that ledger and Jenny Wanger's [Denver panel in October](https://jennywanger.com/articles/building-alone-faster/) named it: AI is single-player, so everyone builds alone, and one PM burned 30 hours on a prototype that ignored the design system. The product engineer is the answer to that too. You can only build alone safely if you're anchored in the system rather than standing next to it.

The skills are the ones infrastructure engineers have always had and PMs have always been allowed to skip. Read a design doc and know where the state lives and what breaks under load. Know your domain well enough that the model's confident wrong answer is obvious to you, for as long as that still counts for something. Write an eval before you write a feature. Pull your own numbers with SQL rather than asking for a dashboard. Treat cost and latency per request as product metrics, not someone else's SLO. Read every pull request even when the agent wrote it. The tools follow from the skills: a terminal and a git workflow you are fluent in, one of the agentic coding tools, an eval harness, the observability stack your engineers use, direct access to the warehouse, a local cluster or sandbox you can break, and whatever protocol your company uses to wire agents into its internal systems. None of that is exotic. It's the standard kit of a senior engineer, and the point is that a product person now has to carry it.

## The counterarguments

One of the counterarguments is Roman Pichler's, from [April 2026](https://romanpichler.medium.com/should-product-managers-be-product-builders-beab955be6dd): PMs who build neglect strategy, accumulate tech debt and burn out, so building should stay a side activity. Ant Murphy adds [the numbers](https://www.antmurphy.me/newsletter/how-product-is-changing-in-2026): about 42,000 open PM roles on LinkedIn at the start of 2026, roughly double the year before, and 59% of respondents naming strategy and business acumen as the skills that matter. Felipe Barreiros argues [the two roles aren't rivals](https://www.product.engineer/blog/product-engineer-vs-product-manager) and that the PM's coordinating work grows with scale.

Where I get tripped up is that every one of those defences describes an anchor. Strategy, business acumen and cross-team coordination are the marketing end of the spectrum with a different label on it. If that's your job, carry the number. What none of them defends is the position in between, and that's the position most of the open roles are still written for. The 42,000 postings tell you demand for the title is up. They don't tell you how many of those jobs will exist as written in three years.

I'm not claiming the engineering end is better or more noble. Someone has to own the revenue and the message, and the people who do it well are rare. It's just not where I'm going, and it's not where most of the PMs I work with should go either. Their value is in being accountable for how the system runs.

## What to watch

Three signals will tell you whether this is a real split or a fad that stays inside the valley. Watch the PM to engineer ratio in job postings at companies with more than 1,000 engineers; Ramp and Linear proved it at startup scale and the question is whether it survives the enterprise. Watch for PM postings that require commits to the repo rather than the usual "technical background preferred". And watch Pragmatic Institute. The day the framework gets a column for building is the day the marketing side concedes the engineering side exists.

I've chosen my camp. It's the one close to the metal, on the infrastructure under all of this, including the models. The metal is valuable because it's hard to operate, hard to pay for and hard to replace, and understanding it stopped being the hard part. Thirty years after someone drew the spectrum, you have to pick an end.