The New PM Role

Four waves changed the vehicle. This one changed the constant.

For twenty years every generation of enterprise software felt like a disruption, and every one of them left the same thing untouched.

Client and server moved the screen off the mainframe, and a trained user still read it and decided. Service-oriented architecture had systems talking to each other, and a trained user still approved what they did. Cloud and mobile changed where and when the work happened, and the user was still there, reading and deciding.

Every one of those was an efficiency wave. They changed the vehicle. The person at the end of the path never changed, which is exactly why the tooling frame kept working for four decades, and why the comparison to spreadsheets holds so comfortably for all of them.

This wave removes the person from the path. That is not an increment on the previous four. It is the first time the constant moved, and it is why the artifacts we trusted all break on the same question.

The user story puts a person at the center: as a user, I want, so that. The journey map draws the path a human walks, step by step. Both of them assume somebody is walking it. Ask whether you can replace the persona with a model and the whole apparatus wobbles, not because the apparatus was badly built, but because it was built around a constant that has stopped being constant.

Hold that alongside the three vectors, because it explains the asymmetry between them. The efficiency vector is this wave behaving like the previous four. The other two are this wave doing the thing the previous four never did.

Efficiency, and why it will not move the needle

This is the vector everyone is talking about: tools, prototyping, faster synthesis, new skills. It is real. It is also the one that changes the least about what you ship.

Start with what it actually absorbs. A large language model is, at its core, a translation engine: it takes intent in one form and renders it in another. That landed directly on the part of the product manager's job that filled the most calendar hours. Writing the requirement. Drafting the story. Restating the same need in the language of engineering, then again in the language of the executive, then again, more slowly, for the person who missed the first three times.

That was the how of the job. It is the single thing a language model does most naturally, and it is being absorbed faster than any other part.

The Excel comparison, taken seriously

Fifteen years ago a comparable thing happened to analysts, and the comparison is worth making properly rather than as reassurance.

Spreadsheets absorbed an enormous amount of analytical busywork. They did not eliminate analysts. What they did was end the career of the analyst whose value was the mechanics, and promote the one whose value was knowing which question to ask. And here is the part that matters for the current moment: spreadsheets made every company's analysts faster and made no company better at analysis than its competitors. The gain was universal, so it was not an advantage. It was the new floor.

Efficiency that arrives for everyone on the same day is not an edge. It is a baseline, and the only question is how quickly you stop congratulating yourself for reaching it.

The part that is not neutral

If vector one merely failed to differentiate, it would be harmless. It does something worse than that. It lowers the cost of building the wrong thing.

A coding agent will produce a working prototype of almost anything you can describe in an afternoon. That is useful when the prototype exists to settle a question. It is dangerous when it exists to be shown, because the moment a prototype demos well, the go or no-go decision leaves the room and does not come back. Nobody kills a thing that works on a screen.

So the efficiency vector, on its own, produces more candidate products reaching a demo, each one arriving with its decision already made. Faster is not better here. Faster is the same product sooner, and occasionally the wrong product with a stronger alibi.

What the market is already doing about it

The commoditization is visible in hiring rather than only in tooling. Tom Verrilli, the chief product officer at Whatnot, has described building a product organization on the premise that they regret product management exists: not that PMs are useless, but that the industry started hiring them by ratio rather than by need, and that a PM added to every pod removes a rep from the engineers and designers who could have made the decision themselves. His team has taken thirty-one thousand eight hundred and thirty-two applications for product roles over two years and hired one.

He is also specific about what is trending down in interviews: candidates whose specialty was driving alignment and stakeholder management. The skill that got commoditized is fast, accurate translation. The skill that did not is the one underneath it.

Which is where the Excel comparison stops working, and the comparison's failure is the most useful thing about it. A spreadsheet computed exactly what you asked, the same way every time, and never made a judgment call. An agent decides. That single difference is the seam between vector one and everything that follows.

Judgment, which is the bulk of it

Translation was never the job. It was the visible part of the job, the part that filled the day and made it look like the product manager was a relay between functions. Underneath it was something the translation was carrying, and that thing is not only surviving the automation. It is becoming the most consequential work on the team.

Four questions make up that work, and none of them has a tool. Each has an owner.

Notice what these have in common. Every one of them is a decision that has to be made before the tools are useful, and every one of them is invisible in a demo.

Agent is a noun. Agentic is a dial.

One of those is what you buy. The other is what your system does, and only you can set it. Every vendor sells you the noun: a model, a set of tools, a loop, a component with a name on an invoice. Nobody sells you the dial, because the dial is the answer to how much of the loop your system closes without a person in it, and that is a judgment about your domain, your risk and your users.

Teams that treat the noun as the decision end up discovering their position on the dial after launch, by observing it. Teams that treat the dial as the decision place the product on a rung deliberately and name the one demonstrated competence that would justify moving it up. Same procurement, entirely different product.

The dial has rungs, and the judgment scales with them

Autonomy is not one setting, it is a ladder, and the human role changes at every rung. At rung one the system suggests and the person is a chooser. At rung two it drafts and they are an editor. At rung three it acts with approval and they are an approver. At rung four it acts with oversight and they are a reviewer. At rung five it acts autonomously and they are a supervisor.

The reason to put this in a paper about the PM role rather than only in a paper about supervision is that it explains why the second vector is not a fixed quantity. The judgment you owe is a function of the rung. At rung one a bad output is ignored by a person who was always going to decide anyway. At rung five a bad output is an action that already happened. Same model, same prompt, same team, and a completely different amount of product work owed.

Which is where most of the damage occurs. Teams climb the ladder incrementally, feature by feature, because each individual step looks small, and they climb without re-paying the judgment the new rung requires. Nobody decides to move from approver to reviewer. It happens because approvals were slow.

There is a line on that ladder worth marking explicitly. Below it, the system proposes and a human executes; mistakes are recoverable by construction, and this is the governance posture enterprises have run for two decades on workflow and process automation. Above it, the system touches state, and supervision stops being a review step and becomes a product with its own requirements.

One nuance keeps teams honest here. Low rungs are automation-like in governance posture, not in nature. A suggests-only model is still probabilistic and the suggestion can be confidently wrong. What makes the low rungs safer is the human hand between the output and the world, not determinism. Over-governing tends to stop below the line. Under-governing gets named above it.

This is the whole argument for why efficiency alone does not move the needle. The tools make it cheaper to build what you already know how to describe. They do not tell you whether it should exist, where it must stop, what good means, or who carries the consequence. An organization that invests only in vector one gets to the same product faster. An organization that invests in vector two gets to a different product.

Collaboration, because the artifacts changed for everyone

The most concrete of the three, and the least discussed. The unit of work that passes between product, engineering and design is no longer the same object, which means the working relationship built around that object has to change too.

What engineering is now asking for

The clearest way to hear the shift is to listen to what engineering asks you for. The request used to be a screen and the behavior behind it. The request now is the boundary: intent, policy, risk tolerance, escalation rules, and an acceptance criterion a test harness can actually check. Give me the boundary, not the screen.

Most product organizations have not changed what they hand over. They are still shipping personas, flows and stories into a build process that needs authority, limits and graded cases. That gap is not a communication problem and it will not be closed by a better template. The unit of work itself changed, from what the user does to what the agent may do.

The tell is easy to spot in your own documents. When you find yourself writing an acceptance criterion for an agent's judgment and it reads as pass or fail, you are using the deterministic tool on a probabilistic problem. The story format was built for software that does what you specified. It has no field for the invoice that is two percent over from a supplier who has been reliable for eight years, and that case is the only reason a human was in the loop at all.

The new engineering conversation

Two things moved on the engineering side and both change what you owe each other.

Generation got cheap and verification did not. A review of four hundred and seventy real pull requests found AI-generated changes carried roughly 1.7 times the issues of human changes, with logic and correctness errors up about seventy-five percent and error-handling gaps roughly doubled. The pattern has a name, the eighty percent problem: the agent nails the well-represented part and degrades across the remainder, which is exactly where the edge cases and the security assumptions live. The cost did not disappear. It moved from writing to reviewing, and it moved onto a team that did not sign the business case.

And enforcement is not yours. You decide where the boundary sits; the architect decides whether a wall stands there. A boundary written into a brief as prose the agent will read is a boundary the agent can reason its way past. A boundary written as a requirement with a number on it is one someone has to close. The failure lives in the hand-off, not in either person's work, which is why that hand-off now needs a check in the middle rather than a hope.

The new design conversation

Design gained a second user and it is often the same person. As a product climbs the autonomy ladder, the person who used to do the work becomes the person who watches the work being done. That person needs a product: the queue, the approval moment, the intervention, the record. A confirmation box asking "proceed?" transfers liability without transferring understanding.

Which makes the approval moment a design artifact rather than a dialog, and makes supervision a surface with requirements rather than something operations absorbs after launch.

Which vector are you being paid for?

The three vectors are not equal, and treating them as three equal thirds is how a real shift gets flattened into a list.

One of them is a tooling story. Two of them are a job-redefinition story. Vector one has the shortest half-life of anything in your current role, because it is universally available, improving monthly, and yours only until the next release reaches everyone else. Vectors two and three cannot be bought, cannot be installed, and do not arrive on a release schedule.

That suggests a blunt question worth asking about your own week. If a large part of it is spent on translation, restatement, synthesis and status, you are being paid for the vector with the shortest half-life. That is not a reason for alarm and it is a reason to move deliberately, because the work does not migrate on its own and nobody will hand it to you.

The honest answer, though, is that there is no single right mix, because the mix is a function of the rung. On a rung-one product the work really is mostly efficiency, and that is not a failure of ambition; a suggestion a person was always going to weigh needs speed more than it needs governance. Climb to rung three and judgment starts to dominate, because the system now touches state. Climb to rung five and collaboration dominates too, because the artifacts, the enforcement and the supervisory surface all have to be built by people who are not you.

The vector you should be paid for is set by the rung your product sits on, not by your title. The expensive failure is a team operating at rung four while still being measured, staffed and rewarded for rung one.

That failure is common and it is quiet, because nothing announces the climb. Approvals get slow, so a gate is relaxed. A workflow gets automated end to end because the pieces already existed. The product moves up a rung and the operating model does not follow, and the gap between them is where the incident eventually happens.

None of those three questions has a tool that answers it, which is the point. They are the part of the job that survived, and they were always the part that mattered.