返回长文
由 AI 译自中文约 12 分钟

The Golden Age of Internet Product Managers Is Coming to an End

If agents become the direct operators of software, how does a product manager's work change? Following the Salesforce Koa story further, I explore interfaces, capabilities, and the changing role of people.

I'm someone who loves to keep asking questions. Sometimes, following an idea one level deeper opens up a new perspective, and things get interesting.

A couple of days ago, as I was finishing my article on Salesforce Koa, I had a feeling that, if I pushed the argument a little further, there was a question hiding underneath that the industry was seriously overlooking.

In the two or three years since we entered the AI era, whenever people discuss AI's impact on careers, programmers invariably dominate the conversation.

From writing code to running tests, barriers are visibly being smashed. Many engineers are anxious about whether they'll be among the first to be replaced by AI. UI and front-end designers are feeling the chill too, because generating interfaces and assembling components are among the first things AI has disrupted.

But have you noticed that one crucial role seems to have been quietly given a pass? The people in that role may even feel they have nothing to worry about: product managers.

Many people privately think: if writing code gets cheaper and building interfaces gets easier, surely we'll need people who understand needs and human behavior to define products more than ever?

But if we follow the underlying logic of how software is evolving, we might arrive at a provocative conclusion that points in exactly the opposite direction:

Perhaps we've got this completely backward.

Programmers are facing an upgrade to their tools. The people facing an entire way of thinking becoming obsolete, and their skills plummeting in value, are the product managers shaped by the past twenty years of the internet industry.

This isn't entirely an alarmist hot take. If we take the Salesforce Koa example one step further, there's a question we all have to face:

If software is primarily going to be used by agents, will SaaS still be SaaS as we understand it today?

If most software will be operated by agents in the future, then the product design methods the software industry has built over the past twenty years around “making software easier for people to operate” will themselves become outdated.

01 What have product managers been paid so well for over the past twenty years?

To unpack this provocative argument, we first need to look back objectively: over these twenty years, what has been the core ability of a supposedly “excellent product manager”?

Think of the classic product manager skill set from the internet's golden age:

Research users → map user journeys → design pages → place buttons → optimize click paths → reduce learning costs → improve conversion rates.

Whether building apps at a tech giant or working on enterprise SaaS, product managers always seem to discuss:

Should this button go on the left or the right?

Should this process take three steps or five?

What should this tab be called?

How do we make this foolproof and easier to use?

How do we remove two form fields and bring the abandonment rate down a few percentage points?

Why were these abilities so valuable that companies were willing to pay excellent product managers annual salaries of more than a million yuan?

Because for the past thirty years, software rested on one absolute premise:

The person directly operating the software was a human.

Humans have weaknesses.

Our eyes get tired. We have emotions. We are terribly impatient. We dislike complexity.

If a button is buried too deep and users can't find it, they'll simply uninstall the app. If a system asks employees to fill in three more fields, they may resist or refuse to use it altogether.

So product managers have to think on people's behalf: how to click, where to click first, where to go next, and how not to get lost.

At heart, the entire product manager's playbook has been about accommodating human nature:

How do we make cold machine logic feel smoother, more comfortable, and easier for people to work with?

We've built a vast, sophisticated discipline of interaction design around human eyes and fingers.

But what if, one day, humans are no longer the ones directly operating the software?

02 Designing for humans vs. designing for agents: when the interface disappears, the old skills lose their power

At the end of the previous article on Salesforce Koa, we discussed an important trend: software is becoming headless.

What does “headless” mean?

In plain language, it means removing the “face”: the graphical user interface, or GUI.

The familiar software we've known for thirty years—complex menus, densely packed tables, elaborate dashboards, and web apps you have to log into before you can click anything—is rapidly receding into the background.

Salesforce says employees may go months without logging into their CRM. You say something in Slack, Claude, or another familiar chat window, and an agent behind the scenes calls APIs, retrieves data, updates statuses, and moves workflows along.

This brings the most consequential change:

The direct user of software shifts from a human to an agent.

Once that operator changes, much of the skill set product managers have relied on so confidently suddenly loses its relevance.

Think about it. If an agent operates the software and can call an API in five milliseconds, does it care whether your button is on the left or the right?

Does it care whether the process takes three steps or five?

Does it care what you've named a tab in your menu?

Does it care about the interface's color palette and whitespace?

When 80% of future operations aren't initiated by human clicks, how much business value is there in “saving one click”?

Users might never even see that page. The value of an interaction flow buried in a secondary page, which product managers once spent so much effort optimizing, would naturally fall sharply.

When software no longer has to appeal to human eyes and fingers, what remains of the moat for product managers who have devoted most of their energy to making it smoother for people to use?

03 In the AI era, the product manager's skill set changes

As software's actual users begin to shift from humans to agents, the entire approach to design is upended:

What product managers design in the future may not begin with an interface, but with capabilities that agents can understand and invoke.

1. Designing features for people: the human-facing PM

In the past, a product manager designing a refund feature might ask:

  • Where should the refund option appear?
  • What should the button say?
  • What page appears after the user clicks it?
  • How many steps should the form take?
  • How do we reduce abandonment?

2. Designing capabilities for agents: the agent-facing PM

In the future, a product manager working on the same feature might need to ask:

  • What exactly does the refund capability mean?
  • Under what conditions may an agent invoke it?
  • Which parameters are required?
  • Above what amount is human approval mandatory?
  • Which prerequisites must be checked before executing a refund?
  • What business status is returned on failure?
  • Are automatic retries allowed?
  • Once the call completes, which downstream processes are triggered automatically—updating accounting records, adjusting inventory, or deducting sales commission?
  • What counts as success?
  • How can another agent determine whether the refund complied with the rules?

Notice that both are product design, but they involve completely different ways of thinking.

The first designs how a person operates an interface.

The second designs how an agent invokes capabilities and follows specifications.

The first centers on making things comfortable for people to use; the second on making execution predictable for agents.

In the past, a product manager at a major internet company who didn't truly understand the business could still deliver a product by being good at competitor analysis, borrowing prototypes, drawing a few polished Figma screens, and reusing existing interaction components. They might even secure a high salary on the strength of their presentations.

But when you build products for agents, you can no longer hide behind prototypes. You have to face the underlying structure of the business directly.

04 The product manager's two users: humans move into a new role

That raises a question: if software is primarily designed for agents, do humans really leave the picture? Where do they fit?

The answer is: humans haven't left, but their role has been fundamentally reshaped.

When building a product in the future, product managers will face two entirely different kinds of users:

1. Agent users: the execution layer

The main workforce handling the tedious, heavy lifting: frequent queries, operations, moving information between systems, and orchestrating execution. They need clear semantics, precisely defined parameters, unambiguous states, and isolated permissions.

2. Human users: the supervision and decision-making layer

Humans move to the top of the system. Their role is to express goals, state preferences, review exceptions, approve high-risk operations, and bear ultimate responsibility.

This leads directly to a disruptive conclusion: the very nature of UX—user experience—is being fundamentally reshaped.

For the past twenty years, UX has studied:

How humans operate software.

In other words, the experience of execution: how to make clicking smooth and filling in forms fast.

In the future, an increasing share of UX research will instead ask:

How humans supervise agents.

That means the experience of supervision and handling exceptions: Intent + Review + Exception UI.

· How do I know what the agent just did?
· When should I intervene?
· Why did it make this judgment? What evidence supports it?
· How do I change its decision?
· How do I approve or undo it with one click?
· When something goes wrong, how can I understand the context in three seconds?

Take a simple example: a hotel check-in management system.

Product managers used to rack their brains optimizing front-desk check-in: saving two keystrokes, reading an ID automatically, or encoding a key card with one click.

In the future, the agents on both sides will have completed verification, payment settlement, and key delivery in the background. All that remains on the front-desk screen is a simple notification: “The guest for room 302 has arrived. Lighting interfered with the facial scan. Please verify their ID manually.”

Most of the operational screens once designed so carefully will no longer be worth designing.

Because no one will be clicking them.

What will be worth a product manager's attention is the exception interface:

When an agent encounters a conflict or reaches the limits of its permissions, how do we present the context clearly enough for a human to understand the cause and make a safe decision in three seconds?

Along with this, the enterprise services ecosystem will be reshuffled.

SaaS once needed enormous teams of implementation consultants and customer success staff because software interfaces were so complex that people had to be on-site, teaching employees which buttons to click. If software learns to operate itself, that human effort can be saved.

Roles such as FDEs—forward-deployed engineers—will finally be able to stop spending their energy configuring front-end pages. Instead, they can focus on getting closer to the business and translating customers' messy, complex real-world rules into specifications and sandboxes in which agents can operate safely.

05 The dividing line between real product managers and those who only look the part

So, back to the provocative argument at the beginning:

For the past twenty years, one of a product manager's most important abilities has been designing how people use software. If software is primarily used by agents in the future, that methodology itself will become outdated.

The harshest part of this statement is that it doesn't explicitly say AI will eliminate the product manager role. So PMs haven't felt the chill.

More precisely, what it eliminates is the group of “product managers in name only.”

In the internet era, the UI was the only entry point. Even without a particularly deep understanding of the business, someone skilled in user research, competitor analysis, writing PRDs, assembling prototypes, analyzing conversion funnels, running A/B tests, and optimizing page conversion could become a highly paid PM with an impressive career.

But once agents take over a large share of GUI interactions, product managers will no longer be able to hide behind the interface.

You'll have to answer the real questions:

What capability does this product actually provide?
Why does that capability exist?
What inputs does it accept, and what results does it produce?
Which rules form boundaries that must never be crossed?
How do we judge whether it has done a good job?

You'll find that this actually takes us back to the most fundamental product questions.

It forces product managers to evolve from page designers working at the surface into capability architects who understand the inner workings of a business.

That's why I say the agent era will make the distinction between real product managers and those who only look the part much clearer.

Many people who have coasted on familiar habits, drawing prototypes and recycling established formulas, will find it painful to watch their skills rapidly lose value in this paradigm shift.

The golden age of earning a high salary by meticulously polishing buttons really is over.

But for people who truly understand the business, can abstract its rules, and grasp systems engineering, an era that frees them to apply their business architecture abilities is only just beginning.