helloguido

I handed a good part of my job to an agent. Here's what was left.

Guido9 November 20267-minute read

I started delegating most of the production work that makes up a product manager's routine to an AI agent: documentation, business refinement, story breakdown and implementation plans. This piece reports what the agent did better than I did, where it failed, and what remained as work that is distinctly human. The main conclusion is that automating production does not eliminate the product function, but shifts its center to an activity almost no organization practices regularly: reviewing assumptions after launch. I propose a name for the liability that builds up when that review doesn't happen, assumption debt, and a simple protocol to reduce it.

The question

In October 2026, Miles Nurse published the essay Hire the translator, not the title, arguing that AI is absorbing the PM's "production hats" (tickets, acceptance criteria, status reports) and that the remaining work is translation: presenting the same trade-off to a CFO, a designer and a tech lead so that each understands what is being given up.

The thesis is plausible, but it was formed by observing teams, not from a deliberate test. My question was narrower: if I hand an agent everything delegable in my own work, what exactly is left for me?

Method

This is a single-person case study and should be read as one. For each new initiative I give the agent five inputs: the goal, the constraints, the initial hypotheses, access to the data needed to validate or refute them, and the team's available capacity.

The agent returns a nearly complete PRD, to which I still add some metrics by hand; an implementation plan; the business refinement; a list of items to validate; and a proposed story breakdown. For low-complexity tasks it also proposes a plan I can implement myself.

I did not measure time in a controlled way. My estimate is about 15 hours a week freed up. The most reliable indicator I have is indirect: the overtime that used to be frequent has become rare.

Results

What the agent does better

In production itself, the agent outperforms me on consistency. It covers error and edge cases in acceptance criteria without the fatigue that makes a person skip steps, keeps documentation current, and doesn't vary in quality from one day to the next.

The most relevant result, however, came from analysis, not production. In one initiative, the problem was a sign-up that is only completed when a second person receives an invitation and finishes a confirmation step. The data showed that invitations were being sent and that a good share of processes stalled there.

The team's premise was that the obstacle was the confirmation step itself, for being laborious or poorly explained. Planning was already heading toward redesigning it. By cross-referencing the data, the agent shifted attention to an earlier point in the flow: the invitation. The hypothesis we are now investigating is that the message we send doesn't make clear to the recipient that there is an action to complete for the process to finish.

That point hadn't been examined because the invitation data wasn't available in the dashboards the team checks day to day. The information existed, but outside the usual field of view. The case illustrates a common pattern in human reviews: they tend to evaluate each screen in isolation, while the agent walked through the entire sequence of events.

Where the agent fails

The failures were frequent and of three kinds. The agent states unfounded premises with the same confidence as it confirms true ones. It mixes up the contexts of different initiatives. And it blends topics within a single document.

None of these failures is detectable from a quick read, because the text it produces is fluent and well structured. In practice, this requires full review of every deliverable, not spot-check supervision. That vigilance cost is real and has to be subtracted from any estimate of time saved.

Discussion

Translation is necessary, but not sufficient

The experiment confirms the first half of Nurse's thesis: production hats are delegable, and a good share of them already have been. The second half, that the remaining work is translation, seems to me correct but incomplete.

Translating a decision for different audiences presumes the decision rests on valid premises. When those premises aren't reviewed after launch, good translation produces alignment around something that may never have been true. In that scenario, translation skill amplifies the error instead of correcting it, because it convinces more people, faster.

Assumption debt

I propose calling assumption debt the set of hypotheses that underpinned product decisions and were never confronted with data after delivery.

The concept is analogous to technical debt in three respects: it accumulates silently, it makes future decisions more expensive, and it is rarely paid down on anyone's own initiative. It differs in one decisive respect. Technical debt usually has organizational visibility, with backlog items, owners and cycles dedicated to paying it down. Assumption debt appears in no management artifact, and so it tends to grow unnoticed.

The invitation case is an example of assumption debt caught before it was incurred: an intuitive hypothesis was about to guide weeks of work.

There is a structural reason to expect agents to increase this liability. By lowering the cost of building, they increase the volume of deliveries. If assumption review doesn't grow in the same proportion, the debt accumulates faster than before.

I also record an example of my own. With Candidatei, a product I build alone for people looking for jobs, I have operated since my time at a large job platform on the premise that candidates pay someone to help them prepare for a job opening or an interview. I built features on top of that premise without ever testing it deliberately.

What remains with the PM

From the experiment, I identify three functions I couldn't delegate to the agent.

  1. Translation. The function Nurse describes: making a decision understandable to disciplines with different vocabularies and incentives.
  2. Managing the portfolio of bets. The agent produces analyses that inform where to invest, but it doesn't answer for the choice. Deciding to stop an initiative, reallocate a team, or sustain a bet without conclusive evidence requires someone who takes on the consequences before the organization.
  3. Closing the loop. Returning to a delivery after launch and checking whether the premises that justified it held. It is the least practiced of the three and the only one that reduces assumption debt.

Nurse argues the first function is a condition for the second, because the trust earned through translation is what gives legitimacy to managing larger bets. I agree with that order, but I'd add that the third function underpins the other two. Without it, translation can't be corrected and the portfolio has no scoreboard.

A protocol: the D+30 review

To make the third function practical, I propose a minimal protocol. Thirty days after each launch, the people involved meet for about 45 minutes to answer a single question: which premises supported this delivery, and what does the data say about each one today?

Each premise gets one of three classifications:

ClassificationNext step
ConfirmedRecord the evidence and close it
RefutedOpen a backlog item to fix the delivery or the strategy
UndeterminedDefine which data would settle it and a deadline for getting it

The agent can gather and cross-reference the data before the meeting, which lowers the cost of the protocol. Classification and next steps, however, remain decisions for the people in the room.

Limitations

This account has limits that need to be stated. It is one person, in one organizational context, with no comparison group. The time saving is estimated, not measured. The invitation case is still under investigation, and the hypothesis the agent raised may not be confirmed.

There is also an author bias. I've worked in product for 17 years and have a direct interest in the function surviving. Nurse, who started as a designer, concludes that designers are good candidates for the remaining work. I conclude that the PM who reviews premises is indispensable. It is reasonable to suspect we are both defending our origins. A reading compatible with both arguments is that the residual function belongs to whoever exercises it, regardless of title.

Next steps

The next essay will detail the D+30 protocol based on putting it into practice.

As for the hours freed up, part went into other initiatives and into leaving the backlog pre-refined from a business standpoint. The other part went to physical activity and study, which is not a product outcome, but may be the hardest one to get by other means.

Reference

If you're rethinking the product role on your team, or deciding what to do with the time AI gave back, write to me on LinkedIn. Thirty minutes, no proposal at the end.

Guido on LinkedIn