← Blog

Leaders With AI Blog

Most Product Owners Are Not Ready for What's coming Two Years From Now

Published May 28, 2026 / By Joshua Partogi
product owner product leadership agentic ai
A confession from someone who spent 15 years training thousands of them to be exactly this unprepared.

A personal reflection by a Professional Scrum Trainer · 2026

It started with a question from a participant.

I was running a PSPO AI Essentials course online, the kind of session where faces are small squares on a screen but the questions, when they come, land just as hard as they do in a room. We were deep into a discussion about agents as users, about what it means to build a product when the entity consuming it isn't a person. And someone stopped me and asked, quite plainly: 

"So the stuff you taught in PSPO training, the stuff about outcome and behaviour change... does that still apply?"

I didn't have a clean answer. And the silence that followed in that virtual room told me something I've been sitting with ever since.

For fifteen years, I have been training Product Owners, online and face to face, across industries, company sizes, cultures, and continents. Thousands of people have come through sessions with me, learning to think about users, outcomes, and the difference between building something and building something that matters. I have invested deeply in that, and in the people who've come through it.

Fifteen years is long enough that a set of ideas stops feeling like a curriculum and starts feeling like how you see the world.

And I am increasingly worried that the Product Owners I've trained, and the ones being trained right now, this week, in classrooms and virtual rooms around the world, are being prepared for a world that is shifting faster than the programmes are.

If AI agents become the primary consumers of software within the next two years, and there is growing evidence to suggest they will, then a significant number of Product Owners will be caught completely flat-footed. Not because they aren't talented. But because everything they've learned optimises for the wrong kind of user.


Why two years? Where is this coming from?


I want to be honest here. This isn't a certainty. It is partly my own hypothesis, informed by patterns I'm watching closely. But it is not without grounding.

The signal, not just the prediction
The mobile web transition took roughly four years from "interesting experiment" to "table stakes" between 2010 and 2014. The shift from desktop to mobile didn't announce itself clearly until it had already happened to the companies that missed it. The agentic shift is showing similar early indicators, but moving faster because the underlying infrastructure, large language models, API ecosystems, and autonomous tooling, is maturing at a pace that mobile hardware never could.

Sequoia Capital, one of the most influential voices in where technology is heading, has written explicitly about software moving from "human-interactive containers" to "agentic infrastructure." They argue the SaaS seat-based pricing model is already cracking because it makes no sense to charge per human user when one agent can do thousands of tasks in seconds. When the business model breaks, the product paradigm follows.

OpenAI, Anthropic, Google, and Microsoft are all in a race to deploy autonomous agents as mainstream consumer and enterprise products. That race has a two-year horizon on current trajectories. We are not waiting for the technology. We are waiting for adoption to tip. And adoption, historically, tips faster than anyone is comfortable with.

I could be wrong about the timeline. Two years might be three, or eighteen months. But the direction is not in question. The question is only whether the Product Owners building software today will be ready when it arrives.

The shift that's already happening, quietly


This isn't a prediction about some distant future. The reorientation is already underway in products you use every day, and most Product Owners haven't noticed because it's happening at the infrastructure layer, not the interface layer.

Travel. Expedia has built headless, agent-friendly API endpoints so AI travel agents can compare itineraries and execute bookings without ever rendering a UI. The visual flow that took design teams months to perfect is simply not in the journey anymore.

E-commerce and retail. For years, checkout funnels were optimised to prevent human buyer's remorse, relying on strategic confirmation screens to force a moment of human review before committing. An agent doesn't need that reflective pause. It already knows what it wants. Procurement agents using tools like Anthropic's Computer Use navigate checkout paths autonomously. This forces products to rethink rate limiting and fraud prevention entirely. If an agent hits a logic loop, it could purchase 500 enterprise laptops in seconds, making automated, machine-level error handling a critical product priority.

Data and analytics. Salesforce's Agentforce doesn't look at the beautiful colour-coded dashboards your team spent months perfecting. It ingests raw data directly via SQL and JSON, bypassing the visualisation layer entirely. Product teams at these companies are now building what they call "shadow layers," interfaces purely meant for AI agents to query data, sitting underneath the human-facing dashboard like a parallel product.

Communications. Traditional notifications are timed around when a human might look at their phone, lunch hour, commute time. An agent operates 24 hours a day and responds within milliseconds. When a system broadcasts a notification to thousands of active agents simultaneously, their instantaneous, concurrent response creates a massive synthetic DDoS spike on internal servers. Urgency and backend rate-limiting protocols must be rewritten for a user base that literally never sleeps.

We are living through something that behaves exactly like the mobile wave of 2010. Companies that didn't pivot then didn't fail because they were incompetent. They failed because they were excellent at optimising for a screen that was no longer the primary screen.
The same dynamic is playing out now. Except the new "screen" has no pixels at all.

Why Product Owners specifically are underprepared


Developers are already adapting. API design, schema structure, idempotency, rate limiting, these are engineering conversations happening right now, in sprint reviews and architecture sessions. Engineers can see the technical seams changing and they're responding.

Product Owners are trained to live one layer above that. They think in terms of user journeys, personas, jobs to be done, and outcome metrics. And almost all of that training assumes the user is a person, someone who experiences confusion, frustration, satisfaction, and delight.

An AI agent experiences none of those things. It doesn't get confused by cluttered navigation. It gets stuck on a broken data schema. It doesn't feel frustrated by a slow page load. It times out and retries, potentially triggering a cascade of duplicate transactions. It doesn't feel delighted by a thoughtful onboarding flow. It needs a well-structured OpenAPI specification it can parse and act on immediately.

The gap
Most Product Owners are still asking: "What does the user feel at this moment?" They haven't yet started asking: "What does the agent parse at this moment? What happens when it hits an ambiguous response? Does our system handle a retry loop without duplicating a payment?"

The tension sitting inside my own training room


That question from the online PSPO AI Essentials session hasn't left me. Because it surfaces a tension I haven't resolved.

Scrum.org now offers both the Professional Scrum Product Owner course and the PSPO AI Essentials course. They sit alongside each other. Participants move between them, or attend one without the other. And I am finding myself asking: should I be teaching different things in each? Or the same things with a different lens? And if the answer is different things, what does that mean for my honesty as a trainer?

The dilemma
In PSPO, I teach outcome over output. I teach that the measure of a great product is a change in user behaviour. In PSPO AI Essentials, I'm exploring a world where the user may be an agent that doesn't have behaviour in any meaningful human sense. Do I teach those two things as if they're compatible? Do I acknowledge the tension explicitly in one course but not the other? And if I'm teaching different perspectives in different rooms, am I being inconsistent, or am I being honest about the fact that the field is genuinely in transition?

There is also a harder version of this question. Most participants who come to my PSPO trainings are not from outcome-driven organisations. They're from output-driven ones. They measure velocity, count features, track release dates. A significant part of every PSPO training is just getting them to see that output isn't the point, that a released feature nobody uses is not a success.

So if I now introduce the agentic complexity on top of that, telling them that even outcome as behaviour change is getting complicated, am I helping them or pulling the floor out from under people who haven't found solid ground yet? Do I skip the outcome conversation entirely for participants still operating in output-driven organisations, and jump straight to agent-era thinking? That feels like doing them a disservice. But staying silent about the agentic shift also feels dishonest in a different direction.

I don't have a clean answer. And after fifteen years, that is an uncomfortable place to be.

What happens to the UX Researcher in the room?


Here is the part of this I find hardest to write.

For fifteen years, I have taught Product Owners to work closely with UX Researchers. That relationship is central to how I think about good product development. The UX Researcher is the person who gets you out of your assumptions. They go and sit with real users. They watch people struggle. They bring back the uncomfortable truth that the feature your team spent three sprints building is being completely ignored, or worse, is causing harm. I have seen that partnership change the direction of products in ways that no amount of data analysis could.

So when the user is an agent, who does the Product Owner work with?

You can't interview an agent. You can't watch it feel confused. You can't ask it what it was trying to accomplish when it hit the error. What you can do is instrument the API, analyse the logs, look at where parse failures cluster, measure retry rates, study the pattern of calls that end in timeouts. That work sounds less like UX research and more like data science.

The uncomfortable question
Is "AX Research," if we're even calling it that, just data science with a product framing? And if it is, what does that mean for the UX Researchers who have built careers around the craft of understanding human beings? The skills that make a great UX Researcher, empathy, the ability to hold space for a user's confusion, the instinct to ask the follow-up question that reveals the real problem, those skills don't map cleanly onto analysing JSON logs and API failure rates.

I don't want to be dramatic about this. UX Research isn't disappearing overnight, and there will still be human users of many products for a long time. But I also think it would be dishonest to pretend the shift doesn't create real pressure on a discipline that was already fighting for its seat at the table. If the primary user stops being human, the role built around understanding humans is going to have to change significantly, or find the products where humans remain central.

That is a hard thing to say. It might read as saying a role becomes redundant, and I understand why that lands badly. I'm not saying it with any satisfaction. I'm saying it because I think denying it would be worse.

What I hope, and this is genuinely a hope rather than a certainty, is that the instinct at the core of UX Research, the discipline of understanding the entity using your product deeply enough to build for them honestly, survives the transition even as the methods change entirely. But what that looks like in practice, I don't yet know.

What is success when the user has no behaviour to change?


This is the tension that sits heaviest with me, and I want to stay in it rather than resolve it too quickly, because I think Product Owners need to feel it too.

For fifteen years, I have taught that outcome is a change in user behaviour. Not features shipped. Not velocity points. Actual, observable, measurable change in what real people do. Did they accomplish something they couldn't before? Did they stop doing something harmful? Did they do something valuable more often?

This definition works because human behaviour is observable, meaningful, and connected to real stakes. People have habits. They have a before and after. Behaviour change is a signal that something genuinely shifted.

So what is outcome when your user is an AI agent?

An agent doesn't have habits. It doesn't have a before and after in the same way. It executes a task loop. You can measure task completion rate, parsing error rate, retry frequency, latency, cost per successful call. These are real and useful numbers. But they describe the performance of a machine, not the transformation of a person.

Is it still about change in user behaviour? But what does that even mean if the user is an agent? Behaviour implies a pattern that can be shaped by experience. Agents don't learn from your product the way users do. They just execute, or they don't.

If an agent keeps coming back to your product repeatedly, is that a good thing? For a human user, retention is one of the strongest signals of value. Return visits mean the product is working. But an agent returning again and again might not mean value is being created. It might mean it's stuck in a retry loop, attempting the same call with slightly different parameters, burning compute and creating noise.

Is a returning agent a loyal user, or a DDoS attack you accidentally caused? In human-centric product thinking, we almost never have to ask that question. In agentic product design, it might be one of the most important questions on the backlog.

And if an agent never comes back, is that failure, or is it the highest form of success? Did it complete its task so cleanly, in a single well-structured call, that it had no reason to return? A human product that users never revisit is a dead product. An agentic product that completes tasks in one clean exchange might be a perfect one.

Everything we thought we knew about engagement, retention, and return visits needs to be interrogated from scratch. The metrics that signal health in a human product might signal dysfunction in an agentic one. And the metrics that signal dysfunction in a human product, low return rates, single-session completions, might signal excellence.

What's actually different, concretely


Interface
Designed for humans: Visual UI — buttons, modals, charts.
Designed for agents: Headless — clean APIs, JSON payloads, webhooks.

Speed
Designed for humans: Async — humans check phones later.
Designed for agents: Synchronous real-time — milliseconds matter.

Error handling
Designed for humans: "Oops! Something went wrong."
Designed for agents: Structured JSON with explicit remediation paths.

Permissions
Designed for humans: Session tokens, single-user OAuth.
Designed for agents: Granular, task-scoped programmatic guardrails.

Return visits
Designed for humans: Retention signal, the product is working.
Designed for agents: Could be success, or a runaway retry loop.

What "good" means
Designed for humans: Visual clarity, low cognitive load, delight.
Designed for agents: Predictability, structure, machine legibility.


What Product Owners need to start thinking about now


These aren't instructions. We are early, and nobody has this completely figured out. These are the questions every Product Owner needs to start holding before they become urgent:

  • Your API is now your product. If a feature only exists as a button in the UI, an agent can't use it. Every capability needs a clean, documented API path, or it effectively doesn't exist for the next wave of users.
  • Error messages are agent instructions. Vague errors cause expensive retry loops. Structured errors with explicit remediation let agents self-correct. "Please try again" is not a product decision. It's a product failure.
  • Blast radius planning. An agent in a loop can order 500 units in seconds. Circuit breakers, spending caps, and rate limits per agent session need to be product requirements, not engineering afterthoughts.
  • Idempotency is not optional. Agents retry on network failure. Every state-changing operation must be safe to call multiple times. Duplicate transactions and records become product-level liabilities.
  • Least-privilege permissions. Define exactly what scope each agent needs per task, and nothing more. At agent speed, over-permission is a product risk, not just a security concern.
  • Reversibility as a feature. Agents make autonomous mistakes. Rollback and transaction reversal need to be first-class product capabilities, designed in from the start, not bolted on after an incident.
  • Redefine what outcome means. Task completion rate? Autonomous operation without human fallback? Cost per successful execution? Start constructing the definition now, before you're measuring the wrong thing under pressure.
  • The human is still upstream. Someone set the goal. Someone holds accountability. Understanding where the human sits in the loop is still where the most important product decisions need to serve.

Two years is genuinely not long


I've been in this long enough to know how these timelines feel. Two years sounds like a comfortable planning horizon. It isn't. Two years ago, most organisations were still arguing about whether generative AI was real or hype. Now it's in their roadmaps, their budgets, and their hiring briefs.

The Product Owners who will navigate the agentic shift aren't going to be the ones who panic-read a whitepaper in twelve months. They're going to be the ones who started asking uncomfortable questions now. Who sat with the tension between what they were trained to do and what the product landscape is becoming. Who started building literacy in API design, agent failure modes, and what "good" looks like when your user has no eyes, no feelings, and an infinite appetite for structured, unambiguous data.

I'm still a practitioner who believes deeply in human-centred thinking. I'm not ready to abandon that. But I am beginning to understand that human-centred, in the agentic era, means caring about the human who deployed the agent. The person whose goal it's serving, whose trust it operates within, whose life it's meant to improve.

The user moved. It didn't disappear. And it's our job as Product Owners, as trainers, as practitioners who've spent fifteen years building conviction in this craft, to move with it.

Even when we don't yet know exactly where we're moving to.

Related reading