How product managers work with engineers using AI agents

The boundary moved from skill to consequence

For twenty years the split between product and engineering work was drawn on capability: engineers wrote the code because they were the only ones who could. That line has genuinely blurred, and the reaction in most teams has been either to pretend nothing changed or to conclude that product managers should now ship features. Both are wrong, because the line was never really about capability. It was about who carries the consequence when something is wrong at 2am, and that has not moved at all.

Draw the new boundary there instead. Anything whose worst case is your own wasted afternoon is yours. Anything whose worst case reaches a customer, a payment, a permission or an on-call rotation belongs to the person who owns that rotation, no matter how small the change looks or how confident the agent sounded.

What should a product manager build alone?

Four categories, and they share a property: the artifact exists to make a point rather than to serve a user.

Internal tools with an audience of one team. Demonstrations that settle an argument faster than a slide deck would. Throwaway versions of a flow you want to feel before you write the spec for it. Data views that answer a question you keep asking an analyst. In each case the software is disposable and the thinking is the product, which is exactly the trade an agent is good at.

The output of this work is not a feature. It is a better brief, and that reframing matters because it removes the awkward question of whether the product manager's code was good. Nobody asks whether the wireframe was well drawn.

What still belongs to engineering, and why difficulty is the wrong test

Anything inside the product's real codebase. Anything holding a customer's data, money or permissions. Anything that becomes a dependency for someone else's work. Anything that gets paged.

Notice that none of those is a statement about difficulty. A one-line change to a permissions check is trivial to write and catastrophic to get wrong, while a two-hundred-line internal dashboard is fiddly and harmless. Teams that sort by difficulty end up with product managers confidently shipping the dangerous small thing and deferring the safe large one. Sorting by consequence produces the opposite and correct assignment.

What actually changes in the handover?

Ambiguity stopped being self-announcing. When an engineer read an acceptance criterion that could mean two things, you found out, because they asked. An agent reading the same line does not ask: it selects one meaning, implements it thoroughly, and produces a clean pull request that looks finished. The interpretation you did not intend is now in the diff, and the only person who would have caught it is the person who wrote the ambiguous line.

This is why the spec format is under active revision rather than merely under pressure. Building with Claude Code teaches the distinction directly as a module: product requirement prompts against traditional PRDs, and when each one applies. The short version is that a PRD carries the reasoning a human needs and a prompt carries the constraints a machine needs, and most teams currently have one document trying to do both jobs badly.

What does an engineer want from you now?

The same three things as before, with the tolerance for vagueness removed.

• The constraint that lives outside the repository: the vendor rate limit, the retention rule, the partner API quirk nobody documented. An agent reads code and cannot read your institutional memory, so if it is not written into the project's context file, it does not exist.
• The decision, made. Not three options with a recommendation. An agent given an unresolved choice will resolve it for you, on your behalf, without telling you.
• The acceptance check, stated in a form something could actually run. Not "the dashboard should feel fast", but the number, the threshold and the condition.

That list is not new advice. What is new is that the cost of skipping any of the three used to be a conversation and is now a merged change.

Does this make delivery faster or just noisier?

Both, and which one you get depends on where your bottleneck already was. If code generation was the long pole, throughput genuinely improves. If the long pole was decisions, review capacity or dependency untangling, agents make the queue visible rather than shorter: five pull requests waiting on a product answer is the same delay as one, delivered faster.

This is the unglamorous half of the shift and it is where Project Management for Product does its work: planning and scoping without false certainty, dependency management across teams, and the reporting rhythm that keeps decisions moving instead of pooling. It runs 1 week with 8 self-paced microlessons alongside its live session, and it sits inside the Product Delivery Specialist Track, which bundles 6 bootcamps for people whose problem is predictability rather than ideas.

One honest number. Building with Claude Code is 1 week, 6 hours in total with 4 of them taught across 2 live sessions of 120 minutes. That is a small figure for a change in how a team works, and it is small deliberately: the bootcamp installs the setup, and the habit that follows takes considerably longer than six hours. Treat the number as the cost of starting, not the cost of arriving.

Where this goes wrong in practice

The most common failure is not a product manager overstepping. It is a prototype handed over as a foundation. Someone builds a convincing version of a flow, engineering is asked to productionise it, and every shortcut taken to move fast transfers along with it, including the ones nobody noticed taking. The prototype's value was the demonstration. Its codebase was never the deliverable, and treating it as one converts a two-day win into a two-week cleanup.

The second failure is quieter and more expensive: a product manager who now builds instead of deciding. Time spent building an internal tool is time not spent resolving the ambiguity three engineers are blocked on, and an agent has made your building time cheap without making your decision time cheap. The scarce thing did not change.

Who this is for, and who it is not for

This fits a product manager or delivery lead on a team where engineers already use agents daily, and where the working agreement has not been renegotiated since they started. It assumes you are not trying to become an engineer and are trying to stop being the source of the ambiguity that now ships.

It is a weaker fit if your team has not adopted these tools yet. The renegotiation described here follows adoption rather than preceding it, and doing it in advance produces a policy nobody has a reason to follow.

Renegotiate the handover with the same tools they use

The fastest way to write a spec an agent executes correctly is to have run one yourself, badly, at least once. Building with Claude Code is aimed at exactly that: context files, reusable skills, tool integrations, multi-agent workflows and the quality gates that catch bad output before a human has to. It is taught by Guilherme Salgueiro, and its companion on the delivery side, Project Management for Product, covers the coordination half that agents do not touch.

See the Building with Claude Code bootcamp

For the tool your engineers most likely have open, see building a prototype with Cursor and GitHub Copilot for product managers. For the design side of agent behaviour, see how to design an AI agent, and for the spec format the handover is moving toward, see the product requirement prompt.