Scaling AI: From Activity to Impact

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.

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 [https://yuvalyeret.com/category/ai-activity-to-impact/] Follow Yuval on Linkedin [https://www.linkedin.com/in/yuvalyeret/]for insights on AI adoption and impact, AI-native organizational strategy, AI bottlenecks, scaling AI intelligently, AI in engineering, and beyond.

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 [https://www.linkedin.com/in/itleaderdna/] for practitioner-level insights from inside a live AI transformation. https://yuvalyeret.com/category/genai/

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? [https://yuvalyeret.com/blog/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 [https://pages.yeretagility.com/scaling-w-agility-crashcourse] — a free email course to help you scale without falling into the process theater trap. 🔗 Follow Yuval on LinkedIn: linkedin.com/in/yuvalyeret [https://www.linkedin.com/in/yuvalyeret/]

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 [https://pages.yeretagility.com/scaling-w-agility-crashcourse] — a free email course to help you scale without falling into the process theater trap. 🔗 Follow Yuval on LinkedIn: linkedin.com/in/yuvalyeret [https://www.linkedin.com/in/yuvalyeret/]