Yuval Yeret's Blog

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

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. The same 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 — that 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. Basically at every stage it's worth doing learning.

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.

The wait it makes visible was already there: the feature might be deployed, but it's not really providing the potential value. And the limit on that state is doing deliberate work rather than adding drag — don't start new features, take care of adoption before starting new things. In that same team the flow problem was nowhere near this lane: implement kept growing while Done didn't, and most of that band was really waiting for code review.

"We don't have time for all that right now"

I think it's a choice. If you don't have time for this, then you're wasting your time on other things.

Impact Corner

One lane, one class of work

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.

The backfill exercise

Take the epics already closed as Done, give them the state they never had, and sort:

1. Adoption confirmed
2. We don't know
3. We know there isn't any

Pile 2 is the finding.

Prompt for an AI coach

Help us inspect this work without treating release as success.

Separate what we know into output, outcome, and impact:
- Output: what was shipped, enabled, or introduced?
- Outcome: what behavior changed, for whom, and how do we know?
- Impact: what business indicator should move if this outcome matters?

Flag where we have evidence and where we only have a hypothesis. Suggest the
smallest next observation or experiment that would raise confidence. Do not
recommend building more until the current learning gap is clear.

Preference snippet

For a team constitution, working agreement, or AI preferences file:

Do not treat release as success for product bets, AI initiatives, or workflow changes.
Ask what behavior changed before claiming value.
Ask what business indicator moved before claiming impact.
If the evidence is missing, define the smallest next observation or experiment.

The AI Traction Scorecard is a quick way to see where you stand.

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? Does your board stop at deliverable and output, or does it go towards outcome — the changed behavior for somebody?

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

Flow Metrics: The Problems They Help You See

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.

When everyone is busy but nothing important finishes

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

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

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

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

When forecasts are mostly hope with formatting

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

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

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

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

When blockers show up too late

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

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

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

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

When the same people are involved in everything

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

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

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

When the portfolio has too many good ideas

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

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

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

When local improvement does not improve the business

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

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

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

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

What the four flow metrics are really for

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

Together, they help with three leadership conversations:

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

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

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

A simple way to decide whether flow metrics are worth it

Ask these questions:

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

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

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

That is why focus on flow.

A lightweight self-assessment prompt

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

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

Which flow metric should you start with?

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

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

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

How to Calculate Kanban WIP Limits in the AI Age

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';

The question I hear after explaining why WIP limits matter is usually much more practical: Fine. What number should we actually put on the board?

There is no universally correct number, but there is a defensible way to choose a starting one. My current rule of thumb is:

Decide whether you want to keep doing what you are doing today or deliberately change it. A lower limit is a nudge toward more focus, collaboration, and improvement.
Count the genuinely independent human collaboration pods that can steer, judge, and integrate the work.
Start with one actively guided feature per pod. Test a second only when an agent is pursuing a goal autonomously long enough to create real waiting time, and you have exhausted useful finishing work inside current WIP.
Cap that number at any shared review, architecture, product-decision, integration, environment, or release constraint.
Add a small, controlled flow buffer. Compare one extra slot, half again, and twice the active work rather than pretending one choice always wins.
If you have useful data, compare those numbers with the WIP level the system was at or below on half of observed days, and the level it was at or below on 85 percent of observed days.
Size Ready queues to last until the next replenishment opportunity (the next trip to the supermarket), not to keep everybody and every agent busy forever.

Then try the policy for two to four weeks. If you or your team feel spread too thin and want to do something about it, lower WIP until the limit makes you finish, help, review, pair, or improve the system before starting more. If you are happy with the current pattern, leaving it alone is a legitimate choice. Just do not expect an unchanged limit to create new collaboration by itself.

AI changed the temptation, not the constraint

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.

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.

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.

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

Outcome Framing Coach: From Output to Outcome

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';

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. To help leaders, Product Owners, and teams break this habit, I created the Outcome Framing Coach skill.

What is the Outcome Framing Coach?

It's 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. Here are some one-click prompts you can use to start a conversation with your preferred AI, pointing right back to this skill:

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/outcome-framing-coach/.

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.

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

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/outcome-framing-coach/) — 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/.

AI Agents Run Toward Goals. Are Yours Worth It?

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.

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

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.

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

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

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

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

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

AI Isn’t Failing — Our Operating Systems Are

Yuval Yeret — Fri, 24 Oct 2025 00:00:00 GMT

Why do most enterprise AI initiatives fail to deliver business value?

The stat everyone is quoting is that about 95% of AI projects fail — meaning people are spending money on AI and not seeing the value afterwards. That is understandable. It is very new technology and it is certainly not well understood yet. But the conclusion most people draw from it, that the models are immature or the data isn't clean, is the wrong one.

I worked through a different explanation with Dave West, CEO of Scrum.org, on the Scrum.org Community Podcast. I think AI is one example where organizations without the right operating system, without the right approach, are struggling to get the value out of it.

The déjà vu in that number

When Dave brought up those numbers, I had déjà vu, because we both know what the CHAOS report says about the success rates of IT projects — success from the perspective of do they complete on budget, on time, do they deliver the scope. Later on, after we improved that and created better feature factories, we started to look at whether they were delivering outcomes. Is there evidence that those successful projects, that minority of successful projects, are actually moving the needle for the business?

We've gone a long way towards creating more value for our businesses. I don't think we're anywhere close to the nirvana of being customer-centric, outcome-focused, empirical, evidence-based product organizations in IT or in technology in most organizations. But when you start to look beyond the people who have been exposed to these ideas, it's like the stone age.

Dave pointed out where the AI spend is actually happening, which sharpens the problem:

A lot of AI adoption is being done outside traditional IT organizations. It's being done in sales, marketing, legal. And they're taking this technology and saying, "can I build something that quickly reviews contracts?" And they build something and it works, and then they realize it doesn't work quite as well as they thought, and then they're like, oh, that was unsuccessful.

It's a similar challenge: there's this new technology, there's this new opportunity, and it's very tempting to spend your time on LLM geekery, making sure the data is clean and talking about legal aspects all the time. But very few people talk about why are we doing this. What's the business purpose for this?

Why "manage it like a project" is the trap

Even the disciplined organizations are running AI adoption as a project — and we've learned what the problems are with treating complex strategic initiatives as projects. We've learned that focusing on scope, even if you deliver that scope, doesn't necessarily deliver the value.

Dave put the structural version of it well:

EOS and most operating systems being used by organizations would treat AI like they would treat "we need to build a new building" or "we need to run an event." It literally is a defined, scoped sort of like it's a project. When your operating system has this concept of projects within it as the mechanism for driving change, that isn't necessarily the most successful orientation for AI.

Yes — but I'd argue it's not just AI. Whenever I look at the challenges companies are really facing, the strategic challenges, what keeps their CEO and senior management team up at night — tackling those challenges, developing their organization, working on growth — whether it's a mom-and-pop shop, a scaleup, a mid-market company or an enterprise, those challenges are complex. Regardless of whether they are product development challenges or company development challenges.

There's a lot that is unknown, a lot that is uncertain. They're bets. They're bets on: if we build this new standard operating procedure, if we build this new process, if we give people ChatGPT, if we do this, if we do that — will people want to use it? Is it something that is worth our investment? Is it even feasible to achieve?

A lot of the time our focus is too much on "is it possible to achieve this," or even "let's just assume it is, let's build a plan and deploy it." We're not thinking about the human aspects. We're not thinking about our organization as an organism, as a living thing. We're not really making the assumption that we don't know — that we need to balance championing something with being skeptics about it.

And it is not in the interest of leadership teams to be skeptics about their own strategic initiatives. That is the uncomfortable part.

The product paradigm, applied past the edge of the product org

How I backed into company-level operating systems: in some of the organizations I work with, Dyno Therapeutics was one example, we realized that in order to really move the needle on the strategic growth the organization needs, you have to go beyond just the product organization. You improve the product organization, you level up your agility, and you see the constraint is elsewhere. It's in marketing, or bringing in the right partners, or making the onboarding experience work well.

So we saw opportunities to leverage the same ideas we use to accelerate and create better outcomes inside the technology organization — in people operations, in finance, in marketing, in partner success, and in the interaction between these different groups, because a lot of strategic value comes from the interaction.

Think about what a mid-market company or a scaleup faces. There's running the operation, running the customer factory, running marketing, bringing people through the funnel, fulfillment, serving them — whatever it is that you do. It can be a professional service, a dental clinic, an architectural firm. It can be a software-as-a-service company that onboards and activates people, where you need to make sure they use the product, that they're happily using it, that they don't churn out the other end, that they refer other people, that the flywheel is spinning.

That's running the operation. But you constantly need to think about how to spin the flywheel faster. You need to continue developing the organization — developing a product that serves your external customers better, and also developing the company so that people inside it can do a better job serving those customers and operating that customer factory.

The product metaphor works because once you start to see these key business processes as products, and you have people who own their effectiveness at creating outcomes, you start to think about how to develop them.

Dave named the practical benefit, and did it from experience rather than theory:

As a small business when I was at Tasktop, making decisions about where we invested — do we invest in a help desk, do we instead invest in more software engineers — was actually really hard. At that moment of crisis we made a decision and hired somebody or spent some money. It was very not strategic. The benefit of approaching this from a product paradigm is you get that strategicness, because you've decided where you're putting your money and then you can review how that's going.

The decomposition anti-pattern

As Dave talked through decomposing a business into products, there was a siren going on in my head, because of the anti-pattern I see often when people go into this.

It's tempting to take your organization and say: you're the VP Sales, sales is a product. You're the VP Marketing, marketing is a product. You're the VP Product, product is a product. You're the VP People, that's a product.

But what we saw at Dyno is that the product is not those functions. The product is the onboarding experience, and separately the overall employee experience — what they call the aviator experience — and the partner experience, and capsule development. That often cuts across functions.

The jury is still out on whether "products" is even the right language for these organizations. There are advantages and disadvantages, and the alternative is to speak about value streams, and the difference between operational value streams — how the organization creates value directly — and what enables it to create value.

I do see an advantage in product language, and it's not because we talk about product in Scrum. The main advantage is that when I talk to leaders of mid-market firms, there's a trend: in order to scale, to better fulfil the needs of your customers, you need to productize. That's a language that is starting to resonate. Be intentional about the balance between the bespoke services you provide and productized services. Even if you're not a product company, productize your services.

Take me as an example. I'm a service provider — an agile coach, a management consultant, whatever you want to call it. You can consume my services by having a conversation with me and we'll figure out the best way to support your organization. Or I could create a productized service: there's an SKU, an agility roadmap, I help you figure out how to find gold with AI.

Going through that switch from bespoke into a productized service is a product development exercise, although it might not have any product in it. You see a lot of legal firms, accountants, financial advisors and doctors switching models — from a visit to a concierge approach or a membership — even though there's no product around that. They need to develop their organization to a point where that works. That is complex. That's the sort of stuff we're talking about, and that's why I think product could be a useful metaphor.

Context is the work now

Dave made a point about his own AI usage that connects directly to this:

The most successful uses personally of AI that I've had are where I bound the problem. I provide a consistent context, I pick the right model, the AI engine knows the boundaries. The solution that comes out is very different when it hasn't got those boundaries.

I think about it as context development. The additional information you provide the AI engine when you're working with it on anything is crucial. I spend more time developing the context for my AI usage than the actual prompts, and it has improved my personal AI effectiveness dramatically.

Look at how I do it. I create a space — a ChatGPT project, or a Gemini Gem — and the instruction prompt I use there, I develop using something like Scrum. I don't run a full Scrum process, but I stop myself, say after a day of using that prompt, and I ask myself as well as the AI engine: how are we doing? Are we getting good results? How could we improve this prompt based on the conversations we've had? Let's look at how often I had constructive feedback for you, or even non-constructive feedback for you, because I'm not as nice with AI as I should be with the future overlords.

And we improve the prompt. We create another version of it. It's not under source control right now — I should probably do that better — but I have a version 4.5 of my personal advisory board Gem that I use.

The more you think about your products, your customer factory, how you're creating value in your organization, where the constraints are, where the bottlenecks are, what the strategic focus is, the better results AI will give you. And the better results the people developing AI capabilities for the organization will be able to deliver.

Where do you want to hire AI?

Where I see people finding gold using AI — whether it's a small organization, an individual, or an enterprise — is when they use product techniques, whether they call it product or not, to think through AI strategy and execute on AI attempts with the mindset of: what's the problem we want to solve here, what is our strategy, where do we want to play with AI inside the organization.

The challenge in the past was where do we hire another person. The challenge right now is: we're not going to hire additional people, but where do we want to hire AI?

Is it marketing? Is it the fact that we're leaking people? Is it the overall customer experience, which involves both the product and customer success? Is it onboarding and activating people — we get MQLs, but those people aren't really using our product? Maybe it's something on the product side. Maybe it's something else that relates to onboarding customers.

Whatever it is, we want to focus AI on our strategic challenges, on the things we believe will move the needle or will affect the bottom line if we improve them. Things like OKRs provide a really good mechanism for grounding that focus. And if you're using a product model, those OKRs work within the context of the products and within the context of a broader business strategy.

Watch the conversation

This article is based on my crossover conversation with Dave West, CEO of Scrum.org, on the Scrum.org Community Podcast. We go further on the operating-system question, the product-versus-value-stream debate, and the Toyota production-system-versus-design-system analogy.

Check where your AI effort is actually creating traction

If this sounds familiar, take the AI Traction Scorecard. It is 11 questions, about five minutes, and it will help you see whether your AI effort is creating traction, mostly producing activity, or getting stuck in theater. Use it to find the next constraint to inspect before the next pilot turns into another status update.

Whatever it is, focus AI on your strategic challenges — on the things you believe will move the needle, or will affect the bottom line if you improve them.

Originally published at https://yuvalyeret.com/blog/ai-isnt-failing-our-operating-systems-are/.

The Product Operating Model Audio Series

Yuval Yeret — Fri, 17 Oct 2025 00:00:00 GMT

Do you feel inspired by becoming an empowered product organization, but are unsure of the concrete steps to take to initiate the transformation?

What You’ll Learn:

Why Agile Feature Factories Fail—and What to Do About It
Assessing Your Current Operating Model—Are You Stuck in Projects?
Principles of Effective Product Operating Models
When does a Product Operating Model make sense?
Making It Real: Mapping Your Trail Toward Transformation

This is for you if you’re:

A Head of Product, Technology, Engineering, or Product Ops, trying to apply or scale product-led practices
Tired of theory or comprehensive perspective frameworks and hungry for real-world strategies that work
Too busy to sit down for training or even watch a video “masterclass” (Webinar in disguise…) and prefer to consume audio podcasts.
Not a fan of 6-figure, inspiring slide decks left behind by expensive consulting firms and product experts.
Trying to discern

Listen to the episode

This came out of an episode of Scaling AI: From Activity to Impact.

Listen on the episode page or directly on Spotify.

Originally published at https://yuvalyeret.com/blog/welcome-to-the-navigating-the-product-operating-model-landscape-audio-series-episode-0/.

Reviews in a Product Operating Model

Yuval Yeret — Wed, 01 Oct 2025 00:00:00 GMT

Reviews reveal the real operating model

Show me your review sessions and I can usually tell whether you are in process theater, feature-factory mode, or product-lab mode. The review is where the operating model becomes visible. Are people reporting on work completed, or are they inspecting whether the work is changing outcomes?

https://youtu.be/AifEjtiZ4rI

If you want to shift from a feature factory to a product lab, change the focus of your review sessions. I am working with a product leader who wants the organization to focus on outcomes and help product managers think more strategically. Instead of reviews centered on backlogs, plans, outputs, and deliverables, we are coaching product managers to inspect the outcomes they are seeing from the work.

That means asking better questions. What are the leading indicators? Do we still believe this direction makes sense? What evidence are we seeing about how the product is doing? What are we learning from product and business KPIs? Do we have fresh ideas for moving the needle on North Star Metrics? Are there new metrics that matter now?

So how about you? What do your product reviews focus on? What have you changed to move them toward outcomes and impact?

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

Originally published at https://yuvalyeret.com/blog/what-should-reviews-look-like-in-a-product-operating-model/.

Why Do So Many Business Transformations Flop?

Yuval Yeret — Wed, 30 Jul 2025 00:00:00 GMT

Transformations flop when they are managed like rollouts

In this solo episode of Scaling With Agility, I walk through why so many agile and digital transformations fail. I have seen this pattern repeatedly: organizations try to scale change by copying and pasting frameworks instead of addressing the actual friction on the ground.

When you look closely at failing initiatives, you usually find too much work in flight, dense dependency networks, and leadership behaviors that reinforce the silos they claim to be breaking down. Instead of doubling down on top-down mandates and agile theater, treat organizational change more like a product. Validate desirability. Iterate. Learn whether the new way of working solves a real problem before rolling it out everywhere.

https://youtu.be/Cvg7kyxvILo

If you force a solution that is not ready for the mainstream, you kill its credibility. Sustainable change does not come from checking boxes or putting on a show. It comes from creating an internal market for change where teams want to adopt new ways of working because those ways solve problems they already feel. That means looking at flow, cycle time, and work in progress at the portfolio level, not just the team level.

Ask yourself: Are you actually changing how work gets done, or are you just putting on a show?

Listen to the episode

This came out of an episode of Scaling AI: From Activity to Impact.

Listen on the episode page or directly on Spotify.

If this is the problem you are trying to solve, start with the Scaling w/ Agility Crash Course.

Originally published at https://yuvalyeret.com/blog/why-do-so-many-business-transformations-flop/.

Forever Flywheels?

Yuval Yeret — Mon, 28 Jul 2025 00:00:00 GMT

Flywheels are all the rage these days. I'm a fan as well.

“No matter how dramatic the end result, the good-to-great transformations never happened in one fell swoop. Rather, the process resembled relentlessly pushing a giant, heavy flywheel…turn upon turn, building momentum until a point of breakthrough.” (Jim Collins, Good to Great)

A key attribute of a flywheel is the self-reinforcing loop.

Some examples of Flywheels in the agility/product space -

Safety Nets - Investing in test automation and collective ownership that, over time, creates more flexibility in the team, reducing bottlenecks, and creating even more safety and capacity to invest even more in test automation and collective ownership
Working ON the Org/Business - Investing in improvement in general. Spending time ON your business/organization is very hard when there's no "momentum" - when you need to keep turning the wheel to keep it moving. But as you invest in improvement, you start to build momentum, and things become somewhat easier. The same amount of work on the business results in more and more impact, and more and more capacity to focus on the business.
Descaling - Investing in team empowerment/autonomy - can be very challenging when you have a tightly coupled organization. Just getting the teams talking about their dependencies seems to take all the energy and time you have. But as you start to invest in descaling, you make integration and coordination somewhat easier. Which frees capacity and builds momentum and conviction to do more and more of that.

Consistency is crucial for all of these examples. It's not about "installing a framework" and then moving on. It's about the grit and the grind.

You can't talk about Flywheels without talking about their nemesis - the Doom Loop. (aka Downward Spirals)

Tech Debt, Quality Issues, and Hero Culture are a few examples that immediately come to mind.

Look at your organization

Can you identify your flywheels? Your doom loops? Look at both your ways of working and your actual product/business.

Originally published at https://yuvalyeret.com/blog/forever-flywheels/.

Clemens Adolphs on Getting AI Investments Right

Yuval Yeret — Tue, 15 Jul 2025 00:00:00 GMT

Where do AI initiatives actually go to die?

AI initiatives have a well-known graveyard: the proof-of-concept stage. Something impressive gets built, everyone is excited for a week, and then it gathers dust.

I dug into why with Clemens Adolphs, co-founder of AIce Labs, on the Scaling with Agility podcast. He describes the job as helping enterprises get AI initiatives done right end to end — "and not just have everything die in the proof of concept stage and gather dust there." A lot of the pitfalls he sees overlap with what agility is supposed to help with, which is why the conversation was worth having.

The risk nobody tests

The failure usually gets blamed on feasibility. Clemens puts the weight somewhere else:

With everything you ever build there is that market risk broadly — will anybody actually want it once you build it? And market risk doesn't necessarily need to mean, oh, you're building a consumer-facing product and they have to buy it. It could also just be an internal tool that you roll out and you want your people to use, but they don't use it. There's too much friction, and they just rather copy paste from ChatGPT.

That is the part organizations skip. I'm tempted to say an AI-native CRM that doesn't require the salespeople to enter information manually is obviously great, everybody's going to love that — but I've seen so often that even these obvious assumptions eventually fall flat. How often do we think things are really desirable, a field of dreams that people would really come to, and then we jump straight to technology feasibility?

Interestingly, Clemens's counter-example is about where market risk is genuinely low:

Let's say the last big project — it already had some internal validation, because they had a basic tool that did the thing and that had adoption. If you're improving on something that already exists along the dimension that tool was being used, then that typically has very low market risk. It's like, oh, we're paying for this tool because it saves us five minutes.

So the question isn't "is there risk," it's "which risk is the live one here." Improving an adopted tool is a different bet from launching something nobody has asked for.

Prototyping is the new wizard behind the screen

There's an interesting opportunity in how the AI ecosystem is evolving. If you look at vibe coding, or even things that aren't vibe coding, there are so many opportunities to prototype, to create preliminary versions of things that work. They're not proving feasibility from a technology perspective and they're not necessarily going to be production code ever — but they're the new version of the Wizard of Oz test.

The old version was a human behind the screen making things work. The new version is ChatGPT or Claude with some gum and glue and a few prompts, and things work, and we can prove some things very cheaply. If those things work, we can make it a more robust solution.

Take the internal market seriously

Here's the realization I keep coming back to: you have an internal market, and you need to treat it like a market, where people have options. Even when we are developing systems of record, how people use them matters. Your CRM is a system of record, but are people really going to use this feature or that feature, or are they going to do the minimum they have to in order to get away with it? We need to apply the product management and product discovery techniques to the internal market as well. People have a choice to use the products we're building for them internally — and they also have a choice not to.

You can mandate that they use it, but you can't mandate that they embrace it. Then they'll find their workarounds and back channels, and that should tell you something. As Clemens put it, if they're not using your shiny awesome tool, maybe it's worth digging into that and treating it as "we're getting a bad NPS, let's do some user interviews."

Or we're not seeing usage — so let's look at the pirate metrics internally. Are people aware of our tool? Are they activating? Once they're activating, are they actually using it? Do they continue using it? Are they paying for it?

That last one is the interesting one, because internally people don't typically pay for anything. So how do you know people are actually willing to invest in that tool? Maybe it's enough that they invest their time as a replacement for money. Maybe at some point we'll see people paying for AI tokens for usage — are they really willing to pay for the AI consumption of their department's tooling?

Clemens pointed at where that experiment is already running:

It's interesting in the developer space, where famously developers are cheap when it comes to tooling. But with Claude Code and Cursor and this and that, everybody is shelling out money even if it's not reimbursed by the employer, because they just see so much value in what the tools do for them. I still think the business should pay for the tool, but it would be an interesting thought experiment — if we took this tool away from you, how much would you pay to get it back?

That relates to the product-market-fit survey question. How dissatisfied would you be if we took this tool away from you? If we took away the AI capabilities on your CRM, how unhappy would you be — or would you actually be very glad?

I know that from my own space. Few people running agility transformations are willing to ask the teams they work with: are we a keeper? Would you fight to keep using the process, the operating system? Would you fight to keep having access to us as an internal consulting service?

If you're an internal consultant, whether that's an AI consultant or an agile consultant, it would be very interesting to know what the people you work with actually think. Are they willing to tolerate you? Are they going to fight for your time? Are they going to use the first opportunity to throw you under the bus because you're not useful? It might be a tough mirror to face, but it's better to know early than to be surprised when the budget for the enabling function is cut — which happens very often.

The AI-waterfall anti-pattern

I asked what separates the projects that work from the ones that go sideways.

What works is if the objectives and values are clear — what we want to achieve — but there's freedom and leverage and flexibility in the how.

And the anti-pattern is the one where you have a Gantt chart without calling it a Gantt chart.

And it's exactly that, and the whole idea of estimates. What does it matter that we estimate something? You told us this needs to happen then. So it needs to happen then. Or velocity charts — what does it matter that we track velocity? You told us how many stories and which ones you need done.

Let me poke at that, because I'm with him but I want to play devil's advocate. If I'm the business owner or the sponsor, I want some sense of where this is going. I'm going to pay you, or fund my people, and they're going to go away and do their thing.

What is it that we know? We know we need to achieve a certain outcome. What does that outcome really look like? What are the hard points and the soft points? Of the hard points, the use cases we want to show — how many of those are working already at each point in time, and how do we think those use cases will spread over the two or six months we're going to work on this?

That framing is useful, and I've seen it be useful against scope creep. When you don't have anything like it, it's tempting for people to add more and more use cases: this is cool, while we're at it let's add this capability and that capability, because we don't know when this is going to finish anyway, so let's just keep delivering value. But there are diminishing returns. Is it more valuable to deliver the base outcome after two months, or to deliver with these additional use cases after three? If we're not even having those conversations, we're just letting the team figure it out — which might be fine if they have the right context, but only then.

Clemens had the better version of what a status update should sound like:

Last time we showed you it couldn't do this, now it can do that. That's way more interesting than just giving them a report that says last week we completed 37 story points.

Velocity is output. Traction is the needle moving.

I try to talk about the difference between velocity and traction. Velocity is output — not activity. Activity is that we spent six hours on this. Velocity is output. Traction is that this is moving the needle towards where we want to be. We're not just showing you working stuff; it's working stuff that does what you want it to do, at least a small part of it.

That requires the team to be empowered enough to ask whether the use case you added, or the user story you threw in, is actually going to lead to the outcome you want. The best version of the contract between sponsor and team is: tell us what you need, tell us what you really really want, and we will figure out how. You don't have to write the user stories — the team that's going to do the work will slice it into the work they need to do. Tell us the big story of what you're trying to achieve. Tell us the outcome.

Clemens noted the industry is having its own argument about this:

Recently there was this pushback against even using user stories. Linear, the issue tracker, have their whole philosophy written up online, and their point is write issues, don't write stories. Maybe that's the backlash against how they have just been used.

Another recent read was Robert Martin's Clean Agile, where he says user stories are supposed to be very simple, just a placeholder for a conversation that needs to take place just in time when you actually work on the thing. But they have become this thing where they're in Jira and they're three pages long.

And ready months in advance — which creates a lot of waste, because by the time you get there half the acceptance criteria might not be applicable anymore. It's all spec'd out, the designer already made the design for the fully functional thing in Figma, and now you have this super complicated thing with lots of tabs and dashboards and popups. Good luck doing nice modular vertical slicing on that. Everything is meshed together into a giant story, and because of that you have a feature branch working on that story that lives for two weeks.

There is a lot to fix in this ecosystem.

Principles travel; practices do not

Trying to converge, I put my read back to Clemens: these projects are the classic place to be agile in how you develop them, to think from a product perspective, to think about an internal market, to try things at the right level of agility. He got there first with the better formulation — that these projects are the place to be agile, but not the place to do agile. I don't think there's any place to do agile, to be honest.

In this case in particular, the principles very strongly still apply. But if you take those principles and you apply them to a given context, and use that to derive practices, those practices might make sense in that context — and then you port those to a different context and it doesn't work anymore, and you have to go back to the principles.

That is exactly what we believe in here, and it earned him his badge as a friend of the no-BS, nuance-first version of this podcast.

Watch the conversation

This article is based on my Scaling with Agility conversation with Clemens Adolphs, co-founder of AIce Labs. The full episode goes deeper on engagement models for AI delivery, the Swiss-cheese model of AI capability, and where user stories went wrong.

Prefer audio? Listen on the episode page or directly on Spotify. Find Clemens on LinkedIn.

You can mandate that they use it, but you can't mandate that they embrace it.

Originally published at https://yuvalyeret.com/blog/clemens-adolphs-on-the-role-of-agility-in-getting-ai-investments-right/.

From FOMO to JOMO

Yuval Yeret — Thu, 10 Jul 2025 00:00:00 GMT

You start hearing about the next thing—EOS, Agile, Scaling Up, AI.

At some point, there's enough FOMO (Fear Of Missing Out) that you feel like you SHOULD do something about it.

I've had numerous business leaders reach out and ask me to help them "do the thing" (the latest example being AI Transformation).

When that's the ask, adopting a new thing - process, tool, or approach - fizzles more often than not.

Because you don’t really care about the thing for its own sake, you care about expensive problems.

Let me suggest a prediction: If you're entering AI Transformation mainly out of FOMO, it will soon turn into JOMO (The Joy of Missing Out)

That's precisely what I've observed happening with Agile, Scrum, OKRs, and EOS in the past, and I'm already seeing it occur with AI.

Want to sanity-check a big idea before you invest? Instead of blindly following your FOMO, consider having a "why" conversation. This is the conversation I have with leaders who reach out to make sure we head toward real impact instead of JOMO, but you can have it with yourself, your team, or even your favorite GenAI chatbot.

Write down:

The problem you’re solving (who has it, why it matters) or the opportunity you want to leverage
The business impact you expect if you solved/leveraged it.
Why is this so important to you? Why deal with it now? Why not wait a couple of months before tackling it?
The behavior change you expect (who will do what differently, by how much)
What are the alternatives? What have you tried? What else might do the job instead of doing this thing?
The central hypothesis you’re betting on (we believe [business impact] will be achieved if [who] attains [benefit] through the [thing])

If you're still in FOMO mode, think deeper about:

The smallest experiment you can run to test it
The signals you’ll watch to know if it worked

If you can’t see the connection between the thing and your most expensive problems or most lucrative opportunities, it probably isn’t worth your time.

If you can see the connection, you have just framed the initiative in a way that makes it clear why you're focusing on it, what the outcomes are to align towards, and empowers everyone to make the right decisions to steer it along the way based on what you learn.

All of which will improve the odds of getting real value out of this initiative, rather than adding one more abandoned change effort to the pile.

That is the real shift: stop asking whether you should "do the thing" and start asking which expensive problem is worth organizing around.

Originally published at https://yuvalyeret.com/blog/from-fomo-to-jomo/.

Managing a Product Transformation like a Project

Yuval Yeret — Wed, 09 Jul 2025 00:00:00 GMT

The next time a big consultancy pitches a transformation - let's say a project-to-product transformation - ask them how they recommend managing it.

Then listen for whether what they describe looks more like a project or a product.

For example, will they measure vanity metrics or product metrics?

It just goes to show how tempting vanity metrics are. They are easier to collect, easier to explain, and easier to defend than the real question: is the change actually improving how the organization creates value?

That real why can be uncomfortable, especially when the honest answer is "because a big consultancy firm sold us on it." It is also frightening to look at the actual outcomes of our initiatives instead of the activity around them.

Here's the thing.

As change agents driving a product operating model, we are asking people to behave differently. We should show them how that looks:

Starting with a hypothesis: We believe that we will achieve stronger, more sustainable growth if product teams can deliver measurable customer outcomes with a product operating model that gives them end-to-end ownership and clear success metrics. (Don't copy-paste - create your own!)

Provide leading indicators, for example -

% of product teams who can clearly state their product mission and intended outcomes (ideally without looking it up)
% of new product initiatives that go through hypothesis prioritization to determine whether to test, ship and measure, or drop
% of new product initiatives that require testing undergo a discovery/truth curve process.
% of product teams report they are empowered at the right level to make decisions
% of product teams report less dependency overhead

For Key Results / Success Criteria, move from % to a discrete result, e.g., 80% of product teams can ...

And don't forget Kill Criteria, such as after 6 months, fewer than 30% of teams can articulate their mission and outcome metrics

What do you think will happen once you start treating your product operating model transformation as a product initiative instead of a project?

If you want a deeper path through this, the Product-Oriented Portfolio Agility Trail Map digs into applying product thinking to the transformation itself.

Originally published at https://yuvalyeret.com/blog/the-irony-of-managing-a-product-transformation-like-a-project/.