Product ownership in the age of AI

Let me start by saying that since Claude Sonnet 4.6 was released, it has made me really think about my role and what value I bring throughout my work. AI is going to completely change my industry, if not the whole white-collar working space.

The scary truth is that there is so much I probably would not even bother putting on my résumé anymore. Skills I have spent years developing suddenly feel uncertain. Product ownership tools. UX frameworks. Large chunks of hard-earned expertise that I have no idea will still matter in five years.

There are so many skills that, frankly, I think AI can already do a better job at than me, or where the ways of working will be so fundamentally revolutionised that those skills may become irrelevant.

For me, that is a tough pill to swallow. I could not have imagined that those hard-earned skills, the ones that gave me more bargaining power in the workplace, could be swept out from under me.

So I have been trying to understand what I will do more of. Of course, these are just theories. Nobody knows where this is heading. But without a theory, you have no chance of adapting ahead of it.

So I thought I would put this post together about what I am doing as a PO in June 2026. It is likely this content will be outdated by July. Things are moving at breakneck speed.

Before I get to my theory, I want to hit on the three things that have changed for me this year as a Product Owner. Apart from the obvious stuff, like using meeting recordings to draft PRDs, I have three new ways of thinking as an AI PO that I would like to share.

As a Product Owner, you have a massive backlog of items. I am not a daily groomer, but at least once a week I move a few things around. One thing many people who do not work in product fail to understand is how big of an impact effort has on prioritisation.

I have seen many colleagues wrongly think of prioritisation as a single dimension: what is the most important thing to do now? Or perhaps, what is the highest impact thing to do right now?

But that thinking is flawed.

Impact is only one piece of the puzzle. The most impactful feature might take eight weeks to develop, while three less impactful features might take one week each. That equation becomes very different.

What I have noticed is that certain items lend themselves very well to AI. Projects that are mechanical, repetitive, and already have good examples in the codebase.

Right now, these items are dirt cheap to develop. In some cases, the effort has dropped to only 10% of what it used to be.

This changes the shape of the backlog. I'm still learning how to spot the work that suddenly costs 10% of what it used to, but it has become a new dimension in how I think about prioritisation.

To summarise, grunt work is dead. There is no more long, arduous, repetitive work in the same way there used to be. Now you can create a workflow, refine it, and iterate through an entire category of items.

Think about a configurable product where dozens of settings need to be migrated from a legacy page to a modern one. Historically that might have been months of repetitive work. Today it is often dramatically cheaper.

As a PO, you find yourself connecting customer problems to technology problems. This will always involve alignment between very different types of stakeholders with very different needs.

Sometimes understanding the feasibility of something early can save you a lot of time, especially with your dev team. A big part of what a developer does is work out how the product works today. What is the current state?

Every ticket represents a move from current state to desired state. Understanding current state is always a useful framing for tickets in the backlog, and a useful starting point when you are in the early problem-solving phase.

If you have just received a fresh problem from a customer and have an idea of how you could solve it, those questions often come back to architecture. If you work across distributed stacks, with many services all interconnected and communicating with each other, you will know that architectural details can completely change the direction you take things.

So what has changed for me is that I now use an IDE. I use a code editor, just like software engineers do. I sync the repos I am responsible for down to my local machine and use the code editor to effectively talk to the codebase.

This keeps me out of developers' hair and steers me in the right direction early. When I get into the room with developers, there is a much better chance that what I am thinking is feasible. That helps me move a lot faster.

As I explained in my first point, some work's effort has dropped down to about 10% of what it used to be. For that category of work, it means I need to prepare far more requirements than I used to.

This happened to me. I hit a position where I could not keep up with my engineers' need for new requirements. The engineer was scaling with AI, but I was not.

I investigated how I could solve this problem. I realised that the work I described in my first point was, in a way, also grunt work for me from a requirements perspective. We had lots of good examples in the product of similar work. More importantly, we had lots of great examples of tickets with similar work in the backlog.

This led me down the path of connecting into our backlog MCP server. It paired naturally with the workflow I already had for talking to the codebase.

I could pull similar tickets, record my voice explaining changes, and pull specifics from the codebase to tighten requirements. Things like URLs, exact names of fields, settings, and implementation patterns.

Now, not only was the development of these items taking 10% of the time it used to, but the product ownership work was too.

These three things have fundamentally changed how I do my work every day. I have already got new and exciting things I am doing that I am not yet ready to post about, but now to my theory about where things will go.

First, a fun exercise.

Take your job title, post it into whatever AI you are using, and ask:

I am a [insert role]. What role before the Industrial Revolution would most closely translate to my job today?

Now read the answer.

The First Industrial Revolution, which kicked off around Manchester in the 1770s, saw a fundamental shift in where energy came from to do labour. What used to be done with muscles and fed by grain, grass and agriculture — think a horse fed by hay turning a mill — was transformed into machines that used coal instead.

Machines took more of the physical labour, leaving humans with more of the cognitive work. In many ways, that process never stopped.

The history of technology is really the history of finding new ways to convert energy into useful outcomes.

I think AI is another important milestone on that journey.

Now cognitive work itself is entering the remit of machines. We are taking energy from coal, gas, nuclear, solar and renewables and increasingly converting it into cognitive output.

We have a competitor now. Or an ally. Maybe both.

My theory is that the jobs left will be those where you define the why.

Why do those cognitive tasks need to be done to begin with? Why is this self-driving car going where it is going? Why should we be excited about where we can take this product?

As AI gets better at answering questions, the value shifts towards deciding which questions are worth asking in the first place.

Maybe Product Owners become philosophers more than problem solvers. Less focused on execution, and more focused on deciding what is worth doing at all.