The product owner skills that coding agents make scarce
Stefan-Iulian Tesoi · · 6 min read
Three product owner skills move to the top once coding agents do the building: writing a criterion someone else can check by running something, cutting work into items with one observable outcome each, and reading the evidence that comes back instead of the summary of it. Stakeholder work still matters. Estimation sessions mostly stop being the job.
None of the three is new. Each used to be done part-time, by whoever had a spare hour, because a developer reading a loose ticket filled the gaps from context. A coding agent fills the same gaps with guesses, at the speed it writes code, so the part-time skills become the scarce ones.
Which product owner skills matter most now?
The ones that decide whether an item can be built without a conversation. When a developer took two weeks over a story, a vague sentence cost a question at standup. When a coding agent takes two hours, the same sentence costs a finished, wrong change, and the question arrives in review instead.
The 2020 Scrum Guide gives the product owner four accountabilities: developing the Product Goal, creating and clearly communicating backlog items, ordering them, and keeping the backlog transparent. None of the four changed. The weight between them did, and so did what "clearly communicating" has to mean when the reader is a program.
| Product owner competencies | When people built the item | When a coding agent builds it |
|---|---|---|
| Writing acceptance criteria | Helpful; the developer asked about gaps | Decisive; gaps become guesses |
| Story splitting | Kept sprints tidy | Decides whether an item can finish |
| Reading what came back | A demo at the sprint review | Item by item, against evidence |
| Estimation sessions | Rationed developer weeks | Rations little; the build takes hours |
| Stakeholder facilitation | Central | Central |
| Ordering the backlog | Central | Central, and done more often |
What an AI product owner actually does describes the role from the other side, as the work a tool can take on. The skills below are the parts a person still has to be good at to direct it.
How do you practise writing checkable criteria?
Write each criterion as a thing to run and a thing to observe, then hand the item to someone who was not in the room. "Search feels fast" fails that test. "A search over 10,000 items returns in under 300 ms in the staging load test" passes it, because anyone can run the test and read the number.
Writing testable requirements is learned by watching criteria fail. Three habits make the practice cheap:
- Name the thing to run. A test file, an endpoint, or a page and the action taken on it. A criterion with no verb a machine can perform is a wish.
- Name what to observe. An exit code, a status, a row in a table, text on a screen.
- Write the failing case too. "An expired link shows the expiry page" catches more defects than "a valid link works".
The exercise in teaching a team to write executable items is the fastest version: hand each person their own item, unedited, to an agent, and let them read what comes back. It takes about an hour. For anyone asking how to become a better product owner this year, it beats a course, because the feedback is a running program. More worked examples are in acceptance criteria that an agent can verify.
Cutting work by outcome, not by component
Story splitting for an agent means one observable outcome per item. "Build the export API" and "build the export button" are components, and neither can be checked by someone using the product. "An admin can download last month's invoices as CSV" can.
The skill is in what to cut away. A well-sized item has three or four criteria. An item that needs nine is usually two or three items, and the giveaway is criteria that describe different users or different screens. Splitting by outcome raises the number of items, which is the point: each one can finish, be checked and be released without waiting for its siblings. Splitting stories for coding agents walks one story into six.
How do you read evidence instead of a summary?
Read the checks that ran, not the sentence describing them. Evidence is a command, its exit code and a count. A summary is a claim that the evidence exists, written by the same process that wrote the code.
This blog has a recent example. On 22 October 2026, a coding agent's commit for two posts reported the remaining build guards as passed. The deploy build then failed at the image check, because one post's photograph was already the hero of another. The fix, two hours later, reported that same guard with a count: "81 heroes, no repeats". The second line can be checked against a build log. The first could only be believed.
A reviewer can re-run a command. Nobody can re-run a sentence saying it passed.
Reading evidence is a habit rather than a technical skill. Open the list of checks before the description. Look for the check that did not run. Ask for the number where there is only a verdict. Laimonade's hand-over asks a coding agent for each check as a row, with the exact command and its result, so a reviewer reads rows rather than prose. What evidence a coding agent should return lists the fields worth asking for.
Which skills matter less, and which do not change?
Estimation matters less, facilitation does not change, and code review stays with engineers. The Scrum Guide already makes the Developers responsible for sizing, yet many product owners spent hours in planning poker, because the estimate decided where scarce developer weeks went. When a build takes hours, that rationing argument shrinks, and the time is better spent on criteria. Do story points still work with coding agents covers what is worth keeping.
Three things do not move at all:
- Saying no. Cheap building multiplies the requests worth refusing.
- Ordering. A queue that empties in days needs ordering more often, not less.
- Talking to the people who use the product. No criterion is better than the understanding behind it.
Reading code is not on either list. A product owner who can follow a diff gains something, but judging how a change was built is code review, and the product owner's question is whether it does what the item said.
Frequently asked questions
Does a product owner need to read code now?
No. A product owner needs to read evidence: which checks ran, what they returned, and which criterion each one covers. Following a diff helps, and some product owners enjoy it, but judging how code was written is code review, which stays with engineers. The product owner's question is narrower: does the change do what the item said?
Can a developer pick these skills up faster than a product owner?
Often, for the criteria. Developers already think in tests, so a checkable criterion comes easily to them. The harder parts are deciding which outcome is worth building and refusing the rest, and those come from time spent with customers rather than with code. Teams that run agents well tend to pair the two people.
What is a good interview exercise for a product owner?
Give the candidate a vague backlog item and twenty minutes to make it buildable: one outcome, three or four criteria someone else could run, and a split if it is too large. Then show a submission with a confident summary and one missing check. A hiring panel learns more from whether they find the gap than from any answer about agile.