AI Product Operations: A PM's Guide to the New Product-Engineering Partnership

This is an expanded version of a presentation I gave to the LA CTO Forum on 4/10/26. Request a copy of the slide deck and access to the video here.

When AI coding tools arrived, product teams did what came naturally: we used them to write more. Five-page PRDs became twenty pages. Competitive analyses ballooned. Acceptance criteria multiplied until nobody could review them in a single sitting. The documents got bigger and faster, and the collaboration got worse. More documents, longer documents, faster: none of this means better communication.

What's worse, we created a trust problem. Engineers can't tell which decisions were the PM's and which were the model's. A polished and detailed PRD used to be a pretty good sign that a PM had done the hard discovery work and the thinking, but now AI can produce this in minutes. Those old quality signals are dead, and AI helped kill them.

Forward-thinking PMs did something perhaps even more damaging: they discovered tools like Lovable or Replit, built prototypes over a weekend in a random tech stack, and dropped them in Slack asking engineering to ship them. Your engineering team might not tell you this, but they don't know what to do with prototypes in code like these. They're no better than Figma click dummies, and they might be worse. They almost certainly aren't compatible with your product's tech stack, and it could take hours of an engineer's time to get them to run outside of the Lovable container. They have no architectural awareness, no connection to a real data model, and no understanding of how your product's actual codebase works.

That's not a handoff, that's a failure mode. And if you're a PM who's done any version of this, you're not alone. When I first started using AI to gain leverage in product work, I made all these mistakes too.

In most product organizations, a feature moves through a predictable chain. A PM writes a PRD, a designer interprets that PRD into mockups, an engineer interprets those mockups into code, and QA interprets the intent yet again when testing. Every handoff is lossy. Intent degrades each time it passes through another person's understanding.

The bottleneck in that process was never speed. It was the fidelity lost between each interpretation. AI didn't fix this. It made the first step faster while leaving every downstream interpretation intact.

If you're on a team that already runs genuine product trios or embedded cross-functional squads, you've partially closed this gap through organizational design. People sitting together lose less signal than people tossing documents over walls.

The data backs this up. Coding accounts for only 25-35% of idea-to-launch time (Bain & Company), and the same report shows that companies pairing AI with end-to-end process transformation see 25-30% productivity boosts versus 10% from coding tools alone. Teams with high AI adoption merge 98% more PRs but spend 91% longer on code review (Faros AI, 10,000+ developers). The bottleneck doesn't disappear; it migrates. And most product teams still aren't truly outcome-focused (Teresa Torres), which means discovery has the most room for improvement and the least AI investment.

AI made the fast part of the process faster, and the slow parts worse.

A sprint of work can now be built by a coding agent in a day. The marginal cost of building more is approaching zero. When engineering velocity is no longer the constraint, the bottleneck moves to product: to taste and customer understanding, to the rigor of our discovery process.

The danger isn't slow delivery. The danger is building too much of the wrong thing, far too fast.

You could respond by doubling down on engineering practices: review processes, test automation, architecture governance, better tooling. That's necessary but it only addresses the coding slice. The rest (understanding customers, making the right bets, aligning on what to build, validating before committing) remains untouched.

This is where a new practice comes in. AI Product Operations compounds alignment by making the shared context permanent, machine-accessible, and independent of who happens to be in the room.

AI Product Operations is a set of practices that product and engineering adopt together to make the full product cycle work at the speed AI enables. It's a shared operational discipline. It doesn't necessarily mean you need a new vendor or that you need new headcount.

The core idea: instead of treating AI as a tool that makes individual contributors faster, treat it as infrastructure that closes the interpretive gaps between product, design, and engineering. When a PM's AI agent can read the codebase, the PM stops writing abstract requirements that an engineer has to reinterpret. When an engineer's guardrails constrain how a PM prototypes, the engineer stops receiving throwaway code in the wrong tech stack. The handoff layers that used to degrade intent start to disappear.

Some examples of what this could look like:

Intercom has built 13 internal Claude Code plugins with over 100 versioned skills, plus read-only production console access with safety gates. Their most active users aren't engineers, they're design managers and product management leaders who use the system heavily. What Intercom proved is that non-engineers will adopt AI infrastructure when the guardrails make it safe.

Ramp built an internal platform called Glass that reached 99% company-wide AI adoption. They've distributed over 350 shared skills through an internal marketplace. It's Git-backed, versioned, and reviewed like code. When a sales rep figures out a better way to analyze Gong calls and draft battlecards, they package it as a skill and every rep on the team gets it overnight. What Ramp proved is that organizational knowledge compounds when you make contribution easy and discovery automatic.

These companies built internal AI platforms. AI Product Operations takes the same principles -- governed access, versioned skills, shared context repositories, non-engineer adoption -- and applies them specifically to the product-design-engineering collaboration cycle from discovery through delivery. Product Managers are ideally placed to orchestrate this for their organizations: we understand the business, the strategy, and what the priorities are. We know where the most important business context is and we have the cross-functional relationships to marshal it.

1. Who is the customer? A specific segment, not "users" or "the market."

2. What is the problem? Observed behavior, not an assumed need.

3. How do you know they want this? Evidence from interviews, usage data, support tickets, or sales calls. Not opinion or internal consensus.

4. What does the customer experience look like? Walk through it step by step.

No evidence? Go get some. This is a three-minute check, not a process gate.

For AI Product Operations to work, you need a cross-functional team. Start with two core roles, expand to five as the practice matures:

A Product Lead who owns discovery priorities and the customer evidence backlog. An Engineering Lead who defines tech stack guardrails and architects data access patterns. As the practice matures, add a Data Lead who knows where the data lives and can validate quality in AI-generated outputs, and loop in UX Research to make customer research artifacts AI-accessible. Finally, bring in a Program Lead: they know the processes that run your company, and know where automation can provide real operational leverage.

Scale this to your reality. Under 30 engineers, it's one PM and one engineer meeting weekly. Add the Data Lead as soon as you can. Larger teams add the other roles and formalize the rhythm and delivery cadence. At 100+, consider a standing squad with dedicated focus.

Where to start: find the most AI-pilled people already deep in Claude or Codex for their own day-to-day work. They've already figured out agent workflows on their own, and they are the best candidates to be your squad's founders.

For AI Product Operations to work, engineering defines the boundaries. Product and other business teams operate within them. This is the partnership, not a power grab.

Engineering leaders are already articulating this shift: the primary job of an engineering team is less about writing code and more about enabling agents to do useful work. The guardrails they set (tech stack, coding standards, data access patterns, architectural constraints) become the operating instructions that both human engineers and AI agents follow. When something goes wrong, the question shifts from "who is responsible?" to "what was missing from the environment that could have prevented this?"

That reframe gives PMs a clear contract to operate within:

PMs prototype in the same tech stack engineering uses, not whatever Lovable defaulted to. AI coding tools handle whatever stack you throw at them, so there's no excuse for prototyping in a random framework.

Prototypes can also follow your product's design and style guidance: same design systems and component libraries, so they look and feel like the real product.

Data sources are governed, with reusable, versioned skills that encode how to access and interpret each source. Committed to a repo and maintained like any other engineering asset.

Codebase access is sandboxed, read-only, scoped to whatever engineering is comfortable with. The PM's AI agents need to read the code, not write to it.

Not every PM will build prototypes on day one. Some will start with AI-assisted discovery: synthesizing transcripts, analyzing data, building context repositories. The technical curve comes later, and the squad exists precisely to bridge that gap.

For PMs ready to go deeper, you need Git literacy and comfort with tools like Claude Code or Cursor. The learning curve is real, but shorter than you'd expect - and it's accessible to non-technical people. Boris Cherny told us that half of Anthropic's sales team uses Claude Code for their daily work: if the sales team can do it, so can you.

The squad's first practical job: making discovery-relevant data accessible to AI agents.

AI models will produce slop without your data. They don't fail because of a lack of intelligence, they fail because of the lack of good context. The models need your customer patterns, your usage signals, the particular shape of your problem. The same model that produces generic output with no context will produce genuinely useful analysis when it can access your customer calls, support transcripts, CRM data, and product analytics.

You can synthesize a thousand customer support transcripts in an afternoon, cross-referencing CRM data with churn signals to find correlations that would have taken a data science team weeks. The constraint is no longer time or labor, it's whether your data is accessible to AI agents at all.

Start with the highest-value sources: customer call/sales call transcripts (especially in enterprise), meeting transcripts, support data, product and business analytics, CRM data. The squad defines the sources and the governed access patterns: which data sources to use with queries built and vetted, reusable access skills versioned and committed to a source code repo.

For prototypes, you'll want the squad to build some read-only extracts with PII redacted from the core tables that define your product experience. Or, build synthetic data in your product's data models if that's what your environment demands. What's important is that your prototypes use real-ish data that's in your actual data model, not whatever data model an AI hallucinates from a vague prompt.

Get your legal and data governance teams involved from the start. Getting buy-in upfront is far easier than retrofitting compliance.

With data access in place, the next step is curated collections of synthesized, AI-ready organizational knowledge.

Customer insight syntheses alongside competitive intelligence and product decision history: what was tried, what worked, what failed, and the reasoning behind each decision. Plain markdown in a repo, versioned and reviewable.

The process matters more than the specific contents. Build the first version manually and tune the prompts until leadership validates the quality. Only then automate the refresh cycle. A context repository stays current because the automation runs on its own. It's not a wiki that dies the moment the last person forgets to update it.

Ramp's experience validates the compounding effect. Their skill marketplace hit 350+ shared skills because they made contribution easy and discovery automatic, with a built-in recommendation system to surface the right skills by role and current work. One person's breakthrough becomes everyone's baseline. That compounding is what you're building toward with context repositories: organizational knowledge that grows with use rather than decaying from neglect.

Andrej Karpathy declared prompt engineering dead earlier this year and named context engineering as the breakout skill.

What the AI Product Operations team is building is context engineering for the business.

For PMs, this means curating the full information environment your AI tools operate within: objectives, domain knowledge, constraints, accumulated organizational memory. PMs are well-positioned for this work because understanding the business, its customers, and the strategic motivation behind product decisions is already the job.

When your AI agents have read access to the actual codebase, requirements get mapped to what actually exists: the real services and data models, the real constraints.

We should be crystal clear, though, that the goal is NOT to have PRDs prescribe implementation specifics. Engineering still decides the technical approach. Instead, the goal is to create shared and well-informed understanding.

This is where the interpretive gaps in the old process actually close. Instead of writing an abstract document that an engineer has to mentally map to the existing architecture, you're producing requirements that are already grounded in what's built. Everyone sees the same complexity upfront. The conversations shift from "that's not how it works" to "here's how we'd extend what exists to meet the customer need."

I've seen this work in my own practice. When I started giving my AI agents read access to the actual codebase while writing requirements, the quality of the conversation with engineering changed immediately. Scope surprises that used to surface mid-sprint started surfacing during requirements. The PRDs got shorter because the agent could reference existing services directly instead of describing them abstractly.

PMs with codebase access can also self-serve on scope, behavior, and complexity questions that currently require engineering time. Each of those inquiries used to be a Slack message and a context switch for both sides. With codebase access, you investigate directly and arrive at the conversation with answers rather than interrupts.

When you prototype with real customer data drawn from governed replicas, grounded in the codebase, the prototype looks and behaves like the real product. Engineering evaluates working software connected to real data patterns within their own architecture. It's not a mockup in a random framework.

The infrastructure cost is lower than you think. A data replica doesn't mean copying the entire production database. 100 rows of representative data from the core tables covers most scenarios, and PII redaction and access setup is a few days of work. Guardrail instruction files take an afternoon. Codebase access is standard branch permissions.

When prototyping drops to hours instead of sprints, stop building one prototype and arguing about whether it's right. Build a few, each grounded in the same codebase and real data, each taking a different approach. This is the approach Simon Willison and other AI leaders are taking.

The point is testing, not debating. Put prototypes in front of real users and pick the one that fits.

Engineering retains full discretion over what happens next -- whether that means keeping the code or throwing it away. That's engineering's call, and as a PM you can't be attached to that outcome. The value was delivered the moment both sides achieved shared understanding. Even with zero prototype code survival, this handoff beats three weeks of document back-and-forth followed by a build that misses the mark.

Some companies are pushing beyond AI Product Operations into deeper organizational redesign. Jack Dorsey and Roelof Botha recently published their Sequoia piece "From Hierarchy to Intelligence", arguing that hierarchy itself is an information routing protocol that AI can now replace. Block is restructuring around what they call "world models" instead of management layers.

The connection to what I've described is real. Context repositories are a version of what Block calls a company world model. It's organizational knowledge that replaces what managers used to carry up and down the chain. Data legibility creates a customer world model, making behavioral signal accessible at scale.

Most companies are years away from Block's vision. But the companies building AI Product Operations infrastructure now -- the squad, the guardrails, the context repositories, the governed data, the codebase-aware prototyping -- are building the foundation that makes the next transformation possible. The PM's role in that future is one worth building toward: less time routing information between people, more time on the judgment calls, customer intuition, and strategic sensing that no model can replicate.

You don't need a department. You need two or three people who believe in this.

Find the PM and engineering leads who are already using AI seriously for their own work. Give yourselves 90 days and measure what changes:

If those signals are positive at 90 days, expand. If not, adjust and try again.

And if you want to start before the squad is formed: begin with discovery. Use AI to synthesize the customer evidence your team already has. Build a context repository from your existing research. Bring sharper, evidence-backed problem definitions to your next planning cycle. That's something any PM can do today, and it demonstrates the value that makes engineering want to open the door.

The teams moving fastest aren't just writing better code or better documents. They're designing the operating model together: product and engineering building shared infrastructure that makes the whole system faster and more effective than the sum of its parts.

The infrastructure is buildable today. The question is whether you'll build it before the gap between what AI can produce and what your customers actually need becomes the thing that defines your product.

I coach Product Leaders to thrive in the age of AI. If you’re interested in leveling up, find me here: https://pmcoaching.net