Podcasts about product owners

We're talking about either the terrifying or totally mundane new world of "vibe coding" - using AI to generate code without deep technical expertise. Joining Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel for this podcast, we're happy to welcome back to the podcast Lenar Mukhamadiev, CEO of iDelsoft (https://idelsoft.com)!Listen as we discuss how this trend is changing product development, software engineering careers, and business innovation. Stick around while we argue over resistance, how vibe coding enables faster market testing and many more points, including:Accelerating time-to-market for new ideasEvolving role of professional developersUnderstanding business problems is more valuable than codingEmergence of "product engineers," or notA future where everyone is a software creator#AIinTech #ProductDevelopment #FutureOfWork= = = = = = = = = = = =YouTubeSubscribe on YouTubeAppleSpotify= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Deniz Ari: Why Great Product Owners Listen—Communication Lessons from Product Ownership Extremes The Great Product Owner: The Power of Clear Communication Deniz describes a truly exemplary Product Owner who excelled through outstanding communication skills. This PO was an exceptional listener who maintained openness throughout all interactions. They ensured the team thoroughly understood requirements and priorities, always clearly articulating the rationale behind decisions. With a well-defined product vision and transparent prioritization process, this PO successfully bridged the gap between the development team and clients. Deniz emphasizes how this clear communication style naturally fostered team motivation, as everyone understood not just what they were building, but why it mattered. The Bad Product Owner: The Tyrant PO Deniz shares a challenging experience with a problematic Product Owner during what initially appeared to be a straightforward public sector migration project with adequate budget and timeline. Despite these favorable conditions, the situation deteriorated when the PO began pushing the team to work overtime, overstepping boundaries by questioning architectural decisions, and inappropriately assuming Scrum Master responsibilities. Described as a "tyrant" or "despot," this PO exhibited extremely poor communication skills and preferred dictating rather than collaborating. When Deniz attempted to address these issues, the situation became so toxic that it affected Deniz's health, ultimately leading to their decision to leave the project. The PO subsequently claimed no Scrum Master was needed. Deniz reflects that sometimes the best option is to recognize when a situation cannot be changed and to move on. Self-reflection Question: What boundaries would you establish with a dominant Product Owner, and at what point would you decide that the situation cannot be improved? [The Scrum Master Toolbox Podcast Recommends]

Deniz Ari: Why Your Process Changes Are Failing—The Stakeholder Alignment Problem 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. Deniz explores the challenges of implementing change in organizations, emphasizing that change is always a long and difficult process requiring patience and trust. Drawing on the Change Curve concept, Deniz shares a personal experience trying to improve project visibility by cleaning up backlogs in JIRA for 10 in-flight projects. Despite good intentions, Deniz found themselves as the only person using the tool, with team members and Product Owners using different systems that better suited their specific needs—POs wanting only high-level items while the development team needed to split items into smaller tasks. Through this experience, Deniz learned the crucial importance of having all stakeholders (Product Owners, development teams, and managers) aligned on using the same tool, and understanding the unique perspectives of each group before implementing process changes. In this episode, we refer to the Change Curve.  Self-reflection Question: What changes have you attempted to implement that failed because you didn't fully understand the different needs and perspectives of all stakeholders involved? [The Scrum Master Toolbox Podcast Recommends]

Do you want to hear a story about stifling growth and creativity through the lens of one developer's personal story?You're in luck! Join Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel as they watch and react to Theo's YouTube video: "Being a good engineer kinda sucks," April 28, 2025.It's a tale about the tension between excelling at your craft versus navigating organizational politics and dysfunction. That's right, today, we're talking about themes of career development, team dynamics, and leadership, so feel free to stick around for our thoughts on these and:The sustainability trap of overworking to meet unrealistic expectationsHow organizational politics can punish innovation and excellenceThe importance of product sense vs. documentation-driven developmentFinding and nurturing relationships with like-minded professionals#Leadership #ProductManagement #CareerDevelopment #TechCareersLINKS= = = = = = = = = = = =YouTubeAppleSpotifyREFERENCES= = = = = = = = = = = =Check Out Theo's Video here: https://www.youtube.com/watch?v=3VuM1GCadt4...and his YouTube Channel: https://www.youtube.com/@t3dotgg...and his website: https://t3.gg/MUSIC= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Deniz Ari: Security Team Breakdown—The Devastating Impact of Poor 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. Deniz shares the story of a security project with a team of eight experienced, senior engineers working on mission-critical systems. Despite initial motivation and clear architectural solutions, the team soon exhibited signs of negative behavior including complaints and criticism. The root cause traced back to frequent Product Owner changes—several within less than a year—and poor client management. Instead of shielding the team, the PO directly transferred stress from clients to the team, demanded overtime, and created unnecessary tension by bringing unfiltered conflicts to the team and requesting excessive details. Deniz emphasizes the importance of avoiding unnecessary tensions, being more political when necessary to protect the team, and being mindful of tone in written communications. Self-reflection Question: In what ways might you be failing to set proper boundaries in your role, and how could establishing clearer limits improve both your effectiveness and your team's performance? Featured Book of the Week: Boundaries by Henrik Cloud Deniz recommends "Boundaries" by Henrik Cloud, a book about human relationships and personal limitations. The book addresses crucial questions: Does your life feel out of control? Do you keep saying yes to everyone? Are you taking responsibility for others' feelings and problems? Have you forgotten your own limitations? Deniz explains how this book helped them learn to say "no" while still considering others' realities and feelings, and understanding why we often struggle with setting boundaries. Deniz highlights that being a Scrum Master involves much more than just processes and methods—it requires healthy personal boundaries. [Scrum Master Toolbox Podcast Recommends]

Simina Fodor: Why the 'Why' Matters—Product Owner Communication Lessons 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: Transparency and Customer Focus This exemplary Product Owner shaped Simina's entire view of product management and even inspired her to consider a future transition to that role. Despite not having a traditional product background (coming instead from support), this PO demonstrated exceptional openness to both giving and receiving feedback. They consistently explained the logic behind decisions, sharing the "why" that motivated their priorities. What truly set them apart was bringing customer perspectives and use cases directly to the team, helping developers understand the features through the lens of personas and user scenarios. The PO's transparency extended to their own professional journey, openly sharing how they grew into the role, which created an atmosphere of continuous learning and development. The Bad Product Owner: The Ghost Commander This experienced Product Owner approached the role with a command-and-control mindset carried over from previous Project Management experience, believing that backlog grooming was "beneath them." Essentially a ghost to the team, they avoided retrospectives while issuing constantly shifting priorities with little explanation or logic. The PO would issue commands and demand immediate responses without considering consequences, creating a toxic environment that threatened to destroy team morale. Simina recommends coaching such Product Owners on agile mindset principles and seeking leadership support when necessary to prevent team deterioration. Self-reflection Question: How can you effectively bridge the gap between command-and-control Product Owners and teams seeking more transparency and collaboration? [Scrum Master Toolbox Podcast Recommends]

Simina Fodor: The Courage to Question—Signs of a Healthy Agile Team 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. For Simina, Scrum Master success goes far beyond facilitation skills – it's about what happens when you're not in the room. True success means creating a self-sustaining team that maintains healthy practices even in your absence. Simina looks for indicators like: Do team members feel safe raising concerns regularly? Can they push back with the Product Owner and offer suggestions? Do they proactively ask for the "why" behind requests instead of blindly following directions? She emphasizes that successful teams raise dependencies early in the sprint, have the courage to plan work with other teams, and handle integrations independently. The ultimate test of Scrum Master effectiveness is whether the team continues to thrive even when you step away for a few days. Self-reflection Question: What specific behaviors would indicate that your team has reached a level of self-sustainability that would allow you to step back? Featured Retrospective Format for the Week: Start/Stop/Continue Simina advocates for the simplicity of the Start/Stop/Continue retrospective format. After experimenting with numerous complex approaches, she found that sometimes the most straightforward formats yield the best results. This classic structure cuts through noise and focuses teams on what truly matters: what new practices they should begin, what isn't working and should stop, and what's effective and should continue. Simina appreciates how this format's simplicity makes it accessible and easy to follow, allowing teams to concentrate on meaningful conversation rather than getting lost in complicated retrospective mechanics. [Scrum Master Toolbox Podcast Recommends]

"If you're going to write about Agile, you better work Agile."In this special live episode, hosts Jim and Sander chat with Olina Glindevi and Ben Walder, the creative duo behind The Visual Agile Coach Playbook, at the ScanAgile 25 conference in Helsinki. They share the origin story of their book, their collaboration journey, and the power of visual thinking in agile coaching and team collaboration.The motivation and madness behind writing The Visual Agile Coach Playbook while juggling day jobs and family life.Using visuals as a serious and practical tool in agile work — not just as decoration or “fun stuff.”The creative friction between Ben's structured writing approach and Olina's visual process — and how they found agility in their collaboration.Why they believe trust, feedback, and staying in your lane can lead to stronger results when working in teams.The role of visual agile coaches and how visuals can unlock alignment, clarity, and engagement in teams.A sneak peek into their next project — a collaborative book on the future of work.Get the book: https://a.co/d/1V11eSOConnect with Olina & Ben (51) Olina Glindevi ✏️ | LinkedIn & (51) Ben Walder | LinkedInCheck out our sponsor:www.xebia.comwww.scrummatch.comwww.wiserbees.comwww.masteringagility.orgHosted by Ausha. See ausha.co/privacy-policy for more information.

Witam w dwieście osiemdziesiątym czwartym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest raport o stanie rynku pracy ról związanych z zarządzaniem produktem i projektem w IT.Dziś moim gościem jest Łukasz Drynkowski, z którym mam przyjemność współtworzyć portal z ofertami pracy dla branży IT o nazwie SOLID.Jobs.W tym odcinku omawiamy m. in. takie aspekty raportu jak:liczba ofert dla ról PM, PO w 2023 i 2024 roku,średnia liczba aplikacji w poszczególnych rolach,wynagrodzenie i oczekiwania finansowe w zależności od rodzaju umowy,technologie wymagane przez pracodawców.Subskrypcja podcastu:zasubskrybuj w Apple Podcasts, Spreaker, Sticher, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)poproszę Cię też o polubienie fanpage na FacebookuLinki:Raport – https://solid.jobs/zarzadzanie-projektem-i-produktemProfil SOLID.Jobs na LinkedIn – https://www.linkedin.com/showcase/solid.jobs/SOLID.Jobs – https://solid.jobs/Wsparcie:Wesprzyj podcast na platformie Patronite -https://patronite.pl/porozmawiajmyoit/Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.plhttps://porozmawiajmyoit.pl/284

In dieser Podcastfolge spricht Daniel Koppel mit Oliver über seinen Weg in die digitale Produktwelt – und darüber, wie ihn die Ausbildung zum Produktmanager beruflich und persönlich verändert. Daniel kommt nicht aus der IT. Er hat eine kaufmännische Ausbildung gemacht, im Lager gearbeitet, Verantwortung übernommen. Aber irgendwann merkt er: Das kann es nicht gewesen sein. Der Job funktioniert – aber erfüllt nicht. Und das soll sich ändern. Über Freunde aus der IT erfährt er mehr über agiles Arbeiten, über Quereinstiegsmöglichkeiten, über Produkte, die echten Nutzen bringen. Der Gedanke, sich beruflich neu auszurichten, wird konkreter. Daniel informiert sich, prüft Optionen und entscheidet sich schließlich für eine geförderte Ausbildung zum Produktmanager mit IHK-Abschluss. Nicht als Notlösung – sondern als echte Perspektive. In der Ausbildung lernt er, wie moderne Produktentwicklung funktioniert: von Design Thinking bis Scrum, von Customer Journey Mapping bis Roadmapping. Er absolviert Zertifizierungen zum Scrum Master und Product Owner, entwickelt Produktideen, arbeitet an echten Use Cases – und erlebt, wie viel Freude es macht, Produkte mitzugestalten statt nur zu verwalten. Gleichzeitig geht es um mehr als nur Inhalte. Daniel muss lernen, zu lernen. Sich zu strukturieren, dranzubleiben, Verantwortung zu übernehmen – auch für den eigenen Fortschritt. Genau das macht die Ausbildung zum Produktmanager für ihn so wertvoll: Sie fordert, aber sie gibt auch Sicherheit. Mit echtem Praxisbezug, sinnvollen Tools und guter Begleitung. Was ihm besonders hilft: Die Ausbildung wird durch einen Bildungsgutschein gefördert. Und sie gibt ihm die Möglichkeit, Schritt für Schritt in den Beruf hineinzuwachsen. Heute steht Daniel kurz vor dem Abschluss, bereitet sich auf Bewerbungsgespräche vor und merkt, wie gefragt die Themen sind, mit denen er sich beschäftigt hat. Agilität, Nutzerzentrierung, Produktstrategie – das, was vor einem Jahr noch Neuland war, gehört inzwischen zu seinem Werkzeugkasten. Daniels Geschichte zeigt, was eine gute Ausbildung zum Produktmanager leisten kann – besonders für Menschen, die den Quereinstieg wagen. Sie schafft Klarheit, stärkt Selbstvertrauen und eröffnet neue Wege. Und sie macht deutlich: Es ist nie zu spät, einen neuen Anlauf zu nehmen. Wenn du selbst mit dem Gedanken spielst, dich beruflich zu verändern, mehr Verantwortung zu übernehmen oder tiefer in die digitale Produktwelt einzusteigen – dann hör in diese Folge rein. Vielleicht ist es genau der Impuls, den du brauchst.

In dieser Episode spreche ich mit Olaf Bublitz über sein neues Buch „Agile Produktentwicklung mit visuellen Methoden“, das er gemeinsam mit Thomas Starz veröffentlicht hat. Olaf gibt uns spannende Einblicke, wie visuelle Methoden dabei helfen können, Kommunikation in der Produktentwicklung effizienter zu gestalten – und wie man eine durchgängige visuelle Landschaft vom ersten strategischen Gedanken bis zur Umsetzung aufbaut. Wir sprechen unter anderem über: Wie Olaf vom Entwickler zum Visual Product Ownership-Experten wurde Warum ein Product Development Canvas ein guter Startpunkt für jedes Produkt ist Welche visuellen Methoden besonders hilfreich sind (z. B. People Interactions Map, Strategy Map) Wie man visuelles Arbeiten auch remote und in hybriden Teams erfolgreich umsetzt Was passieren muss, damit Workshop-Ergebnisse nicht versanden Warum „schöne Visualisierungen“ zweitrangig sind – und es auf etwas anderes ankommt

When maximizing desired outcomes for your stakeholders - whether it‘s your customers or employees & partners - you need to self-assess your ways to see how you are improving your craft. Enter: the Product Owner self-assessment. Shobit Mishra explains how he has been using this tool to start from his baseline to improve performance and critical stakeholder involvement in the ERP space in small peacemeal fashion. Hosted by Thoralf J. Klatt

Nie każdy projekt potrzebuje Product Ownera. Czasem PO to wartość, czasem – koszt (i frustracja współpracującego z nim Project Managera). Podczas tej rozmowy rozbieramy na czynniki pierwsze, kiedy ta rola wnosi realną wartość, a kiedy jest sztucznie wciskana tylko dlatego, że „tak mówi Scrum Guide”.Z odcinka dowiesz się o:✔ przykładach firm, które PO potrzebują, ale go nie mają,✔ sytuacjach, gdzie PO się nie sprawdza (i dlaczego), ✔ jak może wyglądać sensowna (lub nie do końca sensowna) współpraca PO z Project Managerem, ✔ stanie rynku pracy i tym, ✔ co może pomóc PO-som nie wypaść z gry,✔ najbardziej irytujących bzdurach o PO, jakie krążą po social mediach.

Neste episódio do Product Guru's, Paulo Chiodi recebe Joaquim Torres, o Joca, para discutir uma das dúvidas mais persistentes do universo de produtos: afinal, qual é a real diferença entre Product Owner (PO) e Product Manager (PM)? Com base em experiências práticas, postagens virais no LinkedIn e séries de artigos, Joka desmistifica a origem de ambos os papéis, contextualiza a confusão gerada por metodologias ágeis como o Scrum, e revela como nomenclaturas erradas podem impactar até salários e estrutura organizacional.Além disso, a conversa avança para a estrutura de carreira em produtos, falando sobre APM, GPM e o papel estratégico do PM. Joca também comenta sobre a importância de ter clareza nos papéis e responsabilidades, como isso afeta empresas grandes e a transição de profissionais de outras áreas para produto.O episódio fecha com dicas valiosas para quem está entrando na área ou quer ajudar seu RH a entender melhor a diferença entre cargo e disciplina na gestão de produtos./// Conteúdos completares:Vídeo POvsPM: 3 perspectivas: https://youtu.be/EfcmyA-c3s8?si=VBhxsQ4TVleuO8O7Post do Joca que viralizou: http://bit.ly/3ETH17QLivro do Joca: https://amzn.to/4m1NRJ8/// Viva a nova era de produtos digitais com a PM3. PM, chegou a hora de criar e delegar com mais inteligência! A PM3 vai realizar uma Masterclass exclusiva: ‘'O Roadmap da NOVA ERA de Produtos'' Lá, eles vão falar sobre o que PMs podem delegar com IA, quais ferramentas já estão moldando o mercado, e por que dominar essa habilidade é essencial para quem quer crescer na carreira. O evento é online, gratuito e acontece no dia 13/05.Acesse o link e faça a sua inscrição: https://go.pm3.com.br/Podcast-PG-NovaEra/// Onde encontrar os convidados:Joca Torres | Founder & Principal Consultant @ Gyaco:https://www.linkedin.com/in/jocatorres/// Nesse episódio abordamos:• PO é um papel do Scrum; PM é uma função de carreira.• Usar PO e PM como sinônimos pode achatar salários e gerar confusão organizacional.• GPM é o primeiro passo da liderança em produto em empresas maduras.• APM deve ter escopo pequeno, mas responsabilidade real e não ser "assistente de PM".• Cargos precisam de clareza de papéis e responsabilidades, isso evita disfunções.• RH muitas vezes força nomenclaturas incorretas por limitações em seus sistemas.• PM é responsável por entregar valor tanto para o cliente quanto para o negócio.• Certificações como CSPO não garantem experiência prática nem conhecimento profundo.• Produto é disciplina, não apenas um cargo; qualquer área pode praticar.• Muitas pessoas já praticam gestão de produto sem saber, é preciso traduzir experiências anteriores./// Capítulos00:00 Abertura02:14 Por que ainda falamos sobre PO vs PM03:00 A confusão entre os papéis e a viralização no LinkedIn06:30 A visão de PO e PM em startups vs empresas grandes07:05 A origem dos papéis e a evolução histórica11:03 Construindo a carreira: de BA a PM13:00 APM, PM e a estrutura ideal de crescimento16:40 Nomenclatura e impacto no RH21:37 O debate vai migrar para cargos de liderança?26:00 O papel real de um GPM29:42 Estrutura de produtos ideal: APMs, PMs e GPMs32:57 APM deve ter squad própria?35:53 A importância da clareza de papéis nas empresas39:50 Separação entre produto de negócio e produto digital44:51 Qual o papel real de um PM?48:37 Migração de outras áreas para produto50:45 Gestão de produto como disciplina, não só cargo53:09 Encerramento/// Onde encontrar a Product Guru's:WhatsApp: https://whatsapp.com/channel/0029Va7uwHS5fM5U0LIatu3XX (antigo Twitter): ⁠https://twitter.com/product_gurus⁠LinkedIn: ⁠https://www.linkedin.com/company/product-guru-s/⁠Instagram: ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠https://www.instagram.com/product.gurus/⁠

BONUS: Nesrine Changuel shares how to create emotionally connected, delightful products! In this BONUS episode, we explore the concept of product delight with Nesrine Changuel. Nesrine shares insights from her extensive experience at companies like Skype, Spotify, Google Meet, and Chrome to help us understand how to create lovable tech experiences that drive user loyalty and differentiation. We explore the Delight Grid Framework she created, and discuss the importance of emotional connection in product design. We also touch on practical ways to incorporate delight into everyday product decisions. The Essence of Delight in Products "Creating emotional connection between users and products... What I'm usually vocal about is that it's not enough to solve functional needs if you want to create sustainable growth, and more particularly if you want to have your users love the product and create habits using your product." Nesrine explains that while most companies know how to solve functional problems, truly delightful products go beyond functionality to create emotional connections with users. This connection comes from anticipating user needs and surprising them on both functional and emotional levels. She emphasizes that delight emerges when users experience both joy and surprise simultaneously, which is key to exceeding expectations and building brand loyalty. Moving Beyond User Complaints "Most features that are built in products are coming from users' complaints... What I'm trying to be clear about is that if you want to build an emotional connection, it's about opening up a little bit more of your source of opportunities." Many teams focus primarily on addressing user complaints, which puts them in a reactive position. Nesrine encourages organizations to anticipate user needs by engaging with users in comfortable environments before problems arise. She suggests looking beyond direct feature requests and investigating how users feel while using the product, how they experience the journey, and what emotions arise during the experience. This proactive approach opens new opportunities for creating delightful experiences that users may not explicitly request. In this segment we refer to the KANO model for categorizing product features. Understanding Emotional Demotivators: The Zoom Fatigue Example "I tried to interview many users and realized that, of course, with the fact that we all moved into video conferencing, some demotivators started to surface like boredom, low interaction, overwhelm. There was a term that started to show up at the time - it's called zoom fatigue." Nesrine shares how her team at Google Meet tackled emotional demotivators by first deeply understanding them. By investigating "Zoom fatigue," they discovered through Stanford research that one major cause was the fatigue from constantly seeing yourself on screen. This insight led them to develop the "minimize self view" feature, allowing users to broadcast their video without seeing themselves. This example demonstrates how understanding emotional pain points can lead to features that create delight by addressing unspoken needs. The Delight Grid Framework "We want to delight the users, but because we don't know how, we end up only doing performers or hygiene features." Nesrine introduces her Delight Grid Framework, which helps product teams balance functional and emotional needs. The framework begins by identifying emotional motivators through empathetic user research. These motivators are then placed in a grid alongside functional needs to classify features as: Low Delight: Features that only solve functional needs Surface Delight: Features that only address emotional needs (like celebratory animations) Deep Delight: Features that solve both functional needs and emotional motivators She emphasizes that the most successful products prioritize deep delight features, which create lasting emotional connections while solving real problems. Detecting Opportunities Through User Journey Mapping "I use customer journey maps... One of the elements is feelings... If you do the exercise very well and put the feeling element into your journey map, you can draw a line showing peak moments and valley moments - these are pivotal moments for connecting with users at the emotional level." Nesrine advocates for using customer journey maps to identify emotional highs and lows throughout the user experience. By focusing on these "pivotal moments," teams can find opportunities to amplify positive emotions or transform negative ones into delightful experiences. She encourages teams to celebrate positive emotional peaks with users and find ways to turn valleys into more positive experiences. Real-World Example: Restaurant QR Code Payment "The waiter came with a note, and on the note, there is a QR code... What a relief that experience was! I've been very, very surprised, and they turned that moment of frustration and fear into something super fun." Nesrine shares a delightful dining experience where a restaurant transformed the typically frustrating moment of splitting the bill by providing a QR code that led to an app where diners could easily select what they ordered and pay individually. This example illustrates how identifying emotional pain points (bill-splitting anxiety) and addressing them can turn a negative experience into a memorable, delightful one that creates loyal customers. Creating a Culture of Delight Across Teams "It's very important to have the same language. If the marketing team believes in emotional connection, and the designer believes in emotional connection, and then suddenly engineers and PMs don't even know what you're talking about, that creates a gap." For delight to become central to product development, Nesrine emphasizes the importance of creating a shared language and understanding across all teams. This shared vision ensures everyone from designers to engineers is aligned on the goal of creating emotionally connected experiences, allowing for better collaboration and more cohesive product development. Recommended Reading Nesrine refers us to Emotional Design by Don Norman Designing for emotion, by Aaron Walter And Dan Olsen's The Lean Product Playbook About Nesrine Changuel Nesrine Changuel is a product leader, coach, and author with over a decade of experience at Skype, Spotify, Google Meet, and Chrome. She specializes in designing emotionally connected, delightful products. Her book, Delight, introduces a framework for creating lovable tech experiences that drive user loyalty and differentiation. You can link with Nesrine Changuel on LinkedIn and follow Nesrine's website.

Carmen Jurado: Beyond the Backlog—How Great Product Owners Embrace Team Collaboration The Great Product Owner: Standing with the Team  Carmen shares that the best Product Owners she's encountered are those who stand with their teams. Drawing from her own recent experience as a Product Owner, she emphasizes the importance of being there for your team, recognizing that they make you look good. Great Product Owners understand that achievements are team efforts, not individual accomplishments. Carmen also highlights that exemplary Product Owners have a deep understanding of the goals, values, and principles of Agile methodologies, allowing them to better support their teams and leverage agile practices effectively. In this segment we refer to the book Generative AI in a Nutshell. The Bad Product Owner: The Novice Who Does Everything Carmen describes a common anti-pattern she encountered: the inexperienced Product Owner who attempts to handle everything independently. This particular PO was preparing reviews and planning sessions alone, feeling that these events wouldn't happen otherwise. The team wasn't engaged, and the backlog had ballooned to over 300 items. Carmen helped this PO sort through the backlog to start with a clean slate and conducted a stakeholder mapping session to manage difficult stakeholders, particularly a CFO who was treating the PO as merely a scribe. They also worked to involve the team in Scrum events, reducing the burden on the PO. Carmen emphasizes the importance of keeping the team updated on process changes and the value of having a PO who can openly discuss their challenges. Self-reflection Question: As a Scrum Master, how can you help both experienced and novice Product Owners find the right balance between taking ownership and enabling team participation? [Scrum Master Toolbox Podcast Recommends]

In this episode of the Scrum.org Community Podcast – Value Delivered Series, host Dave West is joined by Carmit Ophir, Senior Director at StoreDot, and Professional Scrum Trainer Michal Epstein to explore how StoreDot leveraged Professional Scrum to tackle the complex challenges of developing ultra-fast-charging batteries for electric vehicles.Faced with low collaboration and siloed teams of chemists, engineers, and system experts, StoreDot turned to Scrum to foster transparency, cross-functional teamwork, and faster feedback loops. The results? Accelerated innovation, milestones delivered ahead of schedule, and a cultural shift driven by leadership support and a commitment to continuous improvement.Whether you're navigating R&D in a highly technical space or looking to drive transformation in your organization, this conversation is full of insights and practical advice. Key Takeaways:Why R&D teams can embrace agilityThe importance of leadership support in Scrum adoptionHow a culture of feedback and experimentation accelerates value delivery Tune in to hear how StoreDot is literally charging ahead with Scrum.

In dieser Folge sprechen wir mit Ulrich Voigt und Alexander Odendahl von der Sparkasse KölnBonn über ein Thema, das strategisch kaum relevanter sein könnte: Künstliche Intelligenz im Banking. Uli Vogt ist Vorstandsvorsitzender der Sparkasse KölnBonn und einer der Treiber für Zukunftsthemen innerhalb der Sparkassen-Finanzgruppe. Alexander Odendahl verantwortet als Product Owner den Bereich generative KI und bringt langjährige Erfahrung aus Data Analytics und digitaler Innovation mit. Gemeinsam geben sie einen offenen Einblick: Wie erste Prototypen zu konkreten Projekten wurden Warum KI nur dann funktioniert, wenn auch Veränderung mitgedacht wird Wieso sie sich für einen kollaborativen KI-Ansatz entschieden haben Und welche Rolle der „Führerschein für KI“ im Unternehmen spielt Wir sprechen über reale Use Cases – von smarter Dokumentenerkennung über Mehrsprachigkeit bis hin zur Einbindung in bestehende Prozesse. Außerdem geht's um Zusammenarbeit mit der FI, Austausch mit Hochschulen und warum der Mensch trotz KI weiter im Zentrum bleibt. Zum Abschluss teilen die beiden, was sie persönlich an KI fasziniert – und warum bei ihnen Leuchti und Doki nicht im Kindergarten, sondern in der IT arbeiten. Viel Spaß beim Hören! Viel Spaß beim Hören! Fragen, Anregungen und Feedback sehr gerne an mail@plaudertaschen-podcast.de Euer Plaudertaschen-Team Dieser Podcast wird präsentiert von: => S Broker AG & Co. KG - Innovative und bedarfsorientierte Lösungen „as a Service“ für das Wertpapiergeschäft der Sparkassen. => GuideCom AG - Unsere Heimat ist die Sparkassen-Finanzgruppe, denn seit mehr als 20 Jahren dürfen wir nahezu alle Sparkassen und Verbundpartner als Digitalisierungsexperte begleiten. Mit der GuideCom Sales & Service Cloud bieten wir den Finanzinstituten eine integrierte, datengetriebene Plattform für den Firmenkundenvertrieb. Durch einen starken Fokus auf Kundenzentrierung, Kollaboration und Automatisierung ist sie die Grundlage für eine zukunftsorientierte, erfolgreiche Zusammenarbeit. => Sparkassen Consulting GmbH - Wir. Beraten. Sparkassen. Folge direkt herunterladen

Chris Sims: The Empathy Advantage, How Great POs Connect Teams with Users 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: Deep Market Knowledge Creates Team Empathy Brad exemplifies a truly effective Product Owner through his exceptional understanding of end users and customers in the investment management space. What sets Brad apart is not just his deep domain knowledge, but his established relationships with gatekeepers at customer organizations. These connections provide valuable insights that inform product decisions. Most importantly, Brad regularly spends time with the development team, helping them empathize with stakeholders and understand the real-world impact of their work. His user stories consistently focus on actual users and why the requested features matter, creating clear context for developers and fostering meaningful connections between technical work and business outcomes. The Bad Product Owner: The Disempowered Proxy Problem Chris identifies a common anti-pattern: the disempowered proxy Product Owner. This situation occurs when someone performs the day-to-day PO responsibilities for the team, but lacks true authority to make decisions. Instead, an unseen "real PO" holds ultimate control and can swoop in at any time to change priorities or requirements. This arrangement quickly erodes team trust as they realize the proxy must continually defer decisions, creating delays and uncertainty. Chris suggests either empowering the proxy with more decision-making authority while keeping stakeholders appropriately involved, or having the higher-level PO commit to spending sufficient time with the team to fulfill the true Product Owner role themselves. Self-reflection Question: How might you identify and address power imbalances in the Product Owner role within your organization? [Scrum Master Toolbox Podcast Recommends]

Chris Sims: Middle Management, The Forgotten Layer in Agile Transformations 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. Chris Sims recounts his experience with a rapidly growing startup that decided to adopt Scrum to address slowing delivery. When a VP championed the initiative, Chris provided training that generated excitement at the team level. However, they overlooked a critical component: the middle management layer. As teams embraced Scrum, they found themselves caught between multiple sources of direction—their direct managers, project managers, and newly established Product Owners with backlogs. This created confusion as middle managers, who weren't included in the transformation discussions, continued operating in their traditional ways. The result was teams appearing busy yet delivering slowly. Chris emphasizes the importance of considering how management roles evolve during agile transformations, deliberately redefining job descriptions, and helping managers find ways to bring value in the new structure rather than undermining it unintentionally. Self-reflection Question: In your organization's agile transformation, how are you addressing the needs and concerns of middle managers whose roles might be significantly impacted? [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: Hypothesis-Driven Product Ownership, The Experimental Mindset 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 Experimenter Richard describes great Product Owners as "experimenters" who understand that everything they do is a hypothesis requiring validation. The best POs establish feedback loops early, actively engage with users and clients, and approach product development with a scientific mindset. Richard shares an experience working with a "coaching PO" who excelled at involving everyone in defining what needed to be done.  This PO was inspiring and helped the team participate in both building and decision-making processes. Richard emphasizes that the relationship between PO and team must be a true partnership—not hierarchical—for success to occur. Great POs facilitate team involvement rather than dictating direction, creating an environment where collaborative problem-solving thrives. In this segment, we refer to the Role Expectation Matrix Retrospective, and the Product Owner Sprint Checklist, a hands-on coaching tool for anyone interested in helping PO's prepare and lead successful Sprints with their teams. The Bad Product Owner: The Tech Visionary Disconnected from Users Richard recounts working with a high-level sponsor, a medical doctor interested in technology, who hired multiple development teams (up to four Scrum teams) to build a product. While technically knowledgeable, this PO had very concrete ideas about both the technology and solution based on assumptions about client needs.  The team developed impressive technology, including a domain-specific language (DSL), and felt they were performing well—until they delivered to actual clients. Only then did they discover users couldn't effectively use the software, requiring a complete rethinking of the UX concept. This experience taught Richard the critical distinction between the customer (the sponsor/PO) and the actual end users, demonstrating how even technically sophisticated Product Owners can miss essential user needs without proper validation. Self-reflection Question: How might you help Product Owners in your organization balance their vision with the practical realities of user needs and feedback? [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: Contracting for Success,  Establishing Clear Agile Coaching Outcomes 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. Richard reflects on his evolution in defining success as a Scrum Master and Agile Coach. Initially, he believed that if his team was successful, he was successful—but soon realized this perspective was incomplete. Top management wanted tangible evidence of coaching impact, which became problematic without clearly defined metrics. Richard now advocates for establishing a coaching agreement at the beginning of any engagement, with both management and teams defining what success looks like for the coach. He emphasizes the importance of dual-sided accountability as a natural outcome of proper contracting, using metrics that matter to the organization such as flow metrics and outcome metrics to demonstrate coaching value. Self-reflection Question: How are you measuring your own success as a coach or Scrum Master, and have you created explicit agreements with both teams and management about what success looks like? Featured Retrospective Format for the Week: Solution Focused Retrospective Richard recommends the Solution Focused Retrospective from the book "Solution Focused Coaching for Agile Teams." While traditional retrospective formats from books like "Agile Retrospectives" typically open a topic and dig deeply into the problem space, the solution-focused approach suggests spending only a short time discussing problems before pivoting to designing the desired future state. This format focuses on identifying the next step and emphasizing what positive outcomes the team wants to achieve, rather than dwelling on what's wrong. Richard values this approach for its ability to maintain a positive, forward-thinking mindset within teams. [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: When Individual Performance Metrics Block Agile Transformation 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. Richard shares an experience of implementing Agile methods in a large organization that initially showed promising signs with management "pull" for change. The transformation began well with cross-functional teams created through self-selection workshops. However, unexpected resistance emerged during the kick-off day, particularly from a line manager and his team. When investigating the source of this resistance, Richard discovered that the company's bonus structure was tied to individual performance metrics, fundamentally conflicting with Agile's team-oriented approach.  This insight led to developing a pilot for a team-focused performance management system. After three months, the team held a retrospective with all stakeholders, where management demonstrated remarkable leadership by empowering teams to redesign their structure when the initial setup wasn't working. This flexibility allowed even the most vocal critics to become part of the solution. Self-reflection Question: In what ways might your organization's reward structures be unintentionally blocking successful Agile adoption? [Scrum Master Toolbox Podcast Recommends]

Scrum Fails When Product Owners Think They Are The BossI'm afraid that everyone interprets it differently, and that's the source of problems. For me, the word owner is misleading. As a Product Owner, you own nothing, though you may think you do.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/

Richard Brenner: How Small Signs of Cynicism Can Destroy Agile Team Cohesion 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. Richard shares a powerful story about how team dysfunction often starts with small steps. During a joint retrospective with three agile teams, Richard witnessed a moment where a team member made a cynical comment toward a manager who was attempting to participate. This revealed a damaged relationship between management and the team, creating tension that Richard initially chose to ignore. Looking back, he would now immediately address such comments and tackle the "elephant in the room." Richard explains how seemingly minor behaviors like cynicism or passive-destructive actions (such as consistently being late to stand-ups) can significantly impact team health. He recommends establishing conflict resolution protocols early and using impact feedback without judgment to address these issues before they escalate. In this segment, we refer to Lysa Adkins' conflict resolution protocol.  Self-reflection Question: What small signs of dysfunction might you be overlooking in your team that could develop into larger problems? Featured Book of the Week: Solution Focused Coaching for Agile Teams Richard recommends "Solution Focused Coaching for Agile Teams" by Ralph and Veronika. This book describes the solution-focused approach to many common situations that Agile coaches face in their work. Richard values this resource for its practical guidance on addressing challenges through a positive, solution-oriented perspective rather than dwelling on problems. [Scrum Master Toolbox Podcast Recommends]

Richard Brenner: Skipping the Vision, How Not to Introduce Kanban 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. Richard shares an important learning experience from introducing Kanban to teams using a top-down approach. Without clearly articulating why the change was needed, team members questioned what they were doing wrong that necessitated change. Richard found himself unable to connect the organizational vision to the methodology shift, leading to resistance. He emphasizes the importance of first understanding the problem before applying Scrum or Kanban, defining what success looks like, and involving people early in the change process. Richard also recommends thorough contracting with client organizations to assess their current state and understand who is trying to change what, and why. In this episode, we refer to Kotter's book Leading Change. Self-reflection Question: How might your change initiatives be improved by spending more time defining the "why" before introducing new methodologies? [Scrum Master Toolbox Podcast Recommends]

Product Owners vs. Product Managers vs. Project ManagersWhile you are knee-deep looking for your next role, I've seen endless variations of “product” roles. Specifically, the terms Product Owner (PO), Product Manager (PM), and Project Manager (PjM) seem to be used interchangeably, or even used to describe the same person. Yet, some teams have all three within each individual squad.So, what's the difference between these three roles? And why do we need all three in the first place?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/

BONUS: Keeping Backlogs Lean With The Now-Next-Later-Never Roadmap Framework with Kent McDonald In this BONUS episode, we explore the art of backlog management with product management expert Kent McDonald. As someone with decades of experience in software product development, Kent shares practical strategies for keeping backlogs lean, meaningful, and focused on outcomes that truly matter. Learn how to escape the trap of bloated backlogs and implement a Now-Next-Later-Never approach that will transform your product management practice. The Problem with Bloated Backlogs "Some teams use backlogs as 'long term storage' devices." Product backlogs often become unwieldy and difficult to manage because teams view them as a permanent repository for every idea that comes along. Kent explains that this "storage mentality" is one of the primary reasons backlogs grow out of control. Another common mistake is diving in too early and splitting items before they're actually ready to be worked on, which multiplies the backlog size unnecessarily. These practices lead to confusion, lost focus, and ultimately decrease a team's ability to deliver value efficiently. The Now-Next-Later-Never Roadmap Framework "You want to group things together on roughly categories of when you will attack it." Kent walks us through the practical implementation of a Now-Next-Later-Never roadmap approach that keeps things manageable. This framework provides a simple but powerful way to organize initiatives based on their priority and timing. Instead of maintaining an endless list of requirements, teams can group work into these four buckets, making it easier to communicate priorities both internally and with stakeholders. Kent emphasizes that these roadmap items should be described in terms of outcomes rather than features, helping everyone stay focused on the value being delivered rather than specific implementations. For more on the origin of the Now-Next-Later roadmap practice, see this article by Janna Bastow. Making "Now" Work in Practice "We only split items in the 'now' column." When implementing the Now-Next-Later-Never approach, the "Now" column is where the magic happens. Kent advises: Only split items that are in the "Now" column into actionable tasks Express roadmap items in terms of outcomes or customer problems to solve Limit the number of items in the "Now" column to maintain focus List outcomes rather than detailed features to avoid having a large number of items Kent explains that the "Later" and "Never" columns serve an important purpose in setting expectations with stakeholders about what won't be worked on immediately or at all. Managing the Movement Between Roadmap Categories "Items can move back and forth, to facilitate expectation setting." The Now-Next-Later-Never roadmap isn't static. Kent provides practical advice on how to manage the flow of items between categories: Revisit the roadmap regularly, ideally monthly Consider reviewing the roadmap during sprint review sessions Use this format when communicating with stakeholders for clearer expectation setting Hold strong on the "Now" items to maintain focus and avoid constant reprioritization This approach creates a dynamic but controlled environment where priorities can evolve without creating chaos or confusion. Dealing with Backlog Bloat "Create a 'museum', a set of items you can look at, but don't look at every day." For teams struggling with already-bloated backlogs, Kent offers bold but effective advice: Create a "museum" for items you want to preserve but don't need to see daily Consider deleting your old backlog and starting fresh Begin by asking: "What are the main outcomes we're trying to achieve?" Focus on getting to a smaller set of bigger items, then sequence them appropriately These approaches help teams overcome the fear of "losing" work while refocusing on what truly matters. Maintaining a Lean Backlog "Backlog items don't age well." Kent's team maintains an impressively lean backlog of just 23 items across three brand websites. He shares the routines and guardrails that prevent backlog bloat from creeping back in: Create a filter to control what gets into the backlog in the first place Keep the Product Owner just slightly ahead of the development team Avoid the anti-pattern of trying to keep all developers busy all the time Remember that backlog items don't age well and lose relevance over time These practices ensure the team stays focused on delivering current value rather than managing an ever-growing list of aging requirements. About Kent McDonald With decades in software product development, Kent is a go-to expert in product management, and agile strategy. He is a seasoned consultant and author of three books on agility, he helps teams cut through clutter to focus on what truly matters. When not optimizing workflows, he's exploring National Parks (52/63) or grooving to some jazz tunes. You can link with Kent McDonald on LinkedIn, or follow Kent McDonaldn on Substack.

Zvonimir Durcevic: How Feedback Transforms Product Owners 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: Embracing Feedback and Adapting Over Time  Zvonimir shares his experience with a Product Owner who demonstrated exceptional growth over a two-year period. What made this PO stand out was their willingness to receive feedback from the team and adjust their behavior accordingly. When the team expressed difficulty accessing the PO for questions and early feedback, the PO responded by rearranging their schedule to sit near the team part-time. Zvone emphasizes how these incremental changes, driven by openness to feedback, transformed this person into an exemplary Product Owner. The key insight: great Product Owners honor past practices while embracing necessary changes for the future. Self-reflection Question: How might your willingness (or reluctance) to accept feedback be affecting your development as a Product Owner? The Bad Product Owner: The Reluctant Subject Matter Expert In this segment, Zvonimir describes working with a Subject Matter Expert who was assigned the Product Owner role despite not wanting the responsibility. While this person excelled at documenting requirements from their extensive knowledge, they resisted taking on core PO duties. The organization assigned them the role but didn't push for proper adoption of responsibilities. Consequently, the team and Scrum Master were forced to assume PO duties to fill the gap. Although this arrangement functioned temporarily thanks to the team's capabilities and the SME's knowledge, it created an unsustainable situation where role accountability was unclear. [Scrum Master Toolbox Podcast Recommends]

Our guest on this episode of Data Driven Finance is Gretchen Rodriguez, Head of Product for Payments at TD Bank. She approaches products with an entrepreneur's mindset and has designed and launched products in fintech, e-commerce, cybersecurity, and identity & trust. Gretchen spent time as Product Owner at eBay, serves on a couple of boards, and is a product adviser to Med Fem Wellness. We talk about emerging payments and the ecosystems that support it. Topics covered include: The way we pay for products and services is changing. Consumer behaviors around how they make and want to make online payments. The ideal end game for payments from a consumer's point of view. The obstacles still in the way of seamless, superior payment systems. How can we accomplish the interconnectivity required for improved payment experiences? The opportunities open banking offers for opening and funding accounts. Additional benefits of connectivity for business account holders. The payment enhancements that are being explored today. A warning for the banks allowing themselves to fall behind.

We're excited to welcome Oeystein Kjoersvik to AI Uncovered. Oeystein leads the Generative AI program within the Quality Assurance team at Merck, where he focuses on developing AI tools and applying a quality-first approach to ensure safe, effective use of AI in GxP-regulated environments.In this episode, Tim and Oeystein delve into the challenges of adopting AI in regulated settings, the complexity of validating GenAI tools, and the transition from traditional processes to AI-augmented systems. They also explore Oeystein's work with the IMPALA Consortium and the importance of cross-industry collaboration to identify and scale high-value use cases for Generative AI.Before his current role, Oeystein served as a Product Owner in Analytics at Merck IT, building analytics platforms and integrating data science across systems. He also contributed as a Machine Learning Subject Matter Expert to TransCelerate's Intelligent Automation Group, advancing AI applications in pharmacovigilance.Oeystein brings a rare blend of technical expertise and regulatory insight. He's passionate about helping teams adopt AI responsibly and transparently—ensuring innovation aligns with quality across the pharmaceutical landscape.Welcome to AI Uncovered, a podcast for technology enthusiasts that explores the intersection of generative AI, machine learning, and innovation across regulated industries. With the AI software market projected to reach $14 trillion by 2030, each episode features compelling conversations with an innovator exploring the impact of generative AI, LLMs, and other rapidly evolving technologies across their organization. Hosted by Executive VP of Product at Yseop, Tim Martin leads a global team and uses his expertise to manage the wonderful world of product.

Marina Lazovic: Leadership Skills Make the Difference for Product Owners 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 PO as a Leader Marina identifies that while product skills are important, it's leadership abilities that truly distinguish exceptional Product Owners. Great POs demonstrate strong empathy and lead by example, creating an environment where the team feels supported. Marina emphasizes the importance of availability – outstanding Product Owners make themselves accessible to their teams when needed, establishing a presence that goes beyond just attending ceremonies. This leadership through presence and support fosters trust, enabling teams to approach challenges with confidence knowing their PO has their back. The Bad Product Owner: The PO Who Did Not Understand Their Team Marina describes a problematic pattern where Product Owners fail to understand their team's strengths and weaknesses. These POs lack awareness of team composition – not recognizing the balance between senior and junior members or understanding their specific challenges. This blindness leads to unrealistic expectations about what the team can accomplish in a sprint. Marina suggests addressing this by establishing regular sync meetings with the PO to discuss team dynamics and challenges. By helping Product Owners understand team composition, Scrum Masters can bridge this knowledge gap and foster more realistic planning and expectations. Self-reflection Question: How might you help a Product Owner better understand the unique composition and capabilities of your team without creating an adversarial dynamic? About Marina Lazovic Marina is a Scrum Master and Kanban Trainer from Belgrade, Serbia, with nearly a decade in the IT industry. Though not from a technical background, she is passionate about helping development teams and organizations optimize processes and build great products using Agile. She thrives on driving efficiency and fostering collaboration. You can link with Marina Lazovic on LinkedIn.

How do we build trustworthy AI systems? What steps can organizations take to protect AI from attacks? And what role do we play in shaping a secure AI future?As AI becomes more advanced, it raises an important question—can we truly trust AI agents to act responsibly? Digital trust is essential to ensuring AI systems are accurate, ethical, transparent, secure, and accountable. But as AI evolves, so do the risks.In this episode of the FIT4PRIVACY Podcast, host Punit Bhatia speaks with Rani Kumar Rajah, founder of Secura.AI, about the growing challenges of AI security and governance. They discuss the new risks AI agents bring, such as data breaches, model theft, model poisoning, and the ability of AI to remember sensitive data—threats that go beyond traditional cybersecurity concerns.Securing AI requires a holistic approach, including strong risk management, security measures, compliance strategies, and asset protection. But AI safety isn't just a responsibility for businesses—individuals must also increase their AI awareness to understand both the opportunities and risks that AI presents.Tune in now to Episode 135 of FIT4Privacy Podcast and learn how to build digital trust in AI!

In this episode of the Scrum.org Community Podcast, Dave West and PST Andy Brandt explore the state of Agile transformations and the shift toward the Agile Product Operating Model (APOM) as featured in their recently written whitepaper. While Agile has been widely adopted, challenges like misalignment between business strategy and technical execution persist. Andy shares how focusing on products instead of work and starting small with one team can drive meaningful change. They discuss the role of AI in enhancing productivity, the importance of organizational alignment, and how executive commitment can lead to spectacular results. Tune in to learn how to move beyond Agile transformations and embrace a product-first mindset!Referenced whitepaper: Moving Beyond Agile Transformations: Leveraging the Agile Product Operating Model

Marina Lazovic: How to Introduce Data-driven Decision Making to Skeptical 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. Marina describes her experience introducing data-driven decision making to help teams improve their processes. Starting with basic metrics like velocity, she gradually expanded to more sophisticated data points such as how long items remain in specific workflow states. She emphasizes the importance of introducing these concepts naturally into daily work and using the data to spark meaningful conversations with both the team and Product Owner. By examining why items were stuck and for how long, the team uncovered underlying issues they could address. Marina also explains how she used historical data to inform sprint planning, making estimates more realistic. Her approach focused on simplicity—introducing one data point at a time, avoiding jargon, encouraging teams to discover problems themselves, and empowering them to develop their own solutions rather than imposing answers. Self-reflection Question: What single data point could you start tracking that might reveal the most important improvement opportunity for your team? About Marina Lazovic Marina is a Scrum Master and Kanban Trainer from Belgrade, Serbia, with nearly a decade in the IT industry. Though not from a technical background, she is passionate about helping development teams and organizations optimize processes and build great products using Agile. She thrives on driving efficiency and fostering collaboration. You can link with Marina Lazovic on LinkedIn.

Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel are listening and reacting to Melissa Perri on Lenny's Podcast as she makes claims about product management, agile, frameworks, and why most companies struggle with product management. We discuss many of her claims, including:Product Management has nothing to do with the Manifesto for Agile Software DevelopmentScrum is only for Large OrganizationsLarge Organizations Lack Infrastructure to support Product ManagementRigid Processes Can Crash Your Entire Company...and many, many more!Whether you're in a startup or enterprise, Silicon Valley or your average FinTech, this discussion offers practical insights on balancing process with customer-centricity.#ProductManagement #AgileLeadership #TeamDevelopmentTags: product management, agile coaching, scrum, kanban, product strategy, team development, organizational design, product owner, product manager, safe framework, agile transformation, continuous delivery, silicon valley, enterprise agileReferences:Lenny's Podcast with Melissa Perri, https://youtu.be/wbi9chsAHp4Marteen Dalmijn's newsletter about Waternet: https://mdalmijn.com/p/how-a-digital-transformation-canAA199 - W. Edwards Deming's Profound Knowledge for Transforming OrganizationsAA187 - The Future of AI, According to Big Tech= = = = = = = = = = = =YouTubehttps://youtu.be/c0htPyVTKeESubscribe on YouTubehttps://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1Applehttps://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotifyhttps://open.spotify.com/show/362QvYORmtZRKAeTAE57v3= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Marina Lazovic: How Limiting Work-in-Progress Saved a Struggling Agile Team 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. Marina shares the story of a small team of three developers who were struggling with multiple challenges. The team was primarily working on front-end fixes but faced persistent environment issues that kept breaking their work. Under pressure from a Product Owner pushing for delivery, the team fell into the trap of working on too many things simultaneously, resulting in items staying perpetually "in progress" and never reaching "done." As the situation deteriorated, the PO began micromanaging the team in attempts to unblock work. Marina explains how she helped the team understand the value of limiting work-in-progress (WIP), even when initially both developers and the PO were resistant to the idea. Through experimentation over several sprints, they discovered that limiting WIP actually increased their completion rate rather than reducing it. Self-reflection Question: What work-in-progress limits might benefit your current team, and how could you experiment with implementing them in a way that addresses stakeholder concerns? Featured Book of the Week: The Five Dysfunctions of a Team Marina recommends "The Five Dysfunctions of a Team" as an essential read for Scrum Masters. She describes it as a book filled with valuable lessons and examples that she could easily identify in her workplace. Marina finds particular value in sharing the concepts with her teams and using the book as a framework to discuss dysfunction patterns they might be experiencing. The practical examples provided in the book serve as excellent conversation starters to help teams recognize and address their own challenges. About Marina Lazovic Marina is a Scrum Master and Kanban Trainer from Belgrade, Serbia, with nearly a decade in the IT industry. Though not from a technical background, she is passionate about helping development teams and organizations optimize processes and build great products using Agile. She thrives on driving efficiency and fostering collaboration. You can link with Marina Lazovic on LinkedIn.

Karen Suarez: Decision Authority, The Make-or-Break Factor for Product Owners 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: Clear Vision That Inspires Action Karen describes an exemplary Product Owner who deeply understood both their product and market. This PO maintained a perfect balance of being firm in their vision while remaining open and curious to input. What made this PO particularly effective was their ability to communicate a clear, compelling vision that motivated the team. They defined key results in ways that were easily understood and actionable for team members. Most importantly, they trusted the development team with solution design rather than prescribing how features should be implemented, creating an environment where the team felt both guided and empowered. The Bad Product Owner: Committee Decisions and Never-Ending Backlogs Karen identifies two common anti-patterns in the Product Owner role. The first is when the PO isn't truly empowered to make decisions because the company hesitates to give this responsibility to a single person. In these cases, the PO becomes merely a proxy for a committee, with solutions predetermined elsewhere. The second anti-pattern is the PO who cannot say "no," allowing backlogs to grow unmanageably large. Karen once worked with a team that had accumulated 5,000 backlog items! Her solution was to use data to demonstrate why such expansive backlogs are counterproductive, create filtered views showing only the highest-priority items, and eventually make it acceptable to delete irrelevant backlog items altogether. Self-reflection Question: In your organization, does the Product Owner have true decision-making authority, or are they operating as a proxy for committee decisions? About Karen Suarez  Karen is a dedicated Scrum Master with a long experience driving agile transformations and fostering high-performing teams. She is passionate about continuous learning, and excels in aligning agile practices with organizational innovation. You can link with Karen Suarez on LinkedIn.

Każdy i każda z nas styka się z produktami. I każdy produkt jest w jakiś sposób zaprojektowany. Kto to robi i na czym polega ta rola? O różnicy w pracy właściciela produktu (Product Owner), menedżera produktu (Product Manager) oraz kierownika projektu (Project Manager) rozmawiam z Natalią Cholewą. Ciekawie było usłyszeć o jasnych stronach tej pracy, ale też o wyzwaniach. Natalia wspiera właścicieli produktów. Otwarcie rozmawialiśmy o tym jak to jest pracować nad produktem. Zapraszam do słuchania i rozmowy! Gościni Natalia Cholewa – mama, żona, córka, przyjaciółka, zawodowo jest produktowcem.Top 5: Osiąganie, Ukierunkowanie, Dyscyplina, Bezstronność, BliskośćInstagram Intencjonalny newsletter Co tydzień wysyłam list, w którym zapraszam do rozmowy i zadania sobie ważnych pytań. Linki Streszczenie Kim jest Product Owner? Dominik: Zacznijmy od podstaw – jak myślisz o poszczególnych rolach? Natalia: W Polsce są one trochę wypaczone. W ogłoszeniach o pracę zamiennie stosuje się nazwy Product Owner, Analityk Biznesowy, a nawet Product Manager. Wszystkie te role zajmują się zaspokajaniem potrzeb biznesowych, jakkolwiek by one nie były zdefiniowane. Analityk Biznesowy jest bliżej zespołu niż Product Owner – jeśli obie te role funkcjonują w firmie. Product Owner decyduje o kierunkach rozwoju produktu. Product Manager to osoba, która stawia rozwój produktu na pierwszym miejscu – wyznacza […] The post #259 Czy każdy produkt ma osobę, która się nim opiekuje? Rozmowa z Natalią Cholewą. appeared first on Near-Perfect Performance.

Karen Suarez: When a Scrum Master Needs to Hire a Manager, An Organizational Design Story 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. Karen shares her experience as the first Scrum Master in a company where development, QA, product, and deployment were all separate departments, resulting in a cycle time exceeding six weeks. She strategically approached transformation by first identifying interested individuals in other departments who were already collaborating with the development team. Karen formalized the Product Owner role by cultivating a relationship with someone from the product department who showed interest in working closely with the team. She created regular collaboration routines between QA and development, and gradually involved the deployment team by inviting them to demos and having developers learn deployment skills. When faced with trust issues between deployment and development teams, Karen recognized the need for leadership support and built a case for hiring a manager who could help bridge these departments, acknowledging that some organizational challenges require sponsorship beyond the Scrum Master role. Self-reflection Question: In your organization, what departmental silos might be increasing cycle time, and who could be your allies in breaking down these barriers? About Karen Suarez  Karen is a dedicated Scrum Master with a long experience driving agile transformations and fostering high-performing teams. She is passionate about continuous learning, and excels in aligning agile practices with organizational innovation. You can link with Karen Suarez on LinkedIn.

Ever left a meeting feeling more drained than before it started? That’s the dreaded meeting hangover. Brian Milner and Julie Chickering dive into why bad meetings have lasting effects—and what facilitators AND participants can do to make them better. Overview Bad meetings don’t just waste time, they drain energy, morale, and engagement long after they’re over. In this episode of the Agile Mentors Podcast, Brian and Julie Chickering unpack the concept of "meeting hangovers"—the lingering negative effects of ineffective meetings. They explore why bad meetings happen, the shared responsibility of facilitators and participants, and practical strategies for turning the tide. From fostering accountability to knowing when to walk it off, this conversation will help you rethink how meetings impact team dynamics and productivity. References and resources mentioned in the show: Julie Chickering #137 Stop Wasting Time with Guests Kate Megaw HBR The Hidden Toll of Meeting Hangovers by Brent N. Reed, et al. When: The Scientific Secrets of Perfect Timing by Daniel H. Pink Remotely Productive by Alex Pukinskis Working on a Scrum Team Class Subscribe to the Agile Mentors Podcast Want to get involved? This show is designed for you, and we’d love your input. Enjoyed what you heard today? Please leave a rating and a review. It really helps, and we read every single one. Got an Agile subject you’d like us to discuss or a question that needs an answer? Share your thoughts with us at podcast@mountaingoatsoftware.com This episode’s presenters are: Brian Milner is SVP of coaching and training at Mountain Goat Software. He's passionate about making a difference in people's day-to-day work, influenced by his own experience of transitioning to Scrum and seeing improvements in work/life balance, honesty, respect, and the quality of work. Julie Chickering is the brains and brawn behind JC Agile Consulting, believes that Lean and Agile practices are packed with potential — to enable positive culture change, business agility, and breakthrough results. Julie is a past president and board member of the Agile Project Management Network (APLN), a Certified Scrum Trainer (CST), PMI Agile Certified Practitioner (PMI-ACP), as well as a traditional Project Management Professional (PMP). Auto-generated Transcript: Brian Milner (00:00) Welcome back Agile Mentors. We're here for another episode of Agile Mentors podcast. I'm with you as always Brian Milner and haven't got to say this for a while. So I'm happy to say again, welcome back to the show, the fabulous Julie Chickering. Welcome back, Julie. Julie (00:15) Thanks, Brian. Glad to be here. Brian Milner (00:17) Yeah, very excited to have Julie back. Julie is a friend of the show. We've had her on multiple times and it's been too long. We just need to have you on more often again. So thank you for making the time and coming back. We wanted to have Julie on sort of as a little bit of a continuation from our last episode that we had with Kate McGaw. You we talked a little bit about facilitation there and there was a lot that we talked about initially to set that up to talk about Julie (00:30) Sure. Brian Milner (00:44) just the fact that there's an epidemic of bad meetings. There's kind of a harmful thing happening where it's extremely prevalent that meetings are going poorly. There's not a lot of attention that's given to this. There's not a lot of focus in a lot of organizations because it's such a prevalent issue. of our meetings being so bad. And Julie pointed out to me this Harvard Business Review article that sort of became a touchstone, I think, for what we wanted to talk about. It's called the hidden toll of meeting hangovers. And we'll link to this in the show notes. But the idea behind the article was just to say, they quoted a stat early on saying that they did a study and found that more than a quarter, 28 % of meetings left employees with lingering negative effects, such as impaired engagement and productivity. And so that's what they were referring to this sort of this meeting hangover, that bad meetings take a toll beyond just the lost time in the meeting. And that's kind of what we were talking about more with Kate is, you know, yeah, we want to make our meetings better, but there is sort of this ongoing lingering that, you know, from my reading of this and what I've experienced, kind of compounds, you know? One bad meeting then can lead to another bad meeting and another one and that feeling of anxiety and disconnectedness and like I said here, impaired engagement and productivity, those kind of grow and get worse and worse the longer that you have these bad meetings. So Julie, I'll just start with you and say, you know, when you read this article, what was it? What was it that really stood out to you, that jumped out to you, that made you think this was an important kind of area of focus? Julie (02:27) First of all, I love the title because I can relate to it. So when you're having a hangover, you just feel terrible, right? And this person that they talk about first, Jacob, about like, he was so frustrated when he left the meeting. So the introductory story when he was so frustrated when he left the meeting, he canceled his one-on-one right after because he knew he couldn't concentrate. And then he was just like so upset. for the rest of the day and talking about how he just didn't even want to work on the project anymore. So just this, I just got this physical sensation reading this around how it feels when you're in a meeting that's ineffective. And we've all been there and I could just like feel it in my body when I read this story. And I also feel like once you know what I, what an ineffective meeting feels like, the ineffective one is more noticeable and draining. yeah, so and then this this lingering effect of morale and just wasted, just wasted opportunity. And it feels like Brian Milner (03:32) Yeah. Yeah. Julie (03:47) in the corporate world, this is the norm. That we just have meeting after meeting after meeting that's just sucking the life force out of everyone. And then we wonder why nothing gets done. Brian Milner (04:00) Yeah, I mean, this article is packed with statistics and it's tempting for me to just kind of read them all off to you. I'm not going to do that. But there's a couple of things that kind of jump out to me. they talk about how around half of people have this feeling of that as a result of the hangover from the meeting, that they have negative or harmful impacts on their interactions with coworkers. They feel more disconnected from their team. and they want to spend more time alone based on the fact that, I went through this really kind of, there's no other way to say it, traumatic experience of having this really harmful, bad meeting. they connect the dots by saying, people will leave these meetings and oftentimes they will then go commiserate with coworkers and say, share their frustrations, which is helpful, it's good. But it also, you know, they noted here, this can kind of spread some feeling of negativity or hopelessness, you know, that it's always going to be this way. You know, yeah, I had a meeting like that as well. Boy, I guess this place is doomed. It's always going to feel like this. And so they have this kind of ongoing, as I said, compounding almost nature of it that one bad thing leads to another leads to another leads to another. And pretty soon you've got this really harmful, negative work environment and it's not necessarily something that's just happened. It's just the repetition of going through those things lead to this ongoing negative psychological impact in the organization. Julie (05:28) Yeah, I'm just smiling because I can just think of some meetings that I used to have a leader that would always show up late. Always show up late. We'd be halfway through the topic and then he would show up and we'd have to stop what we were doing and go circle back and just speed and you could just feel. the whole mood of the meeting change. We were actually making progress and we have to stop and we have to go all the way over. And this is constant. So what we would do afterwards is then have meetings after the meetings to complain about the leader doing that. The more adult thing would have been of course to say to the leader, when you do this, Brian Milner (06:15) Yeah. Julie (06:22) This is the outcome. Brian Milner (06:25) Yeah. So, so that's kind of, you know, what we want to talk about a little bit in here as well is, in the last episode, we, focused a lot on facilitation and the idea that, Hey, there's a lot of responsibility to the meeting organizer, whoever's facilitating this to not have it be this negative kind of environment. And I don't disagree with any of that, that we talked about in the last episode. I think there is a lot of that, that is true, but I think it's, it's. important for participants to not look at that as, it's all the facilitator then, right? I'm just a participant, I'm showing up and it's your job to get all this stuff out of me. And if the meeting goes poorly, that's entirely your fault. And I think it's important for us to recognize, no, if I'm a participant, if I accept that meeting invite and I'm here, I have a role to play. I have a contribution to be made and I can have, you Julie (07:14) Right. Brian Milner (07:19) as kind of Pollyanna-ish as it sounds, I can have a negative impact or a positive impact on this meeting. And I think that's an important kind of responsibility to take a hold of. Julie (07:25) you Yeah, I agree. And I think about that in a couple of ways. So actually, in both Scrum Master and Product Owner class, I remind them at the end of every meeting to ask two questions. The next time we have this kind of meeting, what would you want to do differently? But you gotta ask the question. And if you ask the question and nobody says anything, then they can't feel victim to a poorly run meeting. But you gotta be able to listen. You gotta be able to listen to it. Doesn't mean you have to say yes in the moment. It could be that you would follow up after, but just ask the question. What would you wanna do differently the next time we have this type of meeting And then ask them, what did they like? Brian Milner (07:48) Yeah. That's good. Julie (08:11) I used to do it the other way around. I don't know if I told you this story before or not, but do you remember Daniel Pink did the he was our keynote speaker at the Scrum Gathering, our conference a few years ago when he talked about. OK, when he talked about timing. OK, so something he said is like, yes, he said, as people, if there's two, if there's good news and bad news to always start with the bad news first. And end with the good news, because as people, we remember the last thing we talked about it. Brian Milner (08:20) Absolutely. Yeah. Yeah. Julie (08:40) So if I say to you, okay, the next time we have this type of meeting, what would you want to do differently? And nobody says anything. Okay. What did you like? And then they leave going, we actually got something done. Unless of course we didn't get anything done. Brian Milner (08:57) That's awesome. Yeah. I mean, I think about like how in classes, a lot of times when we talk about forecasting and estimation, you know, I make a little joke. It's not really a joke. It's the truth. But when I present, I've learned over the years when I present information to stakeholders about timings, I, know, if, if I do calculations and it says it's going to take between five and six sprints to do something, I've learned to say the maximum amount of time it will take is six sprints. there's a chance it could come in as soon as it's five sprints and yeah. Yeah. I mean, I learned to do that because what I say in classes, I've learned a lot of people stop listening after the first one. And I think actually though, I may be wrong. It may be more what you're saying that, you know, we, we remember the last thing that we hear. but it may be a combination, right? Cause if, if I hear the low number first and I I'm happy with that, I stopped listening and I don't want to hear the bad news. Julie (09:27) Brilliant! Brian Milner (09:50) So if I say the bad news first, it could take as long as this, but there's a chance it could come in earlier, then I'm leaving them with the good news that it could be this, you know, as soon as this, but they've set their expectation that, you know, it could take as long as, you know, the bad news that I gave them initially. So I don't know, maybe there's a combination of that there as well. But yeah, I agree with what Daniel Pink says about that. And timings do make a big, difference for sure. and how we present things. Julie (10:18) Okay, so a key though in that is that you can only ask those questions if you're staying within the time box and you've allocated time to actually ask the question. And like some of these things that came up as the root causes of like poor time management, like running over or stuff like that. If you're running over, nobody's going to really want to take the opportunity to give you feedback. So what do you think about, so what you talked with Kate a lot about when we talking about here is the role of the facilitator. And I think we should talk about what people can do if they are feeling like they're the victim of the lack of facilitation or poor facilitation. So what do think about that? Brian Milner (10:52) Yeah. Yeah. Yeah, I mean, I think we have several roles to play, right? I I agree. If I'm not the facilitator, then it's important for me to come into that meeting, well, knowing what the expectation is. know, like if I'm coming into a meeting as a participant, I don't think it's responsible. to show up to the meeting. And I've shown up to meetings like this, showing up with the attitude that, hey, it's not my meeting. It's the other person's meeting. You got me. I'm here. But now it's on you to get out of me, whatever it is that you're hoping to get. And maybe I put in very little prep work for it. So there is some kind of interplay here between the facilitator and the participant. Because you could say, well, that's the facilitator's responsibility to help you understand. Yes, it is. That's, this is what I'm trying to say is I, I think it's a mistake to shirk that responsibility entirely and say, I'm not the facilitator. Don't look at me. Right. If, if they didn't ask me to prepare or, or, you know, here's what I need you to, to, come prepared to talk about. Well, then I've got a bad facilitator and you know, we're just, we're hopelessly going to be in a bad meeting. No, when I get the invite, you know, Kate said last week, you know, Julie (12:17) Mm-hmm. Brian Milner (12:22) You can decline invitations to meetings. You don't have to accept every meeting invite that you get. But if you do accept it, I think that there's an accepting of responsibility there to say, all right, I'm going to be a participant in this meeting. What do you need from me? And in advance, making sure you talk to that meeting organizer and saying, hey, I agree. This is probably a good thing for us to meet about, but I want to prepare. I want to know that I can come to this meeting armed with information that's going to be helpful to others and I can play my part. So meeting facilitator, meeting organizer, what did you have in mind for me in this meeting? What is it that you were hoping to get from me in this meeting so that I can show up prepared? And that small little question, I think, does several things, right? mean, one, it says, to the facilitator, do you know what it is that you want from this person? If they come back at you and say, I don't know, I just thought maybe you needed, well, if they say, you know, we just thought maybe you needed to be in the loop or whatever, well, I might come back at that and say, that sounds like an email, you know? Julie (13:31) Yeah, I'm also thinking though there's the flip side of then people, there's two different things. I want to go back to how I can also help. what also struck me when you were saying that is that I think there's also this cultural part of am I being excluded? That, you know, that sense of They're not inviting me. A lot of times people don't need to be there. What you're afraid if you're not there, does that mean something? Does it mean you're being cut out? You're not important? There's that whole ego part. Yeah. Brian Milner (14:04) Yeah. Right. Sure, mean, especially if there's a decision to be made, right? You could feel like, they don't want my voice in that decision. And I think that that's a legitimate concern. If I'm responsible for an area and decisions are gonna be made in the meeting and I'm left out of that invitation, I might have a concern and say, if there's gonna be a decision made around this, I probably should have an input. Is there reason why you didn't want my input in this meeting? And, you know, even asking that question can sometimes just trigger, well, this is lower level things. This is not really at the level that you weigh in on. Usually we didn't want to waste your time, you know, something like that. You might find out it has nothing to do with the fact that they didn't want your opinion. It was more of, we were trying to be conscious of your time and, and, and didn't think that this was the kind of thing that you would need to weigh in on. So you might have a micromanaging kind of problem there that you need to address as well. Julie (15:11) Yeah, this is all people's stuff. It's what makes it fun. Brian Milner (15:14) Yeah. I want to, want to just, I'm sorry. I don't want to mean to interrupt you, but there's one thing I've been thinking about this whole time as well, because we've been talking about bad meetings and bad meeting hangovers. And I think initially the first thought that kind of comes to our heads about that is facilitation and maybe the meeting not being organized well. But I think there's another thing that makes a meeting a bad meeting that it's important to call out as well. Julie (15:37) Mm. Brian Milner (15:40) I'll just give you an example. I remember there was a job I took the very first day of the job. It my first day on the job. We had a meeting with some of the other leaders in that organization, and I got called into this, and they introduced me. Hey, this is Brian. I remember them saying, he's the new whatever, whatever the last guy was that had my position. OK, he's the new whoever. And we got into discussion about upcoming things, the status of different projects and other things. in the middle of that meeting, there became a shouting match and there were F bombs dropped left and right. And I remember walking out of that meeting going, what the hell did I get myself into? You know? so what I'm trying to call out there is there are sometimes bad meetings. It's not about the facilitation or the order or the agenda or anything else. There's sometimes bad meetings because we don't bring kind of the Julie (16:15) Mm-hmm. Brian Milner (16:29) best parts of ourselves to the meeting. We bring the worst parts of ourselves to the meeting. And sometimes we don't censor that and we don't let those, we don't kind of, I don't know how to put it. We're not engaging civilly, right? And I know that sometimes when I've been in those and I've had multiple of those kinds of meetings like that, that I would say, yeah, that was a bad meeting. But it wasn't because the facilitator did a bad job. It's because the participants were kind of letting their inner demons manifest through themselves in the meeting and they weren't really treating everyone with respect. They were very disrespectful to their coworkers. And I think that that's maybe more common than we care to admit. Julie (17:05) Mm-hmm. Yes, when you're sharing that to me, that goes back to meeting working agreements. like, what can I, so if we go back to, if you're in a situation where you're in a bad meeting, even if the facilitator is doing the best that they can, there's things that you can do. So to me, if we've had, and I know you were brand new, but you said that that was not. uncommon. If we had meeting working agreements and you let out an F-bomb and that was against the meeting agreements that anyone else in the room can say, you just broke one of our, you can, you, anyone can call people on that behavior. shouldn't have to be just the facilitator because the facilitator might be like just trying to run through, okay, now what am I going to do? It might be needing to just take a little breath to figure out what do, right? But I can imagine if that was the norm in that environment that people got that disrespectful in the meeting that when people left, there was a hangover effect. Like you kind of was like, what am I doing? Brian Milner (18:07) Right. Julie (18:27) What's happening here? What's going on? What did I sign up for on day one? This is day one. What's day two going to be like? Are we holding back? Right. Here's the new guy. Let's be on our good behavior. We'll only drop three F bombs instead of four. So, at, I was very fortunate that at, Brian Milner (18:27) Right. Right. Right. Yeah. Yeah, they were on their best behavior, right? Guess I was new. Yeah. Julie (18:50) rally software, just, this was norm. It was normal to learn, everyone learned how to facilitate and be good participants and all that, except it was really quite funny at our coaches events because we had to have the working agreement that the facilitator actually got to choose how to facilitate, but we didn't get to facilitate the facilitators. But anyway, I have started recommending Alex Bukinski's book, remotely productive. took a lot of what Jean taught us and help is helping people apply that remotely. So like chapter four is how to help in a bad meeting. So if you're a participant and it's going bad, how can you help get back on track in a respectful way? So not being, not being a jerk about it. But even, so he just even gives examples of things like. when somebody makes a recommendation. like noticing when people agree on an action and you type it into chat. It doesn't have to be the facilitator who types it into chat. Like as a participant, you can go, okay, the action was or a decision was made noting decisions, decision, write the decision down, but helping the facilitator be like, we would talk about that. Actually, I forgot until I just started speaking out about it that often, especially in Brian Milner (19:54) Yeah. Yeah. Julie (20:11) big significant meetings, would have a scribe, a facilitator and a scribe. So this is what he's talking about actually is somebody scribing. Brian Milner (20:22) Yeah, yeah, that's a very important component because if we just shout things out and no one's really capturing what the next steps are, those are going to get lost. And we could have to repeat this meeting because we just didn't really follow up in any way. We didn't take any action. So I agree. That's an important component of it is at least designating that it doesn't have to be one person, but just designating that, hey, here's the expectation. Here's what we're going to do. Yeah. Julie (20:49) Um, yeah. So there's a bunch of really good tips in here and like the Kindle version's 1499 or something. So I've been telling people like, if you can have just one meeting that sucks less, you're going to get your 1499 back. So if you could have one less meeting hangover, you're to get your 1499 back, think for sure. Brian Milner (20:49) That's a great tip. Yeah. Yeah, absolutely. I should clarify with my story earlier that I'm a big boy. It wasn't the language that bothered me. It was directed at someone else, like kind of F-U, that kind of thing. That's a very different dynamic than just saying, those effing suppliers, I sure hate that. That's fine. Or maybe more fine for others than some, but. Julie (21:21) Mm-hmm. Right. Brian Milner (21:38) That didn't bother me, was more just that the attitude behind it was a negative one towards someone else. But yeah, that's a great tip there, just understanding that when I'm a participant there, when I show up, that I have a role to play in it as well. There's things I can do and if there's not notes being taken, then I can maybe step up and do that. Hey, someone said we're going to need to do this? All right, let me put that in the chat. Remember, this is what needs to happen. Julie (22:05) Yeah, and he gives nice, some like a template here on when we're making decisions like data, diagnosis, direction, do next. So he's given a nice, he gives a lot of really great tools. I'm really, and like liking it quite a bit. back to your, your example that is, in the, the behavior part. was a lack of respect versus really the content. Yeah, I get that. The conflict that's going on. Brian Milner (22:42) Yeah. The tip from the book you just mentioned kind of aligns also to something that's in this article, the Harvard Business Review article. One of the things it says is they have some tips in this as well. And one of the things they say is demand accountability every time. And I think that's a good kind of takeaway as well is they're specifically talking about these action items, things that we would do as a result. As a participant, think it's important to, I like that language, demand accountability. If we have this meeting, all right, what is it that you're hoping to get out of this? I'm showing up, I'm here, what do you need from me? What are we gonna do as a result of this? Any participant can ask that. Any participant can say, so that we don't just waste this time, what are we going to do next? Julie (23:11) Mm-hmm. Brian Milner (23:29) I think you demand accountability when you do that. Julie (23:33) Yeah, and I would say too, the first thing we should ask is what's the purpose of this meeting? And so if you go up to turn agendas into action plans, Jean taught us is you have a purpose statement. And then actually she taught us that what are the questions we need to answer in order to meet the purpose? Those are our agenda topics. When we've answered those questions, we're complete with this meeting. And then like where the Brian Milner (23:39) Yes. Yeah. Yeah. Julie (24:01) come back down here to make every minute count. Don't run over. Alex also gives some nice gentle waves of doing like we would say time check. We have 10 more minutes left. You could just put that in chat time check. We have 10 more minutes left. You don't have to be the facilitator to be like time check. So I do like that. He's helping people think about what they can do versus just being victim to Brian Milner (24:05) Yeah. Julie (24:29) the lack of facilitation. Brian Milner (24:31) Yeah. And as a participant, I can, I can check in at the start of the meeting and say, all right, just, want to, I want to, have a time box check here. Our meeting is scheduled from this time to this time. That's our time box, right? We can't, is there, or I have something right after this. just so you know, here's my time box. can't go further than this. and you know, I think as a participant, it's. Julie (24:46) Hmm. Brian Milner (24:56) you can have those same effects just like you said, hey, time box check, it's this, we got this much time left. And as a facilitator, I know I've reached the end of our time boxes sometimes when we haven't really gotten as far as I had hoped, but I've been okay saying this was a good start. This was a good start to what it is we need to decide. Obviously this is gonna take more time. We are at our time box, so we're gonna have to wrap this meeting up, but we'll schedule follow-ups and we'll take it from here. If I'm entering a meeting where I need a decision by the end of that time box, then by all means, make sure people are aware of that from the start. If I'm a participant or if I'm the facilitator, we're here together, but we all need to understand that we need to leave this with a decision on this. Julie (25:37) Yeah. So the other thing, Kia, I believe, around the decision is, and also be clear about how we're going to make the decision. So is this going to be a collaborative decision? We're all going to vote? Or are we getting, everyone going to give their opinion? Somebody else is going to make the decision? And then we'll check, like, how are we, how is the decision going to be made? So that's not a surprise as well. Brian Milner (25:50) Yeah, yeah, yeah. Yeah, yeah, extremely important. I know when I talk about in our product owner classes about doing things like buy a feature as a way to prioritize, one of the things I always try to say to the stakeholders is, hey, we're going to play by a feature, but this is no promise that this is going to be what the final prioritization is. You're helping me to prioritize, but I want to set the expectation. I have to take into account your opinions and other people's opinions and market factors and lots of other things. So make sure we're on the same page. We need to understand this is a component of the decision. I will make the final decision outside of this meeting, but I really appreciate the input and I need your input to help me make the decision. Julie (26:32) Right. Yeah, love that example. So moving down when they say press paw, how to recover how to press. Brian Milner (26:55) Yeah, yeah, yeah. If you find yourself having a hangover from one of these bad meetings, yeah. Julie (27:01) Well, even if it's a great meeting, I am a fan of Adam Grant and I can't like pull up the where he said it. And he said it someplace that the studies show that people actually need like 10 minutes between topics. So if you're going to finish a meeting, you should have at least 10 minutes before the next meeting to be able to. Brian Milner (27:19) Yeah. Julie (27:27) focus and reframe. So I also feel like sometimes these meetings are bad because people are rushing from meeting to meeting. They don't have time to take a bio break or get a bite to eat. So now they're hungry and all that kind of stuff. But we do this to people on a regular basis. Brian Milner (27:46) Yeah, yeah. But, and I agree with that. if it's a good meeting or a bad meeting, I'll find myself, because I work from home exclusively. Well, I shouldn't say exclusively. Sometimes I'll go and work on site with different companies. But when I'm working from home, I'll leave the meeting of something I've just talked about and I'll have to go get more tea or something. And there's a little decompression of, wow, let me kind of throw that off, right? Let me take a deep breath. And now I can reset and I'm ready for whatever the next thing is. But I find I do that kind of naturally and I can't imagine not doing it. I can't imagine kind of going one thing to the other all the time and never having that break. That would kill me. Yeah. Julie (28:31) It happens all the time. It happens all the time. back to meeting working agreements. That's another one that I suggest is people don't start like at the top or the bottom of the hour. Like they offset it a bit to build in breaks. But when you're setting that time box, you got to set, you got to leave space in your agenda time. You have to leave space in your time, your meeting time to close your meeting properly. Brian Milner (28:59) Yeah. Yeah. Julie (29:01) We don't think about how much time that takes either. So it all adds up for sure. Brian Milner (29:09) I like the idea too that they have in here of walking it off. I know just in my work history, kind of like the example I gave you, there have been times when I've been through meetings where I feel like, yeah, I just got to get this off of me. And I have taken... remember, know, in certain circumstances, I'm not a smoker at all, but I, I had, I've always had developers that smoke in some way, shape or form. I, I wouldn't be uncommon for me to go and just stand outside with them while they smoke. or I'll walk down to the corner and get a drink or something and come back. there's something about taking that walk, getting outside the office. or if I'm here working at home, you know, maybe I'll even just go take the dog for a quick walk around the block. And by the time I come back, that's such a good way to. just kind of let whatever that is go away and reset. Now I'm ready to do what I need to do next, but it all goes to know, eliminating that hangover effect that I might have that came from a bad meeting. Julie (30:12) Yeah, so another facilitation tip around that, especially if you've just done a big meeting, if you can, walk it off with someone else. But do it in a debrief way, like what did you learn? And so we would talk about walking the walls. If we're physically together, we have stuff all over, like grab a friend. Brian Milner (30:21) Mmm. Yeah. Julie (30:34) or grab something you don't usually talk to and then walk the walls, so to speak. So at the end of class when I do have enough time, I like them in their breakout rooms to just debrief each other. Like what are a few things you want to try and remember? Because we all remember different things. So there's different ways you can do it. The way they talk about walking it off is it Brian Milner (30:38) Yeah. Julie (31:01) to avoid the hangover, but hopefully we're gonna switch the culture and people are gonna have good meetings and they're gonna wanna talk about positive stuff at the end. I mean, there's both ways of thinking about that physically, I think. Brian Milner (31:13) Yeah. Yeah, I agree. Well, I hope people have gotten a lot of this. You know, we kind of debated, we do this? Should we talk about this? It's so close to kind of the last topic, but I do kind of see it as a part one and part two. You know, there is a part one of that that is, bad meetings sometimes are very much a cause and effect of not facilitating well. But I would hate for people to entirely think, well, it's just the facilitator. there are only one person in the room. And if all the other people think that's not really my responsibility and I don't really have a part to play in this, then the facilitator can only do so much. Julie (31:45) Yeah. Yeah, and depending on what type of meeting it is, like really big, significant, like quarterly planning meetings, then the facilitator needs to do more work, in my opinion, to set everybody up for success. So depending on the size, the length, the... Some meetings need more structure than others, but I agree that as participants, you gotta have accountability to and how it's going and do I need to be here? What's the purpose? If the purpose isn't introduced, then you would ask kindly, what's the purpose of the meeting? What are we trying to accomplish here? I'm just wondering, I'm just checking in. just, not like, the hell am doing here? Brian Milner (32:38) Right, right. Julie (32:39) was to make sure that I'm, you know, whatever. But I do like what Kate said. don't know. You should be able to ask the questions. You should be able to decline all of that. So here's what I'm thinking now, Brian. Another thing people could do, though, is if they start to pay attention to the cost. Brian Milner (32:44) Yeah. Julie (33:05) of being in meetings just through their own health and well-being, then yes, they can be proactive. They can learn a few tips from Alex, but then maybe they, even if they're not the Scrum Master or someone who would normally be assigned to becoming a facilitator, maybe they can get some of the facilitator training because... The training that Kate was talking about really is applicable to any kind of role. It doesn't have to be the scrum master or product owner or team lead or manager. It's really applicable to all people. And then the other thing too, if it's something that say you're in the developer level role, even if you're a business analyst, quality, whatever, quality engineer, whatever, and you wanna become a facilitator. get the training and see if you like it. Then you can kind of be stealth-like in there with, and I feel like that's some of the things Alex is trying to teach people as well. If you're going to be the facilitator or the participant, that there's ways that you can make a difference in a positive way. Brian Milner (33:59) Yeah. Yeah. Absolutely agree. agree. Well, this has been a great conversation. We got to have you on more often. So I apologize it's been so long, but I really appreciate you taking the time and bringing this topic up. And it's a great, great focus for us, I think. thanks for bringing it, Julie. Julie (34:21) Beautiful. Well, I don't have a meeting hangover, do you? Brian Milner (34:36) I do not. I feel great. I don't need to walk anything off right now. Awesome. There we go. I'm right there with you. All right. Thanks, Julie. Julie (34:39) Me either. I'll just go back to drinking tea. Okay. right. Thank you. Yep.

We're exploring the false dichotomy between being good at your job and being seen as valuable by leadership!The framework for this conversation was an eye-opening yet brutally honest post about the tactics one product manager claims to use to advance his career without delivering real impact. We ask, "is success about making an impact or just being seen as valuable," while we explore the tactics described in the article:Focusing on vision while ignoring executionUsing positivity to mask problemsAvoiding accountabilityDealing with the Inevitable burnoutWhether you're a product manager, leader, or team member, you won't want to miss our conversation around building sustainable career success without sacrificing integrity.References:Ronald Westrum: A typology of organisational cultures, 2004AA201 - Mastering Stakeholder Communication and ManagementAA199 - W. Edwards Deming's Profound Knowledge for Transforming OrganizationsAA195 - Tyranny of Plans & Planning in Software DevelopmentAA117 - You Should Do Time-Based Estimates (Article Review)AA87 - Burnt-Out Product ManagersAP52 - Taylorism: The Principles of Scientific Management#ProductManagement #LeadershipCulture #AgileTeams= = = = = = = = = = = =YouTubeApplehttps://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotifyhttps://open.spotify.com/show/362QvYORmtZRKAeTAE57v3= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Karen Suarez: How to Design Communication Channels to Protect Agile Team Focus, and Avoid Interruptions 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. As a first-time Scrum Master managing a team of 15-20 people, Karen focused primarily on protecting them from constant interruptions in their open office space. However, she soon realized this approach was creating barriers between the team and stakeholders. Karen developed strategies to balance protection with accessibility by establishing "office hours" when the team could be interrupted, creating dedicated communication channels (like Slack) to collect stakeholder questions, and always including the Product Owner when change requests came in. This balanced approach maintained team focus while keeping communication lines open. In this segment, we refer to the Coach Your Product Owner e-course, available to all who need to support their product owners with understanding, and adopting an Agile way of working. Self-reflection Question: How might creating structured interruption times help your team maintain focus while still remaining accessible to stakeholders? Featured Book of the Week: The Scrum Guide Karen recommends repeatedly reading The Scrum Guide throughout your Agile journey. She finds she learns something new with each reading as her interpretation evolves with experience. Karen also highlights "Inspired: How to Create Tech Products Customers Love" by Marty Cagan, which helped her better understand the Product Owner role and gave her practical tools to support POs in their responsibilities. About Karen Suarez  Karen is a dedicated Scrum Master with a long experience driving agile transformations and fostering high-performing teams. She is passionate about continuous learning, and excels in aligning agile practices with organizational innovation. You can link with Karen Suarez on LinkedIn.

Is it better to hire someone with deep domain expertise and teach them product management, or to bring in an experienced PM who can learn the domain? Today, we're debating the strengths and weaknesses of both approaches across critical areas like business impact, product discovery, stakeholder management, and leadership!Listen (or watch) as Product Manager Brian Orlando and Enterprise Business Agility Coach Om Patel discuss why domain experts excel at identifying immediate pain points but may struggle with deeper product methodologies... or listen/watch as we discuss how experienced PMs can bring fresh perspectives while also facing steeper learning curves in specialized industries. This podcast is all about exploring the real-world tradeoffs Product Leaders face when building product teams and providing insights for both hiring managers and product professionals!#ProductManagement #CareerDevelopment #AgileLeadershipReferences:Boiler Room (film), 2000Marty Cagan - Inspired: How to Create Tech Products Customers Love, 2008AA120 - Did AirBnB Fire Their Product Managers?AA199 - W. Edwards Deming's Profound Knowledge for Transforming OrganizationsAA201 - Mastering Stakeholder Communication & Management= = = = = = = = = = = =YouTubeSubscribe on YouTube:https://www.youtube.com/channel/UC8XUSoJPxGPI8EtuUAHOb6g?sub_confirmation=1Applehttps://podcasts.apple.com/us/podcast/agile-podcast/id1568557596Spotifyhttps://open.spotify.com/show/362QvYORmtZRKAeTAE57v3= = = = = = = = = = = =Toronto Is My Beat (Music Sample)By Whitewolf (Source: https://ccmixter.org/files/whitewolf225/60181)CC BY 4.0 DEED (https://creativecommons.org/licenses/by/4.0/deed.en)

Anuj Ojha: Helping PO's Move Beyond User Story Templates to True Customer Understanding 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 Setter Who Empowers Teams In this segment, Anuj describes an exemplary Product Owner who mastered the art of inclusive product development. This PO excelled at bringing everyone together to discuss the product and potential solutions, while maintaining a clear focus on the vision and problem space. Rather than dictating solutions, they created an environment where team members could freely explore solutions while the PO remained available for questions and guidance. Their success came from building strong relationships with stakeholders and customers, and effectively using the Eisenhower matrix to prioritize work. The Bad Product Owner: The Requirements Translator Anuj discusses common anti-patterns he's observed in Product Owners, particularly those who may have previously been project managers. A crucial issue arises when POs create user stories without first understanding the customer and their journey with the product. Some POs become mere translators, rigidly adhering to story templates instead of truly understanding customer needs. The key to improvement lies in helping POs learn to engage directly with customers, focus on problem exploration rather than immediate solutions, and collaborate with the whole team in solution discussions. Self-reflection Question: How can you help your Product Owner move from being a requirements translator to becoming a true value maximizer? [The Scrum Master Toolbox Podcast Recommends]

Season Hughes: From Defensive to Collaborative 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: Building Team and Customer Connection A great Product Owner demonstrates deep care for both the product and the team members, understanding their challenges and experiences. Season highlights how exceptional POs actively advocate for customer involvement in sprint reviews and consistently conduct customer interviews, creating a strong bridge between the development team and end-users. The Bad Product Owner: The Defensive Questioner Season describes a challenging situation where a Product Owner would respond to team proposals with defensive "why" questions, creating an atmosphere where developers felt they needed to justify their suggestions. This approach led to team defensiveness and reduced collaboration, highlighting the importance of asking questions in a way that promotes understanding rather than creates tension. Self-reflection Question: How do you ensure your communication style encourages collaboration rather than defensiveness? [The Scrum Master Toolbox Podcast Recommends]

What does it mean for a network engineer to develop a product mindset? And what does a product mindset have to do with network automation? Guest Peter Sprygada connects these concepts in today's episode of Total Network Operations, sponsored by Itential. Peter says that as an organization advances its network automation capabilities, the impetus shifts... Read more »

What does it mean for a network engineer to develop a product mindset? And what does a product mindset have to do with network automation? Guest Peter Sprygada connects these concepts in today's episode of Total Network Operations, sponsored by Itential. Peter says that as an organization advances its network automation capabilities, the impetus shifts... Read more »

Substack Week: AI in Product Management, Enhancing Product Development Through Artificial Intelligence with Toni Dos Santos In this Substack Week episode, we explore how artificial intelligence is transforming product management with Toni Dos Santos, co-author of The Product Courier newsletter. From automating routine tasks to enhancing strategic decision-making, Toni shares practical insights on leveraging AI to build better products faster and more efficiently. From Music to Banking to AI Product Management "I wanted to work in that area to find ways to put innovation to service to the consumers, and making it as invisible as possible." Toni's journey into AI and product management began in an unexpected place - the music industry. After working as a music producer, his interest in innovation led him to banking, where he discovered the untapped potential of data analytics. His experience working with machine learning and deep learning in banking laid the foundation for his current work with generative AI in product management. The launch of ChatGPT in 2022 sparked his deep dive into applying AI to product management challenges. Revolutionizing User Story Creation with AI "User stories are a big pain for many product managers, particularly junior ones... The idea is that you provide the AI with a PRD or description of the product, and it's going to write user stories based on best practices." Toni explains how AI can transform the process of writing user stories by automating the initial drafting while preserving the essential collaborative aspects. He emphasizes that while AI can handle the mechanics of writing, the real value comes from using it as a springboard for deeper discussions with the team. The technology can suggest edge cases, highlight potential gaps, and provide a structured foundation for further refinement. AI as a Tool for Understanding User Needs "Use all the transcripts, the feedback from user interviews that I have, feed it to AI and retrieve from it the key pain points, the major patterns that it identifies." Rather than replacing human insight, AI serves as a powerful tool for analyzing user feedback and identifying patterns. Toni shares practical examples of using AI to: Process and analyze app store reviews at scale Identify clusters of users with similar pain points Extract key themes from user interviews Validate qualitative findings with quantitative data Strategic Role of AI in Leadership "For product leaders, they should be the ones thinking how AI will affect their work because to define a strategy, to define a roadmap, AI can summarize tons of data, tons of information that you cannot do yourself." Toni challenges the notion that AI primarily impacts lower-level tasks. He argues that AI's ability to process vast amounts of information makes it particularly valuable for leadership roles. Leaders can use AI to: Prepare more effective meetings with relevant agendas Create alignment across different departments Practice important presentations and interviews Generate and evaluate strategic options Best Practices for Getting Started with AI "The best resource is to go into it... get ChatGPT, Gemini, whatever, and just dive into it and try and get learning and start practicing right away." For product managers looking to incorporate AI into their workflow, Toni emphasizes the importance of hands-on experience. He recommends: Starting with practical experimentation rather than just theoretical learning Understanding AI's limitations (20% error rate) and always double-checking outputs Treating AI interactions as conversations rather than one-off prompts Focusing on areas where AI can augment rather than replace human judgment Resources For Further Study BOOK: Bret King, Bank 3.0: Why Banking Is No Longer Somewhere You Go But Something You Do Toni's Product Courier Newsletter The AI focused episode with Marshall Goldsmith AI Course by IBM: Armin Ries, free AI course by IBM [The Scrum Master Toolbox Podcast Recommends]