When agents write the code, the product manager's leverage moves upstream to framing the problem and authoring the spec. The slow part of building is no longer implementation; it is deciding precisely what to build, which makes the PM who writes an executable specification the most valuable person in the room.
For two decades the product manager's job had a familiar shape. Gather requirements, write tickets, groom a backlog, defend priorities, and wait while engineering turned the words into software. The bottleneck sat in implementation, so the PM's job was mostly about deciding what to build and in what order.
Agents broke that shape. When a coding agent can turn a precise specification into working software in an afternoon, the slow part is no longer implementation. It is deciding exactly what "precise" means.
The leverage moved upstream
Under the AIDLC method, the AI Development Life Cycle I run on every build, the first two phases are Frame and Spec. Both belong to the product manager more than to anyone else.
Frame pins down the user, the single constraint that matters, and the metric that proves the system earns its keep. Spec turns that frame into an executable contract, written so a coding agent can build against it without a single clarifying question. The PM who can do this well is worth more than three who can groom a backlog, because a vague spec now produces a thousand lines of confidently wrong code instead of a polite request for clarification.
The skill that used to be optional, writing with enough precision that there is exactly one correct interpretation, is now the core of the job.
What the day actually looks like
The grooming meeting shrinks. The spec review grows. A modern PM spends less time arguing about priority order and more time writing acceptance criteria that an eval suite can check. They sit closer to the engineering loop, watching traces of how the agent interpreted their words, and tightening the spec when the agent drifts.
If you are a PM whose team has adopted AI coding tools but whose process still looks like 2022, that gap is the thing slowing you down. The fix is not another tool. It is a method that puts your spec at the center of the build, which is exactly what AIDLC does.
The PMs who win
They treat the spec as the product. They own the success metric end to end. They learn just enough about evals to know when a requirement is testable. And they stop measuring their output in tickets closed and start measuring it in shipped behaviour that holds under load.