Tech lead as product owner: when it works and when it fails
Stefan-Iulian Tesoi · · 6 min read
For a few weeks, usually yes. As a standing arrangement on a team running coding agents, rarely. The tech lead writes the acceptance criteria and then reviews the agent's work against them, so nobody checks the criteria themselves, and specification is the first job dropped when an incident lands.
The tech lead as product owner is the default on most teams of three to eight engineers, and it is rarely a decision. Nobody else knows the system well enough to write an item a coding agent can execute. Whether the tech lead can do the job is not in doubt. What stops while they do it is the question.
When does the tech lead as product owner arrangement work?
It works when someone else decides what to build, the agents are few, and the specification load stays under about five hours a week. Below that line, the tech lead absorbs the work into the gaps of a normal week and the cost is real but tolerable.
Three conditions tend to hold together when it works:
- Someone else owns the "what". A founder or product manager decides what should exist, and the tech lead turns those decisions into items. The tech lead is specifying, not choosing.
- The agents are few. One or two coding agents return a handful of items a day. Six verification decisions a day is manageable; twenty is a second job.
- It has an end date. A tech lead covering for four weeks while a product owner is hired keeps the role visible as a gap. One covering indefinitely makes the gap invisible.
It beats every alternative in the first month of agent adoption, when nobody yet knows what an executable item looks like on this codebase and the tech lead is best placed to find out.
Who checks the criteria when one person writes and reviews?
Nobody does, and that is the product owner conflict of interest in its plainest form. Code review checks the diff against the acceptance criteria. When the reviewer also wrote the criteria, a criterion that missed the point passes review, because the review measures the work against the same misunderstanding that produced it.
On a human team, the engineer doing the build used to cover part of that gap. They read the item, noticed it made no sense, and asked. A coding agent pushes back far less often. It builds what the criteria say, and when the criteria say the wrong thing, it builds the wrong thing correctly.
The second conflict is quieter. Tech lead responsibilities include keeping the codebase healthy, and a tech lead who also sets priorities will, reasonably, weight refactors and infrastructure ahead of the feature a customer asked for. Neither weighting is wrong. The problem is that one person holds both, with nobody to argue with.
| Role | The question it asks | What goes missing when one person holds both |
|---|---|---|
| Product owner | Is this the right change, specified so it can be checked? | Nobody challenges the criteria |
| Tech lead as reviewer | Does this change meet the criteria without damaging the system? | Review confirms the author's own intent |
Reviewing agent-written code assumes the criteria were right, and that assumption needs a second reader somewhere in the loop.
Why is specification the first thing dropped?
Because it has no deadline, no alarm and nobody waiting on it this hour. An incident has all three. A pull request has a colleague waiting for the review. An item that is not yet written well enough has nothing pulling at it until an agent picks it up and builds the wrong thing.
The pattern repeats: the backlog is groomed three weeks in four. In the fourth week, agents run on items written in the twenty minutes before sprint planning. The rework arrives the week after, and it lands in the tech lead's review queue, which is the same calendar that dropped the specification in the first place.
The tech lead does not stop writing specifications. They start writing them at the last possible moment, which is the moment they are worst at it.
What does it cost in hours each week?
Four to six hours a week on a team of three to eight engineers, before counting the extra review that weak items create. The breakdown is in what product ownership costs a small engineering team: writing acceptance criteria, sequencing work, checking what came back and answering questions.
For a tech lead, where the hours come from matters more than how many there are. The usual tech lead responsibilities, such as design decisions, unblocking engineers, code review and incident response, are already interrupt-driven. Four to six hours of writing that needs unbroken attention gets the leftover slots, which in practice means late afternoons and the hour before planning.
The cost worth measuring is the design work that stopped. Ask the tech lead when they last wrote a design document or paired on a hard module. If the answer is "before the agents arrived", product ownership has displaced it.
What are the alternatives to doubling up?
There are three, and they differ by what they cost rather than by which one is correct.
- Hire or borrow a product owner. A person who holds the business context writes the items, and the tech lead reviews them for feasibility before they reach an agent. Every criterion gets two readers again. The price is a salary, or a fractional contract at one to two days a week, which on a small team buys more hours than the load needs.
- Split the role by direction. The founder or product manager writes the criteria; the tech lead keeps sequencing and review. This is cheap, and it works once the person writing criteria can describe testable behaviour, a skill most people need a few weeks to learn.
- Automate the repetitive middle. An AI product owner drafts items with acceptance criteria, sequences them against work in flight, and checks returned work against criteria written in advance. Laimonade does this. A coding agent can take its work as far as In Review and no further; closing the item is a decision for the tech lead or for Laimon, the product owner agent, and each closure records who made it. The drafter and the reviewer are no longer the same person, so the criteria get a second reader.
For engineering managers weighing the three, the engineering leaders page covers what changes for a team that adds Laimonade, and what it does not do.
Frequently asked questions
How long can a tech lead hold both roles before it shows?
About four to six weeks on a team running more than one coding agent. The first sign is rework labelled as a code defect that traces back to an ambiguous criterion. The second is idle agents during a week when the tech lead was handling an incident. Both usually appear in the second month.
Does the problem go away with a second reviewer?
Partly. A second reviewer catches code that fails the criteria, and some code that meets bad criteria. It does not fix the criteria before the agent builds against them, so the rework still happens; it is only caught sooner. The cheaper fix is a second reader before the build, not after it.
Is this different on a team of two?
Yes. On a team of two there is nobody to hand either role to, so the goal becomes keeping the two jobs visibly separate. Book specification time as its own calendar block, and reread an item's criteria a day after writing them, when they read like someone else's work.
Can a tech lead be a product owner on a Scrum team?
The Scrum Guide allows it. It says the Product Owner is one person, not a committee, and it does not forbid that person also being a Developer. What it assumes is that the role gets the attention it needs to stay accountable for the backlog, which is the part doubling up erodes first.