Most software organizations still describe themselves as cross-functional. But in practice, cross-functional often means a queue of functions.

Product defines the problem. Design shapes the experience. Frontend and backend engineering implement the system. DevOps deploys and operates it. Analytics measures what happened. QA finds what broke. Scrum, at its best, helped reduce the distance between these functions.

LLM-based development allows more steps in product development to happen in parallel, in conversation with one another, and closer to the original user problem. Requirements can become structured specs, prototypes, tests, release gates, and experiments, with evidence from each stage feeding the next version.

One useful model is neither a traditional squad with AI tools added on top nor one person with a swarm of agents. It is a small group of high-context builders organized around a clear product outcome.

My working hypothesis for some product bets is a pod of four to six people. That is not a universal staffing prescription; the right size and disciplines depend on the system, risk, and stage of the work.

A builder is not a product manager who learned to prompt, a designer who can generate mockups, or an engineer who uses Copilot. A builder is someone who can participate across the full path from user need to production outcome. They may have a depth spike in product strategy, UX, frontend, backend, infrastructure, experimentation, or data. But they are not limited to that spike.

They can reason about the customer. They can shape a spec. They can critique an interface. They can understand the system architecture. They can work with AI coding tools. They can evaluate quality. They can look at telemetry after launch and decide what should happen next.

The role becomes broader because the work becomes more continuous.

Current coding agents can inspect codebases, edit files, run commands and tests, create pull requests, support review, and inspect CI results. But the human role does not disappear. It moves up the stack toward intent, judgment, architecture, quality, safety, and accountability.

The mistake is to treat AI as a productivity layer for the same old process. Give every function an AI tool, keep the same handoffs, keep the same ceremonies, keep the same tickets, and hope velocity goes up.

Some velocity will go up. But the deeper gains come from redesigning the system of work.

DORA’s 2025 research describes AI as an amplifier and found higher adoption associated with greater throughput but also greater delivery instability when the underlying system was weak. Stack Overflow’s 2025 survey shows the same tension from a developer perspective: AI adoption is widespread, but trust is not. The most common frustration is that the output is almost right, but not quite.

That is why I expect some teams to operate with fewer handoffs and require more shared product context, quality discipline, and ownership across the people in the loop.

The builder pod

In a traditional team, the operating model is organized around roles.

In a builder pod, the operating model is organized around the product bet.

A typical 4 to 6 person builder pod might look like this:

• One person has a product and outcome spike. They are strongest at customer understanding, strategy, prioritization, metrics, and experiment design.
• One person has an experience and prototype spike. They are strongest at interaction design, information architecture, design systems, accessibility, and rapid validation.
• One or two people have full-stack system spikes. They are strongest at architecture, data models, APIs, frontend implementation, performance, and maintainability.
• One person has a platform, reliability, and operations spike. They are strongest at CI/CD, infrastructure, observability, security, deployment, and cost controls.
• One person, sometimes shared across pods, has an evaluation and data spike. They are strongest at test strategy, product analytics, experimentation, model evaluation, and quality gates.

These are not rigid job descriptions. Everyone can move through the whole loop: user requirements, spec generation, prototype validation, implementation, evaluations, experiments, early launches, and production.

The pod is small enough to maintain shared context. It is large enough to preserve review, dissent, and operational coverage.

The PRD becomes executable

In the AI-native workflow, the PRD is no longer only a document that explains what should be built. It becomes an executable contract between the team, the AI tools, the system, and the customer outcome.

A strong AI-native PRD or spec should include:

• The user problem.
• The job to be done.
• The non-goals.
• The product behavior.
• The data and event requirements.
• The design constraints.
• The accessibility, privacy, and security constraints.
• The acceptance criteria.
• The evaluation plan.
• The rollout plan.
• The kill criteria.

AI is highly sensitive to context. Vague requirements produce plausible software. Precise requirements produce software that can be tested, reviewed, and improved.

Spec-driven development is emerging for this reason. Thoughtworks describes it as a practice where well-crafted software requirements become prompts for AI coding agents, and in the more radical version, the spec becomes the source of truth while code becomes a generated byproduct.

Humans do not stop writing requirements. Requirements become more important. The spec becomes the steering wheel.

Scrum is a foundation, not the whole operating model

Scrum was a major improvement over waterfall-era delivery. It pushed teams toward smaller increments, cross-functional collaboration, inspection, and adaptation. The official Scrum Guide already describes small, self-managing, cross-functional teams with no subteams or hierarchies. That remains directionally right.

The challenge is how easily Scrum practices can drift from their original intent.

• Backlogs can become warehouses rather than prioritized choices.
• Story points can become accounting systems instead of planning aids.
• Standups can drift into status reporting.
• Sprint planning can become negotiation over capacity rather than outcomes.
• Sprint reviews can focus on completed output instead of evidence and learning.
• Retrospectives can repeatedly identify process debt without creating ownership to change it.

AI-native development strains this model because the speed of work changes. A team can generate a prototype in hours. It can create multiple solution paths in parallel. It can test edge cases earlier. It can simulate implementation options before committing. It can ship behind flags sooner. It can learn from telemetry continuously.

A two-week sprint is not always the natural unit of learning anymore.

The better unit is the validated product bet.

The workflow puts more weight on context than ceremonies, specs than tickets, evidence than velocity, shared ownership than handoffs, and production learning than sprint completion.

Agile values still matter. Individuals and interactions still matter. Working software still matters. Customer collaboration still matters. Responding to change still matters. AI-native development should be seen as a return to those values, not a rejection of them.

The new artifacts

When an operating model relies heavily on epics, stories, points, sprint rituals, and release trains, AI-assisted work may need additional artifacts.

1. The builder brief. This is the one-page articulation of the product bet: the user, the problem, the outcome, the constraints, and the decision that needs to be made.
2. The context pack. This is the shared operating memory for humans and AI: relevant code paths, APIs, design tokens, data contracts, examples, previous decisions, analytics, guardrails, and system constraints.
3. The executable spec. This is the PRD that can drive generation, review, and evaluation. It includes acceptance criteria, non-goals, edge cases, observability requirements, and rollout logic.
4. The prototype record. This captures what was tried, what users saw, what the team learned, and what changed before production.
5. The evaluation matrix. This defines what must be true before the system can move forward: unit tests, integration tests, accessibility, performance, privacy, security, product behavior, and if the product uses AI directly, model quality and safety checks.
6. The launch ledger. This ties feature flags, A/B tests, exposure rules, metrics, incidents, decisions, and follow-up work into one record.

These artifacts are lighter than traditional process documents, but more operationally precise. They are the control plane for high-speed development.

What changes for product leaders

The PM role moves closer to the build. Product managers will explore concepts, generate prototypes, interrogate tradeoffs, write better specs, define evals, and inspect production behavior instead of writing requirements and waiting for implementation.

McKinsey argues that AI can move PMs closer to prototypes and technical proofs of concept, reducing some sequential handoffs. It separately predicts greater overlap among product management, product design, and product marketing.

This is not a demotion of product management. It is an expansion of product management.

Product leaders in this model need fluency in customer needs, business strategy, system behavior, AI capability, experimentation, and operational risk.

They do not need to be the strongest coder in the room. They need enough fluency to work with technical artifacts and enough judgment to connect those artifacts to customer and business outcomes.

The near future

I expect access to AI coding tools to become less differentiating.

If that happens, the difference will be operating model. Smaller, high-context teams with fewer handoffs may have an advantage. They can rely more on high-quality context, treat evaluation as a first-class product discipline, ship earlier behind stronger controls, and measure learning instead of output alone.

They will also be more accountable.

AI makes it easier to produce software but it does not automatically make it easier to produce good software. That is the central leadership challenge.

The durable advantage will come from combining AI speed with human judgment, product taste, engineering discipline, and operational responsibility.

In that world, the most important question is not “How many engineers do we need?”

The better question is:

“What is the smallest team of builders that can own the outcome end to end?”

For some bounded product bets, I think four to six may be enough. Complex platforms, regulated systems, and operationally intensive products will require different shapes and deeper specialist support.

A practical learning loop

The pod mission should be one product outcome rather than one function: improve onboarding completion, reduce friction in a discovery flow, increase self-service success, reduce operational toil, or launch an AI-assisted workflow.

A weekly cadence might define the bet and its evaluation criteria on Monday, swarm on the prototype and implementation paths through Wednesday, run human and technical review on Thursday, then launch behind flags and inspect telemetry on Friday. The calendar can stretch or compress; the important sequence is problem, spec, prototype, build, evaluation, launch, and learning.

The artifacts described earlier become the pod's standing memory. Its measures should balance speed, product outcomes, quality, cost, and review load: time from user signal to prototype, time from an approved spec to a testable build, eval pass rate, escaped defects, rollback rate, experiment and learning velocity, outcome movement, AI cost per shipped outcome, and human review load. The exact set should follow the product bet rather than becoming a universal scorecard.

The leadership review should focus less on velocity and more on evidence. What did the pod learn? What changed in the product? What changed in user behavior? What got safer, faster, simpler, or more useful?

Operating principles

Five principles hold this model together. Use AI across the workflow without treating its output as trusted by default. Make the shared spec stronger than any individual prompt. Treat prototypes as tools for exposing ambiguity rather than stakeholder theater. Move evaluation, instrumentation, privacy, security, and performance checks alongside implementation. Keep named humans accountable for architecture, risk, and launch decisions.

The pod also needs reversibility and honest dissent. Feature flags, staged rollouts, observability, rollback paths, and kill criteria let a small team move quickly without hiding mistakes. Breadth should not become sameness: product judgment, design taste, engineering depth, operational discipline, and data fluency still need independent voices.

I would not scale this structure until the loop works. Clear specs, useful prototypes, reliable evals, safe launches, measurable learning, and accountable ownership have to exist before adding more pods. Otherwise the organization will only create chaos faster.