The AI-Native Operating Model

Most organizations are adopting AI the way they adopted mobile, as a feature added to an operating model that otherwise stays exactly as it was. Mobile did eventually reshape the companies that treated it that way; it took them about a decade, and the decade was the cost. The opportunity with AI is structural, and most transformation programs are missing it in the same way. If agents can absorb coordination, first drafts, and eventually whole workflows, the right organization is shaped differently from the one most of us inherited: fewer people whose job is coordination, more whose job is direction and judgment, and a platform that treats agents as first-class customers rather than an audience to be served later.

Three layers, in order

I run this as three layers, and the order is the argument. The first is individual fluency: every product manager builds with AI by hand rather than reading about it. The second is the organization's own tooling, where the product workflow itself (roadmaps, tickets, customer feedback, metrics) runs on agent surfaces. The third is the product platform, models included, where self-service and agent access are the product rather than a channel bolted on afterward. A team that has not built with agents cannot design tooling for them, and a team whose own workflow does not run on agents cannot credibly sell an agent-first platform to anyone else. Most enterprise AI programs begin at layer three, which is why so many of them are brochures.

What convinced me

Fluency is built by building, and the illustration I keep returning to is a skeptic. We ran a small competition in which every team, and every product manager on it, had to ship a working application of their own, with no mandate and no lecture series attached. The most experienced skeptic on my team, a person with a well-earned suspicion of anything described as transformational, built a partner-facing portal from a conversational prototype. A version of it went to production and is now quietly reducing the back-and-forth of onboarding new bank partners. One person is not a proof, but it is the mechanism in miniature. Nothing I could have said would have moved him; the evidence had to be his own hands.

Giving the organization an agent surface is what makes the change of shape real. We built agent interfaces over the systems product managers live in, so that a roadmap update, a ticket, a synthesis of customer feedback, or a metrics pull is a request rather than an afternoon. A great deal of what is called product management is coordination, and coordination is what agents are good at. The result on my team has not been fewer people. It has been more scope: the same organization now runs three platforms, for outside data, for document intelligence, and for workflow automation, where it ran one. I hold my own teams to a bar that scope should roughly double every three years on flat headcount, and I would look hard at any AI tooling that could not get a team there.

Self-service is the product. When we made the platform self-serve, with an agent that could work across hundreds of repositories and services, a partner integration that had required a sequence of meetings became something a team could do largely on its own. Onboarding time roughly halved, the tools a partner had to touch collapsed to one, and adoption ran well past the target we had set, all through voluntary use.

A distinction matters here. A meeting whose purpose is coordination is a defect, and the honest metric of a platform is how many of them remain. A human whose purpose is judgment, in any flow where a wrong answer is expensive, is a design decision. The models beneath the platform follow the same rule: we moved to small, specialized language models before they were fashionable, set thresholds by evaluation rather than faith, and automated exactly where the expected cost of error fell below the friction removed.

Where the humans stay

Through all of this, what my team owned was direction and the quality bar. On the verification work, the team led delivery end to end while I owned what we were building toward and what good looked like, and that division is the template. As agents take on more of the execution, direction and the bar are the parts that stay human longest; a leader who cannot articulate either will find that the agents execute beautifully toward nothing in particular. The product manager's role bifurcates accordingly, into fewer people, all of them owning direction and a bar, and no one whose job is to carry information between rooms.

The model has failure modes I take seriously. AI-native must not become AI-everywhere, and the threshold rule exists to draw that line without sentiment. Tooling sprawl is the second trap; sixteen half-built internal agents are worse than three that work. And the sequence holds at the other end too: tooling first, then shape the organization to what the tooling has proven, never the reverse, because cutting headcount ahead of capability is a bet placed with other people's careers.

The open question

What does the product manager's role look like at the end of this curve? My answer today is direction and the bar. But evaluations for multi-step agent behavior barely exist, and whoever works out how to hold a quality bar over a trajectory rather than a single output will be defining the next version of this job. I would like my organization to be where that gets worked out.