Originally written in French. Translated by AI — the meaning has been preserved, not the prose.
I published a simple sentence on LinkedIn: the Product Owner role already struck me as an organizational aberration, and in the age of AI it is becoming genuinely hard to defend.
66,000 impressions and around forty comments later, two things are clear. First, I touched a nerve. Second, half the disagreements rest on a misunderstanding I want to clear up right away.
I was not looking for controversy — I don't care about view counts. And above all: I held exactly this position before AI. Mentioning AI crystallized the reactions, but it is not the foundation of my argument. It is the accelerator.
The original post and the full thread are here. This article is my structured reply to everyone who took the time to disagree.
What I am not saying
I am not saying AI will replace Product Owners.
People replied, quite rightly, that an AI does not understand a market, does not anticipate a need, does not defend a vision in front of a sponsor, does not hold a NO GO and does not answer for its calls six months later. I agree. Completely.
Nor am I saying that people with "PO" on their business card are useless. I know excellent ones. I am criticizing the split, not the people who live inside it.
What I am saying: the product is what runs in production
A spec describes an intention. A PRD describes an objective, expected rules, scenarios. A mockup describes a desired interface.
But between that intention and production, something always happens. I developed this point in The product question should start from the source code:
Compromises are made. Details are adjusted. Edge cases appear. Decisions are made during development. Technical constraints force slight changes to the behavior. Discussions happen in a pull request or a merge request. Trade-offs don't always make it back into the original documentation.
[...] the spec isn't the truth of the product. It's a useful approximation at a given moment. The truth is what's running.
That isn't a problem. It's actually normal: a living product isn't built like a frozen document.
But it has a consequence we refuse to look at squarely. If the truth of the product is manufactured between intention and production, then whoever stays upstream of production is not working on the product. They are working on an intention. They never see the trade-offs that actually define what the customer will experience.
The customer doesn't see your discovery. They don't see your prioritization framework or your beautiful roadmap. They see what ships. And the quality of a product lives in an accumulation of small details — details you only notice if you follow through to the end.
Hence my conviction: whoever thinks the product must be the one who ships it and looks after it once it's live. One and the same person. Full ownership.
The aberration isn't what the role does, it's what its existence reveals
What makes the PO role indefensible to me is therefore not what a PO does day to day. It is the fact that an organization judged it useful to separate the "noble" part — thinking the product — from the part you delegate: tracking the backlog, holding the relationship with the developers, watching the release.
That is Taylorism applied to product.
And we have already seen this movie.
There was a time with analysts on one side and programmers on the other. One group thought, the other produced code by the yard. That split disappeared. Today there are developers, who take a problem end to end: architecture, code, security, delivery, follow-up. There are even fewer and fewer architects separated from the rest of the team.
Nobody misses analyst-programmers. Nobody argues we built better software when thinking and execution lived in two different heads.
I see no reason for product to escape that movement.
I hold myself to the rule I impose on developers
There is one argument I have to face before all the others, because it points straight at me.
In Quality belongs to those who ship, I laid down a rule I consider non-negotiable on the engineering side:
The healthiest rule is simple: whoever creates the bug fixes it.
Not because people should be punished. [...] Because responsibility for the fix has to stay tied to responsibility for the production.
And further on:
In most cases, if a developer created the defect, they should fix it. Even if they've moved on to something important. Even if it disrupts the schedule. Even if it slows down the next feature.
Quality consumes capacity. Hiding it doesn't make it free.
I would be poorly placed to demand that of developers and exempt myself.
A PM who designs, then hands a PO the job of carrying the thing through to production, does exactly what I criticize in the developer who ships and moves on. They externalize the cost of what they produced. They never see where their understanding fell short, where the wording was ambiguous, where the trade-off was shaky. The loop never closes.
And that loop is what creates quality.
Quality cannot be delegated after the fact. Not on the code side, not on the product side.
"You're describing a bad PO"
This is the most frequent objection, and it came from several different people: a PO's role is to understand the need, define features from the customer's point of view, carry a vision, arbitrate between conflicting priorities, maximize value.
My answer is consistent: that is called a Product Manager. You have just described my job.
If your definition of PO overlaps my definition of PM, then we agree on the substance and we are arguing over a word.
The problem is that this is not what the market hires for. I was told I was describing a PO who doesn't exist. Open the job ads: feed the backlog, write the user stories, sit between the business and the devs, run the ceremonies. That PO is everywhere. That PO is the majority.
And there is a point nobody raised in the comments.
You cannot ground a profession on a disposable artifact
The argument most often used to defend the role is the backlog: the PO maximizes product value by holding, refining and prioritizing it.
Except I already demolished that foundation elsewhere, without mentioning AI once. In The Backlog Is Not a Dumping Ground:
A backlog item is useful up to delivery. After that, it loses much of its value.
Tickets drift out of sync. Specs drift out of sync. Trade-offs change during implementation. The final behavior in production often differs from what was written at the start.
[...] The backlog isn't a source of truth. It's a temporary coordination aid.
And above all, it is no longer where you think the product:
Tools like Jira, Notion, or their equivalents remain, for the most part, card tools. Souped-up word processors. [...] They can be useful for coordinating action. But they're very weak for building product thinking.
[...] The ticket is no longer where you think. It's where you push the result of thinking that's already structured.
So if the backlog is neither the product's memory, nor the product's brain, nor a durable asset — how do you ground a profession on keeping it?
You can ground a function on a consumable artifact. Not a profession.
Note that this argument has nothing to do with AI. It was already true in 2020.
The name matters, and here's why
I was told that PO is a role within a methodological framework, whereas PM is a profession. That what matters is what you do, not what you're called.
In principle, I agree. I did project management at a time when I didn't know it had a name. What you do matters more than the label.
But the title manufactures the mandate.
In practice, POs have less ownership and less autonomy. When you are a PM, you own your scope, full stop. Several people put it better than I did in the comments: the PO title has often served to compartmentalize product responsibility without granting the decision mandate.
A PO without an arbitration mandate isn't a role. It's an uncomfortable position.
And I recognize a mechanism I already described in Why Organizations Prefer Soft Decisions:
A clear decision makes responsibility visible. It exposes whoever makes the call. It offers a handle for criticism. It forces one to own the fact that certain requests were not granted.
A soft decision distributes that responsibility. It dilutes it among the participants, the meetings, the documents, the cautious phrasings, the successive validations.
Splitting product responsibility in two is the same reflex applied to the org chart. It lets you have someone who bears the consequence without having had the choice, and someone who had the choice without bearing the consequence.
The arrangement is comfortable. It is also the reason nobody is really accountable for anything anymore.
Where AI actually comes in
My argument about AI is not "it will replace POs". It is more mechanical than that.
The thinker / executor split had an economic justification. The work of translating, documenting, drafting and formatting cost a lot of time. Enough to justify a dedicated role to absorb that plumbing.
For a long time the PM was a switchboard: gather needs, rephrase, produce documents, clarify tickets, restore order, coordinate, prioritize, follow up, chase, document again. Part of the job consisted of compensating for the organization's friction. We ended up accepting as normal a mass of tasks that were not the core of the job, only its plumbing.
That cost is collapsing.
And when the economic justification for a division of labor disappears, the division of labor does not survive long.
That is where my original disagreement and AI meet. AI does not create the problem: it removes the last practical excuse we had for living with it. You can no longer say "yes, in theory the PM should follow through to production, but in practice there's no time".
So continuing to hire today against a job description built around passing information along means optimizing a circuit that is already obsolete.
The nuance about writing
I was told: "writing was never the bottleneck of the job".
On arbitration, that's true. Deciding was never a writing problem, and I won't pretend otherwise.
But in the broad sense, I disagree. I am the only PM for the entire company. When you have to produce a video in fifteen languages with subtitles, articles in four or five languages, the posts, the briefs on the benefits and the points to highlight — the workload is insane. AI lets me do things I simply didn't have time for. It wasn't the decision bottleneck. But it was very much a wall.
I see AI as an excellent personal assistant. It picks up my thinking, swallows the sources, does the grinding work. But the person who understands finely, who chooses, who takes the risk and who answers for it is the PM. Not the AI.
And there is one thing it will never do: the bet.
If you're a startup and the question is "we go all in or we die", that choice belongs to the people who founded the company. An AI can analyze the option. It cannot own it.
Where my critics moved me
Three things I take away from the debate.
The mandate matters more than the title. Several people refocused the discussion there, and they are right. A PM locked into operations and firefighting, without the latitude to define a product strategy, will be busy without producing anything useful. Renaming roles fixes nothing if the mandate doesn't follow. My insistence on vocabulary must not obscure that.
You can redesign the role instead of deleting it. A tech lead described his team to me, on regulated healthcare software with a legacy codebase: they didn't remove the role, they redefined it. The developer carries part of the product vision, the PO designs. The people stay, the role changes. That is probably fairer than my initial phrasing, and it deserves saying: what becomes indefensible is the transmission belt, not the people.
The real danger is the insulation layer. The problem isn't that a PO exists. It's when they become the layer that cuts developers off from the real need — on the grounds that devs shouldn't have to understand the business, only execute specs. AI is going to make that even less tenable. On our team, developers have been interviewing customers directly for months. And a few days ago, I pushed my first pull request on our main product.
On domain expertise, finally, let me correct a received idea: it is not the PO's property. I've found it in CSMs who came from the field, in support people. It can be anywhere — and it must be in the PM. In my domain, I devour books and videos on industrial maintenance. I owe it to myself to be excellent on the business, otherwise I have nothing to arbitrate.
Where I don't budge
I was told the PO I describe is probably the one I used to be. That's possible.
And I'll add something more awkward to admit: it is very comfortable to offload the backlog, the dev follow-up, the releases. The PM has an objective interest in the PO role existing. You keep the part that tells well in a meeting and delegate the part that costs.
That is precisely why I distrust it.
Separating those who think from those who execute is an aberration. Not because AI is arriving. Because the product is what runs in production — and you don't delegate responsibility for what you designed.
AI doesn't make that argument true.
It makes it impossible to sidestep.
Learn more
Quality belongs to those who ship The Backlog Is Not a Dumping Ground: It's a Tool for Action The product question should start from the source code