Podcasts about product owners

Carmela Then: When Remote Teams Stop Listening—The Silent Killer of Agile Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Two minutes into it, my mind's starting to wander and I started to do my own thing." - Carmela Then   Carmela paints a vivid picture of a distributed team stretched across Sydney, New Zealand, India, and beyond—a team where communication had quietly become the enemy of progress. The warning signs were subtle at first: in meetings with 20 people on the call, only two or three would speak for the entire hour or two, with no visual aids, no PowerPoints, no drawings. The result? Within minutes, attention drifted, and everyone assumed someone else understood the message.  The speakers believed their ideas had landed; the listeners had already tuned out. This miscommunication compounded sprint after sprint until, just two months before go-live, the team was still discussing proof of concept. Trust eroded completely, and the Product Owner resorted to micromanagement—tracking developers by the hour, turning what was supposed to be an Agile team into a waterfall nightmare. Carmela points to a critical missing element: the Scrum Master had been assigned delivery management duties, leaving no one to address the communication dysfunction.  The lesson is clear—in remote, cross-cultural teams, you cannot simply talk your way through complex ideas; you need visual anchors, shared artifacts, and constant verification that understanding has truly been achieved.   In this segment, we talk about the importance of visual communication in remote teams and psychological safety.   Self-reflection Question: How do you verify that your message has truly landed with every team member, especially when working across time zones and cultures? Featured Book of the Week: How to Win Friends and Influence People by Dale Carnegie Carmela recommends How to Win Friends and Influence People by Dale Carnegie, a timeless classic that remains essential reading for every Scrum Master. As Carmela explains, "We work with people—customers are people, and our team, they are human beings as well. Whether we want it or not, we are leaders, we are coaches, and sometimes we could even be mentors." Written during the Great Depression and predating software entirely, this book emphasizes that relationships and understanding people are the foundation of personal and professional success. Carmela was first introduced to the book by a successful person outside of work who advised her not just to read it once, but to revisit it every year. For Scrum Masters navigating team dynamics, stakeholder relationships, and the human side of Agile, Carnegie's principles remain as relevant today as they were nearly a century ago.   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: The Scrum Master Who Learned That Perfect Boards Don't Build Perfect Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The failure part is, instead of leading the team to work toward a common vision, I was probably one of the persons that helped the divide." - Carmela Then   Carmela shares a vulnerable story from her first Scrum Master role at a bank. Armed with training, certifications, and the ability to build a beautiful physical Scrum board with perfectly straight lines, she believed she was ready to lead. But Carmela quickly discovered a crucial truth: mastering the mechanics of Scrum is vastly different from serving a team's real needs. Instead of showing up as a humble learner willing to grow alongside her team, she put on a facade of competence and confidence.  When two Product Owners began fighting for dominance, rather than stepping back and focusing the teams on their shared purpose, Carmela found herself drawn into the political battle, supporting one PO over the other. The result was devastating—a toxic environment where one PO was demoted, and talented team members left the organization entirely. Looking back, Carmela recognizes that her failure wasn't about the Scrum board or ceremonies; it was about not putting the customer and common goals at the center. She learned that Scrum Masters must lead with humility, focus on outcomes rather than egos, and help teams unite rather than divide.   In this episode, we refer to John C. Maxwell and Failing Forward by John C. Maxwell.   Self-reflection Question: When was the last time you prioritized looking competent over truly serving your team's needs, and what did that cost you?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Coaching Product Owners to Be the Voice of the Customer In this episode, we refer to Henrik Kniberg's "Product Owner in a Nutshell" video and Product Ownership by Geoff Watts. The Great Product Owner: Rob Gard's Customer Obsession Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The role of the PO really is to help the team empathize with the user, the customer of the product, because that's how they can develop great solutions." - Steve Martin   Rob Gard worked at a fintech firm and is now CPO of a major fintech company. Steve describes him as having a brilliant mind and being a real agileist—someone Steve learned a huge amount about Agile from. Rob's defining characteristic was his absolute obsession with the user. Everything focused on customer pain points. Working with engineering teams serving military customers, Rob held regular workshops with those customers to understand their pain firsthand. He was literally the voice of the customer, not theoretically but practically. Rob pushed and challenged teams to be more innovative, always looking for better ways of providing better software. His gift was communication—specifically, briefing the team on the problem rather than just reading out stories in refinement sessions. This is the anti-pattern many Product Owners fall into: going through the motions, reading requirements without context. Real product ownership, as Rob demonstrated, is telling a story that helps the team empathize and understand the pain. When teams can internalize customer problems, they develop better solutions. Rob's ability to communicate the problem into the minds of teams enabled them to serve customers more effectively. This is the essence of great Product Ownership: not being a proxy for management, not juggling multiple teams, but being deeply connected to customer pain and translating that pain into context the team can work with.   Self-reflection Question: Do your refinement sessions tell stories that help the team empathize with customer pain, or do you just read out requirements? The Bad Product Owner: Proxies for Management Instead of Customer Advocates Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte   Steve emphasizes that Product Owners often have great intentions but struggle due to lack of training and coaching. The anti-patterns are systemic: commercial managers "dressed up" as Product Owners without understanding the role. Project managers transitioning to PO roles—though Steve notes PMs can make really good POs with proper support. The most damaging pattern is Product Owners spread across multiple teams, having very little time to focus on any single team or their customers. These POs become proxies—representing the voice of senior management rather than the voice of the customer. They cascade requirements downward instead of bringing customer insights upward. The solution isn't to criticize these struggling Product Owners but to help them understand their role and see what good looks like. Steve recommends Henrik Kniberg's "Product Owner in a Nutshell" video—15 minutes, 15 years old, still profoundly relevant. He also points to Product Ownership by Geoff Watts and formal training like CSPO or IC Agile Product Ownership courses. The fundamental issue is meeting Product Owners where they are, providing coaching and support to transform them from management proxies into customer advocates. When POs understand their role as empathy builders between customers and teams, everything changes.   Self-reflection Question: Is your Product Owner the voice of senior management or the voice of the customer?   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: Making Scrum Master Success Visible with OKRs That Actually Work Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "It is not the retrospective that is the success of the retrospective. It is the ownership and accountability where you take improvements after the session." - Steve Martin   The biggest problem for Scrum Masters isn't just defining success—it's being able to shout it from the rooftops with tangible evidence. Steve champions OKRs as an amazing way to define and measure success, but with a critical caveat: they've historically been poorly written and implemented in dark rooms by executives, then cascaded down to teams who never bought in. Steve's approach is radically different. Create OKRs collectively with the team, stakeholders, and end users. Start by focusing on the pain—what problems or pain points do customers, users, and stakeholders actually experience? Make the objective the goal to solve that problem, then define how to measure progress with key results. When everyone is bought in—Scrum Master, engineers, Product Owner, stakeholders, leaders—all pulling in the same direction, magic happens. Make progress visible on the wall like a speedometer, showing exactly where you are at any moment. For an e-commerce checkout, the problem might be too many steps. The objective: reduce pain for users checking out quickly. The baseline: 15 steps today. The target: 5 clicks in three months. Everyone can see the dial moving. Everything should focus on the customer as the endpoint. The challenge is distinguishing between targets imposed from above ("increase sales by 10%") and objectives created collaboratively based on factors the team can actually control. Find what you can control first, work with customers to understand their pain, and start from there.   Self-reflection Question: Can you articulate your team's success with specific, measurable outcomes that everyone—from developers to executives—understands and owns? Featured Retrospective Format for the Week: Post-Retro Actions and Ownership The success of a retrospective isn't the retrospective itself—it's what happens after. Steve emphasizes that ownership and accountability matter more than the format of the session. Take improvements from the retrospective and bring them into the sprint as user stories with clear structure: this is the problem, how we'll solve it, and how we'll measure impact. Assign collective ownership—not just a single person, but the whole team owns the improvement. Then bring improvements into the demo so the team showcases what changed. This creates cultural transformation: the team themselves want to bring improvements, not just because the Scrum Master pushed them. For ongoing impediments, conduct root cause analysis. Create a system to escalate issues beyond the team's control—make these visible on another board or with the leadership team. Find peers in pain: teams with the same problems can work together collectively. The retrospective format matters less than this system of ownership, action, measurement, and visibility. Stop retrospective theatre—going through the motions without taking action. Make improvements real by treating them like any other work: visible, measured, owned, and demonstrated.   [The Scrum Master Toolbox Podcast Recommends]

Iedere product owner stelt zichzelf vroeg of laat dezelfde vraag: hoe word ik beter in mijn werk? Of je nu junior bent of al jaren ervaring hebt, groei blijft een continu proces. In deze aflevering spreekt Ruud met Stijn Bossink, product owner bij Intergamma (Gamma & Karwei). Hij werkte eerder bij Shimano, Prominent en Timing en deelt openhartig over zijn eigen ontwikkelpad: de fouten die hem verder hielpen, de momenten waarop hij echt groeide en de vaardigheden die hij moest aanleren. Samen onderzoeken Ruud en Stijn wat vakvolwassenheid betekent, hoe je als PO weet waar je staat, hoe je van junior naar ervaren ontwikkelt en wat voor omgeving leidinggevenden moeten creëren om product owners te laten groeien. Een eerlijk gesprek over leren, experimenteren, vallen en opstaan en wat je kunt doen om je ontwikkeling doelgericht te versnellen. In deze aflevering hebben we het over: persoonlijke groei, vakvolwassenheid, leerervaringen, product owner skills, leiderschap & omgeving, doorgroeipad PO Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

Steve Martin: When a Distributed Team's Energy Vanishes into the Virtual Void Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They weren't a team, they were a group of individuals working on multiple different projects." - Vasco Duarte (describing Steve's team situation)   The infrastructure team looked promising on paper: Product Owner in Italy, hardware engineers in Budapest, software engineers in Bucharest, designers in the UK. The team started with energy and enthusiasm, but within a month, something shifted. People stopped showing up for daily stand-ups. Cameras went dark during meetings. Engagement in retrospectives withered. This wasn't just about being distributed—plenty of teams work across time zones successfully. The problem ran deeper. The Scrum Master had a conflict of interest, serving dual roles as both facilitator and engineer. Team members were simultaneously juggling three or four other projects, treating this work as just another item on an impossibly long list. Steve spent a couple of months watching the deterioration before recognizing the root cause: there was no leadership sponsorship or buy-in. Stakeholders weren't invested. The team wasn't actually a team—they were individuals happening to work on the same project. Steve considers this a failure because he couldn't solve it. Sometimes, the absence of organizational support creates an unsolvable puzzle. Without leadership commitment, even the most skilled Scrum Master can't manufacture the conditions for team success.   In this episode, we refer to The Phoenix Project by Gene Kim, a book about organizational culture disguised as a DevOps novel.   Self-reflection Question: Is your team truly dedicated to one mission, or are they a collection of individuals spread across competing priorities? Featured Book of the Week: The Phoenix Project by Gene Kim "There's a lot of good lightning bulb moments that go off." - Steve Martin   Steve describes The Phoenix Project as a book about culture, not just DevOps. Written like a novel following a mock company, it creates continuous light bulb moments for readers. The book resonated deeply with Steve because it exposed patterns he'd experienced firsthand—particularly the anti-pattern of single points of failure. Steve had worked with an engineer who would spend entire weekends doing releases, holding everything in his head, then burning out and taking three days off to recover. This engineer was the bottleneck, the single point of failure that put the entire system at risk. The Phoenix Project illuminates how knowledge hoarding and dependency on individuals creates organizational fragility. The solution isn't just technical—it's cultural. Teams need to share knowledge and understanding, deliberately de-risking the concentration of expertise in one person's mind. Steve recommends this book for anyone trying to understand why organizational transformation requires more than process changes—it demands a fundamental shift in how teams think about knowledge, risk, and collaboration.   [The Scrum Master Toolbox Podcast Recommends]

Steve Martin: When the Gospel of Agile Becomes a Barrier to Change Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "It took me a while to realize that that's what I was doing. I felt the reason wasn't working was them, it wasn't me." - Steve Martin   Steve carried the Scrum Guide like a Bible in his early days as an Agile coach. He was a purist—convinced he had an army of Agile practitioners behind him, ready to transform every team he encountered. When teams questioned his approach, he would shut down the conversation: "Don't challenge me on this, because this is how it's supposed to be." But pushing against the tide and spreading the gospel created something unexpected: resistance. The more Steve insisted on his purist view, the more teams pushed back. It took him a couple of years to recognize the pattern. The problem wasn't the teams refusing to change—it was his approach. Steve's breakthrough came when he started teaching and realized he needed to meet people where they are, not force them to come to him. Like understanding a customer's needs, he learned to build empathy with teams, Product Owners, and leaders. He discovered the power of creating personas for the people he was coaching, understanding their context before prescribing solutions. The hardest part wasn't learning this lesson—it was being honest about his failures and admitting that his righteous certainty had been the real impediment to transformation.   Self-reflection Question: Are you meeting your teams where they are, or are you pushing them toward where you think they should be?   [The Scrum Master Toolbox Podcast Recommends]

In dieser Folge ist Dominique allein am Mikrofon und denkt laut über ein Thema nach, das im Produktalltag oft übersehen wird. Es geht um die Pause und um ihre Wirkung auf Entscheidungen, Zusammenarbeit und Produktentwicklung. Ausgangspunkt ist ein sehr persönlicher Zustand von Erschöpfung und Müdigkeit, der schnell deutlich macht, wie stark fehlende Erholung die eigene Denkfähigkeit beeinflusst. Genau daraus entsteht die Überzeugung, dass die Pause ein unterschätztes Werkzeug in der Produktarbeit ist. Pause bedeutet hier keinen Stillstand. Sie steht für Verarbeitung. Während der Körper scheinbar nichts tut, sortiert das Gehirn Eindrücke, verknüpft Gedanken und schafft Ordnung. Gerade Produktentwicklung ist geprägt von Komplexität, Unsicherheit und einer hohen Dichte an Entscheidungen. Ohne Pause entsteht dann schnell Entscheidungsmüdigkeit und Priorisierungen werden unsauber, strategische Fragen werden aufgeschoben und operative Themen übernehmen die Kontrolle. Die Pause schafft Raum, um innezuhalten und bewusst wahrzunehmen, warum eine Entscheidung so oder anders ausfällt. Und gerade im persönlichen Arbeitsalltag zeigt sich das besonders deutlich. Product Owner:innen und Produktverantwortliche sind häufig ein Engpass, weil viele Entscheidungen an ihnen hängen. Fehlt die Pause, fehlt die Energie für genau diese Entscheidungen. Dabei können kurze Unterbrechungen vor wichtigen Weichenstellungen helfen, den Kopf zu entlasten und die Qualität der Entscheidung zu verbessern. Das können sogar nur wenige Sekunden sein, ein tiefer Atemzug oder ein kurzer Blick aus dem Fenster. Auch bewusst kürzere Meetings oder kleine Lücken zwischen Terminen wirken wie eine Pause, in der Gedanken sacken dürfen. Die Pause wirkt jedoch nicht nur individuell, sondern auch im Team. Produktarbeit lebt von Abstimmung und gemeinsamen Entscheidungen. Pausen im Team helfen dabei, Spannung abzubauen, Konflikte zu entschärfen und sich neu auszurichten. Retrospektiven, No-Meeting-Zeiten oder bewusste "Denkpausen" sind Ausdruck davon. Sie unterbrechen das Dauerfeuer aus Meetings und To Dos und schaffen Raum für Reflexion. Gerade vor Commitments oder nach intensiven Diskussionen hilft eine kurze Pause dabei, bessere gemeinsame Entscheidungen zu treffen. Auch das Produkt selbst profitiert von der Pause. Produktentwicklung besteht aus einem ständigen Wechsel aus Bauen, Lernen und Entscheiden. Lernen braucht Zeit. Feature Pausen, bewusste Phasen ohne neue Umsetzungen oder Zeiten der Konsolidierung helfen dabei, Erkenntnisse zu verarbeiten und den nächsten Schritt klarer zu sehen. Weniger Aktivität kann hier zu mehr Wirkung führen. Auch Nutzerinnen und Nutzer profitieren davon, wenn Produkte nicht permanent verändert werden und Zeit bleibt, Neues zu verstehen und anzunehmen. Am Ende steht die Einladung, Pause bewusster einzusetzen. Als Entscheidungswerkzeug, als Lernfenster und als Mittel gegen Überlastung. Die Frage bleibt offen und richtet sich direkt an den eigenen Alltag. Wo fehlt gerade die Pause im Produktteam, im Produkt oder bei einem selbst und was würde passieren, wenn man ihr mehr Raum gibt. Die Pause wirkt als Hebel gegen Aktivitätswahn. Produktarbeit wird schnell mit Beschäftigung verwechselt. Viele Features, viele Storypoints und volle Kalender fühlen sich produktiv an, führen aber nicht automatisch zu mehr Wert. Die Pause hilft, den Fokus wieder auf Wirkung zu richten und bessere Entscheidungen zu treffen. Sie schützt langfristig den Outcome, auch wenn sie kurzfristig Output kostet. Lasst uns auch die Pause wertschätzen. :)

Product owners worden dagelijks overspoeld met input: bugs, feature requests, vragen via Slack, klantverzoeken en ideeën vanuit de hele organisatie. De kunst is om overzicht te houden, scherp te blijven bepalen wat belangrijk is en duidelijk te communiceren naar stakeholders, zonder kopje-onder te gaan. In deze aflevering spreekt Ruud met Maaike, product owner en specialist in het creëren van structuur in chaos. Ze ontwikkelde een eenvoudige, maar effectieve manier om bugs en feature requests te beoordelen aan de hand van drie vragen. Daardoor ontstaat direct overzicht, betere keuzes en meer rust in het werk. We verkennen hoe product owners grip houden op alles wat er binnenkomt, hoe je slim communiceert over prioriteiten en hoe je voorkomt dat je backlog een reactieve lijst wordt in plaats van een strategisch hulpmiddel. In deze aflevering hebben we het over: backlogmanagement, prioritering, bugtriage, feature requests, stakeholdercommunicatie, overzicht creëren Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

In dieser Podcastfolge widmen sich Dominique und Tim dem Spannungsfeld zwischen Vertrieb und Produktentwicklung. Beide bringen zahlreiche Erfahrungen aus Organisationen mit, in denen diese beiden Bereiche eng zusammenarbeiten müssen und sich dabei dennoch häufig gegenseitig blockieren, missverstehen oder aneinander vorbei arbeiten. Vertrieb und Produktentwicklung verfolgen oft unterschiedliche Ziele und arbeiten in unterschiedlichen Zeithorizonten. Während der Vertrieb stark auf kurzfristige Abschlüsse, Umsatzziele und konkrete Kundenbeziehungen fokussiert ist, denkt die Produktentwicklung i.d.R. langfristiger: in Visionen, Roadmaps und Wiederverwendbarkeit. Diese unterschiedliche Perspektive führt regelmäßig zu Reibung, besonders dann, wenn Zusagen gemacht werden, die nicht zur Produktstrategie passen oder wenn Produktentscheidungen den Vertriebsrealitäten zu wenig Rechnung tragen. Das Spannungsfeld entsteht dabei weniger aus bösem Willen als aus strukturellen und kulturellen Unterschieden innerhalb der Organisation. Der Vertrieb und das Produktteam haben unterschiedlichen Zugang zu Kunden und Nutzenden. Vertrieb ist nah an den Einkaufsorganisationen und ihren Entscheidern, Produktentwicklung ist näher an den tatsächlichen Anwenderinnen und Anwendern. Gerade im B2B Umfeld führt diese Trennung dazu, dass wertvolle Informationen nicht zusammenfließen. Vertrieb hört Marktargumente, Wettbewerbsvergleiche und Kaufhindernisse. Produktentwicklung sieht Nutzungsprobleme, fehlende Wirksamkeit und Schwächen im Erlebnis. Wenn diese Perspektiven getrennt bleiben, entstehen Situationen, in denen sich weder verkaufen lässt, noch nachhaltig und strategisch Produkte entwickelt werden können. Besonders deutlich wird das Spannungsfeld zwischen Vertrieb und Produktentwicklung bei kundenspezifischen Zusagen. Kurzfristige Deals können dazu führen, dass Features versprochen werden, die nicht zur langfristigen Ausrichtung passen. Dadurch entstehen Einzelfalllösungen, die Entwicklungsressourcen binden und selten echten Produktwert erzeugen. Gleichzeitig ist es zu einfach, diese Situation allein dem Vertrieb zuzuschreiben. Verkaufsziele, Incentives und Zeitdruck erzeugen ein Umfeld, in dem solche Entscheidungen logisch erscheinen. Produktentwicklung steht hier vor der Aufgabe, Orientierung zu geben und klar zu machen, wofür das Produkt langfristig stehen soll. Umgekehrt darf die Produktentwicklung nicht erwarten, dass der Vertrieb die Produktstrategie automatisch versteht oder unterstützt. Wenn Vision, Zielgruppen und strategische Leitplanken nicht klar kommuniziert werden, entsteht Raum für Interpretationen. Vertrieb füllt diese Lücke dann mit eigenen Prioritäten. Das Spannungsfeld zwischen Vertrieb und Produktentwicklung verschärft sich dadurch weiter, obwohl beide Seiten eigentlich am gleichen Erfolg interessiert sind bzw. sein sollten. Und gerade in dieser Zusammenarbeit steckt enormes Potenzial (oder wird eben verschenkt). Der Vertrieb liefert wertvolle Einblicke in Marktveränderungen, Wettbewerber und Kaufmotive. Die Produktentwicklung kann diese Impulse nutzen, um bessere Entscheidungen zu treffen und Risiken frühzeitig zu erkennen. Wenn der Vertrieb regelmäßig Einblick in Produktentwicklungen bekommt, neue Funktionen versteht und deren Nutzen einordnen kann, steigt die Qualität der Gespräche mit Kunden deutlich. Beide Seiten gewinnen an Sicherheit und Wirksamkeit. Voraussetzung dafür ist eine bewusste Gestaltung der Zusammenarbeit. Regelmäßiger Austausch, gemeinsame Termine und echte Beziehungspflege schaffen Vertrauen. Es geht darum, die Perspektive des jeweils anderen zu verstehen und ernst zu nehmen. Produktentwicklung profitiert davon, Verkaufsrealitäten kennenzulernen. Vertrieb profitiert davon, die Komplexität von Produktentscheidungen zu verstehen. Diese Nähe reduziert Missverständnisse und verhindert Eskalationen, bevor sie entstehen. ... mehr dazu dann in der kompletten Folge - hört mal rein!

Natalia Curusi: From Spreadsheets to Discovery—Helping POs Make the Transition The Great Product Owner: Taking Ownership and Coaching the Team Forward Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "That person was not just a great product owner, but a great coach—he had excellent communication and stakeholder management skills, and he coached myself as a Scrum Master, showing me how product ownership should look like." - Natalia Curusi   Natalia worked with a Product Owner who embodied everything the role should be. He didn't come from a technical background, but he possessed exceptional domain knowledge, outstanding communication skills, and stakeholder management expertise you rarely find in one person. What made him truly remarkable was that he coached everyone around him, including Natalia as the Scrum Master.  He demonstrated full empowerment and ownership—making decisions himself rather than constantly escalating to higher management. When risks needed to be taken, he took them with courage and conviction. The team trusted him completely because he balanced business needs with team capacity, always understanding what they could realistically achieve. Over the past five years, this person has been promoted multiple times and now serves as a global director of product, still with the same company.  When Natalia thinks about what great product ownership looks like, she thinks of him—someone who combined technical understanding with coaching ability, took genuine ownership of outcomes, and empowered the team through clear vision and decisive leadership. These are exactly the skills that are hardest to find in the market, yet when you find them, the impact is transformative for the entire organization.   Self-reflection Question: Does your Product Owner take ownership and make decisions, or do they constantly escalate to higher management, preventing the team from moving forward with confidence? The Bad Product Owner: Assigned Without Training, Support, or Willingness "She was a great subject matter expert with deep domain knowledge, but the organization assigned her the product owner role without her willingness, without training, and while she was already 80% loaded with other responsibilities." - Natalia Curusi   Natalia encountered a Product Owner anti-pattern that reveals a systemic organizational failure. The person was an exceptional subject matter expert with incredible domain knowledge, but when the organization decided to adopt Agile, they assigned her the PO role like sticking a label on a box—no training, no consent, no preparation. She was already working at 80% capacity on other responsibilities and had no understanding of what product ownership meant. Frustrated and overwhelmed, she approached the role from a command-and-control mindset. At the project start, she brought a massive spreadsheet of requirements, expecting the team to implement them sequentially.  The team tried a different approach, wanting to understand problems before discussing solutions, but the PO surprised everyone by re-introducing the spreadsheet in a later meeting—a clear sign of misalignment and broken trust. Natalia, recognizing this was a battle she couldn't win without organizational support, chose to manage the relationship rather than create open conflict. She worked to mediate between the PO's spreadsheet approach and the team's need for discovery and iterative development. The real anti-pattern wasn't the individual—it was the organization assigning critical roles without providing training, time, or psychological safety. This situation illustrates why product ownership fails: not from bad people, but from bad systems that set people up to fail.   Self-reflection Question: When you see a struggling Product Owner, are you addressing the individual's behavior or the systemic conditions that set them up to fail in the first place?   [The Scrum Master Toolbox Podcast Recommends]

In deze aflevering onderzoekt Ruud hoe agile werken waarde kan creëren in een sector waar innovatie traditioneel langzaam verloopt: de bloemenhandel. Hij spreekt met Mark Schermer, Global Head of Flowers bij Syngenta, over wat er gebeurt wanneer je een klassieke industrie laat werken met korte iteraties, experimenteren en “fall fast, learn fast”. Mark legt uit hoe agile principes hun weg vonden naar de veredeling van bloemen: een proces dat normaal jaren duurt. Hij deelt de eerste resultaten, de uitdagingen en vooral de voordelen: sneller inzicht, minder verspilling en teams die beter leren samenwerken en beslissen. Een inspirerende aflevering voor iedereen die benieuwd is hoe agile werken buiten de IT echte verandering kan brengen. In deze aflevering hebben we het over: agile werken, scrum mindset, innovatie in traditionele sectoren, bloemenveredeling, experimenteren, fall fast learn fast, iteraties, veranderprocessen, teamontwikkeling, Syngenta Flowers Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

In this episode of the Scrum.org Community Podcast, host Dave West sits down with authors Sander Dur and Ryan Brook to explore their new book, The Anatomy of a Product—a practical field guide that uses the human body as a metaphor to demystify modern product management.Dave, Sander, and Ryan dive into why so many organizations still struggle to define and manage products effectively, and how this book helps bridge the gap between theory and real-world practice. They discuss treating products as living systems, the dangers of “marshmallow backlogs,” the need for evidence-driven decisions, and why continuous care and adaptation are essential for healthy products.The authors share insights from working with organizations like Miro, unpack common “product diseases,” and offer actionable guidance for Product Owners, product teams, and leaders seeking clarity in today's complex environment.Listeners are invited to connect with the authors and join them at their book launch event in Amsterdam on January 13!Key Points Why the Book?Clarifies what a product is and offers a practical guide from definition to retirement.Human Body MetaphorProducts are like living systems—interconnected, adaptive, and influenced by their environment.Theory vs. PracticeHelps teams apply product concepts realistically, beyond Silicon Valley-style theory.Insights from real examplesReal-world examples showing how to balance strategy, business thinking, and everyday product work.Backlog HealthAvoid “marshmallow backlogs” by filtering work through strategic goals and focusing on value.Validation & EvidenceEmphasizes validating ideas early and aligning efforts to outcomes, not just requirements.Product HealthIntroduces “product diseases” and how to diagnose and prevent common issues.Links:Book Launch eventThe Anatomy of a Product

Iedere product owner kent het moment: iemand komt met een goed idee, een wens van een stakeholder, of een kleine aanpassing “die toch even tussendoor moet”. En ergens weet je: dit gaat niet passen. Nee zeggen is dan lastig, maar misschien wel de belangrijkste vaardigheid die je als product owner kunt ontwikkelen. In deze aflevering praat Ruud met Anouk, ervaren product owner bij onder andere CTRL Chain, Boerschappen en Mosadex eHealth. Ze deelt hoe zij leerde om op een constructieve manier nee te zeggen, waarom dat juist vertrouwen oplevert, en hoe je dat morgen zelf kunt toepassen. Een aflevering over grenzen stellen, focus houden en leiderschap tonen als product owner. In deze aflevering hebben we het over: nee zeggen, grenzen stellen, stakeholder management, prioriteiten, vertrouwen, focus, product owner skills Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

Une conférence des RDV Transformations du Droit 2025 > https://www.transformations-droit.com:D'anciens juristes, devenus "Legalops" ou Product owners" pour le compte de directions juridiques, présentent leur fonction.Pourquoi ont-ils changé de métier ?Comment passer de juriste à chef de projet IT/ Legal ops/Product owner ?Quelle est la valeur ajoutée de ce profil par rapport à un chef de projet non juriste ?Quel est l'impact de la création de ce métier pour une direction juridique ?Qu'ont-ils appris en tant que Legal ops/product owner ?Venez découvrir ces fonctions devenues incontournables en phase d'innovation juridique, et peut-être initier un réseau avec eux.Intervenants :- Emmanuel Bret, Business Product Leader, chez Adeo services,- Arthur Debono, Digital Product Manager - Legal Operations, chez Decathlon,- Meije Bouquet - Avocate (9B Avocat), legal ops et product owner chez Dylogy.Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.

Viele Menschen starten motiviert in ihrer Rolle und stellen dann fest, dass ihnen Entscheidungen entzogen werden oder dass bestimmte Aufgaben weiterhin von anderen übernommen werden. Der Frust wächst, weil der Wunsch nach Verantwortung da ist, aber die Strukturen nicht mitziehen. Genau daran knüpft das Gespräch in dieser Folge an und zeigt Wege, wie mehr Ownership nicht nur gefordert, sondern im Alltag schrittweise aufgebaut wird. Direkt zu Beginn wird klar, dass ein wichtiger Aspekt für mehr Ownership fachliche Tiefe ist. Menschen, die die Kund:innen, den Markt, das eigene Produkt und relevante Wettbewerbsangebote sehr gut verstehen, entwickeln ein anderes Standing. Sie können Diskussionen auf eine faktische Ebene bringen und wegführen vom Raum der reinen Meinungen. Das öffnet Türen, weil Entscheidungen nachvollziehbarer werden und Stakeholder:innen merken, dass jemand nicht nur koordinieren möchte, sondern echte Produktverantwortung übernimmt. Fachliche Klarheit wirkt auf die Organisation, auch wenn sie anfangs kaum Freiraum bietet. Damit verbunden ist aber auch der Umgang mit Unsicherheit. Jede Produktentscheidung bleibt eine Wette. Wer diese Wette sauber beschreibt, ihre Risiken benennt und darauf achtet, auf welcher Datengrundlage entschieden wird, tritt automatisch verantwortlicher auf. Das Gespräch zeigt gut, wie stark sich die Wirkung eines Product Owners verändert, sobald Entscheidungen nicht mehr als absolute Wahrheiten präsentiert werden, sondern als reflektierte Schritte mit nachvollziehbarer Logik. Viele Stakeholder:innen reagieren positiv darauf, weil sie erkennen, dass Entscheidungen begleitet werden und nicht blind getroffen werden. Das zeigt, dass Kommunikation eine wichtige Rolle spielt. Klare Sprache erzeugt Klarheit über Risiken, Annahmen und Wissenslücken. Sie macht sichtbar, welche Informationen fehlen und wo die Organisation Prioritäten setzen sollte. Es steckt viel Ownership darin, offen zu sagen, welche Informationen fehlen, welche Wahrscheinlichkeiten realistisch sind und welche Konsequenzen bestimmte Wege haben. Gute Kommunikation heißt in diesem Kontext nicht, Konflikte zu vermeiden, sondern Orientierung zu schaffen. Aber am Ende geht es um die eigene Haltung. Ownership entsteht nicht dadurch, dass jemand sie verleiht. Sie wächst durch konsequentes Handeln. Dazu gehört, aktiv Informationen zu suchen, Discovery voranzutreiben, Entscheidungen einzufordern und Transparenz darüber herzustellen, was möglich ist und wo Grenzen liegen. Wer sein Umfeld so begleitet, verändert Schritt für Schritt die Wahrnehmung der eigenen Rolle und schafft die Grundlage für echte Product Ownership, selbst wenn die Organisation noch im alten Denken steckt.

Scott Smith: Empathy and Availability Define Excellent Product Ownership Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Always Present, Always Available, Always Curious "They are always present. They always make themselves available for team members that need them." - Scott Smith   Scott is currently working with a Product Owner who exemplifies what great PO collaboration looks like. This person is always present—not just physically but mentally engaged with the team's work and challenges. They make themselves available for team members who need them, responding actively on the team chat and interacting consistently.  What makes this PO stand out is their empathy and curiosity. Instead of being defensive when questions arise or challenges emerge, they lean into helping the team understand and solve problems. They show genuine curiosity about what the team is experiencing, asking questions and exploring solutions together rather than dictating answers.  This PO understands that their role isn't to be the smartest person in the room but to be the most available, most collaborative, and most curious. The result is a team that feels supported and empowered, with clear direction and someone who genuinely helps them answer the hard questions. Scott's experience with this PO demonstrates that presence, availability, empathy, and curiosity are the foundations of great Product Owner work.   Self-reflection Question: How present and available are you to your team, and do you approach their questions with curiosity or defensiveness? The Bad Product Owner: Never There When the Team Needs Direction "The PO was never present. The team had lack of clarity, and vision, and had no direction or someone who would help answer those questions." - Scott Smith   Scott has also experienced the opposite extreme—a Product Owner who was never present. This absence created a cascade of problems for the team. Without regular access to the PO, the team lacked clarity about priorities, vision, and direction. They had questions that went unanswered and decisions that couldn't be made.  The result was frustration and a team that couldn't move forward effectively. An absent PO creates a vacuum where uncertainty thrives. Teams end up making assumptions, second-guessing decisions, and feeling disconnected from the purpose of their work.  The lack of someone who can help answer strategic questions or provide guidance means the team operates in the dark, building things without confidence that they're building the right things. Scott's experience highlights a fundamental truth about Product Ownership: presence isn't optional.  Teams need a PO who shows up, engages, and stays connected to the work. Without that presence, even the most skilled team will struggle to deliver value because they can't align their efforts with the product vision and customer needs.   Self-reflection Question: If your team were asked whether you're present and available as a Product Owner or Scrum Master, what would they say?   [The Scrum Master Toolbox Podcast Recommends]

Scott Smith: Using MIRO to Build a Living Archive of Learning Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We're in a servant leadership role. So, ask: is the team thriving? That's a huge indication of success." - Scott Smith   For Scott, success as a Scrum Master isn't measured by velocity charts or burn-down graphs—it's measured by whether the people are thriving. This includes everyone: the development team and the Product Owner.  As a servant leader, Scott's focus is on creating conditions where teams can flourish, and he has practical ways to gauge that health. Scott does a light touch check on a regular basis and a deeper assessment quarterly. Mid-sprint, he conducts what he calls a "vibe" check—a quick pulse to understand how people are feeling and what they need. During quarterly planning, the team retrospects and celebrates achievements from the past quarter, keeping and tracking actions to ensure continuous improvement isn't just talked about but lived. Scott's approach recognizes that success is both about the work being done and the people doing it. When teams feel supported, heard, and valued, the work naturally flows better. This people-first perspective defines what great servant leadership looks like in practice.   Self-reflection Question: How often do you check in on whether your team is truly thriving, and what specific indicators tell you they are? Featured Retrospective Format for the Week: MIRO as a Living History Museum "Use the multiple retros in the MIRO board as a shared history museum for the team." - Scott Smith   Scott leverages MIRO not just as a tool for running retrospectives but as a living archive of team learning and growth. He uses MIROVERSE templates to bring diversity to retrospective conversations, exploring the vast library of pre-built formats that offer themed and structured approaches to reflection. The magic happens when Scott treats each retrospective board not as a disposable artifact but as part of the team's shared history museum.  Over time, the accumulation of retrospective boards tells the story of the team's journey—what they struggled with, what they celebrated, what actions they took, and how they evolved. This approach transforms retrospectives from isolated events into a continuous narrative of improvement. Teams can look back at previous retros to see patterns, track whether actions were completed, and recognize how far they've come. MIRO becomes both the canvas for current reflection and the archive of collective learning, making improvement visible and tangible across time.   [The Scrum Master Toolbox Podcast Recommends]

Het is zover: 2026 staat voor de deur. Tijd om jouw nieuwe roadmap vorm te geven. Maar hoe bepaal je wat écht impact heeft? Hoe vind je de balans tussen nieuwe features, verbeteringen en het wegwerken van technical debt? In deze aflevering praat Ruud met Dennis van Leukeleu over hoe je de juiste keuzes maakt, impact meet en technical debt slim meeneemt in je planning. Handvaten, frameworks en praktijkvoorbeelden waarmee jij als product owner met vertrouwen jouw roadmap voor 2026 opstelt. In deze aflevering hebben we het over: roadmap 2026, product strategy, impact meten, technical debt, feature planning, stakeholder alignment, product owner tips Over deze podcast: In de Product Owner podcast spreken we elke week met een interessante gast uit de wereld van product management en gaan we in op echte ervaringen, lessen en tactieken van product owners, ondernemers en specialisten. De Product Owner podcast is een initiatief van Productowner.nl

Scott Smith: Why Great Scrum Masters Create Space for Breaks Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "Think of the people involved. Put yourself in the shoes of the other." - Scott Smith   Scott found himself in the middle of rising tension as voices escalated between the Product Owner and the development team. The PO was harsh, emotions were running high, and the conflict was intensifying with each exchange. In that moment, Scott knew he had to act.  He stepped in with a simple but powerful reminder: "We're on the same team." That pause—that momentary break—allowed everyone to step back and reset. Both the PO and the team members later thanked Scott for his intervention, acknowledging they needed that space to cool down and refocus on their shared outcome.  Scott's approach centers on empathy and perspective-taking. He emphasizes thinking about the people involved and putting yourself in their shoes. When tensions rise, sometimes the most valuable contribution a Scrum Master can make is creating space for a break, reminding everyone of the shared goal, and helping teams focus on the outcome rather than the conflict. It's not about taking sides—it's about serving the team by being the calm presence that brings everyone back to what matters most.   Self-reflection Question: When you witness conflict between team members or between the team and Product Owner, do you tend to jump in immediately or create space for the parties to find common ground themselves? Featured Book of the Week: An Ex-Manager Who Believed "It was about having someone who believed in me." - Scott Smith   Scott's most influential "book" isn't printed on pages—it's a person. After spending 10 years as a Business Analyst, Scott decided to take the Professional Scrum Master I (PSM I) course and look for a Scrum Master position. That transition wasn't just about skills or certification; it was about having an ex-manager who inspired him to chase his goals and truly believed in him. This person gave Scott the confidence to make a significant career pivot, demonstrating that sometimes the most powerful catalyst for growth is someone who sees your potential before you fully recognize it yourself. Scott's story reminds us that great leadership isn't just about managing tasks—it's about inspiring people to reach for goals they might not have pursued alone. The belief and encouragement of a single person can change the trajectory of someone's entire career.   [The Scrum Master Toolbox Podcast Recommends]

Thanks to Prosus Group for collaborating on the Agents in Production Virtual Conference 2025.Abstract //The discussion centers on highly technical yet practical themes, such as the use of advanced post-training techniques like Direct Preference Optimization (DPO) and Parameter-Efficient Fine-Tuning (PEFT) to ensure LLMs maintain stability while specializing for e-commerce domains. We compare the implementation challenges of Computer-Using Agents in automating legacy enterprise systems versus the stability issues faced by conversational agents when inputs become unpredictable in production. We will analyze the role of cloud infrastructure in supporting the continuous, iterative training loops required by Reinforcement Learning-based agents for e-commerce!Bio // Paul van der Boor (Panel Host) //Paul van der Boor is a Senior Director of Data Science at Prosus and a member of its internal AI group.Arushi Jain (Panelist) // Arushi is a Senior Applied Scientist at Microsoft, working on LLM post-training for Computer-Using Agent (CUA) through Reinforcement Learning. She previously completed Microsoft's competitive 2-year AI Rotational Program (MAIDAP), building and shipping AI-powered features across four product teams.She holds a Master's in Machine Learning from the University of Michigan, Ann Arbor, and a Dual Degree in Economics from IIT Kanpur. At Michigan, she led the NLG efforts for the Alexa Prize Team, securing a $250K research grant to develop a personalized, active-listening socialbot. Her research spans collaborations with Rutgers School of Information, Virginia Tech's Economics Department, and UCLA's Center for Digital Behavior.Beyond her technical work, Arushi is a passionate advocate for gender equity in AI. She leads the Women in Data Science (WiDS) Cambridge community, scaling participation in her ML workshops from 25 women in 2020 to 100+ in 2025—empowering women and non-binary technologists through education and mentorship.Swati Bhatia //Passionate about building and investing in cutting-edge technology to drive positive impact.Currently shaping the future of AI/ML at Google Cloud.10+ years of global experience across the U.S, EMEA, and India in product, strategy & venture capital (Google, Uber, BCG, Morpheus Ventures).Audi Liu //I'm passionate about making AI more useful and safe.Why? Because AI will be ubiquitous in every workflow, powering our lives just like how electricity revolutionized our society - It's pivotal we get it right.At Inworld AI, we believe all future software will be powered by voice. As a Sr Product Manager at Inworld, I'm focused on building a real-time voice API that empowers developers to create engaging, human-like experiences. Inworld offers state-of-the-art voice AI at a radically accessible price - No. 1 on Hugging Face and Artificial Analysis, instant voice cloning, rich multilingual support, real-time streaming, and emotion plus non-verbal control, all for just $5 per million characters.Isabella Piratininga //Experienced Product Leader with over 10 years in the tech industry, shaping impactful solutions across micro-mobility, e-commerce, and leading organizations in the new economy, such as OLX, iFood, and now Nubank. I began my journey as a Product Owner during the early days of modern product management, contributing to pivotal moments like scaling startups, mergers of major tech companies, and driving innovation in digital banking.My passion lies in solving complex challenges through user-centered product strategies. I believe in creating products that serve as a bridge between user needs and business goals, fostering value and driving growth. At Nubank, I focus on redefining financial experiences and empowering users with accessible and innovative solutions.

What is value and how does that inform what we are actually working on? A product owner can't maximize the value of the product without first defining what is valuable.Let's dive in!Today's session is great for agile leadership, Product Owner, Product Management and anyone really in the organization helping to move the needle!Don't forget to sign up for the 2 day virtual CSPO Certification course with me scheduled for December 18-19, 2025 and use the promo code PLANETPO for 20% off!https://www.scrumalliance.org/courses-events/search/coursedetail?id=202512214Audio has been good to me and this community, but I'm launching more formats and opportunities to help you grow in 2026!Coming Soon: www.planetproductowner.org will be your one stop shop for the podcast, events, downloads and more! 2026 will be a great launch with the community!

Sara Di Gregorio: Coaching Product Owners from Isolation to Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Using User Story Mapping to Break Down PO Isolation "One of the key strengths is the ability to build a strong collaborative relationship with the Scrum team. We constantly exchange feedback, with the shared goal of improving both our collaborating and the way of working." - Sara Di Gregorio   Sara considers herself fortunate—she currently works with Product Owners who exemplify what great collaboration looks like. One of their key strengths is the ability to build strong collaborative relationships with the Scrum team. They don't wait for sprint reviews to exchange feedback; instead, they constantly communicate with the shared goal of improving both collaboration and ways of working.  These Product Owners involve the team early, using techniques like user story mapping after analysis phases to create open discussions around upcoming topics and help the team understand potential dependencies. They make themselves truly available—they observe daily stand-ups not as passive attendees but as engaged contributors. If the team needs five minutes to discuss something afterward, the Product Owner is ready. They attend Scrum events with genuine interest in working with the team, not just fulfilling an attendance requirement. They encourage open dialogue, even participating in retrospectives to understand how the team is working and where they can improve collaboration. What sets these Product Owners apart is their communication approach. They don't come in thinking they know everything or that they need to do everything alone. Their mindset is collaborative: "We're doing this together." They recognize that developers aren't just executors—they're users of the product, experts who can provide valuable perspectives.  When Product Owners ask "Why do you want this?" and developers respond with "If we do it this way, we can be faster, and you can try your product sooner," that's when magic happens. Great Product Owners understand that strong communication skills and collaborative relationships create better products, better teams, and better outcomes for everyone involved.   Self-reflection Question: How are your Product Owners involving the team early in discovery and analysis, and are they building collaborative relationships or just attending required events? The Bad Product Owner: The Isolated Expert Who Thinks Teams Just Execute   "Sometimes they feel very comfortable in their subject, so they assume they know everything, and the team has only to execute what they asked for." - Sara Di Gregorio   Sara has encountered Product Owners who embody the worst anti-pattern: they believe they don't need to interact with the development team because they're confident in their subject matter expertise. They assume they know everything, and the team's job is simply to execute what they ask for. These Product Owners work isolated from the development team, writing detailed user stories alone and skipping the interesting discussions with developers. They only involve the team when they think it's necessary, treating developers as order-takers rather than collaborators who could contribute valuable insights.  The impact is significant—teams lose the opportunity to understand the "why" behind features, Product Owners miss perspectives that could improve the product, and collaboration becomes transactional instead of transformational. Sara's approach to addressing this anti-pattern is patient but deliberate. She creates space for dialogue and provides training with the Product Owner to help them understand how important it is to collaborate and cooperate with the team. She shows them the impact of including the team from the beginning of feature study.  One powerful technique she uses is user story mapping workshops, bringing both the team and Product Owner together. The Product Owner explains what they want to deliver from their point of view, but then something crucial happens: the team asks lots of questions to understand "Why do you want this?"—not just "I will do it."  Through this exercise, Sara watched Product Owners have profound realizations. They understood they could change their mindset by talking with developers, who often are users of the product and can offer perspectives like "If we do it this way, we can be faster, and you can try your product sooner."  The workshop helps teams understand the big picture of what the Product Owner is asking for while helping the Product Owner reflect on what they're actually asking. It transforms the relationship from isolation to collaboration, from directive to dialogue, from assumption to shared understanding.   In this segment, we refer to the User Story Mapping blog post by Jeff Patton.   Self-reflection Question: Are your Product Owners writing user stories in isolation, or are they involving the team in discovery to create shared understanding and better solutions?   [The Scrum Master Toolbox Podcast Recommends]

Alidad Hamidi: When Product Owners Facilitate Vision Instead of Owning It Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Co-Creating Vision Through Discovery "The best product owner I worked with was not a product owner, but a project manager. And she didn't realize that she's acting as a product owner." - Alidad Hamidi   The irony wasn't lost on Alidad. The best Product Owner he ever worked with didn't have "Product Owner" in her title—she was a project manager who didn't even realize she was acting in that capacity. The team was working on a strategic project worth millions, but confusion reigned about what value they were creating. Alidad planned an inception workshop to create alignment among stakeholders, marketing, operations, advisors, and the team.   Twenty minutes into the session, Alidad asked a simple question: "How do we know the customer has this problem, and they're gonna pay for it?" Silence. No one knew. To her immense credit, the project manager didn't retreat or deflect. Instead, she jumped in: "What do we need to do?" Alidad suggested assumptions mapping, and two days later, the entire team and stakeholders gathered for the workshop. What happened next was magic. "She didn't become a proxy," Alidad emphasizes. She didn't say, "I'll go find out and come back to you." Instead, she brought everyone together—team, stakeholders, and customers—into the same room.   The results were dramatic. The team was about to invest millions integrating with an external vendor. Through the assumption mapping workshop, they uncovered huge risks and realized customers didn't actually want that solution. "We need to pivot," she declared. Instead of the expensive integration, they developed educational modules and scripts for customer support and advisors. The team sat with advisors, listening to actual customer calls, creating solutions based on real needs rather than assumptions. The insight transformed not just the project but the project manager herself. She took these discovery practices across the entire organization, teaching everyone how to conduct proper discovery and fundamentally shifting the product development paradigm. One person, willing to facilitate rather than dictate, made this impact. "Product owner can facilitate creation of that [vision]," Alidad explains. "It's not just product owner or a team. It's the broader stakeholder and customer community that need to co-create that."   Self-reflection Question: Are you facilitating the creation of vision with your stakeholders and customers, or are you becoming a proxy between the team and the real sources of insight? The Bad Product Owner: Creating Barriers Instead of Connections "He did the opposite, just creating barriers between the team and the environment." - Alidad Hamidi   The Product Owner was new to the organization, technically skilled, and genuinely well-intentioned. The team was developing solutions for clinicians—complex healthcare work requiring deep domain understanding. Being new, the PO naturally leaned into his strength: technical expertise. He spent enormous amounts of time with the team, drilling into details, specifying exactly how everything should look, and giving the team ready-made solutions instead of problems to solve.   Alidad kept telling him: "Mate, you need to spend more time with our stakeholder, you need to understand their perspective." But the PO didn't engage with users or stakeholders. He stayed comfortable in his technical wheelhouse, designing solutions in isolation. The results were predictable and painful. Halfway through work, the PO would realize, "Oh, we really don't need that." Or worse, the team would complete something and deliver it to crickets—no one used it because no one wanted it. "Great person, but it created a really bad dynamic," Alidad reflects. What should have been the PO's job—understanding the environment, stakeholder needs, and market trends—never happened. Instead of putting people in front of the environment to learn and adapt, he created barriers between the team and reality.   Years later, Alidad's perspective has matured. He initially resented this PO but came to realize: "He was just being human, and he didn't have the right support and the environment for him." Sometimes people learn only after making mistakes. The coaching opportunity isn't to shame or blame but to focus on reflection from failures and supporting learning. Alidad encouraged forums with stakeholders where the PO and team could interact directly, seeing each other's work and constraints. The goal isn't perfection—it's creating conditions where Product Owners can connect teams to customers rather than standing between them.   Self-reflection Question: What barriers might you be unintentionally creating between your team and the customers or stakeholders they need to serve, and what would it take to remove yourself from the middle?   [The Scrum Master Toolbox Podcast Recommends]

Karim Harbott: From Requirements Documents to Customer Obsession—Redefining the PO Role Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Strategic, Customer-Obsessed, and Vision-Driven   "The PO role in the team is strategic. These POs focus on the customer, outcomes, and strategy. They're customer-obsessed and focus on the purpose and the why of the product." - Karim Harbott   Karim believes the industry fundamentally misunderstands what a Product Owner should be. The great Product Owners he's seen are strategic thinkers who are obsessed with the customer. They don't just manage a backlog—they paint a vision for the product and help the entire team become customer-obsessed alongside them.  These POs focus relentlessly on outcomes rather than outputs, asking "why are we building this?" before diving into "what should we build?" They understand the purpose of the product and communicate it compellingly.  Karim references Amazon's "working backwards" approach, where Product Owners start with the customer experience they want to create and work backwards to figure out what needs to be built. Great POs also embrace the framework of Desirability (what customers want), Viability (what makes business sense), Feasibility (what's technically possible), and Usability (what's easy to use). While the PO owns desirability and viability, they collaborate closely with designers on usability and technical teams on feasibility.  This is critical: software is a team sport, and great POs recognize that multiple roles share responsibility for delivery. Like David Marquet teaches, they empower the team to own decisions rather than dictating every detail. The result? Teams that understand the "why" and can innovate toward it autonomously.   Self-reflection Question: Does your Product Owner paint a compelling vision that inspires the team, or do they primarily manage a list of tasks? The Bad Product Owner: The User Story Writer "The user story writer PO thinks it's their job to write full, long requirements documents, put it in JIRA, and assign it to the team. This is far away from what the PO role should be." - Karim Harbott   The anti-pattern Karim sees most often is the "User Story Writer" Product Owner. These POs believe their job is to write detailed requirements documents, load them into JIRA, and assign them to the team. It's essentially waterfall disguised as Agile—treating user stories like mini-specifications rather than conversation starters. This approach completely misses the collaborative nature of product development.  Instead of engaging the team in understanding customer needs and co-creating solutions, these POs hand down fully-formed requirements and expect the team to execute without question. The problem is that this removes the team's ownership and creativity. When POs act as the sole source of product knowledge, they become bottlenecks.  The team can't make smart tradeoffs or innovate because they don't understand the underlying customer problems or business context. Using the Desirability-Viability-Feasibility-Usability framework, bad POs try to own all four dimensions themselves instead of recognizing that designers, developers, and other roles bring essential perspectives. The result is disengaged teams, slow delivery, and products that miss the mark because they were built to specifications rather than shaped by collaborative discovery. Software is a team sport—but the User Story Writer PO forgets to put the team on the field.   Self-reflection Question: Is your Product Owner engaging the team in collaborative discovery, or just handing down requirements to be implemented?   [The Scrum Master Toolbox Podcast Recommends]

Darryl Wright: The PONO—Product Owners in Name Only and How They Destroy Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Collaborative, Present, and Clear in Vision   "She was collaborative, and that meant that she was present—the opposite of the MIA product owner. She came, and she sat with the team, and she worked with them side by side. Even when she was working on something different, she'd be there, she'd be available." - Darryl Wright   Darryl shares an unusual story about one of the best Product Owners he's ever encountered—someone who had never even heard of Agile before taking the role. Working for a large consulting company with 170,000 staff worldwide, they faced a difficult project that nobody wanted to do. Darryl suggested running it as an Agile project, but the entire team had zero Agile experience. The only person who'd heard of Agile was a new graduate who'd studied it for one week at university—he became the Scrum Master. The executive sponsor, with her business acumen and stakeholder management skills, became the Product Owner despite having no idea what that meant.  The results were extraordinary: an 18-month project completed in just over 7 months, and when asked about the experience, the team's highest feedback was how much fun they had working on what was supposed to be an awful, difficult project. Darryl attributes this success to mindset—the team was open and willing to try something new.  The Product Owner brought critical skills to the role even without technical Agile knowledge: She was collaborative and present, sitting with the team and remaining available. She was decisive, making prioritization calls clearly so nobody was ever confused about priorities. She had excellent communication skills, articulating the vision with clarity that inspired the team. Her stakeholder management capabilities kept external pressures managed appropriately. And her business acumen meant she instantly understood conversations about value, time to market, and customer impact.  Without formal training, she became an amazing Product Owner simply by being open, willing, and committed. As Darryl reflects, going from never having heard of the role to being an inspiring Product Owner in 7 months was incredible—one of the most successful projects and teams he's ever worked with.   Self-reflection Question: If you had to choose between a Product Owner with deep Agile certification and no business skills, or one with strong business acumen and willingness to learn—which would serve your team better? The Bad Product Owner: The PONO—Product Owner in Name Only   "The team never saw the PO until the showcase. And so, the team would come along with work that they deemed was finished, and the product owner had not seen it before because he wasn't around. So he would be seeing it for the first time in the showcase, and he would then accept or reject the work in the showcase, in front of other stakeholders." - Darryl Wright   The most destructive anti-pattern Darryl has witnessed was the MIA—Missing in Action—Product Owner, someone who was a Product Owner in Name Only (PONO). This senior business person was too busy to spend time with the team, only appearing at the sprint showcase. The damage this created was systematic and crushing. The team would build work without Product Owner engagement, then present it in the showcase looking to be proud of their accomplishment.  The PO, seeing it for the first time, would accept or reject the work in front of stakeholders. When he rejected it, the team was crushed, deflated, demoralized, and made to look like fools in front of senior leaders—essentially thrown under the bus. This pattern violates multiple principles of Agile teamwork. First, there's no feedback loop during the sprint, so the team works blind, hoping they're building the right thing. Second, the showcase becomes a validation ceremony rather than a collaborative feedback session, creating a dynamic of subservience rather than curiosity. The team seeks approval instead of engaging as explorers discovering what delivers customer value together. Third, the PO positions themselves as judge rather than coach—extracting themselves from responsibility for what's delivered while placing all blame on the team.  As Deming's quote reminds us, "A leader is a coach, not a judge." When the PO takes the judge role, they're betraying fundamental Agile values.  The responsibility for what the team delivers belongs strictly to the Product Owner; the team owns how it's delivered.  When Darryl encounters this situation as a Scrum Master, he lobbies intensely with the PO: "Even if you can't spare any other time for the entire sprint, give us just one hour the night before the showcase." That single hour lets the team preview what they'll present, getting early yes/no decisions so they never face public rejection. The basic building block of any Agile or Scrum way of working is an empowered team—and this anti-pattern strips all empowerment away.   Self-reflection Question: Does your Product Owner show up as a coach who's building something together with the team, or as a judge who pronounces verdicts? How does that dynamic shape what your team is willing to try?   [The Scrum Master Toolbox Podcast Recommends]

We're excited to feature another visionary builder in product management: Tim Herbig, Product Coach and author of the newly released book “Real Progress: How to Connect the Dots of Product Strategy, OKRs and Discovery”.In this episode, Tim joins Matt and Moshe to share how his journey, from being handed a Product Owner role out of the blue, to leading teams and coaching organizations, shaped his mission to help product managers connect strategy, OKRs, and discovery into a framework for real impact.Tim draws on his years of experience across diverse industries and organizations to address a challenge he's seen again and again: teams invite him to solve one issue but quickly discover there are deeper, often interlinked problems between strategic planning, measuring progress, and enabling effective discovery. That's the gap he set out to fill with his book, a hands-on resource designed specifically for PMs and teams looking to go beyond process and frameworks, and start making progress that matters.Join Matt and Moshe as they explore with Tim:The story behind writing “Real Progress” and connecting the dots between strategy, OKRs, and discoveryWhy so many teams appear busy but are stuck making “alibi progress” instead of real impactThe Progress Wheel: a visual tool for mapping how strategic, measurable change drives product successHow to think critically about frameworks, challenging readers to adapt tools for their own context, rather than following them blindlyThe book's practical structure: workbook-like prompts and non-linear sections for self-assessment and targeted improvementKey building blocks of strategy and how they relate to various templates and organizational maturityLinking company strategy to product strategy, and the strategic thinking required for product leadersUsing OKRs to measure if your strategy is working, and spotting when OKRs reveal deeper strategic problemsRole of discovery in reducing strategic risk and building conviction, including how Tim's Evidence Strength Matrix helps teams evaluate signalsFirst steps for teams looking to connect their frameworks and drive improvementAnd much more!Thinking about making progress in your product work? Check out Tim's book at realprogressbook.com and connect with him on LinkedIn or herbig.co.You can find the podcast's page, and connect with Matt and Moshe on LinkedIn:Product for Product Podcast - http://linkedin.com/company/product-for-product-podcast  Matt Green - https://www.linkedin.com/in/mattgreenproduct/ Moshe Mikanovsky - http://www.linkedin.com/in/mikanovsky Note: Any views mentioned in the podcast are the sole views of our hosts and guests, and do not represent the products mentioned in any way.Please leave us a review and feedback ⭐️⭐️⭐️⭐️⭐️

Alex Sloley: How to Coach POs Who Treat Developers Like Mindless Robots In this episode, we refer to the previous episodes with David Marquet, author of Turn the Ship Around! The Great Product Owner: Trust and the Sprint Review That Changes Everything Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "She was like, oh my gosh, I've never seen this before, I didn't think it was possible. I just saw you deliver stuff in 2 weeks that I can actually use." - Alex Sloley In 2011, Alex worked with a client organization creating software for external companies. They needed a Product Owner for a new Agile team, and a representative from the client—who had never experienced Scrum—volunteered for the role. She was initially skeptical, having never witnessed or heard of this approach. Alex gently coached her through the process, asking her to trust the team and be patient. Then came the first Sprint Review, and everything changed. For the first time in her career, she saw working product delivered in just two weeks that she could actually touch, see, and use. Her head exploded with possibility. Even though it didn't have everything and wasn't perfect, it was remarkably good. That moment flipped a switch—she became fully engaged and transformed into a champion for Agile adoption, not just for the team but for the entire company. Alex reflects that she embodied all five Scrum values: focus (trusting the team's capacity), commitment (attending and engaging in all events), openness (giving the new approach a chance), respect (giving the team space to succeed), and courage (championing an unfamiliar process). The breakthrough wasn't about product ownership techniques—it was about creating an experience that reinforced Scrum values, allowing her to see the potential of a bright new future. Self-reflection Question: What practices, techniques, or processes can you implement that will naturally and automatically build the five Scrum values in your Product Owner? The Bad Product Owner: When Control Becomes Domination Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "They basically just owned the team. The developers on the team might as well have been mindless robots, because they were being assigned all the work, told how much work they could do in a sprint, what the work was." - Alex Sloley In 2018, while working with five interconnected Product Owners, Alex observed a Sprint Planning session that revealed a severe anti-pattern. One Product Owner completely controlled everything, telling the team exactly what work they would take into the Sprint, assigning specific work to specific people by name, and dictating precisely how they would implement solutions down to technical details like which functions and APIs to use. The developers were reduced to helpless executors with no autonomy, while the Scrum Master sat powerless in the corner. Alex wondered what caused this dynamic—was the PO a former project manager? Had the team broken trust in the past? What emotional baggage or trauma led to this situation? His approach started with building trust through coffee meetings and informal conversations, crucially viewing the PO not as the problem but as someone facing their own impediment. He reframed the challenge as solving the Product Owner's problem rather than fixing the Product Owner. When he asked, "Why do you have to do all this? Can't you trust the team?" and suggested the PO could relax if they delegated, the response was surprisingly positive. The PO was willing to step back once given permission and assurance. Alex's key lesson: think strategically about how to build trust and who needs to build trust with whom. Sometimes the person who appears to be creating problems is actually struggling under their own burden. Self-reflection Question: When you encounter a controlling Product Owner, do you approach the situation as "fixing" the PO or as "solving the PO's problem"? How might this reframe change your coaching strategy? [The Scrum Master Toolbox Podcast Recommends]

Stop the Madness!  You've coded like a rockstar, but the sprint clock is ticking, and QA is still pounding away!  This episode tears down the biggest myth in Scrum: the phantom finish line.Is it "done" or is it "done-done with a big D"?  We're dropping the truth bomb: it's either done, or it's not done!  Period.  Get ready to smash the silos, ditch the "I'm done my bit" mindset, and transform your team into a Done-Achieving Machine!Discover the root causes of that agonizing sprint-end stall, why starting the next sprint is the LAST thing you should do, and how shifting to M-shaped individuals is your team's superpower.  Learn practical, high-impact strategies for Product Owners and Development Teams to size work effectively, eliminate iterative waterfall, and ensure every feature is truly shippable and usable.

Renee Troughton: Analytics From Day One and Four Other Principles of Great POs Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "Product owners who think about their products as just a backlog that I prioritize, and I get some detailed requirements from stakeholders, and I give that to the team... that's not empowering the team. And it's probably leading you to building the wrong thing, just faster." The Bad Product Owner: The Backlog Manager Without Vision Renee describes a pattern of Product Owners who don't understand product management—they lack roadmaps, strategy, and never speak to customers. These POs focus solely on backlogs, prioritizing detailed requirements from stakeholders without testing hypotheses or learning about their market. Taking an empathetic view, Renee notes these individuals may have fallen into the role without passion, never seeing what excellence looks like, and struggling with extreme time poverty. Product ownership is one of the hardest roles from a time perspective—dealing with legislative requirements, compliance, risk, fail-and-fix work, and constant incoming demands. Drowning in day-to-day urgency, they lack breathing space for strategic thinking.  These POs also struggle with vulnerability, feeling they should have all answers as leaders, making it difficult to admit knowledge gaps. Without organizational safety to fail, they can't demonstrate the confidence balanced with humility needed to test hypotheses and potentially be wrong. The result is building the wrong thing faster, without empowering teams or creating real value. Self-reflection Question: Are you managing your Product Owners' workload and supporting their strategic thinking time, or are you allowing them to drown in tactical work that prevents them from truly leading their products? The Great Product Owner: Analytics from Day One and Market Awareness "They really iterated, I think, 5 key principles quite consistently... the one thing that did really shape my thinking at that time was... Analytics from day one." Renee celebrates a Chief Product Owner who led 13 teams with extraordinary effectiveness. This PO consistently communicated five key principles, with "analytics from day one" being paramount—emphasizing the critical need to know immediately if new features work and understanding customer behavior from launch. This PO demonstrated deep market awareness, regularly spending time in Silicon Valley, understanding innovation trends and where the industry was heading. They maintained a clear product vision and could powerfully sell the dream to stakeholders.  Perhaps most impressively, they brought urgency during a competitive "space race" situation when a former leader left with intellectual property to build a competing product. Despite this pressure, they never allowed compromise on quality—rallying teams with mission and purpose while maintaining standards. This combination of strategic vision, market knowledge, data-driven decision-making, and balanced urgency created an environment where teams delivered excellence under competitive pressure. [The Scrum Master Toolbox Podcast Recommends]

Tom Molenaar: When Product Owners “Eat the Grass” for Their Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Vision Catalyst "This PO had the ability to communicate the vision and enthusiasm about the product, even I felt inspired." Tom describes an exceptional Product Owner who could communicate vision and enthusiasm so effectively that even he, as the Scrum Master, felt inspired about the product. This PO excelled at engaging teams in product discovery techniques, helping them move from merely delivering features to taking outcome responsibility. The PO introduced validation techniques, brought customers directly to the office for interviews, and consistently showed the team the impact of their work, creating a strong connection between engineers and end users. The Bad Product Owner: The Micromanager "This PO was basically managing the team with micro-managing approach, this blocked the team from self-organizing." Tom encountered a Product Owner who was too controlling, essentially micromanaging the team instead of empowering them. This PO hosted daily stand-ups, assigned individual tasks, and didn't give the team space for self-organization. When Tom investigated the underlying motivation, he discovered the PO believed that without tight control, the team would underperform. Tom helped the PO understand the benefits of trusting the team and worked with both sides to clarify roles and responsibilities, moving from micromanagement to empowerment. In this segment, we refer to the book “Empowered” by Marty Cagan. Self-reflection Question: How do you help Product Owners find the balance between providing clear direction and allowing team autonomy? [The Scrum Master Toolbox Podcast Recommends]

Is Scrum Dying? Or Are We Just Doing It Wrong?Scrum used to be king. Now people don't even want it on their CV.Remember when being a Product Owner was cool? When Scrum Masters were change agents, not glorified note-takers?When saying “we use Scrum” signalled progressive, Agile thinking?Fast forward to now, and you'll find Product Owners ashamed of the title, Scrum Masters sidelined, and developers stuck in factory-mode delivery.Teams are jumping ship to SAFe, Kanban, or “whatever Spotify did,” chasing results Scrum couldn't deliver.How to connect with AgileDad:- [website] https://www.agiledad.com/- [instagram] https://www.instagram.com/agile_coach/- [facebook] https://www.facebook.com/RealAgileDad/- [Linkedin] https://www.linkedin.com/in/leehenson/

Terry Haayema: The Product Owner Who Made Retros Unsafe (And How We Fixed It) Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. "The biggest anti-pattern was that he made the retro unsafe... he would come to the retro and called people out for things that had not been done." The Bad Product Owner: The PO Who Made Retros Unsafe Terry describes a product owner who came from a management background focused on widgets and KPIs, completely unprepared for the collaborative nature of the product owner role. This person's biggest anti-pattern was making retrospectives unsafe by calling out individual team members for things not completed or not done to his satisfaction. When gentle coaching interventions failed, Terry took the dramatic step of excluding the PO from retrospectives entirely. Surprisingly, this shock treatment worked - when the PO asked why he wasn't invited, Terry used SBI feedback (Situation, Behavior, Impact) to help him understand how his actions were destroying team dynamics. The story has a positive ending, with the PO eventually understanding and changing his approach. In this segment, we refer to the Retrospective Prime Directive, and the SBI feedback framework. The Great Product Owner: The Customer Connector Terry's best product owner example saw their role not just as the voice of the customer, but as the connector between team and customers. Instead of relying solely on user stories and personas, this PO organized regular informal events where real customers and team members could meet, share pizza and beer, and have genuine conversations. These social connections led to deep customer understanding and resulted in their best feature ever - a simple addition that showed customers their last six orders for easy reordering. This feature increased both order frequency and size while dramatically improving the team's ability to empathize with their users. Self-reflection Question: How might you help your product owner move from being the voice of the customer to being the bridge that connects your team directly with real users? [The Scrum Master Toolbox Podcast Recommends]

One thing lots of agile or scrum teams have in common is that they experience carry over work. Sometimes, we can do it and still survive and meet our goals. But if carry over work becomes the norm and we are unable to get out of the trend, it is problematic for us. There are several different culprits that lead to carry over work, but none is worse than the backlog hijacker. This episode is great for agile leaders, scrum masters, dev teams, software managers and of course the Product Owner!We'll explore some ways to diagnose and triage this problem we have and learn how to say bye bye to our backlog hijacker!Thank you all for your continued support and sharing the podcast! I love being your Practical Agile Coach!

Shawn Dsouza: Beyond Product Knowledge—The Hidden Skills Every Product Owner Needs Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn explores both ends of the Product Owner spectrum through real experiences. On one side, he addresses the "Forced" or "Accidental" Product Owner—a common but problematic pattern where organizations appoint someone based solely on product knowledge. He shares the story of a QA professional thrust into the PO role who knew the product inside out but lacked other essential PO skills, frustrating the team with inadequate responses. Through coaching questions inspired by "The Advice Trap," Shawn helped this reluctant PO reflect on responsibilities and develop confidence beyond technical knowledge. The Great Product Owner: The Story-Crafting Superstar Shawn celebrates a Product Owner who elevated user story writing to an art form—"the Picasso of writing user stories." This exceptional PO co-crafted clear, well-structured stories with the team and used AI to refine stories and acceptance criteria. Her meticulous preparation included intensive refinement sessions before vacations and expert story slicing techniques. By handling requirements clarity superbly, she freed the team to focus entirely on problem-solving rather than deciphering what needed to be built. The Bad Product Owner: The Forced/Accidental Product Owner Organizations frequently make the mistake of appointing the person with the highest product knowledge as Product Owner, assuming technical expertise translates to PO effectiveness. However, the Product Owner role requires diverse skills beyond product knowledge—stakeholder management, prioritization, communication, and strategic thinking. When a QA professional was thrust into this role, their deep product understanding couldn't compensate for underdeveloped PO competencies, leading to team frustration and project complications. In this segment, we refer to the Coach Your PO e-course published by your Scrum Master Toolbox Podcast! Self-reflection Question: What skills beyond domain expertise should you develop or look for when transitioning into or selecting someone for the Product Owner role? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: From AI Anxiety to AI Advantage: A Scrum Master's Experimental Approach Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn faces the massive AI transformation currently reshaping the tech industry, acknowledging both its benefits and the fear it creates among professionals questioning their relevance. In his organization, he witnesses AI delivering wonders for some teams while others struggle and lose projects. Rather than viewing AI as an overwhelming wave, Shawn advocates for experimentation. He shares practical examples, like helping a Product Owner streamline story creation from Excel to JIRA using AI tools, and leveraging MIRO AI for team collaboration. His approach focuses on identifying friction points where AI experiments could add value while keeping conversations centered on possibilities rather than fears. Self-reflection Question: Instead of fearing technological changes like AI, how can you create small experiments to explore new possibilities and reduce friction in your current work processes? [The Scrum Master Toolbox Podcast Recommends]

Shawn Dsouza: The Database Migration Disaster— Why Software Development Teams Need Psychological Safety Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Shawn worked with a skilled team migrating a database from local to cloud-based systems, supported by a strong Product Owner. Despite surface-level success in ceremonies, he noticed the team avoided discussing difficult topics. After three months of seemingly smooth progress, they delivered to pre-production only to discover 140 critical issues. The root cause? Unspoken disagreements and tensions that festered beneath polite ceremony facades. The situation deteriorated to the point where a senior engineer quit, teaching Shawn that pausing to address underlying issues doesn't cost time—it builds sustainability. In this segment, we refer to the episodes with Mahesh Jade, a previous guest on the Scrum Master Toolbox podcast. Featured Book of the Week: The Advice Trap by Michael Bungay Stanier Shawn discovered this transformative book when he realized he was talking too much in team meetings despite wanting to add value. The Advice Trap revealed how his instinct to give advice, though well-intentioned, was actually self-defeating. The book taught him to stay curious longer and ask better questions rather than rushing to provide solutions. As Shawn puts it, "The minute you think you have the answer you stop listening"—a lesson that fundamentally changed his coaching approach and helped him become more effective with his teams. Self-reflection Question: When working with teams, do you find yourself jumping to advice-giving mode, or do you stay curious long enough to truly understand the underlying challenges? [The Scrum Master Toolbox Podcast Recommends]

Bernie Maloney: Problems vs. Solutions: The Great Product Owner Distinction Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Strategic Problem Solver Bernie describes an exemplary Product Owner from a stealth program sponsored by a CTO, where the company needed to create new intellectual property. This Great Product Owner understood that Agile operates in three dimensions: most organizations only focus on outputs and delivery (first dimension), some reach outcomes (second dimension), but the truly great ones operate in the third dimension of strategic or business agility - defining problems worth solving. This Product Owner knew that high-performing teams need to understand what problem is worth solving rather than just receiving solutions to build. They embraced the Mobius loop approach, focusing on discovering the right problems rather than jumping straight to solutions. In this segment, we refer to the Mobius Loop, and to Steve Blank's work on the job of a startup.  We also refer to the episode with Elliott Parker on the critical importance of the “startup mindset” to foster innovation in larger organizations.  The Bad Product Owner: The Backlog Jockey with Authority Issues Bernie identifies the anti-pattern of Product Owners being treated as mere "backlog jockeys" by their organizations, which forces them into solution-building mode rather than problem-solving mode. These Product Owners don't understand the importance of saying "no" and lack clarity about intent and goals. The worst case Bernie encountered was a team manager who also served as Product Owner, wielding positional authority that shut down team communication. This person would interrupt daily scrums, causing teams to revert to waiting for direction rather than self-organizing. The combination of unclear intent and positional authority creates a toxic environment that destroys team autonomy and psychological safety. Self-reflection Question: Is your Product Owner focused on defining problems worth solving, or are they primarily managing a backlog of predetermined solutions? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: The Micromanagement Trap—When PO's Good Intentions Harm Agile Team Performance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Visionary Leader During an agile transformation project modernizing a build system with multiple stakeholders, Mariano worked with an exceptional Product Owner who demonstrated the power of clear vision and well-defined roadmaps. This visionary Product Owner successfully navigated complex stakeholder relationships by maintaining focus on the product vision while providing clear direction through structured roadmap planning, enabling the team to deliver meaningful results in a challenging environment. The Bad Product Owner: The Task-Manager Micromanager Mariano encountered a well-intentioned Product Owner who fell into the task-manager anti-pattern, becoming overly detail-oriented and controlling. This Product Owner provided extremely detailed story descriptions and even specified who should do what tasks instead of explaining why work was needed. This approach turned the team into mere task-handlers with no space to contribute their expertise, ultimately reducing both engagement and effectiveness despite the Product Owner's good intentions. Self-reflection Question: Are you empowering your team to contribute their expertise, or are you inadvertently turning them into task-handlers through over-specification? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: Fear-Free Teams—Creating Psychological Safety for High Performance Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano's definition of Scrum Master success has evolved dramatically from his early days of focusing on "deliver on time and budget" to a more sophisticated understanding centered on team independence and psychological safety. Today, he measures success by whether teams can self-manage, communicate effectively with stakeholders, and operate without fear of criticism. This shift represents a fundamental change from output-focused metrics to outcome-focused team health indicators that create sustainable high performance. Self-reflection Question: How has your definition of success evolved in your current role, and what would change if you focused on team independence rather than traditional delivery metrics? Featured Retrospective Format for the Week: Frustration-Based Retrospective Mariano's retrospective approach focuses on asking team members about their biggest frustrations from the last sprint. This format helps team members realize their frustrations aren't unique and creates psychological safety for sharing challenges. The key is always asking the team to propose solutions themselves rather than imposing fixes, making retrospectives about genuine continuous improvement rather than just complaining sessions. [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: From Evangelist to Facilitator—How To Lead A Successful Company Merger Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. During a complex merger between two telecom companies, Mariano faced the challenge of uniting team members with different cultures, practices, and tools. His initial approach of selling Agile theory instead of focusing on benefits failed because he forgot about the "why" of change. The breakthrough came when he shifted from being an Agile evangelist to becoming a facilitator who listened to managers' real challenges. By connecting people and letting the team present their own solutions to leadership, Mariano successfully created unity between the formerly divided groups. Self-reflection Question: Are you trying to sell your methodology or solve real problems, and what would happen if you focused on understanding challenges before proposing solutions? [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: Breaking Down The Clan Mentality In Agile Teams Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano encountered a competent team that was sabotaging itself through internal divisions and lack of trust. The team had formed clans that didn't trust each other, creating blind spots even during retrospectives. Rather than simply telling the team what was wrong, Mariano created an anonymous fear-based retrospective that revealed the root cause: a Product Owner who behaved like a boss and evaluated team members, creating a culture of fear. His approach demonstrates the power of empowering teams to discover and solve their own problems rather than imposing solutions from above. Self-reflection Question: What fears might be hiding beneath the surface of your team's dynamics, and how could you create a safe space for them to emerge? Featured Book of the Week: Turn the Ship Around! by David Marquet Mariano recommends "Turn the Ship Around!" by David Marquet (we have an episode with David Marquet talking about this book, check it here). Mariano highlights the fascinating story and introduction to the leader-leader model, which differs significantly from the traditional leader-follower approach. This book resonates with Mariano's journey from directive leadership to facilitative leadership, showing how empowering others rather than commanding them creates more effective and engaged teams. [The Scrum Master Toolbox Podcast Recommends]

Mariano Gontchar: From Boss to Facilitator—The Critical Role of Empathy in Scrum Mastery Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Mariano shares his transformation from viewing himself as a boss in his project manager role to embracing the facilitator mindset essential for Scrum Masters. His journey reveals a crucial insight: you cannot implement Scrum with a "big bang" approach.  Instead, success comes through empathy and understanding your team's needs. Mariano emphasizes that working with Agile requires constant practice and learning, but the key lesson that changed everything for him was learning to empathize with his team members rather than directing them from above. Self-reflection Question: How might your current leadership style be limiting your team's potential, and what would change if you shifted from directing to facilitating? [The Scrum Master Toolbox Podcast Recommends]

Salum Abdul-Rahman: Learning to Communicate Value in Public and Non-Profit Sectors' Product Development Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Systematic Value Communicator Salum describes working with a Product Owner who had a PhD in data science on a public sector visualization project. This exceptional PO was extremely systematic in working with stakeholders and possessed a unique ability to bridge abstract concepts with concrete implementations. In the public sector, where monetary feedback is absent, this PO excelled at thinking about value achievement and communicating it effectively to the team. They had the magical capability to involve stakeholders while demystifying complex requirements, helping the team understand not just engagement metrics but how their work would change society and the world. The Bad Product Owner: The Absentee Specialist The most common anti-pattern Salum encounters is the absentee Product Owner - typically a specialist assigned to the PO role while maintaining their full-time job as a domain expert. With only 10-20% time allocation, these POs lack the capacity to fulfill their responsibilities effectively. They often don't have the time or knowledge to develop essential PO skills, requiring extensive hand-holding to understand even basic concepts like user stories. Salum's approach involves booking time directly in their calendar for backlog refinement sessions and providing comprehensive guidance to help them understand the role, though this intensive support is necessary due to their limited availability for skill development. In this segment, we refer to the concept of ‘enshitification' by Cory Doctorow, and refer to Tom Gilb's bonus episode on the Scrum Master Toolbox Podcast.  Self-reflection Question: How do you ensure your Product Owner has both the time allocation and skill development needed to truly serve the team and stakeholders effectively? [The Scrum Master Toolbox Podcast Recommends]

BONUS: The Platform-as-Product Revolution: How to Turn Your Biggest Cost Center Into Your Secret Weapon With Alvaro Lorente In this BONUS episode we explore a topic that's creating a lot of discussion—and sometimes confusion—in the software community: Platform Teams vs DevOps. In this conversation, we dive into Alvaro Lorente's journey from delivery teams to platform leadership, exploring how to treat platforms as products, avoid common pitfalls, and build bridges between engineering and product leadership. The Evolution from DevOps Role to Platform Team "DevOps is a culture, not a role." Alvaro's journey into platform work began when he joined a company where the infrastructure team was left behind and struggling with traditional DevOps approaches. Initially, they had a single DevOps person who became a bottleneck rather than an enabler. This experience highlighted a fundamental misunderstanding that many organizations face—treating DevOps as a job title rather than a cultural shift toward collaboration and shared responsibility. The team experimented with a "DevOps buddy" approach, placing experienced individuals within each delivery team, before eventually consolidating into a dedicated platform team with the clear intention of treating it as a product-focused unit. Platform as a Product: A Scaling Strategy "Platform as a product is a scaling strategy. Look for common problems that you can then solve once, and serve many." The concept of treating platforms as products emerged from recognizing that feature delivery teams have continuity and ongoing needs that a platform team should serve. Rather than solving their own problems first, successful platform teams focus on making other teams' work easier and more comfortable while managing costs effectively. This approach requires identifying common problems across multiple teams and creating solutions that can be implemented once but serve many. The key insight is that platform teams exist to facilitate the delivery of value in a scalable way for other teams, not to pursue their own technical interests. Understanding Your Customer and Validating Value "I want to see platform team members talking to their customers. Understand their pains, and what they struggle with." Effective platform teams operate like any other product team by actively listening to their customer-teams rather than pushing ideas onto them. This means platform team members should regularly engage with their internal customers to understand pain points and struggles. Success requires defining clear KPIs for the platform and focusing on the quality of deliverables including release notes, demos, bug fixing processes, and feature prioritization. The validation comes from observing whether teams willingly adopt platform features rather than being mandated to use them. Building Bridges with Product Leadership "Focus on the key impact and value that the platform team can bring to the company." Making the case for investing product talent in platform teams requires demonstrating concrete business value. This includes quantifying how many incidents are being resolved faster or prevented entirely, and highlighting the money saved through internal platform development versus external solutions. Platform work offers excellent growth opportunities for Product Owners, serving as a training ground for product thinking and stakeholder management. The focus should always be on measurable impact rather than technical complexity. Avoiding Common Platform Team Traps "Don't just start working on what you think is important! Start with the Product process, listen to the client-teams, and help them directly." When standing up a platform team, several critical mistakes can derail success. The most important trap to avoid is immediately diving into what the platform team thinks is important without first understanding customer needs. Platform teams should resist delivery pressure that might compromise quality and never mandate adoption of their features—teams should want to use what the platform provides. Treating the platform as a genuine product with quality standards is essential, and leaders should view the creation of a platform team as the beginning of a change management process rather than just a technical reorganization. Resources and Continuous Learning "One size does NOT fit all!" For teams looking to improve their platform work, Alvaro recommends Camille Fournier's work on platform teams and resources focused on "The value of product thinking in platform teams." The key is to get experiments running within your team and recognize that there's no universal solution—each organization must find its own path based on its unique context and needs. About Alvaro Lorente Currently Director of Engineering at Voxel (an Amadeus company), Alvaro is a software engineer who has grown in the people leadership path, experimenting with everything from product development to startups and open source projects. He embraces the idea of being a jack of all trades, helping wherever needed to drive value and impact. You can connect with Alvaro Lorente on LinkedIn and follow his insights through his Substack newsletter titled Leads Horizons.

Irene Castagnotto: Building Bridges—How Great Product Owners Create Team Alignment Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: Building Trust Through Transparency and Purpose Irene emphasizes that exceptional Product Owners excel at building trust with their teams by consistently sharing the "why" behind decisions and features. They trust their teams completely and ensure that team members understand the purpose and reasoning behind every request. This transparency creates a foundation of mutual trust where teams feel confident in the Product Owner's direction. Great Product Owners use moments when features don't work as expected as opportunities to explore and reinforce the underlying purpose, turning potential setbacks into learning experiences that strengthen team understanding and alignment. The Bad Product Owner: When Stories Replace Truth Irene witnessed a Product Owner who, when facing difficult client conversations without positive information to share, chose to "make up stories" rather than being transparent about challenges. This lack of honesty led to delivering something the client couldn't accept, resulting in an angry client during the demo. This anti-pattern of using "good words" instead of honest communication ultimately damages client relationships and team credibility. The lesson learned: Product Owners must be transparent with clients about what is and isn't possible, even when the news is difficult to deliver. Self-reflection Question: How do you balance protecting your team from client frustration while maintaining the transparency necessary for successful product development? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: The Risk-Aware Scrum Master: Preventing Problems Before They Happen Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene defines success for Scrum Masters as helping teams anticipate and manage risks before they become unexpected problems. She focuses on ensuring teams don't face surprise risks during sprints and don't start work with missing requirements. Her approach includes using user story mapping with Product Owners to visualize potential risks and maintaining team happiness as a key success indicator. For Irene, creating a positive team environment is a crucial deliverable that Scrum Masters must actively work on. She emphasizes the importance of listening to team feedback and regularly assessing whether the team feels supported and engaged. In this segment, we refer to W. Edwards Deming, and his famous quote “a bad system will beat a good person, every time!” Featured Retrospective Format for the Week: The Good/Bad/Risk Retrospective This retrospective format works particularly well with younger teams and uses humor to help teams discuss emotionally challenging topics. The format focuses on three key areas: what went well (Good), what didn't work (Bad), and what potential risks the team sees ahead (Risk). Irene recommends this approach because it helps teams surface risks that aren't visible to anyone else, creating opportunities to address potential problems proactively. By incorporating the language of risk into everyday conversations, teams become more aware of potential challenges and can plan accordingly. The humor element helps reduce the emotional intensity that often accompanies difficult discussions about team performance and challenges. In this segment, we refer to the book “How to Make Good Things Happen: Know Your Brain, Enhance Your Life” by Marian Rojas Estape. Self-reflection Question: How comfortable is your team with discussing risks openly, and what techniques could you use to make these conversations more approachable? [The Scrum Master Toolbox Podcast Recommends]

Irene Castagnotto: When Proactive Help Backfires - A Gen Z Scrum Master's Learning Journey Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. Irene shares a valuable lesson about the pitfalls of being overly proactive without proper communication. As a new Scrum Master, she observed Product Owners struggling with role changes and took initiative to help them understand and implement changes. However, she discovered that her well-intentioned proposals weren't aligned with what the POs actually wanted. The key insight: when people don't speak up during your proposals, it often means they're not on board but are avoiding conflict. Irene learned that asking questions and letting others express what changes they're ready for is far more effective than assuming what help is needed. Self-reflection Question: How can you better gauge whether your team is genuinely on board with your suggestions, especially when they remain silent during discussions? [The Scrum Master Toolbox Podcast Recommends]

In this episode of the Small Business PR Podcast, I sit down with Kim Behzadi, founder of Read It & Eat—a purpose-driven food and book subscription box that fights hunger with every purchase.Launched from her bedroom after losing her job during the pandemic, Kim bootstrapped her business with no investors, no PR background, and no big-name endorsements. Today, she's been featured in Women's Day, local magazines, and podcasts—without spending thousands on PR retainers or flooding the media with free samples.If you're a product-based founder who wants consistent, cost-free press, this episode is your blueprint.How Kim Built a PR System That Delivers Year-Round FeaturesAfter joining the PR Starter Pack, Kim learned to:Pitch with purpose, not desperationBuild relationships with journalists through LinkedIn, Instagram, and even TwitterAdapt pitches for national vs. local media to maximize relevancePlant PR “seeds” months in advance to secure Q4 gift guide placementsHer Women's Day feature led to:A 40% increase in website trafficLocal partnerships like a Buffalo book club and tea shop collaborationInvitations to vend at book fairs and community eventsA direct connection with a Harlequin author for a special edition boxWhy Serving (Not Selling) Gets You FeaturedKim stopped leading with “Here's my product” and started pitching with “Here's a story your audience will love.” This value-first approach helped her:Land coverage without sending dozens of samplesGet invited to collaborate with brands and authors she once thought were “out of reach”Build a press system she can run in just two dedicated nights per weekKim's PR Tools & StrategiesLinkedIn & Instagram to find and connect with journalistsEmail + social media follow-ups to stay top-of-mind without spammingSeasonal pitching calendar to target: Valentine's Day, Mother's Day, Back-to-School, Holidays, and themed brand roundupsThe CPR Method (Credibility, Point of View, Relevance) to craft irresistible pitchesCommon PR Mistakes Kim AvoidedOverspending on product samples before confirming interestWaiting for the “perfect” moment to start pitchingRelying solely on social media for visibilityFinal TakeawayYou don't need an expensive PR firm—or a massive marketing budget—to land in national gift guides. What you do need is: ✅ A clear, value-driven message ✅ A repeatable system ✅ The courage to hit “send”If Kim can build Read It & Eat from her bedroom and land Women's Day, so can you.

Industrial Talk is onsite at Xcelerate 2025 and talking to Austin Anderson, Product Owner, Condition Monitoring at Fluke Reliability about "Azima's Powerful AI Vibration Platform". Scott MacKenzie hosts the Industrial Talk podcast, highlighting industry innovations and trends. He introduces Austin Anderson, who discusses Azima's diagnostic system and its integration with Fluke Reliability. Anderson explains the standardization of data collection over 15 years, emphasizing the importance of accurate data for reliability. He details the integration of Azima's AI with human analysts for 85% accuracy and the development of a user-friendly interface. The conversation also covers the future of Azima, including expansion into oil analysis and thermography, and the importance of efficient data storage and management. Anderson can be contacted via LinkedIn for more information. Action Items [ ] Rebuild the Azima user interface to make it more user-friendly and easily accessible. [ ] Integrate Azima's data and insights with Fluke's other reliability solutions, such as alignment and balancing, to provide an end-to-end connected reliability offering. [ ] Enhance the Azima platform to include additional reliability data sources beyond just vibration, such as oil analysis and thermography. [ ] Develop a solution that can automatically translate Azima's problem identifications into work orders in the customer's CMMS (e.g., eMaint). Outline Introduction and Overview of Industrial Talk Podcast Scott MacKenzie introduces the Industrial Talk podcast, emphasizing its focus on industrial innovations and trends. Scott highlights the free ebook and workbook available on Industrial Talk, which expands on five elements of successful companies: educate, collaborate, innovate, invest in culture, and communicate effectively. Scott MacKenzie thanks listeners for their support and celebrates industrial professionals for their boldness, bravery, and problem-solving skills. Introduction of Austin Anderson and Azima Scott MacKenzie introduces Austin Anderson, who will discuss the product Azima. Austin Anderson shares his background, mentioning his three-year tenure with Azima and his role in developing the diagnostic system. Scott MacKenzie inquires about the accuracy of the data stored in Azima, to which Austin explains the standardized method of data collection and its relevance over the years. Austin discusses his background in vibration analysis and his previous work with the Navy, highlighting his expertise in the field. Strategic Path and User Experience of Azima Austin outlines the strategic path for Azima, focusing on making reliability engineers superstars and providing useful insights for top-level executives. Scott MacKenzie asks about the integration of Azima with Fluke Reliability, and Austin explains the goal of making the platform user-friendly and value-added. Austin describes the end-to-end connected reliability solution offered by Fluke Reliability, including hardware, software, and alignment and balancing services. Scott and Austin discuss the importance of user experience and the redesign of the user interface to make it more accessible and user-friendly. Data Accuracy and Integration with Fluke Reliability Scott MacKenzie inquires about the accuracy of the diagnostic system, and Austin explains that AI can achieve 85% accuracy, with the remaining 15% covered by human analysts. Austin discusses the integration of Azima with Fluke Reliability's x5...