Developers here have been interviewing customers without going through the Product Manager for months.

And three days ago, I pushed my first pull request to our main product.

Those two sentences say more about what is happening in product teams with AI than any analysis. Developers are moving up towards the problem, the customer and product ownership. PMs are moving down towards the prototype, the code and sometimes production.

You could read this as two isolated anecdotes. I think it is the beginning of something deeper. The historical roles of product management, development and design are becoming less clear-cut. The boundaries are moving. But contrary to what you might expect, that does not mean everyone will do everything, or that responsibilities are about to disappear.

The real subject is not that AI makes teams "more productive". The real subject is that it sharply raises the capacity to build. And when the capacity to build rises, the bottleneck moves.

The constraint used to be: "How much can we build?"

It is becoming: "What should we build? Why? For whom? In what order? At what risk?"

That shift is what blurs the roles.

When developers build more, the PM becomes the bottleneck

One trigger for all this is simple enough: with AI, developers can build faster.

Not just write a few lines more quickly. Build more options, more variants, more prototypes, more small tools, more initiatives. A developer who was already autonomous can find themselves going three, four or six times faster on certain tasks. A team with a limited delivery capacity can suddenly generate far more things to test, to decide on, to review, to prioritise.

The problem is that the capacity to decide does not automatically rise at the same rate.

If everything still has to pass through the PM, the PM quickly becomes the new saturation point of the system. This is no longer about writing specs or keeping a backlog moving. The load shifts towards prioritisation, product coherence, validating the customer signal, reading the market, user impact, strategy and living with the consequences.

An organisation can then believe it has solved its speed problem because developers are building more. In reality, it has simply moved the blockage.

There are three possible answers.

The first is to hire more PMs. Sometimes that is necessary, but it is not always the right answer. If the model stays the same, you have only added one more layer of decision-making.

The second is to automate part of the PM's operational work: documentation, release notes, launch material, first-pass analysis, translations, summaries, demo videos, screenshots, press material. That frees up time, but it does not settle the underlying question.

The third is to redistribute part of the product ownership towards the people who build. That is where roles genuinely start to blur.

Speeding up the code is not enough

One mistake would be to think AI transforms an organisation purely because it speeds up development.

Local speed does not automatically create value. It can even create more mess if the whole workflow stays as it was. A team can generate more code, more prototypes, more documents and more tickets while making worse decisions.

The whole flow has to be rethought: idea, discovery, specification, prototyping, development, testing, security, launch, communication, support and learning.

Drop AI agents onto an unchanged process and all you are likely to do is move the bottlenecks around. Code speeds up, then product blocks. Product speeds up, then design blocks. Design speeds up, then technical validation blocks. Validation speeds up, then go-to-market or support cannot keep up.

So the subject is not only: "How do we make developers faster?"

The subject is: "How do we make the whole system able to absorb that speed without losing quality, coherence and responsibility?"

Which is why the new roles do not reduce to "a PM who codes" or "a developer who does product". Part of what is now needed concerns workflow orchestration, judging AI output, product memory, decision quality, how readable the repos are, and the ability to give agents reliable context.

What AI makes ordinary in product management

For a long time, PMs differentiated themselves through fairly distinct instincts or skills.

Some were very good at writing. Others at data. Others at benchmarking, product marketing, discovery, experience design or delivery coordination. Those differences do not vanish entirely. But part of their differential value drops.

With AI, a lot of these capabilities become easier to reach:

• writing a decent spec;
• producing a first data analysis;
• running a benchmark;
• drafting a release note;
• putting together an acceptable mock-up;
• summarising interviews;
• producing a first version of a user journey;
• turning a need into a prototype.

These skills do not become useless. A PM still has to know how to judge a spec, challenge an analysis, read a mock-up, understand an interview summary or assess a prototype. But producing the first version of those artefacts is becoming less rare.

A PM used to be strongly differentiated by being able to produce a good spec, a clear benchmark, a usable summary or a first mock-up quickly. Tomorrow, that is closer to the minimum level.

This leaves exposed the PMs whose strength lay mainly in mid-level execution. Those who coordinated, wrote, administered, followed up, reformulated and produced correct artefacts without bringing a strong product judgement risk losing part of their value.

The product job is not disappearing. But its minimum level is rising.

What stays hard: product judgement

Once building gets easier, choosing what to build gets more critical.

That is where the PM job keeps its value. Not in the capacity to generate more artefacts, but in the capacity to choose, to make the call and to take on what follows.

What stays hard:

• choosing the right problem;
• understanding a market;
• reading the real signal behind customer requests;
• weighing the short term against the strategy;
• saying no;
• holding a coherent vision;
• creating alignment;
• taking on the product, business, technical and human consequences of a decision.

The augmented strategic PM looks more and more like a kind of mini-CPO. Less delivery administration, less mechanical production of deliverables, and more of the calls where no option is perfect.

The role matters most when there is no good solution. Only two or three bad options, with different costs, different risks, different political effects, different customer impact. In those moments, AI can help analyse. It cannot take it on.

So the augmented PM is not simply a PM who goes faster. It is a PM who has to judge better.

Differentiation moves towards the customer signal

If everyone can build faster, building fast is no longer enough of an advantage.

Raw code production becomes partly a commodity. Not software. Not engineering. Not architecture, security or maintainability. But the capacity to turn out a first version quickly is becoming less rare.

Real differentiation then moves towards what competitors cannot simply generate:

• the quality of the customer signal;
• proprietary data;
• domain knowledge;
• distribution;
• trust;
• operational constraints;
• accumulated learning;
• the ability to read correctly what customers are really asking for.

A quick prototype is only worth something if it tests a real signal. Otherwise it just accelerates a wrong direction.

So the strategic question becomes: which advantage of our own are we building on?

A team with AI behind it can turn out a great deal. But if it does not read its market any better, if it does not understand its users any better, if it cannot tell a strong signal from well-phrased noise, it will only produce mediocre things faster.

That is one more reason the PM does not disappear. The role moves towards how well it reads the real world.

Developers are moving up towards product

Developers have never been mere executors.

A complete specification is a fiction. Even a good spec never describes every behaviour a product is expected to have. There are always silent zones: edge cases, error messages, implicit behaviour, security rules, expiry times, invisible priorities, micro-interactions, fallback decisions.

In those zones, developers are already making product decisions.

AI makes that more visible. If an agent writes part of the code, the human has to spell out the expected behaviour, settle the edge cases, define acceptance criteria, check the result. Micro-decisions that used to be absorbed silently into the implementation become visible, and therefore more important to frame.

That is one reason developers are moving up towards product. They talk to customers more, understand the problems better, own more of their features, make their local decisions more explicit.

There is an important nuance, though: a developer does not become a product engineer just by using a coding agent or by shipping faster.

Without access to customers, to data, to business context and to the calls being made, all they risk becoming is an operator of coding agents. More responsibility, more pressure, but not necessarily more product power.

A real product engineer is not just a fast developer. They are someone who owns part of the product judgement as close as possible to the building.

PMs are moving down towards building

The reverse movement exists too.

With AI, a PM can turn an idea into something real much faster than before. A mock-up, a prototype, an internal tool, a dashboard, a translation, an interface change, sometimes even a scoped and supervised pull request.

That changes the nature of the work.

It used to take a long sequence: state the need, write the spec, produce a mock-up, ask for an estimate, wait for a slot, get it developed, test, adjust. Today, on some subjects, you can go from hunch to something you can handle far more quickly.

And sometimes it is no longer even about prototyping. On simple or well-defined cases, you can build something almost real: a dashboard, a read-only screen, an interface improvement, an internal automation, a translation, release material.

That does not mean the PM becomes a developer in the classic sense. It means they can work inside areas of building that used to sit outside their scope.

Several levels need separating here.

The prototyping PM or PO turns a business intent into a prototype or a POC.

The Product Builder goes further: they build tangible artefacts, internal tools, dashboards, first versions, scoped and supervised contributions.

The Product Engineer goes further still: they can own a product responsibility all the way to a production deliverable. And that role can be reached from two directions. A developer moving up towards product. Or a product profile technical enough to move down towards production.

So the criterion is not where someone started. The criterion is their level of action.

Does this person stay at the mock-up? Do they produce a prototype? Do they open a pull request? Do they carry something through to a shippable deliverable? Do they understand the risks well enough to get what they build properly validated?

That continuum is what is new.

Roles blur, responsibilities remain

The risk would be to conclude that because roles blur, responsibilities dissolve.

I think exactly the opposite.

The more roles blur, the more responsibilities have to be spelled out.

A product choice is still a product choice. It belongs to product: vision, positioning, coherence, the calls, the guiding principles, reading the market, the customer signal.

A technical choice is still a technical choice. It belongs to engineering: security, performance, scalability, architecture, maintainability, platform quality.

An experience choice is still an experience choice. It belongs to design or front end: design system, consistency of use, accessibility, the UX bar.

The organisation that works is not the one where everybody does everything on their own. It is the one where anyone can step beyond their original domain because someone is accountable for setting the standards, the guardrails and the limits.

A PM can push a pull request. But it gets reviewed, accepted, corrected or refused.

If it is refused ten times in a row, that tells you something. Perhaps the PM is not yet at the level for that kind of contribution. Perhaps the subject is too risky. Or perhaps the engineering team has not yet put in place the directives, the tooling or the guardrails that would let other profiles contribute safely.

The pull request or merge request then becomes a governance mechanism. Not just a technical tool.

It all comes down to the skill / risk pairing

The right question is not: "Can a PM push to production?"

The right question is: "On what scope, with what skill, at what risk and behind what guardrails?"

You need a simple gradation.

Low risk: translations, content, dashboards, read-only screens, non-critical internal tools.

Medium risk: small write actions, internal workflows, scoped and supervised interface changes.

High risk: payments, permissions, security, sensitive data, critical business logic, regulated products, architecture.

Even in a regulated product, not everything carries the same level of risk. A dashboard or a read-only screen can be relatively safe if the rules are clear and technical validation is in place. Conversely, an apparently simple product can contain a very sensitive zone if it touches data, permissions or an irreversible business decision.

The analogy with a junior developer is useful. You do not hand someone the keys to the product on day one. You start with simple scope, then widen it step by step.

The augmented PM can follow the same logic: translations, read-only, dashboards, small writes, then possibly more critical contributions if the skill, the context and the guardrails keep up.

The split between PM profiles

Not every PM will be able to become a builder or a product engineer at the same pace.

In the short term, PMs with a technical background have an advantage. They can read a repo, make sense of an error, hold a conversation with a coding agent, interpret what has been generated, spot certain absurdities, ask for a technical review in the right place.

A PM without that grounding can of course learn. But they risk being confined to the mock-up or the shallow prototype for as long as they do not understand enough of what AI produces.

AI is still too unreliable for anyone to ignore what happens under the bonnet. If you do not understand at least some of the errors it makes, getting past a reliable mock-up becomes hard.

That does not mean non-technical profiles are doomed. In the medium or long term the reverse could happen. If agents become far more reliable, profiles coming from psychology, literature, philosophy, design, research or business could take the advantage, thanks to their ability to express a human, social or business reality with precision.

But with the tools as they stand, the split is real.

PMs who do not want to become builders will probably have to get very strong on other dimensions: strategy, market, discovery, influence, understanding people, quality of expression, the ability to say no and to steer a team.

New jobs are not always jobs

People talk a lot about "new jobs". The term is useful, but it can mislead.

Not all of these roles will settle into HR titles. Some will become posts. Others will stay as skills spread across the team. Others again will be absorbed into Product Ops, Design, Engineering or QA.

What matters is not the title. It is the responsibility.

Who judges?

Who builds?

Who guarantees?

Who assesses?

Who keeps the memory?

Who orchestrates the workflows?

AI makes visible a set of responsibilities that were sometimes implicit or secondary: judging probabilistic output, documentation that agents can actually use, product memory, workflow orchestration, the quality of the context, how readable the repo is, how clear the acceptance criteria are.

These needs are not peripheral. They become central as soon as a team works with agents.

The PM does not disappear, the minimum level rises

Product management is not disappearing.

But the job is getting less forgiving for profiles who lived mainly off coordination, writing, follow-up and the production of intermediate artefacts.

There will be less room for the administrative PM.

There will be more room for two kinds of profile.

On one side, those who can build enough to speed up product learning: prototype, make things real, test, contribute, sometimes go all the way to a real deliverable.

On the other, those who can judge well enough to steer a team that can now build far faster than before: understand the market, read the signal, make the calls, say no, hold a vision, protect coherence and take on the consequences.

Between those two poles, plenty of combinations will exist. But the minimum level is going up.

AI is not removing product management. It is forcing the job back into what it should always have been: a responsibility for creation, judgement and impact.

Appendix: a catalogue of future product roles

This appendix is not trying to predict future LinkedIn titles. It describes the zones of responsibility that AI is making visible.

Augmented strategic PM

A PM who automates part of the mid-level execution in order to concentrate on vision, the calls, product coherence and reading the customer signal.

Their value is choosing the right problems, deciding when no option is clean, protecting the positioning and holding the alignment between market, strategy, users and execution.

Their risk is being mistaken for a slightly more productive PM, or becoming the new bottleneck if every decision still has to come back up to them.

Prototyping PM or PO

A product profile able to turn a business intent quickly into a prototype, a POC, an internal tool or a first testable journey with AI's help.

Their value is reducing the ambiguity between business, product and engineering.

Their risk is staying at the mock-up, or going around the developers too early on subjects that need genuine technical thought.

Product Builder

A product profile able to turn an idea directly into a testable artefact, a working prototype, an internal tool or a scoped and supervised contribution.

Their value is shortening the time between hunch and demonstration.

Their risk is mistaking a prototype that works for a product that can be maintained.

Product Engineer

A profile able to own a product responsibility all the way to a production deliverable: understanding the user, choosing the solution, building, shipping, measuring, impact.

They can come from a developer background or from a product background that is technical enough.

Their value is redistributing part of the product judgement as close as possible to the building, and closing the gap between idea, prototype and production.

Their risk runs both ways: believing a developer becomes a product engineer without real access to customers, to data, to business context and to the calls being made; or believing a PM can become a product engineer without being able to understand, get validated and maintain a production deliverable.

Product Systems Designer

The role that designs the AI-powered product systems: feedback, discovery, spec generation, routing insights, living documentation and release workflows.

Their value is improving the mechanisms that let the team make better decisions continuously.

Their risk is becoming too abstract a function if it is not connected to the team's actual workflows.

AI Product Evaluator

The role responsible for judging the AI output inside the product: quality, hallucinations, failure UX, robustness, business testing and consistency with the product intent.

Their value is making the quality of a probabilistic product testable.

Their risk is being reduced to classic QA, when the assessment also covers product intent, trust and acceptability.

Product Knowledge Curator

The role that keeps the product memory in a form both humans and agents can use.

Their value is making past decisions, the customer signal, the constraints, the calls and the documentation genuinely actionable.

Their risk is producing heavy documentation instead of a living memory.

Agentic Product Ops

Product Ops specialising in orchestrating the tools, automations and agents that support product work.

Their value is maintaining the AI workflows that run across product management: feedback, briefs, discovery, release notes, documentation, impact measurement.

Their risk is automating noise if the quality criteria and the ownership are not clear.

Three families of roles

These roles fall into three families.

Judgement roles: the augmented strategic PM.

Building roles: the prototyping PM or PO, the Product Builder, the Product Engineer.

System roles: the Product Systems Designer, the AI Product Evaluator, the Product Knowledge Curator, agentic Product Ops.

The title matters less than the responsibility. In teams working with AI, the central question will be less "what is your role?" than "what are you able to judge, build, guarantee, assess or maintain?"