What AI Can Do and Can’t Do for You as a Product Owner
AI can help us move faster, but are we going in the the righ direction?
AI is changing the way we work. It is not just helping developers write code faster. It is also becoming part of the discovery process and helping us shape features.
I use AI for creating screen designs, brainstorming ideas, challenging my thinking, and evaluating whether a new feature or improvement actually fits with the current application.
But I have realised something along the way.
AI can help us move faster, but someone still needs to be in the driving seat.
AI is an ongoing conversation
For me, using AI is not about asking one question and getting an answer.
It is an ongoing dialogue.
I give it context, explore an idea, challenge it, change my thinking and add more context. I use it to look at a problem from different angles and sometimes to understand the existing application better.
The interesting part is that I have also learned AI by working with other people.
Whenever we were doing something together or demoing something, I started observing how other people were using AI. Everyone explores it in different ways. There is no standard way of using AI.
And I think that is actually part of the skill.
You cannot really compare how one person uses AI with another person. People are constantly experimenting and trying to become more efficient.
But, as humans, we also have a tendency to stop once we become comfortable with something.
That is why I think the most important part of the AI journey is to explore, observe, learn from each other and keep growing your skillset.
But then comes the handover
This is where I started seeing another challenge.
After all the discovery, brainstorming and discussions with AI, eventually we need to turn that thinking into something the team can build and write an epic out of it.
And this is where context can get lost.
A well-written epic is important, but sometimes it is simply not enough.
The epic might explain what we want to build. But the AI conversation, research, experiments and discussions contain a lot of the why.
I have even used branches and merge requests during discovery to research the existing application and explore how something could work.
All of that helped me reach the final solution.
But when you hand over the epic, you cannot just hand over all of that context automatically.
You still need to talk to people.
A lesson from a feature that went wrong
I experienced this myself with a feature where users needed to use two pricing methods side by side and switch between tabs while retaining their values.
I had given the full context to the Tech Lead. The Tech Lead then had a technical refinement with a developer. We had a short demo before delivery and everything appeared to be working fine.
But when I tested it just before delivery, I realised that the data was not actually being stored across sessions. It was only temporarily stored in the browser cache.
The feature technically worked, but it didn’t meet the actual user need.
I had to pull the feature back just before delivery and create an improvement epic to make sure we actually delivered what was needed.
When we looked at what had happened, I realised that somewhere in the process of passing the requirement from one person to another, the context had been lost.
It was almost like passing the parcel.
I had explained the context to the Tech Lead. The Tech Lead had technically refined it with the developer. But somewhere in between, the original why was no longer clear.
What did I learn?
For me, this was also a lesson in ownership.
It would have been easy to say that the developer misunderstood the requirement or didn’t really understand what was needed or that the context was lost somewhere between hops or the tech lead wasn’t clear enough or they faced a technical challenge but never communicated back.
But that doesn’t really solve the problem.
The question should be:
What can we do differently next time?
We realised that, for important features, it might feel like we are wasting the team’s time by having everyone in the refinement. But actually, spending time together upfront can save much more time later.The whole team needs to understand the idea behind the feature.
Not just what we are building.
But why we are building it.
I also learned something myself. I had used the words “data retention”, but I should have been more specific and said “the data needs to be retained across sessions.”
That small difference in wording completely changed the expected behaviour.
So the lesson wasn’t just about the team. I also had something to improve in the way I communicate requirements.
AI doesn’t completely remove the need for people
This is where I think we sometimes get the AI conversation wrong.
We talk about AI making us more efficient, automating work and helping us create things faster.
And it does.
But faster does not automatically mean better.
AI can help us explore an idea. It can help us create designs. It can challenge our thinking. It can help us understand an existing application and even help us get to an epic much faster.
But AI doesn’t own the product decision.
Someone still needs to understand the user problem, provide the context, make the decisions and bring people together.Someone needs to be in the driving seat.For me, that is one of the biggest opportunities for Product Owners.
Use AI to accelerate the work, but don’t lose the human conversation around it.
Because sometimes the most important part of a feature is not what is written in the epic.
It is the conversation that explains why.
Comments