The AI Product Operating Model
How AI Native companies think and how to use those principles to scale faster
Marty Cagan made the product operating model famous.
But if you look at how the top AI companies are operating, it is quite different:
Anthropic engineers prototype hundreds of solutions and ship without ever consulting a product manager or designer.
OpenAI’s new hot product Codex started with just two PMs, one designer, and about 40 engineers, collectively responsible for 10 to 12 distinct product surfaces. At any traditional company, each of those surfaces would get its own squad of 15 to 20 people.
Cursor operates with 40 engineers, one PM, and scaled past 4 billion dollars in ARR faster than almost any company in history.
This new way of working is not the product operating model of old gen.
This new way is the “AI product operating model,” and over the coming decade, most companies will move to it.
Over the past three years, I have been working to define the AI product operating model. After 150+ podcasts - and countless deep dives on the topic - today, I’m ready to present everything.
And I didn’t do all the work myself.
Introducing Rohan Varma of OpenAI
I’ve partnered with someone at the epicenter of this revolution - Rohan Varma. He’s a Product Manager on Codex at OpenAI. Earlier, he was the first PM at Cursor. He also runs the top-ranked AI PM Certificate on Maven at Product Faculty:
I took it all the way back in 2024 and learned a ton. It’s great if you’re starting your AI PM journey. Use my discount code AAKASH550C7 to get $550 off:
Why This Matters
Recall what Sam Altman said in 2024:
We’ll see the first one-person billion-dollar company within our lifetimes, possibly very soon, powered entirely by AI agents doing what used to require hundreds of people.
It’s REALLY happening…
Matthew Gallagher built Medvi, and in 2025, he did $400M+ on his own. He has now hired his brother, and in 2026, they’re projected to do $1.8 billion.
Not to mention the crazy rise of OpenClaw: Peter Steinberger single-handedly built one of the most useful AI personal assistants and scaled it so massively that it became a household name worldwide is insane. Again, just one person with a bunch of agents.
If you showed these numbers to a VP of Engineering at any large enterprise, they’d tell you these companies are running on borrowed time. That you can’t sustain quality and growth at this scale without proper resourcing. And for most of the last 30 years of software history, they would have been completely right.
But something has changed massively in the past 3 years, and most organizations have still to come to terms with it.
Codex ran a hackathon with a large enterprise recently: the kind of company with thousands of developers and a mature engineering culture. They scoped a modernization project at 10 engineers, 12 months.
Two engineers with Codex completed it in JUST THREE DAYS.
So the question worth sitting with is:
Why is this possible now when it wasn’t possible before?
Today’s Post
We have curated the full structural logic of how AI-native companies are organized: the people model, the process model, the tool model, the economic model, and what it looks like to start rebuilding in that direction from wherever you are today.
The Belief That’s Holding Companies Back
Inversion of Product Development
What EPD Looks Like Now
The AI-Native Workflow
The Real Problems You’ll Encounter
How to Start - The AI Leverage Playbook
Plus 4 downloadable resources, including: an AI Native Team Diagnostic Worksheet, an AI workflow decomposition skill, and more.
1. The Belief That’s Holding Companies Back
Every decision your product organization has ever made traces back to a single belief:
Writing code is hard, and engineers are your scarcest resource.
Pull on that thread and watch how much unravels.
The org chart you’re running right now is an accumulation of the fossil record of every time your company ran into this belief - across people, process, and tools:
Let’s start with people.
The whole org is oriented around engineers. They’re expensive, so you can’t afford to waste a sprint building the wrong thing. So you hire layers to coordinate them: EMs, TPMs, scrum masters. You hire a PM to prioritize ruthlessly.
You hire specialists at every layer (QA, security, platform, data) because the work becomes too complex for generalists. Then you hire people to manage the specialists
Almost 30 to 50 percent of the total effort in any traditional team right now is pure coordination overhead.
Then move into the process.
Sprint planning exists to make sure engineers build the right thing before they start, because changing course is expensive. Backlog grooming exists for the same reason.
Code review exists because every human-written line needs another human to verify it before it touches production. QA, staging, feature flags, phased rollout, on-call incident response: every checkpoint exists to protect expensive engineering time from waste.
Finally, let’s talk tools.
The IDE is a precision instrument for one engineer writing code character by character. Jira exists to coordinate humans across a slow-moving pipeline where work takes weeks.
Daily standups exist because when work moves slowly, and dependencies are everywhere, people need regular synchronisation just to stay unblocked.
That belief is no longer a fact: building code is no longer expensive.
The question that should be sitting uncomfortably in the back of your mind right now: if you were starting your product organization from scratch today, with the tools available today, would any of this exist in its current form? Would you run two-week sprints? Write 30-page PRDs before a line of code is written? Hire dedicated QA? Staff each product surface with a squad of 15?
AI-native companies built in this era might be our best guide for what the answer looks like. And the answer, almost universally, is no.
That gap is precisely the opportunity and the threat hiding inside every product organization in the world right now.
🔨 How do you know whether your team is actually AI-native? We created a markdown diagnostic worksheet that you can complete yourself or work through with Claude/Codex. It will help you identify your team’s biggest bottleneck, assess your AI-native readiness, and map the operating model you’re running today versus the one you’ll likely need tomorrow.
2. Inversion of Product Development
When coding agents started appearing a few years ago, most engineering leaders filed them under ‘productivity tools’: the same mental category as a better IDE, a smarter autocomplete, a faster CI pipeline.
But the tools didn’t stay there. In just two years, they evolved through three distinct phases: autocomplete assistants like GitHub Copilot and Cursor Tab, to task-level CLI agents like Claude Code, to fully agentic systems like Codex that take complex work, iterate, and ship results on their own.
Just to put things in perspective: A task that takes an engineer ten hours now takes ten minutes with Codex or Claude Code.
In a traditional product process, you build late. The build is expensive, so you front-load everything else: research, discovery, spec writing, design reviews, technical scoping, stakeholder alignment.
But when building becomes cheap enough that you can build first and evaluate second, this logic collapses. At Codex and Cursor, entire phases of the traditional SDLC have collapsed or disappeared:
Code review as a separate stage? When agents verify their own work at the point of generation and humans review outcomes rather than line-by-line diffs, the traditional review process is redundant.
Elaborate sprint planning? When building the wrong thing costs thirty minutes of agent time instead of two weeks of engineering time, you can afford to build first and evaluate second. Which is exactly what Codex does.
The build/decide sequence? Completely inverted. The question is no longer “should we build this?” asked about a spec. It’s “ I had this idea based on XYZ. We built this - should we ship it?” asked in front of a working product that an agent put together overnight.
This one inversion changes the entire epistemology of how product decisions get made, because you’re no longer deciding based on reasoning about what something might be, you’re deciding based on direct experience of what it actually is.
🔒 That was the structural logic behind why AI-native companies are winning. Below:
The exact way the PM, engineer, and designer roles are being rebuilt from scratch
The complete AI-native workflow that replaces sprints and PRDs
The full AI Leverage Playbook for wherever you are today (startup to enterprise)
+ 4 downloadable resources.
Keep reading with a 7-day free trial
Subscribe to Product Growth to keep reading this post and get 7 days of free access to the full post archives.
 | A guest post by
|