Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
For months now, developers have been interviewing customers without going through the Product Manager.
And three days ago, I pushed my first pull request to our main product.
These two sentences describe better than any analysis what is happening in product teams with AI. Developers are moving upstream toward the problem, the customer, and product ownership. PMs are moving downstream toward the prototype, the code, and sometimes production.
You might see these as two isolated anecdotes. I think they mark the beginning of a deeper inversion. The historical roles of product management, development, and design are becoming less clear-cut. Boundaries are moving. But contrary to what one might assume, this doesn't mean everyone will do everything, or that responsibilities will disappear.
The real story isn't that AI makes teams "more productive." The real story is that it significantly raises the capacity to produce. And when the capacity to produce increases, the bottleneck moves.
Before, the constraint was often: "How much can we build?"
Tomorrow, it becomes: "What should we build? Why? For whom? In what order? With what risks?"
That shift is what blurs the roles.
When Developers Produce More, the PM Becomes the Bottleneck
The trigger is fairly simple: with AI, developers can produce faster.
Not just write a few lines more quickly. They can produce more options, more variants, more prototypes, more internal tools, more initiatives. A developer who was already autonomous may find themselves moving three, four, or six times faster on certain tasks. A team with a limited delivery capacity can suddenly generate far more things to test, prioritize, review, and arbitrate.
The problem is that the capacity to decide doesn't increase at the same rate.
If everything still has to go through the PM, they quickly become the new saturation point of the system. The job is no longer just writing specs or managing a backlog. The load shifts toward prioritization, product coherence, customer signal validation, market arbitration, user impact, strategy, and managing consequences.
An organization may believe it has solved its speed problem because developers are producing more. In reality, it has simply moved the bottleneck.
There are three possible responses.
The first is to hire more PMs. Sometimes necessary, but not always the right answer. If the model stays the same, you're just adding another layer of arbitration.
The second is to automate part of the PM's operational work: documentation, release notes, launch materials, initial analyses, translations, summaries, demo videos, screenshots, PR content. This frees up time but doesn't solve the underlying problem.
The third is to redistribute part of the product ownership to those who build. That's where roles genuinely start to blur.
Accelerating Code Isn't Enough
It would be a mistake to think AI transforms organizations only by accelerating development.
Local speed doesn't automatically create value. It can actually create more disorder if the full workflow doesn't change. A team can generate more code, more prototypes, more documents, and more tickets while making worse decisions.
The entire flow needs to be rethought: idea, discovery, specification, prototyping, development, testing, security, launch, communication, support, and learning.
Adding AI agents to an unchanged process just risks moving bottlenecks around. Code accelerates, then product blocks. Product accelerates, then design blocks. Design accelerates, then technical validation blocks. Validation accelerates, then go-to-market or support can't keep up.
The question isn't just: "How do we make developers faster?"
The question is: "How do we make the entire system capable of absorbing this speed without losing quality, coherence, and accountability?"
That's why the new roles don't reduce to "PM who codes" or "developer who does product." Some of the new needs are about workflow orchestration, AI output evaluation, product memory, decision quality, repo readability, and the ability to give agents reliable context.
What AI Commoditizes in Product Management
For a long time, PMs differentiated themselves through fairly distinct sensibilities and skills.
Some were very strong writers. Others in data. Others in benchmarking, product marketing, discovery, experience design, or delivery coordination. These differences don't disappear entirely. But part of their differential value is dropping.
With AI, many capabilities become more accessible:
- writing a solid spec;
- producing an initial data analysis;
- running a benchmark;
- writing a release note;
- producing a passable mockup;
- synthesizing interviews;
- producing a first-draft user journey;
- turning a need into a prototype.
These skills don't become useless. A PM still needs to know how to assess a spec, challenge an analysis, read a mockup, understand an interview synthesis, or evaluate a prototype. But the initial production of these artifacts becomes less scarce.
Before, a PM could be strongly differentiated by their ability to quickly produce a good spec, a clear benchmark, a usable summary, or a first mockup. Tomorrow, that will be closer to the minimum bar.
This puts at risk the PMs who were primarily strong through intermediate execution capacity. Those who coordinated, wrote, administered, tracked, reformulated, and produced correct artifacts without carrying a strong product judgment risk losing part of their value.
The product role isn't disappearing. But its minimum bar is rising.
What Remains Hard: Product Judgment
When producing becomes easier, choosing what to produce becomes more critical.
That's where the PM role retains its value. Not in the ability to generate more artifacts, but in the ability to choose, arbitrate, and own the consequences.
What remains difficult:
- choosing the right problem;
- understanding a market;
- reading the real signal behind customer requests;
- arbitrating between short term and strategy;
- saying no;
- holding a coherent vision;
- creating alignment;
- owning the product, business, technical, and human consequences of a decision.
The augmented strategic PM increasingly resembles a kind of small CPO. Less in delivery administration, less in the mechanical production of deliverables, and more in the trade-offs where no option is perfect.
The role becomes especially important when there is no good solution. Only two or three bad options, with different costs, different risks, different political effects, different customer impacts. In those moments, AI can help analyze. It cannot own the outcome.
The augmented PM isn't simply a PM who moves faster. It's a PM who needs to judge better.
Differentiation Shifts Toward the Customer Signal
If everyone can build faster, building fast is no longer a sufficient advantage.
Raw code production becomes partly a commodity. Not the software. Not the engineering. Not the architecture, security, or maintainability. But the ability to quickly produce a first version becomes less rare.
Real differentiation shifts toward what competitors can't simply generate:
- the quality of the customer signal;
- proprietary data;
- domain knowledge;
- distribution;
- trust;
- operational constraints;
- accumulated learnings;
- the ability to correctly interpret what customers actually want.
A fast prototype only has value if it tests a real signal. Otherwise, it only accelerates a bad direction.
The strategic question becomes: on what proprietary advantage are we building?
An AI-augmented team can produce a lot of things. But if it doesn't read its market better, doesn't understand its users better, can't distinguish a strong signal from a well-phrased noise, it will only produce mediocre things faster.
That's another reason why the PM doesn't disappear. The role shifts toward the quality of reading reality.
Developers Moving Up Toward Product
Developers were never pure executors.
A complete specification is a fiction. Even a good spec never describes all the expected behaviors of a product. There are always silent zones: edge cases, error messages, implicit behaviors, security rules, timeouts, invisible priorities, micro-interactions, fallback decisions.
In those zones, developers are already making product decisions.
AI makes this reality more visible. If an agent writes part of the code, the human must make the expected behavior explicit, arbitrate edge cases, define acceptance criteria, verify the result. The micro-decisions that were silently absorbed in implementation become more visible — and therefore more important to frame.
This is one reason why developers are moving up toward product. They talk more to customers, understand problems better, carry more ownership over their features, make local decisions more explicitly.
But there's an important nuance: a developer doesn't become a product engineer just because they use a code agent or ship faster.
Without access to customers, data, business context, and trade-offs, they risk becoming an AI agent operator. More responsibilities, more pressure, but not necessarily more product power.
The real product engineer isn't just a fast developer. It's someone who carries part of the product judgment as close to construction as possible.
PMs Moving Down Toward Construction
The reverse movement exists too.
With AI, a PM can materialize an idea much faster than before. A mockup, a prototype, an internal tool, a dashboard, a translation, an interface change, sometimes even a supervised PR.
This changes the nature of the work.
Before, you often had to go through a long sequence: formulate the need, write the spec, make a mockup, ask for an estimate, wait for a slot, get it developed, test, adjust. Today, on certain topics, you can move much faster from intuition to a tangible artifact.
And sometimes, it's no longer just about prototyping. On simple or well-framed cases, you can code something nearly real: a dashboard, a read-only screen, an interface improvement, an internal automation, a translation, a release support.
This doesn't mean the PM becomes a developer in the classical sense. It means they can intervene in construction zones that were previously outside their perimeter.
A few levels are worth distinguishing here.
The prototypist PM or PO transforms a business intent into a prototype or POC.
The Product Builder goes further: they build tangible artifacts, internal tools, dashboards, first versions, supervised contributions.
The Product Engineer goes further still: they can carry product responsibility all the way to a production deliverable. And this role can come from two paths — a developer moving up toward product, or a sufficiently technical product profile moving down toward production.
The criterion isn't the background. The criterion is the level of capability to act.
Does this person stay at the mockup level? Do they produce a prototype? Do they open a PR? Do they carry a production-ready deliverable? Do they understand enough about the risks to properly validate what they produce?
That continuum is what's new.
Roles Blur, Responsibilities Remain
The risk would be to conclude that, since roles are blurring, responsibilities are dissolving.
I think exactly the opposite.
The more roles blur, the more responsibilities need to be clarified.
A product decision is still a product decision. It belongs to product: vision, positioning, coherence, trade-offs, guiding principles, market reading, customer signal.
A technical decision is still a technical decision. It belongs to engineering: security, performance, scalability, architecture, maintainability, platform quality.
An experience decision is still an experience decision. It belongs to design or front-end: design system, usage coherence, accessibility, UX standards.
The organization that works isn't the one where everyone does everything on their own. It's the one where anyone can intervene beyond their initial domain because owners set the standards, guardrails, and limits.
A PM can push a PR. But it gets reviewed, accepted, corrected, or rejected.
If it gets rejected ten times in a row, that says something. Maybe the PM doesn't yet have the level for that type of contribution. Maybe the topic is too risky. Maybe the engineering team hasn't yet put in place the guidelines, tools, or guardrails that allow other profiles to contribute safely.
The PR or MR then becomes a governance mechanism. Not just a technical tool.
Everything Depends on the Competence / Risk Pairing
The right question isn't: "Can a PM push to production?"
The right question is: "In what perimeter, with what competence, what risk, and what guardrails?"
A simple gradient applies.
Low risk: translations, content, dashboards, read-only screens, non-critical internal tools.
Medium risk: small write actions, internal workflows, supervised interface changes.
High risk: payments, permissions, security, sensitive data, critical business logic, regulated product, architecture.
Even in a regulated product, not everything carries the same risk. A dashboard or a read screen can be relatively safe if the rules are clear and technical validation is present. Conversely, an apparently simple product can hide a very sensitive zone if it touches data, permissions, or an irreversible business decision.
The junior developer analogy is useful. You don't hand someone the keys to the product engine on day one. You start with simple perimeters, then expand progressively.
The augmented PM can follow the same logic: translations, read-only, dashboards, small writes, and eventually more critical contributions if the competence, context, and guardrails are in place.
The Fracture Between PM Profiles
Not all PMs will be able to become builders or product engineers at the same pace.
In the short term, PMs with a technical background have an advantage. They can read a repo, understand an error, dialogue with a code agent, interpret what was generated, spot certain absurdities, ask for a technical review at the right moment.
A PM without that culture can certainly learn. But they risk being limited to mockups or superficial prototypes for as long as they don't understand enough of what AI produces.
AI is still too unreliable to completely ignore what's happening under the hood. If you don't have at least a minimal understanding of the errors being produced, it becomes difficult to go beyond the reliable mockup.
This doesn't mean non-technical profiles are condemned. Over the medium or long term, the opposite may even emerge. If agents become much more reliable, profiles from psychology, literature, philosophy, design, research, or business could gain the advantage through their ability to finely express human, social, or domain realities.
But in the current state of the tools, the fracture exists.
PMs who don't want to become builders will probably need to move very strongly on other dimensions: strategy, market, discovery, influence, human understanding, quality of expression, ability to say no, and capacity to orient a team.
The New Roles Aren't Always New Jobs
People often talk about "new roles." The term is useful, but it can be misleading.
Not all of these roles will necessarily become stabilized HR titles. Some will become positions. Others will remain distributed competencies within the team. Others will be absorbed by Product Ops, Design, Engineering, or QA.
The important point isn't the title. It's the responsibility.
Who judges?
Who builds?
Who guarantees?
Who evaluates?
Who maintains the memory?
Who orchestrates the workflows?
AI makes visible responsibilities that were sometimes implicit or secondary: evaluation of probabilistic outputs, agent-readable documentation, product memory, workflow orchestration, context quality, repo readability, clarity of acceptance criteria.
These needs aren't peripheral. They become central as soon as a team works with agents.
The PM Isn't Disappearing — The Minimum Bar Is Rising
Product management isn't disappearing.
But the role is becoming less tolerant of profiles that lived primarily from coordination, writing, tracking, and producing intermediate artifacts.
Tomorrow, there will be less room for the administrative PM.
There will be more room for two types of profiles.
On one side, those who know how to build enough to accelerate product learning: prototype, materialize, test, contribute, sometimes push all the way to a real deliverable.
On the other, those who know how to judge well enough to orient a team that can build much faster than before: understand the market, read the signal, arbitrate, say no, hold a vision, protect coherence, and own the consequences.
Between these two poles, many combinations will exist. But the minimum bar is rising.
AI isn't eliminating product management. It's forcing the role to become what it always should have been: a responsibility of creation, judgment, and impact.
Appendix: A Catalog of Future Product Roles
This appendix doesn't try to predict future LinkedIn titles. It describes the zones of responsibility that become visible with AI.
Augmented Strategic PM
A PM who automates part of intermediate execution to focus on vision, trade-offs, product coherence, and customer signal reading.
Their value lies in choosing the right problems, deciding when no option is perfect, protecting positioning, and maintaining alignment between market, strategy, users, and execution.
Their risk is being mistaken for a simply more productive PM, or becoming the new bottleneck if all decisions continue to funnel upward.
Prototypist PM or PO
A product profile capable of quickly turning a business intent into a prototype, POC, internal tool, or first testable journey with the help of AI.
Their value is reducing the ambiguity between business, product, and tech.
Their risk is remaining at the mockup level or bypassing developers too early on topics that require real technical thinking.
Product Builder
A product profile capable of directly turning an idea into a testable artifact, functional prototype, internal tool, or supervised contribution.
Their value is reducing the time between intuition and demonstration.
Their risk is confusing a working prototype with a maintainable product.
Product Engineer
A profile capable of carrying product responsibility all the way to the production deliverable: user understanding, solution choice, construction, delivery, measurement, and impact.
They can come from a developer background or from a sufficiently technical product background.
Their value is redistributing part of the product judgment as close to construction as possible and reducing the gap between idea, prototype, and production.
Their risk is twofold: believing a developer becomes a product engineer without real access to customers, data, business context, and trade-offs; or believing a PM can become a product engineer without the ability to understand, validate, and maintain a production deliverable.
Product Systems Designer
A role that designs the AI-powered product systems: feedback, discovery, spec generation, insight routing, living documentation, and release workflows.
Their value is improving the mechanisms that allow the team to make better decisions continuously.
Their risk is becoming too abstract a function if not connected to the team's actual workflows.
AI Product Evaluator
A role responsible for evaluating AI outputs in the product: quality, hallucinations, failure UX, robustness, business testing, and alignment with product intent.
Their value is making the quality of a probabilistic product testable.
Their risk is being reduced to classical QA when the evaluation also covers product intent, trust, and acceptability.
Product Knowledge Curator
A role that maintains product memory in a form usable by both humans and agents.
Their value is making past decisions, customer signals, constraints, trade-offs, and documentation genuinely actionable.
Their risk is producing heavy documentation instead of living memory.
Agentic Product Ops
Product Ops specialized in orchestrating the tools, automations, and agents that support product work.
Their value is maintaining the AI workflows that run through product management: feedback, briefs, discovery, release notes, documentation, impact measurement.
Their risk is automating noise if quality criteria and ownership aren't clear.
Three Families of Roles
These roles can be read in three families.
Judgment roles: Augmented Strategic PM.
Construction roles: Prototypist PM or PO, Product Builder, Product Engineer.
System roles: Product Systems Designer, AI Product Evaluator, Product Knowledge Curator, Agentic Product Ops.
The title matters less than the responsibility. In AI-augmented teams, the central question will be less "what is your role?" and more "what are you capable of judging, building, guaranteeing, evaluating, or maintaining?"
For More
Four Days of Vibe Coding as a Rusty PM In 8 days, I understood that the Product Manager job was about to change completely AI shouldn't just help us produce ten times more. It should also force us to understand ten times better what we produce In software, the edge will no longer be technology. It will be understanding the context.