The PM Role Isn't Dying. It's Being Rebuilt From Scratch.

The PM lifecycle assumed clean lanes between PMs, designers, and engineers. That model is breaking fastest at the companies setting the pace, and the hiring loop is finally catching up to a job that no longer looks like the framework it screens for.

Published: 2026-05-05

Sometime last year, a VP of Product interviewing me for a startup role asked me to walk through the Product Management Life Cycle. I've heard versions of the same question many times since, usually from HR screeners at both early and late stage startups.

I paused the first time, but not because I didn't know the answer. I've lived inside that lifecycle for six years, moving products through discovery, definition, design, development, deployment, and measurement. I could have drawn the whole thing on a whiteboard in my sleep.

I paused because reciting it felt dishonest. The lifecycle assumed a specific division of labor, where product managers owned the what and the why, designers owned the look and feel, and engineers owned the how and the when. Everyone had a lane, and the PM's job was to keep everyone in theirs, in sequence, on time. That's a structure built for 10,000-person coordination, which makes it a strange thing for a startup to screen for.

That model is breaking, and it's breaking fastest inside the companies that set the pace for everyone else.

What I've Been Watching

Over the past year, I've noticed a pattern by hearing the same thing from friends across very different roles in tech. An engineering manager, a few engineers, and a data scientist at a big tech company have all told me recently that they spend a meaningful part of their week functioning as product people. They're defining and designing what they offer to others, deciding what should exist, who it's for, and how it should work, often without a product manager in the room.

If that's true, then everyone can be the PM. The skills that used to make the role legible, like framing problems, writing requirements, and making product calls, are now distributed across the team. I don’t see it as a threat to my profession. But it's a real question about what a PM actually is in the AI age, and what we're being hired to do that the engineer or the data scientist next to us can't already do for themselves.

I thought this was just a personal observation at first, but then I started listening more carefully to what practitioners at the frontier were saying out loud. Three patterns kept showing up across very different companies and roles.

The Work Has Changed. The Hiring Hasn't.

The old model moved in a clear sequence. Strategy came first, then spec, then design, then engineering, then launch. The PM sat at the front of that line, turning goals into requirements, while designers turned requirements into interfaces and engineers turned interfaces into software. Each handoff introduced a delay, and each delay added more chances for the original idea to drift before it shipped.

What's replacing that sequence looks different. You start with intuition, then build a rough prototype, and only then decide whether to write a spec for it. The prototype itself becomes the decision point, and the spec, if it ever exists, comes after rather than before.

Just this April, Alex Embiricos, the product lead for Codex at OpenAI, described this directly on the Behind the Craft podcast. For specs, his team writes about ten bullets and that's it. Their designers now write more code than engineers did six months ago. They plan short term and long term, but never medium term, because the medium term roadmap doesn't fit how their team actually works anymore. The six month roadmap was always a fiction, and now it's an obviously expensive one.

That's how the work has changed. The hiring has not.

If you've been through a PM interview cycle recently, you know what I mean. There are courses, communities, and coaches dedicated to the CIRCLES method, the HEART framework, and the structured three-part answer to "how would you prioritize these three features?" Every major tech company's PM interview has been reverse-engineered into a formula, and you can buy it, practice it, and get quite good at performing it without ever having shipped anything. I don't think the people who built these resources were cynical. PM hiring at scale is genuinely hard, and there's no clean way to evaluate someone's product judgment in a one-hour interview. So companies standardize the interview by asking candidates to design an alarm clock for the blind, evaluate whether Spotify should enter the podcast market, or prioritize a backlog they've never seen, and they grade the structure of the thinking instead of the quality of the instincts.

The problem is that structure and instinct are different things. On teams that build before they spec, instinct is the job.

I've sat on both sides of this split during my own job search:

Big tech is already splitting on this internally. The same company runs both interviews in the same hiring season, and they paint two completely different pictures of what a PM is supposed to be.

What that split tells me is something honest about the framework-heavy interview. Rather than finding the best product person, it’s about producing a defensible hiring decision at scale, in a part of the organization where defensibility still matters more than surprise. The AI agent teams have quietly opted out, because they can't afford to hire for framework fluency when what they need is someone who has actually been in the room where fast, ambiguous, high stakes product decisions get made.

These frameworks systematically underweight taste, the willingness to just build something and see what happens, and comfort with ambiguity that doesn't resolve neatly. Those are exactly the qualities the new work demands. The people the standard process keeps out might be the ones it should let in. Take Zevi, the non-technical Meta PM who ships real software and has engineering teammates asking him for lessons.

It's fine if you want to work at a company built around the old model. I'm not sure I do anymore.

What This Means For The PM Role

A senior PM friend of mine described her team as one of the most aggressive about vibe coding. Small features get shipped directly by engineers, with product and design just doing a sanity check before launch. For polished work, product and design open the codebase and edit it themselves before merging in, instead of running eight rounds of "please change this copy." As a former engineer who'd transitioned into a PM role, she is now shipping production code again. She genuinely feels more occupied now than she did before.

Her experience tells me something important. The collapse of role boundaries hasn't reduced anyone's work. It has redistributed who does what, and the people who can move fluidly across the old boundaries are absorbing more of the work, not less. This is the lived reality behind the frontier observations. The role is being rebuilt while everyone is still doing their day jobs, often with more output expected, not less.

A founder I respect, who came up through engineering, said something to me recently about how AI changes the early stage of building a company. It clarified the answer I had been circling for months:

That conversation gave me a clean way to define what a product manager is in 2026. A PM runs the discovery, prototyping, and iteration loop themselves, while holding a coherent point of view about what the product should be. The job isn't writing requirements for engineers anymore, because the engineers are running their own version of that loop. It's closing the loop on your own slice of the work, contributing to a shared sense of where the product is going, and making sure the team is building toward something real instead of just building. That definition is uncomfortable for a lot of PMs, because the role is no longer protected by a clear handoff structure. Your contribution is the artifact, the working thing, and the judgment behind it. If you can't produce that, the engineer or the data scientist next to you can, and they will.

Nikhyl Singhal, a former product exec at Meta and Google who now runs The Skip, told Lenny in April that the next two years will be the most chaotic period in product management history. His prediction is that companies will shed 30,000 people and rehire 8,000, all of them AI-first. The PMs at risk aren't the ones who can't recite the lifecycle. They're the ones who can only recite it. The ones who survive close the loop themselves. They don't just identify problems and write requirements, they build artifacts, run experiments, and ship.

The time between "I think this is the right thing to build" and "let me show you what I mean" has collapsed from weeks to minutes. Cat Wu, the head of product for Claude Code at Anthropic, describes her team's cadence moving the same way at the team level, from months to weeks to days. The principle she keeps returning to is simple: just do things rather than plan to do things or align on doing things, and adjust as you learn.

I noticed this shift in myself recently, after a friend who works as a data scientist vented to me about a PM on her team who kept pinging her for basic analysis that wasn't really her job. That PM wasn't lazy. She was operating inside the old model. AI is now the first gate I go to whenever I need something, not because I'm avoiding my colleagues, but because the loop closes so much faster that going to a person before exhausting that route feels almost impolite.

This is what a build-PM actually is. It isn't a PM who knows how to write engineering tickets with acceptance criteria, but a PM who treats the act of building as a thinking tool rather than a final step.

The Mismatched Interview Question, Reconsidered

When that VP asked me about the Product Management Life Cycle, they weren't being malicious. They were screening for a role that made sense in a world that's fading, a role that coordinated specialists across a predictable sequence, managed handoffs, and kept a roadmap current. That role still exists at plenty of companies, but it isn't the role I want, and it isn't the role that's growing.

What's growing is something closer to what Amjad Masad, the CEO of Replit, described in a recent YC podcast. He sees a future where companies are organized around two functions, which are builders and the people who sell what builders make. The traditional PM, designer, and engineer have merged into a single practitioner who moves from idea to artifact to learning without waiting for a handoff.

I left that interview less interested in the role than when I walked in. I just realized I was being screened out by the right filter, in the wrong direction. The companies leaning on these frameworks tell us something about themselves, and the companies that don't tell us something too.

I'm a builder-PM based in the Bay Area. I write weekly essays on AI products and build independently while looking for the right founding team to join. If this resonated, or if you want to push back on it, I read every message.