What’s Left for the PM?

Of the four crafts in this section, the product manager’s should have been the safest, and it was the most exposed. The engineer produces code, the designer produces screens, things with a shape you can point at and a skill you can respect. The product manager produced documents and meetings, which everyone on every team has privately suspected for years could be cut in half with no loss. So when a machine arrived that is, at its core, a translation engine, that takes intent in one form and renders it in another, it landed directly on the part of the job that filled the most calendar hours: writing the requirement, drafting the story, restating the same need in the language of engineering and then again in the language of the executive and then again, more slowly, for the person who missed the first three times. That was the PM’s how. It is the single thing a language model does most naturally. The translation layer that was the daily texture of the job is the layer most completely absorbed.

If that were the whole story, this would be a short and grim chapter. It is not, because translation was never actually the job. It was the visible part of the job, the part that filled the day, the part that made it look like the PM was a relay between functions. Underneath it was a different thing the translation was carrying, and that thing is not only surviving the automation, it is becoming the most consequential work on the team. The question of this chapter is what the PM is once the translation is stripped away, and the answer is the one the whole book has been building toward: the PM is the person who decides what should exist, and encodes that decision precisely enough that an agentic team can build it without being told a fourth time.

The how that was always a proxy

It helps to be exact about what got automated, because the loss is real and pretending otherwise is how PMs end up defending the wrong ground.

The requirement document is largely a generated artifact now. Hand a model the intent and the constraints and it will draft the user stories, the acceptance criteria, the edge cases you would have spent an afternoon enumerating. The status update, the stakeholder summary, the translation of an engineering reality into an executive sentence, all of it is the kind of rendering a language model is built for. A PM who measures their value by the volume of these artifacts is measuring the part of the job the machine just made nearly free, and there are a lot of PMs who, if they are honest, spent most of their week there. The discomfort is legitimate. A large fraction of what the role did all day is gone.

But notice what the translation was always for. You did not write the requirement because the writing had value. You wrote it because a decision had been made, that this was worth building, in this way, for this reason, and the requirement was how you transmitted that decision into a form the builders could act on. The document was the carrier. The cargo was the decision. For thirty years the carrier was so labor-intensive, so much of the job, that we mistook it for the cargo, the same way the designer mistook the screen for the craft and the engineer mistook the writing for the work. The agent did the team a brutal favor: it made the carrier nearly free, which finally separates it from the cargo and shows you which one you were actually being paid for. You were being paid for the decision. You were spending your time on the document.

The decision was always the job

Strip the translation away and what is left is two things, and they are the two the foundations of this book already named, the go/no-go and the executable brief, and they are what remains when everything else is automated.

The first is the go/no-go: the judgment about whether this thing should exist at all. Is this the right problem, for the right user, at the right time, worth the cost, aligned with where the product needs to go. That decision was never automatable, because it is not a translation of anything; it is a bet, made under uncertainty, against a future the data does not yet contain. The agent can give you more of the inputs to the bet, faster, the research, the competitive scan, the synthesis. It cannot make the bet, because making the bet is taking responsibility for an outcome, and an agent does not have a career or a reputation or a customer who will remember. The go/no-go is the first thing that is left, and it is the most important, because everything downstream is leverage on it.

The second is the intent itself, encoded with enough precision that the build is faithful to it. This is the executable brief the foundations introduced: not the human-readable explanation of what you want, but the specification exact enough that an agentic team builds the right thing from it, including the value it is supposed to deliver and the way you will know whether it did. This is where translation does not disappear so much as change in kind. The old translation was lossy and repetitive, the same idea restated for different human audiences who each understood a fraction. The new translation is singular and exacting: one specification, precise enough to govern a machine that will do exactly what it says and not what you meant. That is a harder skill than the old translation, not an easier one. The old kind forgave imprecision because a human on the other end would fill the gap with judgment. The new kind punishes imprecision, because the agent fills the gap with a confident guess and builds it at full speed.

In practice these two come in sequence around a single gate, and the sequence is the PM’s to run. The first thing the PM writes is the slim decision brief, the case for the bet and nothing more, taken into a room with a sponsor and a finance partner and, crucially, the architect and the domain expert, because the suitability tests that decide the bet are partly theirs. The gate fires, and most ideas stop there. Only on a go does the PM write the second pass, the commitment, where the boundary and the accountability and the definition of done get designed, and only then does the executable brief begin in parallel. The PM owns both passes and owns the discipline of not collapsing them: the temptation, now that the agent makes a fluent full brief cheap to produce, is to write the whole thing up front and call the decision made by having specified it. That is the failure the foundations named, the bet made by default in the act of writing, and the two-pass order is what prevents it, because a slim brief forces the decision to be a decision before it becomes a blueprint.

A PM who understands that the cargo, the go/no-go bet and the executable intent, was always the job has just been handed back all the time the carrier was eating.

What it looks like done right

The abstraction deserves a concrete case, because “make the decision and encode the intent” can sound like the same advice every product book has given for thirty years. It is not, and the difference shows up in the details of a single feature.

A payments team, the same one whose retry logic failed earlier in this section, wants to add instant payouts: let a merchant withdraw their balance in seconds instead of the next business day. The agent can build it in a day, and that is exactly the trap. The PM’s work happens before the agent is ever pointed at the problem, and it is two distinct acts.

The first is the go/no-go, and it is not a translation of a stakeholder’s request. The loudest customers want instant payouts; the data shows competitors have it; the agent’s research summary recommends building it. All of that is input, and none of it is the decision. The decision is the bet the PM makes against a future the data does not contain: that instant payout will not become an instant fraud-drain, that the support cost of reversing erroneous withdrawals will not exceed the retention it buys, that this is where the next quarter’s scarce attention should go rather than the reliability work the same team owes the same merchants. The agent assembled the case. The PM owns the verdict, and owns it the way you own a thing your name is on when it goes wrong.

The second act is encoding the intent precisely enough that the fast build is the right build. Here the old translation and the new one diverge sharply. The old requirement might have said “let merchants withdraw their balance instantly,” and a human engineer would have filled the gaps with judgment, asking, at the standup, what about a merchant whose recent charges might still be disputed. The agent does not ask. It builds exactly what the spec says, at full speed, and a spec that says “withdraw their balance instantly” ships a system that lets a merchant pull out money that a customer is about to claw back. The executable intent has to carry what the human engineer used to supply: that “balance” means settled, undisputed funds; that an account with an open dispute or an abnormal charge pattern is held for review; that instant means seconds for the trusted majority and not-at-all for the risky few, and where that line sits. None of that is decoration on the requirement. It is the requirement, and it is the difference between a feature and an incident. The PM who writes the loose version and the PM who writes the exact version did the same amount of typing. Only one of them did the job.

Why the front end is now the scarce work

There is a reason this matters more now than it did when the carrier was expensive, and it is the through-line of this whole book, so let me state it plainly here because the PM chapter is where it is most true.

When building was slow and costly, the cost of building was itself a brake. A wrong go/no-go or a vague spec got caught, eventually, by the sheer friction of execution: somebody, three weeks into building the wrong thing, would notice it was the wrong thing, and the slowness that was a curse was also a safety net. The expense of execution bought time to discover a bad decision before it had fully played out. The agent removed the brake. Execution is now fast and cheap, which means a wrong decision is no longer caught by the friction of building it; it is reached faster, fully realized, at scale, with everyone’s name on it. Speed is a multiplier, not a corrective. It multiplies whatever it is pointed at, and if it is pointed at the wrong thing, it gets you to the wrong thing sooner and more completely than slow execution ever could.

That is what makes the front end the scarce, decisive work. When execution was the bottleneck, it was rational to spend your judgment there, on getting the build right, because the build was where things went wrong slowly enough to fix. Now the build is not where things go wrong; the build is faithful and fast. Things go wrong at the front, in the decision and the intent, and they go wrong invisibly, because a precise spec for the wrong product produces a beautiful, working, fully-shipped wrong product. The scarce work moved to the only place a mistake is now expensive: the bet about what to build, and the precision of the intent that encodes it. Everything the agentic team does downstream is leverage on those two things, and leverage on a wrong premise is just a faster way to be wrong.

I have watched the other end of this. Early in my career I was part of a team that spent close to ten months writing a strategy document for a platform, a hundred and ninety-eight pages, small font, every diagram you can imagine. The doctrine of the time held that planning should take roughly three times as long as building, and that document was the planning, taken with deadly seriousness, because the cost of building the wrong platform was a multi-year mistake. We have spent the twenty years since then dismantling that, shrinking the plan, moving it inside the sprint, then inside the ticket, on the theory that fast iteration would catch what big planning used to. And it did, as long as iteration was slow enough to be a check. Now iteration is not a check, because it is too fast to function as one, and the question the hundred and ninety-eight pages were really answering, are we sure this is the right thing, has come back, stripped of the pages, as the only question that still matters. The planning did not die. The ratio collapsed and the document shrank to a paragraph. But the discipline the document enforced, deciding carefully before committing, is more load-bearing now than it was when it took ten months, because nothing downstream will catch the error anymore.

How the new job goes wrong

Every other chapter in this section named a failure mode, because the failure mode is how you can tell the job is real. The designer’s was the unsupervised supervisor; the engineer’s was the house of cards; the team’s was the ceremony preserved as a husk. The PM has one too, and it is more dangerous than any of them because it is the most invisible.

The old PM failed loudly. A bad requirement produced confusion, a missed deadline, a feature nobody used, and the failure announced itself somewhere in the long slow process of building, with enough time and enough people in the loop that someone usually caught it. The new PM fails silently, and fails faster. The characteristic failure is not writing a bad document; the document is the part the agent now handles. It is making a confident decision on a shallow basis and encoding a loose intent with total fluency, and then watching the agentic team build it, correctly and beautifully and at full speed, into the wrong thing.

This is worse than the old failure for a specific reason. When the carrier was expensive, a half-formed decision tended to expose itself during the labor of carrying it; you could not write the hundred-and-ninety-eight pages without, somewhere around page sixty, discovering the hole in your own logic. The carrier was a slow, involuntary audit of the cargo. Strip the carrier away and the audit goes with it. A PM can now move from a vague intuition to a deployed product without ever being forced to slow down enough to notice the intuition was vague, because nothing in the pipeline imposes the friction that used to do the noticing. The agent will not push back; it renders whatever it is given. The fluent spec for the half-understood problem looks identical, on the page, to the fluent spec for the well-understood one. The only difference is in the world, three weeks later, when the thing ships and is wrong in a way no one decided.

The new failure also has a quieter, slower version, which is the one that should worry a careful PM more. It is the gradual outsourcing of the judgment itself. The agent’s research is good, its synthesis is plausible, its recommended go/no-go is usually reasonable, and a PM under time pressure can slide, one decision at a time, from using the agent’s analysis as input to using it as the answer. Nothing dramatic marks the slide. Each individual hand-off feels efficient. But the end state is a PM who has stopped making the bet and started ratifying the agent’s, and the one thing the role exists to do, take responsibility for a decision under uncertainty, has been quietly delegated to a system that cannot hold responsibility at all. The failure is not that the agent decides badly. It is that no one is deciding, and the org will not notice until the bet it never consciously made comes due.

The convergence, from the seat that can see it

This is the closing chapter of the section, so it is the place to say what the chapters add up to, and the PM is the right vantage because the PM is the one who can see it.

Each of the other crafts migrated toward judgment, but it is a mistake, and the mistake this chapter most wants to prevent, to think they migrated to the same judgment. They converged on the posture and kept their objects, and naming the object each one now owns is the cleanest way to see why the team still needs all of them. The engineer stopped being the author of the code and became the owner of one exclusive question no other seat can answer: whether the code holds together and is safe to run, the review throughput and the integration risk and the accountability for what ships. The designer stopped making the screen and became the owner of whether a human can supervise the thing at all, the supervisor’s calibration and the approval surface, which is design’s alone because no other craft studies how a person behaves under uncertainty. The architect owns whether the boundary is real and the system fits, the enforced wall rather than the wish, a question she was always standing on. The team’s coordination became the work of keeping the collaboration human as the agent absorbs the ceremonies. And the PM owns the one judgment furthest upstream, whether the thing should exist at all and what success would even mean, the build-or-don’t and the definition of done that every other seat’s work is downstream of. Same posture, five different objects, and the objects are why the walls between the disciplines do not vanish even as the hows that built those walls get cheap. What converged is the kind of work. What stayed distinct is what each kind of work is about, and a team that hears “everyone does judgment now” and staffs one judgment-worker has confused a convergence of posture for a collapse of roles. The error is not just incomplete, it is backwards: once everyone is doing judgment, the judgments overlap at the seams, and the seams are where the failures live, which is why the supervision side of the work has to separate into distinct owners even as the building side converges. Merge to decide, separate to ship. That division is what the whole next half of this book is about.

The PM can see this when the others cannot, and the reason is structural, not flattering. The engineer sees the convergence from inside engineering and describes engineering migrating toward judgment. The designer sees it from inside design. Each stops at the edge of their own craft, because that is the edge of their view. The PM is the only role whose job was always to stand in the seam, across all the crafts, translating between them, which means the PM is the only one positioned to watch them all arrive at the same destination from different roads. The translation job is gone. The vantage the translation job gave you is the thing that survived it, and it is more valuable than the translation ever was, because someone now has to hold the whole, see that the crafts have converged, and own the decision they have all converged on. That is not a relay between functions. It is the center.

So what is left

What is left for the PM is the part that was always the job and never got the time it deserved, because the carrier was eating the calendar. What is left is the go/no-go, made well, made with the responsibility an agent cannot hold. And what is left is the obligation that comes with all of it, which is heavier than it was, because the safety net is gone.

I will end the section on the sentence the whole book is built to defend, because it is truest here, at the front of the pipe, where the PM stands. Good product always depends on good planning. All the magic we now do, the vibe coding, the agents building agents, the team of ten people doing the work of a hundred, is worthless if the go/no-go was wrong or the spec encoding the intent and the value was incomplete. The agent did not change that. It removed every excuse not to face it, by taking away the slow execution that used to hide a bad decision and replacing it with fast execution that broadcasts one. The PM’s job was always the decision. Now it is only the decision, and the decision matters more than it ever has, because everything else has been automated except being right about what to build.