Yuval Yeret's Blog

Don't Redesign Your Process Yet. Change Who Writes the Artifacts.

Yuval Yeret — Sat, 22 Aug 2026 00:00:00 GMT

The first thing to change is who writes the artifacts, not how you work

"We didn't change the process. We still have a quarterly planning and we have sprint planning and we have roadmaps and a list of features that we want to deliver in a quarter." That is Shay Mandel, describing an organization of about two hundred people that has spent three or four months putting an agentic development lifecycle into production. On purpose, they didn't say let's jump to the end and let's change everything, all the processes and everything. What they changed instead is who writes the artifacts: in order to create good requirements there are a set of steps you need to do, and they created a skill for each one of them. The people in engineering, and in product, are not supposed to write anything on their own anymore. They just need to fix the skills or fix the context.

It's clear that the model is not going to be perfect. But you're trying not just to fix the model's outputs, or even to avoid fixing the model's outputs. You're fixing the system instead. The inputs into the model, whether that's the context or the skills. So essentially everybody is developing this system that is the agentic development lifecycle, which is the right mindset. That is the change I would make first, and it's a much smaller change than the one most leadership teams reach for after a demo. The process change is real and it comes second. You can tell when it comes due: it's when your board stops telling you where the work is.

What they changed, and what they left alone on purpose

Quarterly planning is unchanged. So is sprint planning, the roadmap, and the list of features they want to deliver in a quarter. So are Jira and Confluence, and the split between engineering, product management and insurance product.

They didn't change the processes much. What they did was break them down. In Shay's words: in order to create good requirements, there are a set of steps you need to do, and they created a skill for each one of them. Describing the problem. Then analyzing the problem, getting some data, maybe doing some user research, creating wireframes. All of these are things that you usually do. And then eventually you articulate everything in one PRD where you define the solution. There is an uber skill that helps you route. You say you want to do this PRD. It tells you which stage you're in, and then it directs you. It's interactive. It asks you how you measure it, what you expect the impact to be, and it interviews you until it can write the section.

Then the same treatment on the far side of the handoff, where the cost usually is:

"We know that usually we hand off to engineering and then there are a lot of reviews and questions and there is kind of a lot of feedback. We created a skill for that, so we call it PRD review by engineering." : Shay Mandel

It goes and looks at everything and makes sure that for every domain, the requirements actually answer the questions or the details that they need. Then it gives the product manager the feedback, and suggestions on how to fix it. It preempts the engineering review, in the hope that when engineering looks at it there's less rework. It tries to do this as automatically as possible. Each domain mapped and created their own context. That makes it a little bit more accurate, and also more efficient in how to do the review, the tech design, the implementation and the testing. But eventually, after this stage, it's ready for engineering review for real, by a human. They assume that there are humans in the loop and they want them still to look at it until they get the confidence.

None of that required a new process. It's the same lifecycle, with different hands on the pen.

Everyone's job is now fixing the thing that writes the artifact

They're running this in a few squads so far, and the others are adopting it pretty fast. They understand the value, they understand the efficiency, so almost all the engineers are contributing to it and the PMs are contributing too. What they are contributing is not documents.

"They are not supposed to write anything on their own anymore. They just need to fix the skills or fix the context. So everything that is written will be written in a better quality." : Shay Mandel

They fix the system, and then see that the model is able to create the right solution. Shay put it to his own people more bluntly:

"We need a new state of mind. We are now developers, not of the code, we are developers of the system." : Shay Mandel

At the moment they're still reviewing the PRs, the code changes. But they are not the initial reviewer, they are the last reviewer, after however many automatic iterations it took. So hopefully it's zero. You have zero feedback, that's the goal. And if you do have feedback, the engineer should go in and change the guidelines, the context, whatever. Then next time the reviewer, or even the designer, goes in and does the work better the first time.

Those skill files are the executable specification of how you work, which is the argument I make at more length about what spec-driven harnesses actually are.

Decide which decisions stay human, and say which ones out loud

Once agents write the artifacts, "keep a human in the loop" stops being a policy and becomes a design question, because the loop has a lot of places to sit. It's an interesting dilemma. At the extreme, I could say that how to code something is a decision. And if I want humans to make those decisions, then I'm back all the way to humans at least reviewing all the code. There could also be a decision of what's important. Just choosing what's the feature, what's the architecture, what's the outcome that we want to see, the leading indicators, what's the system behaviour that we want to see. The question is where the right altitude is for the decisions moving forward.

When you execute there are a lot of decisions to make, and they're trying to let the machine do those. But there are important decision junctions where they still think there's a place for human judgment. Deciding on the priorities and selecting the features is one. Most of the work on creating the PRD might be automatic, but they expect a human to read it and approve it. On the engineering side they let the agent create the technical design and the plan, and they want a human review before it starts coding. Then the agent runs the PR review, and once it says the review is okay, they still want a human to look at it before it goes to production.

What decides the altitude, in his domain, is how long the feedback takes to arrive. The insurance case makes that unusually legible. The general rule underneath it travels: the slower and more expensive the signal that tells you a decision was wrong, the higher up the human belongs. That is a line you can draw before you need it, and almost nobody does. What most organizations have instead is an unstated assumption that a human will catch it, held by people who each think someone else is the one catching it.

Expectations are the other half of that job, and Shay's framing is the one I'd hand to anyone whose management has just watched a demo. From idea to POC, like always, it's very quick. From idea to production level, writing it in a way that will pass all the reviews and so on, takes time.

"We talk about it kind of as grades, so we say the initial version will probably be sixty percent accurate or seventy. And we'll probably get to ninety percent or ninety-five. And the extra five percent is why we need a human in the loop." : Shay Mandel

So the first thing to do is to set the expectations: give the demo, but also say that it will take time until you get to this level. That's leadership work, and it's cheaper than the alternative.

Your harness is a product, and its hardest users are not engineers

One of the things I've seen in other organizations that I work with and talk to is this pattern: the harness is created by engineering. A spec-driven harness that is very engineering oriented, you might say, both in what it focuses on and what it doesn't focus on, but also in how it's structured. And when you give it to anybody that's not an engineer, or even to anybody who isn't the engineer that wrote it, people don't really know what to do with it. They don't even understand what the benefit of it is.

Shay hit the concrete version of that immediately, because his rollout crosses functions by design:

"For product managers and insurance experts, they live in a different place. When you tell them open a terminal and just write these commands, you lost them." : Shay Mandel

Engineers usually can do some admin or root access on their machines and the others don't, and it makes sense. So they just need to make sure that the skills they write work for everyone, and that the expectation is set in the right way. And they need very clear getting-started guides. In some cases those are different for the different audiences, or have different levels. You need to think from a product perspective, even about your AI harness and your AI capabilities. You need to make sure it's something that people find easy to activate and easy to retain, especially when you start to move beyond engineering. It's the same argument I make about treating your AI context as a product.

The failure mode Shay is watching for is the one that looks like enthusiasm. He talked with other companies, and what worried him is that some of them have a lot of skills because everyone builds their own. They don't use the generic skill. And then when you look at the statistics, every skill is used by maybe one or two users. A lot of what you build, all these brains, is not really utilized. Next's answer is that everyone should improve the brain that we have in the company, and that it all sits on top of the same brain. Shay leads a squad for what they call AI enablement. It builds the infrastructure, the guidelines and the methodologies. And they put one of their people inside the business squads, to make sure they're building the right infrastructure for them, that those squads actually use it, and that they can contribute back. A forward deployed engineer.

And then the detail that pays for all of it:

"Part of their definition of work for this squad is not to deliver the feature, it's to build a system that can deliver more features in the future." : Shay Mandel

They shifted some of that squad's OKRs, with approval from management. It's okay that the first quarter will be slower, because it will accelerate the quarters after it. This quarter the focus is building the machine. And the machine has to be built so other teams can extend it and other squads can use it. If every squad and every engineer has their own way of working, it won't be productive and it'll be very hard to maintain. If you want people building the machine, you have to stop measuring them on the features they didn't ship while they were building it. That's a funding decision, and it's the one place leadership can't delegate.

When the board stops telling you where the work is, change the process

Next isn't there yet, and they know it. They think they need to build this kind of dashboard. Right now they look at the epic levels and they see the completion of the epics, and they're starting to think about how to see everything that's going on, assuming much more will be going on, and what the right way is to visualize which projects are in flight and which stage they're in.

One of the things I've seen for many years, and I think it applies well here too, is an epic-level Kanban board. First of all, epic-level statuses that reflect all of the touch points between agents and humans. If you think about the PRD: the agent finished writing it, and it's now waiting for human review. That's a distinct state change. So all of these state changes, especially when it's a handoff between humans and agents, show them separately. Then use a Kanban board to reflect where things are, and where things are waiting for the humans. You also get the benefit of flow metrics that show you telemetry of how long it takes in each one of these steps, so you can start to calculate flow efficiency and how much time things are really waiting.

The signal that the process itself needs to change turned up in something Shay described almost as an aside. The extra capacity doesn't only show up as doing more of the same, faster. It also shows up in what they're willing to scope. Instead of saying okay, that's the MVP, that's phase one, let's make it as simple as possible, in some cases they can dream bigger. Phase one can be a bit bigger. A bigger change, something more bold that they can move forward. The moment your capacity starts changing what you're willing to scope, your quarterly planning is working from the wrong assumptions and your board is describing a flow that doesn't exist any more. Fix the board first. It's the cheapest instrument you have, and most boards stop too early even before agents get involved.

"Isn't that just moving slowly?"

It's the fair objection, and no. Change two things at once and you can't tell which one is failing, which is where most AI programs are right now. Beyond that, any improvement away from the constraint is meaningless. Deleting a ceremony is almost always away from the constraint. Changing who writes the PRD, and what a person does when it comes back wrong, is right at it.

The fact that settles it for me is that Next's product and engineering organization isn't the cautious corner of that company. When I asked Shay about the rest of the business, his answer inverted the assumption most technology leaders start from. It is the best argument I have for changing authorship first instead of redesigning the process.

Listen to the full conversation

Shay Mandel leads product and AI enablement at Next Insurance. He's on LinkedIn at linkedin.com/in/shaymandel, and he runs the Product Leaders AI meetup, which is Bay Area local and also on Zoom.

The full episode goes further on the auto-improvement loops they point at a KPI, the ask-engineering and ask-product agents they built for a team split across time zones, and where the actuaries, finance and HR come into this: Developers of the System, Not the Code: Inside Next Insurance's Agentic DLC, also on Spotify.

If you're standing this up right now: change authorship first, hold the process still enough that you can read the results, and treat the harness as a product with users who aren't you. The operating model will need to change. It'll be a much easier argument to make once your own board is showing you where the work is stuck.

Originally published at https://yuvalyeret.com/blog/change-who-writes-the-artifacts-before-your-process/.

How Next Insurance Broke Its Whole Lifecycle Into Agent Skills

Yuval Yeret — Sat, 22 Aug 2026 00:00:00 GMT

What an agentic development lifecycle looks like when it is actually running

Shay Mandel has spent his career on the boundary between engineering and product. A developer at heart, as he puts it, who also likes to see big systems: how we impact customers, how we improve processes. He joined Next Insurance more than seven years ago, when it was quite a small company that then grew almost a hundred percent every year in revenue until it was acquired. They do small business insurance: think about a technician who comes to your house and needs general liability, and workers comp if he has an employee. They provide all these kinds of coverages digitally, so you can just go online and create a policy with no need for an agent. Across engineering, product management and insurance product, that's around two hundred people building the product.

For the last three or four months those two hundred people have been moving the product development lifecycle onto agents. What he wanted people to take from the conversation was what a nice goal looks like for a company that really wants to adopt an agentic development lifecycle, some of the struggles getting there, a lot of the learnings and the caveats, and even just setting expectations of how long it will take. So that's what this is: his account of what they broke into skills, where humans still decide, what the agents get wrong, and what they deliberately left alone. My questions are kept where they moved the conversation, and the full episode is linked at the end.

They didn't change the process. They broke it down.

The first surprise is how much stayed the same.

"I think what we did is we didn't change the process. We still have a quarterly planning and we have sprint planning and we have roadmaps and a list of features that we want to deliver in a quarter." : Shay Mandel

That was deliberate. On purpose, they didn't say let's jump to the end and let's change everything, all the processes and everything. They kept the roles, kept the boundaries between engineering, product and insurance product, and kept Jira and Confluence. What changed sits underneath all of it:

"We kind of broke down the existing processes. We didn't change the processes much, but we said, in order to create good requirements, there are a set of steps you need to do, and we created a skill for each one of them. So like describing the problem. Then analyzing the problem, getting some data, maybe doing some user research, creating wireframes. All of these are things that you usually do. And then eventually you articulate everything in one PRD where you define the solution." : Shay Mandel

Each step is its own skill, and there is a router sitting above them:

"There is like an uber skill that kind of helps you route. You say I want to do this PRD, it can tell you what stage are you in, and then it will direct you. And then it helps you, it's interactive, it asks you like, okay, you want to define the problem, let's define it. How do you measure it? What do you expect the impact to be? And it kind of interviews you and eventually it creates the section in the PRD." : Shay Mandel

The skill I'd steal first is the one they built for the handoff, because it targets the most expensive round trip in the whole lifecycle:

"We know that usually we hand off to engineering and then there are a lot of reviews and questions and there is kind of a lot of feedback. We created a skill for that, so we call it PRD review by engineering. And this is a skill that goes and looks at everything and it makes sure that for every domain, the requirements actually answer the questions or the details that we need. And provides feedback for the PM and also suggestions on how to fix it." : Shay Mandel

So it preempts the engineering review, in the hope that when engineering does look at it, there's less rework. After that stage it goes to a real engineering review by a human, and they assume there are humans in the loop and they want them looking until the confidence is there. Then the same treatment on the far side: implementation plan, technical design, implementation, testing, review, all skills, all supposed to be automated, and all of them are. Each domain mapped and wrote its own context to make the reviews and the tech design more accurate and more efficient in their area.

"They are not supposed to write anything on their own anymore"

The accountability change is the part that's hard to copy, and it applies on both sides of the house.

"We have the people in the engineering, and also in products, they are not supposed to write anything on their own anymore. They just need to fix the skills or fix the context. So everything that is written will be written in a better quality." : Shay Mandel

What I wanted to emphasise back to him is that this is a different instinct from the one most organizations land on. It's clear that the model is not going to be perfect. But you're trying not just to fix the model's outputs, or even to avoid fixing the model's outputs. You're fixing the system instead: the inputs into the model, whether that's the context or the skills. And then see that the model is able to create the right solution. Essentially everybody is developing this system that is the agentic development lifecycle.

Shay had already put that to his own people in a sharper way:

"We definitely talked with all the engineers and also with product and we explained to everyone, you need to change the state of mind. We need a new state of mind. We are now developers, not of the code, we are developers of the system." : Shay Mandel

Asked how the engineers feel about it, his answer was unglamorous and probably the reason it's working. It's an evolution, and any time you adopt something new you see the same adoption curve: early adopters who jump on it, late adopters, and laggards. Most of them are now at the point of saying okay, I understand that I need to do this and I also understand the benefit. There's still frustration when you write something you think is right and the quality of the result isn't what you expected. Sometimes not enough detail, sometimes too much detail and too long to read. It takes time to tune. But it's already saving them time.

Where humans still decide

I pushed on this, because "keep a human in the loop" stops meaning anything once agents write the artifacts. At the extreme, how to code something is a decision, and if I want humans making those decisions I'm back to humans reviewing all the code. There's also the decision about what's important: the feature, the architecture, the outcome we want, the leading indicators. The real question is the altitude.

"When you execute there are a lot of decisions to make, but we are trying to let the machine do this. But there are important kind of decision junctions that we still think there is a place for human judgment." : Shay Mandel

Their junctions, in order: deciding the priorities and selecting the features. Reading and approving the PRD, even when most of the work creating it was automatic. Reviewing the technical design and the plan before coding starts. And a human before production, after the automated PR review has done its rounds.

"We are not the initial reviewer. We are the last reviewer." : Shay Mandel

The goal is that the last reviewer has zero feedback. And when there is feedback, the fix goes back into the guidelines or the context, so that next time the work is done better the first time.

Why those junctions and not others is a domain answer, not a principle. Making a mistake in an insurance product can be very harmful, and it might take a long time to see the output. You introduce a new product and you start getting claims only after a year. Then you see if it's too many claims or too little, and whether you should adjust something. A button position is not that: the agent creates both variants, runs the A/B test in production, and comes back saying this one is winning. Today they still review it and switch manually. Maybe in the future they push that automatically, because if it's very clear that one solution is better than the other, then they let it go. They're not there yet. They need to build their own confidence in the system first.

The loops: pointing an agent at a KPI

The part that goes furthest is what they call the loops.

"We are also having some teams that are starting what we call the loops, which is kind of the auto improvement loop. So we take a business problem and we say this is a problem that kind of repeats itself and we want it to be continuously improving. So it should go from monitoring what we have right now, deriving from that what's the new feature, and then going through all the features. There are humans in the loop, but this is like a process that humans should mostly review, maybe tune, and push to the next step." : Shay Mandel

Pointed at the funnel: improve the conversion, from start to quote or to purchase. Which is worth naming for what it is. You give it a KPI, you give it an area and you say improve this area. You don't even give it features. You tell it to focus on outcomes, and you run a loop around a goal.

It works partly for a reason that has nothing to do with models:

"Not everyone can do it, but it's based on the fact that we formalized everything there. So the questionnaire and all of that is very formal, and we moved it to be almost no code in most of the areas, so it's fairly easy to change." : Shay Mandel

And what comes back is a mix. It has a lot of ideas, some of them unrelated. It doesn't have all of the experience their subject matter experts have. Some changes in an insurance product need to be filed and approved by the state department of insurance, so they aren't easy to just make. And then the one that tells you what's really going on:

"In some cases it can tell you, all the competitors are doing X, you should do it the same. And we say, okay, but we are digital and they are not, and we don't want to be the same." : Shay Mandel

That isn't a model failure, it's an information failure. Matching the competition is a reasonable default; the only thing making it wrong at Next is a strategic position that lives in people's heads. So they can get a lot of recommendations for features, but they still need the human eye to look and make the right decisions. The repair is to write the missing thing down:

"When we understand, okay, if we just knew this, then we add it to the context. And we say, okay, this is our strategy and it's going against our strategy. Okay, let's articulate this in the strategy MD file." : Shay Mandel

His framing for the agent writing a PRD is a junior PM: whatever training he'd give a human PM, understanding what's the company and what are the goals, gets written into a context file or a background file, and they have multiple files of that nature.

One brain, and agents you can ask

A junior PM is probably not going to be an insurance expert. So I asked whether he'd tried going the other way: if you think about the most senior insurance expert that you have on staff, have you tried systemizing their knowledge, making a digital twin for them that's available for the agents? And a similar idea: take the ideas from the world's best growth hackers, the best books and resources on growth hacking, and bring them into what a growth agent knows.

"The state of mind is that everyone should improve the brain that we have in the company. So the best insurance experts, they are helping us write this brain. And we are also looking at asking Claude like, how would you solve this, and let's build this into the brain." : Shay Mandel

What they did next is the part I'd copy directly. They created these agents that enable you to ask different functions in the company. So you can have ask insurance expert, and ask engineer.

"If I'm a product manager and I want to do a new feature, but I'm not sure what types of different statuses we have in the system for this user behavior, I can just say I want to ask engineering. What are these statuses? And it will look in the code and everything and all the context that we have and will bring me back the answer. So instead of me talking with an engineer face to face, which is a big problem in our company because we are in very different time zones." : Shay Mandel

It runs the other way too. An engineer sees a PRD that has been through all the reviews, goes to implement, and still has a question. What will the PM do here? If the PM sat at the next table in the same time zone you'd just ask. Since that's not the case, he asks the bot, and gets back how that PM usually makes decisions and the specific guidelines. And when I asked whether the agents themselves get that access:

"Yes, of course. It all sits on top of the same brain." : Shay Mandel

Where the brain lives was decided before anyone was trained on it. They chose a repo over a wiki, so they get version control and everything in one place, and people can contribute and review. GitHub gives them a lot of mechanism for that. Then they trained, and let the people who wanted to run with it run, because those are the ones who find the problems and contribute back. A weekly meeting collects the learnings and cross-pollinates them across the organization.

What changed about managing the work, and what didn't

Less than you'd expect. They still run quarterly planning, sprint planning, roadmaps and a quarterly feature list. Jira holds the tasks. An implementation plan eventually creates tickets. Agents working asynchronously in the background write back as comments: this is what I'm planning to do, this is what I've done, this is how I reviewed it. That gives both people and other agents somewhere to read the state from.

Asked what dashboard he looks at, the honest answer was that they're still working it out. They look at epic-level completion today and are thinking about how to visualise everything in flight once much more is going on. What the extra capacity is doing to their planning, and what to put on the board once the old one stops telling you where the work is, is the subject of the companion piece.

The part that reframes the whole thing

I closed by asking about the rest of the business, and what AI-first means beyond product and engineering. His answer inverted the usual assumption:

"We already implemented this in the support and the claims and the customer facing, we did this already about a year ago, and we continue to improve. We have product managers that we deploy there and a team that supports these different teams, and they are applying the engineering mindset." : Shay Mandel

So product and engineering is actually behind some of the rest of the organization when it comes to going agentic. Which is worth sitting with if you assumed, as most technology leaders do, that engineering leads this and the rest of the company follows.

The way I'd generalise it: we look at product and engineering like a factory, like a pipeline. There is a value stream, a flow, a set of stages. You create a skill for each stage, and you work on optimizing the system. The question is what other factory lines are material to your business. Claims processing, closing the books each month, whatever it is. Then apply the same concept there. The mindset you need, that engineering mindset of constantly tuning the process, is somewhat more difficult to find in other business processes. So applying AI outside of engineering means bringing an engineering mindset to the rest of the organization, whether by applying engineering capacity to it or by building that mindset where it doesn't exist yet.

Listen to the full conversation

Shay Mandel leads product and AI enablement at Next Insurance. He's on LinkedIn at linkedin.com/in/shaymandel, and he runs the Product Leaders AI meetup, which is Bay Area local and also on Zoom.

The full episode: Developers of the System, Not the Code: Inside Next Insurance's Agentic DLC, also on Spotify.

If you want my own argument about the sequencing underneath all of this, why changing who writes the artifacts before you change your process is the move, and how you know when the process change is finally due, that's the companion piece.

Originally published at https://yuvalyeret.com/blog/how-next-insurance-broke-its-lifecycle-into-agent-skills/.

Agility Might Have Been Waiting for AI

Yuval Yeret — Tue, 04 Aug 2026 00:00:00 GMT

AI is forcing everybody to be very agile about who they are, what they do, what impact can they make, and how they're perceived, including myself. I've pivoted from Scaling with Agility to Scaling AI from Activity to Impact.

Am I just jumping on the AI bandwagon?

I've worked on AI-adjacent scaling and agility challenges quite a bit over the last couple of years and that's shifting into AI adoption in product/engineering organizations and the wider business more recently. I've noticed that there's a lot in common.

Many of the patterns that I developed, used, and avoided for improving development lifecycles and how companies work over the years are very applicable when trying to shift organizations from AI ambition to AI-Native operating systems. For example, AI theater caught up very quickly to something that took a decade in the agile world to happen. AI is much faster about everything.

All the way from network / operating-system plumbing to AI-Native plumbing

I often say that I'm a plumber. Not because that's maybe the profitable future for us knowledge workers when AGI is here, but no. I found myself over the years, whether it was in the Israeli Air Force back in the nineties, or leading engineering teams and building engineering systems, or over the last almost twenty years at this point helping leaders improve flow in their engineering pipelines and eventually outside of engineering in marketing, sales, throughout the organization. It's like plumbing. Sometimes things are stuck, sometimes there's a bottleneck, sometimes there's a very ugly mess on the floor that you need to clean up. Whatever the context, I come and help organizations, and I do that much better than I do real plumbing.

Being on the frontier

My clients at Gillette don't like it when I talk about the "bleeding edge" that much. Go figure. But that's what I've been doing. Applying patterns, practices, frameworks, on new frontiers. Whether that was agile, flow, kanban, outcome thinking, evidence-based management.

Using agile techniques to design and launch award-winning razors at Gillette.

Helping an AI Biotech startup accelerate the velocity of research, discovery and commercialization of therapeutic viruses by organizing people in AI/ML, the wet lab to work better together towards aligned outcomes.

Advancing a multi-portfolio technology organization and the business around it from the early stages of a software factory towards becoming a truly product-native organization.

FOMO vs Real Pain / Opportunity

This willingness to try innovative approaches on new frontiers is very different from what was happening elsewhere in the industry. While I was working with these organizations, a lot of other companies were on a transformation fueled by FOMO and the industrial complex itself.

I was helping organizations tackle expensive problems or explore a very lucrative opportunity.

I often come in when organizations realize that there IS an expensive problem or opportunity they need to ACTUALLY work differently to solve for / leverage. It's when they realize that the activity theater that the FOMO transformation creates isn't enough.

That's why when leaders pull me in to discuss how to shift from Tokenmaxxing to transformation I get a strong deja-vu sense.

I see bottlenecks. I see them all the time

When you're trying to shift from activity to impact, one of the most useful perspectives is visualizing flow and looking for bottlenecks.

It's a key tool I've been using as an organizational plumber.

For example, when working on optimizing the throughput of a product group at a large tech firm back around 2010 we used this end to end flow visualization technique to identify a gap in capacity between the development organization, the developers that were building features, and the testing organization.

One of the early insights that we had, once we modeled and showed this information on cumulative flow diagrams, was that this gap is happening, and it doesn't make sense to focus too much on improving the development throughput. It makes more sense to focus on the bottleneck, which is the testing. Not necessarily getting testers to work harder. Subordinating the whole way we were working to the bottleneck. Figuring out how to reduce the overhead of testing (e.g. through automation, or easier to access more stable product APIs, improving the testing approach/architecture).

Organizations adopting agentic software development lifecycles (AI DLCs) are seeing that their bottleneck isn't coding anymore (in some cases, it wasn't the bottleneck even before adopting AI in coding).

Thinking of looking for bottlenecks and orienting your work around these bottlenecks, rather than focusing on the local optimum of a certain function, is a very useful engineering organization optimization technique that is as relevant these days as it was back in 2010.

Why we default to measuring activity instead of impact

It's so hard to measure the impact of what we're doing that we're tempted by these vanity metrics for the activity. We're tempted to measure lines of code, hours worked, planned versus done, how many tokens people use, how many people here are using their Claude Code or Copilot or Slack AI, how many days a week do they use the things. And how many agents can you run? How many agents are you running in parallel? The more agents you run, the more bragging rights you have, right? That's easy to measure.

It's harder to measure the output that you're creating, but it's possible. It's possible to measure how many features are you creating, how many articles are you publishing, how many skills are you creating, how many podcasts are you publishing.

It's much harder to measure impact. It's much harder for a product team, or an internal team that's supporting the organization, to understand what impact are we making in general, and even harder, each small thing that we do, what's the impact of that thing.

Because it's so hard to measure, we often measure the output and the activity.

And once we allow ourselves to measure and focus on activity, we are at risk of falling into activity theater. That's true in case of Agile - where a whole industry focused on activities such as ceremonies, sticky notes, writing stories. And it's true for AI.

You can't give agents outcome goals without an outcome-oriented organization

A lot of my work with organizations in recent years has been on saving organizations from activity theater by orienting around expensive problems/opportunities and figuring out effective outcome-oriented metrics that matter to align them on the journey from activity to impact.

In the AI world it's the same sort of challenge, especially for organizations that are still stuck in an activity theater operating system.

How can you assign an effective /goal to an agent when you don't have an outcome-oriented value architecture even amongst your human employees? It's fascinating how the race towards being AI-native is surfacing so many of the gaps I've been focused on helping organizations close for more than a decade.

When you can't rally people around a purpose or a mission, you turn to mandates and governance. I've seen the damage that the agile police has done in too many enterprises (I often come in to rebuild agility from its ruins). And the same mandates are being inflicted on people to get them moving towards AI.

Your organization is a market, so treat AI adoption like a product

If you CAN frame a transformative reality, you can replace mandates by inviting people. Appeal to their intrinsic motivation. People are motivated by autonomy, or you could say agency, by mastering something, and by being connected to the purpose.

It can be useful to think about AI as a product that people can choose to use to get their job done better. Which shifts the role of AI leadership/enablement as well. From policing to shaping AI as a product people will choose to use, will want to keep using, and will miss if it goes away.

I find that a lot of the work I'm doing with product organizations on shifting from being an activity theater or even a feature factory to becoming product-native transfers very neatly into creating AI capabilities that enable an AI-native organization.

Unreasonable agility

We've built most companies around the fact that our ability to build and deliver products/technology is a bottleneck that can't keep up so we need to protect it. The whole design of Agile ways of working creates stability and predictability. But what happens if the bottleneck moves?

First of all, we need to rethink our ways of working.

But more interestingly, we need to rethink the potential of what we can do with products/technology.

The product/tech bottleneck forced us to be very reasonable. To continuously make tough tradeoffs. What if we didn't have to be reasonable?

Unreasonable Hospitality describes what happens when you break through the chains of the reasonable.

What could unreasonable agility, achieved through agentic software development lifecycles look like? What business transformation could it unlock?

In a sense, real agility might have been waiting for AI. Real agility might be the ultimate AI Impact. And in parallel, agility and product thinking are crucial for navigating the disruptive journey towards becoming AI-native.

Scaling Agility on the path from AI Activity to Impact

Agility isn't going anywhere. Not in my head, and not in my work. It is the "Powered by Intel" inside the AI-Native organization. As well as the ultimate outcome of being AI-Native. So, no, pivoting from Scaling w/ Agility to Scaling AI isn't jumping on a bandwagon. It is realizing how important and valuable the lessons from years of helping organizations scale agility to tackle expensive problems or lucrative opportunities are for turning AI ambition to impact.

Want to dive deeper? Listen to my conversation with Philip Morgan about the relationship between AI, agility, and how I'm shifting my business around it.

Originally published at https://yuvalyeret.com/blog/agility-might-have-been-waiting-for-ai/.

How to Leverage Flow Metrics To Accelerate Your Agentic Development Lifecycle

Yuval Yeret — Fri, 31 Jul 2026 00:00:00 GMT

Isn't it surprising that 10x coding doesn't move the needle that much?

Fully agentic software factories are of course all the rage these days. But more and more leaders I talk to acknowledge that while creating a fully agentic software development lifecycle - is feasible, they haven't yet nailed the approach that makes it trustable.

AI is making some steps in the workflow such as specifying and coding and testing much faster and cheaper. But humans are still very much involved in the lifecycle. And the overall throughput isn't dramatically different and far from the 10x promises everyone is in FOMO on.

Optimizing an agentic software factory requires seeing it as a flow system

When a leader pulls me into a conversation about this, my go to tool is the flow perspective. Seeing the software factory end to end. Visualizing how work is flowing. And where it gets stuck.

In this article I'm sharing my playbook for troubleshooting and optimizing the flow in an agentic software development lifecycle (aka software factory). This is based on what I've been doing and teaching others how to do for almost 2 decades. Because even though AI changes some of the attributes of the software factory, it doesn't change the "laws of physics" that affect it. Reinertsen's Principles of Product Development Flow and Managing the Design Factory still very much apply.

Agentic software development output gets stuck in human queues

Imagine you are the VP of Engineering on Monday morning. Over the weekend, one of your engineers used an agent to complete most of a migration that had been sitting in the backlog for months. Another team has three AI-generated pull requests ready for review. A product manager has a surprisingly convincing prototype for an idea that was only discussed on Friday.

When people ask, you brag about 10x speed. But you know that the reality is a bit more complex. That this speed hasn't turned into throughput yet. While the agents are running very fast, you know that without proper human guidance that speed turns into slop. Features that might work but aren't really useful. Or aren't aligned to the architecture.

So the reality is that between very fast agentic turns you have human intervention. And because the agents are so fast, the work for the humans is piling up. and up. and up. The factory doesn't look that neat anymore. It looks like piles of inflight inventory that hasn't been reviewed yet.

The migration is waiting for the one architect who understands the affected services. Pull requests (PRs) are accumulating because the agents keep working while review waits. And you see more and more conflicts between PRs - breaking your continuous integration. The prototype has triggered a debate about whether anyone actually wants the feature. Meanwhile, the engineers get the agents started on even more work because they don't want to sit idle. And even worse, they don't want the agents to sit idle. (God forbid they have unused tokens at the end of the month, right?)

AI coding's speed moves the bottleneck, but doesn't eliminate it.

Cycle time tells us the REAL speed of our lifecycle

While performing the individual activities in the feature lifecycle faster can be useful, what we care about is the end to end speed. How long it takes a feature to flow from early consideration/prioritization to value realization. That's exactly what the cycle time metric focuses on.

Cycle time looks beyond just the development time, or deploy time. It isn't a measure of engineering speed. When AI moves accelerates activities such as coding and testing, it's even more important to look end to end. To consider feature adoption, usage, retention, and initial improvement iterations, as part of the cycle.

Throughput forces an honest conversation about what counts

Throughput measures the number of features which make it to the finish line per time period.

It is not uncommon to see local 10x acceleration turn into meagre or non-existent throughput improvements end to end, since the acceleration only gets features faster to the bottleneck where they pile up even higher unless we do something to elevate the bottleneck.

WIP tells us whether the new speed is creating a traffic jam

AI makes starting work feel almost free. Someone mentions a useful idea and, twenty minutes later, there is a worktree. An engineer wonders whether a library migration would work and asks an agent to try it. A product manager asks their AI agent for a spec based on a quick description of an ask that came over in email, barely takes a look at what looks like a well considered PRD (AI's documents always feel comprehensive, don't they?) and an engineer pulls the spec and launches an agent swarm to work on it.

Each start sounds reasonable on its own. Together they can overwhelm.

Feature-level Work in Process is the number of features and experiments currently in flight. It includes a breakdown into how many are in each step in the end to end value stream. How many are still being implemented? How many have moved into code review? How many have been merged but not released? How many are live but still haven't told us whether they helped the customer?

Work item age tells us where attention is needed today

Work item age points our attention at items that are moving slower than others through the lifecycle.

I like work item age because it shows trouble while there is still time to do something about it.

Think about two features that have both been active for ten days. One is in the release lane and scheduled to go live tomorrow. The other is sitting in code review because the reviewer found an unanswered product question. They have the same age, but very different chances of reaching a customer soon.

Even when AI agents are involved, work will often age while waiting for humans. I see that in my own agentic workflows. The more things I do, the more likely it is for some of them to go stale.

Work item aging is a leading indicator to cycle time. When we inspect ongoing flow (e.g. at a Daily Scrum, or when our flow agent runs its routine inspection loop), looking at the items aging the most is a useful area to focus on, and figure out:

What is this item actually waiting for?
Can more agentic work help?
Who can make the decision it needs?
Should we review it, split it, ship it, pause it, or stop it?

Flow efficiency highlights delays and waits in our workflow

Trustable agentic development is characterized by spurts of fast progress by agents followed by periods of waiting for humans. Our definition of workflow should let us see when features are moving and when they are waiting.

While these waits/delays are inherent, we want to make sure we understand what they are so we can explore ways to shorten them.

Using Feature-level Flow Metrics in your Agentic Cadence

One of the main questions teams who start scaling agentic workflows ask me is what cadence of meetings makes sense. Do we need Sprints? Sprint Planning? Reviews? Retrospectives? Quarterly planning?

My take is that as long as humans need to align/coordinate/collaborate/stay in the loop at some level, it makes sense to maintain a cadence of inspecting and adapting our intent, the result of our work, and our processes. Like the entire process, the cadence will inspect and adapt at a higher altitude. Instead of inspecting stories, we will look at features. Instead of limiting our perspective to "is this working as specified" we will look at "Is this being adopted? Is it helping people?". This makes for a much more interesting and higher impact inspection and adaptation.

Planning

While agents are faster, they still have limited capacity. And that capacity also costs tokens. If we want to optimize the value humans and their agents will create, we need to consider our feature throughput and pull in the right amount of features, otherwise we will spread ourselves too thin.

We should start with looking at the features currently in flight (Work item aging is a useful view here) and focus on a plan for finishing them before starting new ones.

Then we look at our historical throughput. If it shows us we can deliver between 4-5 features every 2 weeks, taking on 10 is bound to result in a pileup. Taking on 4-5 is more likely to be the right amount, unless we've recently seen significant improvement.

If there's a specific deadline attached to one of the features in our backlog, our cycle times and service level expectations can help us figure out when it makes sense to get going on it. If, for example, we know based on past cycle times that we can finish 85% of our features within 5 days end to end, that can help us decide if/when to start working on a feature that needs to be finished on a specific day.

Reviews - One way to coordinate human perspective and decision making

When features flow fast, we prefer continuous review/feedback rather than waiting for a scheduled event. Having said that, there's still value in stepping back from the individual feature and reviewing the bigger picture. Are all these features we're delivering moving the needle towards our goals?

There's still value in a diverse set of people getting into a room and inspecting intent, specifications, designs, architecture, working product, or product telemetry. Getting all these people into a room every time a feature hits a stage in the pipeline can become a meeting nightmare. We want more and more people to shift to a "makers schedule" where they have fewer and fewer meetings. It might not be intuitive, but the right cadence can be an efficient way to coordinate feedback and perspective across multiple people, while letting them stay in the flow in between.

Continuous Improvement

Process improvement is one activity that really benefits from a cadence. From stepping away from the day to day flow of work to look at ourselves from the outside. To look at flow patterns and design improvement experiments.

This is where inspecting our cycle times, WIP, throughput can help us understand what's going on.

It is where we look at where AI made us faster, and what became the constraint as a result?

If we see that 85% of our features spend at least 7 days waiting for a broad forum design review, we can discuss ways to shorten that, e.g. by introducing a more frequent cadence of standing design reviews, or introducing an async design review, or whatever other pattern makes sense.

Flow metrics don't care about your process

These flow metrics are useful regardless of what process you use. Whether it's spec-driven-development, an in-house or open source harness, whether it's skill-based or an agent-swarm.

You still want to know your throughput. Your cycle times. The amount of Work in Process. And how it's aging.

Because you still want to maximize the amount of value you're creating by delivering valuable features and using the speed of delivery to inspect and adapt more effectively.

Flow metrics still matter in the age of agentic development. They actually matter even more.

Originally published at https://yuvalyeret.com/blog/flow-metrics-still-matter-agentic-ai-development/.

How to Measure AI Impact Beyond Token Caps

Yuval Yeret — Fri, 31 Jul 2026 00:00:00 GMT

The token cap is the least interesting number in your AI budget

Somewhere in your company right now, someone is trying to decide whether an employee should get $100, $300, or $1,000 a month of AI spend. It is a real question with a real invoice behind it, and it is also the wrong place to start, because there is no cap number that is defensible on its own. Set it low and you throttle the experiments that would have told you something. Set it high and you have no way to distinguish a team burning tokens on work that shipped from a team burning tokens on sessions nobody ever looked at again. I got into this with Tomer Elias, a product executive who has spent fifteen years around AI and data, including the first AI lab in Israel, a cybersecurity unicorn, and a committee defining agentic identity standards alongside OpenAI, AWS, and Cloudflare. He has been going company by company asking enterprises how they actually decide.

His answer, and mine, converged fast: the cap is downstream of attribution. Until you can trace a block of AI spend to a piece of work, and that work to a stated objective, the cap is a guess dressed up as governance. What follows is the method underneath that claim. It is a ladder from token spend to business impact, and every rung of it is an old measurement problem that AI made expensive enough to finally address. The uncomfortable part, which Tomer names directly, is that the ladder mostly measures your organization, not your AI.

Why can nobody agree on the right cap?

Start with the mechanics of the decision, because they explain the deadlock. Tomer put it in the terms the finance side of the house recognizes:

"AI puts the credit card at the hand of the employees. But without the oversight and training, costs can spiral. But high usage doesn't really mean a bad thing. It's not good or bad. The question is what's the impact that you get out of that." : Tomer Elias

That last sentence is the whole problem. High usage is not a signal in either direction. A startup burning enormous amounts of tokens is not obviously in trouble, and an enterprise with disciplined, modest per-seat usage is not obviously healthy. It might just be an organization where nobody has found anything worth doing yet. Without a way to evaluate whether the spend was wasteful or impactful, as Tomer said, it does not really matter what the cap is.

I pushed back on one part of this in the conversation, and I want to keep the pushback in, because it changes what you should do about it. This is not a new problem that AI introduced. I have been helping organizations define outcomes, measure them, and close the loop on them for the better part of a decade before any of this. The tooling was different and the bill was smaller, but the failure was identical: teams commit to activity because activity is safe to commit to, and outcomes are not.

There is a diagnostic I use for this. I have a tool I vibe-coded that connects to an organization's Jira, Linear, ADO, or GitHub and classifies everything in flight into four buckets. Activity: let us do this thing. Output: let us build this feature, this screen, this integration. Outcome: let us enable this kind of user, internal or external, to do something they could not do before. Impact: this moves a business number. When I asked Tomer to guess what share of a typical organization's managed work sits at outcome level or above, he said twenty percent. Twenty percent is a good organization. Most are below it, and most of what is below it is output masquerading as outcome in the ticket title.

So when a leader says they cannot measure AI impact, the honest reading is usually that they could not measure impact before AI either. What changed is that the incapacity now has a monthly invoice attached to it.

What does AI actually expose about your organization?

Tomer's framing of this is the line from the conversation I keep coming back to:

"Once you implement AI in your organization, it bubbles up or self-surfaces your DNA and the organizational culture that didn't change for a while and now needs to change if you really want to push impact with AI." : Tomer Elias

This is why I think the cap debate is a distraction rather than merely a hard problem. The cap is a spend-control question. What the spend is exposing is a design question about how your organization defines value, who is allowed to decide, and whether anyone closes the loop. Those were true before you bought seats. AI is the contrast dye.

Tomer comes at organizations as an industrial engineer, which produces a useful lens: every company is a factory whose output happens to be a service, a product, or software. Factories went from humans on the line, to humans and machines, to machines, and at each step there were definitions of what good looked like, what waste looked like, what you spent per line and what you got back. The same definitions should exist when you start inviting digital helpers into your workflows. His caveat is the important one, though: an LLM is not a machine, because a machine's output is the same every time and an agent's is not. That non-determinism is exactly why you need observability and guardrails rather than a fixed cost-per-unit assumption.

I would add the second half of the factory lens, which is where I think most AI programs lose their money. Goldratt's rule holds here with no modification: any improvement away from the constraint is meaningless, and any improvement directly at the constraint is a multiplier. The pattern I keep seeing is an engineering organization that gets genuinely faster at writing code while the code review queue, the QA pass, the release approval, and the downstream decision-making are untouched, usually because those steps belong to people who are less comfortable with the tools. You have moved the bottleneck, paid for the privilege, and shipped nothing faster. If the people deploying AI in your organization showed up as continuous improvement engineers rather than as tool champions, they would find the use cases that actually pay.

The attribution ladder, one rung at a time

Here is the practical core. Instead of asking "what is our AI ROI," which nobody can answer, ask which rung of this ladder you can currently stand on. Tomer's advice was to start deliberately small, and I think he is right that the sequencing matters more than the sophistication:

"It's really hard to say, hey, your ARR tripled just because you implemented AI. It could be that it was tripled because of economical changes. And maybe you have now a great sales team. It's not just because of AI, but the question is whether you can attribute first." : Tomer Elias

Rung one: can you tie spend to a piece of work? Not to a person, not to a department, but to an initiative. Five people, ten sessions, a thousand dollars of tokens, all pointed at this OKR or this goal. If you cannot produce that sentence today, nothing above this rung is available to you, and this is the rung to build first.

Rung two: did anything leave the session? Tomer's version of the first honest measurement is unglamorous: did the agentic work produce something that was eventually embedded in your product, or was it a wasteful session, not an experiment but plain waste? A merged PR, a shipped prototype, a document that someone else used. This is the rung that separates token-maxing from work.

Rung three: is anyone using the thing? Take the example we worked through in the episode, because it is the one I see everywhere: an organization decides to aggregate all its meeting recordings and make them available as context. First you can observe that you collected them, which is genuinely better than nothing. Then you can observe telemetry that people are accessing them. Both are cheap. Both are more than most organizations have, which should tell you something about how early this all still is.

Rung four: is it changing decisions? This is where the value hypothesis has to have been written down in advance. Somebody funded the transcript pile expecting fewer meetings, or faster decisions, or better ones. If nobody wrote down which, you cannot close the loop on it, and the honest answer is that you funded a capability without a claim attached.

Rung five: does a business objective move? Tomer's example here was an approval process that used to take a month, compressed by agents that arrive carrying the full context a human approver needs. Even when a person still signs off, they are no longer going back and forth gathering information. That is the full kit in Lean terms. You want to see the white light of the welder welding, not the welder walking back to the parts bin.

Most organizations I talk to are trying to argue about rung five while standing on nothing. Start at rung one. It is a data plumbing problem, not a philosophy problem.

Fund AI experiments the way a VC funds companies

The other half of the cap conversation is what happens when someone runs out of budget. Today, in most places, they ask and they get more, automatically. That is not a terrible default. It beats throttling curiosity, and it does not turn a finance policy into a referendum on whether someone is working hard enough, but it wastes the moment. The request is the only point in the whole loop where someone is naturally motivated to explain what they are doing.

So change what the request costs. Not more money, more evidence. When you ask for the next tranche, you say what you are working on, what you have to show, and why continuing is a better bet than stopping. This is staged funding: pre-seed, then a checkpoint, then a real conversation. My preference is that the pre-seed round has no token budget at all, so people use their existing subscription. If they come back with a prototype, a proof of concept, an MVP, anything that constitutes evidence rather than enthusiasm, there is a lightweight business case to update. Sometimes the right move is to continue because the option value is worth holding even though you are not sure it will work, which is real options thinking and innovation accounting doing their job. Sometimes the right move is to kill it.

Which means the criteria have to be agreed up front, when nobody is invested. Tomer asked the sharpest version of the question in the conversation: how long would you let the experiment run? The answer being "it depends" is exactly why kill criteria belong in the conversation on day one rather than in a budget meeting three months later.

I would not have a human being sitting in that loop, though. The instinct is to appoint someone to approve token requests, and you have just created a single point of failure whose calendar becomes the constraint. The version I want is an agent that grills you: here is what I want the tokens for, here is what I have so far. It pushes back, it points out that the thing already exists as a subscription, it tells you to go ahead without escalating. The decision rights stay with leadership. The bottleneck does not get a desk.

The build-versus-buy question nobody asks first

Tomer took the conversation somewhere I did not expect, and it is the most immediately actionable thing in the episode. Before any of the measurement machinery matters, most organizations are skipping a question:

"That build mode drove everyone to say, I'll just use Claude and build it myself. Without really thinking about the experimental stage, you know, how much time will it take you to ramp up to do something that is not part of your core business?" : Tomer Elias

His point is about total cost of ownership, and it is not the usual TCO lecture. It is that your manpower is not built to maintain this, your DNA is not built to maintain this, and the ramp-up plus the iterative support plus making it work at scale is the part that never makes it into the decision. The question to answer before you build is whether the outcome is better than a product you could have bought.

I would sequence it slightly differently. Desirability comes first: would anyone actually use this? Until that is settled, build versus buy is premature optimization. Once it is settled, feasibility and viability come in, and that is exactly where total cost of ownership lives.

But here is what struck me. I have looked at every spec-driven framework and harness I can find, and none of them ask this. They were built by engineers who want to engineer. Nowhere in the flow, not before the spec and certainly not after it, does anything stop and ask: is there an open source project for this? Is there a subscription service? Why are we building this ourselves? That is a gap in the tooling, and right now it has to be filled by a person or a prompt, because it will not be filled by the harness.

Tomer sees the person filling it as an emerging role. Some tech-forward companies he has spoken with have already named someone per business unit to make that call before anyone starts building. He calls the general version a business engineer, the successor to the go-to-market engineer who wires Zapier, Salesforce, and Gong together to make a revenue process run. Their projects are framed as what we want to automate, and their judgment call is build versus buy, weighed against what is actually painful and what will generalize across the company rather than becoming another point solution to maintain.

Give the business engineer a digital twin of your stack

If you are going to make that role work at any scale, it cannot depend on one person's memory of your tech estate. I coached a go-to-market engineer who was frustrated that AI had told them to build something, and asked me why it had not suggested doing it in Slack, which is already connected to Salesforce. My answer was the boring one: does it know you have Slack connected to Salesforce? It does not have the context.

So we built a skill on the fly that mapped the ecosystem: go look at Slack, map everything you can see, and if you cannot see it, grill me until you do. It found Salesforce and a great deal more. The output is not a diagram for humans. It is a queryable map of what already exists and what considerations a business engineer would apply, so that anyone working on an AI use case, and eventually agents hunting for use cases on their own, can ask whether this makes sense, whether we already have a way to do it, and if not, what is off the shelf.

Tomer's caution here is real and it is the reason this is harder in a large enterprise than the paragraph above suggests. The blocker is not the mapping, it is the knowledge base underneath it: updated, curated, tagged, classified. He spent years looking at how organizations manage structured and unstructured data across cloud and on-prem, and that is what convinced him enterprises would take longer to adopt AI properly than the hype cycle assumes. Smaller companies can close that gap. Enterprises are carrying a data debt that predates every AI decision they are about to make. I asked him whether anyone is solving this well at enterprise scale, and neither of us could name one. That is either a gap in our knowledge or a genuinely open market, and I suspect the CMDB and asset-management incumbents should be more worried about it than they appear to be.

Measure whether your ways of working are still moving

There is one more loop, and it is the one almost nobody instruments. When I asked Tomer what a manager should actually set as an AI-related goal for their team, his answer was grounded and correct: for a product team, look at how much code was written by AI, how much of it passed review and made it into the product, and whether regressions surfaced that were caused by the way the agents were used. Feed that back to whoever initiated the tooling so the next round is better informed. That is a solid baseline.

I want to add a different altitude, from a Siemens engagement in Israel years ago. We did not call them OKRs at the time, but one of the goals the VP gave the organization was: I want to see experiments in how we work. I want to see us changing the way we work. And specifically, I want to see failed experiments, because a quarter with no failed experiments means nobody left their comfort zone. Today you would call that compound engineering, and it is measurable.

The measurement I would put in front of every engineering leader sits on the files that describe how the agents should work here. Pull requests landing on your CLAUDE.md and AGENTS.md, skills being curated rather than written once, anyone actually using them. Those are the meta-loops, and they are cheap to instrument compared to everything else in this article.

The culture question underneath the cap

I want to close where the cap conversation actually ends up, because it is not a finance conversation.

The Goldilocks problem in front of leaders is real: encourage people to experiment without turning it into "burn tokens at all costs." What decides which way that lands is not the policy. It is whether people feel safe. In a healthy organization, people experiment, report what did not work, and improve their own throughput without fear. In a toxic one, you get toxic token usage, activity theater with a credit card, and worse, people who quietly avoid improving their own throughput because they think they are cutting the branch they are sitting on. Tomer named the same fear from the enterprise side: performance reviews are already asking employees whether they used AI to hit their KPIs, and the honest answer to that question depends entirely on whether the honest answer is safe.

Which brings the whole thing back around. The token cap looks like a budgeting decision. It is actually a question about whether your organization can state what it wants, trace what it spent, and tell the truth about what came back. Tomer's advice for leaders starting out was education first, then defining the use cases and goals you want people to attempt, then reviewing the process monthly rather than waiting for the quarter. Mine is narrower: pick one AI investment you are currently funding and walk it up the ladder as far as you can get. Wherever you fall off is the rung to build next, and it will tell you more about your operating model than any cap ever will.

Listen to the full conversation

This article came out of my conversation with Tomer Elias on Scaling AI: From Activity to Impact. The episode runs about 54 minutes and goes further on agentic identity and security guardrails, the data infrastructure blocker, and who ends up building AI capability outside of product and engineering.

Listen on the episode page or directly on Spotify. Find Tomer on LinkedIn.

Watch the full conversation:

You cannot set a defensible cap on spend you cannot attribute. Pick one AI investment, walk it up the ladder, and let the rung you fall off tell you what to fix.

Originally published at https://yuvalyeret.com/blog/how-to-measure-ai-impact-beyond-token-caps/.

Your Kanban Board Ends Too Early

Yuval Yeret — Thu, 30 Jul 2026 00:00:00 GMT

Why is nobody using the AI agents you shipped?

People are deploying a feature and calling it a day, essentially. The problem is that while the feature might be working, it might not be useful. Or even if it's useful, it might not be used. One specific scenario I'm seeing when working with AI enablement leaders is that they're working on AI use cases: they are deploying agents, deploying Gems, and nobody's using them. It's not really useful that way.

What follows from treating deployment as done is that nobody pays attention to whether people are really using it. Nobody's really working on getting value, getting an impact from the thing. The card left delivery, so the important part is over.

What I typically do in these cases is suggest adding a column to the board, where the criterion for entering it is that we believe the thing is useful and we believe it's ready to be used, and the criterion for leaving that lane is that we have evidence that people are actually using it. That's very simple. It's not a huge change. And what I've seen in organizations where we've added this (the marketing team that added real learning to their flow is the written-up example) is that just adding that lane forces the interesting conversations.

What your spec board asks, and what it leaves out

If I was an engineering leader today, I would take this opportunity to revisit everything. So when I see these teams relying only on GitHub PRs to see and manage flow, I'm worried. While PRs can give you insight into DORA metrics, they don't give you the full flow picture.

My go-to view when I'm joining an engineering team to see what's going on and help them navigate the shift to AI-native development lifecycle is a spec-level kanban. How many are still being implemented? How many have moved into code review? How many have been merged but not released? How many are live but still haven't told us whether they helped the customer?

The first three are on every spec-level board I get shown. The fourth one has no column behind it.

What "Done" on your board is really telling the team

Where a board effectively ends reflects a mental model of siloed thinking, I would say. Take the column names off and just look at the last state. It doesn't take into account the realization that real value crosses value streams, or crosses multiple functions throughout the value stream.

With AI enablement work this shows up in a starker form, because a lot of it has never been given a lifecycle at all. What I see with a lot of AI enablement situations is that they don't even look at the end-to-end picture. They don't even consider the end-to-end lifecycle of an AI use case. They don't yet apply the product lifecycle, or something like a product lifecycle, to this work. And if they did, it would be just focused on delivering the AI agentic lifecycle capability, including anything related to adoption or fine-tuning.

Most boards have no Learn stage after release

When I walk into an organization and ask to see the board, the thing I rarely see is a Learn stage.

What makes that expensive is not that the organization is guessing. The organization is not even seeing it as guesswork. They're just moving on. The fact that this stage is missing means that, essentially, they're moving on to other things. So the feature might be deployed, but it's not really providing the potential value.

Somebody is still carrying that risk, and it's the users. They're getting features that aren't necessarily fit for purpose for them, which means they're not necessarily using them. And the team is not necessarily getting closer to the outcomes that they are responsible for, assuming that they're responsible for outcomes. In other cases the teams are not responsible for outcomes, but the organization is responsible for outcomes, and it's not really seeing those outcomes.

How to tell whether adoption is actually happening

If you feel you have an adoption gap and you want to focus on it, it's really the telemetry. From the moment there's telemetry, we're in the stage of understanding where the friction points are, and it could be that there's an actual sprint where you don't develop anything, only telemetry, and you go and watch the users and try to understand what's blocking them.

Here is how that plays out. I was recently working with an AI enablement lead running an agentic development lifecycle across a set of teams. The technical side was working, and this is exactly the stage where, beyond the technical solution, we've passed the point where the technical works and we're now in the hypothesis of whether the users are using it. So concretely, what are you doing about it? First of all, do you have adoption measurements? They didn't. They knew how it was going from what people told them.

The backlog aimed at adoption was demo sessions, showing examples, giving people an incentive to use it, and usability improvements to the framework. All of that pushes the capability at people. None of it says whether anyone is pulling. So alongside the telemetry, on every feature, both the ones you've already done and the new ones, make sure that as part of the lifecycle, there's an adoption stage.

Why faster engineering doesn't show up in the business

You're not going to get anywhere close to the 10x if you're just improving output in a certain area. Organizations right now are aiming to improve, and there's the promise of the 10x, so organizations that want to fulfill the promise of AI leverage need to look end-to-end. Otherwise, all they'll be able to show is local improvement.

The main thing is that AI accelerates some stages dramatically. Because of that acceleration, there's the potential to create bottlenecks even faster, or more and more stuff to pile up in between the stages. You can see both halves of that on a cumulative flow diagram. Since implement keeps growing and growing, it means I have extra implementation capacity that isn't reaching Done. It keeps sitting there in progress, and if I split the statuses a bit more I'd have implement and waiting for code review. And another pattern: when I do manage to send things out, I don't really manage to close the loop in adoption, in monitor-adapt-learn. Things get stuck at that stage a lot of time too.

That same AI enablement team had planned the next quarter on a twenty to thirty percent velocity gain that was assumed rather than observed, because adoption was still partial. That's wishful thinking.

Their leaders don't care about that local improvement. Maybe for right now they are able to get away with it, and that's part of what we're seeing right now: people are getting away with local improvement. But over time, leaders will become smarter and start to expect the actual outcome, the actual impact. They'll expect it end-to-end. It won't be enough to just say development is faster and we're creating much more code and we have many more PRs and maybe even we're code-reviewing the PRs. That's not going to be enough.

Where to put the lane so it actually holds

Concretely, what I usually do is create an epic lifecycle, a Kanban board of the epics that manages the life of the epic. We prioritized it, and now it's in planning, and now it's in work, and we released it, and now we're working on adoption. And we don't close it until we've made sure that the adoption is as we want it. Putting that state specifically in the lifecycle really helps to focus on it. Keep it on the epic rather than the story, because with a harness a story can open and close inside an hour, which is the wrong altitude to hold an adoption question.

A limit on that state also sends a signal: don't start new features, take care of adoption before starting new things.

And it can be interesting to look now, in hindsight, at the things you closed that are Done, and see whether there is already adoption of this feature, of this epic, or not. Even to move things and say: we have things that are fine, we have things we don't know, and we have things we know are not. That can be an interesting exercise.

The learning is worth doing at more than one point, too. You can do compound learning at the stage of having working software, and also at the stage after adoption.

Doesn't another lane just add overhead and slow flow?

Too many states is a real cost, and it's usually the first thing I cut. Looking at a board with too many states for that team, where another team's is simpler, the move is to simplify: every organization and its Jira. So this is one lane, on one class of work, not a board redesign.

Is there enough risk and uncertainty to justify the overhead of frequent feedback loops? Whether the people you shipped it to will actually pick it up is exactly that kind of uncertainty.

And the limit on that state does not mean sitting idle. I can work the board right to left: review telemetry for a live feature, unblock review, help test, release something, or close the learning loop on work that is already in flight. Starting another feature should come after those options, not before them.

In some cases, what I hear is simply "we don't have time to manage a more complex board. We don't have time to worry about adoption and impact". That's a great signal that something much deeper is going on. What the "system" is telling us is that it was designed and finetuned to generate activity, not to ensure impact.

Adding a lane to the workflow and using its presence on the kanban board to drive different conversations is one great way to start to reprogram your "system".

Impact Corner

I packaged the whole move as a skill you can run in your own agent, against your own board: extending-kanban-from-output-to-outcome. It carries the diagnosis questions, the lane with its entry and exit criteria, and the altitude argument. The backfill exercise, the answers to the overhead objection, and the coaching prompt and preference snippet are in there too.

/plugin marketplace add yyeret/ai-impact
/plugin install ai-impact@ai-impact

If you would rather just have the lane, this is it:

Released -> Adoption / Learn -> Outcome Confirmed

Entry: we believe the thing is useful and it's ready to be used.
Exit:  we have evidence that people are actually using it.

Does your board stop at output, or go all the way to outcome?

Does the setup of your board ensure that what you've done has moved the needle on behavior, or has just delivered?

Originally published at https://yuvalyeret.com/blog/your-kanban-board-ends-too-early/.

Teach your AI agents to help you Focus on Flow

Yuval Yeret — Wed, 29 Jul 2026 00:00:00 GMT

import AIPrompt from '~~/components/ui/AIPrompt.astro'; import { Content as 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.

Why these six got sharper with agents in the loop

None of the problems below are new. What changed is how quickly you reach them.

When a team can generate work far faster than it can review, decide on, or release it, every one of these failure modes arrives earlier and looks better on the way in. Everyone is visibly busy, more than before. More things are genuinely in progress. The dashboards that count activity all point up. And the queue in front of the humans grows the whole time, because the part that got cheap and the part that stayed expensive were never the same part.

That is why "are flow metrics worth it" is a more urgent question now than it was two years ago, not a less urgent one. The symptoms below used to build over quarters. With agentic development in the loop, teams reach them in weeks, and the faster the tooling gets, the less the activity numbers tell you.

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.

Teach your agents to ask about flow

Here is where this gets practical rather than philosophical. The questions above are the ones I ask on a first call, and they work because somebody who knows what to listen for is asking them. You now have something that can ask them constantly and cheaply.

Start with the prompt below as a one-off conversation. That is the low-commitment version and it is genuinely useful. But a prompt you paste when you remember to paste it is a habit you will drop by week three.

The version that sticks is putting it in the harness. Whatever your agents read as standing instructions, CLAUDE.md, AGENTS.md, a skills directory, a saved project prompt, is where flow awareness belongs, because that is the file they read every single time without being asked. Three things worth encoding: what a work item is for your team, which of the symptoms above you are currently worried about, and a standing instruction to say something when it sees one. Then when you ask an agent to pick up the next piece of work, it can notice that four things are already open and nothing has finished this week, and tell you so before it starts a fifth.

This is the same move as writing anything else down that you want to keep happening. An agent that has read your flow context will bring it up unprompted. One that has not will help you start a fifth thing very efficiently.

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/.

Do WIP Limits Still Make Sense When Agents Write the Code?

Yuval Yeret — Wed, 22 Jul 2026 00:00:00 GMT

import AIPrompt from '~~/components/ui/AIPrompt.astro'; import { Content as PromptContent } from '~~/data/prompts/calculate-kanban-wip-limits-ai-age-prompt.md';

Starting work has become easier.

I catch myself doing this. I start one agent on a dashboard, another on article research, another on a client artifact. Each start is rational. The agent is going to work for a while, so why should I wait?

A couple of hours later, I am the one carrying the map. Which decision is waiting? Which branch needs review? Which result do I no longer remember well enough to judge quickly? The agents are not overloaded. I am.

That experience is becoming normal. Anthropic's customer stories describe teams at Rakuten and developers at Ramp running multiple Claude Code sessions simultaneously. Anthropic's own advanced-patterns guide treats parallel instances as a real operating mode. One practitioner described the coordination problem of five active project sessions.

Maybe we have broken through an old human limit. More likely, we have made it much easier to walk into the old utilization trap with a crowd of cheap digital workers behind us.

This is the point I made in Stop Focusing on Utilization. Start Focusing on Flow. Keeping every resource busy is not the goal. In agentic development, an idle agent can be perfectly healthy. Human attention for steering, review, integration, and deciding what matters is usually more scarce than agent runtime.

There's still a limit to how much work we can process at the same time

That is why WIP limits should still mainly reflect human capacity and attention. The argument to the contrary is valid up to a point: long-running agents create useful waiting time, good isolation reduces interference, automated checks reduce review effort, and some humans really can supervise more parallel work than before. We have always used waiting time this way. A long build, a mainframe job, or a slow test suite gave us a reason to do something else rather than stare at the screen.

But “something else” does not have to mean another feature. While an agent works, I can improve tests, prepare telemetry, clarify a product decision, review the release path, or do other useful work inside the same feature. I can also work the board right to left: review telemetry for a live feature, unblock review, help test, release something, or close the learning loop on work that is already in flight. Starting another feature should come after those options, not before them.

There is another reason to be conservative. The human version of a context window is shared across every thread we are juggling. We compact it automatically, usually without noticing. Every additional feature pushes detail out, makes reorientation more expensive, and creates some quality loss. AI agents can have separate context for separate threads. I cannot.

So my default for one human or one pod is one actively guided feature. A second feature becomes a legitimate experiment when the first agent is running a genuinely autonomous loop, such as working toward a /goal, rather than waiting for continuous prompting. Even then, the efficiency gain has to pay for the cognitive load.

There is a stronger counterexample. If an agent system can independently choose a bounded task, implement it, test it, deploy it, watch the outcome, and recover inside clear policies while humans sample by exception, human attention may no longer be the immediate constraint. The relevant limit might then come from environments, release risk, customer exposure, or compute economics. I think most teams are still far from that operating mode. Until agent output can move safely through the whole loop, counting agent sessions as capacity mostly moves unfinished work toward the next human.

One of the first things that shows up is frustration

Even individually, before you get to teams, I see it in my own work and I hear it from coachees as well. They start more things, because it is a very fragmented interaction mode with the agents, and it becomes a headache. It is both a headache and things fall to the sidelines. So it is clear that there is a price we pay for not paying attention to the work in progress we are juggling.

One of the first things that shows up is actually frustration and burnout. It is simply unsustainable pace. Even if you are working the same amount of hours, you are not in the flow zone as much.

That is one thing that happens. The other is that the flow time is longer. Despite the fact that agents are working very fast, if the humans are juggling too much, there is a chance that items will stay stuck waiting for the humans. The flow efficiency, as we refer to it in the flow world, gets worse and worse, because you do not have time and you struggle to even know what to pay attention to.

So I would invite you to measure, to have some telemetry. How long does it take from the moment you start an agent session on a work item to the point that that work item gets to the point that it delivers an outcome? And actually measure flow efficiency, and see.

Limiting new starts is definitely a worthwhile starting point. What it does is it gives you, first of all, the ability to focus on the fewer things that flow and improve the flow efficiency. It also creates some slack time to reflect on the health of this overall system and start to come up with ways to actually manage the WIP more effectively.

Then use AI on the juggling itself

There is another point, which is using AI to actually improve the ability to manage and to juggle multiple sessions, in a couple of different ways. One is to just make it easier to manage what is waiting for you as a human, and to have agents as flow facilitators.

The other is the cost of getting back in. Every time you need to go back into an agent-driven session, how long does it take you before you are actually working again? That is one of the things to work on improving.

Count the feature once

A feature flowing through Spec Kit's Spec → Plan → Tasks → Implement path is one feature, not four WIP items. Several BMAD personas discussing it are not several delivery pods. Two review agents examining the same pull request are parallel perspectives on one item.

Implementation-task fan-out, worktrees, pull requests, agent outputs waiting for input, and human review decisions are how that feature moves. They are useful workflow signals. They may need orchestration policies. But they do not become extra WIP items that you add to the feature count. The feature stays in WIP while it is being built, waiting for input, under review, deployed, or awaiting the learning needed to call it Done.

The human question is simpler:

Am I actively guiding the AI? That is much like coding. The feature is active, and the human is not actually free.
Is the agent pursuing a goal autonomously? That creates real waiting time and may justify pulling another feature, up to the point where context switching starts damaging judgment and quality.

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3 text-slate-900"> <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/count-feature-once.webp" alt="Hand-drawn sketchnote showing several AI agents working inside one feature boundary that still counts as WIP of one, with finishing first before considering an autonomous second feature" loading="lazy" class="h-auto w-full" /> <figcaption class="mt-3 text-sm text-slate-700"> Fan-out inside Feature A is still one feature in WIP. A genuinely autonomous goal loop can justify Feature B, but only after looking for useful same-feature and right-to-left finishing work. </figcaption> </figure>

Start the active feature limit at 1 for a solo pod. Test 2 only when the agent can run independently toward a clear goal, same-feature and right-to-left work are genuinely exhausted, and the second feature improves throughput without more reorientation, stale output, merge churn, rework, or quality loss. Three simultaneous features should require unusually strong evidence.

The upstream funnel and the downstream release/adoption path are separate WIP conversations. You can keep feature concurrency under control inside the spec-driven workflow and still drown in ideas before it or releases after it. Count end to end wherever the next meaningful learning boundary sits.

Start with how the team actually collaborates

Headcount alone is almost useless for choosing the number. The same six people can behave like one whole-team swarm, two independent trios, three stable pairs, or five builders feeding one reviewer.

Start with one actively guided feature for each independent pod. Treat that as a starting point. Let a pod try a second feature only when its agent is running an autonomous goal loop long enough to create useful waiting time, the pod has already looked for finishing work, and the extra concurrency pays for the cost of switching context. Then check whether a shared reviewer, architect, decision maker, environment, or release gate forces the number back down.

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3 text-slate-900"> <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/collaboration-topology.webp" alt="Hand-drawn sketchnote showing the same six people as one swarm, two trios, or three pairs, producing different active-feature WIP limits and a shared review cap" loading="lazy" class="h-auto w-full" /> <figcaption class="mt-3 text-sm text-slate-700"> Do not derive WIP by dividing headcount. Count independent end-to-end pods, then look for the shared human constraint that makes the multiplication stop. </figcaption> </figure>

For the three-pair example, I would start with three active features and perhaps one shared Ready slot, for a combined limit of four. If each pair later proves it can carry a second autonomous feature without more aging or quality problems, the team could try six active features. That is a later experiment, not the default just because each pair has agents.

How much WIP is sustainable depends on how much you trust the agents

There is a second dimension to that topology question, and my starting point is to point back to the human experience people have had around span of control: how many people did they manage to effectively manage, and what are some of the best practices they used in that space. Then I want to explore that statement rather than accept it. Is it actually true that the cognitive load of managing agents along the lines we are talking about is similar to managing humans?

There are multiple modes of management, both for humans and for agents. There is the mode where a person is working towards an intent, towards an outcome, and does not need constant micromanagement. There is the mode where you are still building them, and that may require a certain type of interaction and load on the manager. Humans might require some subject matter expertise sort of direction as well, depending on the context. If you have people that you can trust and they know their work better than you, then it is a different interface.

Similarly for agents. If you are still nurturing, developing, building the compounding expertise of the agents, it probably requires much more cognitive load. If the agents can actually work towards goals by themselves because they are trusted at this point, then maybe you can start to build on more and more WIP, because you trust them. The interface is lighter weight. You become a stakeholder that reviews their work from time to time rather than a collaborator.

So one approach is to just experiment. If you feel like you are in a sustainable flow zone, add.

Decide whether you actually want the limit to change anything

Before calculating anything, ask a more basic question: do we want to keep doing what we are doing, or change how we work? A limit close to current WIP will mostly preserve current behavior. That may be exactly what you want if work is flowing well and the team has no appetite for a change.

But if you notice that you or your team are spread too thin across several areas and you want to do something about it, lower the limit until it occasionally stops another start. That uncomfortable moment is useful. It creates a reason to finish something, help someone else, review, pair, remove a blocker, or improve testing and the workflow before pulling more work.

If nobody intends to behave differently when the limit is reached, the number becomes WIP-limit theater. The policy cannot create collaboration on its own. It can create the nudge and the conversation.

Slack for flow is positive WIP, not a missing slot

I used to hear people create “slack” by taking a person away from the WIP calculation. That confuses two different things.

Capacity slack is human attention available to help, review, improve the system, or handle an incident.
Flow slack is a small amount of controlled WIP that protects the constraint from ordinary hiccups.

In The Goal, Herbie sets the pace of the Boy Scout hike. Letting the faster scouts run far ahead does not make the troop arrive sooner; it creates distance (inventory) between them. Drum-Buffer-Rope uses a buffer to protect the constraint and a rope to control release. The point is not zero inventory. The point is enough protection without an uncontrolled gap.

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3 text-slate-900"> <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/buffer-needs-rope.webp" alt="Hand-drawn sketchnote contrasting controlled release through a one-item Ready buffer and review rope with uncontrolled AI starts creating a large pull-request queue" loading="lazy" class="h-auto w-full" /> <figcaption class="mt-3 text-sm text-slate-700"> A small queue before the constraint can protect flow. A growing queue created by unconstrained starts is just delayed feedback wearing a busy-looking disguise. </figcaption> </figure>

This also explains why an expedite item should consume a real slot or displace a normal item. If “urgent” silently adds WIP, the rope is decorative.

With no useful history, compare three levels of protection

Start with the active feature count your collaboration pattern can credibly support. Then compare a combined limit with one extra slot, half again as much WIP, and twice as much. For example, if you believe the team can actively guide four features, the three combined limits are five, six, and eight.

Candidate	Example with four active features	Favor it when	What it protects	Main risk
One extra slot	`4 + 1 = 5`	Replenishment and recovery are fast; aging and feedback delay are expensive	Ordinary small hiccups	The constraint may starve during larger variation
Half again	`4 × 1.5 = 6`	Variability, dependencies, and interrupts are moderate	A pooled buffer of roughly half the active load	Inventory can age without being useful
Twice active work	`4 × 2 = 8`	Recovery is slow or constraint starvation is very expensive	The strongest heuristic protection	The biggest queue, context burden, and feedback delay

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3 text-slate-900"> <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/wip-choice-spectrum.webp" alt="Hand-drawn WIP choice spectrum for four active features, comparing limits of five, six, seven, and eight from one-extra, half-again, double, median, and 85-percent-of-days approaches" loading="lazy" class="h-auto w-full" /> <figcaption class="mt-3 text-sm text-slate-700"> Moving left is a stronger nudge toward focus, collaboration, and faster feedback. Moving right preserves more concurrency and gives the constraint more protection from running dry. </figcaption> </figure>

When the starting active count is one, both “one extra slot” and “twice active work” produce a combined limit of two. That is not a contradiction. It is a reminder that these are rough conversation starters. Recovery time, starvation cost, and human context matter more than the arithmetic.

Use historical percentiles when the history means something

Percentiles give you two more candidates. Sort the observations from lowest to highest. The 50th percentile, also called the median, is the middle: the system was at or below that WIP level on half of the observed days. It is often abbreviated p50. The 85th percentile is the level the system was at or below on 85 percent of observed days. It is often abbreviated p85. For example, if the 85th percentile is 7, WIP was 7 or lower on roughly 85 out of every 100 observed days and higher than 7 on roughly 15.

These are descriptions of what happened, not probabilities that a proposed limit will work and not automatically the limits you should choose. First name what you measured, then interpret the percentile.

Historical actual WIP answers: how much WIP did this system carry in past daily snapshots? The level the system stayed at or below on 85 percent of days is a gentle limit; it changes only the unusually crowded days. The level it stayed at or below on half the days is a much stronger intervention; it should force a conversation often enough to change how the team works. After that meaning is clear, p85 and p50 are useful shorthand.

Items consumed during one protection or replenishment interval answers: how much must be ready so the constraint is unlikely to starve before the next refill? Here the 50th percentile protects a typical interval. The 85th percentile carries more inventory to protect 85 percent of historically similar intervals.

Those are different questions. Do not average the answers.

Historical data also ages. If item definition, staffing, workflow, agent use, or replenishment cadence changed, segment the history. An old queue is evidence that inventory existed. It is not evidence that people had capacity to handle it.

As a stable-system cross-check, use Little's Law:

target WIP ≈ throughput rate × target cycle time

If a pod finishes four comparable features per week and wants a one-week average cycle time, a WIP candidate of eight deserves scrutiny. The equation is a consistency check, not a precision calculator for an unstable system.

This aligns with Daniel Vacanti's emphasis on WIP, throughput, cycle time, and age as the core flow evidence in The Kanban Guide, and with Don Reinertsen's warning that high utilization creates queues whose economic cost is routinely underpriced. I have made the same practical point in Why Focus on Flow Metrics? and AI Coding Moved the Bottleneck.

Size Ready queues by replenishment cadence

Think about the supermarket. If you shop once a week and consume four items a week, you need more on the shelf than if you shop twice a week. The team's throughput did not change. The replenishment interval did.

With no data, estimate how many items the team will consume before the next replenishment, then compare one extra item, half again, and twice that amount. With data, compare the amount consumed in a typical interval with the amount that covered 85 percent of historical intervals. Once the meaning is clear, you can call those p50 and p85.

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3 text-slate-900"> <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/replenishment-cadence.webp" alt="Hand-drawn supermarket sketchnote showing Ready limits of five for weekly replenishment, three for twice-weekly, and two for continuous replenishment at four items per week" loading="lazy" class="h-auto w-full" /> <figcaption class="mt-3 text-sm text-slate-700"> Queue limits depend on how often you can go back to the supermarket. Faster replenishment lets you carry less work without starving the next stage. </figcaption> </figure>

This is especially useful for Ready for Review, Ready for Test, and Ready for Release. Size the queue around what the receiving stage can consume during the protection interval. Better yet, put the waiting and active statuses under one combined limit so a full queue stops upstream starts.

A real historical example: Stories and Bugs only

Here is an anonymized example from a real board. I filtered out Epics because they are a different flow unit. Over 91 daily observations, Stories and Bugs had current WIP 21. WIP was 23 or lower on half the days (the 50th percentile, or p50), 26 or lower on 85 percent of the days (the 85th percentile, or p85), and reached a peak of 33.

The workflow and WIP regime changed during the period, so I also looked at the 36 days from June 17 through July 22. In that window, WIP was 23 or lower on half the days and 24 or lower on 85 percent of the days. The peak was 26, and current WIP was 21. I would treat 23 as a data-only system experiment, not yet a recommendation.

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3 text-slate-900"> <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/wip-history-stories-bugs.webp" alt="Hand-drawn bar chart of Stories and Bugs WIP over 91 days, with weekly medians, half-days-at-or-below 23, 85-percent-of-days-at-or-below 26, recent-regime shading, and current WIP 21" loading="lazy" class="h-auto w-full" /> <figcaption class="mt-3 text-sm text-slate-700"> This redraw uses only Stories and Bugs. In the recent 36-day window, WIP was at or below 23 on half the days and at or below 24 on 85 percent of the days. The chart is evidence about past inventory, not proof that the human system can support it. </figcaption> </figure>

For the same recent window, the combined-column 50th-percentile (p50) candidates were:

Combined stage	Current	p50	p85	Data-only starting experiment
Development + Ready for Code Review	8	8	9	8
Code Review + Ready for QA	2	3	4	3
QA + Ready for UAT	3	6	7	6
UAT + Ready for Release	8	6	8	6

The 50th-percentile stage candidates happen to sum to the system's 50th-percentile WIP of 23. Do not turn that coincidence into a rule. Stage percentiles do not normally add to a system percentile because their peaks can occur on different days.

Before using 8 / 3 / 6 / 6, I would ask: How many human collaboration pods can really carry development? Who reviews? How often can QA and UAT replenish? Is release cadence responsible for the inventory at the right edge? If UAT can release only weekly, the queue conversation is different from a team that can release continuously.

Put active and Ready statuses under one combined limit

I have recommended this board pattern for years: keep the active state and the downstream Ready state distinct, but put both under one combined WIP limit.

Examples:

In Progress + Ready for Code Review
Code Review + Ready for QA
In QA + Ready for UAT
UAT + Ready for Release

This controls the work owned by the receiving stage, including the work it has completed but the next stage has not yet pulled. It also avoids the loophole where a team “finishes” work into an unlimited queue.

<figure class="my-10 overflow-hidden rounded-2xl border-2 border-dashed border-teal-700 bg-amber-50/30 p-3"> <div class="mb-3 flex flex-wrap items-center gap-3 px-1 font-heading text-slate-900"> <span class="rounded-lg bg-teal-700 px-3 py-1 text-sm font-bold tracking-wide text-white">REAL JIRA EXAMPLE</span> <span class="text-base font-semibold">Active + Ready under one column limit</span> </div> <div class="overflow-x-auto rounded-xl border border-slate-300 bg-white"> <a href="/assets/images/posts/calculate-kanban-wip-limits-ai-age/jira-board-wip-limit-configuration.webp" target="_blank" rel="noreferrer" > <img src="/assets/images/posts/calculate-kanban-wip-limits-ai-age/jira-board-wip-limit-configuration.webp" alt="Jira board configuration showing paired statuses inside columns and maximum WIP fields, including In Progress with Ready for Code Review, Code Review with Ready for QA, In QA with Ready for UAT, and UAT with Ready for Release" loading="lazy" class="h-auto w-full min-w-[620px] sm:min-w-0" /> </a> </div> <figcaption class="mt-3 text-sm text-slate-700"> Jira can put an active status and its downstream Ready status under one combined column maximum. The counts shown are today's snapshot. Percentile decisions require WIP history over time. The visible maximums are an example, not my recommendation. </figcaption> </figure>

Jira applies the column maximum to the combined count and can still show the mapped statuses as separate drop zones when a card moves into the column. Atlassian documents both the combined column constraint and the separate status drop targets. The maximum is a visual signal, not a hard gate. The team still needs an explicit pull policy when the column is full.

How the guidance changes across spec-driven workflows

The frameworks shape the workflow. They do not set capacity.

Spec Kit

Start with one solo feature moving through Spec → Plan → Tasks → Implement. Parallel research, task fan-out, and outputs waiting for human input all remain inside that feature. The Spec Kit documentation gives you durable artifacts that make the WIP policy executable: count active feature directories/specs, not the agents or tasks inside them. Consider a second feature only when the first is progressing through a truly autonomous goal loop and there is no useful same-feature or right-to-left work to pull.

Compound Engineering

The Compound Engineering loop moves through Brainstorm, Plan, Work, Simplify, Review, and Compound. Multi-agent review is fan-out on one result, not another feature slot. If the agent is working autonomously, use the time to simplify, review, compound, or finish something already in flight before starting another feature.

BMAD

BMAD offers many specialist agents and Party Mode. Personas are roles, not end-to-end pods. One solo human with twelve available personas still starts with one feature. In multiplayer mode, two trios that independently steer features start with two active slots. Each pod can test a second slot later if its agents are genuinely autonomous and the added context pays off. If both trios need the same architect or product owner for every decision, that shared queue may lower the useful limit.

Superpowers

The Superpowers subagent-driven development skill uses fresh implementer and reviewer agents while explicitly avoiding parallel implementers and clearing review before the next task. That is a useful orchestration policy inside the feature. It does not create a second WIP count alongside feature WIP.

Matt Pocock's skills

Matt Pocock's skills compose specification, tickets, implementation, and review. Standards and Spec review agents may inspect one diff in parallel, but they converge into one human decision. The tickets, implementation branches, and review outputs are activity inside one feature flow. They do not justify pulling a second feature by themselves.

The common pull rule is simple: count the feature once, define the limit, and define what happens before anyone starts another feature. First, find useful work inside the feature the agent is already advancing. Second, work the board right to left: review, test, repair, simplify, generate evidence, integrate, release, inspect telemetry, or stop obsolete work. Only then consider another feature, and only when the current agent loop is genuinely autonomous.

Common questions practitioners actually ask

We are a team of six. What number should we put on the board?

First ask how the six people collaborate. If they work as one swarm, start with one active feature and one protective slot, for a combined limit of two. If they work as two independent trios, start with two active features and compare combined limits of three or four. If they work as three stable pairs, start with three active features and compare four, five, or six. If everyone feeds one reviewer, set the review constraint first (often 1 Reviewing + 1 Ready = 2) and let it govern upstream pull. Test a second feature per pod only after autonomous loops and flow evidence justify it.

I work alone with several agents. Is a WIP limit of one too conservative?

No. One actively guided feature is the right default. Agent tasks and waiting inputs inside it are still that one feature. When an agent is running autonomously toward a goal, first look for useful work inside the same feature, then work the board right to left to finish or learn from existing WIP. If those options are exhausted, test a second feature. Keep it only if the efficiency gain outweighs context reload, forgotten details, stale outputs, merge churn, rework, and quality loss.

Our agents can generate code much faster than review. Should implementation get a bigger limit?

No. That feeds the constraint. Limit Ready for Review + Reviewing around reviewer consumption, then use idle implementation capacity to prepare evidence, reduce change size, improve automated checks, repair failures, or help review. I cover this pattern directly in AI Coding Made Code Review the Bottleneck.

As I told one team in a recent private workshop, “Coding is ten times faster, but code review is still the same speed.” The exact multiplier will vary. The queue pattern is what matters.

We already have WIP of 15. Should we set the limit to 15?

Only if you are comfortable with the current pattern. A limit of 15 will mostly document what the system already does. If people feel spread too thin and want to change, compare the WIP level the system stayed at or below on 85 percent of days as a gentle ceiling, the level it stayed at or below on half the days as a stronger intervention, and an aggressive experiment near half current WIP. If those historical levels are 13 and 10, I would discuss 13, 10, and 7-8, then ask which one is likely to create the behavior change the team actually wants.

What if requests arrive whether we have capacity or not?

Do not pretend the arrival queue can be blocked. Keep it visible and govern it with service and triage policies. Apply the strict limit to treatment/processing work. That is the distinction I make in How to Limit WIP When You Cannot Block Arriving Work Requests.

How long should we keep the experiment?

Usually two to four weeks, long enough to experience normal variation but short enough to change course. Watch throughput, cycle-time distribution, work-item age, starvation, blocked time, limit exceptions, review age, context-reload time, forgotten agent sessions, merge churn, rework, and quality. Raise the limit only when throughput improves and the other signals remain stable.

Use the WIP Limit Configuration Coach with your agent

The prompt below asks about your workflow, collaboration topology, agent autonomy, shared human constraints, flow data, and replenishment cadence. It calculates all five candidates, recommends one starting configuration, and translates it into board and agent pull policies.

The number is not the policy. The policy is what happens when the number is reached. If the answer is “we start one more because the agent is idle,” you do not have a WIP limit yet.

Originally published at https://yuvalyeret.com/blog/calculate-kanban-wip-limits-ai-age/.

Scaling Product Orgs with Portfolio Agility

Yuval Yeret — Thu, 02 Jul 2026 00:00:00 GMT

Your portfolio process isn’t slowing you down by accident

You built empowered product teams. You wrote down a product operating model. And somehow decisions still stall, competitors still pivot faster than you do, and every initiative that actually matters turns into a program with a coordination tax attached. The cross-product process you added to bring order and reduce risk doesn’t stop the wrong things from getting built; it just makes building anything slower. That gap between the operating model on paper and the one people work in every day is the portfolio problem, and most of the standard answers to it are borrowed from project and program management, which is exactly why they grind against the way product organizations want to work.

This minibook takes a different route. Instead of standing up structures and processes first, it starts with the portfolio behaviors you want (the conversations, the thought process, the decisions), and then asks what the minimum process is that would actually produce them. That is the main thing separating this from frameworks like SAFe Lean Portfolio Management. The test isn’t whether you ran the ceremony on schedule. It’s whether someone in the room was willing to ask “do we really have the capacity and the attention span for this, or should we finish what’s already in flight and reconsider?”, and whether the answer changed what you did next.

What this looks like from where you sit

Three symptoms show up together, and leaders usually name at least two of them before they name the portfolio:

Decision paralysis. Uncertainty and complexity bring things to a standstill. Teams operate in silos and can’t adapt without a meeting to authorize it.
Missed opportunities. You watch competitors pivot while your organization works hard to hold the status quo in place.
Cross-functional hell. You created agile and product teams, and yet every meaningful change still requires so much collaboration that it becomes a project or a program.

That is the portfolio challenge: managing a growing set of technology and product investments well enough that the ones you picked actually land. It is an established practice, which is part of the trouble. The established version of it leans on traditional project and program management, and those habits clash with the product operating model you are trying to run underneath.

Introducing The Portfolio Agility Trailmap

The Portfolio Agility Trailmap is a practical, no-fluff minibook for leaders of growing organizations and practicing portfolio leaders who want to use the foundational practices of multiple-product/portfolio agility to evolve their organization from a feature factory managing scattered investments to creating a product-oriented mega-lab that drives growth, value, and resilience. This is a trail map, not a roadmap (or a blueprint). That means there are multiple paths to get from where you are now to where you want to go. A trail map will not tell you which route to take. The purpose of any trail map is simply to familiarize yourself with the terrain.

What you’ll walk away with

This is a straightforward introduction you can adapt to a scale-up or mid-sized tech and product context, not a dense reference. By the end you should be able to:

Decide whether you need a defined portfolio operating model at all, or whether your context doesn’t warrant one yet.
Start where you are, using visibility, focus, and flow as a low-risk first intervention rather than a reorg.
Descale the portfolio by organizing around outcomes and products, so there are fewer dependencies to coordinate in the first place.
Reduce risk on your most strategic initiatives by moving from outputs to outcomes and steering on evidence instead of on reported progress.
Treat the operating model itself as a product, with its own outcomes, reviews, and iterations.
Show up as a portfolio leader whose language and behavior model what you’re asking of everyone else.

How to read it

You can go cover to cover for the lay of the land, or pick your own route, since it’s a trail map rather than a roadmap. Either way, stop and reflect occasionally: are you seeing something new? Is there a fork here you hadn’t considered? Here is how four leaders actually made their way through:

Mark wanted better empiricism and less investment risk, so he refined the definition of workflow to encourage product-discovery behaviors, and introduced one explicit decision: do we go through discovery, or skip it and go straight to delivery?
Susan, a product leader at a midmarket company, wanted her teams empowered even on the biggest initiatives, so she structured those initiatives around outcomes and used OKR language instead of classic PRDs and business cases.
Ed’s enterprise was running at an unsustainable pace. The intervention was a portfolio-level planning exercise borrowed from agile planning, where the groups involved built a realistic roadmap in pull mode rather than having one handed to them.
Emily, a COO in pharma, was trying to run several organizational transformations at once from a top consulting firm’s recommendations. Key people were stretched thin across their day jobs and multiple transformation "Sprints". That forced a hard conversation about focus, which led to empowering a bigger group to own one specific mission, and to bringing discovery and empiricism language into how the initiatives were run. Adoption got faster once the work got narrower.

Trailmap Chapter Navigation

Chapter	Topic & Core Focus
Chapter 1: Why Scaling Makes You Slower	The scaling trap, coordination tax, and diagnostic questions for your operating model.
Chapter 2: Finding an Operating Model That Regains Traction	Why scale-ups are portfolios and how to evolve portfolio agility.
Chapter 3: Understanding Your Portfolio	Visualizing invisible work, establishing flow boundaries, and descaling by organizing around outcomes.
Chapter 4: Accelerating Flow on the Initiatives That Matter	Right-to-left Kanban reviews, bottleneck elevation, and the 4 key portfolio flow metrics.
Chapter 5: Reducing Risk and Improving Outcomes	Moving from project to product, outcome-oriented cards, and evidence-based steering.
Chapter 6: Using the Trail Map to Build Traction	Designing product-oriented transformation, walking the talk, and continuous inspection.

The objection worth taking seriously

If you have been near a portfolio before, the behaviors-first framing should make you suspicious. Process discipline is what portfolio management is for. Frameworks like SAFe Lean Portfolio Management specify the cadence, the roles, and the artifacts precisely because leaving those to good intentions is how organizations end up with a spreadsheet nobody trusts and a quarterly meeting nobody prepares for. Say "we care about behaviors, not process" out loud in a room of experienced portfolio people and at least one of them will hear "we're not going to hold anyone to anything."

That objection is fair, and the answer is not that process doesn't matter. It's that process is the dependent variable. Pick the behavior you want first (someone willing to say "we don't have the attention span for this right now") then install the smallest process that reliably produces it, and keep checking that it still does. A Portfolio Kanban, a PI Planning event, or a monthly review can all carry that conversation; the format matters much less than whether the conversation happens, whether the thought process gets applied, and whether decisions change as a result. What this approach rejects is the reverse move: adopting a full ceremony set on the theory that the behaviors will follow. They usually don't, and then you are stuck defending the process instead of the outcomes. So the standard here is a Minimally Viable Process: enough structure to move the behaviors you care about, and no more than you can honestly sustain.

Chapter 1: Why Scaling Makes You Slower

Meet Mary, a co-founder of FlowImpact Yoga (FIY), a rising power in products serving the yoga and pilates industry. A successful initial product let FIY invest in extending the suite: more capabilities for their core client, Yoga Studios, plus a branch out to Pilates studios and gyms with a yoga studio. The product and technology organization recently crossed 200 people, and with that size came the expectation of more throughput, more speed, and more impact to support the company’s growth while keeping existing customers happy. Mary has run product and technology through all of it.

Recently she noticed a problem she can’t explain away. As the organization grew, it could work on more products and initiatives, but overall throughput hasn’t grown at the pace of the investment. It’s stuck, and arguably regressing. Worse, the features that do ship aren’t landing the way they used to. It’s full gas in neutral. More time goes to meetings and coordination, and managers have become the bottleneck as they try to broker cross-functional dependencies across silos and emerging fiefdoms. Instead of a lean, flexible startup, FIY has quietly become a slow bureaucracy. There must be a better way.

Why Does Scaling Lead To Stalling?

So what’s going on here? FIY is representative of what we see in many scale-up organizations. Small companies are inherently agile in their path to discover, develop, and deliver their first products (also known as pre-Product Market Fit). As these companies scale up, however, several patterns emerge almost unavoidably. Let’s look a bit closer at FIY's growth path:

Once FIY’s initial product was successful, they launched a new product to increase their customers' lifetime value. This meant scaling up the product organization to multiple teams. Without a strategy/operating model for managing those teams, the span of control and perceived need for involvement hampered decision-making. Leadership became a decision-making bottleneck.
Extending FIY’s product line meant that each product now has its own goals and priorities, but they are all dependent on the same shared resources for delivery. Leadership oversight is required to foster collaboration across product teams and identify delivery synergies.
FIY’s Leaders are now splitting their time between newly introduced growth initiatives while still being expected to provide high-quality oversight to their existing product lines. Growth and business dynamics necessitate transformation (e.g., adopting a different marketing/sales motion, adopting GenAI, moving to SaaS). These are often complex and require time-intensive collaboration across functions. Devoting the time and energy needed to work through cross-functional issues reduces the capacity of team members to stay on top of their other delivery work. At this point Mary is realizing that FIY needs to upgrade its operating model. What worked for a singularly focused small product team is not up to the scale of FIY’s current product organization’s size and complexity.

Does your technology/product organization need an operating model upgrade?

Over to you now. Ask yourself the following questions to uncover any issues with your current operating model:

Are you managing multiple strategic initiatives that span multiple teams across the organization?
Are you now developing/maintaining multiple products?
Are the leaders becoming a bottleneck?
Are you considering standing up a project/program management discipline? Answering “Yes” to these questions indicates that you might need to upgrade your operating model.

Chapter 2: Finding an Operating Model That Regains Traction

The usual suspects: company-level operating systems for scaleups

Mary’s search for better ways to manage the growing complexity starts outside the product and technology organization. One of FIY’s board members, a partner at the VC firm that led their B round, suggested OKRs to create company-level clarity and alignment. Other systems you might find in companies like FIY are the Entrepreneurial Operating System (EOS), Scaling Up, or 4 Disciplines of Execution (4DX). The common thread is that they all include goals, whether they call them Goals, Rocks, OKRs, or WIGs.

So FIY’s product and tech organization wrote objectives and key results for every team and initiative, and other than one more management tool to keep current, nothing much changed. The work toward those goals is still managed the way it always was, goals are still set by department, and cross-functional dependencies are as painful as ever. Mary is still looking for a way to scale her organization’s speed, throughput, and impact. In other words, she wants her organization to stay agile as it scales.

Staying agile as you scale

Agile ways of working are designed for single products. Even the multi-team scaling patterns assume cohesion and unity of purpose. But suppose we did want to use agile principles and techniques to align investments, priorities, and execution across multiple separate products and initiatives. What would that actually look like?

A scaling company IS a portfolio

Mary isn’t running a classic IT shop and she isn’t a PMO. But she is starting to realize that she is managing a portfolio: multiple products mixed with multiple organizational strategic initiatives. If you’re leading a growing company with hundreds of people and dozens of teams, that’s probably your reality too: a set of investments and initiatives that map to teams and functions in a non-trivial way. Portfolio management is the layer that keeps those aligned to strategy and actually executed.

Managing and Improving Portfolio Agility

Here’s a quick overview of what it means to manage a portfolio using an agile perspective:

Start by recognizing that you already have a portfolio of investments, even if it’s not formalized.
Start to understand your portfolio and the flow (or lack thereof) of your significant investments.
Begin to actively manage the flow and shape demand. This includes the brave action of saying “No” or “Not yet”.
Turn the collection of projects into cohesive products: creating an intentional balance between technology and business investments.
Decide which decisions to manage at the portfolio level, and which decision-making authority you empower the teams to have. A key enabler for this is deciding what is the threshold at which work will be managed at which level.
Improve alignment AND autonomy. Teams are free to innovate, while strategic goals keep everyone focused on the outcomes that matter. Eventually, over several quarters if not years, you’ll be operating in full agility mode: treating your entire business like a product. This will not happen overnight! Be patient. This approach isn’t for everyone. It’s not a cookie-cutter process. It doesn’t have a certification training. There aren’t hordes of coaches who can claim they know it. And there’s no framework to parrot. But if you’re interested in adopting a principle-based, evolutionary, light-weight, focused intervention approach to improving the speed, throughput, and outcomes of your product/technology organization, you’re in the right place.

What about SAFe Lean Portfolio Management? If your organization is already invested in the Scaled Agile Framework (SAFe) you’re probably familiar with SAFe Lean Portfolio Management (LPM) - a framework geared toward improving portfolio-level agility, with a special focus on the context of enterprise-scale IT. I find the full LPM to be a bit much for scaleups and mid-market organizations. However, some of the concepts of SAFe LPM are aligned with the approach to portfolio agility described here, and are applicable to any organization that’s tackling multiple initiatives, products, and dozens of teams. I find it useful to complement SAFe LPM with a focus on outcomes and evidence-informed steering, so even if you’re already familiar with LPM, I invite you to keep reading.

Chapter 3: Understanding Your Portfolio

Why the hard initiatives get hidden rather than fixed

As we discussed earlier, companies struggle to drive strategic cross-functional initiatives, and it gets worse as they scale and the work spans more teams and more leaders. Companies know these initiatives are tough, so they try to avoid them and divide and conquer instead. Running them siloed doesn’t make the challenges disappear, though. It just hides them. Strategic, deep transformations do require collaboration across functions and disciplines. It’s time to shine a light on what’s really going on in your organization.

You can’t improve what you can’t see

The first step to improving the flow of work across the organization is making the big picture visible. Without visibility, improvement isn’t possible.

So how do you start ‘seeing’ flow (or the lack of it)?

A Kanban board is a simple, effective tool for mapping your organization’s most significant initiatives. Think of it as a visual snapshot of what’s happening across your teams. Your Kanban might include a long list - or just a few work items - either one is perfectly fine. Don’t worry about defining 'significant' right now either. You’ll have time to refine and prioritize later. Start with what you have. Here’s a high-level view of what it takes to start to see flow using a portfolio kanban board:

Figure out the boundaries of your workflow - where are we starting to track initiatives? When do we finish tracking them?
What is the workflow for these initiatives? What stages do they go through? These turn into columns on the board.
Create a sticky note, box, or card for every initiative. Place the card in the appropriate column based on the stage its currently in.
Look for implicit connections. Are there multiple initiatives that are tightly dependent on each other - that should be managed as one unit?

Establishing Flow Boundaries

Defining the start and finish boundaries. It might look obvious, but there are some interesting questions to explore here: When do you start managing initiatives? When the initiative is still just an idea? (a twinkle in a business stakeholder’s eye…) Or when the “business” is ready to ask technology to support it? The earlier you intercept an initiative, the more opportunities to improve speed and impact you can identify. For now, it might make sense to start with work that is already in flight and be ready to evolve towards Idea management later as you get buy-in.

When do you stop managing initiatives? Remember, Agility is about execution. We are not managing everything. We are responsible for taking Ideas aligned to strategy and transforming them into deliverable outcomes. Once the outcome has been achieved, the maintenance and measurement of that outcome moves off the Portfolio Kanban and onto the Operational roadmap. So it’s critical to define when is the right time to move to “business as usual”? Again, start with where you are right now and discuss whether to make a change to this flow boundary now or consider it later. Identifying What Should be on the Board

Which investments SHOULD be managed at the Portfolio level?

Here’s a simple technique you can use to answer this question. Analyze the cards on your portfolio kanban according to the three criteria below:

Investment size
Strategic opportunity/risk
Level of cross-product collaboration needed

Duration vs Size - a common guidance you might encounter is to consider investments that might span multiple quarters as worthy of portfolio consideration. On paper, this could be a good proxy for size. In reality, many organizations spread their capacity and attention too thin across too many investments - meaning that initiatives might span multiple quarters even though they’re not that big - because only a few people are working on them, and they’re also multi-tasking. This is why size is a better criteria.

Use 1 for low/small, 2 for medium, 3 for high. Add up the numbers for the 3 criteria:

3-4 This should probably NOT be a portfolio-level card.
5-6 Let’s have a conversation about whether we want to manage these
7-9 This SHOULD be a portfolio-level card. Why? We want the portfolio conversations to focus on investments/initiatives with more significant, higher opportunity/risk, high cross-product collaboration. For all other investments, decision-making should be decentralized to empowered product teams. This doesn’t mean portfolio leaders don’t care about these other investments. However, they trust their product teams and maintain a lighter touch interface compared to those investments the portfolio leaders want to focus on. We managed these non-portfolio initiatives by including an "Awareness" slide in the monthly Portfolio review meetings. Smaller projects being worked on by the Teams that were also doing "portfolio" work were shown on a slide "For Awareness Only" so that leaders knew the work was being done, but they were not expected to "manage" it. Over time, you’ll want to sense whether you’re managing the right altitude at the portfolio level:
Altitude Too Low: Conversations become tactical, lengthy, business leaders start to lose interest.
Altitude Too High: Strategic work isn’t discussed, side channels are used where the key behaviors aren’t reinforced
Cruising Altitude: Conversations are engaging, appropriate, steering at just the right level.

Improving Traction by Organizing Around Outcomes

Your new board is probably busy, and that’s information

There’s a reasonable likelihood that the Portfolio Kanban board you just created is busy. Usually it’s some mix of these:

The organization is working on too many things at the same time.
The organization is too centralized - a core group wants to see everything and wants to actively manage too much.
The organization is tangled among different factions - Instead of collaborating, multiple groups are establishing their own agendas and their own kanban boards. Representing each group’s work on the Portfolio Kanban, while busy, will reveal redundancies and duplicative efforts. Once you establish a Portfolio Kanban board to see all the work you’re managing, you should consider whether you NEED to manage this work at the portfolio level. It may be time to review and refine the definition of the portfolio workflow, focusing on which items should be processed at the Portfolio level, and what work should be managed at the initiative or team level.

Descale Your Portfolio By Organizing Around Outcomes

If this exercise points to many cards that need to be managed at the Portfolio level, one conclusion would be that you indeed need to invest in better portfolio management, coordination mechanisms, etc. “Level of cross-product collaboration needed” is a factor for managing an investment initiative at the portfolio level because the higher the number of collaborators required, the more effort is needed to align priorities and focus execution. But what if we found a way to reduce that level of effort?

That is what descaling means, and it works on two fronts at once.

Minimize the number of in-flight outcomes that span teams, groups, and functions:

Limit work in progress to fewer multi-functional, cross-portfolio outcomes running at the same time.
Prioritize those outcomes so it’s clear where people should be dedicated first.

Minimize the number of teams, groups, and functions any one outcome needs in order to land:

Create stable “broader-perspective” teams, or transient “strategically focused” teams, aligned around prioritized focus areas.
Evolve the product and business architecture to support self-service, reduce coupling, and cut the need for coordination in the first place.

Here are some ways to think about descaling:

Identify the constraints, the usual suspects involved in everything. In many cases 80% of the dependencies map to 20% of the teams.
Look for topology options that might work better.
Consider whether architectural interventions such as a self-service platform can melt some of the iron spaghetti.
Consider aggressive cross-team and cross-function T-shaping, so people can do work that’s currently locked to specific constrained teams.

Come up with several design options and compare them (including the current state) on:

How much of the portfolio’s work gets localized under this option? Aim for the majority; 80% would be better.
How big a change from the current state is this? Change is hard.
How much product, technology, and people risk does it carry (say, distributing a core capability to people with limited know-how)?
How future-proof is it? How well does it fit the strategy, and what’s on the horizon?

When you find a significantly better alternative worth exploring, evolve it like a product: clarify the desired outcomes and leading indicators, agree on a discovery approach, and tackle it incrementally where you can. Reorganizing around outcomes leads to better flow and effectiveness, and a flow perspective is usually what gets that conversation started.

Chapter 4: Accelerating Flow on the Initiatives That Matter

Actively Managing Portfolio Flow

If your Portfolio Kanban still looks like a traffic jam in rush hour - full of cards, without much movement - don’t despair. Seeing the swamp is the first step in shaping it into a river. No New Work. Freeze. Differentiated Service. Applying WIP Limits. Those are patterns you can apply to start shaping the flow. Here are a few of my favorites:

1. Right To Left Kanban Reviews

It might be as simple as reviewing the board and discussing the work right to left (instead of left to right – the way work flows). By using this “Hebrew mode,” you are focusing on finishing work already in progress and only getting to discuss starting new work after the weight of all the investments already in progress, which is essentially demotivating you from even considering it. You can use this nifty “system” to nurture a habit of stop starting, start finishing.

2. Look for Flow Constraints

As you start focusing on flow, you’ll begin to see constraints:

The one team/group involved in everything (maybe it makes sense to be even more careful when introducing new investments involving them)
The investments that are so big that they occupy their “lane” much more than others (maybe it makes sense to break them into independent investments each worthwhile on their own and accelerate time to market? )
Investments where you feel like you’re running blind – with no transparency about what’s going on & no leading indicators for months about whether this investment will be worthwhile. (Which can be an excellent opening for exploring outcome-oriented, evidence-informed portfolio management)

There’s so much that actively managing portfolio investments using a flow perspective can tell you. And so many opportunities for further improvement emerge organically. That’s the beauty of using Kanban. It catalyzes dialogues about improvement rather than telling people how to improve. Actively managing flow on a Portfolio Kanban won’t magically turn a project-oriented organization into a product-oriented portfolio. But it is one of the most effective ways to start the path.

Improve Your Portfolio Flow By Focusing On Flow Metrics

Work will expand to fill the time you give it - In order to accelerate flow, you need to measure and manage flow

Kanban/Flow Metrics can help sharpen your flow focus even further. The four flow metrics described in the Kanban Guide for Scrum Teams / Kanban Guide are Work in Process (WIP), Cycle Time, Throughput, Work Item Age (WIA).

How can these metrics help us at the Portfolio level?

Work In Process (WIP)

While we can see the current WIP just by looking at the Portfolio Kanban, explicitly measuring the WIP level and seeing it trend over time can provide deeper insights into opportunities for waste reduction and flow acceleration.

Cycle Time

Portfolio-level investments will take months to finish - not weeks, and hopefully not years. Cycle Time measures exactly how long and gives us key information about our time to learn and time to market. Over time, we can hopefully establish a Service Level Expectation (SLE) that will help us manage our expectations around investment workflow.

Throughput

How many investment initiatives are we delivering every quarter? Year? Throughput doesn’t care about the size of the investments. It counts investments “finished” in a unit of time. Remember – in most portfolio workflows finished means “we’re done treating this as a high profile investment – it's now back to business as usual”. With information about the overall throughput, we can have some interesting conversations about the funnel leading into the workflow. For example – if we learn that our throughput is 3 investments a quarter (I know multiple portfolio teams who would love to have that) – how many investments does it make sense to consider each quarter? What’s the proper shape of the consideration funnel? Where are our bottlenecks/constraints?

Work Item Age

What if we had an early warning system alerting us to specific initiatives that aren’t flowing as well as the others? This is what Work Item Age does. It shows us the age of active initiatives and highlights those that have been active the longest, especially considering where they currently are in the workflow.

Now what? Start measuring flow metrics for your Portfolio Kanban.

Do that as soon as possible because it will take time to see meaningful data. You can wait a bit with analyzing and discussing the data, but once you get to it, you’ll have some interesting baseline and trend data to look at. If you do have some historical data from the current project/program management system, you can try reverse engineering flow metrics to accelerate establishing a baseline. This data can also help you decide whether you want to invest in portfolio-level flow. Finally, a warning. It’s essential to focus on flow. And it is the right place to start. But it’s far from enough.

Chapter 5: Reducing Risk and Improving Outcomes

Let’s say we meet 2 months from now, and you have implemented everything we covered so far. There’s much better traction; execution is streamlined. You might be more efficient at doing strategic cross-functional work, but…

Does that work result in the outcomes and impact we had in mind?
Do we even know what outcomes we’re aiming at? What real success (not checking the box) looks like?
Are we managing the risk of missing the mark (even though we’ve done the work we planned to)?
Would we change direction if we weren’t on the right track? Would we even know we need to?

Project to Product

These are all shortfalls of the classic project-oriented mindset. Product Operating Models address these issues by:

Aligning around outcomes
Providing flexibility in advancing towards these outcomes
Using leading indicators and frequent feedback loops to steer. Scrum and Lean Startup are examples of frameworks that help instantiate a product mindset. But how do we apply these ideas to strategic initiatives that span the organization and aren’t necessarily product-related?

Back to FlowImpact Yoga

Remember FIY? They started managing their business initiatives in a high-level Kanban board. They plugged in all of their in-flight initiatives and got going on seeing and improving flow. They got to the point of more efficient strategic execution. Like us, they realized they needed to move from project to product thinking to become effective. Jim, the CPO, brings up the language of “Bets,” which he learned in a Product Leadership Slack Forum. They decide to apply the concept of outcome hypothesis with leading indicators to the cards on their kanban board, even though those cards don’t always reflect products. When they get together, they review these leading indicators to decide whether to continue investing, pivot, or stop altogether. They also decided to change their workflow to separate “Discovery/Exploration” and “Execution” to reflect the concept of the truth curve - where you aim to learn as efficiently as possible, whether you’re on the right track before you fully commit. (aka Fire Tracer Bullets, Then Cannonballs). This clear distinction on their Kanban board ensures they have the right conversations about which initiative is a bet that requires discovery and when it is ok to skip to execution. They also introduce a policy of integrating “measure and learn” into their Kanban workflow. They agree on a set of questions they will consider for initiatives in flight:

Have we achieved our outcome hypothesis?
What can we learn from the metrics?
Are we still making progress, or are we seeing diminishing returns?
Is this still a business constraint? Fast forward a few months - While fewer business initiatives are in motion, more initiatives impact the metrics that matter, and the business has improved traction overall. FlowImpact Yoga is now executing with better Flow and more substantial Impact.

Outcome-oriented Kanban Cards That Encourage Steering with Evidence

Since OKRs (Objectives and Key Results) are a common approach for setting goals in scaleups and midsized organizations, let’s use them as an example of how to orient around outcomes. While OKRs are very popular, a common anti-pattern is to use them in a traditional project mindset focused on outputs/activities. A good start is to use OKRs as your Kanban cards – meaning each card will include an Objective and a small set of Key Results - focusing on outcomes, providing leading indicators that enable steering. Make sure to consider an outcome hypothesis. What are we hoping to see? What’s going to look different for all the various stakeholders? And what is going to be the impact of this changed environment on our business? Describe some leading indicators – How will we know we are heading in the right direction? How will we know we’re not? OKRs as cards is just one idea. Here are some other options to consider:

If you’re a serious Lean shop, Your cards might represent A3 canvases focused on a problem/opportunity.
If you’re a Lean Startup fan, you might use Lean Canvas as your card format (yes - even for internal initiatives!). The Why Now Elevator Pitch format is a good way to structure a story based on your lean canvas.
Inspired by the Spotify Model? Your cards can represent Bets based on DIBBs (Data, Insights, Beliefs, Bets)
Interested to dive deeper into outcome orientation and managing risk by evidence-based steering? Check out Evidence-Based Management. If this is all a bit daunting, you can start lightweight by just ensuring the card name is outcome-oriented instead of specifying the solution/activity.

Kanban Workflows that Encourage Evidence-based Steering

The card format isn’t enough. You also need to structure your Kanban flow to encourage outcome orientation and empiricism. Here’s an example:

By explicitly defining the Discover / Tracer Bullets as a step, we’re driving conversations about validation before proceeding to execution. Spotify's Think It Build It Ship It Tweak It is another example. Find the flow and language that work for you. The key is to encourage the right conversations when considering and steering investments. One significant advantage of having these conversations at this level is that it provides a model for conversations throughout your organization.

All Together Now

At this point, you have a trail map that shows you a few paths you can take to improve traction towards outcomes on your strategic initiatives These paths guide you on:

Encouraging strategic focus by seeing and limiting the number of strategic initiatives in motion
Balancing effectively between alignment and autonomy
Improving flow and traction by (re)organizing in ways that make it easier to collaborate around multi-disciplinary cross-portfolio cutting initiatives
Improving value by providing clarity on what outcomes we are looking to achieve and giving execution flexibility

Knowing the paths isn’t the same as walking them

Which leaves the part everyone underestimates: actually deploying this operating system in a live organization. That’s the next chapter.

Chapter 6: Using the Trail Map to Build Traction

In this chapter, we won't learn any new concepts or practices. Instead, we will discuss how to use the product-oriented thinking and practices we already established are worthwhile when pursuing strategic change/transformation, for our organizational operating system upgrade (which is strategic change/transformation itself!).

Product-oriented Change / Transformation

What does that look like? Pretty much like what we've learned so far in the course:

Actively manage the flow of your most significant investments

Therefore, make sure not to pile this operating system upgrade on top of everything else you're doing in the organization. Consider it as part of your organizational WIP (work in progress).

Descale by organizing around outcomes

Determine who's the team that would need to work on this and let them work directly together. Does creating a team in the organization that owns "operating systems" makes sense? Maybe, Maybe not. Like any other initiative, that's a strategic question to consider.

Reduce risk through speed and evidence-based management

Use agile, product-oriented ways of working to manage and derisk this initiative. Determine a benefit hypothesis and define leading indicators. Agree on success and kill criteria. Discover/explore if its useful through a focused minimally viable change (tracer bullet). Validate/Invalidate and steer based on evidence.

Walk the talk

It's tempting to say - it's apparent that we need this operating system. To mandate rather than take the time to invite/figure out. And you'll probably rely on SOME conviction, charisma, authority. But remember - you're expecting people to approach initiatives this way as part of the new operating system. So, better try to walk the talk. And be open about how hard it is. And about learning. (It often helps to have an outsider to remind you and challenge your comfort zone...)

Now it's up to you

You know enough to get started. It doesn't have to be perfect. Just get going. The Product-oriented Portfolio Agility Trail Map describes a lightweight, easy path to get started with. (Like any trail map, you can always go with a double black diamond on your first run.) Within a few days/weeks, you could probably have a live portfolio Kanban board mapping your initiatives and where they are. You could start some conversations about using more outcome-oriented language. You could revisit your goal-setting processes to introduce some flow and focus. You could start having conversations about traction on leading indicators, not progress on scope. You could start an experiment with a virtual team working together towards a multi-disciplinary strategic goal. Even if it's just changing the language you use in your existing conversations, documents, artifacts, or meetings, you're getting somewhere.

Try, Inspect, and Adapt

Stop and reflect every once in a while. Bookmark this, and come back to it in a month with the team working on the operating model upgrade: how are we doing? What evidence are we actually seeing? What’s next? If you feel good about where you are, turn some tracer bullets into a cannonball by committing to a real experiment. If you’re ready for the next improvement, re-read for ideas, or use a principle-based assessment to structure the conversation about where to go next. This is a trail map, not a roadmap. There are multiple paths and I don’t know which one is yours: I’m just trying to help you know the terrain. Here are some example paths:

When leaders wanted to improve empiricism and reduce investment risk, we improved the definition of workflow to reflect better and encourage product discovery behaviors. We also introduced a key decision: whether to go through discovery or skip it straight to delivery.
When a product leader wanted to empower product teams, even when working on the most significant initiatives, we emphasized structuring these initiatives around outcomes, using OKR language instead of classic PRDs and business cases.
When an enterprise struggled with an unsustainable pace, a key intervention was a planning exercise inspired by agile planning techniques. The different groups involved collaborated to create a realistic roadmap using pull mode.
When a pharma company was scrambling to tackle too many organizational transformations at one time (trying to implement recommendations by a top consulting firm), to the point where key players were stretched too thin between their ongoing work and multiple transformation "Sprints" it was time for a tough conversation about organizational focus, organizing focused teams by empowering a larger group of people that WOULD be able to focus on a specific mission, and introducing a language of discovery and empiricism to how the initiatives were managed, that enabled real agility in the trenches. What challenge will YOUR future self be working on? Who knows...

Epilogue

You’ve covered a lot of ground. A quick recap of the trail:

Chapter 1. Why your product/tech organization gets slower as it scales.
Chapter 2. Finding an operating model that regains traction toward outcomes at scale.
Chapter 3. Understanding your portfolio, and establishing flow boundaries you can see.
Chapter 4. Establishing and accelerating flow on your most significant initiatives.
Chapter 5. Reducing risk and improving outcomes by steering on evidence.
Chapter 6. Using the trail map to evolve toward organizational traction.

Keep this as a reference to nudge you along your portfolio agility path. I’m genuinely interested in upstream interventions like this one. I like working with scaleups and larger organizations that are stuck at a scaling inflection point, and helping them use portfolio-level moves to get through it. If you want to work together on portfolio agility or another interesting challenge, let’s talk.

Appendix: A Few More Notes on Portfolio Workflow

Workflow stages. You’ll have to define the states items flow through between your start and end boundaries. You might already have a workflow. Or you might want to take inspiration from SAFe’s LPM, Spotify’s Think it / Build it / Ship it / Tweak it, or another variant. Either way, have the dialogue about whether to start from what you have or leap to a new model: don’t let the choice happen by default.

It’s your portfolio workflow, so make it yours. The key point about every element of the definition of workflow is that you, as the portfolio team, should own it. What you have right now is a starting point. Commit to trying it, inspecting, and adapting based on whether it actually fits. Over time you’ll want to pull in better flow, outcome orientation, autonomy, and empiricism, and you’ll be able to see whether you’re genuinely product-oriented, with evidence that feeds your product topology decisions. You have to start somewhere, and it’s better to start seeing the flow now than to spend months settling your ways of working (never mind your product structure) before you begin.

What People Who’ve Done This Work Say

I have had the great pleasure of working with Yuval over the last few years as we were orienting our organization towards outcomes and Product Oriented Teams from a traditional Information Technology organization. Yuval has advised me personally through this path and has also helped our organization adopt agile in a pragmatic way with a focus on the outcomes for the enterprise. As we continue this path, we owe a debt of gratitude to Yuval for giving us the best training and start on this path. Yuval would be an asset to any C suite as they contemplate adapting their organization to a rapidly evolving technology environment that is likely to disrupt many businesses. Transformation is more about people and mindset. With the right leaders and the right mindset, organizations can deliver remarkable results. We have experienced this over the last two years.

Sunil Cutinho - CIO, CME Group

Without question, Yuval is the best Lean/Agile partner I have ever worked with. Over the 2+ years of our working relationship, he has consistently brought a pragmatic and refreshingly direct approach towards problem-solving, coaching, and training.

Steve Lizotte - Engineering Leadership - NEC

Yuval understands how organizations and people operate. During our work together, Yuval consistently provided original and thoughtful insights and perspectives on the challenges we faced.

Roy Emek - Ex-Tech Executive

Yuval helped me bring the science and mindset of agile into our world. He advised my team and me on operationalizing the best practices and applying them pragmatically and practically to our unique context – focusing on transparency, empiricism, shared understanding, and empowerment.

Vincenza Nigro - Global Franchise Lead - Hansa BioPharma

Yuval takes an incremental and highly collaborative approach to understanding the problems to be solved, and doesn't push a cookie-cutter solution - instead, he provides insight from his deep experience across multiple methodologies and frameworks and coaches the business leaders to align on a path forward.

Rachel Grundy - Chief of Staff - ButcherBox

Originally published at https://yuvalyeret.com/blog/scaling-product-organizations-with-portfolio-agility/.

Using Spec-Driven Agentic Development Harnesses to Shift from Output to Outcome Framing

Yuval Yeret — Thu, 02 Jul 2026 00:00:00 GMT

import AIPrompt from '~~/components/ui/AIPrompt.astro'; import { Content as PromptContent } from '~~/data/prompts/outcome-framing-coach-prompt.md';

{/* copy-check: allow-staccato: Yuval typed this draft, so the short-paragraph rhythm is his own. */}

When I look at teams adopting spec-driven-development harnesses such as Speckit, Kiro, Compound Engineering and the like, I see much more than specification/planning discipline.

The real magic of these frameworks is that they embed an explicitness about "How we work here" that system optimization practitioners like me drool all over.

In Lean we call this "Standard work". In Scrum it's the "Definition of Done" (and "Ready"). In Kanban it's "Definition of Workflow".

In an agentic development lifecycle the markdown files that outline behaviors such as steps in the workflow, what to do in each, how to evaluate success and readiness to proceed, are now executable specification. They are THE "operating system code" of your agentic development lifecycle.

Spec-driven-development makes continuous improvement tangible.

Why is this so exciting? First, Because continuous improvement is now much more tangible. You can see it in changes to these markdown files. You can collaborate with agents to drive it.

Finally, we can properly develop the company as a product: treating our ways of working as version-controlled, executable code.

Spec-driven-development harnesses as a coaching tool

Second, Because beyond being an executable operating system, these preferences can also nudge us, on a continuous basis, towards better practices.

And when I say us, I do mean us humans. The agents of course have to follow the lifecycle specification. But a side benefit of having agents involved in our workflow is that when they do interact with us they can enforce policies/rules and nudge us using guidelines.

Case Study - Shifting from activities and outputs to outcome-based goals

Case in point - shifting from outputs to outcomes. I've talked quite often about the value of shifting from outputs to outcomes.

I see it every day: teams are trying to become more "outcome-oriented," but when you look at their Jira backlog, it's a graveyard of activities and outputs. Epics are titled "Build Database Migration" or "Implement New API." This prescriptive language anchors the team to a specific solution rather than the actual user capability they need to unlock, drastically limiting their agility. If the "Database Migration" turns out to be the wrong way to solve the user's problem, they've already boxed themselves in before work even begins.

So I'm constantly on the lookout for better ways to help people frame work in outcomes, so they enable aligned agency and faster convergence towards valuable outcomes.

GenAI GPT/Gem Outcome Framing Coaches - Nice proof of concept, Limited adoption/retention

Early on in my adventures with generative AI, I've noticed how effective it can be for classifying goals, objectives, work items and language in general as activity, output or outcome.

The next step was to create an outcome framing coach custom GPT and gemini gem for a product portfolio operating model client last year. When more and more people started to shift to agent environments such as Claude Cowork, Code, Chatgpt Work, I realized that a skill is a better way to deliver the outcome framing coach.

What is the Outcome Framing Coach?

So I created an AI agent skill that uses a straightforward taxonomy (Input → Activity → Output → Outcome → Impact) to classify your work items, flag prescriptive language smells like "build" or "implement", and suggest an outcome-focused rewrite. The goal isn't to remove all technical details (the description can still specify what you're building) but to elevate the framing of the Epic so the team understands why they are doing it and who benefits.

How to use it right now

You can take the prompt below and paste it into ChatGPT, Claude, Gemini, or even configure an Atlassian Rovo agent with it.

But I have a hunch that you're not going to. Or even if you get excited and add the skill, you won't run it that often.

That hunch is an informed guess based on what I'm noticing with the people I coach. They don't remember to use the awesome skills I create for them. They don't even remember to use awesome built-in capabilities that we discuss in our coaching sessions.

So how do we drive more usage of a skill such as the outcome framing coach? Here's where spec-driven-development is really interesting.

Scaling outcome-framing coaching using Spec-driven-development

Don't get me wrong. Out of the box most frameworks are very output focused. And getting the developers behind them to shift towards outcomes is proving a non-trivial endeavor.

But that's ok. Most organizations fork and evolve their harnesses anyhow. (It's on my todo list to write about some guidelines and best practices for evolving your spec-driven harness. Stay tuned...)

And when you do that, you can easily plug in whatever behaviors you want both the agents and involved humans to follow.

For example, you can insert an outcome framing coach as a skill into the specification step, or add a outcome/intent step preceeding it. This skill will then review and provide feedback on human input into the agentic workflow, as well as shape the AI outputs.

We Keep Saying that term (Spec-driven Development). I'm not sure it means what we think it means

Spec-driven-development is named this way to reflect the fact that agents are building from specifications rather than from pure vibe.

I'm starting to think that the name is great, for a different reason.

Spec-driven-development means we are driving an AI-native development lifecycle based on an explicit executable specification of its workflow.

Spec-driven-development and other agentic harnesses are proving to have fascinating potential for guiding agents while developing and coaching humans.

In fact, They are becoming a first-order engineering leadership leverage point.

I love how Shay Mandel framed this in our recent conversation - "We are developing the system that Develops the code". In other words - They are focused on evolving the specification and wiring of their AI-native development lifecycle.

So what's the actionable advice here?

If you are leading an organization on a journey towards AI-native engineering, be very interested in what behaviors your organization's agentic harness is designed to promote. And engage in shaping its impact on both your agents and your humans.

And if you're already concerned that agents and their humans are overly focused on specifications and working software, consider taking the outcome framing coach below and working with your agent on the best way to integrate it into your harness.

The Full Skill Code

If you are building your own custom agents, or configuring a Rovo Agent for Jira, you can copy the full skill instructions below.

# Outcome Framing Coach

## Outcome

Classify a work item on the value taxonomy, flag prescriptive language smells, and suggest an outcome-focused rewrite that anchors to user capability and measurable business impact.

## Outcome Indicators

- The rewritten epic title or description names a user/persona, a capability they gain, and a measurable result.
- Prescriptive verbs ("build", "implement", "create") are removed from epic titles.
- The team can answer "how will we know this succeeded?" before work begins.

## Taxonomy

| Level        | Definition                              | Signal words                                                                  |
| ------------ | --------------------------------------- | ----------------------------------------------------------------------------- |
| **Impact**   | A business metric or bottom-line result | revenue, retention, conversion, churn, ROI, NPS, cost reduction               |
| **Outcome**  | A capability the user/customer gains    | "users can…", "ability to…", enables, empowers, self-serve, visibility        |
| **Output**   | A deliverable artifact to build or ship | feature, API, component, page, dashboard, integration, release                |
| **Activity** | Work performed to produce an output     | implement, test, QA, UAT, spike, discovery, fix, maintain, upgrade, configure |
| **Input**    | Resources consumed                      | budget, staffing, hiring, headcount, capex, opex                              |

**Coaching goal:** move epics from Activity/Output framing up toward Outcome or Impact.

## Prescriptive Language Smells

Flag these verbs in epic titles as output-oriented smells:
`build · create · implement · setup · set up · add · integrate · develop · launch · deploy · configure · migrate · establish · introduce · rollout · redesign · rebuild`

## Workflow

1. **Receive** an epic title, description, or list of epics.
2. **Classify** each item on the taxonomy above. State the level and a one-sentence rationale.
3. **Flag** any prescriptive verbs in the title.
4. **Suggest** an outcome-focused rewrite using the template:
   > `[Persona] will be able to [accomplish core task], resulting in [measurable change].`
5. **If already Outcome/Impact:** acknowledge it and suggest how to add or sharpen the measurable KPI.
6. **Do not** invent KPIs: use `[add KPI]` as a placeholder when the team must define it.

## Gotchas

- Do not reframe Bugs or operational Tasks: they are legitimately Activity-level; the coaching question there is whether they belong in an epic.
- Do not over-engineer the framing. One clear sentence beats a paragraph.
- Do not remove all delivery language from the _description_: only the _title_ needs to be outcome-first. The description can still specify what will be built.
- Activity-level epics (spike, discovery, UAT) should prompt a question: "What decision or capability does this activity unlock?" Answer that to find the parent outcome.
- **Quarterly bucket epics** (summary starts with `FY##Q#` or `Y##Q#`) are always Activity: the time-box framing signals a container for work, not a deliverable. Do not classify as Output based on what's named inside the bucket.
- **Business metric ≠ user capability**: "Increase audience 15→50%" or "retain 22M PVs" are Impact (business metric + improvement verb), not Outcome (user capability change). Outcome requires a user gaining an ability; Impact requires the org gaining a measurable business result.

## Example

**Before (Output):** `SPT | Daily Budget Threshold Implementation`

**Classification:** Output: describes a feature to implement, not a capability gained.

**Smell:** `Implementation`

**After (Outcome):** `Media planners will be able to set daily spend caps per flight, resulting in fewer budget overruns and less manual intervention from ops.`

Originally published at https://yuvalyeret.com/blog/spec-driven-agentic-harnesses-outcome-framing/.

How Far Along Is Your Project-to-Product Shift?

Yuval Yeret — Wed, 01 Jul 2026 00:00:00 GMT

import AIPrompt from '~~/components/ui/AIPrompt.astro'; import { Content as PromptContent } from '~~/data/prompts/portfolio-to-product-shift-coach-prompt.md';

If you were in the room for "Product Orientation Through LPM: The Foundation for AI-Native SAFe," you heard the core provocation: before any organization earns the AI-Native SAFe label, it has to cross the chasm from Agile Theater and Feature Factories into an actual Product-Oriented Organization. That's a portfolio-level problem before it's a team-level one: it's about whether your Lean Portfolio Management setup is still organized around projects and approvals, or whether it's shifted to funding and steering products. Most of the questions I get after this talk aren't "what is AI-Native SAFe," they're "okay, but where do I actually start on my own portfolio."

So instead of a slide recap, here's a coaching prompt you can run with your own AI agent right now, using one real initiative from your own portfolio as the test case.

What the coach actually does

This isn't a generic "explain product operating models to me" prompt. It runs the same sniff test I use with clients: take one real initiative, score it on investment size, strategic risk, and cross-product collaboration, and see whether it actually belongs at the portfolio level or should be pushed down to an empowered product team. From there, it locates the real gap (visibility, flow, descaling, outcome orientation, or evidence-based steering) and recommends exactly one experiment to run in the next 2-4 weeks, not a transformation program. If the conversation turns out to really be about AI agents and how much Epic governance to decentralize, it'll name that and connect it back to guardrails instead of another approval gate.

It draws on the same principles from the talk, distilled from the fuller Scaling Product Organizations with Portfolio Agility minibook: referenced in the prompt so your agent, and you, can go deeper on any piece that matters most.

Run it now

Click through to continue with your agent of choice, or copy the prompt into whatever you're already using.

The full prompt, if you'd rather read it first

You are a Portfolio-to-Product Shift Coach, continuing the conversation from Yuval Yeret's talk "Product Orientation Through LPM: The Foundation for AI-Native SAFe." Your job is to help me find where my organization actually sits on the path from a project-oriented Lean Portfolio Management setup to an empowered, product-oriented portfolio: before we talk about AI-Native anything.

### Context

Ask me for this if I haven't given it to you already:

- **My role and how I sit relative to the portfolio:** (portfolio/LPM lead, product leader, Epic owner, SPC, exec sponsor, other)
- **Current governance model:** SAFe LPM / informal portfolio kanban / project-and-program office / none of the above
- **Roughly how many products, value streams, or ARTs share dependencies:**
- **One real initiative currently on, or fighting to get onto, the portfolio board:**

### Instructions

Coach me interactively, one or two questions at a time. Don't dump a framework on me: build the diagnosis from what I tell you.

#### Phase 1: Sniff-test the initiative

Take the one real initiative I gave you and score it against these three criteria, 1 (low) to 3 (high) each:

- **Investment size**
- **Strategic opportunity/risk**
- **Level of cross-product collaboration needed**

Add the three numbers:

- **3-4:** this probably should NOT be a portfolio-level card: push the decision down to the product team.
- **5-6:** worth a conversation about whether to track it at the portfolio level at all.
- **7-9:** this legitimately belongs at the portfolio level.

Tell me the score and what it implies. If most of what I describe scores 7-9, flag that as a signal, not a compliment: it usually means dependencies aren't localized yet.

#### Phase 2: Locate the real gap

Using what you now know, tell me where the real gap is (I don't need to be sequential about this: find the one that matters most right now):

1. **Visibility**: do we even see the flow of our significant initiatives, or are they scattered across tools, decks, and someone's head?
2. **Flow**: are we actively shaping demand (saying no/not yet, reviewing right-to-left, watching WIP) or just adding to a pile?
3. **Descaling**: are we organizing around products/value streams so most dependencies are localized, or is a small set of teams tangled in everything?
4. **Outcome orientation**: are our portfolio cards framed as outcomes/hypotheses with leading indicators, or as scope/output commitments?
5. **Evidence-based steering**: do we actually change direction based on evidence, or does the plan survive contact with reality unchanged?

#### Phase 3: Recommend one move, not a program

Based on the gap you found, recommend exactly one experiment I can run in the next 2-4 weeks: a tracer bullet, not a cannonball. Tie it to a leading indicator I can actually see, not a vanity metric.

If the conversation surfaces that this is really an AI-Native SAFe question: i.e., I'm trying to figure out how AI agents/augmentation change what should be centralized vs. decentralized: name that explicitly and connect it back to guardrails: the goal is decentralizing epic governance toward strategic alignment, intent, and guardrails, not adding another approval layer for agents.

### References

Draw on, and where useful point me to, these:

- [Scaling Product Organizations with Portfolio Agility](https://yuvalyeret.com/blog/scaling-product-organizations-with-portfolio-agility/): the source minibook this coach is distilled from, including the full sniff test and the Visibility/Flow/Descaling/Outcomes/Evidence trail map
- [When and Why Do We Need a Product Operating Model?](https://yuvalyeret.com/blog/when-and-why-do-we-need-a-product-operating-model/)
- [Actively Managing Portfolio Flow](https://yuvalyeret.com/blog/actively-managing-portfolio-flow/)
- [Let's Open the Portfolio Kanban Cards](https://yuvalyeret.com/blog/lets-open-the-portfolio-kanban-cards/)
- [Descale Your Portfolio by Organizing Around Products](https://yuvalyeret.com/blog/descale-your-portfolio-by-organizing-around-products/)
- [Developing Your Product-Oriented Portfolio Using a Product-Oriented Approach](https://yuvalyeret.com/blog/developing-your-product-oriented-portfolio-using-a-product-oriented-approach/)
- [Embarking on Your Product-Oriented Lean Portfolio Management Journey](https://yuvalyeret.com/blog/embarking-on-your-product-oriented-lean-portfolio-management-journey/)
- [Tackling Projects in a Product Operating Model World](https://yuvalyeret.com/blog/tackling-projects-in-a-product-operating-model-world/)
- [Hacking Your Way to an Evidence-Informed Mindset](https://yuvalyeret.com/blog/hacking-your-way-to-an-evidence-informed-mindset/)
- [Your AI Portfolio Doesn't Need More Ideas, It Needs Less WIP](https://yuvalyeret.com/blog/your-ai-portfolio-doesnt-need-more-ideas-it-needs-less-wip/)
- [The Outcome Framing Coach](https://yuvalyeret.com/blog/spec-driven-agentic-harnesses-outcome-framing/): if I need help rewriting a specific epic as an outcome
- [The Portfolio-Oriented Portfolio Agility Trail Map](https://yuvalyeret.com/the-portfolio-agility-trail-map/): the deeper, six-day version of this same path

### Output Format

End with:

- **Sniff-test score and what it means:** ...
- **Where the real gap is (Visibility / Flow / Descaling / Outcomes / Evidence):** ...
- **The one experiment to run in the next 2-4 weeks:** ...
- **The leading indicator that tells us it's working:** ...
- **If this is really an AI-Native SAFe question, what guardrail to set instead of a new approval gate:** ...

### Tone

Direct, practitioner-to-practitioner. No framework worship. Push back if I'm reaching for more process instead of less.

The point isn't to adopt a framework. It's to find the one place your portfolio is actually stuck, and the smallest experiment that tells you whether moving it is worth the effort.

Want the full source material?

The prompt above is distilled from Scaling Product Organizations with Portfolio Agility, the working-draft minibook covering the full path in more depth, including the sniff test, the descaling techniques, and the trail map chapters this coach is built on. If you'd rather get it as a six-day email course instead of one long read, the Portfolio Agility Trail Map walks through the same material a lesson a day.

Originally published at https://yuvalyeret.com/blog/portfolio-to-product-shift-coach/.

Finding AI Gold With Lean Startup Techniques

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

How do we deliver valuable real-world AI impact through solutions that solve problems, using some of what we've learned by building products over the last couple of decades?

We're not seeing the value yet

Unless you've been in a cave, you're aware that there's a gold rush happening out there. Certain companies are definitely making money building AI hardware and solutions, and a lot of people are heading out to mine for AI gold.

A lot of the conversations inside organizations feel like they're more about the technology and the solutions than about what we actually do with this. A lot of the conversation is about how do we train it with the right data, how do we rationalize the data from different systems, and not necessarily what's the outcome we can create.

Whether you agree with the recent MIT research about the number of generative AI projects failing to produce meaningful results or not, it's pretty clear for anybody looking at what organizations are doing with AI that we're not seeing the value yet. We're not seeing the full potential value of this amazing technology. And the problem isn't necessarily with the technology, the infrastructure, the regulation, or even the talent. It's around how we approach it. Like any other technology in recent memory, there's this anti-pattern where we approach it from a solution perspective rather than a problem or outcome perspective.

Most of your organization is still using AI as a better search box

I really like the crossing-the-chasm view of how AI is being adopted across different segments. When you look at the whole marketing world, there are people already talking and experimenting with AI agents and agentic workflows, but those are just the innovators and the early adopters.

The majority are barely using AI as a replacement for search, or as a conversational assistant like ChatGPT, Claude or Gemini, for personal use to be more productive on a task they're running themselves. A lot of people are still struggling with what AI is, whether we really want to use it, whether it's a threat to us, whether it can be valuable. And that's okay.

The same distribution exists in any organization. You will see people using AI for search results, whether the organization is allowing them to or not. There are people conversing with AI, maybe even creating their own Gems or Claude Projects or Perplexity Spaces. And there are very few people trying to use AI for agentic workflows or building autonomous agents. That's true for marketing, and it's true for any other function across the organization.

So the challenge is: we want to use AI for more than search results. Where is the gold? If we're going to search for gold, let's use the modern replacement of the tools the searchers used. What does it look like to pan or sift for AI gold?

Find the friction in your flywheel

One of the models I like to use for finding AI gold is the customer factory. Every successful company can be seen as a customer factory: a happy customer factory. You can think about your organization as a factory that starts with acquiring customers, then activating them, then retaining them, turning them into revenue, delivering enough value that you create revenue. Ideally the customers are happy enough that they refer others.

If this works well it becomes a flywheel. The better your product, the happier your customers, the smoother it is to bring in more customers, and the rotation of the wheel becomes easier. Business flywheels are the sort of thing Amazon used to grow, and they're very popular these days as a metaphor for how you think about growing your business and working through your constraints.

Speaking of that, a similar technique that can be used here is the theory of constraints. If you want to do the best thing for growing your business right now, you want to find the friction in your flywheel: the bottleneck in your customer factory. That's the area you want to improve.

If you don't have enough customers to even activate, that might be the constraint. It might not make sense to try to extract as much revenue as possible from customers if you're not even acquiring them. If you're acquiring them but every second customer churns very quickly, it might not make sense to acquire more. Let's focus on retention first, and make sure we have a solid customer lifetime value before we throw gas on the fire to acquire more people. If we have happy customers but aren't seeing enough referrals, maybe that's the constraint. But let's not focus on creating more referrals if our customers aren't happy: it's not going to work. Addressing the weakest link is the only thing that matters.

Why am I even talking about this? Because when you want to leverage AI in your organization, you want to focus on where it matters.

Here's how that looks in my own business

If I look at my business, there are acquisition challenges I want to do something about. I know that when I bring on a customer they're very happy, and there's a strong lifetime value for the customers I acquire. So at this point I'm focused on acquisition.

How can I convert people who listen to podcasts I'm on, and website visitors, into prospects? Am I converting enough of these people into customers? Is my close rate good enough? Is my average deal close time good enough? That could be another area I focus on. It's a choice: I need to decide which of these areas I focus on.

By unleashing AI, say using the connection between ChatGPT and my CRM, it can help me analyze and understand where it's better to invest: bringing in more leads and prospects, or converting more of the prospects I have. That's something I'll need to think through. But that's the first conversation to have. Where am I focused? Where do I want to make a difference? It doesn't make sense at the moment to go in and improve retention, because I don't have a retention problem.

Where will you play: internally?

The process you might want to go through, when you're trying to think where you can get the most ROI for your AI investments, is the strategic question. What is my goal as a business? What's my growth goal? What's currently going on in my customer factory? Where are the obstacles?

I need to form a strategy for where I will play. That can be seen as an external view of what audience or market I'll focus on: for example, I might focus on mid-market companies rather than enterprises, because I have a certain advantage in that space, and how I will win is what I bring to that space that helps me win there.

But another view people don't often take is: where will I play internally? I will focus, for example, on my sales capabilities, or on marketing, or on establishing expertise, or on my product. Where to play is a choice. It's a choice that I will focus in that area and not focus in other areas that much for now. I will consider them stable, I will consider them okay.

Once I decide to focus in a certain area, how will I win there? If I decide to use AI for customer acquisition, how do I plan to do that? Is it to unleash AI for cold outreach? Probably not. Is it to use AI to help coach me on my customer interactions, combining best practices from business coaches I follow together with data from my CRM? Maybe that's one area. Do I use AI to help me cut clips from long-form content I create? There are different approaches. But now AI is not "I can use AI for everything." It's very focused on what I'm trying to achieve.

The objective is not that you used AI

Once I decide on a strategy, I want to create a goal beyond my day-to-day mayhem. For anybody like me who has to balance billable work for customers with working on the business (and that's all of you as well) every organization needs to run the customer factory and deliver value, but also think about how we grow the factory.

We need clear objectives for what we want to see. What's the future state? What's the strategic shift I want to achieve through using AI in my business? And what does success look like: how do we measure whether we hit that objective? It's not that I've used AI. It's that I've improved my average deal close time, or my close rate, or I see more engagement.

Take a business owner I talked to yesterday. Their biggest constraint is bringing on board the right talent. It's very hard for them to find people for their financial services small business, which is growing very fast. Acquisition is not their issue: delivering value is the issue. In order to deliver value, their challenge is how do I find the right people, and how do I get them up to speed with my processes and my value creation as quickly as possible, so I can unleash them to work with customers and they become leveraged rather than a liability.

If the outcome we want is to be able to scale, to deliver more value without our individual involvement, then what is the solution? Here is where we can start talking about where we think AI can help. Maybe it can help filter through the résumés. Maybe it's only relevant for onboarding people quickly. Maybe we can avoid hiring people, because AI can actually help us deliver more value to more people on our own. Adding people is just one way to achieve the outcome. The outcome we want is to scale, which is a great example of why we focus on outcomes rather than outputs or activities.

Then form a hypothesis, and find the riskiest thing in it

With that in mind, we'll need to form a hypothesis. We believe we'll be able to scale this financial services business better if we can more easily hire the right people using AI-based recruiting. Or: we believe we'll be able to serve twice the number of clients if we gain efficiencies using agentic workflows.

Okay: that's a hypothesis. Now, what's the most important thing we need to learn first? What's the riskiest thing about using agentic workflows to serve more customers? Maybe it's whether people are willing to let us use AI to work on their financials. Maybe it's our own conviction that we cannot use AI for that. Maybe it's the ability to access our customers' data using AI, and how that works with MCP. Maybe it's a feasibility challenge, maybe a desirability one.

Let's look at those different risks and do the minimal amount of work to learn. Are we smelling gold here? Can we sniff out better ideas and get rid of not-so-great ideas at minimal cost?

Goals that are too small or too far away

One of the key conversations at this point is making sure we're focusing on the right things. A lot of the time our goals are either focused on features (hiring more people is a feature) or on business impact, which is too far away. We want to grow revenue, we want to improve customer satisfaction.

What's the problem with either of these? The impact level is not as actionable and doesn't provide strategic choices. Everybody wants to grow revenue. But what are we going to focus on in order to grow revenue, and what are we not going to grow? Focusing on acquisition as a way to drive revenue is a choice.

If you're running a mattress store, it's not that useful to have a goal of increased revenue. You need to be a bit more intentional about what the input is that drives it. Yes, revenue is when a customer buys a mattress, but even "customers buy more mattresses" is not a very useful goal.

It's more useful to convey a strategy for what we're going to do to drive that. The hypothesis, for example, is that when potential customers lie down on the mattress and bring a partner, they're more likely to buy. Now that's useful, because now we can focus on things that are going to move the needle on that. We're making choices. We're going to be laser focused and decisive around what we believe is going to move the needle for getting more people to lie down on mattresses.

The features, the outputs, the activities we drive should be focused on that, but we're not married to any of them. We might put the information for the mattresses on the ceiling, or do something that incentivizes a customer to bring their partner. We will try it, we will experiment, we will sense whether it's useful, and double down or pivot to something else.

Do you actually need to test this?

It can be wasteful to constantly try to learn and constantly experiment. So one of the things I like to do, after coming up with the strategy and the potential initiatives, is ask: do I need to test this? Is there a lot of risk here? What's the relationship between the opportunity, the value, and the risk?

If there's high potential value and high risk, it makes sense to test. If there's high value but low risk, it's an easy bet: let's measure, but let's just do it. If it's high risk with low value, let's probably not tackle that; there are better opportunities. If it's low risk and relatively low value, maybe I can do something quick and get it off the table, or just put it aside.

The hypothesis prioritization canvas is something I integrate into my own kanban board for thinking through the initiatives in the business. It helps me decide whether I want to test something, and how much time I want to spend testing it, or whether I just ship and measure.

This helps me and the business owners I work with avoid two extremes: analysis paralysis on one side, and just jumping in and throwing technology at things without thinking on the other.

Think about it from a financial perspective. Any hour you invest in working on your business is very expensive. You have a very limited budget of time to work on the business: certainly if it's an external investment. So you want to minimize the cost of initiatives that are unproven. Think through what the risks are with the initiative you're considering, and if you don't have high conviction about it, minimize the cost by running efficient experimentation.

That's what panning for AI gold actually looks like.

Originally published at https://yuvalyeret.com/blog/how-to-find-ai-gold-using-lean-startup-product-techniques/.

What Happens to Your Scaled Agile Ways of Working When You Adopt an Agentic SDLC?

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

It's time to rethink your ways of working, not get rid of them

Every week, I have several conversations with leaders whose teams are implementing an AI harness, adopting spec-driven development, and starting conversations about throwing agile ways of working out the door and getting rid of Jira. Because an agentic software development lifecycle supposedly flattens the work. Individuals do the work of teams. Teams can do the work of entire organizations. So it's very tempting to get rid of all these "heavy" large-scale agile processes.

In this article I examine why these scaled processes exist in the first place, what problem they were there to solve, and the conditions in which you can indeed "descale" your ways of working.

Why did we need scaling mechanisms in the first place?

Instead of descaling everything, what I invite you to do is go back to the first principles. Why did you have all of these scaling mechanisms?

The scaling mechanisms were a choice. Coordination overhead that was hopefully worth it at the time, because of a coordination problem you hopefully have.

What actually changes with agentic engineering

AI might have changed something about your coordination problem. There's probably work that individual people can now do without coordination. There's work the teams can do on their own, with minimal coordination with other teams. There's work the teams of teams can do that in the past required coordination across portfolios.

This change in the cost of coordination makes it interesting to look at our choices regarding coordination mechanisms.

There's still value in a lot of the elements of a scaling framework, but done at a different altitude. Instead of PI planning in detailed stories, outcome planning, talking about OKRs. Instead of managing stories in the sprint, managing features.

And the honest counterweight, because the hype runs the other way: there are human aspects that this whole AI-first push is kind of ignoring. Maybe it's because people want to get rid of product owners and scrum masters. Maybe there's politics to flattening the organization this way. But I'm not sure you need to change the team structure.

What I'm seeing when teams over-read that

A few patterns keep coming up. Teams shipping a ton of features, but activation or retention doesn't move. Multiple teams building overlapping capabilities because each one optimized locally. A critical domain expert not in the loop, and the agents crank out something technically fine but strategically off.

The deeper expensive problem is false confidence. Leaders feel good because every local dashboard is green, but the system as a whole is drifting.

So the question becomes: what evidence do we have that our increased output is translating into customer value? That's the grounding that resonates with executives far more than the cadence itself.

And the other thing happens too. In some organizations, the technology organization is sick of Jira, is sick of Agile, and they're just using AI as an excuse to just do whatever they want.

Where should humans be in the loop: in the flow, or on a cadence?

What are some ways for humans to be in the loop? One way is to be inside the flow, inside the definition of workflow. A feature gets to spec-ready. That's an opportunity for humans to be in the loop. Another is to come visit the gemba, where the work is happening, on a cadence: look at everything and where it's at, and provide feedback.

There's an interesting question, though. If the pace of AI progress is so amazing, if AI is progressing its work on features at 10x speed, is it actually effective to visit such a process every two weeks? Or is it way too late?

I see a couple of scenarios. One is that the work will stay pending the human judgment stage until we get to that cadence. If I'm working with a spec-driven lifecycle, AI writes specs for features, but we're saying we want humans in the loop, then the features stay there until we bring the humans together. Assume the humans come together every two weeks. We will probably start to see big staircases in the cumulative flow diagram. We will start to see batching, and flow times where flow efficiency is dramatically lower, because we're waiting.

If we decide we're meeting every day, the flow efficiency will be higher. But it might be a very different coordination cost to get all of the people together. So that's a legitimate trade-off.

And the question is how you scale this. How can you shift some of the judgment that happens on a cadence to happen in a flow system? Can you minimize the reliance on events and shift it into the flow? I think that's one of the attractions of shifting to Kanban and flow from cadence-driven systems.

Before you drop the cadence

But before we jump too quickly to flow and drop the cadence, this dynamic makes me recall a story that Donald Reinertsen shares about the blind person on a roof.

The fact that you can have a structured opportunity to nudge them back towards the right place is a much better way to de-risk them going off the path and off the roof than a scope-based gate would be. They might spend too much time in each one. They might get stuck.

Real features, not green ones

There's an insurance company that dropped all of its agile practices and created small teams that can each deliver features. But those features, when you dive deep into it, are not really valuable features. They're not really minimally marketable features. Even if the team says the feature is green and integrated, there isn't marketable value.

That points to an important practice, which is real features. I don't care whether you're using stories or whatever. You should manage real features, you should manage the flow of those features, and you should recognize when you have features that are unvalidated, that are not integrated with each other, that just cannot work on their own.

Now assume you're past that. You're working with minimally marketable features, and each one, when the team moves it to green, is technically integrated with the others and doesn't break things. That's one of the patterns the System Demo addresses. You could argue that if you have true continuous integration, you don't need the System Demo to prove or protect against technical breakdowns.

But what you might be missing is the opportunity to apply human judgment to the feature mix that is in flight. How these features create a better product together. How the whole customer journey is affected and evolved. How the whole narrative is shaping up. How are we enabling people to actually do their job better?

Those are the questions we need to think about frequently, because of the cost of delayed feedback. The cost of finding out that features don't work well together, that they don't make sense, is amplified dramatically the farther you get away from the point of introducing them.

The half of the review that looks forward

The other piece people rarely talk about in the context of a System Demo is what we talk about in Scrum's Sprint Review: looking forward rather than just looking back.

Let's look at what's in the backlog, let's look at the features that are ready, and apply the same judgment about cohesion. What evidence do we have. Where are we going. What's the hypothesis, and what's the conviction level on desirability and feasibility. Are we approaching it effectively? Do we need to discover before we build, or is discovery a waste of time here? Are we considering the right perspectives?

At least in a reality where we still need the diverse perspectives of different humans as part of the process, where AI doesn't have all of the context it needs, where it isn't even an internal AGI, we still need to do that in some way.

We could do it for each feature. Or we could do it in a continuous flow. But there's a coordination cost to doing it per feature, and that's exactly why a lot of organizations decide it makes sense to create a placeholder for these conversations on a cadence.

Flow or batch, and what each one costs you

When we're thinking about the choice between running a process in the flow for each feature, or waiting and doing it for several features in one bigger batch, we need to be thinking about the trade-off.

When you're doing things in the flow, you don't have to wait as much, and you might not have these cadence meetings that feel forced if there's nothing interesting going on. But it's also more expensive from a coordination perspective to get these continuous meetings happening. People are busy. Getting them together to work on something when it's not on their schedule is hard.

Now, it could be that you managed to change everybody's schedule to a schedule where it's much easier for people to just huddle together when they need to. If that's the case, move towards continuous flow.

But if you're still in what is called the manager's schedule, everybody's calendar is still full, loaded with a lot of meetings, and it's still hard to get people together for something. And you find that you're paying the price of a lot of time spent on coordinating meetings, or missing key stakeholders whose judgment and perspective you want to have, because you're moving to continuous flow. Then the trade-off might not be worth it.

So think about it. Experiment with it. Try it multiple times and see what you're getting from moving to continuous flow. What are you sacrificing? Is the sacrifice worth it?

Monday morning

Pick one event, one board, or one role you still run. Name the coordination problem it was bought to solve, then ask whether you still have that problem. Most people find one or two answers they don't like. If you try that and something surprising falls out, tell me about it.

If you would rather have an agent walk you through it against your real mechanisms, I packaged this diagnosis as a skill you can install, free and CC BY.

It's not that the physics of coordination and coordination overhead and batch sizes has changed. AI hasn't changed the physics. But it's like going to a planet with different gravity. There's still gravity, it's just different, so you need to adjust how you walk, how you move.

These are the guiding principles I use when working with organizations on reimagining their ways of working for the AI age, while still respecting the physics of product development flow.

Originally published at https://yuvalyeret.com/blog/most-of-your-scaling-apparatus-is-now-optional/.

Your Scrum Team Didn't Get Obsolete. Some Of Its Mechanics Did.

Yuval Yeret — Mon, 08 Jun 2026 00:00:00 GMT

Who is actually throwing Scrum out

I'm seeing organizations talking about spec-driven development. We don't need Scrum. Maybe we need Kanban.

Groups that are feeling oppressed by the Scrum police are using AI and SDD as an excuse to throw Scrum out.

There are organizations that are getting rid of Jira. I don't think that makes sense. In some of them, the technology organization is sick of Jira, is sick of Agile, and they're just using AI as an excuse to just do whatever they want.

And maybe people want to get rid of product owners and scrum masters. Maybe there's politics to flattening the organization this way.

And it's easier to cut.

But some of it is real. It's pretty clear that when you talk about who's actually going to work together on something, it's going to be those tiny pods. Things that used to take days can take minutes or hours. So a lot of the mechanics start to feel obsolete.

If I'm an engineering leader right now, I actually think I should question everything. Some of those individual mechanisms or roles might actually become obsolete, and I'm very open to that.

But I want to separate the mechanism from the capability.

What all of it was protecting

I met a CEO of a cybersecurity AI-native firm, a friend from the Israeli community. One of the things they realized between their previous company and this company is that R&D used to be a defensive activity.

It used to be reactive. The bottleneck used to be in engineering, in R&D, in product. So we need to protect the bottleneck. All of our processes, all of Scrum, was about protecting that.

What they're seeing now is that their whole organization is forward-deployed engineers. They're going on the offense. That's his language. He's coming from cyber, state-level cyber, so he has that language of defensive and offensive.

For him, what that enables his company to do is things like unreasonable hospitality. You go into a Michelin restaurant and you're surprised by how hospitable they are. They do things that are wowing you. They're fulfilling dreams.

So the concept I'm starting to think about is: what would unreasonable agility look like?

What can we do now that the bottleneck has moved? That stops protecting. That stops acting from the point of, you only come to us once a sprint, you have to come with ready stories and all of that junk.

What can we actually do now that we've freed that constraint?

That's the question underneath all of this. Not which ceremony survives. What was the ceremony protecting, and is it still the thing that needs protecting.

The fair objection is that nobody can yet say where the constraint went. If dev isn't the constraint, what is? Businesses are confused about it, and most of the confident answers are guesses. The one shift people do report consistently is that the speed of oversight and human decision-making got compressed: the product managers and the VPs are getting crushed under a thousand tiny decisions.

Which is its own answer, if you're listening to it. The constraint moved toward the people who have to decide.

Are the pods the teams?

There's an open question around: are those tiny pods the teams? Or do you still have the notion of teams that those pods live in, and still do a lot of the same structures, just at one higher altitude?

I don't know what the real desired state is. Is it really that we have tiny pods that have no connection to the bigger team? Or is it tiny pods are temporary for a while, but there is a bigger team that they belong to?

There are human aspects that this whole AI-first thing is kind of ignoring. From a stable structure perspective, I'm not sure you need to change the team structure. The pods can be how the work gets divided this week without being the org chart.

So: the team just discusses which features are we doing this sprint, and what are the tiny pods that are going to split off, break out, work on each one of these features.

Do you stop worrying about stories altogether?

Spec-driven development is a very popular approach to agentic development. It's a core part of the lifecycle. And it raises the question in many organizations: do we manage stories the same way we used to?

Typically the answer is the stories are managed in the pod, in the tiny pod, maybe even just by the AI. The interface with the wider organization is not stories. It's features.

There's almost an interesting opportunity here. Jira now will have epics being real epics. And the stories, the issues, will be features. And finally, epics will be epics.

A lot of it is going back to flow. That's definitely the case. In the agentic world, flow and Kanban are becoming more important.

But the more I think about it, I think there's still value in a lot of the elements people are throwing away. Done at a different altitude. Instead of planning in detailed stories, outcome planning, talking about OKRs. Instead of managing stories in the sprint, managing features.

And detailed story planning was never the intent, just so we're honest. The intent was to talk high level about outcomes and then do continuous exploration, continuous delivery throughout. It's about time that this happened. AI forced their hand to do something they should have done a while ago.

The daily one is the one that actually moves

The daily Scrum I don't think is necessarily an event. No, I think it's still daily something. I don't know that it's an event.

But looking ahead, I think Sprint Review still makes tons of sense. Even more.

That asymmetry is worth sitting with, because it's the opposite of where most of the cutting is pointed. The event that coordinated people around tasks is the one that has the least left to do. The event that checks whether all of this fast work added up to anything is the one that got more important.

The exercise, instead of the debate

There's this exercise that talks about the essentials (the small set of things a way of working is actually built on).

The real interesting piece is that at the end of each one of these essentials, there's a list of symptoms that you might find.

I think it's an interesting opportunity to ask: do we see any of these problems? Or do we believe that we'll see any of these problems if we stop doing this thing? And if we believe we might see these, then we might need to invest in those principles.

Do we see these problems? If so, we need to make sure we have cadence and synchronization.

Which I think specifically is an interesting conversation to have. Because if you're going to full flow and you're ready to get rid of sprints and PIs, will we expect to see any of these symptoms? Do we expect to see any of these problems? And if so, what are we going to do about them?

And then it brings you back to: we might need some sort of cadence. Maybe it's not the one that we have right now. But we might need some cadence.

The way this is useful is that it gives people the right perspective from a change management point of view. We're doing this for a reason. We're doing this to avoid these symptoms. We're not doing this just because.

Two cycles worth running

One thing you can do is cycle on the product operating model. What is right for disruption? What is something we need to rethink? What are some things that will continue to work as they are? And you can use that to drive the conversation around what needs to change.

And you could do the same about the role of the team. What does the team do that works well right now? What is the team doing that's right for disruption, or destructive recreation? What are things we wanted to do, and now maybe start doing with AI supporting it?

And when someone brings you an agent to roll out: what's the intent with these agents? Is the intent that they reduce the need for some roles, for some of the events?

Nobody is looking for a process to copy paste

Something interesting happened when we taught experienced Scrum practitioners about Kanban back in 2018. There was an interesting realization in the room about what Scrum was and wasn't. If you ask me, that's probably the most valuable outcome of what took place at the time.

AI is giving us another opportunity like that. To reflect on the assets. To define what this basically is.

And when you do that, what you land on isn't a set of ceremonies. It's a governance framework. It's a risk reduction mechanism.

Which is also where it stays useful. Where it's hard to observe the results of what we're doing, where we're close to the customer and still have to figure out what process needs to change, you need governance. Coding was never the part that needed it.

Nobody's looking for a process to copy paste, and Scrum is not going to be that process to copy paste anymore.

Somebody in the room would go further

I think we should almost take the word teams out, because you may have one person and a bunch of agents. So maybe moving away from all of our team vocabulary.

Now we have teams building software, and the next step is one person doing the work of a team. So the whole premise that we had 20, 30 years ago, even when we started Scrum, that's just gone.

When you're using AI, all the things that are wrong in your team are made even wronger.

What didn't get obsolete

When people asked when does Scrum not make sense, Steve used to say: when you don't have a team.

I think it's okay to say that when you're managing your own work with your agents, maybe you can find using Scrum, but that's not the intent. A lot of the principles would work.

But the real value of this thing is when you have a group of people, a team of people, that need to collaborate in some way towards an outcome.

It's a team sport. It's an optimized team sport.

You don't have rules of volleyball when you are playing volleyball alone. That's meaningless.

So don't ask whether you still need Sprint Planning. Ask whether you still have an alignment problem.

Next: Most Of Your Scaling Apparatus Is Now Optional. Your First Principles Are Not.

Originally published at https://yuvalyeret.com/blog/your-scrum-team-didnt-get-obsolete/.

Goal-Based Loop Engineering: From Spec-Driven to Outcome-Driven

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

Loop Engineering: from activities to outputs to outcomes

Loop engineering is how we get agency from AI. Prompt engineering got us through 2024, Context engineering in 2025 (and continues to be important) and now loop engineering is all the rage in 2026. Whether it's development lifecycles managed as compounding/continuously improving loops, scheduled routines, or truly autonomous agentic workflows, these all rely on effective loop engineering.

What does a loop look like? the /loop and /goal capabilities you can find in agent harnesses such as Claude Code, Codex and Antigravity are good examples.

/Goal 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 from Anthropic:

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.

Reading through this list, something jumped at me. Every single one of these /goals is output-oriented (or you can argue they are activity-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.

When you give AI (and humans...) output-oriented goals, they tend to focus on the output. The result might be a working feature that nobody uses, a page that nobody reads, or a presentation that nobody understands.

To really unlock high-agency AI, we need to set outcome-oriented goals and instrument the system so that the agents can actually measure whether the outcome was reached.

Where this sits relative to spec-driven development

Spec-driven development is a real step up from prompting your way through a change. You write down intent, the agent works against it, and you get something reviewable. But look at what the spec is describing: it is a description of a deliverable. Build this, change that, make these tests pass. The loop terminates when the thing exists.

Goal-based loops move the termination condition. Instead of "produce this artifact," you give the agent a condition to keep working toward and let it decide what to build. That is a genuinely different instruction, and it is the mechanism that could carry agentic work from a software lifecycle into a product one.

Could, not does. Almost every goal I see in the wild is still a deliverable wearing different clothes: tests pass, backlog empty, coverage above eighty. Those are outputs with a completion check bolted on. The loop got more autonomous without getting any more connected to whether the work mattered, and that gap is the actual subject of this piece.

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.

Loop Engineering - New to the AI frontier, a core practice in tackling complex systems

Seeking a goal this way 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.

This is referred to as Loop Engineering. Engineering effective agentic loops that unleash the power of agents using a core concept in designing complex systems - using tight feedback loops to try, sense, and respond to seek a goal.

Ralph Loops

In my own agentic workflows for developing and evolving my web presence and delivery capabilities I have been building something similar manually: a Ralph loop script.

This is what these scripts do more or less:

Run an AI LLM with a prompt
Evaluate the result against an exit/success condition
Exit if the condition it met
Repeat the loop

The /goal feature moves that pattern into the harness itself, which makes it accessible to anyone without custom scripting.

What's missing in the typical agentic loop

When Anthropic introduces a feature like this, the canonical examples they choose are telling. It's not a coincidence that all the examples above are technical.

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 "Landing page that converts" No "Feature that users find useful and are willing to pay for" No "Audience that learns something useful that sticks with them and changes their behavior from the presentation" No "Podcast that earns downloads and listens"

In other words, Nothing that ensures we build something that moves the needle.

The constraint AI agents are facing

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 behavior and 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.

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.

Why do we care? What's wrong with focusing on outputs and deliverables?

Scaling output production is valuable. But the real goal isn't activity or even output.

Organizations are looking for business impact. Revenue growth. Improved margins. Reduced Risk.

And pages, features, presentations, live artifacts, don't necessarily connect to impact. The impact comes from creating leverage - fewer people (and other agents!) able to deliver better value, safer, happier.

Let's simply shift to outcome-oriented loops

Isn't the answer to simply adopt outcome oriented goals?

Let's pick on one example from that list - split a large file.

Earlier this week I facilitated a workshop with an AI GTM team, where one of the use cases they were working on involved integrating an AI agent to a huge google sheet that was used by a finance team. Claude Cowork was complaining it cannot work with this google sheet.

So it makes total sense to open a thread with a goal of splitting the large google sheet. But here are some ways this could go wrong:

The split might still not fix the Claude Code access problem
The split might make it harder to maintain the integrity of the financial data, or make it harder to maintain the workflow overall.
Even if Claude Code COULD access the file, it doesn't necessarily mean it could use/serve the data in it in a useful manner.
Even if it COULD - it might be the wrong solution approach
Even if it was the overall right solution approach - it might not move the needle when it comes to behaviors on the finance team.

There are so many assumptions we're making. (And we know what happens when we ASS-u-Me...)

Asking why several times helped us frame a goal that is closer to the outcome we were really looking for - Enabling the finance team to work with Claude Code to analyze, get insights, and clean up their financial data in a more timely and efficient manner. (Excuse me for staying a bit vague here on purpose when sharing the full real life example...)

The Observability Gap

But coming up with an outcome-oriented goal isn't enough. Consider the example above. Shifting towards outcomes increases our alignment to what our users want, what they really really want (or need). But it also makes it much harder for an agent to declare success.

Because measuring outcomes is much harder than measuring outputs or activity.

And as long as agents cannot see whether their actions and outputs are really helping, they cannot close a real feedback loop. The can spend a lot of tokens building tons of stuff, that is beautiful, well designed, works well, but useless.

What happens in real life when Agents can't observe outcomes ?

In the real world, what I often observe when giving an agent an outcome oriented goal without the observability loop, is that rather than running endless turns, they simply stop and hand it back to me, essentially saying "I did what you asked, but I don't know if it helped. Time for you to figure it out".

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. And even some of the strongest SaaS product companies I've worked with that have great telemetry for their product, lack any sort of telemetry when it comes to internal technology.

In my experience, the typical IT team, even in a strong product company, is still often deep in project and feature factory world focusing on outputs or even activity theater.

That's simply not enough when you're trying to leverage AI for real impact.

The work of building telemetry and closing the observability loop is not glamorous. It does not feel as exciting as shipping a 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 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.

Using Goal altitude to determine what humans should manage

Can your agents only effectively seek output-oriented '/goal' statements right now?

That might be a good place to draw the border between agent autonomy and human responsibility.

Your end to end feature flow might include several segments where AI agents operate autonomously towards output goals (e.g. to build the feature) or even activities (e.g. verify nothing breaks through regression testing) and then return control to humans to help observe outcomes and apply judgement where there isn't quantitative evidence.

In parallel, build the telemetry and observability systems that will let agentic AI take over more and more of the work in that end to end pipeline, especially at the points where work is currently accumulating.

Watch the Update

Prefer audio? Check out the accompanying podcast or directly on Spotify.

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/.

AI Made Engineering Faster. Why Not The Business?

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

Why More AI Activity Is Not Showing Up In The Business

You can 10x engineering and still not 10x the business.

AI agents are getting very good at coding, debugging, test generation, documentation, and a lot of engineering activities. That is real in many organizations. But if engineering was not the constraint to begin with, or now stops being the constraint because of these improvements, faster engineering output may just create more work waiting somewhere else. The leadership question is changing from "how do we make teams faster?" to "where does this speed actually improve the flow to value?"

If you look at most AI programs out there, whether inside engineering organizations or beyond, they are still being managed as local productivity. Leaders are asking their teams to use AI and leverage it. We are seeing a lot of activity. We are giving people the tools. AI can save people time. People can produce more. That is a great start, but it is not really driving the results we want to see.

The promise AI brings to organizations is that AI should help humans scale. Organizations should achieve much more with the same number of people. We want to improve profit or EBITDA per person. We want to see people spending less time on toil and more time in their flow and genius zone. The translation from people having less waste and more leverage should be that every time we see a person use AI, it drives impact, because these people now have more time to provide judgment, creativity, and problem-solving. The ROI for AI starts with what humans stop wasting time on.

Why AI's Impact Lands Unevenly Across The Lifecycle

But the reality is that AI is asymmetric. It has a jagged impact on different areas of the organization.

One clear example is coding or engineering. AI coding assistants are great at coding because a big part of their training data is code that is available through open source, and also because code is a relatively deterministic activity. Even if you are not sure how to code something, you can try many times and there is a concrete target function. So AI is great at improving engineering output.

But when you look at the end-to-end lifecycle of development and product, this impact does not repeat in the same way, at least not right now, in other areas of the lifecycle. Engineering speed may improve significantly. You can argue whether it is 10x, 2x, or 3x depending on the environment. But the other activities needed to build awesome products and reach the point where customers or users are actually using them are not moving as fast. They are not moving as fast because AI is not as good at helping organizations there, and also because these areas are harder.

It is harder to get AI to help with product discovery or product adoption. The observability feedback loop is harder. So many organizations let people improve in the areas where improvement is easiest. That creates local productivity, which is simply not enough.

What Happens When Engineering Stops Being The Constraint

You can 10x engineering, but if engineering is no longer the constraint, that output will create congestion downstream. Or it may create an environment where engineering is starved, because it does not have enough well-shaped work to pull.

In the short term, that may be okay, because many teams have accumulated technical debt and gaps in test automation that they can spend quite a while addressing. So I would not be surprised if your organization is not fully seeing the impact of this starvation bottleneck yet.

One advantage of working on technical debt is that validating technical debt work is much easier than validating new functionality. You are not changing the behavior of the system. You are changing something internal that is observable internally. Even if you are fixing quality issues, that is relatively easy to validate against quality acceptance criteria. Validating value and outcomes is much harder.

So you might already be seeing the congestion. Or you might be seeing a situation where the congestion is hidden, developing, or avoided temporarily, because the engineering organization can use its improvements to catch up on things it has been struggling with for years. In any case, at a certain point, if your engineering organization is growing fast enough, it will stop being the constraint. It will stop being the bottleneck. The congestion will move elsewhere.

Where Is Work Piling Up, And Where Are Teams Starved?

One useful thing to do is start visualizing this. Pay attention to where inventory is accumulating and where starvation is starting to appear. The classic way to look at this is to create the value stream flow for the entire lifecycle of features, products, and ideas that you are developing in your organization.

That is true whether you are using AI code assistance or spec-driven development or not. It is something you should already be doing. But it is even more important now to pay attention to end-to-end flow and the full value stream.

You may notice that things that were explored and built are starting to accumulate before shipping to production, depending on how automated that step is in your organization. Or maybe they are already shipped, you have continuous deployment, and the DORA metrics look good. But when you ask whether this work is actually adopted, used, and creating value for people, either it is not really used or you do not really know.

That is an observability gap. It affects your ability to say whether you are getting impact. It also has another effect: if your AI agents cannot know whether what they are building is being enjoyed and used, they cannot close feedback loops either. That is an even worse situation. Figuring out whether anything you are building is creating the expected impact and outcomes, connected eventually to business impact, is a huge move away from AI activity and toward AI value.

What A Cumulative Flow Diagram Makes Visible

One tool I really like for this is the cumulative flow diagram. A cumulative flow diagram shows, over time, how much work is in each stage of your product development lifecycle. In these cases, you may see good flow of work into the system, but then one stage starts piling work onto the next pile over time.

You might see that working-tested software is growing 10 times faster than it used to, but that does not automatically result in improvement in the next stage. It opens a gap between working-tested software, shipped software, and enjoyed-impact software. That is a good sign that the bottleneck has moved and you need to do something about it.

Once you recognize that your AI activity is turning into AI output, which is great progress, the next question is how to shift toward AI impact. Awareness is the first step, but then you need to use this view of end-to-end flow to focus on the bottleneck.

Subordinate Your AI Effort To The Bottleneck

After you find the bottleneck, you can apply principles like the theory of constraints. Subordinate the focus and capabilities of both humans and AI to the current bottleneck.

If the bottleneck is adoption of features you are building, or training users on those features, then your AI effort should not focus on accelerating coding. It should focus on how to use AI to drive adoption. How can we use AI to make it easier for people to use our features? At a minimum, make sure the features you are building are easy to use and do not require a lot of training and change management effort. Maybe use AI inside the feature itself to train, onboard, and activate usage.

Product management has focused on activating users for a while, especially in product-led growth. It is less common when you look at internal systems and internal capabilities, but it is just as important. Adoption is an issue whether you are building B2B SaaS, enterprise software, internal systems, AI capabilities delivered through MCPs and skills, or internal skills shared across the organization. Are people aware of them? Are people using them? Are people actually leveraging what you built for them? That is the question you want to ask.

Ask: where is our bottleneck, and how can we help the bottleneck scale? One interesting way to do that is to give your favorite AI all of this context about the bottleneck and what is flowing through the system. Assuming it is a smart one, ask it to come up with ideas. Do not just tell it what to automate or what agents to create. Ask it what it thinks is going on and what interventions might elevate the constraint.

Who Should Get Your Deepest AI Enablement First?

Let's go back to the premise for AI. If the high-level premise is to help people move from toil to genius, to help people move from constant multitasking and routine work into flow mode where they can focus on creative work, autonomy, mastery, and purpose, that is a positive premise. But we need to apply even this asymmetrically.

It is not that some people matter less than others. But if we want impact in the organization, there are people we should prioritize helping first: the people currently in the bottleneck. If engineers are not the bottleneck, maybe they are not the first people we should focus on with the deepest enablement effort. Maybe the bottleneck is product professionals. Maybe it is operations. Maybe it is users. We need to look.

Do not just help everybody scale. Focus on helping the constraint scale. You will get to everybody at some point. That does not mean you should not give AI tools to everybody. You should. But when you look at enablement, guidance, support, and focus, the current bottleneck should be one of the criteria.

What Actually Turns AI Activity Into Business Impact

Once you start actively managing the bottleneck, working around it, and subordinating other areas around it, the bottleneck becomes more effective. That might mean improving the quality of what feeds into the bottleneck. It might mean using spare capacity elsewhere to automate work that needs to happen at the bottleneck. As the bottleneck improves, flow and throughput improve throughout the entire pipeline, whether that is the engineering pipeline or any important value stream in your organization.

At that point, you are shifting from AI activity anywhere in the cycle to actual impact and actual value. You are seeing overall throughput of value improve. And then, of course, there will still be a bottleneck. It might stay in the same place or move elsewhere, so you need to go through this cycle continuously.

AI by itself does not necessarily create new value. It can create new speed. But that speed only matters when it improves end-to-end flow and achieves impact. That is not automatic. You need to use flow thinking, flow metrics, and end-to-end systemic thinking to get your AI investments to the point where they actually improve business outcomes.

The winners in the race to shift from AI activity to bottom-line impact will be the companies and leaders that pay attention to how AI moved their bottleneck, then focus their best human and AI investments in those areas.

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

Zoetis CTO on AI Operating-Model Change

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

How do you scale AI past personal productivity?

Most organizations have personal productivity handled. People use AI every day and get meaningfully more done. The step almost nobody has taken is the one after that: getting AI into the business process itself, so the work is different rather than just faster.

I put that to Kumar Venugopal, CTO of Zoetis (the world's largest animal health company, which spun off from Pfizer in 2013) on the Scaling with Agility podcast. He has been in technology for almost 30 years, starting in the dotcom era. What follows is his answer to where the ceiling actually is, and what it takes to get past it.

Does this wave actually feel different?

It feels different. I can tell you that the dotcom 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.

It actually feels like it's going to change things, not just be an add-on. 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: okay, but we were still shopping before, we're still shopping now. This one feels like tomorrow's version is completely different than yesterday's version.

I asked how that shows up inside Zoetis:

It shows up in our veterinarian products first and foremost: the ability to leverage AI to do better diagnostics, better genetics, better everything in almost every product line we sell. It really shows up in every department, in every conversation we have.

It's not just about going out and buying a product. 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? We think people are still critical. It's not going to replace people, the company can't be run by agents. But there is going to be a big impact on how people work, how people function and operate.

The four levels of integration

When I talk to leaders like Kumar and ask what they are doing with AI, they see a lot of the potential, and then we get into what the levels of integration actually are.

There's augmenting human thinking and human decision-making: chatting with Claude, chatting with ChatGPT, Copilot, whatever environment you're in. That's a good start, and it's where most people begin.

The next level is still augmenting human beings, but in a much more structured way. Take contracts. It's not that every time somebody in purchasing or legal needs to do something, they have to feed in the contract and do prompt engineering. We create a project for them: an environment where they only need to drop in an additional contract, and all the context and data is already available. That's almost automated.

The next level after that is where you start to work in an environment with the ability to let the agent think on its own and develop things. Then there's full agentic, where people don't necessarily need to be in the loop: they're only in the loop to build and fine-tune the agents.

Kumar was straight about where Zoetis sits:

We have personal productivity very high. People are using AI every day making themselves more productive. Let's just say 20% more productive. So lawyers are 20% more productive, scientists are 20% more productive. That's pretty well happening. It's not consistent.

That leads to the second part, where we do have focused efforts on taking departmental workflows that are cross-functional in nature and building solutions that are a bit more defined: on the one hand fixed, on the other hand with some flexibility. So a team of medical writers can collaborate and become not 20% individually productive but 40, 50% productive as a department.

On the agentic front, the third and fourth category, we're still in the early stage.

What a concrete agentic bet looks like

This is the part I found most useful, because it is a specific number rather than an aspiration:

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

We're in the process of making a bold decision to just make that fully agentic sooner than later. We'll start with our current workflow, which takes 25, 26 days, and we'll try to get it down to two to three days, because there are still humans in the loop, cyber security, some critical steps we can't miss. Once we hit that, then we have to work on the next step to get more efficient.

My background is more in infrastructure than in pets, so I asked the obvious follow-up: is infrastructure-as-code a prerequisite, and what does agentic AI add beyond it?

The business customers or the functional IT side don't know what they need, they don't know what resources they want to pull, what Azure services to bring in. So there's a whole host of agentic exploration on just the design component: setting up the blueprints, getting it organized.

Then you have the execution mode. We have preconceived infrastructure-as-code templated approaches that are very manual in effort today. Those are guardrails for the agent. You get the design blueprint from the design agent, then a human in the loop checks it, then from that you build actual infrastructure code that pulls out the build scripts based on your templates. And then a third agent, after human review, executes on all of the above.

In the end, the customer should feel: this is my need, these are my project documents, this is the SaaS solution I'm buying, this is the integration I need. That's a complete overhaul of how infrastructure is done.

That is the same transition we've seen in software: from telling Cursor or Lovable "I want an app that does whatever," to taking a step back and planning, what people now call spec-driven development. Kumar is describing an infrastructure-oriented version of the same spec.

When building beats buying

The build-versus-buy line moves once vibe coding is real:

Can we replace SaaS applications through vibe coding: not just infrastructure as code but really software as code? We're exploring a couple of options today. If we could get rid of some basic subscription-based SaaS applications we no longer need, could we use that same approach to build the replacement?

Monday.com is an example. For me that's a very generic piece of software, and we could literally develop that. Why do we need to pay $30 per user per month per license? As a corporate you have hundreds of those.

And they did:

With intent from engineering, we did build a replacement for Monday.com in the span of a couple of days. A working prototype. Does it have bugs? Yes, of course. But actually it's just prompts: the developer didn't really do anything. Could a business person have done that with training? Absolutely. They'd still need help to integrate it.

I've never fully understood where the enterprise value in that category comes from either. But it raises the real question, which is not build-versus-buy: it's who does this work, and who maintains it.

Who actually does this work

I'm trying to spearhead this thinking within the organization as the technology person, but almost everybody's interested in joining this effort. There's almost nobody who says "yeah, AI, I really don't care about it, I pretend to just do my COBOL programming and I'm good to go." Nobody in the technology function at least.

We've got a good variety of people, believe it or not, not just developers, interested in learning about vibe coding or how to automate infrastructure. And that's been a shift: business people can use vibe coding to develop solutions. It might just be a prototype, but it's a start. Business analysts on the IT side can do things they couldn't do before.

We have ideas, we have a ton of people ready to execute on those ideas, we have tools we could give them access to. All we need to do is buy tokens, and that seems to be the big constraint: having enough to go around.

Kumar and I worked together in a previous organization where there was a similar vision with Power Apps: business users in R&D would build things themselves rather than needing IT for everything. As I recall, it was very hard to get traction. I wanted to know whether AI is genuinely different or whether we're about to repeat that.

It's different because Power Apps is really still a technology tool and behaves very much like one. 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. That's easy, but nobody wants that: that's useless. InfoPath and Google Forms can do all that simple UI work.

AI is different for us because we can offer the complete set of services. We can provide integration, databases, calls: things that were not easy to do in the past world, that are still not easy but becoming easier by the day. That seems to be a big difference-maker.

The three competencies

Tokens and access aren't the constraint on quality. Everybody can build something. So what do people actually need in order to build something worth having?

Design thinking helps a lot, where you're thinking in the overall structure, in the design language. Prompt engineering is a critical skill set: it sounds easy, I'm just going to ask the LLM, but how you ask the intent is very difficult to frame correctly.

The third is to learn how LLMs work, even at a middle-school math level. How do they form these neural networks? How do they tokenize? What is this Google paper that transformed the world of neural networks? I ask people to learn that because without it, I don't think they can really understand how to use it well.

Learn how these models work, as detailed as your math skills allow you to go, because I'm not that skilled at math. Softmax functions, vectors, you lose me at that point. So I learn as much as I can.

I asked why thinking holistically matters so much, and what the anti-pattern looks like when people go straight at the solution:

You get a lot of pigeon-holed stuff. You get a lot of forms and kludgy user interfaces. I played with it for a couple of weekends and just left out the overall intent (didn't tell the prompt what it was, just wrote exactly what I wanted) and totally different than what I expected came out.

I even took the design language from tools like Duolingo and said, I want to use this design language, I want you to develop this. It was much more accurate. Just going to tactics brings a completely wrong solution. And people will throw it away, because they'll say that's not what I want. And then next thing you know, they lose confidence in that.

Does agile still matter, or is it in the way?

I hear user stories in that answer. I hear outcomes. So I asked directly whether agile is useless at this point, a given, or a prerequisite the way infrastructure-as-code is.

We do not think agile is useless at all. In fact we are doubling down on agile. 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.

The cycles are a lot faster. The ability to integrate and innovate, to deploy and run again: it's hourly, it's minute by minute, every 15 minutes it can regenerate. So that requires us to change maybe the sprint cycles. But I don't see the process going away: the PI planning, thinking about what you want, putting that into proper epics and stories, getting that fed into a model, getting it QA tested by AI.

You were in the GxP world with me before. That would take us six, seven, eight weeks to run through all of that, document it, put a trace matrix together. In this new world I think we could do that within one week max. That changes the cyclical nature of it, and I like that.

My own belief won't surprise anyone: agile might change, but agility is something you need even more in this space. The harder problem is the business side. People in IT may already know how to work this way. When you get to the business people, they often don't have a development mindset at all: building is the role of technology, we say what we want and it magically appears. That was a challenge in the Israeli Air Force in the '90s and it's still a challenge in pharma companies in 2026.

Kumar was honest that this part is not solved:

There's enough anxiety about AI that people are interested, even if they're lawyers, to understand something. Personal productivity is the easiest thing to get them to understand. But what you're talking about with agility, learning how to do this in a new way: I don't feel like we've gotten there yet.

It's not the resistance. The resistance comes from the fact that I have to change. It comes from: will I have a job tomorrow if I'm able to get rid of the majority of my redlining work as a lawyer? What am I going to do? That's a fear that comes from within.

But the interest is there. If I tell them learn design thinking, learn how the models are built, learn proper prompt engineering beyond your personal space, let's put together a product that can help you accelerate contracts: I don't get too much resistance. They realize their skill sets have to change and are blending with technology. You cannot be a business person and say my role is not impacted by technology.

The role everyone is being moved into

The shift I'm hearing described (and I fully agree with it) is that the role everywhere, even for lawyers and other business people, is to become architects. To become developers of a better and better legal function, or quality function, inside the organization. Not so the organization can run GxP without quality people, they're always needed, but to accelerate the whole machine of getting more veterinary products to market, experimenting more, delivering more value with the same capacity.

I asked Kumar what advice he'd give leaders navigating that transition from AI as a technology to AI as a change in how people see their role.

That's a very difficult question to answer. What I've learned is that education is first and foremost the key. You've got to teach yourself, which I had to do, and you've got to teach your people. We've hosted classes on how do NLPs work, how do you build a model, if we had to build our own how would we build one: not that we're going to, but what would that look like?

Step two, be open about the change. Explore what it looks like. Your role could be different tomorrow.

Step three is really to see what's in it for them. I try to tell people: here's what's in it for you. If you learn these skills you become marketable tomorrow. You don't want to get left behind. College kids come out with innate knowledge, you need to keep up with that.

And we do all of this before we get into departmental workflow conversations: conversations that begin to shift work in the organization.

That last line is the whole sequence in one sentence. Education, then openness about the change, then what's in it for the individual, and only then the conversation about changing how the work is done.

Impact Corner

The 4 Levels of AI Operating Model Integration

Level	Architecture	Organizational Impact
Level 1: Personal Productivity	Individual ad-hoc chat sessions with ChatGPT/Claude.	~10-20% local efficiency boost; no system workflow change.
Level 2: Structured Workflows	Shared projects with pre-configured domain context and data.	40-50% departmental speedup on standard tasks (e.g. contract review).
Level 3: Multi-Agent Collaboration	Spec-driven design, generation, and review agents with human validation.	Orders-of-magnitude cycle time compression (e.g. 25 days down to 2-3 days).
Level 4: Autonomous Adaptation	Autonomous agents executing against encoded guardrails and telemetry.	Continuous organizational capability evolution.

Prompt for Evaluating Departmental Workflows for Agentic Transition

Evaluate this departmental workflow for transition from Level 1 (Personal AI) to Level 2/3 (Structured Agentic Workflow).

Given the end-to-end steps of our current process:
1. Map the handoffs and repetitive review gates between team members.
2. Identify which steps can be codified into structured context, guardrails, and templates.
3. Design a human-in-the-loop validation boundary where human judgment focuses strictly on verification, compliance, and edge cases.

Watch the full interview

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.

Prefer audio? Listen on the episode page or directly on Spotify. Find Kumar on LinkedIn.

We think people are still critical. It's not going to replace people. But there is going to be a big impact on how people work, how people function and operate.

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

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 better experience at work. The tools are paid for. There are peers who are learning and exploring with you. Maybe there is even AI training and enablement in place.

But what I hear from more and more practitioners and leaders is disappointment and frustration about 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 latest GenAI capabilities, especially tools that can go beyond augmenting your thinking and do some actual work, 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, and courage. These attributes are not evenly distributed across the company.
Even curious risk-takers may 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 may come up with AI use cases that don't move the needle. Worst case, 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 and 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 projects 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 tends to extinguish creativity and exploration. Sometimes the predefined solution is not 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 and 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, align around the intent and maintain flexibility about what it will take to achieve it.
From detailed plans to adaptive planning - instead of fully planning exactly what everyone needs to do and when, plan a little bit, do it, sense, and adjust continuously until you achieve the goal.

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

Product and software development organizations have been shifting from project thinking to flow and product thinking. They've been using 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, or IT organization, they are still full of 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 and 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 dependency drag as possible.

AI vibe coding is frustrating when it is bound by the constraints of the wrong ecosystem. It becomes high-impact when it is supported by an organizational operating system designed for building with AI.

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

Product Operating Model, or Just 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 Scaling 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

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/.