What an AI Product Owner actually does
Stefan-Iulian Tesoi · · 6 min read
An AI product owner turns decisions into work items an agent can execute, sequences them so nothing blocks, hands them over as work orders, and checks what comes back against the criteria it wrote. Deciding what to build stays with a person.
Teams that adopt coding agents usually discover the same thing about a month in: the agents are not the constraint. Writing the code stopped being the slow part. What replaced it is less visible and harder to staff — keeping a backlog in a state an agent can actually work from.
What does an AI product owner actually do?
What does a product owner do, once agents are writing the code? Four jobs, and only the fourth is new:
- Specify. Turn a decision into an item that can be acted on without a follow-up question.
- Sequence. Order the work so nothing is asked for before the thing it depends on exists.
- Dispatch. Get the right item to the right agent, with its dependencies resolved.
- Verify. Check what came back against the criteria that were written before the work started.
For most of the last two decades those four collapsed into one role, because the bottleneck sat downstream of all of them. When building took three weeks, spending a day on specification was rounding error and nobody needed to name the parts separately. At forty minutes a change, the naming matters: three of the four are now the slow part, and the fourth barely existed as a discipline.
The gap is product ownership, not code
An agent handed "improve the onboarding flow" will produce something. Whether it produces the right thing depends entirely on what surrounds that sentence: which repository, what "improved" means, which behaviour must not change, and how you will know it worked.
That is product ownership for coding agents, and it does not scale by adding more of them. Three agents working from an ambiguous backlog produce three plausible interpretations and a merge problem.
It also does not scale by working harder at it, which is the more surprising half. The work is not difficult — it is repetitive, and repetitive work decays under load in a way difficult work does not. Nobody forgets how to write an acceptance criterion. People skip writing one on a Thursday when four items are waiting and the agents are idle.
What does agent-ready mean in practice?
An agent-ready backlog item needs four things that a human-only team often leaves implicit:
- A target. Which repository, which surface. Obvious to whoever wrote the item, invisible to anyone else.
- Acceptance criteria that can be checked. Not "works well on mobile" but a breakpoint and a behaviour.
- Dependencies that are stated. If the item needs work that does not exist yet, an agent will build against the gap rather than notice it.
- A scope boundary. What this item does not cover, so two items do not both claim the same change.
Every one of those is cheap to write and expensive to omit. Omitting them does not produce an error — it produces confident, wrong work, which costs more than an error because it passes review.
The test is not whether the item is well written. It is whether somebody with no memory of the planning conversation could act on it and be right.
A work order, end to end
Concretely, for one small change:
| Field | What it says |
|---|---|
| Repository | The checkout, by name, not "the frontend" |
| Outcome | What a user can do afterwards that they could not before |
| Criteria | Three or four checks, each runnable |
| In scope | The files or surfaces this item may touch |
| Not in scope | The adjacent thing somebody will otherwise "fix" |
| Evidence | What to hand back: commands run, exit codes, files changed |
The agent fetches that over MCP — the Model Context Protocol, the open standard Claude Code and Cursor both speak — rather than being pasted a ticket. It builds, then submits with the evidence attached. Nothing is marked done: a person reads the diff against the criteria from before the work started, and closes it or sends it back labelled as either bad code or bad criterion, because the two need different fixes.
Why is this a product and not a checklist?
You could enforce all of that by hand. Most teams start there and stop, because the discipline decays the moment a sprint gets busy. The interesting question is whether the ownership layer can hold the standard on its own: notice the item with no target, refuse to hand an agent work whose dependencies are unmet, and record what it learned when the work turned out to be wrong.
The four backlog defects we keep finding are the argument in miniature. Each one is obvious once named and invisible while unnamed, and each survives review because review tests whether a reader understands an item, not whether a builder could execute it. A checklist catches them on the day someone remembers the checklist. A system catches them on the fortieth item of a bad week, which is when they actually appear.
That is the layer Laimonade is building. Not another way to run agents — a way to be sure the work you give them is worth doing.
What it deliberately does not do
Three things stay with a person, and this is a boundary rather than a limitation we expect to lift:
- Deciding what should exist. Priority is a judgement about a business, not an inference from a backlog.
- Marking work done. An agent reporting on its own work grades its own homework. Finished work moves to review with its evidence; a person closes it.
- Ruling on whether a criterion was right. Roughly half of what we send back turns out to be a specification defect rather than an implementation one, and only someone who knows what was wanted can tell those apart.
A system that writes the acceptance criteria and also rules on whether they were met has no independent check in it anywhere. That is worth more than the hours it costs.
If you want the four failure modes in detail, they are in a backlog an agent can actually read. The symptoms that say a team has this gap are in signs your team has a product ownership gap, the split of who holds which half in who owns the backlog, the bill in what product ownership costs a small team, and the comparison with the role it does not replace in AI product owner vs human product owner. What Laimonade is covers the mechanics, and the sprint workflow covers how a week of this actually runs.
Frequently asked questions
Does this replace a product manager?
No. It replaces a specific part of the work — writing items an agent can execute, sequencing them, and checking returned work against the criteria. Deciding what the product should become, what it is worth, and what order it happens in stays with a person. On a small team that person is usually the founder or the tech lead rather than anyone holding the title.
What happens to the backlog we already have?
Most of it stays where it is. The items you will actually work on in the next two sprints need their criteria rewritten anyway, and everything older is reference material that is cheaper to leave alone than to migrate badly. Starting with the next twenty items is both the fastest way to see whether this helps and the cheapest to undo.
Can an agent mark its own work done?
Not here, deliberately. Work an agent finishes moves to review carrying its evidence: the commands it ran, their exit codes, and the files it changed. A person closes it. The whole value of the verification step is that something other than the author is doing the checking, and an agent closing its own story removes exactly that.
How is this different from an AI feature in our existing tracker?
An AI feature summarises items for people. This produces items for agents and then checks what came back. The distinction shows up in what happens on a bad day: a summariser gives you a tidier version of an unexecutable item, and an ownership layer refuses to dispatch it until the repository is named.