What a product owner costs a small engineering team
Stefan-Iulian Tesoi · · 6 min read
On a team of three to eight engineers, keeping the backlog executable takes four to six hours a week. That is the product owner cost, and it is paid whether or not anyone holds the title: writing acceptance criteria, sequencing dependencies, and checking returned work against what was asked for.
The figure surprises people because it never appears on a calendar. Nobody books four hours for grooming. It arrives in fifteen-minute pieces between other things, gets filed as engineering overhead, and escapes measurement that way.
Where does the time actually go?
Into converting decisions that have already been made into instructions someone else can follow without asking a question.
That distinction is the whole cost. Deciding what to build next is fast — most teams of this size can settle priority in a twenty-minute conversation. Writing it down so a coding agent or a new contractor can act on it without a follow-up is slow, and it is slow in a way that does not compress with experience. The facts have to be gathered: which repository, which existing pattern to follow, what the thing should do when the input is empty, which test proves it.
This cost stayed hidden under a human-only workflow, because whoever built the work usually held the missing facts in their own head. They wrote the item, they built it, and the specification never had to leave the skull it was formed in. Point a coding agent at the same item and every unstated fact becomes a question or a wrong guess.
Which four activities consume the week?
Four, and they divide roughly evenly between writing work down and checking it came back right.
| Activity | Hours a week | What it looks like when skipped |
|---|---|---|
| Writing acceptance criteria | 1.5–2.5 | Work comes back matching the title, not the intent |
| Sequencing and dependency checks | 0.5–1 | Two agents edit the same module in the same hour |
| Reviewing returned work against criteria | 1.5–2 | "Done" means the diff compiled and nobody complained |
| Answering clarification questions | 0.5–1 | The queue stalls behind one person's inbox |
The cost of backlog grooming is the easiest of the four to measure and the one most often quoted alone, which is why the total gets underestimated by half. Grooming is the first row. The third row is the same work read backwards, and it grows with agent throughput rather than with team size — two agents shipping six items a day produce six verification decisions a day, on a team that used to make six a week.
Sprint planning is where the shortfall becomes visible. The meeting was designed to negotiate capacity, and on a team running agents it quietly turns into a readiness check: not can we build this, but is this written well enough to hand over. Usually nobody renames the meeting.
What does a product owner cost when nobody is named one?
More than hiring one, in most cases, because the work still happens — it is simply billed to the most expensive person available, at the worst hour of their day.
The arithmetic is worth doing with your own numbers. At a fully loaded cost of €110,000 for a senior engineer and 2,080 working hours a year, an hour is about €53. Five hours a week across 46 working weeks is 230 hours, or roughly €12,000 a year. That is the floor, and it assumes productive hours rather than the leftovers after 5pm.
The floor is not what makes it expensive. These four costs are:
- It lands on the most senior person. The work requires knowing the system, so it defaults to whoever knows it best, which is whoever is least replaceable.
- It is the first thing dropped in a busy week. A backlog that is groomed three weeks in four produces a fourth week where agents run on last month's specification.
- Rework is charged twice. An item built from an ambiguous criterion costs the build, the review, the argument and the rebuild. About half of the rework we see labelled as a code defect is a specification defect wearing a code defect's clothes.
- It has no queue. Engineering work that exceeds capacity shows up as a growing sprint backlog. Specification work that exceeds capacity shows up as idle agents, which looks like a tooling problem.
The visible cost of product ownership is four hours a week. The invisible cost is that the four hours come out of the one calendar you cannot afford to fill.
Hire, absorb, or automate?
Hire when the specification load exceeds roughly fifteen hours a week, absorb below five, and automate the repetitive middle — which is where teams of three to eight almost always sit.
The market answer at this size is to hire a product owner for startups on a fractional basis, and it runs into an arithmetic problem: four to six hours a week is too little to hire for and too much to donate. A fractional product owner is typically contracted at one to two days a week, which buys more than the load and costs more than the value — and a half-present product owner has the worse version of the problem, because they hold none of the missing facts in their head.
Three tests, in the order that settles the question fastest:
- Count the clarification questions. Of your last twenty items, how many needed a question answered before work could begin? Above a third, the specification is the constraint and no amount of hiring downstream helps.
- Time ten items from prioritised to ready. Compare it to build time. Whichever is larger is what you are actually paying for.
- Label last month's rework. Bad code or bad criterion. The ratio tells you whether to invest in review or in specification.
What is worth automating is the part that is identical every time: turning a decision into an item with criteria, sequencing it against what is already in flight, and checking what came back against the criteria written in advance. That is what an AI product owner does, and it is what Laimonade was built for — it drafts and verifies; a person still decides what is done and what ships. For a team of one or two, the solo founder case is different again, because the hours have nowhere to move to. The pricing page is priced against those hours rather than against seats.
The accountability itself is not new. The Scrum Guide has described the Product Owner as a single accountable person since 2001, and it says nothing about how many hours it takes, because until recently nobody was consuming specification fast enough to find out.
Frequently asked questions
Can a tech lead absorb product ownership part time?
Up to about five hours a week, yes, and most do. Past that it competes with the work only they can do, and it loses — specification is the task with no deadline attached, so it slips first. The failure is not that it stops happening, but that it happens in the last twenty minutes before a sprint starts.
What is the first thing to automate?
Acceptance criteria, because it is the input to everything downstream. An item with testable criteria can be verified mechanically, which removes the second cost centre as well as the first. Automating review before specification produces confident verification of the wrong thing, which is worse than no verification at all.
Does this change if the team is remote?
It raises the clarification cost and lowers everything else. A question that costs thirty seconds across a desk costs half a day across time zones, so the value of an item that can be executed without a question is higher. The four activities are the same; the penalty for doing them badly is larger.
How is this different from what a project tracker already does?
A tracker stores the item once someone has written it. The cost measured here is the writing, sequencing and checking — none of which Jira, Linear or Shortcut do on your behalf. Replacing one tracker with another moves unexecutable items more quickly, which is why the migration rarely changes the number.