Yeret Agility's Blog

AI Didn't Kill Agile. It Moved the Bottleneck.

Yuval Yeret — Sat, 06 Jun 2026 00:00:00 GMT

Why AI Doesn't Make Agile Obsolete (And Where the Bottleneck Moved)

There is a popular narrative that AI coding tools and agents are making Agile obsolete. This gets the story exactly backwards: AI isn't killing agility; it is moving the bottleneck. When engineering capacity goes from a scarce, expensive constraint to an abundant commodity, the machinery we built to ration it—backlogs, prioritization queues, and heavy governance gates—turns from protection into a cage. The bottleneck has shifted downstream to organizational absorption capacity: from "can we build it?" to "can anyone actually put it to work and prove its value?"

This shift inverts the job of agility. Instead of protecting engineering from the organization, our new task is to unleash engineering into the organization at the front lines, close to the actual human workflows. When the cost of building falls toward zero, we unlock "unreasonable agility"—the ability to experiment, throw away, and iterate at a tempo that used to be irresponsible. But speed without steering is just waste, accelerated. To scale this new speed without chaos, we must replace external scarcity brakes with internal ones: organizing around goals rather than specs, managing opportunity backlogs instead of feature lists, and building a thin platform spine so edge learning compounds.

Did AI make Agile obsolete?

There is a popular narrative right now that AI is making Agile obsolete. I think it gets the story exactly backwards: AI is not killing agility, it is moving the bottleneck. And whenever the bottleneck moves, the operating model has to move with it.

The argument for "AI killed Agile" usually goes like this: if AI can generate code, specs, tests, designs, and documentation—maybe whole applications—then all the process we built around software development is dead weight. Why bother with Scrum, planning, refinement, estimation, or product management when the machine just produces the thing? The mistake is to confuse a particular implementation of agility—the one built for a world where engineering was the scarce resource—with the purpose of agility. The implementation is aging out, but the purpose is about to matter more than it ever has.

For most of the software era, the bottleneck was production. Could we build the thing? Could engineering keep up with demand? Could we point scarce engineering capacity at the highest-value work instead of spraying it everywhere? That world produced Agile, Scrum, Kanban, Lean Product Development, and DevOps. Underneath every framework and ritual was one economic fact: engineering capability was scarce and expensive.

So we built machinery to ration it. Backlogs, prioritization, sprint commitments, intake processes, architecture review boards, and governance layers. Be honest about what most of that machinery was for: it existed to protect a scarce, expensive resource from waste and thrash. A lot of what we call Agile became, in practice, a system for managing constrained engineering throughput—a careful queue in front of the one team everyone wanted more of. That was the right design for that constraint, but AI changes the constraint entirely.

Where did the bottleneck move?

Code generation is getting dramatically cheaper. So is prototyping, specification, and experimentation. Small teams now produce what used to require a department, meaning the ability to create software is no longer the thing standing in the way. When production stops being the bottleneck, a different one shows up underneath it: adoption, consumption, and operationalization. The question is no longer "can we build it?" but "can anyone actually absorb it and put it to work?"

This is why so many organizations are drowning in AI activity while starving for AI impact. They have copilots, agents, internal tools, LLM integrations, pilots, and a graveyard of prototypes. And yet the workflows barely change, people drift back to old habits, customers don't adopt, and no one can connect the token bill to a business outcome. The AI "transformation" is mostly theater because the limiter isn't technical capability anymore. It's organizational absorption capacity. Humans, workflows, incentives, trust, governance, and habits do not evolve at the speed a model ships. That gap—between how fast we can now create capability and how slowly organizations absorb it—is the defining management problem of this decade, and it is exactly the gap Forward Deployed Engineering exists to close.

Why is Forward Deployed Engineering suddenly relevant again?

Forward Deployed Engineering is suddenly fashionable, presented as if someone just invented it. They didn't. It is simply the newest label for a pattern as old as engineering itself: customer-facing engineering, field engineering, delivery organizations, solution engineering, professional services, and embedded consulting. I've spent close to two decades inside this exact tension—working with Amdocs, HP, NEC, Idemia, Aras, and others—navigating the same core questions every time. How much do you invest in a central platform, and how much do you bend it to the reality of a specific customer? How close should engineering sit to the operational mess, and how much autonomy belongs at the edge?

I've watched the same fight play out inside enterprise IT. On one side, a central group protecting standards, architecture, and platforms. On the other, business units routing around them because central delivery feels slow and disconnected. Neither side is wrong, but the topology is just hard. So while FDE itself is old news, what is new is the size of the gap it now has to span. AI has widened the distance between capability creation and capability adoption faster than any technology shift I've seen. Closing that distance is no longer a side function you bolt on after the "real" engineering. It is the work.

What are the two ways engineering moves to the front lines?

There isn't one FDE model. There are two, and they lead to different operating models. The first is familiar: keep the product stable as a platform, and stand up downstream forward-deployed teams to get it adopted in each customer's reality. In this model, the platform protects scale while the FDE layer absorbs context.

The second model is more interesting, and AI is what makes it possible: the product organization itself becomes forward-deployed. When a 10x increase in engineering leverage means your R&D no longer has to sit behind a wall of intake and protection, you can send it on offense—closer to customers and closer to the actual workflows—without giving up the integrity of the product. You stop running R&D as a defended fortress and start running it as a front-line force. You can see both models straining at the companies furthest ahead. OpenAI and Anthropic did the thing everyone is racing toward: they 10x'd what a product organization can create. The result is enormous capability sitting in front of a consumption-and-adoption wall. More and more SaaS companies are about to land in the same place. They'll win the build and then discover the build was never the hard part.

How did agility's job change when engineering stopped being scarce?

Here is the line I would defend out loud: for thirty years, agility's practical job was to protect engineering—to ration a scarce resource, defend it from thrash, and aim it at the highest-value work. The gates, the queues, the prioritization rituals: all of it was a fence around something precious. When the precious thing stops being scarce, the fence stops being protection and becomes a cage. If engineering is no longer the bottleneck, every gate you built to ration it is now just drag. This is the real reason so many smart people feel like Agile has gone irrelevant. They're not wrong about the cage; they are just wrong about the conclusion.

Because agility's job doesn't disappear when engineering becomes abundant. It inverts. The job is no longer to protect engineering from the organization. It's to unleash engineering into the organization—push it to the front lines, point it at the highest-value adoption problems, and keep it learning fast enough to matter. It is the same purpose underneath, but with the opposite posture: from defending capacity to deploying it.

Forward Deployed Engineering is what that inversion looks like in an org chart. Done well, it's a more honest expression of what agility was always about than most of what carries the Agile label today. FDE teams live where uncertainty is highest. They can't lean on central planning because the learning only exists in the field. They can't treat deployment as something that happens after delivery, because delivery isn't done until someone adopts it. It is build, try, learn, and adapt—at the boundary between the plan and the reality. It is empirical process control with the training wheels off.

What does AI make newly possible?

When engineering was scarce, agility was reasonable. It was bounded by the cost of building. You couldn't stand up five variants to see which one customers adopted—you'd burn the quarter. The cost of production quietly did your prioritizing for you. It forced restraint, and restraint looked like discipline. Take that cost toward zero and you unlock something I'd call unreasonable agility—adaptiveness at a tempo and scale that used to be irresponsible.

You can build three real versions for three customers instead of arguing about one roadmap. You can throw away last week's implementation without grief because rebuilding is cheap. You can put a working thing in front of a frontline team in the morning and have a better one by the afternoon. You can treat the deployment itself as the product and re-tune it continuously against what people actually do. The moves that used to be too wasteful to consider become the default. Learning can now move almost as fast as the uncertainty it's chasing. That's the upside everyone is excited about. It's real, but it has a catch almost no one is pricing in.

What happens when speed loses its brake?

The cost of building was never only a tax; it was a brake. It forced prioritization whether you valued prioritization or not. It made you think before you built, because building was the expensive part. Remove the brake and motion gets cheap, but direction doesn't. Direction was never priced by the cost of code. So you get speed without steering—and AI does not create new value, it creates new speed. Point new speed at the wrong thing and you don't get transformation; you get waste, accelerated.

Unreasonable agility without a replacement brake degrades in predictable ways. First, bespoke sprawl: every customer becomes a snowflake, nothing compounds, and you find yourself maintaining forty one-offs by spring. Second, activity theater: dashboards full of prototypes and tokens consumed, none of it tied to an adopted outcome. Third, fragmented learning: ten teams discover the same lesson ten times and none of it makes it back to the center. It leads to heroics that don't scale, and then burns out the heroes.

The danger in this era is no longer moving too slowly. It is accelerating in the wrong direction with the confidence of someone who is "shipping." And weak feedback loops, merely costly when production was slow, become genuinely dangerous when a bad signal propagates at the speed of generation. So "just remove all the process" is half right and half catastrophic. The old gates do need to go, but remove the brake and put nothing in its place, and unreasonable agility eats itself. You don't get a forward-deployed organization; you get expensive chaos with a modern logo.

How do you scale unreasonable agility without killing it?

The whole game is replacing an external brake with an internal one. Scarcity used to do your prioritizing from the outside. Now it has to come from inside—goals, feedback, and judgment, not gates and queues. Reach for the old heavy governance and you re-cage the engineering you just freed. Reach for nothing and you drift.

A few things I've seen actually hold the line:

Organize around goals, not specs. Spec-driven development made sense when implementation was the expensive part. When implementation is cheap and clarity of intent is scarce, you flip to goal-driven development. You don't hand teams a specification to execute. You hand them a goal to seek—a customer transformation goal, an adoption goal, or an operational leverage goal—and let the implementation path stay fluid. Goals constrain exploration without scripting it. They are the steering that replaces the brake.
Reframe the backlog around opportunity, not product. In a forward-deployed world, the unit of value isn't a feature; it's a realized outcome. This means maintaining an opportunity backlog instead of a product backlog, led by an opportunity owner instead of a product owner—someone accountable for an adoption or transformation outcome, not for shipping a list. The question stops being "how much did we build?" and becomes "how much real change did we enable?"
Make the feedback loop measure value, not output. Velocity was the right metric when output was the constraint. It's actively misleading now. Instead, measure adoption. Measure the ratio of token spend to operational value. Measure whether the workflow actually changed and stayed changed. If your dashboard can't tell activity from impact, it will happily celebrate the wrong one.
Keep a thin spine so the edge compounds. This is the old central-platform-versus-edge problem, and it gets sharper. Unreasonable agility at the edge only pays off if the learning and the reusable pieces flow back to a center light enough not to slow anyone down. Too much spine and you've rebuilt the cage; too little and every engagement starts from zero. Keep the spine thin and load-bearing at the same time.
Empower teams to seek value, and hold them to the outcome. Empowerment without accountability is abdication, and the old accountability—"did you hit the plan?"—is the wrong question. The right one is closer to an investor's: probability of win times impact, minus the cost of pursuit. Real autonomy over how, a hard line on what for.

None of this is a new framework to install by the book. It is a set of forces that keep unreasonable agility pointed at something.

What does the Agile industry need to admit?

Agile itself now needs Forward Deployed Engineering. The Agile industry productized the same way SaaS did. Frameworks became products, training became distribution, and certifications became recurring revenue. For a long stretch that made sense—it created real access and scale. But it landed where enterprise software is landing now: a yawning gap between the theoretical capability of the "product" and the impact it makes on the ground. Organizations don't need another framework PDF, certification badge, or terminology debate run from an ivory tower. The capability to "do Agile" is no longer scarce; the ability to make it stick in a specific organization's reality is.

So Agile has its own activity-to-impact bottleneck—and the same fix. What organizations need are forward-deployed agility practitioners: people who embed at the front lines, read the shifting bottleneck, adapt the practices to the actual context, and stand up operating systems that turn AI activity into outcomes. Doing the work, and helping others do it. Working, validated outcomes over comprehensive documentation. Customer collaboration over contract negotiation. I wonder where I've heard that before. The Manifesto was never an implementation manual; it was a set of directional principles. In the AI era they matter more, not less. We just stopped reading them as principles and started selling them as products.

Where does this leave leaders?

The headline narrative has it backwards on every count. AI didn't kill agility; it relocated the place where agility matters most. It didn't make engineering discipline obsolete; it inverted discipline's job from protecting a scarce resource to unleashing an abundant one. And it didn't remove the need for a brake; it moved the brake from the outside—the cost of building—to the inside, where it has to be made of goals, feedback, and judgment instead of gates.

The organizations that win the AI era won't be the ones with the best models. Everyone will have good models. They will be the ones that learn, adapt, deploy, and absorb faster than everyone else—the ones that build a system for continuously integrating new capability into evolving human work. That is an agility problem. Increasingly, it is a Forward Deployed Engineering problem. Because it is no longer enough to create capability; creating it is the part that just got cheap. The work now—the scarce, valuable, unglamorous work—is helping organizations absorb it.

Agility isn't dying. It's finally leaving the software department.

If your AI program is generating a lot of activity and not enough adopted impact, that's the gap I help leadership teams close. Get in touch or DM me on LinkedIn to discuss how we can align your operating system to this new speed.

Originally published at https://yuvalyeret.com/blog/ai-didnt-kill-agile-it-moved-the-bottleneck/.

Is Spec-Driven Development a Step Forward or Back for Product Development?

Yuval Yeret — Fri, 05 Jun 2026 00:00:00 GMT

What is Spec-Driven Development (SDD) and How Does It Fit with Agile?

Spec-driven development looks like a step backward if you think of the spec as a document that sits between business people and developers. In that model, a detailed spec is requirements theater with more Markdown. It invites mini-waterfall behavior: write a lot, hand it off, let the builders build, and review the mess later. I think that is the wrong mental model for what is happening.

The better frame is that the spec is becoming a higher-level programming language. Humans will increasingly maintain intent, constraints, acceptance criteria, examples, context, and learning strategy at the spec layer, while AI agents do more of the lower-level coding work. That does not mean Scrum needs detailed specs in the Product Backlog, refinement, or Sprint Planning. It means the team aligns around goals and context there, then develops the spec during the Sprint as part of doing the work.

What happens to our development lifecycle when we adopt AI for coding?

I'm seeing engineering organizations go in a couple of different directions with their iterative agile lifecycles as they adopt AI-spec-driven development. (Think Scrum, SAFe). Most of the time, they either try to force-fit spec-driven activities into their existing Scrum process, or they throw away all of the process and start from scratch.

Case in point - A Scrum community thread recently raised a question I expect many teams are asking in different words: if AI is doing more task decomposition, and specs are detailed enough that they almost describe the code AI will generate, what happens to Product Backlog Refinement, Sprint Planning, and Scrum itself?

The concern is fair. Some teams are seeing refinement become disengaging because one person, sometimes with AI, arrives with a detailed breakdown before the conversation starts. Some teams are spending less time estimating because the work is sliced smaller or because the implementation effort feels less meaningful when AI is in the loop. Some people look at the flow and see docs first, execution second, review later, and they reasonably ask whether we have recreated waterfall with better tools.

I look at the whole spec-driven thing differently.

Spec-driven moves your development lifecycle one level up

In my view, the intent of spec-driven development is not to create a heavier ticket before coding starts. It is that the spec becomes the code layer that humans maintain most of the time. Think about the historical stack: machine code, assembly, C, higher-level languages, low-code, no-code. We moved upward because each new layer let humans express intent at a more useful level of abstraction, while still allowing lower-level work when the situation demanded it. We did not stop caring about lower layers. We just stopped asking most people to live there every day.

AI-assisted software development is pushing us through another layer shift. Much of our "code" will be managed through spec-driven interactions. There will still be lower-level coding. There will still be situations where someone has to inspect the generated code, tune the architecture, write a tricky algorithm, debug a production issue, or work close to the metal. There are still people writing C in the Linux kernel, even though most business software has moved far above that layer. But for a growing share of product work, the human programming surface is becoming the spec.

Coding the spec is not a burden

This is why I do not buy the complaint that writing the spec is just a new administrative burden. It can become one, absolutely. Bad process can turn anything into a burden. But the useful version of spec-driven development is not "write more documentation before the real work." The useful version is "program the system at the level where human judgment matters most."

The spec is where we express the goal, intent, context, constraints, trade-offs, acceptance criteria, examples, risks, assumptions, and the signals we will look for. That is not paperwork. That is the work. It is the programming language of human intent.

The important shift is that the spec is not a proxy for requirements being fed to passive builders. It is the place where builders, product people, designers, domain experts, and agents collaborate to shape intent into a working outcome. That is a very different thing from a business analyst writing a detailed requirements document and throwing it over the wall.

When Should We Do Spec-Driven Development? Where does it fit in an Agile/Scrum Lifecycle?

The next mistake is trying to force this new spec layer into classic Scrum artifacts at the wrong altitude.

Do we need to specify before adding something to our backlog?

A Product Backlog does not need to contain detailed specs. A Product Backlog item does not need to include the full spec that an AI agent will use to build. During refinement, and even during Sprint Planning, the useful level is usually the same level good teams already aimed for before AI: what is the goal or intent, what are the rough acceptance criteria, what context matters, what leading indicators would tell us this is worth doing, and what is the next sensible slice?

Should developers expect a ready spec before starting to build something?

The argument around "ready" is decades old at this point. One side argues that the development factory can do twice the work at half the time if you focus on ready inventory. And that is true. But do you really want twice the work? The other side of that argument is that if you care about outcomes not output, you should be ok with discovery that happens closer to the work, even though it creates some messiness. You might think about it as value trumps flow/waste elimination.

With that in mind - the answer in the spec-driven world depends on what you're trying to optimize for. If you're trying to optimize for output, maybe you should focus on ready specs before building. If you're building in an environment of opportunity and uncertainty, you're better off allowing the spec to emerge and evolve iteratively.

In this environment, a clearly articulated goal is enough to have a refinement conversation. It is enough to prioritize. It is enough to decide what is worth pulling further.

Yes, It is not enough to drive an AI coding agent all the way through a meaningful implementation, and that is fine. It was never supposed to be.

One of the healthiest things AI can do for Scrum teams is force them to revisit what refinement is actually for. Refinement is not a ceremony where the team must collectively decompose everything into tasks. It is not where the team has to manufacture detailed estimates. It is not where the entire implementation approach has to be agreed in advance.

Useful refinement creates shared understanding of the business problem, the product intent, the shape of the option, and the reasons this might or might not matter. It should help the Product Owner and Developers inspect whether the item is worth keeping, whether it is small enough to pull soon, whether the acceptance criteria are directionally clear, and whether there is enough context for a team to make progress.

If a team is using refinement to review a giant AI-generated task breakdown, I would not be surprised if engagement drops. Most of that detail can be figured out at code-writing time. Worse, that detail can crowd out the conversation humans should be having: what are we trying to achieve, what might we be wrong about, what are we choosing not to do, and what would make this a bad bet?

The Product Backlog should carry intent and context. The spec-driven loop should elaborate the work at the moment the work is being developed. These are different altitudes. Mixing them creates process mud.

So when DO we /Specify?

The detailed spec belongs closer to execution. Once the work starts, a human team member, or a pair, or a small swarm, pulls a goal (e.g. from the Sprint Backlog or a kanban ready queue) and specifies, plans, and builds in collaboration with AI, using the spec as the evolving "code". That is when the real spec-driven cycle goes into full gear. It may involve one person and one agent. It may involve several specialized agents. It may involve two people pairing with an agent. It may involve the whole team swarming a larger item because the risk or importance warrants it.

This is the atomic work that happens day in and day out. You don't need a process like Scrum or Kanban to delve too much into these steps. Like you didn't micromanage each test case in a TDD session, or the microtasks for a developer/engineer as they're approaching how to build something.

What should we do in our Sprint Planning once we move to Spec-Driven Development?

Is Sprint Planning where we break down all of the specs into tasks and estimate them? NO.

The goal of Sprint Planning is not to finish all thinking before the Sprint starts. It is to decide why this Sprint is valuable, what can be done, and how the selected work will initially be approached. The "how" can be quite lightweight, especially when the team has the ability to elaborate specs rapidly during execution.

So, can we cancel our Sprint Planning sessions when shifting to spec-driven development?

That does not mean planning becomes irrelevant. If anything, AI makes focus more important. AI does not unlock the dream of doing everything at once. It makes it easier to start too many things, create too many branches of work, generate too much code, and flood the review and adoption parts of the system. A Sprint can still be very useful as a focus mechanism: this is what we are aiming at now, and that means we are not doing all the other plausible things yet.

The Sprint Backlog can contain a couple of bigger outcome-oriented items, several smaller ones, or one large bet the team intentionally swarms around. The team can decide in Sprint Planning how much collaboration each one deserves. Maybe one person takes the lead and brings others in at decision points. Maybe two people pair with an agent because the architecture is sensitive. Maybe the team divides and conquers after agreeing on boundaries. Maybe they swarm because the risk is high or the learning matters.

That is team design work. Scrum gives the container. It does not need to micromanage the spec cycle inside the container.

Inspecting and Adapting Continuously

When a human-agent pair is moving quickly, important learning can show up mid-Sprint. The agent discovers that the existing architecture does not support the intended direction. The spec exposes a hidden assumption about the workflow. A prototype makes the original idea look less valuable than a nearby option. A technical constraint suggests a different slice. Customer feedback changes the bet.

Waiting a week or two to discuss that can be silly. This is where the Daily Scrum can become useful again, not as a status meeting, but as a steering point. What did we learn? Is our plan for the Sprint Goal still coherent? Do we need a product decision, an architecture conversation, a customer touchpoint, or a team swarm? Is the work moving toward the intent, or are we just generating output?

AI makes this more important because things move faster. A bad direction can produce a lot of plausible code quickly. A good learning loop can redirect quickly, too. The Daily Scrum is one of the places where the team can keep the learning loop visible without turning every spec into a whole-team meeting.

Now, does that have to be a meeting? Do we have to wait until that specific time in the day to talk through stuff? Of course not. Some of the most effective teams I'm seeing are leveraging co-location, continuous availability, and osmosis, while doing some of the most awesome AI-native coding I've seen. But if that's not reality, a structured opportunity to check in with each other, realign, and respond to emerging learning, can still be useful.

The Sprint Review matters more, not less - But it focuses on Goals and Outcomes, not details of the work done

At the end of the Sprint, the team needs to step back. That is no less important because AI helped ship more. It is more important because AI can create acceleration whiplash: the inner loop of building accelerates faster than the outer loop of deciding, adopting, measuring, and learning.

The Sprint Review is when the team and stakeholders review what was shipped, what was learned, and what might make sense next. Did anyone use it? Did it change behavior? Did it move the leading indicator we cared about? Did it reduce the constraint we were aiming at? Are we closer to the Product Goal, or did we just produce impressive activity?

This is where the "spec is the new programming language" idea has to stay connected to value. A beautiful spec that generates working software is still not the finish line. The finish line is learning whether the product, workflow, customer, or business is better off. Scrum's review cadence is a useful forcing function for that conversation, especially when AI-assisted teams can generate more work than the organization can absorb.

In my head - the way to shift AI activity to impact goes one step further beyond spec-driven development towards goal-driven development.

Continuously improving everything - How we work, How we organize, How we interact with AI, Everything

The Retrospective also remains highly relevant, but the questions have changed. What did we learn about our collaboration model? Where did AI help? Where did it create noise? Where did we over-specify? Where did we under-specify? Which agent instructions worked? Which review patterns caught problems early? Where did handoffs slow us down? Where did we create too much work in process? What should we retire, try, or tighten?

The bottleneck may no longer be coding. It might be review, product judgment, customer access, data quality, adoption, release safety, or decision-making. The Retrospective is when the team can inspect the entire operating system rather than only ask whether the Sprint felt good.

If the team discovers that specs are becoming too detailed too early, change that. If one person plus AI is doing all the breakdown and the rest of the team is losing shared understanding, change that. If every backlog item is turning into a giant spec, change that. If AI is helping the team move faster, but the organization cannot use what ships, change that.

Who should be writing these Specs? What's the role of Product ownership in a spec-driven development world?

Specs are like code. Team members should be responsible for specifying, planning, and building with their AI. I've seen teams that expect their product managers/owners to write specs, but to me that makes very little sense. It's like asking product professionals to write acceptance tests or detailed user stories. It leads to disempowered team members and tactical product professionals with a vacuum in strategic product leadership.

I see product roles as focused on overall product direction: where we play, how we win, what outcomes matter, what tradeoffs we are making, and where the next best bet might be. That person was never supposed to be a proxy, a firewall, or a requirements vending machine.

The builders on the team should go as close to customers and users as possible. They should understand the business context, the product strategy, the constraints, and the outcome they are trying to create. They are not fed requirements. They are not fed specs. They are aligned to an intent and surrounded by context. So are their agents. (Btw, this is where concepts like Forward-Deployed Engineering come into play - shifting engineering to the front lines rather than hiding and protecting them behind the closed doors of the typical way organizations manage their product lifecycle.)

Do we need a new framework to replace Scrum/SAFe? Do we need a special version for AI-native development lifecycles?

As a member of the inner circles of both the Scrum and SAFe communities, I'm seeing a raging debate about how to adjust/rethink for the native AI world. I don't know where each community will go.

Here's my take. I do not think teams need a special version of Scrum or SAFe. What they need is to strip these frameworks back to their kernel. Empiricism. Alignment to Outcomes. Focus. Transparency. Inspection. Adaptation. Commitment to goals. Self-management.

Then look at the complementary practices around that kernel. Estimation? Optional. Story points? Optional. User stories? Optional. Detailed task breakdown in Sprint Planning? Optional. Whole-team refinement of implementation detail? Optional. If those practices help, keep them. If AI-assisted spec development has made them low-value or actively harmful, retire or reinvent them.

Kanban can help here, too. Not as Scrum's enemy or replacement (although I'm seeing more and more teams thinking that way), but as a way to see the flow. Visualize where specs are emerging, where agent work is in progress, where review is backing up, where adoption is stalled, and where validation is missing. Limit work in process. Manage flow. Make blocked learning visible. Scrum and Kanban have always been more compatible than the framework debates made them sound. AI is doing for Scrum what Kanban did for many Scrum practitioners a decade ago. It is helping people see the essence by making the accumulated baggage more obvious.

The opportunity in unreasonable agility

The best version of this future is not one where AI writes all the code and humans review a pile of generated output with a grim sense of duty. It is also not one where humans write giant specs and agents mechanically execute them.

The best version is a team with agency. Humans and their agents aligned around outcomes. Backlogs that carry intent instead of fake certainty. Specs that are developed at the right altitude, at the right time, by the people closest to the work, assisted by their agents. Reviews that inspect whether real value was realized. Retrospectives that improve the human-agent operating model. Product leadership that provides strategic context instead of feeding requirements.

That team can move very fast without pretending certainty. It can use specs as a programming language for intent, not as a wall between thinking and doing. It can let AI accelerate the lower layers while humans get better at the higher ones: choosing, framing, steering, sensing, and learning. That is not abandoning agility. That is what agility looks like when the programming surface moves up a layer.

The spec is not the paperwork before the work. Increasingly, the spec is the work humans maintain so people and agents can build, learn, and steer together.

Originally published at https://yuvalyeret.com/blog/is-spec-driven-development-a-step-forward-or-back-for-product-development/.

Why Focus on Flow Metrics? The Problems They Help You See

Yuval Yeret — Thu, 04 Jun 2026 00:00:00 GMT

import AIPrompt from '~~/components/ui/AIPrompt.astro'; import PromptContent from '~~/data/prompts/why-focus-on-flow-metrics-prompt.md';

Start With The Expensive Problem

Most teams do not wake up one morning wishing they had better flow metrics. They wake up frustrated because everything feels busy, but important things still take too long. Leaders ask for a forecast and get a mix of confidence theater, story points, and "it depends." Teams say they are blocked, but the blockers show up late, after the date has already slipped. Priorities keep changing because the organization keeps learning too late that the current plan is not going to work.

That is usually the better place to start. Do not start with "we need WIP, cycle time, throughput, and work item age." Start with the expensive problem. Flow metrics are useful when the problem is hiding in the movement of work. They help you see where work waits, where it ages, where it piles up, where it finishes, and whether the system is becoming healthier or just louder.

Start before the principle

I like principle-based assessments because they avoid one of the worst habits in agile improvement: checking whether people perform the mechanics while ignoring whether the organization is getting better. That is the idea behind my Principle-based Agility Assessment. It is meant to move the conversation away from "are we doing the process correctly?" and toward "are we developing the behaviors that make us more agile?"

But even principles can be too far downstream.

"Focus on flow" is a good principle. "Reduce work in progress" is a useful direction. "Manage work item age" can be a powerful practice. But a leader who is not already in the flow conversation may still ask a fair question: why should I care? The answer should not be "because flow is good." The answer should be tied to a problem they recognize.

Maybe too many things are active and too few are finishing. Maybe every meaningful initiative depends on the same platform team, architect, security reviewer, legal person, data scientist, or executive committee. Maybe the roadmap is full, but customers are still waiting for the thing that matters. Maybe the organization is spending more time coordinating work than doing it. Maybe the portfolio looks strategic on slides and chaotic on Monday morning.

Those are the problems that make flow worth caring about.

When everyone is busy but nothing important finishes

One common symptom is the "busy but stuck" organization. Everyone is loaded. Every team can show progress. Every initiative has an owner. The status report is full. But the few things that matter most move slowly, and by the time they reach the finish line, the business context has changed.

This is where WIP becomes more than a metric. It becomes a mirror.

WIP shows how many things are started but not finished. At team level, that might mean stories, defects, experiments, or service requests. At portfolio level, it might mean initiatives, investments, product bets, or major cross-functional changes. The number itself is not the point. The conversation it creates is the point.

If WIP keeps growing, the organization is starting faster than it is finishing. That usually means longer lead times, more context switching, more stale work, more coordination, and more work that needs to be re-explained every time someone comes back to it. This is why "stop starting, start finishing" lands so well. It names the problem in plain English. Flow metrics help you see whether you are actually doing it.

When forecasts are mostly hope with formatting

Another symptom is forecast pain. The business asks reasonable questions: What is likely to finish this quarter? Can we launch this before the customer event? Which roadmap items are realistic? Are we on track, or are we just still busy?

Many organizations answer those questions with commitments, points, confidence votes, or delivery dates that mostly depend on who is in the room. Then the work starts, dependencies appear, queues grow, and the forecast turns into a negotiation. Flow metrics do not create certainty. They make uncertainty harder to ignore.

Throughput tells you how much work the system tends to finish in a period. Cycle time tells you how long similar work tends to take once it starts. Work item age tells you which active items are already becoming risky. WIP tells you whether the system is stable enough for any forecast to mean much.

That last part matters. If WIP is out of control, item sizes are wildly inconsistent, and dependencies dominate the work, a forecast built on top of that system will still be shaky. The metric did not fail. The metric showed you that the system is not forecastable yet. That changes the conversation from "who gave us the wrong date?" to "what about our system makes dates this fragile?"

When blockers show up too late

Teams often know work is stuck before the official reporting system admits it. The card has not moved. The pull request is waiting. The experiment is waiting for data. The design is waiting for review. The initiative is waiting for the same decision that blocked three other initiatives. But until someone names it as blocked, it can sit there looking normal.

Work item age helps here. Age is the elapsed time since an item started. It is useful because it focuses attention on active work before it becomes another disappointing cycle-time data point after the fact.

At team level, an aging item might mean a story is stuck in development, review, testing, or product clarification. At portfolio level, an aging initiative might mean the investment has been active for months without reaching a decision, a launch, or a meaningful outcome signal. The best use of work item age is not to shame anyone. It is to decide what to do: swarm it, split it, remove a dependency, get a decision, narrow the scope, pause it, or stop it.

That is a very different conversation from "please update your status."

When the same people are involved in everything

Flow also exposes structural problems that status reports hide. If the same team appears on 80 percent of portfolio cards, you do not have a prioritization problem only. You have a constraint. If every meaningful product change needs the same architecture group, platform team, data approval, legal review, or leadership decision, the flow of work will be governed by that constraint whether you admit it or not.

This is where flow connects to product operating model, portfolio agility, and organizational design. Sometimes the next move is not "make the constrained team work harder." It might be to reduce the number of active initiatives touching that group, change sequencing so the constraint works on the most important work first, invest in self-service platforms, move decision rights closer to the work, or reshape product boundaries so fewer initiatives need cross-team choreography.

Flow metrics do not make those decisions for you. They make the cost of avoiding those decisions harder to miss.

When the portfolio has too many good ideas

Flow problems are not always caused by bad work. Often they are caused by too much good work. This is especially visible at portfolio level. Every initiative has a sponsor. Every initiative has a rationale. Every initiative can be defended. The problem is that the collection of active initiatives is too heavy for the organization to carry.

A busy portfolio Kanban tells a story. Sometimes it tells you that leadership is still managing too many decisions centrally. Sometimes it tells you that your product architecture creates too much cross-product dependency. Sometimes it tells you that the organization is better at approving work than finishing it. Sometimes it tells you that the portfolio is a swamp pretending to be a roadmap.

The flow move is to review right to left. Start with what is closest to done. Then look at what is stuck. Then ask what should be accelerated, descoped, paused, or stopped. Only after that should you ask what new work deserves to enter. That one habit changes the room. It makes starting new work feel less innocent because everyone has just looked at the unfinished work already asking for attention.

When local improvement does not improve the business

Flow metrics are also useful when one part of the organization is getting faster, but the business is not. This shows up a lot now with AI-assisted work, but it is not only an AI problem. Engineering can get faster while product discovery, review, release, adoption, customer onboarding, or leadership decision-making becomes the real constraint. Marketing can produce more campaigns while approvals or sales follow-up becomes the bottleneck. Product can generate more ideas while teams are still drowning in old commitments.

Local speed is seductive. End-to-end flow is more honest.

The question is not "which team got faster?" The question is "which business constraint moved?" Did a customer get value sooner? Did a costly delay shrink? Did a decision improve? Did a queue get shorter? Did the organization learn something earlier while it was still cheap to change direction?

Flow metrics help connect local work to those system questions. They are not the whole answer, but without them many organizations keep celebrating motion while the constraint stays exactly where it was.

What the four flow metrics are really for

Here is the plain-English version. WIP tells you whether you are trying to do too many things at once. Cycle time tells you how long work actually takes once it starts. Throughput tells you how much work actually finishes. Work item age tells you which active work is becoming risky right now.

Together, they help with three leadership conversations:

Focus: Are we starting more than we can finish?
Predictability: What can we honestly expect from this system?
Intervention: Where should we act now because work is aging, waiting, or piling up?

That is why I would not position flow metrics as a measurement program. Measurement programs often become their own theater. I would position them as a way to have better operating conversations. If the metrics do not change what you start, stop, accelerate, split, descope, or decide, they are probably not helping yet.

If you want the more detailed metric explanation, I cover WIP, cycle time, throughput, and work item age in Flow Metrics for Scrum. I also wrote about applying the same logic at portfolio level in Improving Portfolio Flow Using Flow Metrics.

A simple way to decide whether flow metrics are worth it

Ask these questions:

Do we have more important work active than we can reasonably finish?
Do we often discover blockers late?
Do our forecasts depend more on optimism than on historical flow?
Do priorities shift because old work takes too long to finish?
Do the same people or teams become the bottleneck across many initiatives?
Do we struggle to tell whether the system is improving?
Do leaders spend more time asking for status than making decisions that improve flow?

If several of these are true, flow metrics are probably worth exploring. You do not need a massive rollout. Pick one real workflow. Decide what work item you care about. Make the work visible. Track WIP, cycle time, throughput, and work item age lightly enough that people will actually use them. Then use the data in the meetings you already have.

The first goal is not perfect data. The first goal is a better conversation about why work is slow, what is stuck, what should finish next, and what should stop stealing attention.

That is why focus on flow.

A lightweight self-assessment prompt

You can use this prompt with ChatGPT, Codex, Claude, Gemini, or another assistant as a quick "is flow worth focusing on?" conversation. It is not meant to replace a full assessment. It is meant to start with the problem before jumping to practices.

If flow metrics do not change what you start, stop, finish, split, or unblock, they are probably just another dashboard. The value is in the operating conversation they make possible.

Which flow metric should you start with?

If you are not sure where to start, or which metric makes the most sense for the friction you are actually feeling right now, I put together a quick scorecard. It takes a couple of minutes to fill out, and it will give you a concrete recommendation on what to measure first based on your specific situation.

<div class="not-prose my-10 rounded-2xl border border-slate-200 dark:border-slate-700 bg-slate-50 dark:bg-slate-800/40 p-6 text-center max-w-2xl mx-auto"> <h3 class="text-xl font-bold text-slate-900 dark:text-slate-100 mb-2">Which Flow Metrics Scorecard</h3> <p class="text-sm text-slate-600 dark:text-slate-300 mb-6"> Take the free 2-minute diagnostic to find the right flow metric for your current organizational challenges. </p> <a href="https://scorecard.yeretagility.com/quiz/which-flow-metrics" target="_blank" rel="noopener noreferrer" class="btn-primary no-underline" > Take the Scorecard → </a> </div>

Originally published at https://yuvalyeret.com/blog/why-focus-on-flow-metrics/.

AI Agents Can Now Run Toward Goals — Are Yours Worth Running Toward?

Yuval Yeret — Wed, 27 May 2026 00:00:00 GMT

How to Set AI Agent Goals That Actually Drive Business Outcomes

Claude's new /goal feature lets you set a completion condition and have the AI keep working across turns until the condition holds — a lightweight autonomous loop without you having to prompt each step. It is a genuinely useful step toward higher-agency AI. But look at the canonical examples: migrate an API until every call site compiles and tests pass, implement a design doc until all acceptance criteria hold, split a large file, empty a labeled issue backlog. Every single one is output-oriented. Nothing in the example list asks whether a feature was actually adopted, whether a page works well for visitors, or whether a presentation landed with the audience. The feature is real; the goals people will default to are the wrong unit.

The bottleneck this reveals is not about the feature itself. It is about observability. For an AI agent to chase outcome-oriented goals, it has to be able to close the feedback loop — to ask whether value was actually delivered, not just whether the task was technically complete. That feedback loop does not yet exist for most of the things that matter most. Building it is the next frontier, and it is where the real work of moving from AI activity to impact will happen.

What changed in Claude?

Anthropic recently shipped a capability called completion goals: you set a target condition with /goal, and Claude keeps working across turns until the condition is met. After each turn, a lightweight model checks whether the condition holds. If it does not, Claude starts another turn instead of returning control to you. No more nudging, re-prompting, or babysitting a multi-step sequence.

This is meaningfully different from a one-shot prompt. It is closer to delegating a problem to someone and telling them not to come back until it is done. In my own workflow I have been building something similar manually — a Ralph loop, a recurring automation that keeps Claude working on a thread until a stopping condition is reached. The /goal feature moves that pattern into the harness itself, which makes it accessible to anyone without custom scripting.

The mechanics are sound. The interesting question is what people will use this for.

What do the examples reveal?

When Anthropic introduces a feature like this, the canonical examples they choose are telling. Here is what they offered: migrating a model to a new API until every call site compiles and tests pass; implementing a design doc until all acceptance criteria hold; splitting a large file into focused modules as a tech debt improvement; working through a labeled issue backlog until the queue is empty.

All technical. All verifiable by the agent itself. All output.

That list is not wrong — those are real, useful things to automate. But look at what is not on the list. There is no example of "keep working on this landing page until it converts well." No "keep iterating on this feature until users adopt it." No "keep refining this presentation until the audience understands it." No "keep improving this content until it earns meaningful reach." Nothing that asks whether the thing we built actually mattered to the people it was supposed to serve.

Those absences are not accidental. They reflect a real constraint: AI agents can close the loop on technical correctness far more easily than they can close the loop on human value. Whether tests pass is observable by a machine. Whether people use a feature, whether a page works for real visitors, whether a talk lands — those require a fundamentally different kind of signal.

Why doesn't output create impact?

This is the core tension. Output is easy to measure inside the system. Outcome lives outside it, in the behavior and experience of the people you were trying to help.

When you set a completion goal around a technical criterion, the agent has clear stopping conditions it can evaluate autonomously and reliably. When you set one around an outcome, you immediately run into the question: how would the agent observe whether that condition holds? The agent can write the code. It cannot measure whether the code moved the metric you care about. It can publish the blog post. It cannot tell you whether anyone read it, thought differently as a result, or took a meaningful next step.

This is not a knock on /goal. It is a precise description of where the real leverage is. Automating output production is valuable. But the constraint for most organizations trying to get real value from AI is not that they lack the ability to produce more output. It is that the output they produce often fails to convert into the outcomes they care about, and they have no clear signal on why or how to change that.

What is the new bottleneck?

If you want to give AI agents outcome-oriented goals, you need to solve a prior problem: how does the agent know whether the outcome was reached? This means instrumentation. It means closing the feedback loop between what AI produces and whether that production moved the needle. It means building the observability layer that lets a completion condition like "users adopted this feature" or "this content performs" actually be evaluated, not just assumed.

Most organizations do not have that instrumentation today — not for AI outputs, and often not for human outputs either. We track task completion, story points, PRs merged, tickets closed. We are much weaker on adoption rates, usage patterns, business metric movement, and the causal chain between what we built and what changed. AI acceleration makes this gap more expensive, not less. When the rate of output production increases dramatically, the cost of producing things that nobody uses or that fail to achieve their purpose scales with it.

The work of building new observability is not glamorous. It does not feel as exciting as shipping a /goal feature. But it is what separates the organizations that will use agentic AI to drive real impact from those who will use it to drive impressive-looking activity.

What has to be true for outcome-oriented agent goals?

For outcome-oriented goals to become the norm in agentic AI, a few things need to happen. First, people need to learn how to frame outcome-oriented conditions effectively. Most of us default to output because that is what we have historically tracked and because outputs are easier to specify. Writing a good outcome condition requires clarity about what change you want to see in the world, not just what artifact you want produced.

Second, the feedback loop needs to be closeable by the agent. That means investing in the observability layer — instrumentation, telemetry, measurable leading indicators of value — so that a completion condition based on adoption or quality or business impact can actually be evaluated, not just claimed. For some domains this is a relatively short road; for others it is a multi-year engineering and organizational investment.

Third, the tooling needs to evolve to handle the parts of outcomes that still require human judgment or physical-world observation. Image generation, usability testing, real user feedback, business metric validation — these require either agent-accessible tools or explicit human checkpoints in the loop.

The organizations that get ahead of this will not just be faster at producing output. They will be able to aim that speed at the right targets and know when they have hit them.

What should you ask before setting an AI goal?

You do not need to wait for full observability infrastructure to start reorienting your AI goals. The first move is to ask, for every goal you set: is this a completion condition for an output, or for an outcome? If it is output, is that output reliably connected to the outcome you actually care about, and do you have enough signal to know when it is not?

That question will quickly surface the gaps. It will show you where you are measuring task completion and calling it progress. It will point toward the observability investments worth making. And it will make visible the distinction between AI as an accelerant for activity and AI as a driver of actual impact.

The /goal feature is a real step forward. Use it. But the highest-leverage move is not to chase more efficient loops around output-oriented goals. It is to build the feedback systems that let you aim agentic AI at what actually matters.

What are you doing with completion goals? Are yours output-oriented or outcome-oriented — and what would it take to close the loop on a real outcome?

Watch the Update

The gap between what AI produces and whether it mattered is the next frontier. Build for that one.

Originally published at https://yuvalyeret.com/blog/ai-agent-completion-goals-aim-at-outcomes/.

If AI Coding Made Engineering Faster, Why Isn't The Business Faster?

Yuval Yeret — Thu, 21 May 2026 00:00:00 GMT

Where Does the Software Delivery Bottleneck Move in the AI Era?

AI coding tools change the economics of software delivery. A small team can now generate, debug, test, document, and refactor much faster than it could a couple of years ago. That is real. It matters. But it is also where many leaders make the wrong leap: faster engineering output does not automatically mean faster business impact. In many organizations, AI has moved the bottleneck from "can we build and test it?" to "do we know what is worth building, can we launch it safely, will people adopt it, and can we prove it changed anything that matters?"

This is a flow problem, not just an AI tools problem. If leaders only celebrate local engineering productivity, they may create more output, more work in process, more half-launched tools, and more pressure downstream. The leadership job is changing from "how do we make teams faster?" to "where does this new speed actually improve the flow to value?" That means looking at the whole value stream and aiming human plus artificial intelligence at the current constraint.

Where does value actually flow?

The useful place to start is not the AI tool. It is the path from idea to business impact. An idea has to be discovered, shaped, decided, built, tested, launched, adopted, measured, and learned from. That is the flow that matters. If one part of that flow suddenly gets much faster, the whole system does not automatically get faster. The constraint usually moves.

AI coding changes what feels possible in the build part of that flow. Coding agents, copilots, and increasingly capable development environments can reduce the effort required to create software. They can help with boilerplate, tests, refactoring, debugging, documentation, migration work, and even full feature slices when the intent is clear enough. For engineering teams, this is not a minor productivity bump.

But the system still has to absorb the work. Someone still has to decide what problem is worth solving. Someone has to shape the feature well enough that an agent does not produce the wrong thing quickly. Someone has to look at the architecture, risk, quality, security, adoption, support model, and business outcome. Someone has to launch the thing into a real workflow where people already have habits, incentives, and constraints of their own.

AI can help with many of those activities too. This is not a "humans do everything after coding" argument. It is a constraint argument. When one capability scales faster than the others, the bottleneck moves. If you do not notice where it moved, you end up optimizing the wrong part of the system.

Why does AI speed not automatically become business value?

I keep coming back to one line because it explains a lot of what I see in AI transformation work: AI creates speed, not automatic value. Everything gets faster, including the good things and the bad things.

If your product discovery is sharp, AI helps you turn good intent into tested options faster. If your backlog is full of half-baked requests, AI helps you produce more half-baked software faster. If your team has strong engineering discipline, AI can raise the leverage of that discipline. If your team already struggles with integration, ownership, and release quality, AI may increase the volume of work that hits those weak spots.

This is the part that gets lost in local productivity conversations. A developer becoming 30%, 50%, or even 10x faster at certain tasks is meaningful, but the business does not experience value at the moment code is generated. The business experiences value when the right change reaches the right workflow, gets used, and improves something that matters.

That path from idea to impact includes discovery, prioritization, design, build, test, security, release, adoption, measurement, learning, and sometimes stopping. AI coding mostly accelerates one section of that path. If the rest of the path does not accelerate with it, the pressure just moves downstream.

The point is not to downplay the engineering gain. AI agents are getting genuinely useful at coding, debugging, test generation, documentation, and the mechanics around software delivery. The point is that the gain is asymmetric. Code is a relatively concrete medium with fast feedback loops. Product discovery, adoption, behavior change, and value validation are more ambiguous. They have weaker observability and more human context. So AI often scales engineering faster than it scales the rest of the value stream.

That asymmetry creates what I think of as acceleration whiplash. The inner loop of coding gets faster, but the outer loop of deciding, reviewing, integrating, releasing, adopting, and learning does not move at the same pace. The organization feels more energy and more activity, but the whole system also becomes more volatile. More code arrives at the next gate before the gate has learned how to handle the new arrival rate.

Why is local developer productivity not enough?

Imagine a value stream that starts with an idea and ends with measurable business impact. Before AI coding, engineering throughput may have been the visible constraint. Leaders asked why it took so long to build features, why estimates were unreliable, and why teams could not get more done. Now AI enters the picture and engineering output improves. More prototypes appear. More pull requests are opened. More experiments become technically possible. The demos look better.

Then the organization starts to feel the new congestion. Product leaders cannot make sense of the expanded option set. Architects and security reviewers are asked to look at more changes. Business stakeholders see more demos but still do not know which ones deserve adoption work. Operations teams are asked to absorb tools that change the workflow but not the surrounding policies. Finance still wants to know what changed in cost, revenue, quality, cycle time, or customer experience.

Code review is one of the first places many engineering organizations are already feeling this. AI makes it easier to produce more code, larger pull requests, and more frequent changes. Review capacity does not automatically scale with it. So PRs start accumulating, waiting for review, or they get rubber-stamped because nobody wants to be the person slowing down the new AI-assisted velocity. That makes the metrics look better for a while, but it quietly jeopardizes quality, architecture, security, and shared understanding.

The research direction here is useful, even if I would be cautious about treating any single benchmark as gospel. The patterns to watch are not exotic: PRs getting bigger, review queues getting longer, more changes touching more files, more copy-paste, more churn, and more defects showing up after the merge. These are flow signals. They tell you whether AI is improving the system or just pushing risk into the next queue.

From the inside, this can feel confusing. Everyone can point to more activity. The tools are working. The teams are excited. The engineering demos are real. And still, the business impact lags.

That gap is the signal. It means the constraint is no longer where you thought it was.

Sometimes the gap is visible immediately. Work piles up before release, before adoption, or before business review. Sometimes it is hidden for a while because engineering has a backlog of useful internal work: technical debt, missing tests, brittle pipelines, quality gaps, documentation cleanup, migration work. AI can help burn down that backlog, and that is a good use of the capacity. But it can also delay the moment when leaders notice the new bottleneck. Validating internal quality work is much easier than validating new customer or business value. At some point, if engineering keeps scaling, the constraint will show up elsewhere.

There is another version of this that is more subtle: the expensive busywork factory. When engineering capacity becomes easier to unleash but validated product direction does not keep up, people find work. They clean up papercuts, build internal utilities, prototype side ideas, generate dashboards, and improve things that may be useful but are not necessarily the best use of scarce attention. Some of that work is good. Some of it is the system manufacturing activity because it does not know what value to pull next.

Did the bottleneck move upstream to product judgment?

One of the more surprising effects of AI coding is that it makes weak intent more expensive, not less. When building is slow, vague ideas sometimes die before they consume too much capacity. When building becomes cheap, vague ideas can turn into working software quickly enough to create real downstream cost.

This is why spec-driven development is becoming more important, not less. The AI agent needs a strong description of the desired behavior, the constraints, the acceptance criteria, the edge cases, and the reason the change matters. Without that, it will happily generate plausible code that may or may not solve the right problem.

So the bottleneck often moves upstream to judgment. Which problem is worth solving? What is the smallest valuable slice? What should we learn before we automate? Which customer behavior are we trying to change? What risk should stay human-reviewed? What would make us stop?

Those are not "requirements gathering" questions in the old bureaucratic sense. They are product judgment questions. AI raises the leverage on them because a clear decision can now travel through the build step much faster. A poor decision can travel just as fast.

Did the bottleneck move downstream to adoption?

In other organizations, the upstream work is decent, but the bottleneck appears after the software exists. The team can build internal tools, automations, agents, dashboards, workflows, and prototypes faster than the organization can adopt them.

That is not a technology problem. It is a workflow and operating-model problem. People have existing habits. Teams have handoffs. Leaders have approval paths. Metrics reinforce the old way of working. The new tool may be better in isolation and still fail to change the work.

This is where a lot of AI theater comes from. There are pilots, demos, hackathons, prototypes, and a growing sense that the organization is "doing AI." But business impact does not show up because the work around the tool has not changed. The bottleneck is adoption, process redesign, role clarity, decision rights, or value measurement.

When that is the constraint, adding more AI coding capacity is like widening the entrance to a highway that is jammed three exits later. You will move more cars into the traffic jam. You will not get more people to their destination.

How do you find where the bottleneck moved?

The useful move is to look at the end-to-end flow. Start with the path from business idea to business impact and ask where work is waiting, where decisions are slow, where feedback arrives late, and where value becomes hard to prove.

A cumulative flow diagram is still one of the simplest ways to make this visible. Look at how much work is accumulating over time in each stage: AI activity, explored ideas, working-tested software, shipped software, adopted software, and business impact. If working-tested software is growing much faster than adopted or impact-producing software, the bottleneck has moved. You may have great DORA metrics and still have weak value flow.

You can use the same lens inside engineering. Look at pull requests opened, pull requests waiting for review, review cycle time, PR size, rework after review, defect escape, and how often reviews are approved without meaningful discussion. If AI increases coding throughput but review quality collapses, the bottleneck did not disappear. It moved into review and validation.

This matters even more for AI-enabled development because observability is not just a reporting problem. If you cannot tell whether the thing you shipped is being used, enjoyed, or creating the outcome you expected, your agents cannot close the loop either. They can help produce the next thing, but they cannot learn what "better" means in your context. The feedback loop from real use to future development becomes the constraint.

In some cases, the constraint really is engineering. Maybe a legacy platform needs modernization, the test suite is weak, or teams are buried in toil that AI can help remove. In that case, focus AI there. Use agents to write tests, improve observability, clean up brittle areas, generate migration scaffolding, or reduce manual support work.

In other cases, the constraint is product discovery. Then the right AI use might be research synthesis, opportunity mapping, option generation, experiment design, or turning messy stakeholder input into sharper product bets.

Sometimes the constraint is launch and adoption. Then AI should help with workflow redesign, enablement, support scripts, telemetry, onboarding, internal communications, and the evidence needed to help leaders make the next decision.

And sometimes the constraint is leadership decision quality. Too many ideas are in flight. Funding is spread too thin. Nobody wants to kill a promising-sounding AI initiative. Every team wants its own pilot. In that case, the useful work is portfolio visibility, staged funding, and sponsor-ready evidence. The problem is not that people need more AI ideas. They need a way to choose.

How should leaders apply theory of constraints to AI work?

The theory of constraints gives a practical way to avoid the trap. Find the constraint. Decide how to exploit it. Subordinate the rest of the system to it. Elevate it. Then look again, because the constraint will move.

In this context, "subordinate" is the important word. Do not just ask where AI is exciting. Ask where human and artificial intelligence should be aimed so the constraint can scale. If adoption is the bottleneck, use AI to improve onboarding, activation, support, workflow fit, and usage feedback. If product judgment is the bottleneck, use AI to sharpen options, synthesize evidence, stress-test assumptions, and make better stop/scale decisions. If value evidence is the bottleneck, use AI to instrument the workflow and connect usage to the business outcome leaders actually care about.

In the AI coding world, that might sound like this:

If unclear product intent is the constraint, do not start by buying more coding tools. Improve how teams shape work.
If code review is the constraint, reduce batch size before you add more coding capacity. Smaller PRs, clearer specs, automated pre-review checks, and explicit review WIP limits will do more than asking reviewers to work harder.
If quality and validation are the constraint, use AI to strengthen tests, review risk, catch duplication, and shorten feedback loops before increasing feature volume.
If adoption is the constraint, slow down the demo factory and focus on changing the workflow around fewer, higher-value bets.
If executive decision-making is the constraint, create a visible AI portfolio with confidence by phase, expected impact, cost of pursuit, and clear stop/go criteria.
If business impact measurement is the constraint, define the evidence before the build, not after the launch.

The uncomfortable part is that this often means not using AI where it is most exciting. It means using AI where the system is actually constrained. That is a different management discipline than "encourage everyone to experiment" or "roll out copilots and track usage."

Experimentation is useful. Broad literacy matters. I still want people to have access to the tools. But focused enablement should not be spread evenly just because the org chart is even. If the bottleneck is product, operations, adoption, or users themselves, that is where the deepest AI support should go first. Help the constraint scale. Then look again.

What should leaders ask when AI coding accelerates delivery?

If AI coding is showing up in your organization, I would not start with "how much faster are developers?" I would ask a few harder questions.

Where does work wait after engineering gets faster? Are pull requests getting larger, waiting longer, or being approved with less real review? Are we seeing more churn, duplication, fragile changes, or production surprises? Which decisions are becoming more frequent, more complex, or more consequential? Are we creating more working software than the business can absorb? Are AI-generated prototypes changing real workflows, or just making better demos? Do we know which business metric should move if this work succeeds? Are we funding too many AI bets because each individual bet now looks cheaper?

I would also ask what kind of work your best people are being pulled into. If AI reduces toil, those people should move closer to judgment, customer insight, experimentation, and system-level decision-making. If they simply spend the saved time managing more work in process, you have not improved the system. You have just filled the freed capacity with more traffic.

The promise of AI coding is not that engineers type less. The promise is that scarce human judgment can move closer to the work that matters most. People should spend less time on toil and more time in the places where judgment, creativity, customer insight, and problem-solving matter. But even that move needs to be constraint-focused. Do not only move people into their genius zone in the easiest place to do it. Start where the system is constrained.

A note on the older testing-flow lesson

This is not the first time software organizations have run into this pattern. Years ago, the visible bottleneck was often late testing and painful stabilization. Teams could code faster than the organization could validate, harden, release, and learn. DevOps, CI, continuous delivery, better automated testing, and now AI testing assistants improved that dramatically.

But the bottleneck was not eliminated. It moved. The constraint is less often "can we test working software?" and more often "can we validate real value?" I wrote about the earlier version of this problem in Using Flow To Manage Testing Bottlenecks. The same flow logic applies here, but the center of gravity has moved from release readiness toward value realization.

What is the practical takeaway?

AI coding is a real breakthrough. I am not interested in downplaying it. But the organizations that get business impact from it will not be the ones that only measure local productivity. They will be the ones that notice where the bottleneck moved and redesign the system around that constraint.

Sometimes that means accelerating engineering. Sometimes it means slowing down the idea factory. Sometimes it means improving testing and validation. Sometimes it means helping business leaders make fewer, clearer, better-funded bets. Sometimes it means putting AI to work on adoption and value evidence rather than code.

More output into a constrained system does not create flow. It creates queues. AI just makes the lesson harder to ignore because the output arrives faster.

If AI helped your team build faster, the next question is not "how do we build even more?" It is "where did the bottleneck move?"

Originally published at https://yuvalyeret.com/blog/ai-coding-moved-the-bottleneck/.

From Personal Productivity To AI Operating-Model Change — A Conversation With Zoetis CTO Kumar Venugopal

Yuval Yeret — Wed, 20 May 2026 00:00:00 GMT

How to Scale AI from Personal Productivity to Operating Model Change

Most AI efforts I see are still living inside personal productivity. People are 20% faster with ChatGPT, Claude, or Copilot, and leaders are pointing at that productivity as evidence that the AI strategy is working. It is a fine starting point, but it is not where the real value lives. The deeper opportunity is to move past individual augmentation into workflow-level and operating-model-level change — redesigning how decisions get made, how work flows, what teams own, and what the organization should build versus buy. In a recent conversation on Scaling with Agility, Kumar Venugopal, CTO of Zoetis (the world's largest animal health company), walked me through what that move looks like from inside a Fortune 500 — including a concrete bet to compress an infrastructure workflow from 25 days to 2-3 days using agentic AI, a working prototype of a SaaS replacement built in days, and a clear-eyed view of where AI fluency actually comes from.

The throughline of the conversation is that AI stops being a tool rollout the moment you stop asking "which product should we buy?" and start asking "how do we want the business process to work in a year, and which parts of it should agents now own?" That is an operating-model question, not a procurement question. It pulls in design thinking, prompt framing, basic model mechanics, agile cycles, build-vs-buy assumptions, and a workforce conversation that is honestly more about job security than change resistance. This post is a deep dive on that shift, with Kumar's quotes carrying the weight of the inside view and my commentary connecting them to the operating-model patterns I see across the organizations I work with.

Why does this AI wave feel different?

I have learned to be skeptical of anyone who tells me a technology wave is fundamentally different from the last one, because the people saying that are usually trying to sell something. So I started the conversation with Kumar by asking the most boring version of the question on purpose: across 30 years in technology, from the .com era to today, does this AI wave actually feel different, or is it more of the same? His answer was unambiguous:

"It feels different. I can tell you that the .com era felt different than this one. It feels more systemic. It feels more revolutionary. It feels like it's going to impact not just technology, but technology as a means to transforming other areas… The internet became an add-on, e-commerce became an add-on. We don't shop in brick and mortar stores. We now shop online. But we were still shopping before. This one feels like tomorrow's version is completely different than yesterday's version." — Kumar Venugopal, CTO of Zoetis

The distinction I want to sit with there is add-on versus systemic. If a technology wave is an add-on, the leadership job is mostly procurement, integration, and adoption — you bolt the new capability onto how the business already works. If a technology wave is systemic, the leadership job is different in kind. You are no longer asking which vendor to pick. You are asking how the business itself should be redesigned so that the new capability is not just usable but load-bearing. Almost every AI program I see is still running on the add-on assumption, which is why most of them stall once the easy productivity wins are claimed. Kumar's framing matters because he is naming the shift from the inside, not from a conference stage.

Inside Zoetis, that systemic framing shows up everywhere from the science to the back office. Diagnostics, genetics, and almost every product line they sell to veterinarians is being affected, but Kumar was quick to redirect me away from the product angle and into the operating-model angle, which is where the harder organizational work actually is.

"It's not just about going out and buying a product, Salesforce AI, Agentforce. It's not just about getting the things bought, but it's really about how do we implement this? How do we get this to change our business process? And what are we trying to do with our workforce?" — Kumar

The sentence I would underline there is the second one: how do we get this to change our business process? That is the line between AI as a tool and AI as an operating-model question. Most organizations are still on the procurement side of that line. The ones that cross it are doing harder work that does not show up in vendor scorecards.

Why is personal productivity only the floor?

When Kumar described where Zoetis actually is today, he did not over-claim. Personal productivity is real and meaningful, but he was clear-eyed that it is not where the strategic value lives:

"It's personal productivity today. It's not ingrained into business processes. But if I'm looking at here's my five risks that I've come up with for this particular item, and then I go into the ChatGPT thinking model or any of the others, and I figure out that this is a prompt I want — it tells me what's an additional set of risks that I haven't thought about. It tends to help me think holistically. It helps me think in more detailed ways, and that's the decision making that I was talking about." — Kumar

That is a useful description of the early state because it does not pretend the gains are nothing. Knowledge workers are genuinely thinking more holistically because they have a second pair of eyes that does not get tired, does not have political loyalties, and is willing to stress-test their thinking on demand. Across Zoetis, Kumar estimates that productivity gain at roughly 20% per person — lawyers, scientists, finance, the works — and notes that it is not consistent across the organization but is broadly real. If you stop the AI story there, you have a respectable productivity initiative, and a lot of large enterprises are doing exactly that and calling it an AI strategy.

The reason it is not enough is that 20% per person, applied across an organization that still has the same decision rights, the same handoffs, the same WIP, and the same coordination overhead, does not compound into 20% better business outcomes. It often does not even compound into measurable function-level improvements, because individual productivity gains get absorbed into the queues, meetings, and coordination work that fill the calendar back up. To get past that ceiling, you have to redesign the workflow itself, not just hand people a better tool. That is where the next levels of AI integration come in.

How do organizations move from tool use to workflow change?

This is the part of the conversation where I offered Kumar a frame I have been using with leaders to make the progression concrete. It is my framing, not his — and I want to flag that explicitly because it is easy to blur the line in an interview write-up. He validated it with where Zoetis sits on each level, which is the useful part.

The first level is augmenting human thinking. Chatting with Claude, ChatGPT, or Copilot in an open prompt. This is where most organizations start and where most of the activity still lives. The second level is structured augmentation: instead of every person prompting from scratch each time, a team builds a defined environment around a recurring workflow. Contract review, medical writing, infrastructure requests, customer support escalation — the context is loaded, the prompts are templated, the guardrails are in place, and the human only adds what is genuinely new to the case in front of them. The third level is agent-assisted work, where the agent does meaningful chunks of the task on its own and the human reviews the output rather than producing it. Think Claude Code or Codex for software, but the same shape applies to other domains. The fourth level is fully agentic, where humans are in the loop primarily to coach the agents and fine-tune the system, not to produce the work.

Kumar placed Zoetis honestly across the levels. Level 1 is "very high" — broad adoption, the 20% productivity gain, mostly consistent. Level 2 has "shown good results" in places like a medical-writing department that has moved from 20% individual productivity to 40-50% departmental productivity because the workflow itself is now AI-enabled rather than each writer prompting in isolation. Levels 3 and 4 are still early. The honesty there matters: most CTOs I talk to imply they are further along the curve than they actually are, which makes it harder for their peers to calibrate where they are.

What does a concrete agentic workflow bet look like?

When I pushed Kumar for a concrete example of where Zoetis is making the level 3-4 jump, he went somewhere I did not expect. Most AI demos lean on customer-facing examples because they are more photogenic. Kumar went to internal infrastructure, which I think is the more honest place to look:

"I believe we can have a very modern AI-first infrastructure to do server provisioning, cloud provisioning, things that are anyway templated, but also to do the identity access management, the firewall access management, to do all the 25, 30, 40 tasks that happen when you do that. I believe all of that is agentic capable now." — Kumar

The current workflow to provision the infrastructure behind a new project at Zoetis takes 25 to 26 days. Kumar's stated target is to compress that to two to three days using agentic AI, with humans still in the loop for cybersecurity and the genuinely critical decisions. That is not "AI will transform everything" rhetoric. That is a measurable bet against a specific workflow with a known cycle time, and it tells me more about how Kumar thinks than any AI vision statement would.

The architecture he sketched is worth describing because it is a reusable pattern. He sees three agents working in sequence, with human review between each. The first is a design agent that takes the business intent and produces the infrastructure blueprint — what services are needed, which Azure components fit, what the shape of the integration should look like. A human reviews that blueprint, which is the part most teams want to keep human because the cost of getting it wrong is high. The second is a code agent — Codex or Claude Code style — that takes the approved blueprint and generates the actual infrastructure-as-code from the templated patterns the platform team already maintains. The third is an execution agent that actually runs the provisioning, again with human checkpoints at the steps that matter.

When Kumar described that pattern, I noticed it mirrors something product teams have been learning the hard way over the last 18 months. The teams that get good results from AI coding agents are not the ones telling Cursor "build me an app." They are the ones who write specs first — what people are calling spec-driven development — and then let the agent execute against a tight, well-shaped intent. The same shift applies here. Infrastructure-as-code is not the bottleneck. The templated runbooks are not the bottleneck. The bottleneck is intent, captured well enough that an agent can act on it without producing the wrong thing very quickly. That is a discovery skill and a design skill, and it is the same skill product organizations have been building for years. AI does not eliminate it. AI raises the leverage on it.

How does AI change build-vs-buy decisions?

The infrastructure conversation naturally pulled us into a different topic: what happens to the build-versus-buy default once an organization can stand up working software in days rather than months. Kumar went further on this than I expected:

"Could we get rid of some basic SaaS applications, subscription-based, that we no longer need? Could we then use that same approach to build out that software, implement it, get it out? Monday.com is an example. For me, that's a very generic piece of software. We could literally develop that. Why do we need to pay $30 a user per month per license? And as a corporate, you have hundreds of those." — Kumar

He was not theorizing. He told me they actually built a working Monday.com prototype "in a span of a couple of days," prompts-only, no traditional developer effort. It has bugs, it needs integration work, and it is not a finished product. But the existence of that prototype is the signal. The gap between "buy generic SaaS" and "build it ourselves" is closing fast for the long tail of internal applications where the differentiated value of the vendor is honestly thin.

My take, for what it is worth: I would not run a full migration off that prototype, and I would not encourage a CIO to use this as a budget-cutting bludgeon either. The total cost of ownership math for SaaS includes a lot of things that do not show up in the $30-per-seat line — security review, support, vendor accountability when something breaks at 2am, integration upkeep, compliance posture. But Kumar is right that the question itself is shifting. It is no longer "which vendor should we buy?" by default. It is "what should we buy, what should we build, and what can our business people now safely shape with AI-enabled help?" The set of internal applications that pass the "obvious buy" test is genuinely smaller than it was 18 months ago. That deserves to be in every enterprise architect's decision-making frame.

This is also where things get interesting for the people Kumar called "business analysts on the IT side." He pointed out that business people are starting to use vibe coding to build working prototypes — not because they want to replace developers, but because the friction to express their intent in working software has collapsed. The Power Apps generation of citizen-developer initiatives never really worked at scale, and Kumar was direct about why: "Power Apps is really still a technology tool and still behaves very much like a technology tool. If you want to integrate it to anything, all of a sudden you need much more sophisticated skills than just building a couple of forms." AI is different because it can offer the complete set of services — integration, data, calls to external systems — without forcing the business user to learn another platform's idioms. That shifts what business analysts can do, and it shifts what they should be expected to do.

What kind of AI fluency do people actually need?

The part of Kumar's answer that I think is most under-discussed in the broader AI conversation is what AI fluency actually requires. The default industry pitch is that prompt engineering is the skill people need to learn. Kumar's answer is more demanding and, I think, more correct:

"I found that design thinking helps a lot, where you're not thinking in the tactics, you're thinking in the overall structure, you're thinking in the design language. Of course, prompt engineering is a critical skill set. It sounds easy. I'm just going to ask the LLM, but how you ask the intent — that's very difficult to frame correctly. It's very difficult to put it the most optimal way. The third that I've told people all the time is to learn how LLMs work even at a middle school math level." — Kumar

Three pillars, in his order: design thinking, prompt framing, and enough model mechanics to know what these systems are actually doing under the hood. I like that list because it keeps AI fluency out of the magic-tool bucket. Two of the three skills are not new — they are skills good product and engineering people have always needed. What is new is the third one, the model-mechanics layer. Kumar was very specific that he means tokenization, neural network basics, the self-attention paper, softmax, vectors — middle-school-math depth, not PhD depth, but real enough that people stop anthropomorphizing the model and start asking it the right kind of question.

I want to add one observation Kumar made that I think gets glossed over in most coverage of AI adoption. When I asked him about resistance and whether business users were pushing back on the design-thinking-plus-model-mechanics curriculum, his answer reframed the problem:

"It's not like the resistance comes from the fact that I have to change. It comes from the fact that will I have a job tomorrow? If I'm able to get rid of majority of my redlining work as a lawyer, what am I going to do? That's a fear that comes from within. But at least the interest is there." — Kumar

That is a different problem than the usual change-management framing suggests. The standard playbook treats resistance as inertia or as a deficit of training. Kumar is naming it as a credible career fear. The right intervention for a fear about future employment is not another training module on prompt engineering. It is a credible story about what the role looks like on the other side of the change, and a willingness from leadership to actually walk into that conversation. Without that, the activity continues but the energy behind it gets thinner.

What changes for agile, product, and cadence?

There is a version of the AI-and-agile conversation where the punchline is "AI killed agile" or "ceremonies are obsolete." Kumar was direct that this is not his read at all, and his reasoning is more interesting than the headline would suggest. Cycles compress dramatically, but the discipline of breaking work into shaped, testable units becomes more important, not less:

"We are doubling down on Agile, and we are trying to be not just working on developer productivity, but even the agentic approach has to be built with a minimum viable product approach with proper user stories. You feed those into your prompts. You build step by step, because even AI cannot build sophisticated tools overnight with just one prompt." — Kumar

What changes is the cadence. Sprints that used to take two weeks can compress into hourly or even minute-by-minute regeneration cycles. The GxP validation work that took six to eight weeks in their pharma environment is collapsing into a single week. PI planning, story shaping, test-script generation against the same stories, validation — the pieces of the lifecycle remain, but the time between them shrinks. The risk in that is obvious: if you do not maintain the discipline of stating clear intent, breaking it into shaped pieces, and validating against the intent, the speed becomes a way to ship the wrong thing faster. The agile lesson does not go away. It gets harder to ignore.

The other half of the cadence shift is who participates in it. Business people, in Kumar's words, are still in the mindset of "we say what we want and it magically appears, and building is the role of technology." That assumption is the constraint, not the technology. Getting business people to step into "I need to think about how I build it" is a multi-year cultural change, and it is the one Kumar called out as the unfinished part of the Zoetis story.

What is the operating-model question underneath all of it?

Kumar's closing advice to other leaders was three steps: educate first, be open about how roles will change, and show people what is in it for them personally. I would add a fourth step that runs underneath all three: get specific about which business processes you are actually trying to change, and which parts of the operating model have to move to support that change.

That is the operating-model question, and it is the one most AI programs avoid because it is harder than buying tools. It pulls in funding models, decision rights, team structures, the build-vs-buy default, what counts as a job in a year, and how the organization measures impact. The reason Kumar's framing matters is that he is treating those questions as the actual work, not as the residue that gets sorted out after the technology is deployed. Most AI programs do the reverse, and most AI programs are getting the results that approach earns.

The useful AI conversation is moving beyond personal productivity. The real question is not which tools to buy. It is where AI changes the way the organization makes decisions, designs workflows, and moves work through the system. That is where AI stops being a tool rollout and starts becoming an operating-model conversation.

Watch the conversation

This article is based on my Scaling with Agility conversation with Kumar Venugopal, CTO of Zoetis. The full episode runs about 39 minutes and goes deeper on the agentic infrastructure example, the build-vs-buy threshold, and the workforce conversation.

If your AI strategy still reads like a procurement plan, you are working on the wrong question. The real work is operating-model change — and it starts the moment you ask which business process you actually want to be different in a year.

Originally published at https://yuvalyeret.com/blog/from-personal-productivity-to-ai-operating-model-change/.

Why Your AI Effort Has Activity But Not Impact

Yuval Yeret — Wed, 20 May 2026 00:00:00 GMT

How to Shift AI Initiatives from Activity and Output to Business Impact

Most organizations do not start their AI journey with impact. They start with activity: tool access, training, pilots, hackathons, champions, experiments. That is useful, but it is not the same as value. Some then move to output, especially in engineering, where AI coding agents can help teams produce more software faster. But if engineering is not the real constraint in the business, more engineering output can simply create more work waiting somewhere else.

The better question is not "where can we use AI?" It is "where is the business actually constrained, and how could AI improve flow through that constraint?" AI impact comes from improving the part of the system that limits business results - not from celebrating adoption metrics or optimizing the easiest team to optimize.

Are you doing AI, producing output, or creating impact?

When I look at an AI effort, the first question I want to ask is not which model you are using or which tools you have rolled out. It is simpler than that: where is your AI effort right now? Is it mostly AI theater, is it producing more output, or is it changing business impact? I do not ask that as a rhetorical swipe at people doing AI work. Most organizations start in a perfectly reasonable place: they give people access to AI tools, run AI literacy training, sponsor hackathons, start pilots, and create experiments. There is motion. There are dashboards. There are internal stories. Leaders can point to all of that activity and say, "We are doing AI."

And they are. But that does not mean they are seeing value yet. There are probably spots where value is emerging: somebody is saving time on a document, somebody is using AI to think through a thorny problem, a team is experimenting with a coding assistant, or a function is trying to automate some repetitive work. That is a good start. I am not dismissing it. But it is not the same as AI impact at scale.

This is where a lot of AI efforts start to get comfortable in the wrong way. Activity is visible, easy to count, and reassuring to talk about. You can count how many people have access to the tools, how many people have been through training, how many people attended the hackathon, and how many use cases are in the funnel. Those numbers are not useless, but they are also not enough. They tell you that the organization is moving around AI. They do not tell you whether the business is moving because of AI.

Why does AI activity feel like progress?

AI activity is especially comfortable when the original reason for doing AI was FOMO. The board is asking about AI. The CEO is asking about AI. Competitors are talking about AI. Every conference has AI in the title, and every vendor is repositioning themselves around AI. People feel like they should be doing something, so they do something.

Again, I am not mocking that. In a fast-moving environment, doing nothing is not a great strategy either. The problem is what happens when "doing something" becomes the goal. At that point, the organization starts celebrating the activity itself. The training happened, the pilots launched, the tools were enabled, the dashboard looks active, the AI council met, the town hall had a demo, and someone shared a prompt library. The organization can now check the box that says AI is underway.

But over time, the questions get harder. The conversation shifts from "are we doing AI?" to "what are we getting back?" Leaders start asking what changed in how the business works, whether customers are seeing anything different, whether decisions are moving faster, whether teams are less overloaded, and whether the organization is actually reducing waste, delay, rework, or risk. These are uncomfortable questions because they expose whether the AI effort has crossed from activity into impact. If the answer is not clear, trust starts to erode.

There is another problem, too. If the AI effort is mostly activity, people in the trenches may not understand the vision for how AI is supposed to change the work. They hear that AI is important, that everyone should use it, and that productivity matters. But they may also quietly wonder whether they are helping automate themselves away. That fear is not irrational. If leaders cannot explain where AI fits, what kind of work it should improve, what boundaries matter, and how the organization expects people to participate safely, people will fill in the blanks themselves.

Some people will experiment. Some will comply. Some will avoid the whole thing. Some may even sabotage the effort, or at least refuse to lean into it. That is why AI theater is not only a value problem. It is also a trust problem. When people see a lot of activity around AI but not a clear connection to meaningful work, cost, value, or strategy, support for AI improvements starts to decline. The organization may still be doing AI, but the energy behind it gets thinner.

Why can more AI output still miss the business result?

The next level after activity is output. This is where AI starts to create visible improvement in a specific area. There are real deliverables, real applications, and teams seeing higher throughput. The most obvious example right now is software engineering.

That makes sense. AI coding agents and coding harnesses were trained on a lot of open source code. Engineering teams are often early adopters of new technology. Developers are used to tooling, and the feedback loop is relatively tight: ask the agent to do something, inspect the result, run tests, adjust, and keep going. So we are seeing engineering teams deliver more. In some organizations, engineers are not doing as much manual coding anymore. They are working through agents. In some places, they are even being asked to only code through agents, or at least to use agents as the default path.

That is a real shift. It is not just theater. But more output is still not the same as impact. The key question is whether that output changes a business result. You might see more code, more tickets closed, more artifacts created, and more work moving through one function. The question is whether revenue per person improves, customers adopt more quickly, retention gets better, learning cycles get shorter, or the broader organization becomes more effective.

Sometimes the answer is yes. Often it is not obvious yet. The reason is simple: engineering might not be the bottleneck. It might not have been the bottleneck to begin with. If engineering was already not the constraint in the system, making engineering faster may simply create more output that waits somewhere else. It waits for product discovery, prioritization, security review, deployment, enablement, customer success, sales, legal, or leadership to decide what matters. The local metric improves, but the business does not move much faster. That is not an AI failure. That is a system failure.

What happens when AI makes engineering hungry?

There is also the upstream version of the same problem. Maybe the bottleneck is not downstream of engineering. Maybe it is upstream. Maybe the organization is not able to feed a very hungry AI-augmented engineering organization with enough valuable, validated product ideas.

That can feel like feeding a set of teenagers who do sports all day. You spend all of your time going to Costco or Sam's Club, buying tons of protein and food, and it is never enough. That is what some product organizations are starting to feel like. Engineering capacity goes up. The ability to code goes up. The appetite for well-shaped work goes up. But the organization's ability to discover, validate, prioritize, frame, and steer valuable work does not keep up.

Then people look around and say, "Why are we not seeing more impact? Engineering is moving faster." Yes, engineering is moving faster. But the whole system is not. Sometimes more engineering output even makes life harder for everyone else. More features need to be reviewed, enabled, supported, explained to customer-facing teams, and absorbed by internal groups.

That is the classic danger of local optimization. One part of the system improves, but the end-to-end flow does not. In some cases, the local improvement is neutral to the whole. In other cases, it is actually detrimental. This is why I am cautious when people talk about AI transformation mostly through the lens of individual productivity or functional productivity. Those improvements can be useful. They can also be distractions if they do not connect to the constraint that actually limits business impact.

Where is the business actually constrained?

The more useful question is not "where can we use AI?" That question is too broad and too tool-centered. You can use AI almost anywhere, but that does not mean every use deserves the same attention, risk, funding, or organizational energy. The better question is where the business is actually constrained.

That pushes the conversation into more useful territory. What is limiting flow through the system? Where does work wait? Where do decisions get stuck? Where are customers leaking out? Where are opportunities not turning into revenue? Where are experts overloaded? Where does coordination across functions slow everything down? Where are we generating output that does not turn into outcomes? Once you ask those questions, the AI conversation gets much more practical.

Maybe the bottleneck is still inside product and engineering. Maybe the issue is that you cannot discover valuable ideas fast enough, validate them early enough, or connect engineering work to customer behavior quickly enough. Maybe you are building things, but learning too slowly whether they matter. In that case, AI impact might mean improving discovery, synthesis, prototyping, customer research, experimentation, or product decision quality. It might mean helping product teams feed engineering with better-shaped opportunities, not just more tickets.

But maybe the bottleneck is not product anymore. Maybe it is customer success. Customers start using the product, but they do not stick. The leaky bucket is not because engineering cannot ship; it is because onboarding is weak, customer signals are not being noticed, adoption friction is not being addressed, or the organization does not have the right process for learning from customers after the sale.

Maybe the bottleneck is partner onboarding, if your business model depends on channels and partners take too long to become productive. Maybe it is sales, where marketing can generate interest but the team struggles to qualify, explain, or convert the right opportunities. Maybe it is leadership decision flow: too much work in flight, priorities shifting, and every meaningful cross-functional decision climbing the hierarchy. Work does not slow down because people are lazy. It slows down because the operating model makes decisions expensive. The point is not that one of these is always the answer. The point is that AI impact depends on finding the answer in your system.

Why not optimize where AI is easiest?

The trap is that organizations tend to apply AI where AI is easiest to apply. That is understandable. Easy wins are attractive. They create momentum, show people what is possible, reduce fear, and give the organization examples. But if you stop there, you can end up improving the part of the system that was already strong enough.

This is where the theory of constraints is useful. When there is a bottleneck, you subordinate the system to it. You do not keep optimizing non-bottlenecks and hope the whole system improves. You identify the constraint, exploit it, elevate it, and align the rest of the system around it. The same logic applies to AI. If engineering throughput is already amazing, maybe the next move is not to make engineering even faster. Maybe the next move is to ask how some of that capability can help the real constraint.

That is culturally hard. It cuts across silos and asks people to work outside the area where they are most comfortable. It may mean telling a successful team, "You are doing great things with AI, but improving your own output even more does not help us much right now. We need some of your expertise somewhere else in the business." That is not how many organizations are wired. Most organizations fund departments, measure departments, reward departments, and optimize departments. Then they are surprised when the end-to-end flow suffers.

AI exposes that problem because it can create local acceleration very quickly. If the rest of the system is not ready, the acceleration does not disappear. It turns into queues, coordination load, review burden, adoption friction, and frustration.

What product lesson applies to AI transformation?

Inside the product development world, we have been dealing with this problem for a long time. Output is not enough. Working software is not enough. Shipping more features is not enough. The product group needs to discover valuable ideas, test risky assumptions, build the right things, validate that they actually work, and keep adjusting until customer behavior and business results change. That is one path to AI impact: use AI to improve the product lifecycle end to end, not just the coding part.

But the broader path is bigger than product. An AI-native organization is not just an organization with AI-enabled engineers. It is an organization that can use AI to improve how the whole company works. That means looking at your key business processes: how you create demand, convert it, onboard customers, retain them, learn from the market, make investment decisions, and develop the organization itself. Then ask where AI can improve flow through the part that actually constrains impact.

That may involve automation, decision support, synthesis, better handoffs, faster feedback, or helping people notice patterns they currently miss. It may involve changing the shape of the work, not just making the existing work faster. This is why AI transformation is not only a technology program. It is an operating-model question.

What should leaders look at first?

If you are leading an AI effort, I would start with a simple diagnostic. First, look at activity: what AI activity is happening, who has access, who is trained, what experiments are running, what communities or enablement structures exist, and what the level of curiosity and participation looks like. Then look at output: where AI is creating more throughput, which teams are producing more, which workflows are faster, which artifacts are cheaper to create, and which cycle times are improving locally.

Then look at impact. Ask what business outcome changed, which constraint moved, which queue got shorter, which customer behavior shifted, which decision got better, which costly delay disappeared, and which revenue, retention, quality, risk, or capacity signal improved. If you can answer the first two sets of questions but not the third, you probably have an activity-to-impact gap.

That gap does not mean the AI work is useless. It means the AI work needs stronger steering. The leadership move is to connect the AI portfolio to the business constraint. Not every AI use case deserves the same attention. Not every experiment should scale. Not every local productivity gain should become a strategic program. Some AI activity is just literacy. Some is useful personal productivity. Some is local output improvement. A smaller set should be aimed directly at the constraint that limits business results. That smaller set is where executive attention should go.

Watch the episode

This article is based on the solo podcast episode where I walked through the activity -> output -> impact distinction and why the constraint matters more than the easiest AI win.

What is the practical goal?

The goal is not more AI usage, more AI training, more pilots, or even more output in one part of the organization. The goal is AI impact. And AI impact means the business works better because AI helped improve flow through something that mattered. A customer gets value sooner, a team learns faster, a decision improves, a bottleneck moves, or a costly delay shrinks. The organization becomes better at turning ideas, effort, and technology into outcomes.

That is a higher bar than "we are doing AI." It is also a more useful bar. Because once you frame the work this way, the AI conversation changes. You stop asking only what tools people have. You stop obsessing over adoption numbers as if they are the destination. You stop assuming the easiest AI win is the most important one. You start asking where the system is stuck. And that is often where the real opportunity is.

If your AI effort has lots of activity and even more output, but the business still is not moving faster, do not start by blaming the tools or the people. Look for the constraint.

Originally published at https://yuvalyeret.com/blog/your-ai-problem-might-not-be-an-ai-problem/.

Spec-Driven Development Isn't Waterfall Unless You're Using It That Way

Yuval Yeret — Mon, 18 May 2026 00:00:00 GMT

Last summer, while I was vibe-coding my own scorecard app, I kept running into dead ends. Not dramatic ones — the annoying kind. I would get something working, then realize the path was wrong. Or the behavior was close but not quite right. Or I had built a capability that looked useful in isolation but did not actually help the overall product move forward.

So I started thinking more up front. I used plan mode more. And eventually I started using spec-driven development more formally. Which raises the obvious question: did I just give up agility and go back to waterfall?

I do not think so. But I do think spec-driven development can very easily become waterfall if you use it the wrong way — and that's worth unpacking, because the trap is subtle.

The old reflex shows up again

The industry has been here before.

Complexity rises, surprises pile up, delivery gets late, and people get frustrated. The natural reaction is predictable: "Next time, let's figure everything out up front." That instinct is understandable. It is also where a lot of waterfall-style phase-gate thinking came from.

When work feels uncertain, leaders try to reduce surprise by adding more up-front analysis, more review gates, more detailed plans, and more confidence theater. But when the uncertainty is about what is useful, feasible, desirable, safe, or valuable, writing more up front does not eliminate it. You can spec it all day and still get surprised. That was true with human teams, and it is just as true with AI coding agents.

AI changes the loop, not the need for learning

AI does change something important. A coding agent can burn down some feasibility risk on its own. If you give it a clear enough target, enough context, and a good enough definition of done, it can try an approach, hit a problem, inspect the error, adjust, and try again. That agentic loop is genuinely useful.

It means some of the "how do we make this work?" learning can happen inside the coding loop. In a way, it feels a little like the interaction between a product owner and a Scrum team: you describe what you are trying to achieve, the team works through implementation reality, and it comes back when it learns something important, hits a constraint, or needs a decision. AI coding agents are not Scrum teams, but they can sense and respond to implementation surprises in a similar way.

Spec-driven development is designed for flow, not waterfall. The spec is meant to be a concrete target function for an adaptive agentic loop. The danger is when we treat the spec as a way to remove the need for adaptation — especially when we combine it with larger batch sizes. Trying to figure out an entire spec up front for a month's worth of human-agent interaction is, of course, ill-advised when there's any chance of surprises along the way.

Back to the essence of Spec-driven Development

Spec-driven development helps because it forces me to slow down just enough to think through and specify:

What am I actually trying to accomplish?
What should this enable?
What constraints matter?
What does good look like?
What assumptions am I making?
Where do I need the agent to decide, and where do I need it to ask?

This gives the coding agent better context and reduces avoidable churn. But the more I leaned on it, the more it revealed two traps.

Trap 1: More spec is not always better

There is a point of diminishing returns on specification, and with AI coding agents that point can show up pretty early. At first, better intent helps. Clearer outcomes help. Better constraints, concrete examples, acceptance criteria, a rough plan — all of it helps. But eventually, more specification stops creating better output. Sometimes it just burns time and tokens. Sometimes it constrains the agent so tightly that it cannot usefully respond to what it learns while implementing. Sometimes it makes you feel safer without reducing the real risk.

This is the same dynamic we've always had with human coders. There is a difference between giving a good developer useful context and telling them how to code every step — the first creates alignment, the second wastes talent. AI coding agents are not people, but the same economic idea applies: you want enough guardrails for agency, not so many that you remove the agent's ability to adapt.

Trap 2: Working software is not the same as a valuable outcome

The second trap is more important: even when the AI builds exactly what you asked for, you can still miss the outcome. That should sound familiar, because agile teams learned this the hard way too. Working software matters, but a team can produce working software that customers do not use, do not trust, do not understand, or do not care about.

AI coding agents have the same problem. They can help you create working software, but they cannot magically know whether your customers really want it, whether the workflow will change, whether your internal users will trust the output, or whether the thing you built will move a leading indicator that matters. Unless the learning loop includes real customer behavior, real user feedback, real operational signal, or real business impact, the agent is still making assumptions — possibly very efficient assumptions, but assumptions nonetheless.

That is where spec-driven development has to stay connected to product discovery. Otherwise, you just get better at building the wrong thing.

So is spec-driven development waterfall?

It depends on how you use it. A fully flushed-out spec with a horizon measured in minutes or hours — or in X tokens — makes total sense. The problem is what I'm starting to see in the trenches: teams using specs as a team or group collaboration mechanism, with a horizon of days or weeks.

Don't get me wrong — I see tons of value in some form of spec-driven behavior at that horizon and altitude. But it needs to be a higher-altitude spec. It shouldn't try to anticipate everything up front. At one of my clients, for example, we are using an outcome-oriented, product-led version of spec-driven development at the portfolio level. The specs we aim to create there are only remote cousins of the specs that make sense during a coding session. There's still a structured human-agent collaboration, and it's genuinely useful — it helps everyone orient to outcomes, think about leap-of-faith assumptions, decide whether discovery is needed, and figure out the learning plan. But the "plan" stage of SDD at that level produces a list of potential specs, features, or experiments, not detailed stories and tasks.

A better way to use spec-driven development

Effective spec-driven development is not "big planning up front." It is enough thinking up front to make learning cheaper — appropriate to the altitude and horizon you're working at, and focused on outcomes, assumptions, and leading indicators. It also means treating the inventory and flow of specs as something to visualize, manage, measure, and improve over time — not just through spec and implement, but end to end, all the way to outcomes and learning.

Here's what that looks like in practice.

1. Specify outcomes, not just outputs

Do not only describe the feature, screen, workflow, or capability. Describe what you want it to make possible. What behavior should change? What decision should get easier? What painful work should get lighter? What customer or user outcome should improve, and what business signal would tell you this actually mattered? If the spec only describes the output, the agent can succeed while the product fails.

2. Flush out assumptions, not just requirements

Requirements say what the thing should do. Assumptions say what must be true for the thing to matter. That distinction is critical, and it's easy to lose. Use the coding agent to help surface the assumptions hiding in the work — about users, workflow, data, the business, usability, adoption, technical feasibility, and risk — and then decide which ones need learning before, during, or after implementation. The goal is not to remove all assumptions. The goal is to stop hiding them inside the spec.

3. Decide whether this work needs discovery

Not every change needs deep discovery. Some work is obvious enough, some is mostly technical cleanup, and some is a small improvement with low downside. Just build it. But some work is a bet, and for bets the spec should include the learning approach. Can we test the idea before building it? Can we prototype, or run a fake-door test, or put a thin slice in front of real users? Can we use leading indicators to steer, or learn from support tickets, sales calls, workflow data, or customer behavior? If the work needs discovery and the spec ignores that, you are setting up a beautiful implementation of an unvalidated bet.

4. Think about options

AI makes it tempting to try everything — spin up five agents, build five approaches, pick the best. Sometimes that is smart. Set-based design can make sense when options are cheap enough and the uncertainty is high enough. But it still has a cost. Even if tokens are cheap, management attention is not, and reviewing five approaches, integrating the best ideas, managing conflicts, and deciding what to keep is real work. Sometimes one focused approach with a fast feedback point is better; sometimes multiple options are worth it. The spec should make that choice explicit. Don't unleash a swarm because it sounds cool — use options when the economics make sense.

5. Task the agent with the right feedback points

The coding agent should not disappear into a cave and come back with a finished product if the risk profile does not support that. Ask it to task out the work with appropriate checkpoints. For low-risk work, that may be a straightforward build. For higher-risk work, it may mean validating the architecture before implementation, producing a first thin slice, stopping after a spike, asking for a product decision before continuing, creating testable acceptance criteria, or surfacing tradeoffs rather than guessing. The point is not to micromanage the agent. The point is to match autonomy to risk.

6. Follow through after working software

This is the step many people skip. Once the agent builds the thing, the real product work is not done. Put it in front of real users and watch what happens. Measure something that matters. Listen for confusion, look for workarounds, and ask the harder questions: did the workflow actually change? Would the user miss this if it disappeared? Did the business signal move? This is where spec-driven development either becomes part of an agile learning loop or degenerates into a more disciplined feature factory.

AI coding agents are not product agents

There is a reason we call them AI coding agents — not product agents, not outcome agents, not judgment agents. At least not yet.

They are getting very good at taking context, constraints, and intent and turning them into working software. That is a big deal. But we still have to provide the taste, judgment, context, and connection to real outcomes. We decide what is worth building. We understand the users and customers, notice the friction, and define what good means. We design the learning loop, and we make the tradeoffs when the agent discovers that reality is messier than the spec.

Spec-driven development is powerful when it helps us do that work. It becomes waterfall when it helps us avoid it. That is the whole difference. The point is not to write bigger specs — it is to write specs that create better steering.

If AI has made your team faster at building, the next question is whether you have become better at choosing, validating, and learning. That is where the value is.

Originally published at https://yuvalyeret.com/blog/spec-driven-development-isnt-waterfall-unless-youre-using-it-that-way/.

"Human in the Loop" is Too Small: How Agentic AI Unlocks Human Agency

Yuval Yeret — Wed, 06 May 2026 00:00:00 GMT

"Human in the loop" is a phrase we hear constantly in the AI space. It's meant to be reassuring—reminding us that humans are still in control, still the ultimate decision-makers.

But after a recent conversation with a leader during an AI coaching sprint, I've realized that "human in the loop" is actually too small a vision. The real shift isn't about staying in the loop; it's about humans moving up a level.

From Chatting to Unleashing

This leader was finishing a sprint where they had undergone a significant transformation. They started by simply chatting with AI and using tools like Claude Code for very specific, isolated tasks.

By the end, they were unleashing agentic AI on several complex problems, scaling their context, and integrating an AI "second brain."

It was a massive leap in capability. But it also brought up a deep, almost philosophical question:

"If the AI is doing so much more... what's remaining for me as a leader to do?"

Elevating to Strategic Loops

The answer isn't that the leader becomes irrelevant. It's that they ascend.

We talked about elevating to more strategic loops and interactions:

Shaping the work and the workflow: Defining the "what" and the "how" at a higher level of abstraction.
Designing the agents and the guardrails: Creating the systems that the AI operates within.
Orchestrating and curating: Aligning rules, values, and skills across their team and the entire company.
Setting the next decision: Moving from execution to high-level direction.

This isn't just about efficiency; it's about having the time and opportunity to achieve a higher level of mastery in their field.

The New Agency Equation

As I reflected on this, I kept coming back to Dan Pink’s classic Autonomy, Mastery, and Purpose model for human drive.

In the age of Agentic AI, I’d probably swap Autonomy for Agency.

And Mastery? It starts to look like a weird new craft: getting good at creating AI agents that make your old work disappear.

You don't do this to become irrelevant. You do it so you can take on bigger problems and opportunities that were previously out of reach.

An Exercise for Your Team (and Your Agents)

Years ago, I created an exercise called the Autonomy Mastery Purpose Retrospective. It feels incredibly relevant again as we think about AI adoption.

You can use it to explore how AI is impacting your organization by asking three key questions:

Agency: How is what we're doing with AI contributing to human agency? In what ways are we standing in the way of it?
Mastery: What are we doing to create the conditions for people to pursue mastery? Where are we keeping people fixed where they are—or even causing them to regress in their skills?
Purpose: Are we creating a high-purpose environment? Or are we "growing people like mushrooms"—feeding them crap and keeping them in the dark?

And for a modern twist: You can even run this exercise to explore what level of Agency, pursuit of Mastery, and connection to Purpose you are giving your AI Agents.

If you want to run the full version of this exercise, you might find this detailed write-up useful: Getting Real About Your Values: The Values Retrospective

Transforming your leadership and organizational operating system for the agentic era is exactly what I help with. Explore AI Transformation advisory or book a Clarity Call to discuss how to elevate your team.

Originally published at https://yuvalyeret.com/blog/agentic-ai-unlocks-human-agency/.

What's In The Way of Your AI Traction?

Yuval Yeret — Thu, 09 Apr 2026 00:00:00 GMT

Building With AI - Dream vs Reality

Have you tried coding with AI yet? It can be an exhilarating experience. It SHOULD be an even greater experience when you're at work. The tools are paid for. There are peers who are learning and exploring with you. Maybe there's even AI training and enablement in place. But what I hear from more and more practitioners and their leaders is disappointment and frustration at what AI coding inside the organization REALLY feels like. What's going on? What's making it so hard to get AI traction in an organizational context? And what could you do to unleash the potential of "Building with AI" inside your company?

Give Them AI And Watch Them Build

"We've given everyone Claude Code/Cowork (or Codex, Or Gemini CLI). Now we're waiting for the magic to emerge."

That's a common story I hear from leaders who are trying to figure out how to take AI from "Literacy" and "Activity" to "Strategy" and "Impact"

The thinking is that once smart people have access to the transformational capabilities of GenAI, especially the latest versions of it that can go beyond augmenting your thinking to doing some actual work on its own, they will start to imagine what's possible and find high impact use cases.

The Reality of Give Them AI

There are a couple of problems these leaders are currently seeing, though:

Finding these use cases requires curiosity, tinkering, courage. These attributes aren't evenly distributed across the company.
Even people who are curious risk-takers seem to be afraid to experiment
Many people seem like they're deer in the headlights stuck between the fear of being replaced by AI and the fear of using AI to cut the branch they're sitting on (sorry for the metaphor mixup - AI would never go for that ;-)
When people don't know what to focus on, they might come up with AI use cases that don't move the needle. Worst case scenario they make an improvement that actually piles more work on other people. (For example - generating more code and features, when the bottleneck is training your customers)
High impact often requires coordination between people, since it spans across functions.

None of these are AI problems. They are all human nature and company culture problems.

AI is just very good at exposing how effective you really are as an organization at developing/evolving.

The Reality of Project Work Before AI

A lot of leaders were already feeling the pain before AI:

People are buried in their day to day responsibilities - and have little capacity for extra "projects"
Too many of these projects who all hit the same group of people - So projects are often late, despite everyone working hard.
Project management is focused on activity - and even "successful projects" often don't deliver an impact.
People are told exactly what to do - Sponsors ask for a specific solution - which has this tendency to extinguish creativity and exploration, with the side effect that sometimes the predefined solution isn't the right approach.

What Happens When You Throw AI Into The Mix

In order to deliver AI impact we need to improve our ability to deliver value with projects.

Yes, by giving people AI there's the potential that they'll improve their personal productivity.

But most interesting organizational "alpha" will require more than individual productivity improvement.

It requires a strong capability for the organization to develop/evolve itself.

Otherwise your AI projects/initiatives will hit the same roadblocks. Lots of activity. Little Traction. Little Impact.

A Better Approach To Projects

When you look at companies that manage to improve their project traction and impact, you often see several major shifts:

From Activity to Flow - From Starting to Focusing and Finishing
From Scope to Outcomes - Instead of fixing the solution, aligning around the intent and maintaining flexibility about what it will take to achieve it.
From Following a detailed plan to adaptive planning - Instead of fully planning out exactly what everyone needs to do when, planning a little bit, doing it, sensing and adjusting. continuously. until achieving the goal.

These shifts come from the product/software development world where we've been tackling complex projects with high degress of uncertainty on what to build, how to build it, and whether it will even be useful, forever.

Product/software development organizations have been shifting from project thinking to flow and product thinking. They've been leveraging more focused, iterative and adaptive ways of working (dare I say more agile?)

Treat Your AI Projects as Products

If you think about your AI projects - they look a lot like this. Even if they're not about your product, and don't live inside your product/engineering/IT organization - they are still rife with uncertainty and complexity about Why, What and How.

Which is why when you look at case studies of companies who are getting better traction with their AI investments, you can see flow and product thinking at play:

Focusing on the investments/initiatives that really matter.
Acknowledging investments are bets and emphasizing learning/discovery before doubling down
Assigning directly responsible individuals who own an outcome - and have flexibility about the solution
Steering based on traction on leading indicators and early feedback loops
Creating empowered pods that can run with an idea with as little friction and dependencies as possible.

AI Vibe Coding is useless and frustrating when its bound by the constraints of the wrong ecosystem. It is exhilirating and high-impact when unleashed by an organizational operating system that's optimized for "building with AI"

Originally published at https://yuvalyeret.com/blog/ai-transformation-exposes-why-you-need-a-product-operating-model/.

Product Ownership Topology: The Difference Between Flow and Theater

Yuval Yeret — Mon, 30 Mar 2026 00:00:00 GMT

What is Product Ownership Topology and Why Does It Determine Flow?

When a product grows past one team, the instinct is to hand out product owner titles to match the org chart — one team, one PO, tidy accountability. But product ownership is not a title. It is the authority to make tradeoffs stick. The fast diagnostic: who around this team can say "no" to a meaningful request and have it hold? If the answer is fuzzy, conditional, or political, you have a proxy, a queue manager, or a title without decision rights — and that is one of the shortest roads to Agile Theater.

This article pulls together a three-episode mini-series on product ownership topology. The one-team case: splitting product manager and product owner usually creates a proxy PO unless the decision rights are crystal clear. Platform teams: if the platform is strategically important, it needs an owner with the standing to disappoint important people — not a junior engineer handed the title and told to negotiate with VPs. Multi-team scaling: do not copy-paste a PO onto every team, because products do not scale by org-chart symmetry — ownership works only where a team can deliver meaningful value with real independence. The throughline: fix the topology of authority around the team, not the role description.

I was recently with a client building a fairly complex mix of hardware and software. They had a platform team serving five internal product lines, a "Product Owner" for that platform team, and Product Managers for each of the lines. On paper, ownership looked covered. In practice, every serious prioritization conversation stalled out. Nobody around that platform team really had the standing to make the hard tradeoffs, so the calls kept drifting upward to the CTO. The team itself lurched from urgent request to urgent request and finished very little.

I see versions of this all the time. The problem usually isn't lack of talent or commitment. It is that companies confuse job titles with organizational standing.

If you're leading product in a growing company, this is one of those structural choices that ends up shaping far more than people expect. When ownership is set up well, work tends to flow. When it isn't, you feel it everywhere: prioritization turns into negotiation, escalations become routine, and teams spend a lot of energy managing requests instead of finishing meaningful work.

Product ownership is not a title. It is the authority to make tradeoffs.

Here's the test I like to use:

Who around this team can say "no" to a meaningful request and have it stick?

If the answer is fuzzy, conditional, or political, you probably don't have real product ownership. You have some version of a proxy, a queue manager, or someone carrying the role name without the decision rights that are supposed to come with it.

That is one of the fastest roads to Agile Theater. The ceremonies are there. The tickets are there. The ownership isn't.

The one-team trap: two titles, one product, zero clarity

This often starts innocently. A growing company decides to "do Scrum," and somebody suggests a clean split: the Product Manager will focus on strategy while the Product Owner will work closely with the team. It sounds tidy. But very often what this creates is a proxy Product Owner.

That person becomes the relay station between the team and the person who actually owns the decisions. They refine backlog items, answer some day-to-day questions, and run ceremonies. But when the team needs a real tradeoff, people look past them to the Product Manager, founder, or executive sponsor.

At that point, decision latency goes up almost immediately. The team learns where the real authority sits and starts routing around the PO. You end up with more coordination and less ownership.

For one team working on one product, my default is that one person should own the outcome. That doesn't mean they need to write every Jira ticket. It means they need enough connection to the team and enough authority in the organization to make actual calls.

If your Product Manager is "too busy" to engage with the team, the answer usually isn't to add another ownership layer. More often, it is a sign that your Product Manager is being used as a roadmap broadcaster, stakeholder shield, or internal salesperson instead of a product leader.

Platform teams get into trouble when nobody can say no

Platform teams are where this issue becomes impossible to ignore.

A platform often serves multiple internal products, so leaders end up treating it like a shared technical service instead of a product. Then they wonder why the team is drowning in competing requests.

Here's the question I usually ask:

If this platform team stopped shipping for a quarter, would the business feel it?

If the answer is yes, then this isn't just a service desk with better tooling. It is a strategic bet, and it needs product leadership with enough standing to disappoint important people when necessary.

That doesn't always mean a full-time senior Product Manager sitting with the team every day. But it does mean somebody credible and empowered needs to own the hard tradeoffs around investment and priorities for that platform.

What usually doesn't work is giving a junior engineer or analyst the PO title and expecting them to negotiate with a VP Sales, a GM, and several product leaders with conflicting priorities. That isn't empowerment. It's a polite way to manufacture escalation.

In situations like this, one pragmatic move is to connect platform ownership directly to the leader who owns the broader portfolio or product line. They don't need to micromanage the backlog. They do need to own the "not this quarter." Once that part is clear, the team can stop pretending every request is top priority.

Scaling across multiple teams: don't start with the org chart

As companies grow, they often copy and paste ownership roles team by team. One team, one Product Owner. It looks neat on the org chart.

The problem is that products don't scale according to org chart symmetry. Product ownership works when a team can deliver meaningful value with enough independence to learn, decide, and improve. If the team mostly owns a layer, a component, or a specialist function that can't really move customer or business outcomes on its own, giving that team a Product Owner often creates more coordination overhead than value.

Now you have more people representing partial interests in a system that still needs constant cross-team negotiation. That's not scaling. That's full gas in neutral.

This is why topology matters so much. When I worked with Gillette on the Exfoliating Razor, the work wasn't split into neat software buckets. The meaningful questions were around product problems and choices like the shave experience, the ergonomics, and the viability of the overall bet. Those could move with a decent level of independence while still connecting to one product story. That is the kind of context where separate product leaders can actually help.

If your teams are organized mostly around frontend, backend, or specialist components, slapping a Product Owner on each one rarely fixes anything. Usually it just hides the deeper issue, which is that the topology itself is fighting flow.

A better starting question

If you're trying to improve product ownership, I wouldn't start with "how many Product Owners do we need?"

I'd start here:

What does this team really own?
Can it deliver value with some meaningful independence?
Who has the standing to say no on behalf of this team?
Where do hard tradeoffs get made today?
Which escalations are symptoms of missing ownership rather than bad people or bad process?

Those questions usually surface the real problem much faster than a role-definition workshop does.

If your founders or execs keep getting pulled into feature calls, your ownership model is leaking

A few signs I see again and again:

prioritization meetings end in stalemate
platform teams serve everyone and satisfy nobody
the "PO" runs the backlog but not the decisions
stakeholders keep bypassing the team and going to senior leaders
every important tradeoff turns into an escalation

When that happens, the problem usually isn't that people need better backlog hygiene. The problem is that your decision-making topology is leaking. You've installed the rituals, but you haven't fixed the flow of authority.

Where to start

Pick one team that feels stuck. Map the work it actually owns, the dependencies it can't escape, and the decisions it is allowed to make without escalation.

Then ask the uncomfortable question:

Does the person called the Product Owner actually own anything that matters?

If the answer is no, I wouldn't start by rewriting the role description. I'd start by fixing the topology around the team.

Listen to the mini-series

This article distills a three-episode arc from the Scaling with Agility podcast. Each episode goes deeper on one layer of the topology:

Who Actually Owns Your Product? Why the PM/PO Split Often Creates More Confusion Than It Solves — the one-team, one-product case, and how splitting product manager from product owner creates a proxy.
Why Your Product Owners Can't Say No — platform teams, and why a product owner without organizational standing cannot make a "no" stick.
When One Product Needs More Than One Leader: Getting Multi-Team Product Ownership Right — scaling across many teams, and why the number of genuine product problems matters more than the number of teams.

Frequently Asked Questions

Do I always need one person to be both Product Manager and Product Owner?

No. But for a single team working on a single product, splitting those responsibilities often creates a proxy ownership problem unless the decision rights are crystal clear and the two people operate as one.

Can a platform team have real product ownership even if its users are internal?

Absolutely. If the platform is strategically important, has real customers inside the company, and requires tradeoffs about outcomes and investment, treat it like a product.

What is the quickest diagnostic for fake ownership?

Look at who says no when priorities collide. If the person with the PO title cannot make that call stick, you likely have fake ownership.

If this is hitting close to home, let's talk. I help leadership teams sort out where ownership is real, where it's theater, and what structural changes are actually worth making.

Originally published at https://yuvalyeret.com/blog/who-can-actually-say-no-product-ownership-topology-and-the-cost-of-fake-ownership/.

Portfolio WIP — It's Not About Limits

Yuval Yeret — Thu, 19 Mar 2026 00:00:00 GMT

How should we limit WIP on the Portfolio Kanban? How many initiatives should we allow in each column?"

Every time I introduce a portfolio Kanban system to better manage an organization's initiatives, the question of managing work in progress comes up.

At the team level, WIP limits make intuitive sense. Work items are roughly right-sized. You can say "three items in progress" and it means something concrete about focus and flow. It has a direct connection to throughput.

How is a Portfolio-level kanban system different when it comes to limiting WIP?

But portfolio initiatives? One might represent five person-months of work. Another might represent five hundred. A WIP limit of "four initiatives in progress" tells you almost nothing about the actual load on the organization.

What it does tell you something about is cognitive load on the leadership team.

And that's a real constraint worth managing.

Every card on that portfolio board — regardless of how much organizational effort it represents — requires leadership attention. Discussion time in portfolio reviews. Steering conversations. Evidence reviews. Decision-making bandwidth.

Limiting WIP - Not just about capacity management - also a focusing mechanism

If you're a product leader, a CIO, or running a PMO that's trying to bring product thinking to the portfolio level, this is a critical distinction. You're not doing the work on these initiatives. You're providing strategic focus and governance. The bottleneck isn't team capacity — it's your capacity to meaningfully steer.

So the question isn't "what's our WIP limit?" The question is: How many strategic bets can this leadership team actually pay attention to?

How many initiative owners do you have who can think holistically about a cross-product bet? How many discovery efforts can you run with real attention? Is the same person juggling five strategic initiatives and doing justice to none of them?

Reframing from activity to intent - From Limiting to Reducing WIP

I'll go a step further. I actually have a problem with how WIP limits are typically framed. "Limit WIP" is an activity. Reducing work in process is the outcome. A number in a column header is one technique. But at the portfolio level, the better technique is honest conversation about what you can actually steer — and what you should push down to empowered product teams instead.

How should we approach managing work in process on a portfolio kanban?

Reduce, don't limit. The most useful portfolio WIP question isn't "how many should we allow?" It's: what would need to be true for us to NOT manage this initiative at the portfolio level? That question is what starts to flip the pyramid — pushing decisions and ownership closer to the teams who can actually move fast on them.

Manage your attention, not just the organization's throughput. The portfolio Kanban manages the focus of the leadership team. Most of the actual work across the organization isn't managed at this level — or shouldn't be. When you set WIP constraints here, you're protecting leadership bandwidth, not throttling teams. That reframe changes the conversation entirely.

Let the board create the aha moment. The most powerful WIP reduction I've seen didn't come from a policy. It came from a leadership team looking at their portfolio board for the first time and asking two questions: How are we doing so many things? And: Do we really need to manage all of these?

That second question is where the real shift starts. Because once leaders start to think about what they can safely push down — once they start defining guardrails that make it comfortable to let teams run — you've started the transition from centralized portfolio management to something much more product-oriented.

The irony is that the PMO instinct — let's get everything visible and manage it tightly — is actually the right first step. You need to see the swamp before you can shape it into a river. But the next step isn't tighter management. It's deciding what deserves your strategic attention and what deserves your trust.

The key question therefore is How many of the cards on your portfolio board actually need to be there?

Originally published at https://yuvalyeret.com/blog/portfolio-wip-its-not-about-limits/.

Agility is about efficiently seeking alpha

Yuval Yeret — Mon, 09 Mar 2026 00:00:00 GMT

Cycling with my son to school is one of my favorite morning rituals.

Beyond the quick ride to school, I usually turn it into a longer loop with a couple of neighborhood hills. Nothing too aggressive. Just enough fresh air and headspace to think.

One recent ride led me to a thought that has been rattling around in my head since:

Agility is about efficiently seeking alpha.

That probably requires some explanation.

In investing, alpha is excess return. In the world of product development and business initiatives more broadly, I think of alpha as the excess return from developing new capabilities. That could be a new product, a feature, a new internal capability, a new go-to-market motion, a better pricing model, whatever.

If your organization is doing anything beyond pure keep-the-lights-on work, you're probably already seeking alpha.

The question is whether you're doing it in a smart way or an expensive way.

Here's what I mean:

Agility doesn't magically create alpha.

What it does is help you seek alpha more efficiently. It helps you learn faster and cheaper whether an idea is worth pursuing, reshaping, or killing.

That might sound subtle, but I think it's actually the whole game.

Speculative investing became a lot easier once transaction costs dropped. You can place a bet, see what happens, and adjust without paying huge tolls on every move.

Speculative investing in products, capabilities, and strategic initiatives becomes easier when the cost of learning drops.

When you can test earlier, integrate faster, get feedback sooner, and change direction without a bureaucratic drama festival, you can place more meaningful bets and manage them better.

That is a big part of what agility is about.

When I shared this thought on LinkedIn, Ed Kless made a good point. Why "efficiently" and not "effectively"?

He's right that if you do something ineffective more efficiently, you can make the situation worse faster.

I'm using efficiently on purpose.

At the level of a single product idea or feature, effectiveness matters more. If you're building the wrong thing, doing it faster is not inherently useful.

But at the portfolio level, and certainly at the operating-system level, efficiency matters a lot because it changes the economics of search.

If we can seek alpha more efficiently, the overall system can become more effective because we can:

place more bets
get evidence sooner
sift weak ideas out earlier
invest more in the ideas that are actually showing promise

And to be clear, good agility should improve effectiveness as well, because it isn't just about speed. It is also about empiricism. It helps you select and steer better, not just move faster.

This is one reason I keep thinking about EOS and similar business operating systems.

EOS is great at bringing discipline and structure when a founder is stretched too thin. Same for other operating systems and management frameworks. They can dramatically improve alignment, accountability, and traction.

But more and more leadership teams I talk to are asking a deeper question:

Where's the entrepreneurial in the operating system?

Is the system helping us seek organizational alpha?

Is it helping us navigate hard shifts that require cross-functional collaboration, fast feedback loops, and evidence-informed steering?

Or is it mostly helping us track commitments and run cleaner meetings?

The leadership team of a brewery collective I'm working with is wrestling with exactly this. They're leveraging techniques and mindsets from the product/agility world to scale entrepreneurship across the organization.

What seems to matter most is not adding more project management.

It is replacing project management with:

outcome orientation
evidence-informed efficient experimentation
faster cycles
cross-functional collaboration around real bets

That's the entrepreneurial upgrade.

You can see a similar shift right now with AI vibe coding.

It doesn't guarantee a good business idea. What it does is make it much cheaper to test one.

That changes the game. It makes bootstrapping viable in places where previously you'd need a bigger budget, a bigger team, or more investor patience just to get to first evidence.

Agility plays a similar role inside organizations.

It doesn't guarantee insight.

It doesn't guarantee product-market fit.

It doesn't guarantee strategic judgment.

What it can do is reduce the cost of finding out whether you're onto something.

And when you can do that repeatedly, cross-functionally, and without excessive friction, you're in a much better position to create real alpha.

So when I say agility is about efficiently seeking alpha, I don't mean "go faster no matter what."

I mean build an operating system that makes it cheaper and easier to:

pursue promising bets
inspect reality early
adapt based on evidence
stop protecting weak ideas just because they're already on the plan

That's a much more useful definition of agility than ceremonies, velocity, or whether teams are following the script.

That's also where I think the next generation of operating systems is headed.

Not abandoning EOS, OKRs, or other systems.

Upgrading them with stronger outcome orientation, more empiricism, and better support for entrepreneurial search.

That's the thought, anyway.

Curious whether this framing resonates with you.

Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. Explore Business Agility advisory or let's talk.

Originally published at https://yuvalyeret.com/blog/agility-is-about-seeking-alpha-more-efficiently/.

In the Spotlight - Building and Operating Your Revenue Machine

Yuval Yeret — Fri, 06 Mar 2026 00:00:00 GMT

Most revenue leaders I work with are not struggling with effort. They are struggling with leverage.

There is plenty of activity: pipeline reviews, enablement decks, tool rollouts, process updates. But for many organizations, the system keeps producing the same bottlenecks. Forecasts stay noisy. Hand-offs stay brittle. Adoption of "new and improved" ways of working fades after the first push.

That was the core topic in my recent conversation with Roi Carmel on In the Spotlight: if you want durable GTM performance, you need to do two jobs at once:

Operate today's revenue machine.
Build the next version of the machine while you run it.

Why "rollout thinking" keeps failing in GTM

Many change initiatives fail quietly because they are designed as one-time deployments. New CRM workflow. New qualification framework. New operating cadence. Then leadership expects immediate adoption and measurable impact.

In reality, GTM systems are living systems. Buyer behavior shifts. Team composition changes. New channels appear. AI changes how teams work week to week. If the change model is static while the environment is dynamic, ROI will usually disappoint.

The pattern I see repeatedly is this: organizations treat operating model change as a project to complete, not a capability to cultivate.

Key Insights

"In parallel to building the product, you need to build the organization that is building the product."

For revenue teams, that means building better decision loops, better cross-functional coordination, and better adaptation habits, not only better plans.

"People don't really like being inflicted change upon. They like to be part of the process."

Adoption is not communication. Adoption is co-creation. Teams are far more likely to sustain behavior change when they help shape it.

"If people fail, then that's a failure of the system."

When execution is inconsistent, start with system design before blaming individuals. Usually there is a policy, interface, incentive, or workload issue hiding under the symptoms.

A practical operating approach

If you lead sales, marketing, RevOps, or product marketing, here is a pragmatic pattern:

Pick one business-critical outcome (for example: forecast reliability, win-rate in a segment, or cycle-time to qualified pipeline).
Map the current system that produces this outcome across functions.
Run small experiments in the operating model, not just in messaging or tactics.
Review both business outcomes and adoption signals.
Keep what works, adapt what does not, and repeat.

This is the same logic strong product teams use: short cycles, evidence over opinions, and continuous learning in context.

Watch the full conversation here: In the Spotlight - with Yuval Yeret

Keep exploring in the insights library

If this topic resonates, these pieces go deeper:

A few other questions that often come up in conversations about applying continuous learning/adaptation to the revenue/GTM machine

Is this mainly relevant for large enterprises?

Not necessarily. The pattern appears in scaleups, mid-market firms, and enterprise contexts. The size changes; the operating-system dynamics are similar. At the extreme, even soloists like me have to run the revenue machine in parallel to evolving it.

Should RevOps lead this alone?

RevOps is central, but not sufficient alone. Durable change needs shared ownership across sales leadership, marketing, product marketing, and supporting functions. That's one of the key insights - change participants need to feel and show up as players, not pawns, if you want the change to stick and to really serve the needs of the organization.

How fast should we expect results?

Well, this is an interesting one. On one hand participatory evolutionary change might seem slower because you have to involve more people, and plan for iteration rather than one big bang. On the other hand, the right plan could leverage this iterative incremental nature to show quick progress and value along the way. Ideally you can front load value, seeing much faster results, and even trim the tail - skipping some aspects of the change that you initially planned for but are realizing aren't needed after trying some things out.

Moving from agile theater to real business agility takes more than a framework — it takes a deliberate operating model shift. Explore Business Agility advisory or let's talk.

Originally published at https://yuvalyeret.com/blog/in-the-spotlight-building-and-operating-your-revenue-machine/.

Podcast Deep Dive: AI Strategy and the Operating System Mismatch (with Dave West)

Yuval Yeret — Thu, 26 Feb 2026 00:00:00 GMT

In a recent episode of the Scrum.org podcast, I sat down with CEO Dave West to discuss why so many organizations are struggling to turn their AI investments into business impact.

While we've previously discussed how your Operating System can be a bottleneck for AI, this conversation focused specifically on the mechanics of how AI adoption is shifting the boundaries of traditional IT.

The High Failure Rate of AI Projects

Dave highlighted a startling figure: 95% of AI projects fail to deliver meaningful value.

But as we explored the "why" behind this number, a pattern emerged. These failures rarely stem from the technology itself. Instead, the failure happens when organizations try to "project-manage" a complex, emergent technology with a 20th-century mindset.

"The key for me, what I see where people are finding gold using AI... is when they use product techniques, whether they call it product or not."

Beyond the IT Boundary

One of the most profound insights from our discussion was that AI adoption challenges now originate outside traditional IT. We're seeing sales, marketing, and legal departments leading AI initiatives without the necessary operating system to support the uncertainty of high-potential developmental work.

Context is the New Training Data

We discussed the concept of "Context Development." Just as a product defines its scope and purpose, an organization must provide AI with consistent boundaries and relevant information to be effective. This is why some suggest that Context is the new Code: the performance of GenAI depends less on how you code the interface and more on the quality and specificity of the context—data, constraints, user persona—you provide it.

Key Takeaways for Leaders:

Differentiate Work Types: Don't treat operational optimization (stable work) the same as innovation (complex work). AI fits best into an agile, product-oriented mindset.
Strategy Alignment (OKRs): Use OKRs to ground AI initiatives in real business strategy rather than technology for technology's sake.
Continuous Adaptation: Your OS must be capable of sensing, responding, inspecting, and adapting in real-time. Even a traditional PMO can adapt to this reality, provided they shift from "schedule policing" to "enabling evidence-based governance" focused on leading indicators of value.

Listen to the full episode on Scrum.org: AI and the Implications for your Organization’s Operating System.

Originally published at https://yuvalyeret.com/blog/ai-isnt-the-problem-your-operating-system-is/.

WIP Limits in Scrum with Kanban: The Essential Regulator for the AI Age

Yuval Yeret — Fri, 23 Jan 2026 00:00:00 GMT

Why WIP Limits Are Essential for AI-Accelerated Software Development

Traditional WIP limits in Scrum with Kanban are designed to stabilize team flow, but in the era of AI-assisted development, they have become the critical regulatory mechanism for the entire delivery system. When coding is 10x'ed by AI tools, the bottleneck immediately shifts downstream to code review, testing, and product validation—a phenomenon I call "acceleration whiplash."

Simply generating code faster doesn't mean you are delivering value faster. In this updated guide, we explore how Scrum teams must adapt their WIP limit strategies (the what, when, who, and how) to prevent AI-generated noise from overwhelming human gates and ensure that speed actually translates to business impact.

Why WIP Limits Matter More Than Ever in the AI Era

One of the key Kanban practices is limiting Work in Progress. While this practice traditionally aims to stabilize workflow and reduce cycle times, its role has changed dramatically with the rise of AI-assisted coding tools. When developers use Copilots or LLM code generators, the time it takes to move a feature from "In Progress" to "Ready for Review" drops significantly. Writing code becomes essentially frictionless.

But this speed is highly uneven. While code generation accelerates, the human-bound stages of software development—such as architectural review, E2E testing, product discovery, and user validation—cannot scale at the same rate. This creates a severe queue at the review gate, resulting in larger pull requests waiting for human eyes or being approved without real understanding. This is "acceleration whiplash" in action. It is a system-level flow problem, not a tooling problem. Without strict WIP limits, AI speed simply piles up inventory and slows down overall value delivery.

Who Defines the WIP Limit in the AI Age?

In a classic Scrum with Kanban setup, Developers own the Sprint Backlog workflow, which means they traditionally set and own their internal WIP limits. If the team is using Kanban to visualize and manage their Sprint flow, this remains the starting point. They monitor bottlenecks, adjust limits, and ensure they are swarming on active work rather than starting new tickets.

However, because AI tools shift the system constraints so rapidly, a team-level view is no longer sufficient. Product Owners and Developers must co-design the end-to-end flow boundaries. Without these shared limits, the high-speed engineering engine quickly runs out of ready, high-value work—a problem known as upstream starvation. Developers, finding themselves with empty hands, are tempted to pull low-value, unvalidated backlog items just to stay busy. This results in "AI theater," where the engineering factory runs at maximum capacity to build nice-to-haves that are weakly connected to strategic business outcomes.

Should WIP Limits Be Altered for Mid-Sprint Urgent Work?

A common challenge for Scrum teams is how to handle mid-Sprint interruptions or high-priority requests. In a standard Kanban system, the policy is simple: do not change WIP limits on a whim. If an urgent item is pulled into the Sprint Backlog, it should count against the existing limit. If the team is already at their capacity, they must wait for a slot to free up or treat the exception as a visible policy breach to be analyzed during the Retrospective.

In the AI era, the temptation to bypass this discipline is intense. When a developer can use an LLM to write a "quick fix" in five minutes, it feels harmless to bypass the WIP limit. But that five-minute code generation still carries significant downstream costs: human cognitive load for code reviews, automated regression testing, deployment pipelines, and business validation. Keeping WIP limits rigid forces the team to confront the true cost of these interruptions. It prevents the system from being quietly flooded with half-done, uncoordinated code changes.

How Should Scrum Teams Implement WIP Limits Now?

To manage flow in the age of AI acceleration, Scrum teams need to rethink their WIP limit strategies. Here are three practical approaches:

First, place strict WIP limits on the "Ready for Review" or "QA" columns. When coding speed increases, the queue in these columns will naturally explode. Enforcing a low limit here forces developers to stop writing new code and swarm on testing and reviewing existing PRs.

Second, leverage the time saved by AI to pair and swarm continuously. Instead of five developers working on five separate tickets with their own AI assistants, have them work in pairs or trios. Use the extra capacity to run continuous reviews and quality checks, keeping active WIP ultra-low and reducing handoffs.

Third, apply a strict WIP limit to the "Refinement" stage. Do not feed the high-speed development engine with unvalidated ideas. By limiting the work in flight during product discovery, you ensure that developers are only pulling specs that have clear evidence of business value.

From Agile Theater to AI Value Realization

Optimizing developer speed with Copilots while ignoring downstream constraints is a classic example of local optimization. It builds local speed but slows the overall value stream, leading to high activity and zero business impact.

If you are struggling with these bottlenecks, the answer is not more AI tools—it is a redesign of your operating model to ensure that speed actually translates to value. Managing flow at the team level is the fractal starting point for managing it at the portfolio level.

If you are ready to move beyond AI theater and align your development operating model for actual business impact, let's talk.

Originally published at https://yuvalyeret.com/blog/limiting-work-in-progress-wip-in-scrum-with-kanban-what-when-who-how/.

Is it a Product Operating Model? Or is it Stage-gates?

Yuval Yeret — Tue, 20 Jan 2026 00:00:00 GMT

Navigating the opportunity-rich environment of the AI age, when your company is considering dozens of "finding AI gold" initiatives, requires discipline and product-orientation.

I'm working with a PMO leader to develop a product-oriented portfolio management approach in an organization with deep roots in pharma, chemistry, and hardware development.

Meaning an ongoing clash between stage gates and agility/product-orientation.

I'm recalling an exercise we included in the Scrum.org Professional Scrum w/ Kanban. The "Is it Waterfall? Is it Kanban?" exercise is one of my favorites because it explores the folly of extreme views on this.

Being product-oriented and iterative doesn't preclude the use of stage gates.

It precludes big-batch stage gates that lock in too much up front.

It actually benefits from the right sort of stage gates, those that focus on flushing out risks/leap-of-faith assumptions.

That enables, and even forces, explicit choice between discovery (tracer bullets) and delivery (cannon balls) depending on the risk profile.

Curious: how are you thinking about the role and evolution of stage gates in the AI age?

If you are navigating this tension right now, see Figure Out Your Product Operating Model Strategy and Portfolio Agility.

Originally published at https://yuvalyeret.com/blog/is-it-a-product-operating-model-or-is-it-stage-gates/.

How ARAS Software Is Agile about How They Scale Agile

Yuval Yeret — Wed, 17 Dec 2025 00:00:00 GMT

You scaled your team to 60+ engineers. You installed the "industry standard" frameworks to keep everyone aligned. For a while, it worked.

But lately, it feels different. PI Planning has become a ritual people dread. Innovation cycles have turned into "dead zones." Your teams are spending more time managing the process than shipping code.

You’re starting to become the incumbents you started your business to disrupt.

Here is how one high-growth PLM leader, ARAS Software, navigated the scaling journey with agility.

Specifically, you'll learn how Aras continuously accelerated engineering productivity and throughput by making the right scaling choices at key points on their growth journey - introducing SAFe for initial scaling, and evolving beyond classic SAFe mechanisms when they outgrew them.

This isn't a "polished" shiny conference case study. It's a raw look at what's happening in the trenches of mid-market scaleups.

https://youtu.be/QK\_Yl46tQt4

https://api.substack.com/feed/podcast/1195288.rss

Find the Scaling w/ Agility Podcast on your favorite Podcast Player:

If your scaling motion is becoming process-heavy and value-light, Fixing Your Agility and Portfolio Agility are the two most relevant starting points.

Originally published at https://yuvalyeret.com/blog/how-aras-software-is-agile-about-how-they-scale-agile/.

When Traction Becomes Friction: How to Upgrade Your Operating System for Speed and Uncertainty

Yuval Yeret — Tue, 25 Nov 2025 00:00:00 GMT

Why the "professional management" playbook needs a dose of empiricism.

Many leaders install a Business Operating System (BOS)—such as EOS, Scaling Up, or OKRs — and achieve significant improvements in execution discipline and traction across their organization. They set annual goals, break them into quarterly "Rocks," and execute on them.

Many leaders are discovering that there's an essential nuance to what this execution looks like. Many of the goals they're pursuing are full of complexity, uncertainty, volatility and ambiguity. Following the plan can lead to a situation where "the surgery succeeded, and the patient died". The project is "successful," but it didn't "move the needle".

So what's the alternative to following the plan? Responding to Change. This is what we mean by agility: aligning on a strategic goal and executing it with the ability to sense what is really going on and respond quickly.

The earlier you sense, the faster you respond, the less energy and time you waste going down the wrong path. It’s almost like a cheat code to tilt the odds in your favor.

If a BOS provides the discipline to march, Agility delivers the intelligence to know if you’re marching off a cliff. Here is how to upgrade your BOS from a static reporting tool to a dynamic innovation engine.

1. From "Accountability" to "Empiricism."

A BOS effectively solves the "who will do what, by when" problem. This creates accountability. But in complex environments—whether you are restructuring a sales channel, changing a compensation model, or mandating a return to office—doing what you said you would do isn't enough if the assumption behind the task was wrong.

The Agile Upgrade: Don't use your Weekly L10 or Management Meetings to check off tasks ("Did you send the RTO memo?"). Use them to review evidence.

Traditional BOS (Output): "I sent the 'Return to Office' policy update to the whole company." (Task Complete).
Agile BOS (Outcome): "We piloted 'Anchor Wednesdays' with the Finance team. Productivity remained flat, but employee NPS dropped 20 points. We should pause the wider rollout and interview the team." (Learning).

This shifts the culture from compliance ("I did my job") to learning ("We tested the policy, and it needs work"). You still maintain the meeting discipline, but the content shifts from status updates to hypothesis testing.

2. Treat "Rocks" as Bets, Not Contracts

In many operating systems, quarterly priorities are treated as set in stone. The goal is "Green" or "Red" based on completion. This creates a perverse incentive: teams will execute a bad idea just to get a "Green" score.

The Agile Upgrade: Frame your quarterly goals as Hypotheses or Target Conditions.

Instead of: "Roll out the new subscription pricing model to all clients."
Try: "Validate that 20% of renewals will accept the subscription uplift without churning."

This allows the "How" to change while keeping the "Why" aligned.

Real-World Example: The "Recurring Revenue" Play A typical business move is shifting a service business from one-off projects (lumpy revenue) to retainers (predictable revenue).

The Traditional BOS Way: The "Rock" is "Launch Retainer Model." The team spends 90 days rewriting contracts, updating the CRM, and training sales. They launch in Q2. Clients balk at the price. The quarter is wasted.
The Agile Way: The "Rock" is "Validate the Retainer Value Proposition."

3. Organize Around Value Streams, Not Just "Seats."

Standard operating systems love an Org Chart. They ask, "Do we have the right person in the right seat?" (e.g., VP of Sales, VP of Ops). But when you are trying to enter a new market or fix channel conflict, functional silos kill speed. Legal blames Sales for bad terms; Ops blames Sales for impossible delivery dates.

The Agile Upgrade: Don't just ask "Who sits where?" Ask "How do we deliver value to this new segment?"

You likely need a cross-functional team—what we call a Value Stream Team—that cuts across the silos.

Real-World Example: Entering a New Market. Let's say you acquired a generalist HVAC services company and want to attack the specialized "Medical Facilities" market.

The Silo Way: Marketing buys a list. Sales cold calls. Ops waits for a signed contract. When a deal finally lands, Ops realizes they lack the certifications to service a hospital. The deal dies.
The Agile Way: Create a "Medical Vertical Squad."

The Bottom Line

A Business Operating System is necessary. It replaces the founder's "fragile, personality-driven model" with a professional chassis.

But if you stop there, you risk building a bureaucracy that is efficient at doing the wrong things.

If this is your challenge, see Create a Business-level Operating System leveraging Agility and Portfolio Agility.

Originally published at https://yuvalyeret.com/blog/when-traction-becomes-friction-how-to-upgrade-your-operating-system-for-speed-and-uncertainty/.

How to Upgrade Your Scaling SMB's Operating System Without Losing Agility

Yuval Yeret — Tue, 04 Nov 2025 00:00:00 GMT

Growth is supposed to feel like acceleration. For most companies with 50-500 employees, it feels like wading through mud.

You added people, more layers, and "responsible adults." But instead of getting faster, you got slower. Predictability is down, and coordination overhead is overwhelming your top talent.

I was discussing this exact problem with Dave West on the Scrum.org podcast, as part of a series focused on how agility can help small and medium-sized businesses tackle their growth challenges. We agreed: scaling doesn't have to mean slowing down, but it almost always does. It's because leaders fail to address four systemic traps.

https://api.substack.com/feed/podcast/1195288.rss

Here’s the pragmatic breakdown.

1. Your 'Founder Brain' Is Now the Bottleneck. The skills that got you from 10 to 30 people (hustle, intuition, product-market fit) are not the skills that get you to 100 or 300 (operating as a system). Early-stage leaders who excel at building often hit a ceiling when they need to enable a multi-team organization. The system is now too complex for a single person to manage. It's time to scale up.

2. You Optimized for Silos, Not for Value. As you added functions—Sales, Marketing, Product, Ops—you built functional fiefdoms. Now, each department hits its own scorecard, but the customer waits. You're spending more time in "alignment" meetings than on execution because value flow is breaking down at every handoff. You're optimizing locally while the system slows globally.

Instead of defaulting to departments, organize around outcomes. A cross-functional "Pipeline Health" team, for instance, will consistently outperform disconnected Sales and Marketing units trying to "coordinate" via endless meetings. Your collaboration structures should reflect the flow of value, not a list of functions.

4. Your Scaling Framework Became a 'Responsibility' Checklist EOS, Scaling Up, D4X... these frameworks can be helpful. But too often organizations end up serving the framework instead of making it serve them. You're treating "rocks" and scorecards as activity trackers, not as measures of real-world traction. All of these frameworks can benefit from a healthy dose of outcome orientation, aligned autonomy and evidence-based management.

Originally published at https://yuvalyeret.com/blog/how-to-upgrade-your-scaling-smbs-operating-system-without-losing-agility/.