Scaling AI: From Activity to Impact

Yuval Yeret | Yeret Agility
  • 0.0 (0)
  • Technology

Scaling AI: From Activity to Impact is for technology, product, and business leaders asking a hard question: how do we turn all this AI activity theater into real business impact? Yuval and his guests explore what needs to change in how organizations choose, fund, learn, and work with AI — including how native AI capabilities can help scale AI itself. Building on its roots in scaling with agility, the podcast applies adaptive, product-oriented thinking to the biggest operating-model challenge facing organizations today.

  1. 3d ago

    Beyond Token Caps: How Enterprises Actually Measure AI Impact

    Most enterprise AI conversations get stuck on the wrong number: how many tokens an employee should be allowed to burn. Tomer Elias argues the cap is the least interesting question in the room. The hard part is attribution, knowing whether any of that spend moved a business metric at all. We compare notes on what enterprises are actually doing right now, why AI keeps exposing organizational problems that predate it, and what has to be in place before "AI impact" means anything. About the Guest Tomer Elias is a product executive with more than 15 years leading startups from zero to one and one to 100, through unicorn and IPO stages. His focus has been AI and data throughout. He was part of the first AI lab in Israel, helped build a cybersecurity unicorn, and served on a committee defining agentic identity standards alongside OpenAI, AWS, and Cloudflare. He is currently mapping how enterprises adopt AI and where they sit on the maturity curve. Chapters00:00 Why this conversation00:54 Tomer's background: AI labs, a cyber unicorn, agentic identity standards02:26 What actually changed with gen AI: ambiguity02:50 Human operating systems and agent operating systems06:17 Setting a token cap, and why the number isn't the point07:19 Measuring outcomes was broken long before AI08:43 Activity, output, outcome, impact: what the work really looks like10:55 AI surfaces the organizational DNA you never fixed11:19 The factory lens: an industrial engineer's view of the enterprise14:31 Goldratt and the constraint: where AI actually pays15:56 Two levels of observability: spec conformance vs. value19:00 A worked example: meeting transcripts as context20:33 Kill criteria and staged funding for AI experiments22:41 Build vs. buy, and the question nobody asks first25:09 The rise of the business engineer25:50 The digital twin that knows your stack28:06 Data infrastructure: the real enterprise blocker30:05 Closing the loop: telemetry, usage, decisions34:12 Psychological safety and toxic token usage39:32 Security guardrails: MCP safety, DLP, sandboxes42:54 Who builds beyond product and engineering?46:54 Teaching product skills instead of staffing PMs Notable Quotes "AI puts the credit card at the hand of the employees. But without the oversight and training, costs can spiral. But high usage doesn't really mean a bad thing. It's not good or bad. The question is what's the impact that you get out of that." — Tomer Elias "Once you implement AI in your organization, it surfaces your DNA and the organizational culture that didn't change for a while and now needs to change if you really want to push impact with AI." — Tomer Elias "Any improvement away from the bottleneck or from the constraint is meaningless, and any improvement directly at the constraint is a real multiplier." — Yuval Yeret "If it's a healthy DNA, people would feel safe to experiment. And if it's a toxic culture, you would get toxic token usage and activity theater." — Yuval Yeret Links and ResourcesEliyahu Goldratt, Theory of Constraints and The GoalReal options and innovation accounting for staged funding of experimentsTools referenced in the conversation: Glean, Zapier, Salesforce, Gong, Datadog, Claude, ChatGPTTomer Elias on LinkedIn: https://www.linkedin.com/in/tomer-elias1 If you're working on turning AI activity into business impact, I write about this every week in the Scaling w/ Agility newsletter. Creators and GuestsYuval Yeret — Host, AI transformation advisorTomer Elias — Product executive, AI and data Scaling AI: From Activity to Impact — yuvalyeret.comThe Scaling w/ Agility Newsletter – yuvalyeret.com/insightsYuval's Linkedin – https://www.linkedin.com/in/yuvalyeret/

  2. Jun 2

    Why the Pivot? Tracing the Line from Scaling Agility to AI Impact

    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 yuval@yeretagility.com 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/

  3. May 27

    Claude's /goal Feature Just Exposed A Real Challenge With AI Agents

    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

  4. May 21

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

    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.

  5. May 14

    Avoiding AI Theater: Strategies for Real Impact

    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.

  6. Apr 14

    Beyond AI Hype: Building an AI-Powered Organization w/ Kumar Venugopal, CTO of Zoetis

    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.

  7. Apr 6

    When One Product Needs More Than One Leader: Getting Multi-Team Product Ownership Right

    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

  8. Mar 30

    Who Actually Owns Your Product? Why the PM/PO Split Often Creates More Confusion Than It Solves

    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

See All (45)

About

Scaling AI: From Activity to Impact is for technology, product, and business leaders asking a hard question: how do we turn all this AI activity theater into real business impact? Yuval and his guests explore what needs to change in how organizations choose, fund, learn, and work with AI — including how native AI capabilities can help scale AI itself. Building on its roots in scaling with agility, the podcast applies adaptive, product-oriented thinking to the biggest operating-model challenge facing organizations today.

Information