I published one simple sentence on LinkedIn: the Product Owner job already looked to me like an organisational 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. The first is that I touched a nerve. The second is that half the disagreement rests on a misunderstanding I want to clear up straight away.

I was not looking for a fight — the view count means nothing to me. And above all: I held exactly this position before AI. Mentioning AI is what crystallised the reactions, but it is not the foundation of my argument. It is the accelerator.

The original post and the full exchange are here. This article is my worked answer to the people who took the time to contradict me.

What I am not saying

I am not saying that AI will replace Product Owners.

People told me, 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 it six months later. I agree. Completely.

Nor am I saying that people with "PO" on their business card are useless. I know excellent ones. It is the split I am attacking, not the people who have to live inside it.

What I am saying: the product is what runs in production

A specification describes an intent. A PRD describes an objective, the rules expected, the scenarios. A mock-up describes a desired interface.

But between that intent and production, something always happens. I went into this in The product question has to start from the source code:

Compromises get made. Details get adjusted. Edge cases surface. Decisions are taken during development. Technical constraints force small changes in behaviour. Conversations happen in a pull request or a merge request. The calls made along the way do not always find their way back into the original documentation.

[...] the spec is not the truth of the product. It is a useful approximation at a given moment. The truth is what runs.

That is not a problem. It is entirely normal: a living product is not built the way a frozen document is.

But it has a consequence we refuse to look at squarely. If the truth of the product is manufactured between intent and production, then the person who stays upstream of production is not working on the product. They are working on an intent. They never see the calls that actually decide what the customer will live with.

The customer does not see your discovery. They do not see your prioritisation framework or your beautiful roadmap. They see what goes out in production. And the quality of a product sits in an accumulation of small details — details you only ever see if you follow the thing all the way through.

Hence my conviction: the person who does the thinking about the product has to be the person who ships it and looks after it once it has shipped. One and the same person. Full ownership.

The aberration is not what the job contains, it is what its existence reveals

So what makes the PO job indefensible in my eyes is not what a PO does day to day. It is the fact that an organisation judged it useful to separate the "noble" part — doing the thinking about the product — from the part you delegate: maintaining the backlog, holding the relationship with the developers, watching the release to production.

That is Taylorism applied to product.

And we have seen this film before.

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 has gone. Today there are developers, who take a problem end to end: architecture, code, security, shipping, follow-up. Fewer and fewer architects even sit apart from the rest of the team.

Nobody misses analyst-programmers. Nobody argues that we built better software when the thinking and the 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 the people who ship I set out a rule I consider non-negotiable on the development side:

The healthiest rule is simple: whoever creates the bug fixes it.

Not because anyone needs punishing. Not because anyone needs humiliating. Because accountability for the fix has to stay attached to accountability for what was produced.

And further on:

In most cases, if a developer created the defect, they have to fix it. Even if they have moved on to something important. Even if it disrupts the plan. Even if it slows down the next feature.

Quality consumes capacity. Hiding it does not make it free.

I would be on shaky ground demanding that of developers and letting myself off.

A PM who designs something and then hands a PO the job of carrying it through to production is doing exactly what I criticise in the developer who ships and moves on. They are externalising the cost of what they produced. They never see where their own understanding was thin, where the wording was ambiguous, where the call was shaky. The loop does not close.

And it is that loop that creates quality.

Quality cannot be delegated after the fact. Not on the code side, not on the product side.

"You are 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, to define features from the customer's point of view, to carry a vision, to make the calls between conflicting priorities, to maximise value.

My answer never changes: that is called a Product Manager. You have just described my profession.

If your definition of the PO covers my definition of the PM, then we agree on the substance and we are arguing about a word.

The problem is that this is not what the market hires for. I was taken to task for describing a PO who does not exist. Look at 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 even the majority of them.

And here there is a point nobody raised in the comments.

You cannot build a profession on a disposable artefact

The argument put forward most often in defence of the role is the backlog one: the PO maximises the value of the product by holding, refining and prioritising the backlog.

Except that I demolished that foundation elsewhere, without mentioning AI once. In The backlog is not a dumping ground:

A backlog item is useful up to the point of shipping. After that it loses most of its value.

Tickets drift out of sync. Specs drift out of sync. The calls change during the build. The final behaviour in production often differs from what was written at the start.

[...] The backlog is not a source of truth. It is a temporary support for coordination.

And above all, it is no longer where the thinking about the product happens:

Tools like Jira, Notion or their equivalents are often still card tools. Improved word processors. [...] They can be useful for coordinating action. But they are very weak for building product thinking.

[...] The ticket is no longer where you think. It is where you push the result of thinking that has already been structured.

So if the backlog is neither the memory of the product, nor the brain of the product, nor a lasting asset — how do you build a profession on keeping it?

You can build a function on a disposable artefact. Not a profession.

Note that this argument has nothing to do with AI. It was already true in 2020.

The name matters, and here is why

People objected that PO is a role inside a methodological framework, whereas PM is a profession. That what counts is what you do, not what you are called.

In principle, I agree. I did project management at one point without knowing it had a name. What you do counts for 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 fence off product accountability without granting the mandate to decide.

A PO with no mandate to make the call is not a role. It is an uncomfortable position.

And I recognise there a mechanism I have already described in Why organisations prefer soft decisions:

A clear decision makes accountability visible. It exposes whoever makes the call. It gives critics a handle. It forces you to own the fact that some requests were turned down.

A soft decision spreads that accountability out. It dilutes it across the participants, the meetings, the documents, the careful wording, the successive sign-offs.

Splitting product accountability in two is the same reflex applied to the org chart. It gives you someone who carries the consequence without having had the choice, and someone who had the choice without carrying the consequence.

The arrangement is comfortable. It is also the reason nobody is really accountable for anything any more.

Where AI actually comes in

My argument about AI is not "it is going to replace POs". It is more mechanical than that.

The thinker / executor split had an economic justification. The work of translating, documenting, writing and formatting cost real time. Enough time that we created a dedicated job to absorb the plumbing.

For a long time the PM was a switchboard: gather needs, reformulate, produce documents, clarify tickets, tidy things up, coordinate, prioritise, follow up, chase, document some more. Part of the profession consisted of compensating for the organisation's own friction. We ended up accepting as normal a mass of tasks that were not the core of the profession, only its plumbing.

That cost is collapsing.

And when the economic justification for a division of labour disappears, the division of labour 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 isn't time".

So hiring today against a job ad built around passing information along is optimising a circuit that is already obsolete.

The nuance about writing

Someone replied: "writing was never the bottleneck of the profession".

On the decision-making side, that is true. Making a call was never a writing problem, and I will not pretend otherwise.

But in the broader sense, I disagree. I am the only PM for the whole 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 push — that is an insane amount of work. AI lets me do things I simply did not have time for. It was not the bottleneck on the decision. But it was very much a wall.

I see AI as an excellent personal assistant. It picks up my thinking, it devours the sources, it does the laborious work. But the person who understands the fine grain, who chooses, who takes the risk and owns it, is the PM. Not the AI.

And there is one thing it will never do: place the bet.

If you are a startup and the question is "do we go all in or die", that choice belongs to the people who founded the company. An AI can analyse the option. It cannot own it.

Where my critics moved me

Three things I take away from the argument.

The mandate counts for more than the title. Several people brought the subject back to this, and they are right. A PM locked into day-to-day operations and firefighting, with no room to define a product strategy, will be busy without producing anything useful. Renaming jobs settles nothing if the mandate does not follow. My insistence on vocabulary must not hide that.

You can rethink the job rather than delete it. A tech lead described his team to me, working on regulated healthcare software with a legacy codebase: they did not remove the job, 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 wording, and it is worth saying: what is becoming indefensible is the relay role, not the people.

The real danger is the insulating layer. The problem is not that a PO exists. It is when the PO becomes the layer that cuts developers off from the real need — on the grounds that devs supposedly have no business understanding the domain, only executing specs. AI is going to make that even less tenable. Where I work, developers have been interviewing customers directly for several months. And a few days ago I pushed my first pull request on our main product.

On domain expertise, finally, let me correct a common misconception: it is nobody's property, least of all the PO's. I have found it in CSMs who came from the field, in people in support. It can be anywhere — and it has to be in the PM. In my area, I devour books and videos about industrial maintenance. I owe it to myself to be excellent on the domain, otherwise I have nothing to make calls about.

Where I do not move

I was told that the PO I describe is probably the PO I used to be. That is possible.

And I will add something more awkward to admit: it is very comfortable to be rid of the backlog, of following up with the devs, of releases to production. The PM has an objective interest in the PO job existing. You keep the part that sounds good in a meeting and delegate the part that costs.

Which is precisely why I distrust it.

Separating the people who think from the people who execute is an aberration. Not because AI is arriving. Because the product is what runs in production — and you do not delegate accountability for what you designed.

AI does not make that argument true.

It makes it impossible to dodge.