Can a 3-person pod enabled with AI perform the work of a former Scrum team? A company is experimenting with a new product model to test this hypothesis.
What is the role of the Product Owner in an AI-enabled product team? Do we still need to write user stories in an environment that can quickly build and test AI-generated solutions?
The VP of Product at a global leader in supply chain risk management is trying to answer these questions through a transformation pilot that started a couple of week ago with four pilot “pods”. She is running a radical experiment in how software gets built by dismantling the traditional scrum team, eliminating the Product Owner role, and replacing a significant portion of the development process with AI.
What makes this particularly meaningful to me is that I had the opportunity to work with this product team earlier this year, delivering my AI for Product Managers training. What I am hearing from the VP is, in part, a direct consequence of that work. The PMs who are now navigating this new operating model are the same ones who learned how to leverage AI in product management work.
The PM’s AI Problem
Before getting into the experiment itself, it is worth naming the problem that preceded it. When I first engaged with her team, the questions about AI sounded familiar: Product Managers did not know how to use AI in their day-to-day work, structurally, as a team; they did not know how to run Discovery with AI; they did not know how to build a consistent team playbook so that everyone was working in the same direction rather than each person experimenting in isolation. And underneath all of that was a deeper fear: not that AI would make their jobs harder, but that it would make them unnecessary.
That fear is understandable, but it is also, I would argue, based on a misreading of what AI actually does to the PM role. AI does not replace the judgment of a good product manager. It accelerates execution. And if your execution is now faster, the quality of your upstream decisions matters more, not less. The PMs who thrive in this environment will be the ones who invest in getting better at Discovery, prioritization, and problem framing. The ones who treat AI as a shortcut to shipping more stuff without improving how they think will be the ones who struggle.
The training I delivered focused on exactly this: how to use AI as a thinking partner in Discovery, how to structure prompts that generate useful insight rather than generic output, and how to establish a shared team playbook so that AI becomes a consistent capability across the team rather than a personal experiment for whoever happens to be curious. She mentioned that one of her product managers is now using my prompts to guide her Discovery process, and has already adapted them to fit her context. That is exactly what good adoption looks like.
From Big Teams to Small Pods
Against that backdrop, the experiment makes a lot of sense. Each pilot pod consists of just three people: one product manager, one UX designer, and one engineer. A more experienced “AI Coach” joins in a coaching capacity, observing the process and advising on tooling, but is not an active problem solver on the team. QA is shared across pods rather than embedded.
For years, the default unit of product development has been the scrum team: four to six engineers, one or two QA specialists, a Product Owner, a tech lead, and a UX designer. Planning cycles were quarterly. Handoffs were constant. The overhead was enormous.
Each pod works on one problem at a time, moving through four defined zones rather than juggling multiple workstreams simultaneously. The goal now is radical focus: “You ignore everything else, you just focus on one thing at a time.“
The Four Zones
But changing just the structure of the team without changing the process is not enough. So, they are experimenting with a new product operating model that is built around four sequential zones, each with a specific output that feeds the next.
The four-zone framework is a new operating model designed for radical focus and speed, aiming to reduce product development cycle times from weeks or months down to days. In this model, small “pods” (consisting of one product manager, one UX designer, and one engineer) move through four sequential stages, focusing on one problem at a time.
The four zones are defined as follows:
Zone 1: Discovery and validation. The product manager identifies and validates the problem to be solved. This stage is considered the most critical foundation of the model; if the discovery is flawed, the AI will simply “solve” the wrong problem faster. The primary output of this zone is a product spec.
Zone 2: Technical design. This is where the Product Owner role used to live. Previously, a Product Owner would translate the product spec into user stories and technical requirements for the engineers. That role is now being replaced by AI. The product spec is loaded into an AI tool, which interrogates it against the existing architecture of the product to generate a technical design. The PM and engineer review and refine this together in an iterative loop. The output is a technical spec. The shift is significant: what once required a dedicated role and weeks of work is now a human-reviewed AI output.
Zone 3: AI coding. The technical spec is handed to AI, which does the actual coding. During this phase, the human team observes the process, checks for AI hallucinations, and provides necessary course corrections.
Zone 4: Testing and deployment. The team tests what AI built, makes final adjustments, and deploys to production. A separate QA team, at the moment, provides testing & quality oversight to the pods, before approving the release.
Key Principles of the Framework
Human-in-the-Loop: While AI accelerates execution, human review is mandatory at every stage to ensure quality and oversight.
Elimination of the Product Owner: The traditional tasks of translating specs into user stories and requirements are now handled by AI in Zone 2.
Focus on Inputs: Because AI removes the natural “friction” of high engineering costs, the framework relies heavily on strong product management in Zone 1 to avoid the “feature factory” trap of building low-value features quickly.
The Hidden Assumption: Product Management Still Has to Do Its Job
There is a critical assumption embedded in this entire model that deserves to be named explicitly. The four zones only work if what goes into Zone 1 is worth building in the first place. Faster execution does not fix a broken input. If a pod is fed the wrong problem, it will simply solve it faster.
This is the feature factory risk, and it is more dangerous in an AI-accelerated model than it ever was before.
In a traditional scrum setup, the high cost of engineering acted as a natural filter. If you wanted developer time, you had to justify it. That friction, frustrating as it was, forced prioritization. It made PMs think twice before adding something to the backlog.
AI removes that friction almost entirely. When cycle time drops from months to days, the temptation to feed more into the system is enormous. Why not build that nice-to-have? It only takes a few days now. And that is precisely where the trap closes. More output does not mean more value. A pod that ships ten features in a month has not necessarily moved the needle for the user at all, if those ten features were not solving the right problems.
The role of the product manager as the person who decides what to build, not just how to build it faster, becomes more important in this model, not less. Zone 1 is deliberately designed to be the discovery and validation gate before anything enters the AI-powered pipeline. But as she acknowledged, the current pilots are focused on zones two through four. Zone 1 is still being figured out.
That is the part I would watch most closely. Strong product management practice, grounded in real user insight and disciplined prioritization, is the foundation this entire model rests on. Without it, AI does not solve the feature factory problem. It amplifies it.
In a previous article, I discussed how Product Journey Maps can help avoid the feature factory trap.
Competing Tools, One Hypothesis
The four pilot pods are not all using the same AI tooling, which is itself part of the experiment. One engineer built his own Claude Code setup. Another pod is using AWS Q Developer. A third is working with a custom internal tool the team named “Anti-Factory,” a series of AI agents they built themselves.
The hypothesis is the same across all four: load in the product spec, let AI generate the technical design, then use that design to drive AI-assisted coding.
The baseline they are measuring against is the traditional cycle time for moving through these same stages, historically measured in weeks to months. The target is days.
The Open Questions
Quality is the obvious concern alongside velocity. But the more nuanced challenge she raised is governance: how do you prevent small, fast-moving pods from making decisions in isolation that break something elsewhere in the product? Her instinct is a layer of AI governance agents, each focused on a specific domain, covering design standards and architectural guidelines, that every output must pass through before moving forward. “A checks and balances layer,” as she described it.
There is also the QA bottleneck. When you accelerate the upstream process dramatically, testing can quickly become the new constraint. The product team acknowledged this directly: shared QA is part of the current structure, but it is something the team will need to watch closely as velocity increases.
Human-in-the-loop remains non-negotiable for now. Every AI output at every stage requires a human review before the team advances. The ambition is speed, but not at the cost of quality or oversight.
Key Takeaways
Here are the key takeaways from this company’s AI operating model experiment:
The fear that AI replaces product managers is a misreading of what AI actually does. It accelerates execution. That makes upstream PM judgment more important, not less.
Before teams can run this kind of experiment, PMs need a foundation: how to use AI in Discovery, how to prompt effectively, and how to build a shared team playbook so AI becomes a consistent capability across the team.
Large scrum teams are being replaced by small pods of three people (PM, UX, engineer), with an AI-expert coach observing rather than building.
The technical Product Owner role is being eliminated and replaced by AI in Zone 2, which transforms a product spec into a technical spec.
A four-zone framework governs the process: Discovery, Tech Spec generation, AI Coding, and Testing/Deployment.
Pods focus on one problem at a time, eliminating multitasking across workstreams.
Cycle time is expected to drop from weeks or months to days.
The feature factory risk is real. AI acceleration amplifies the consequences of poor prioritization. Strong product management practice at Zone 1 is the foundation the entire model depends on.
Governance and quality remain open challenges. A layer of AI governance agents is being considered as a checks-and-balances mechanism.
Human review at every stage is still required. Full automation of decision-making is not yet on the table.