From Customer-Led Development: How to Build What Your Customers Want When AI Can Build Anything — the operating manual for building what customers want when AI can build anything. See every chapter.
For decades, "product manager" meant whatever the company needed that quarter. Project manager on Monday, visionary on Wednesday, escalation path for angry customers on Friday. Nobody defined the job because nobody was accountable for defining it.
AI ended that ambiguity. And it didn't just make PMs faster. It split the job in two.
The shape-shifter job
Look at what companies quietly expected from one person with "PM" in their title:
- A project manager who keeps things on track
- A Steve Jobs visionary, minus the friction
- An engineering manager who couldn't code
- A product marketer who also does strategy
- The keeper of the roadmap spreadsheet
Companies said they wanted a PM. What they wanted was a shape-shifter. That worked, sort of, as long as the real bottleneck was elsewhere: engineering capacity, design bandwidth, the weeks it took to produce a competitive analysis.
Then the bottlenecks moved. Today a PM can draft a spec with Claude in an afternoon, prototype an interface with an AI tool, direct an AI coding assistant to write the code, and synthesize fifty customer calls before lunch. Work that used to take a team now takes one motivated person.
When one person can do that much, "do a bit of everything" stops being a job description. It becomes a choice about which everything.
The PM role is dead. Two new roles replaced it.
The two jobs
The split isn't senior versus junior, B2B versus B2C, or technical versus non-technical. It's about output. The two roles produce different things, need different skills, and should be measured differently.
| Full-Stack Engineering PM | Full-Stack GTM PM | |
|---|---|---|
| Focus | Outcomes | Revenue |
| Path | Idea → prototype → code → PR | Research → positioning → enablement |
| Owns | What gets built and whether it works | Positioning, pricing, and sales enablement |
| Measured by | Adoption, time-to-value, engagement, retention | Conversion, expansion, sales velocity |
The Full-Stack Engineering PM
This PM doesn't hand off a PRD and wait. They hear a need, prototype before involving design, build a working version before involving engineering, and put up the pull request themselves. Their currency is shipped features that customers actually use.
The Full-Stack GTM PM
This PM sits between product and revenue. They're on sales calls. They understand the comp plans. They know what the sales team needs to sell, and they make sure the product builds things that can be sold. They grow revenue without writing a line of code.
One customer call, two PMs
Here's what the split looks like in practice. Same company, same customer call, same complaint surfacing on a Tuesday.
The Engineering PM hears it and opens a prototyping tool that afternoon. Their week ends up sounding like this:
"A customer mentioned this problem on Tuesday. I had a prototype by Thursday. We shipped on Monday. Here's the usage data."
The GTM PM hears the same call and notices something else: the way the customer describes the problem doesn't match anything in the sales deck. They dig into the pipeline, find the gap in enterprise positioning, rebuild the deck, retrain the team. A quarter later: "Conversion went up 15%."
Neither of them waited for resources. Neither was blocked by another team. And neither could have done the other's work nearly as well.
That's the point. These aren't two flavors of one job. They're two jobs.
What unites them: customers
Both roles live or die on the same thing: whether customers actually drive their decisions.
An Engineering PM without customer connection is a fast way to build the wrong thing. AI tools amplify that failure. You can now ship unused features at record speed.
A GTM PM whose product team doesn't listen sells vapor. The positioning is beautiful, the deck is sharp, and the promises won't be kept.
The Engineering PM delivers value to customers. The GTM PM makes sure customers receive and recognize that value. Between them, they cover the four metrics that matter: retention and engagement on one side, conversion and expansion on the other. Separately, each moves only half.
Rule of thumb: Don't hire one type expecting them to do both, and never evaluate one on the other's scorecard.
A great Engineering PM might be terrible at sales enablement. A great GTM PM might not be able to write code. That's fine. Judging the first by pipeline numbers, or the second by PRs merged, is how you burn out good people.
The end of the vanilla ice cream PM
If you're a PM, you're probably already asking: which one am I?
A quick tell: are you energized by shipping, or by understanding why people buy? Do you get frustrated when you can't build something yourself, or when the sales team can't explain what you built?
Neither answer is better. Both roles are needed. But trying to be both at once usually means being mediocre at each. That's the vanilla ice cream PM: the generalist flavor everyone tolerates and nobody orders.
Pick your lane. Get great at it. The other type needs you.
For the diagnostics on which type your team is missing, how to tell which one you are, and the customer system both roles depend on, read Customer-Led Development.
If the idea of picking a lane instead of wearing every hat resonates, subscribe to the Context Limit newsletter for more essays on how product work is changing.