AI product operating model: from managing work to managing context

Why the teams building coding agents changed more than their coding speed

“Which coding agent should we buy?” is no longer the question I hear from CPOs. The question is “how should my product team work now that engineering ships in days?”. The most experienced answer comes from the teams that build the agents. Ant Murphy went through more than thirty interviews with the people behind Claude Code, Codex and Cursor and found seven recurring patterns. Read together, they describe an AI product operating model that differs from the one most teams run today.¹

The patterns are easy to list and easy to misread. Everyone manages agents. The unit of work grows. Development becomes bottom-up. Dogfooding feeds discovery. Prototypes replace meetings. Agents need an environment, not a prompt. Roles blur. Taken one by one, they read like a productivity story. Taken together, they point at something else: the work these teams stopped doing, and the work they started doing instead.

I am a co-founder of Teklens. Before that I built Aioma and sold Localina's CRM to Swisscom, and I have taught at ZHAW. At Teklens we have had 24 discovery conversations with product people about how their teams work with AI, and the CPO question above is the one that recurs. This article walks the seven patterns with the original interviews behind Murphy's reading, then argues that they add up to one shift: from managing work to managing context. You will take away what each pattern requires before it works, a checklist for whether an agent could pick up your next feature, and the reasons a bank or an industrial company should adapt these principles rather than copy the processes.

The thesis in one sentence: execution has become cheap, so everything around execution has become the job, and the scarce resource in a product team is no longer coding capacity but shared context and judgement. Coding got fast. Coordination didn't.

Why is everyone becoming a manager of AI?

Because the operative question changed from “how do I do this?” to “how do I get an agent to do this?”. Product people at the frontier companies delegate operational work: analysing metrics, checking hypotheses, updating Jira, organising documentation, preparing decisions. The human role moves up a level: define the goal, provide the context, set the constraints, judge the result.¹

Alexander Embiricos, who leads product for Codex at OpenAI, draws the line between pairing and delegation. Pairing means the agent types while you watch. Delegation means it builds while you are in a meeting or asleep, in its own environment, and you come back to review the result. His point for product people: delegation is a skill, and the skill is writing a brief with enough context to act on without constraining the approach.⁵

Cat Wu, Head of Product for Claude Code at Anthropic, describes the same move from the other side. When a product manager can go from idea to working prototype in an afternoon, the gap between “what if we tried” and “here, try this” almost disappears. The new reflex is demo first, document after.³

Notice what both descriptions have in common. Managing an agent looks like managing a person in exactly one respect: the brief is the work. And a good brief needs the context you do not have in your head at nine in the morning: what was decided last sprint, which option was rejected and why, which part of the code the change touches.

Why is the unit of work getting bigger?

Because splitting every feature into dozens of small user stories made sense when coding took weeks. When it takes hours, the split costs more than it saves. Teams at the frontier hand an agent a whole feature, a problem or a desired outcome. That is not a return to waterfall. The unit of execution has grown, and the bottleneck moved to deciding what to build, coordinating the context and verifying whether the result is good.¹

The Codex team at OpenAI is the extreme case. “We write very few specs on the Codex team. We're talking 10 bullet points and that's it,” Embiricos told Peter Yang in April 2026. The team plans short term and long term and, in his words, never medium term.⁴

Ten bullets work at OpenAI for a reason that does not travel. The other 990 bullets live in the shared context: a codebase the agent can read, evaluation suites that define done, conventions every engineer follows, and colleagues who wrote the previous version and sit within earshot. Hand ten bullets to an agent in a company where the decisions live in meeting minutes and the acceptance criteria in someone's head, and you get ten bullets' worth of software. I described what a ticket needs to carry instead in the anatomy of a Jira ticket for AI product management.

Why does product development become bottom-up, and what keeps it from turning into chaos?

Because nobody at the frontier can predict the roadmap. Teams at Anthropic, OpenAI and Cursor give individuals unusual autonomy: designers, product managers and engineers take an idea from concept to prototype, sometimes to a production candidate, within days. It works for them because they operate in unexplored territory. Nobody knows what the next model will be capable of or what users will value, so exploring many directions quickly beats planning one perfect path.¹

Wu's version on Lenny's Podcast: “We want to make sure every single person on the team feels empowered to take their idea from just an idea to out in the world in less than a week, sometimes even in a day.” Claude Code's desktop app came out of what she calls a side quest, a half-day experiment on something that had just become feasible, not out of a plan.^2,3

The caveat is the part that gets lost in retelling. This is not chaos. Behind the speed sit code reviews, automated tests, evaluations, staged releases and safeguards. “Everyone can ship” only works when the infrastructure around shipping is very strong. DORA's 2025 study of nearly 5,000 professionals puts the general version plainly: AI raises throughput, and without strong automated testing, mature version control and fast feedback loops the added change volume turns into instability.^1,10

What does dogfooding do to discovery?

It compresses the feedback loop from weeks to minutes. The teams behind Claude Code, Codex and Cursor use their own products all day. They meet bugs, limits and opportunities before a customer reports them. Anthropic calls its version antfooding; Wu says the team's channel receives feedback every few minutes.^1,2

Cursor grew the same way: intense internal use and a deliberate focus on power users rather than on a broad “everyone can code” story, as Michael Truell described on the same podcast.⁸

Dogfooding has one dangerous weakness, and Murphy names it: you are not necessarily your customer. Internal usage complements customer discovery. It does not replace it. Customer understanding, strategy, research and data still matter, and the fundamentals did not change.¹

For most DACH companies the weakness is the whole story. A product team at an insurer does not use its own claims software all day. An industrial company's engineers do not run the customer's plant. Dogfooding gives you the developer-tool feedback loop only if you build developer tools. Everyone else has to build the loop with customers, which is slower and cannot be skipped.

Why do prototypes replace some meetings?

Because when building is cheap, debating a hypothetical solution becomes relatively expensive. Instead of an hour around a whiteboard, a team builds two versions and compares them. AI lowers the cost of alternatives so far that teams test ten concepts where they used to test two. Product discussion moves from opinions to artefacts: show the idea, test it, compare.¹

Ian Silber, Head of Product Design at OpenAI, describes the process on the surfaces that matter: “we try 100 things, we throw out 99, we finally ship one”, often changing daily, with A/B tests and user research before anything hardens.⁷

The meeting does not disappear. It moves later and gets a different input: an artefact and a test result instead of a slide and an opinion. That is a better meeting. It is also a meeting that produces a decision which, in most companies, is written nowhere an agent could read it the next morning. Keep that in mind for the sixth pattern.

What does an agent need beyond a prompt?

Five things, and the interviews agree on them even where they disagree on the format. A long-running agent needs enough context to make decisions, a clear desired outcome, explicit verification criteria, access to the tools and systems involved, and a loop in which it can build, test, inspect, fix and repeat. Whether that arrives as a detailed PRD, a lightweight plan or a single goal is still argued about. The requirements underneath are the same.¹

The innovation is therefore not prompt engineering. It is building an environment in which an agent can keep working towards a verifiable outcome. Nufar Gaspar calls this loop engineering: a goal, judging and stopping criteria the agent can measure, a cycle cap and a sandbox. I covered the method in agentic loops: from prompting to a multiplayer team of agents; this article stays on what it asks of the product team.⁹

Look at the five requirements again. Four of them are context, not instruction: what the agent knows, what done looks like, how the result is checked, what it can reach. DORA lists “connect AI to your internal context” among the capabilities that separate teams that gain from AI from teams that only speed up. A product organisation that cannot answer the four for a feature cannot delegate that feature, however good the model. Stripe's engineering team built exactly that for the whole company; the enterprise AI playbook behind it is its own article.¹⁰

Are product roles disappearing?

No. They blur. AI makes it easier for product managers to prototype, for designers to build and for engineers to take part in discovery, and the strongest AI companies still hire product managers, designers and engineers. What changes is the boundary between the roles, and which part of each role is worth paying for.¹

The commodity part of each profession is the part that automates. A product manager whose value is mainly writing Jira tickets is exposed. A designer whose value is mainly moving pixels is exposed. An engineer whose value is mainly translating a specification into syntax is exposed. On the Codex team, designers now write more code than engineers did six months earlier, and Silber expects start-ups with two designers and one engineer: the engineer to keep the system sound, the designers to work out what to build.^1,4,7

The deep part of each profession is what remains. Great product managers bring judgement, commercial thinking and a nose for the problems where a small decision changes a lot. Great designers bring customer empathy, creativity and interaction expertise. Great engineers bring architecture, technical judgement and creative problem solving. AI expands what each person can execute. It does not remove the need for the expertise, which is also why a CPO who regrets product management still hires product managers.¹

Why does the real shift run from managing work to managing context?

Because software teams built their whole apparatus around managing tasks: tickets, stories, handovers, specifications, status updates. AI makes execution cheaper. That raises the value of everything around execution: what are we trying to achieve, why, what does the agent need to know, what has already been decided, how do we know the result is correct. The scarce resource is no longer coding capacity. It is shared context and judgement.¹

Managing context means keeping the goal, the decisions already made, the constraints and the verification criteria of an initiative written down, current and readable by every person and every agent working on it. Managing work means tracking who does which task by when. The first makes the second largely unnecessary; the second never produces the first.

The starting point is not flattering. In Pragmatic Institute's 2019 survey of about 2,500 product people, 73 percent of working time went to tactical work, coordination, administration and support, and 27 percent to strategy. That was before coding agents. Agents do not reduce the 73 percent by themselves. They make every missing decision visible faster, because an agent that lacks context either asks or guesses.¹²

Fiona Fung, who runs the Claude Code and Cowork teams at Anthropic, reported in June 2026 that her teams ship about eight times more code than before. She also reported the hidden cost: with everyone working next to their own agent, engineering stopped being a shared activity, and the team had to rebuild its connection on purpose, with pairing lunches and hackathons. If shared context does not arrive by itself at Anthropic, it will not arrive by itself anywhere. It has to be managed.⁶

Marty Cagan defines the product operating model along three questions: how you build, how you solve problems and how you decide which problems to solve. The AI version changes the first question most, because agents now do much of the building. That puts pressure on the other two, and managing context is the practice that keeps all three connected: the decision reaches the spec, the spec reaches the agent, the result gets checked against the decision.¹³

Why you should not copy Anthropic or OpenAI

Because the frontier companies operate under conditions your company does not have: exceptional technical talent, a technology that changes monthly, high uncertainty about what users want, and internal infrastructure that catches mistakes before they cost anything. A bank, an industrial company or an established SaaS business works under different constraints. Copying “everyone ships every week” without the skills, safeguards and context behind it produces more chaos, not more speed.¹

DORA's one-line summary of its 2025 data is the warning: “AI doesn't fix a team; it amplifies what's already there.” METR's controlled study of experienced open-source developers adds the uncomfortable detail: with AI tools they were 19 percent slower on their own repositories while believing they were faster. Small sample, specific setting, but the finding about self-perception is the reliable part.^10,11

The lesson is not to copy the processes. It is to understand why they work and to adapt the principles. I made the same argument about why the Spotify model fails, and fails harder with AI agents: a practice transplanted without the conditions that made it work becomes a ritual.

Which returns the article to the CPO's question. “How should my product team work now?” does not have a process as its answer. It has four principles that the frontier teams share and that survive the transplant: humans define intent. Agents execute more of the work. Shared context keeps both aligned. Verification closes the loop. Murphy calls this the emerging product operating system. It is a bigger change than adding one more AI tool to the product stack, and it is the change the seven patterns were describing all along.¹

Where Teklens sits in this picture

This is the one place Teklens belongs in this article. Every pattern above needs a place where goal, decisions, constraints and verification criteria live, readable for people and agents, and current when a decision changes. Teklens is built as that place: the shared Product Brain for your software team, a shared memory for people and agents. It keeps product decisions, customer feedback, Jira and code connected and current, so product, engineering and AI agents work from the same knowledge. You decide. Teklens keeps the knowledge together.

The working practice around it is what we call an AI Product Playbook: Activities, each a concrete work step from start to approval, with a purpose, the knowledge they need, a named human owner, assigned agents, a defined result and a human approval, along the flow from decision to spec to plan to build to review to shipped software. Humans steer and approve. Agents do the work. In the vocabulary of this article: managing context as a daily practice instead of a document nobody updates. The measure we care about is less coordination work for the team, not the number of agents in use.

We publish names and numbers only with permission, so there is no metric here; the first teams are working productively with Teklens. If you want to see one real Activity run from start to human approval on your own Jira and repository, book a demo: thirty minutes with a founder and an honest answer whether it fits your setup. One call, and Jira and your repo are connected in under an hour.

Frequently asked questions

Recommendations

• Write the decision, not only the ticket. Every product decision that changes what gets built goes into a place people and agents can read: the goal, the option chosen, the options rejected and why. Start with the decisions from this week's meetings.
• Widen the unit of work only where verification exists. Hand an agent a whole feature when you can write down how the result gets checked. Where you cannot, keep the unit small and design the check first.
• Replace one debate a week with two prototypes. Pick the next discussion that would take an hour, build two versions, put them in front of three users, and decide on the artefact.
• Keep dogfooding and customer discovery separate. Log what internal use taught you and what customers taught you in different columns. If the second column stays empty, your discovery has stopped.
• Build the safety net before the autonomy. Tests, review, staged releases and a named approver come before “everyone can ship”. Autonomy on top of a weak net is the chaos Murphy warns about.
• Grade roles by judgement, not artefact output. In hiring and reviews, ask what the person decided and what it changed, not how many tickets, screens or pull requests they produced.

Scope & caveats

• Ant Murphy's seven patterns are his reading of more than thirty public interviews with people at three companies, published in September 2026 as part one of a series. It is a synthesis of vendor statements, not a study, and the companies describe their own practice.
• Cat Wu, Alexander Embiricos, Romain Huet, Fiona Fung, Ian Silber and Michael Truell speak about their own teams and products. Numbers such as “eight times more code” or feedback “every few minutes” are their statements, not independently measured.
• DORA 2025 surveyed nearly 5,000 technology professionals and adds qualitative interviews; it reports associations, not causal effects. METR's study is a randomised trial with a small sample in a specific setting; the finding about self-perception is the most reliable part.
• Pragmatic Institute's 27/73 split comes from its 2019 annual survey of about 2,500 product people, self-reported and before coding agents. It shows the baseline, not the current state.
• The 24 discovery conversations are Teklens' own, with product people, and they are conversations, not a study. The Teklens statements describe product capabilities, not measured customer results.

Sources

Every external figure and quote in this piece – linked so you can verify it.

1. 1.Ant Murphy, «How The Leading AI Companies Do Product (Part 1)», Newsletter auf antmurphy.me, September 2026 ↗ – The seven patterns and the closing arguments; this article follows his order and adds the primary interviews.
2. 2.Cat Wu mit Lenny Rachitsky, «How Anthropic's product team moves faster than anyone else», Lenny's Podcast, April 2026 ↗ – The “less than a week” quote, antfooding, prototypes instead of documents, designers checking in code.
3. 3.Cat Wu, «Product management on the AI exponential», Anthropic, März 2026 ↗ – Demo first, document after; side quests; idea to prototype in an afternoon.
4. 4.Alexander Embiricos und Romain Huet mit Peter Yang, «How OpenAI's Codex Team Builds with Codex», Creator Economy, 5. April 2026 ↗ – Ten-bullet specs, planning horizons, designers writing code.
5. 5.Alexander Embiricos mit Lenny Rachitsky, «Why humans are AI's biggest bottleneck (and what's coming in 2026)», Lenny's Podcast, 14. Dezember 2025 ↗ – Pairing versus delegation; delegation as a skill; review as the new job.
6. 6.Fiona Fung mit Lenny Rachitsky, «What happens after coding is solved?», Lenny's Podcast, 21. Juni 2026 ↗ – Eight times more code; engineering no longer a shared activity; pairing lunches and hackathons.
7. 7.Ian Silber mit Lenny Rachitsky, «OpenAI's Head of Design: This is the best time in history to be a designer», Lenny's Podcast, August 2026 ↗ – “100 things, throw out 99, ship one”; two designers and one engineer.
8. 8.Michael Truell mit Lenny Rachitsky, «The rise of Cursor», Lenny's Podcast, 2025 ↗ – Internal use and the focus on power users.
9. 9.Nufar Gaspar und Nathaniel Whittemore, «Agentic Loops for Knowledge Workers», The AI Daily Brief, 3. September 2026 ↗ – Loop engineering: goal card, verification criteria, cycle cap.
10. 10.DORA, «State of AI-assisted Software Development 2025», Google Cloud, 23. September 2025 ↗ – Nearly 5,000 professionals; AI as amplifier; throughput versus instability; “connect AI to your internal context”.
11. 11.METR, «Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity», 10. Juli 2025 ↗ – Randomised trial: 19 percent slower while feeling faster; small sample.
12. 12.Pragmatic Institute, «2019 Annual Product Management & Product Marketing Survey», 2019 ↗ – About 2,500 respondents; 27 percent strategy, 73 percent tactical work, coordination, administration and support.
13. 13.Marty Cagan, «The Product Operating Model: An Introduction», Silicon Valley Product Group ↗ – How you build, how you solve problems, how you decide which problems to solve; the frame behind “Transformed” (2024).

Keep reading in the PM Lab

Related deep dives – from the same pillar and the adjacent phases.

Matching use cases from the library

From the article straight into practice: these use cases put the concepts to work with Teklens.