AI Product Owner vs human product owner
Stefan-Iulian Tesoi · · 6 min read
A human product owner decides what the product should become and why. An AI product owner takes those decisions and turns them into work items an agent can execute — repository named, acceptance criteria testable, dependencies sequenced — then checks what comes back against the criteria it wrote.
Those are not two versions of one job. They are two different halves of it, and only one of the halves grew when coding agents arrived. A product owner for coding agents spends their week on a different problem than a product owner for people did.
What does an AI product owner do that a human one does not?
It writes the same item many more times. A person grooming a backlog stops when the item is clear to the next person who will read it, because that reader has the context — they sat in the meeting, they know which of five repositories the team means by "the app". An agent has only the text. Closing that gap means restating things nobody on the team would ever say out loud, for every item, every week.
That is tedious rather than difficult, which is exactly the shape of work worth automating. The judgement in product ownership is not in the restating.
The four jobs a product owner actually holds
Under one title there are four separable jobs:
- Deciding. What should exist, what it is worth, what order it happens in.
- Specifying. Turning a decision into an item someone — or something — can act on without asking a follow-up question.
- Dispatching. Getting the right item to the right builder at the right time, with its dependencies already resolved.
- Verifying. Checking that what came back satisfies what was asked, before anyone calls it done.
For most of the last two decades these four collapsed into one role because the bottleneck sat downstream of all of them. When building took weeks, spending a day on specification was rounding error, and nobody needed to name the parts separately.
Which of those jobs survive contact with a coding agent?
Deciding does. The other three change shape entirely.
| Job | Before agents | With agents |
|---|---|---|
| Deciding | Weekly, in a meeting | Unchanged — still weekly, still human |
| Specifying | Good enough for a colleague | Complete enough for a reader with no context |
| Dispatching | A board someone pulls from | A work order fetched over MCP |
| Verifying | Review of a pull request | Review against criteria written in advance |
Specifying is the one that breaks first. Teams about a month into agent adoption usually report the same thing: the agents are not the constraint any more, and the queue that formed instead is a queue of half-written items. Work that takes an agent forty minutes can wait three days for the sentence that says which repository it belongs in.
Dispatching changes because copy-paste stops scaling at about two agents. Verifying changes because an agent's summary of its own work is a claim, and claims are cheap — we have watched a story marked complete sit on top of a diff that did not implement it.
What stays the human product owner's decision?
Three things, and they are not negotiable at the edges:
- Whether a thing should exist at all. Priority is a judgement about a business, not an inference from a backlog.
- Whether an item is done. An agent reporting on its own work grades its own homework. Laimonade moves finished work to review and stops there; a person closes it.
- Whether a criterion was the right criterion. Roughly half of the agent work we send back turns out to be a specification defect rather than an implementation one. Only a person can tell those apart, because telling them apart means knowing what was actually wanted.
This is a deliberate boundary rather than a current limitation we expect to lift. A system that both writes the acceptance criteria and rules on whether they were met has no independent check in it anywhere.
The useful division is not human versus machine. It is deciding versus specifying — and product ownership was always both, bundled into one person because nobody had to separate them.
How the two roles work together in one sprint
A week, concretely:
- Monday. A person sets priority: three things matter, in this order. That conversation is short because it is the only part of the week that needs their judgement rather than their typing.
- Monday afternoon. The AI product owner takes those three and produces executable items — repository, observable outcome, acceptance criteria that can each be checked by running something, dependencies sequenced so nothing blocks. Items that cannot be made executable come back as questions, not as guesses.
- Tuesday to Thursday. Agents fetch work orders over MCP — the Model Context Protocol, the open standard Claude Code and Cursor both speak — build, and submit with evidence: the commands they ran, the exit codes, the files they changed. Nothing is marked done.
- Thursday and Friday. A person reviews against the criteria from Monday. Rejections are labelled as either bad code or bad criterion, because the two need different fixes and a rejection with no reason produces the same failure twice.
The human hours in that week are the Monday conversation and the Thursday review. The hours that disappeared were spent restating context that the AI product owner now writes down every time, without getting bored on the fortieth item.
Two other things follow from running it this way. Backlog grooming stops being a meeting and becomes continuous, because there is no longer a reason to batch it. And the sprint's real constraint becomes visible: not how much the team can build, but how many items are specified well enough to be built. Our own backlog audits keep turning up the same four defects, and every one of them is invisible until somebody tries to implement from the item.
If you want the longer argument for why this role exists at all, it is in what an AI product owner actually does. For how the loop runs day to day, what Laimonade is covers the mechanics, and the engineering leader's view covers what changes for the person holding the team.
Frequently asked questions
Does an AI product owner replace a human product owner?
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 someone with the title.
Who approves that a story is done?
A person does. Work an agent finishes moves to review with its evidence attached: the commands that ran, their exit codes, and the files that changed. Nothing closes on the agent's own say-so, because a system that writes the acceptance criteria and also rules on whether they were met contains no independent check at any point.
What happens when the AI writes an acceptance criterion that cannot be met?
It surfaces as a blocked item rather than as a failed one, and that distinction matters. The common case is a circular criterion: an item requires output from a second item that is sequenced after it, on the reasonable grounds that there was nothing to produce yet. Both items are individually sensible and together they cannot both be satisfied. A person re-sequences them; nobody rewrites code.
Is this just automated backlog grooming?
Grooming is part of it and not the whole of it. Grooming improves items in place. An AI product owner also dispatches work to agents, holds the sequence across a sprint, and checks returned work against criteria written before the work started — which is the half that keeps "done" and the repository from drifting apart.