Fewer roles. A much higher bar. And the structures many organisations built around the role are quietly collapsing.

At the end of a recent PSPO AI Essentials session I was running online, a participant asked a question that stopped the room.

"With AI agents becoming users of our products, and with products needing to be technically built for non-human consumers, what does that mean for the Product Owner job market? Are we saying the role now needs to be deeply technical? Because most Product Owners I know aren't. And most job descriptions I see still aren't asking for that."

It was a good question. A sharp one. And it connected to something I have been watching build for a while, a quiet but fundamental restructuring of what the Product Owner role is, what the market wants from it, and how the frameworks organisations built around it are starting to strain at the seams.

I have been watching the Product Owner job market for fifteen years. I have seen it boom, correct, and quietly restructure itself in ways that don't always make the headlines. And what I am watching right now is not a hiring slowdown or a cyclical correction. It is something more fundamental.

The Product Owner role is splitting. One version is being automated away. The other is becoming more strategically critical than it has ever been. And most organisations, most job descriptions, and most practitioners have not yet worked out which side of that split they are on.

What I have been teaching for fifteen years

Long before AI entered the product conversation, I taught a version of the Product Owner role that most organisations struggled to accept. I told people the Product Owner is the entrepreneur of the product. Not a proxy. Not a requirement conduit. An entrepreneur. Someone who owns the product fully, including its budget, its strategy, its bets, and its failures.

I taught that the Product Owner should think like a founder. That they should be asking not "what does the stakeholder want?" but "what is the right thing to build, and how do I know?" That accountability for product value means accountability for business outcomes, not just feature delivery. That a Product Owner who doesn't control budget doesn't really own the product at all.

Most of the time, when I said this, I got polite resistance. Organisations would nod along and then go back to asking their Product Owners to write user stories and attend ceremonies. The entrepreneur framing was aspirational. The reality was administrative.

Now here is the irony that I find both satisfying and a little uncomfortable to admit.

The irony

Everything the market is now demanding from Product Owners, founder-mode judgment, budget accountability, strategic autonomy, the ability to operate without perfect data and still make consequential decisions, is exactly what I have been arguing the role should look like for fifteen years. Before AI. Before the agentic shift. Before any of this.

It took AI making the old version of the role obsolete to make the version I always believed in finally viable. That is either vindicating or damning, depending on how you look at it. Probably a bit of both.

The market reset that changed the rules

The 2021 and 2022 hiring peak for product roles was followed by a sharp structural correction. Companies that had scaled their product teams rapidly during the growth era started asking harder questions about what those roles were actually delivering. The answer, in many cases, was not enough.

The correction hit generalists hardest. Specialists with deep business strategy alignment, genuine technical depth, or domain expertise held their ground. The people who could fluently manage a Jira board but couldn't connect their work to revenue, unit economics, or strategic bets were the first to feel the pressure.

In 2026, companies are prioritising immediate revenue generation and real business sustainability over speculative future growth. That demands a different kind of Product Owner. And the job descriptions, slowly, are starting to reflect that.

The glorified business analyst problem

Here is something I have seen in organisations of every size and across every industry over fifteen years: a significant number of companies never really implemented the Product Owner role properly. They hired someone, gave them the title, and then asked them to do what they had always asked their business analysts to do. Gather requirements. Document user stories. Attend meetings. Translate between stakeholders and developers.

That was never what the role was designed for. And for a long time, those organisations got away with it. The gap between what a Product Owner should be and what they were actually doing was uncomfortable but not catastrophic.

That gap is now becoming catastrophic.

The consequence

AI can now perform requirement analysis faster, more thoroughly, and more consistently than most human business analysts. It can synthesise user research, identify patterns, generate acceptance criteria, and produce structured specifications in minutes. If your Product Owner's primary value was writing detailed requirements, that value has just been significantly eroded.

The companies that treated their Product Owners as glorified business analysts are not just behind on a trend. They built the wrong muscle entirely. And now they are paying for it.

From detailing requirements to designing experiments

AI does the requirement-writing work better now. Not perfectly. But well enough that the competitive advantage of doing it as a human is diminishing fast.

What AI cannot do is decide what is worth building in the first place. It cannot hold a genuine hypothesis about user behaviour, design a lean experiment to test it, interpret the results with business judgment, and decide whether to pursue, pivot, or abandon. That sequence, hypothesis, experiment, learning, decision, is fundamentally human work. And it is exactly where the Product Owner role needs to move.

The Product Owner of 2026 does not start with a requirements document. They start with a question. What is the smallest thing we can build to find out if we are right?

Lean product thinking, validated learning, hypothesis-driven development, these have been in the product vocabulary for over a decade. But for most organisations they remained aspirational, crowded out by the pressure to deliver detailed requirements on time. AI removes that pressure. When the requirement-writing work is largely automated, the Product Owner is finally free to do what the role was always meant to do: lead discovery, not just document it.

2022

"Here are the detailed requirements for the next sprint. Twelve stories, all with acceptance criteria."

2026

"Here is the hypothesis we are testing this sprint. Here is the experiment. Here is how we will know if we are right."

The layering problem: when Product Owner and Product Manager stop being different jobs

One of the structural consequences of the shift nobody is talking about openly is what it means for organisations that built elaborate product role hierarchies.

SAFe, and a range of other enterprise frameworks, introduced a layered model where Product Owners handled team-level backlog and delivery concerns, while Product Managers sat above them handling strategy, roadmaps, and stakeholder alignment. The Product Manager was the entrepreneur. The Product Owner was the executor. Two roles, two layers, two sets of responsibilities that were deliberately separated.

The product management community at large reinforced this distinction. Product Manager became the prestige title. The strategic thinker. The person with market context and business judgment. Product Owner became the operational role. The person who wrote the stories and ran the ceremonies. Two different career paths, two different expectations, two different salary bands in some organisations.

Scrum never agreed with this. The Scrum Guide has always been clear: the Product Owner is accountable for maximising the value of the product. That is not an operational definition. It is a strategic one. The Product Owner in Scrum is not a sub-role beneath a Product Manager. They are the product manager, in the fullest sense of the word, with complete accountability for value, strategy, and outcome. Scrum simply never used the title "Product Manager" because it didn't need to. The accountability it described was already complete.

What SAFe and the broader product management community did was take that complete accountability, split it in two, give the top half to a Product Manager and the bottom half to a Product Owner, and then call it a structure. It was, in reality, a fragmentation. And I have spent fifteen years watching it produce Product Owners who were not more the glorified PRD Writers.

What is collapsing

The distinction between Product Owner and Product Manager was always more organisational convenience than principled design. It emerged from the scaling era, when large enterprises needed to divide the product role across layers to manage coordination at scale. That era is ending.

As organisations become leaner, as teams shrink and coordination overhead diminishes, the separation becomes harder to justify. If a single capable person can hold both the strategic vision and the team-level execution, why maintain two roles, two titles, two salary bands, and the communication overhead that comes with them?

What is emerging is exactly what Scrum always described: one person with full product accountability. Not a Product Owner who escalates strategy to a Product Manager. Not a Product Manager who delegates execution to a Product Owner. One person who owns the product, owns the strategy, owns the budget, and owns the outcome. The title on the door matters less and less. The accountability behind it is finally becoming non-negotiable.

For practitioners who built their career around the Product Manager title and its perceived superiority over the Product Owner title, this convergence is uncomfortable. For practitioners who were trapped in the operational version of the Product Owner role and told that strategy wasn't their concern, it is an opportunity. The market is moving toward the Scrum definition, even if it hasn't quite said so yet.

Technical Product Owner vs domain Product Owner: another distinction that is fading

For the past several years, a different kind of split emerged in how organisations thought about product roles. On one side: the technical Product Owner, someone who could speak fluently to engineers, understand architecture decisions, and navigate API design and system constraints. On the other: the domain or business Product Owner, someone with deep industry expertise, stakeholder relationships, and business context.

In large organisations, these sometimes became distinct roles or archetypes. A technical PO partnered with a domain PO. Each brought half the picture. The team needed both.

That distinction is also fading. And the reason connects directly to the question my participant asked in the PSPO AI Essentials session.

When your users include AI agents, you need both. In the same person. An agent operating in a healthcare procurement context needs product boundaries that are technically sound, clean APIs, structured error handling, idempotent transactions, and domain-correct, encoding clinical rules, regulatory constraints, and operational context that no API specification can capture on its own. A Product Owner who has the technical literacy but not the domain depth will build a system that is structurally sound but operationally dangerous. A Product Owner who has the domain depth but not the technical literacy will design product requirements that cannot be implemented in a way agents can safely consume.

The agentic era does not have room for half a Product Owner. It needs someone who can think across the full stack: from business strategy down to API schema, from regulatory constraint down to error payload structure.

This is a high bar. Higher than most current Product Owners have been trained to meet. Higher than most current job descriptions are asking for. But it is the bar the market is moving toward, and the organisations that recognise it first will build products that agents can actually operate within safely and effectively.

Yesterday: Two roles

Technical PO + Domain PO working in partnership. Each holding half the picture.

Today: Converging

Organisations realising the handoff between technical and domain thinking is itself a liability.

Tomorrow: One Product Owner

Full-stack product accountability. Technical literacy and domain depth in the same person. No layer above or below.

The rise of the Product Owner with Agentic knowledge, and why domain depth matters as much as ever

The need for technical depth in a Product Owner is no longer just about communicating with engineers. It is about communicating with agents. When your users include AI agents, the product has to be legible to a non-human consumer. A Product Owner who cannot think in terms of API contracts, data schemas, and error payloads cannot make good decisions about what to build for an agent-inclusive product.

And domain knowledge is equally non-negotiable. Agents can only operate safely within boundaries. Those boundaries need to reflect how the real business works, not just how the system works. None of that context lives in the technical specification. It lives in the mind of a Product Owner who understands the domain deeply enough to encode it.

Healthcare

"Does the agent know which substitutions are clinically prohibited, even when the schema technically permits them?"

Finance

"Does the agent understand that a flagged transaction cannot be retried autonomously, regardless of what the API returns?"

Logistics

"Does the agent know that a Friday afternoon order has different fulfilment rules, not because of the system, but because of how the physical network operates?"

Legal

"Does the agent understand that certain document combinations require human sign-off, even when the workflow technically allows autonomous progression?"

The new transformation nobody is talking about

For the past five years, the dominant story in enterprise agile was about scaling. Organisations adopted SAFe, LeSS, Spotify model variations, and a range of other frameworks designed to coordinate large numbers of teams. Consultancies built entire practices around it. Transformation programmes ran for years and cost millions.

The new story is the opposite. It is about becoming leaner.

2020

Scaling agile. More teams. More layers. SAFe, LeSS, PI planning. The challenge was coordination at scale.

2026

Becoming leaner. Fewer people doing more, enabled by AI. Smaller teams, higher capability, less scaffolding.

AI is compressing the work that used to require headcount. Requirement analysis, documentation, basic engineering tasks, testing, communication overhead, all of these are shrinking. The natural consequence is that organisations need fewer people to achieve the same output. And fewer people, coordinated well, are inherently more agile than many people trying to stay aligned through elaborate frameworks.

The SAFe implication

SAFe was designed to solve the coordination problem of many teams working on a shared product. If AI reduces the number of teams needed, the coordination problem it was built to solve becomes smaller. A leaner organisation does not need a programme increment planning event for twelve teams when it can achieve the same outcomes with three teams and better tooling. The Product Owner and Product Manager layers that SAFe formalised start to look like overhead rather than structure.

This does not mean SAFe becomes worthless overnight. But the assumption that scaling is the answer to enterprise product delivery is going to be challenged hard over the next two years. Organisations that treat their scaling framework as a permanent structure rather than a response to a temporary problem are going to find it becomes a weight rather than a support.

The irony nobody wants to say out loud

The Scrum Guide never described the Product Owner as a PRD writer. It described them as the person accountable for maximising the value of the product. Someone with genuine strategic authority, a clear vision, and the entrepreneurial conviction to make decisions under uncertainty. The internal entrepreneur. The founder of the product.

For most of the past fifteen years, most organisations ignored that. They hired Product Owners and buried them in JIRA. They stripped them of strategic authority. They split them into technical and domain variants and layered Product Managers above them. They measured them on story points and release dates.

The Product Owner · Intent vs. reality

What the Scrum Guide always intended

Accountable for maximising the value of the product
Holds genuine strategic authority, vision, and budget ownership
An internal entrepreneur operating in founder mode
Makes high-stakes decisions under uncertainty
Connects every product decision to real business outcomes

What most organisations actually did

Hired a requirement writer and gave them a new title
Stripped them of strategic authority and budget control
Layered a Product Manager above them for the "real" strategy
Measured them on story points and release dates
Split the role in two rather than developing one complete person

Now, AI is doing the ticket management. The layers are losing their justification. And suddenly, the question of what the Product Owner is actually for is being asked in earnest, in board rooms and hiring conversations, in ways it never quite was before.

What we may be witnessing

As organisations become leaner, as the administrative scaffolding gets automated away, and as the pressure to justify every product role increases, we may finally be arriving at something closer to what the Scrum Guide always intended. A single Product Owner who operates in founder mode. Who holds genuine product strategy and budget accountability. Who runs experiments rather than detailing requirements. Who has the domain depth and technical literacy to make real decisions for both human and agent users, not just document the decisions others have made.

Not more Product Owners doing less. Fewer Product Owners doing what the role was always supposed to be. No layer above. No split below. One accountable entrepreneur, finally doing the whole job.

The answer was in the Scrum Guide all along. It took AI making the misinterpreted version obsolete to make the original version possible.

The new job description, written honestly

Product Owner · 2026 · What's actually changed

What the 2022 JD asked for

Strong visual intuition for mobile app flows and web-responsive design
Experience optimising human conversion funnels and UX journeys
Proficiency in Jira and backlog management tools
Ability to write clear user stories and acceptance criteria
Good communication skills to bridge business and engineering

What the 2026 JD needs to ask for

Full product accountability including budget ownership and strategic authority
Entrepreneurial judgment: treats the product as a business, not a backlog
Hypothesis-driven: designs experiments before writing requirements
Technical literacy: thinks in APIs, schemas, and agent-facing product boundaries
Deep domain expertise to encode business rules and operational context for non-human users
Ability to design for both human and AI agent consumers without splitting into two roles
Founder-mode judgment: connects micro-feature decisions to board-level strategy

What this means if you are a Product Owner right now

If your primary value has been writing detailed requirements and managing a backlog, that value is under real pressure. If you have been operating as a business analyst with a Scrum title, the market has already started to price that in. If you have been relying on a Product Manager above you to handle the strategy while you handle the delivery, that structure is becoming harder to justify.

The Product Owners who will be valued in two years are the ones who can hold the full picture. Strategy and execution. Business domain and technical architecture. Human users and agent users. Experiment design and outcome measurement. That is closer to what the Scrum Guide always described. The market is now forcing organisations to take it seriously.

What this means if you are hiring or leading a product function

Stop posting the 2022 job description. Stop maintaining layers that exist because your organisation was once too large and too slow to trust a single person with full product accountability. And stop splitting the role into technical and domain variants when what you actually need is one person who can do both.

The agile transformation of the past five years was about scaling up. The transformation of the next two years is about stripping back to what actually works. One accountable Product Owner. Fewer of them. Much higher expectations. And finally, the authority to match.

The role is not disappearing. It is finally becoming what it was always supposed to be. The job market is already reflecting that. The question is whether the people in those roles, and the organisations hiring for them, are ready to meet it.

The author is a Professional Scrum Trainer with 15 years of experience helping thousands of Product Owners, in online and face-to-face settings, build human-centred products. These are personal reflections on a role and a market in transition, written with the conviction that honesty about the direction is more useful than pretending it isn't there.

The Shift in the Product Owner Job Market that Most People Haven't Noticed Yet