In this special episode, host Yuval Yeret flips the script with guest Philip Morgan, an expert on positioning and point of view. They discuss the recent rebranding of the podcast and dive deep into the striking parallels between historical Agile Theater and the emerging risks of AI Theater. Discover why measuring raw activity—like tokens consumed or lines of code written—is a trap, and how organizations can shift toward measuring tangible business outcomes and flow efficiency. You'll also learn about Unreasonable Agility and what happens when R&D goes on the offense.

Chapters

00:08 The Agile Shift in AI and Podcast Rebranding

01:07 Philip Morgan's Background in Positioning

02:36 Yuval's Role as a Plumber for Engineering Pipelines

06:53 How Pain and Opportunity Drive Change (Gillette & Biotech Examples)

15:51 Introspective and Compound Engineering

17:08 Exploring AI Theater vs. Agile Theater

21:44 Shifting Bottlenecks: From Coding to Code Review and Adoption

28:04 The Trap of Vanity Metrics and Token Maxing

33:26 Moving from Output to Outcomes and Business Impact

40:50 Breaking the Status Quo and Resisting AI Mandates

56:21 Unreasonable Agility: Taking R&D on the Offense

Notable Quotes

"If you want to succeed with it, find somebody who talks about the principles, who understands it in depth, who can make changes while still being aligned to the spirit." - Yuval Yeret

"People will find a way to use AI without really getting any value. They will find a way to generate a lot of activity, but not really create any change in the impact." - Yuval Yeret

"There's a sense in which it seems like Agile was sort of waiting for AI." - Philip Morgan

Ready to stop measuring tokens and start measuring real business outcomes?

Reach out to Yuval at yuvalyeret.com or [email protected] to discuss how to build unreasonable agility into your organization.

About PhilipPhilip Morgan is a positioning and point-of-view expert who helps independent service providers thrive by leveraging effective market positioning. He is the author of multiple books on the topic and shares his insights freely at ⁠philipmorgan.net⁠.Scaling AI: From Activity to Impact — yuvalyeret.com

The Scaling w/ Agility Newsletter – yuvalyeret.com/insights

Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

Claude and Codex have a relatively new feature — `/goal` — that lets you set a completion condition and keep the AI running autonomously until it's met.

This capability exposes a real challenge with agentic AI and explains why its shifting the bottleneck to its assymetric capabilities in different stages and domains of value creation.

00:09 The new /goal capability — what it does and how it works

02:07 What the official examples reveal: all output, no outcome

03:02 The missing examples — what outcome-oriented goals would actually look like

04:00 Output vs. outcome: why the gap matters for AI impact

04:45 The real bottleneck — observability and closing the feedback loop

05:45 Live demo: setting an outcome-oriented /goal on a blog post

08:30 What the loop did — changes made, open items, what's next

Are your AI goals output-oriented or outcome-oriented? What are you doing to enable outcome-oriented goals in your AI sessions?

And as a final thought - What would happen if your human teams were empowered to seek a /goal?

Insights on Scaling AI from Activity to Impact

Join the Activity to Impact Conversation on Linkedin

AI coding assistants are genuinely good now — coding, debugging, tests, docs. But faster engineering output doesn't automatically become faster business impact. AI has quietly moved the bottleneck: from building working software to validating whether that software creates value for anyone who adopts it.

This episode uses flow thinking, cumulative flow, and the theory of constraints to help leaders see where AI speed is creating congestion — and where human + AI effort should be aimed next.

Key takeaways:• AI creates speed, not automatic value — speed only counts if it improves end-to-end flow• AI impact is asymmetric: engineering scales faster than discovery, adoption, and value validation• Local productivity can create system-level congestion once the bottleneck moves• Tech debt hides the new bottleneck — engineering absorbs extra capacity into easy-to-validate cleanup• Inventory is the signal: watch where work waits, loops, or gets reworked• Subordinate human and AI effort to the current constraint — don't spread enablement evenly

Chapters:00:00 — The promise of AI in engineering02:04 — Why AI's impact is asymmetric05:02 — Spotting the moved bottleneck07:56 — From activity to impact: visualizing flow10:19 — Driving adoption, not just output13:15 — Subordinating people and AI to the constraint15:47 — Continuous improvement and real value

Monday morning diagnostic — pick one AI initiative and ask: What outcome should it improve? Where does work wait or get reworked? If this team gets 2x faster, which group becomes the constraint — and what AI support should be redirected toward them?

"You can 10x engineering and still not 10x the business. Don't force everybody to scale - help the constraint scale."

If this helped, share it with a leader trying to turn AI activity into real business value.

Yuval Yeret explores the evolution of AI adoption in organizations, from activity and output to impactful results. He discusses common pitfalls of AI theater, the importance of focusing on real impact, and strategies to leverage AI for organizational bottlenecks.

00:00 The Journey from AI Activity to Impact

03:59 Understanding AI Output and Its Limitations

07:24 Achieving AI Impact Across the Organization

Dive deeper into how to shift AI from Activity to Impact

Follow Yuval on Linkedin for insights on AI adoption and impact, AI-native organizational strategy, AI bottlenecks, scaling AI intelligently, AI in engineering, and beyond.

The new season of the podcast explores a question that's top of mind for many technology, product, and business leaders these days - How do you scale AI from Activity to Impact? What should your "ways of working" look like to enable you to build great products with AI? To use AI to become a 10x organization?

Today's conversation is with a CTO who's working in the trenches to scale the impact of AI on their organization.

Kumar Venugopal, CTO of Zoetis, the world's largest animal health company, is redesigning how the entire organization makes decisions, builds products, and defines roles — with AI at the center.

In this episode you'll learn what it actually takes to move from personal productivity to organizational transformation, how Zoetis is targeting a 26-day infrastructure workflow down to 2-3 days using a three-agent pipeline, why design thinking is the skill that separates useful AI output from useless output, and why agile matters more in the AI era, not less.

"The real opportunity with AI isn't strictly automation. It's how you embed it into how we make decisions." — Kumar Venugopal

"We are doubling down on Agile. Even the agentic approach has to be built with a minimum viable product approach, with proper user stories. The cycles are a lot faster, but the process doesn't go away." — Kumar Venugopal

Chapters:
00:00 Introduction — from 8086 to the AI era
03:01 Why this AI wave feels systemically different
05:30 AI in veterinary diagnostics and decision-making
08:12 The four levels of AI integration
11:01 Infrastructure automation — 26 days to 2-3 days
13:57 Design thinking as the missing AI skill
16:29 Build vs. buy — can vibe coding replace SaaS?
19:26 Who does this work and what's the real constraint
21:58 Three competencies every employee needs
25:11 Why Agile is more important now, not less
27:45 Scaling AI beyond the technology organization
30:30 Kumar's three-step change model for leaders

Follow Kumar on LinkedIn for practitioner-level insights from inside a live AI transformation.

The question isn't how many product owners you need. It's how many genuine product problems your product actually has.

In the final episode of this three-part series, Yuval Yeret works through the most complex version of the product ownership question: what happens when a product has grown to multiple teams? The default answer — one team, one product owner — often creates titles without real ownership, especially when teams are organized around technical components rather than product value. Yuval walks through when multi-team product leadership genuinely works, when it doesn't, and what the more uncomfortable conversation underneath usually turns out to be about.

This episode lands the series with the most structurally challenging scenario, and connects product ownership topology directly to team design — one of the most consequential and often avoided conversations in scaling organizations. Essential listening for product directors, heads of engineering, and CTOs navigating a growing product org.

• The right question: Not "how many product owners do we need?" but "how many genuine product problems does this product have?" — a reframe that clarifies the structure instantly.
• Mini-products inside a larger product: When teams are organized around real, independently deliverable slices of product value, multi-leader structures work well. The razor example makes this concrete: shaving experience, handle design, packaging, and price viability are all genuine product problems that can be owned semi-independently.
• The symptom vs. the diagnosis: If your teams can't deliver value independently, giving them product owner titles won't fix it. The ownership problem is a symptom. The team design problem is the diagnosis.

"Product ownership only really makes sense when a team can deliver something of genuine value independently. When they can take a customer problem, work on it, and ship something that actually moves the needle — without needing three other teams to complete it first."

"Giving each of those teams a product owner doesn't change the underlying dynamic. It adds titles without adding real ownership. And what you often end up with is product owners who feel like they should have more authority than they do, and teams that are still fundamentally waiting on each other."

"If your teams can't deliver value independently, the product ownership question is a symptom. The underlying question is whether the team structure is set up to enable that kind of independence — and if not, what it would take to get there."— Yuval Yeret

Related reading on yuvalyeret.com:

• When and Why Do We Need a Product Operating Model?

Are your teams structured around genuine product problems they can own end to end? Or around technical components that make independent ownership hard?

Experiment to try this week: Pick one team in your product org. Ask them: what's the last thing you shipped that delivered value to a customer without depending on another team to complete it? If they struggle to answer, you have a team design question hiding inside your product ownership question.

Yuval Yeret helps leaders maximize outcomes through strategic, nuanced agility. As both a SAFe Fellow/SPCT and Professional Scrum Trainer, Yuval is frequently brought in to help organizations evolve from agile theater and feature factories toward product-oriented agility — building on existing investments rather than starting over.

📩 Start here: Scaling w/ Agility Crash Course — a free email course to help you scale without falling into the process theater trap.

🔗 Follow Yuval on LinkedIn: linkedin.com/in/yuvalyeret

Two titles, one product, and a gap in accountability that's quietly costing you more than you think.

In this solo episode, Yuval Yeret tackles one of the most common structural problems in product organizations: the split between product manager and product owner that creates ambiguity instead of clarity. Drawing on client patterns across hardware, software, and platform organizations, Yuval unpacks the misunderstanding at the root of this confusion — and makes the case that product ownership is an accountability, not a workload. The result is a practical framework for knowing when one role is enough, when splitting genuinely makes sense, and how to tell the difference.

• Accountability vs. workload: Product ownership means being accountable for the value the team creates — not writing every story or attending every standup. Confusing the two leads to a split that solves the wrong problem.
• The proxy problem: When someone gets the product owner title but not real decision-making authority, you've created a proxy. Proxies manage queues. Teams that work with proxies quickly learn the real decisions happen somewhere else.
• The no test: Can the person who's supposed to own your product say no to a feature request without escalating? If not, the structure isn't supporting the accountability.

"Product ownership doesn't mean doing all the inbound work yourself. It means being accountable for the value the team creates. Owning the outcome."

"When you split the role and give someone the product owner title but not the real decision-making authority — when they're essentially relaying direction from the product manager to the team — you've created a proxy. Someone who manages a queue rather than owns a product."

"Teams pick up on this pretty quickly. They learn that the real decisions happen somewhere else. So they start going around the product owner, escalating directly, or just making calls themselves and hoping it works out."

If you're not sure whether your product org is set up to make real product decisions or just manage requests, that ambiguity is worth resolving.

Experiment to try this week: Ask your product owner (or product manager) to say no to the next non-critical feature request that comes in — without checking with anyone first. Watch what happens. The reaction will tell you whether the authority matches the title.

Yuval Yeret helps leaders maximize outcomes through strategic, nuanced agility. As both a SAFe Fellow/SPCT and Professional Scrum Trainer, Yuval is frequently brought in to help organizations evolve from agile theater and feature factories toward product-oriented agility — building on existing investments rather than starting over.

📩 Start here: Scaling w/ Agility Crash Course — a free email course to help you scale without falling into the process theater trap.

🔗 Follow Yuval on LinkedIn: linkedin.com/in/yuvalyeret

In hardware-software companies, life sciences, and industrial tech, a familiar pattern emerges: a platform team serving multiple internal customers, one product owner caught between competing roadmaps, and no one with the standing to make the tough calls. In this episode, Yuval unpacks why this happens, what it costs, and what a more workable structure actually looks like.

What you'll hear:

• Why platform teams often end up without real product leadership even when someone has the product owner title
• The difference between having a title and having organizational standing
• How escalation patterns are usually a structural signal, not a performance problem
• One approach to giving platform teams genuine product direction — and why it's usually less disruptive than it sounds

From Shared Service to Strategic PlatformIf your platform team stopped shipping tomorrow, what would happen to your other products? If the answer is trouble — that team is one of the most strategically important things in your portfolio. It just doesn't look like it because it doesn't have a price tag on it. Strategic things need real ownership.

This is part of a three-episode series on product ownership topology considerations in the trenches:

• Episode B (this one): The internal platform problem
• Episode A: One product, one team — who actually owns it?
• Episode C: Multiple teams — when do you need more than one product leader?

About Yuval

Yuval Yeret helps midmarket and scaleup leaders shift from product development and business growth friction to impact through nuanced product thinking and agility applied in the tech/product org and beyond.

For more insights check out www.yuvalyeret.com/insights

Follow Yuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

Most sales leaders are stuck running the machine. Few stop to ask whether the machine is even working.In this episode of In the Spotlight, Roi Carmel sits down with Yuval to break apart the two hats every revenue leader wears — operating the team and building it — and why most teams only do one.Yuval has spent over two decades helping organizations build self-improving teams, starting in product and engineering and now working directly with go-to-market leaders. His approach borrows hard-earned lessons from product development and applies them to how sales and marketing teams adopt new processes, frameworks, and tools.In this conversation, Yuval and Roi cover:· Why leaders who only operate eventually stop improving· The 30% adoption problem — and why most change initiatives fail before they start· Why deploying a framework like MEDDPICC isn't a project, it's a journey· How Computer Associates launched a competitive campaign in 6 weeks while other divisions were still planning· Why co-creating change with sales teams beats inflicting change on them· What product-market fit has to do with internal tool adoption· The role of cross-functional teams when you're building the system, not just running itThis isn't about running more sprints. It's about building teams that learn while they sell.Connect with the Spotlight Community:🌐 www.spotlight.ai🔗 www.linkedin.com/company/spotlight-ai▶️    / @spotlightaivideo  

Why "Rules Written in Blood" Kill Agency—and How Stewardship Restores FlowWhen companies scale, the default move is to add "boxes and rules" to maintain control. But this functional isolation often creates massive friction, turning G&A into a bottleneck instead of an accelerator. In this episode, Tyson Bertmaring and Michelle Holliday join Yuval to explore how shifting from rigid management to "Stewardship" allows your organization to evolve as a high-capacity living ecosystem rather than a bureaucratic machine.

Inside this Episode

• (00:00) The G&A Specialization Trap — Why splitting into silos for efficiency actually slows you down.

• (04:44) Rules vs. Trust — How to stop punishing the many for the past mistakes of the few.

• (10:18) Goals, Principles, and Rules — Building a framework that gives employees context instead of just a checklist.

• (15:05) Stewardship as Organizational Gardening — Why you must tend the "relational soil" where growth happens.

• (24:06) Blurring the Org Chart — Leveraging overlapping responsibilities to catch value that typically slips through the cracks.

• (39:49) Identifying "Zombie" Policies — How to audit the relics of past bureaucracy currently draining your team.

• (52:32) The Bird’s-Eye View of G&A — Transitioning to agile, interdependent service teams that scale with the business.

Notable Quotes & Aha Moments

• "If we trust people to work on million-dollar experiments, we should probably trust them to make $10,000 decisions."

• "Stewardship is recognizing the complexity of an organization and knowing what should be controlled versus what should be tended."

• "We accept silos as 'just how work is,' but those boxes are exactly what prevents flow."

• "The only way out of the 'rat race' is to collaborate—it leads to belonging rather than isolation."

Deepen the Relationship

Connect with Tyson, who’s working on evolving partnership ecosystems in Biotech

Dive deeper into the world of Stewardship in Michelle’s book The Age of Thrivability

Your Next Step: Take the bird’s eye view

Invite a few people from around your G&A organization to take the bird’s eye view with you. What do you see? What’s flowing? What’s clogged? What could be the benefit of taking the bird’s eye view more often? 

Scaling w/ Agility with Yuval Yeret

Yuval Yeret helps scale-up leaders build resilient, high-capacity, thriving ecosystems that drive real business results. Get more of Yuval’s insights on scaling organizations with agility.