Podcasts about product owners

Aimé Flemm: Culture Follows Structure — Why Some Teams Self-Destruct By Design 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.   "Culture follows structure. The destructive tendencies of a team are the consequence of how the organization is actually structured." - Aimé Flemm   Aimé doesn't blame teams when they go toxic. He looks at the org chart. At his first gig, the UX-only team grew bitter — making screens nobody used, blocked from talking to customers, drowning in dependencies. The team's behavior wasn't a coaching problem. It was a structural one. At his current company, building backend software for EV charging stations, he watched the opposite happen: leadership flipped seven component teams (backend, billing, etc.) into seven end-to-end feature teams with one Product Owner. Two-week sprints. Switching costs collapsed — they could decide on Wednesday to change direction, refine on Thursday, and have all seven teams pivot together by the next sprint. The org became truly adaptive. Aimé's question to every Scrum Master listening: is your organization fit for purpose? If the work is predictable and specialism-heavy, component teams can work. If you need adaptability, the structure has to match. Don't coach behavior that the structure forces.   In this segment, we talk about Larman's Laws of Organizational Behavior, the Star Model by Jay Galbraith, and Org Topologies.   Self-reflection Question: Look at the team you're coaching. Which of their "destructive habits" might actually be a rational response to the structure you've put them in? Featured Book of the Week: Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman This week, Aimé recommends two books that complement each other. First — and his "holy bible" — is Large-Scale Scrum: More with LeSS by Bas Vodde and Craig Larman. "I remember reading this for the first time. It took me two weeks, the whole book. And I was just constantly texting people — 'this is it! It all makes sense now. I finally know what to do.'" For the how of organizational change — workshop ideas, possible structures, change tactics, and the people side — LeSS is the book. The companion book Aimé pairs with it is 10x Organization by Alexey Krevitsky, Roland Flemm, and Craig Larman — strong on the what and the why, with a 2x2 visual map that helps you explain to management where you are today, where the market needs you to be, and what should change. (You can also listen to our episode with Bas Vodde and our BONUS episode with Roland Flemm for a deeper view.)   [The Scrum Master Toolbox Podcast Recommends]

Als Product Owner existieren viele Erwartungen an dich gleichzeitig: Stakeholder wollen schnelle Entscheidungen, das Team braucht Klarheit, das Product Backlog wächst weiter und im Kopf läuft die Arbeit oft noch lange nach Feierabend mit. In dieser Folge sprechen Oliver und Dominique darüber, wie Product Owner in genau diesem Alltag entspannt(er) bleiben können, ohne Verantwortung wegzuschieben oder Wichtiges zu ignorieren. Es geht um Fokus, Klarheit und mentale Stärke im Produktalltag. Oliver und Dominique teilen eigene Erfahrungen aus ihrer Zeit in der Product Owner-Verantwortung und sprechen darüber, warum Stress oft dann entsteht, wenn wir alles selbst lösen wollen, Dringlichkeit ungefiltert übernehmen oder den eigenen Fokus aus den Augen verlieren. Dabei wird es sehr praktisch: vom Morgenritual über Tages- und Wochenfokus bis hin zum bewussten Umgang mit einem vollen Product Backlog. Die beiden sprechen über Bullet Journals, Aufgabenlisten, Pausen, Spaziergänge, Meditation, Reviews am Tagesende und die Frage, wie Product Owner äußeren Druck besser einordnen können. Eine zentrale Idee der Folge: Entspannt bleiben heißt nicht, weniger verantwortlich zu sein. Es bedeutet, klarer zu erkennen, welche Verantwortung wirklich bei dir liegt, welche Aufgaben andere besser übernehmen können und welche Dringlichkeit tatsächlich berechtigt ist.

Herken je dat gevoel dat je agenda volloopt met meetings, terwijl het échte werk blijft liggen? Tijd om de regie terug te pakken, want zonder scherpe focus creëer je als Product Owner simpelweg geen waarde. Jochem gaat deze week met Michiel Roozen in gesprek voor het eerste deel van dit krachtige tweeluik. In deze aflevering bespreken ze: Hoe je als Head of Product je Product Owners effectief uit de slopende ad-hoc-modus haalt. De logica achter ‘minder meetings, meer focus' en waarom dit de enige weg is naar echte impact. Een half uur lang bomvol super concrete tips waar je morgen direct mee aan de slag kunt. Een must listen voor iedere PO die, klaar is met de waan van de dag en de baas wil worden over de eigen agenda. De Product Owner podcast is een initiatief van productowner.nl

Dominique und Oliver sprechen in dieser Folge darüber, warum die Wahl des richtigen Zielmarkts weit mehr ist als eine Marketingentscheidung. Wer Verantwortung für ein Produkt trägt, trifft jeden Tag Entscheidungen, die den weiteren Handlungsspielraum einschränken oder erweitern. Genau deshalb beeinflusst der Zielmarkt die Produktentwicklung von Anfang an. Er bestimmt, welche Probleme relevant sind, welche Bedürfnisse zählen und welche Rahmenbedingungen bei der Gestaltung eines Produkts berücksichtigt werden müssen. Für Product Owner:innen und Produktmanager:innen entsteht daraus eine wichtige Frage: Für wen entwickeln wir eigentlich und in welchem Markt soll unser Produkt erfolgreich sein? Ein Zielmarkt besteht aus deutlich mehr als einer Nutzergruppe. Geografische Unterschiede spielen ebenso eine Rolle wie rechtliche Vorgaben, kulturelle Erwartungen oder technologische Rahmenbedingungen. Ein Produkt kann in einem Markt hervorragend funktionieren und in einem anderen kaum Resonanz erzeugen. Manche Funktionen werden in einem Land erwartet, während sie anderswo keine Bedeutung haben. Wer diese Unterschiede ignoriert, riskiert hohe Investitionen in Lösungen, die am tatsächlichen Bedarf vorbeigehen. Der Zielmarkt setzt deshalb wichtige Leitplanken für Produktstrategie, Produktgestaltung und die Auswahl möglicher Lösungsansätze. Häufig entsteht der Wunsch, möglichst viele Kundengruppen gleichzeitig anzusprechen. In der Praxis führt das oft zu Produkten, die für niemanden wirklich überzeugend sind. Ein klar definierter Zielmarkt hilft dabei, Ressourcen gezielt einzusetzen und Prioritäten bewusster zu setzen. Statt jede denkbare Anforderung zu berücksichtigen, entsteht ein besseres Verständnis dafür, welche Probleme besonders relevant sind und wo der größte Nutzen geschaffen werden kann. Diese Fokussierung erleichtert viele Entscheidungen im Produktalltag und schafft Orientierung für Teams und Stakeholder. Die Suche nach dem passenden Zielmarkt beginnt selten mit vollständiger Sicherheit. Meist stehen zunächst Annahmen im Raum. Genau deshalb ist frühes Lernen so wichtig. Kundeninterviews, Beobachtungen im Nutzungskontext und direkte Gespräche mit potenziellen Kundinnen und Kunden helfen dabei, Marktsegmente besser zu verstehen. Dabei geht es nicht darum, Zustimmung für eine Idee einzusammeln. Entscheidend ist, die eigenen Hypothesen kritisch zu prüfen und herauszufinden, ob ein relevantes Problem tatsächlich existiert und ob die gewählte Zielgruppe bereit ist, sich damit auseinanderzusetzen. Auch der Product Market Fit entsteht nicht am Reißbrett. Ob ein Zielmarkt wirklich zum Produkt passt, zeigt sich oft erst nach den ersten Schritten im Markt. Die gewonnenen Erkenntnisse können Anpassungen am Produkt erforderlich machen. Manchmal zeigt sich sogar, dass ein anderer Zielmarkt deutlich besser geeignet ist. Erfolgreiche Produktentwicklung bedeutet deshalb, Markt und Produkt gemeinsam weiterzuentwickeln. Wer den Zielmarkt als lernbare Annahme versteht und regelmäßig hinterfragt, schafft bessere Voraussetzungen für nachhaltigen Produkterfolg. Im Kontext dieser Folge empfehlen wir euch insbesondere folgenden Folgen: - User Feedback mit Kundeninterviews einholen (https://produktwerker.de/user-feedback-mit-kundeninterviews/) - Warum Personas für Product Owner wertvoll sind (https://produktwerker.de/warum-personas-fuer-product-owner-wertvoll-sind/) - Das Problem mit dem Minimal Viable Product (https://produktwerker.de/das-problem-mit-dem-minimal-viable-product/) - The Decision Stack (https://produktwerker.de/the-decision-stack/)

Maria Skvortsova: The Yes-Man Product Owner and the Scrum Master Who Became a Proxy for the Proxy In this episode, we refer to User Story Mapping and the MoSCoW prioritization method. The Great Product Owner: Structure Over Gut Feeling — When a Well-Shaped Backlog Speaks for Itself 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 indicator of a good product owner is a well-shaped backlog — with priorities, with values, with efforts. You definitely know that you pull from the top, and it is the most valuable thing you should work on." — Maria Skvortsova   For Maria, the best product owners she's worked with share one trait: they bring structure. Not rigidity — structure. They use techniques like user story mapping to make priorities visual for everyone. They use value-effort matrices instead of gut feelings. They apply methods like MoSCoW to give the backlog a clear, unambiguous order. The result? A developer never has to ask "what should I work on next?" — the answer is always at the top of the backlog. Maria, drawing on her decade as a C++ developer, knows firsthand how frustrating it is to chase down a BA or PO just to figure out what to build next. A well-ordered backlog doesn't just help the team move faster — it also makes it easier for the product owner to communicate with the business, because every decision has data behind it, not just intuition.   Self-reflection Question: Could a new team member look at your product backlog right now and immediately know what to work on next — and why that item is the most valuable? The Bad Product Owner: The Yes-Man Who Sank the Ship — When Saying Yes to Everything Means Delivering Nothing 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.   "He was always saying yes. And this led to the scope that grew and grew, until we realized we were not capable of delivering what we committed to." — Maria Skvortsova   Maria returns to her SAP migration experience for this anti-pattern. The team had a team lead acting as product owner — someone technical who saw everything as important. Every new requirement got a "yes." The scope ballooned while the iron triangle held firm: fixed cost, fixed time, no room to breathe. The team reached a breaking point where they had to admit, to each other and to the client, that delivery was impossible. Maria stepped in as what Vasco called "a proxy for the proxy" — she helped the team lead build a user story map on Miro, then facilitated a workshop with the business. Her question was disarmingly simple: "If we don't deliver this by go-live, will your product still function? If yes, it goes to release two." That reframing — not "no" but "yes, later" — gave the client clarity without triggering defensiveness. The team lead learned that business stakeholders aren't the enemy; they just need someone to help them make honest trade-offs. And saying "not now" is infinitely more useful than saying "yes" to everything and delivering nothing on time.   Self-reflection Question: When was the last time you or your product owner said "not now" to a stakeholder — and did it feel like a failure or a strategic decision?   [The Scrum Master Toolbox Podcast Recommends]

In dieser Folge spricht Dominique mit Aurelia Weimer über ihre ersten 100 Tage als Product Ownerin. Im Mittelpunkt steht eine Einstiegsphase, die vor allem aus Lernen, Orientierung und vielen neuen Herausforderungen besteht, denn Product Ownership beginnt in der Praxis nicht immer mit einem gepflegten Backlog, klaren Entscheidungswegen oder einer abgestimmten Produktstrategie. Häufig stehen zunächst grundlegende Fragen im Vordergrund: Wie arbeiten die Menschen zusammen? Wer trifft welche Entscheidungen? Welche Erwartungen gibt es an das Produkt? Welche Strukturen helfen bereits und welche stehen eher im Weg? Aurelia berichtet, warum es am Anfang wichtig ist, nicht vorschnell Lösungen zu präsentieren, sondern zunächst Kontext aufzubauen. Dazu gehören fachliches Wissen über die Domäne, ein Verständnis für bestehende Routinen und ein genauer Blick auf die beteiligten Menschen und ihre Erwartungen. Ein weiterer Schwerpunkt der Folge ist die Zusammenarbeit mit dem Entwicklungsteam. Gemeinsame Workshops, offene Diskussionen und die bewusste Auseinandersetzung mit der eigenen Arbeitsweise werden als wichtige Elemente beschrieben, um Schritt für Schritt zu einem passenden Vorgehen zu finden. Dabei geht es weniger darum, Scrum-Elemente möglichst lehrbuchnah umzusetzen, sondern darum, herauszufinden, was dem Team in der konkreten Situation wirklich hilft. Die Folge zeigt außerdem, dass die ersten 100 Tage auch eine Phase persönlicher Entwicklung sind. Neues Domänenwissen, Unsicherheit und Verantwortung gehören ebenso dazu wie Fragen stellen, Unterstützung annehmen und den eigenen Wissensstand realistisch einordnen. Moderne Werkzeuge können den Einstieg erleichtern, etwa beim Erschließen fachlicher Themen oder beim Strukturieren von Informationen. Der Kern wirksamer Product Ownership bleibt jedoch die Arbeit mit Menschen: Beziehungen aufbauen, Perspektiven verstehen, Erwartungen klären und gemeinsam Vertrauen entwickeln.

Njegos Ilic: Why Measuring Your Product Bets Is the Key to Product Owner Success 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.   "If you cannot measure what you build, you will just be depending on who is screaming the loudest and using your gut feeling — which is not a good thing long term." - Njegos Ilic   Njegos defines product owner success through three pillars: the ability to measure product bets, deep knowledge of the industry and product, and the humility to admit mistakes and be challenged. The measurement piece is central — without it, he argues, you're flying blind, making decisions based on opinions rather than evidence, reacting to whoever screams loudest rather than what the data shows. But Njegos is honest that not every environment makes measurement easy. Some companies lack the tooling, the culture, or the historical infrastructure to set up proper analytics. In those situations, he turns to user interviews as the next best thing — getting direct feedback from users, even though he acknowledges that opinions are still limited without data to fact-check them against. His most powerful suggestion: invite the whole team to user interviews, not just the product trio. When developers hear directly from users, they connect to real-world problems, and conversations during refinements become richer and more grounded.   In this episode, we refer to The Mom Test by Rob Fitzpatrick and Shift: From Product to People by Michael Dougherty and Pete Oliver-Kruger.   Self-reflection Question: How do you currently measure whether the features you shipped actually delivered the value you expected — and if you can't measure it, what's your fallback? Featured Retrospective Format for the Week: Start With a Relaxing Exercise Njegos doesn't advocate for a specific retrospective template — and that's the point. From his product owner perspective, he values retrospectives that begin with a relaxing, informal exercise to set the tone. Not everything needs to feel like business as usual. This casual opening allows people to connect as humans first, which opens them up to think differently about what they learned during the sprint. Njegos is candid about the reality: some teams love icebreakers, while others find them childish and just want to get to the point. His advice is to sense the pulse of the team and adapt. The format matters less than whether it creates an environment where people can be honest about what went well, what didn't, and what to improve. A Scrum Master who reads the team's vibe and adjusts accordingly — that's what makes the difference.   [The Scrum Master Toolbox Podcast Recommends]

Njegos Ilic: Why Saying Yes to Every Stakeholder Request Is the Fastest Way to Fail as a Product Owner 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 game is rigged because they are strong personalities, they want to get things done, but you don't have a magic stick — it's really hard to deliver results if you cannot say no." - Njegos Ilic   Njegos shares a failure from early in his career as a product owner in startup environments, where he found himself saying yes to every stakeholder request. Working with strong-willed founders who expected things done their way, Njegos fell into the trap of trying to please everyone — building everything that was asked without pushing back. The result was predictable: scattered priorities, no room to pivot, and a product backlog driven by the loudest voice in the room rather than real user needs. But Njegos frames this failure with a perspective that product owners at any stage can learn from. He compares the learning process to watching children learn to walk — stumbling and falling is not a sign of weakness, it's a necessary step in the process of growing. His advice to product owners currently stuck in this pattern: don't try to avoid failures too hard, because you might prevent yourself from learning the most important lessons. Instead, treat failure as a feedback loop — something happened, you can measure it, and you can change your approach. The key is doing the actual work of reflection: What did I do? What should have been different? What wasn't possible to change, and why?   Self-reflection Question: When was the last time you said yes to a stakeholder request even though your gut told you it wasn't the right call — and what would it take for you to say no next time?   [The Scrum Master Toolbox Podcast Recommends]

Dominique und Tim sprechen in dieser Folge über die Methode des Experience Market und darüber, was dieses Großgruppenformat in der Produktentwicklung und der Product Discovery anderes bewirken kann als viele andere "klassische" Austauschformate. In vielen Unternehmen sitzen Product Owner, Entwickler:innen, UX und Führungskräfte zwar regelmäßig zusammen in Meetings oder Reviews. Und doch bleiben Erfahrungen oft in einzelnen Teams hängen. Dort setzt der Experience Market an. Menschen sprechen strukturiert über echte Situationen aus ihrem Alltag und machen sichtbar, was funktioniert hat, wo Unsicherheit entsteht und welche Probleme sich über Teams hinweg wiederholen. Der Experience Market lebt davon, dass viele Perspektiven gleichzeitig zusammenkommen. Dominique beschreibt das anhand der Product Owner Days in Köln, bei denen im Rahmen einer Abendveranstaltung rund 200 Teilnehmende gemeinsam an verschiedenen Themenstationen gearbeitet haben. Statt Frontalvorträgen oder vorbereiteten Präsentationen entstehen Gespräche direkt an großen Boards. Dort sammelten die Gruppen ihre Erfahrungen zu Themen wie Outcome-Orientierung, Zusammenarbeit oder Product Ownership. Entscheidend ist dabei, dass nicht nur Erfolge sichtbar werden. Auch gescheiterte Ansätze oder schwierige Situationen gehören bewusst dazu. Gerade dadurch entstehen oft die wertvollsten Diskussionen. Wichtig und spannend ist beim Experience Market vor allem die Dynamik zwischen den einzelnen Gruppen. Menschen wechseln während des Formats in drei Runden zwischen verschiedenen Stationen und bringen neue Gedanken mit. Eine Gruppe ergänzt, was die vorherige begonnen hat. Andere widersprechen oder erweitern bestehende Perspektiven aus ihrer eigenen Praxis. Dadurch entsteht kein starres Ergebnisdokument, sondern ein gemeinsamer Erfahrungsraum. Viele Organisationen unterschätzen, wie viel Wissen bereits intern vorhanden ist. Häufig fehlt lediglich ein Rahmen, in dem dieses Wissen sichtbar und anschlussfähig wird. Tim beschreibt dabei seine Beobachtung, die viele Produktmenschen kennen mögen. In klassischen Workshops sprechen oft dieselben Personen. Beim Experience Market entsteht dagegen Bewegung im Raum und damit auch Bewegung im Denken. Die Gastgeber:innen der einzelnen Stationen moderieren nicht im klassischen Sinn. Sie sorgen dafür, dass Gespräche entstehen, Gedanken dokumentiert werden und andere Gruppen später nachvollziehen können, warum bestimmte Themen relevant waren. Genau diese Verbindung aus Austausch, Sichtbarkeit und gemeinsamer Reflexion macht den Experience Market für größere Produktorganisationen interessant. Besonders relevant wird der Experience Market dann, wenn Unternehmen ihre Produktarbeit stärker miteinander verzahnen wollen. Viele Teams kämpfen mit ähnlichen Herausforderungen, ohne voneinander zu lernen. Diskussionen über Outcome Orientierung, Stakeholder oder Produktstrategie finden parallel statt, aber oft isoliert voneinander. Der Experience Market schafft dafür einen gemeinsamen Raum. Nicht als einmaliges Event mit Hochglanzcharakter, sondern als Arbeitsformat, das Menschen miteinander ins Gespräch bringt und Erfahrungen greifbar macht. Ältere Folgen, auf die im Gespräch verwiesen wird: - Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis (JTBD) - Welche Aufgaben gehören zur Product Owner Rolle? Product Ownership Context Canvas (POCC) Habt ihr schonmal vom Experience Market gehört oder sogar teilgenommen? Was sind eure Erfahrungen und Meinungen zu diesem Format? Teilt eure Geschichten und Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Christian Thordal: The Jazz Duo Effect and The Absent PO — Two Sides of Agile Product Ownership The Great Product Owner: Clarity, Accountability, and a Partnership That Fills in the Blanks Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "We kind of filled in the blanks for each other, and it felt very natural — it's grown organically into this partnership where we're extremely aligned on how we see and do things." - Christian Thordal   Christian describes his best Product Owner as someone he currently works with — a person who combines deep product clarity with genuine leadership. This PO is fully accountable for the backlog, sets clear expectations toward the teams, and isn't afraid to push them. What makes this PO stand out is how they use reporting as a communication tool: alongside the backlog, they proactively communicate to the product leader whether things are within or outside scope, always with a plan ready. Christian and this PO hold weekly follow-ups to discuss the team, the backlog, and the product direction. Over time, their alignment has become so strong that during facilitation sessions they naturally fill in blanks for each other — one picks up where the other leaves off. Vasco compared it to a jazz duo, where each musician picks up on the other's leads in real time. This kind of organic partnership in leadership direction reflects positively on the entire team, creating a sense of coherence and momentum that everyone can feel.   Self-reflection Question: How aligned are you with your Product Owner on leadership direction, and what would it take to build the kind of partnership where you naturally fill in the blanks for each other? The Bad Product Owner: When the PO Disappears and the Scrum Master Becomes the Glue 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.   "You can inspire, you can motivate, but you can't really do the work for them." - Christian Thordal   Christian shares an experience from a larger logistics company in Denmark where the Product Owner was a great, likable person — but didn't understand the role. The backlog was high-level, consisting primarily of Epics with no acceptance criteria. Then the warning signs started: the PO became increasingly hard to get a hold of, started canceling refinement meetings (sometimes on the same day), began working more from home, and became physically more distant from the team. Christian and the team were left to navigate on their own, breaking down epics into stories and tasks without knowing if they were building the right product. Christian tried setting up weekly one-hour sessions to help the PO work through the backlog, but the fundamental problem remained — you cannot do the PO's work for them. Eventually, Christian found himself filling in for the PO, which is itself an anti-pattern: the Scrum Master becoming the glue that holds the product together. The symptoms to watch for are clear: a PO who starts missing meetings, backlog items that remain unrefined, a PO who becomes physically or remotely distant, and — the biggest red flag — a Scrum Master who feels compelled to step in and do the PO's job.   Self-reflection Question: Are there signs that your Product Owner is drifting away from the team, and have you caught yourself filling in gaps that aren't yours to fill?   [The Scrum Master Toolbox Podcast Recommends]

Christian Thordal: Structure Creates Freedom, How an Agile Coach Measures Success by Becoming Less Needed 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 less I shine and the more the team shines, the better I perform." - Christian Thordal   Christian shares how his definition of success has fundamentally shifted over the years. Early in his career, the question was "How can I shine?" Today, it is the opposite — success means becoming invisible. For Christian, a high-performing Scrum Master builds teams that no longer depend on them, much like raising a child to become a functional adult by eighteen. They can always call dad for coaching or to borrow money, but they can stand on their own. He illustrates this with a team he moved from what he calls "cowboy loose Kanban" to an adapted Scrum framework. The structure gave the team freedom: he can now miss dailies and planning sessions, and the team still produces a solid plan, sprint backlog, and sprint goal. He drops by to give pointers and encourage good behaviors. Christian also highlights the importance of the Scrum Master and Product Owner partnership — "the mom and dad of the team" — and how building predictability and flow matters more than heroics. A key tactical insight: he created a one-pager roadmap for his domain leader showing issues, plans, milestones, and metrics. This simple artifact gave leadership the comfort that things were under control, buying Christian the autonomy to do his best work. This proved critical when his team was decimated by departures in late 2025 — he hired new people, stabilized the group, and got them delivering again.   Self-reflection Question: What would it look like if your team could run a full sprint cycle without you present — and what is stopping that from happening today? Featured Retrospective Format for the Week: The Four-Box Retrospective Christian shares a retrospective format he calls the Four-Box Retrospective — a structured, pragmatic approach that resonates especially well with engineer-minded teams. The session begins with a team check-in to get the vibe in the room. Next, the team reviews last week's agreements: who was accountable, and are those items still alive or handled? Anything still alive moves forward automatically, ensuring nothing falls through the cracks. Then comes the core mechanic: topic creation divided into four boxes — Tech (tools and tech stacks), Team (issues within the team), Outside (external dependencies and blockers), and Parking Lot (everything else). Presenters explain their topics briefly to give context, and the group uses dot voting to surface the most pressing issues. Discussion follows, with clear accountability assignments and action items written down. The pre-grouping into four boxes saves significant time by giving topics a natural home before discussion begins. Named owners for every action item create real progress between retrospectives. Christian values this format because it is grounded in actual operational problems — people can see the direct application of every conversation, which keeps engagement high and outcomes tangible.   [The Scrum Master Toolbox Podcast Recommends]

Por que seu orçamento de TI nunca é suficiente? Neste Enzimas, Mariana Bernardes, Product Owner na dti digital, fala dos problemas causados pelo desperdício de recursos em TI dentro das empresas. Ela compartilha estratégias práticas para identificar os principais causadores dessa perda orçamentaria e demonstra como a inteligência artificial pode transformar essa realidade, dando visibilidade ao que antes era oculto. Ficou curioso? Então, dê o play!Assuntos abordados:Desperdícios ocultos em TI;ROI de investimentos tecnológicos;Inteligência artificial na gestão;Otimização de orçamento;Eficiência operacional.Links importantes:NewsletterDúvidas? Nos mande pelo LinkedinContato:  osagilistas@dtidigital.com.brOs Agilistas é uma iniciativa da dti digital, uma empresa WPP #enzimas 

Christian Thordal: When Applying Scrum By The Book Fails, Understanding Context Before Changing The System 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.   "I treated Scrum like a military SOP — follow the book, execute the steps. But I failed to see that the context was really the tipping point. What looked like a problem was actually their solution." - Christian Thordal   Christian shares a hard-won lesson from his time coaching three RPA teams at one of Denmark's largest banks during the pandemic. He inherited teams running six-week sprints with half-hour planning sessions that amounted to little more than putting items on a calendar. As a former Danish Army officer, Christian's instinct was to fix the obvious deviation from the Scrum Guide — the sprint length. He advocated for shorter feedback loops and eventually convinced the Product Owner, who also served as the director, to try two-week sprints. The first planning session was a disaster. There was yelling and scolding, and it became clear that the real problem had nothing to do with sprint length. The teams had no proper backlog. The six-week sprints actually worked because they gave teams enough time to go out to the business, discover work, and deliver it within a single cycle. Christian realized he had been applying Scrum mechanically without understanding how work entered the system. He started attending business analyst and PO meetings, uncovered the backlog gap, and helped the teams build a proper one. His key insight: what looks like a symptom can actually be a pragmatic solution to real constraints. Understand the system before you change it.   In this episode, we refer to the book Scrum: The Art of Doing Twice the Work in Half the Time, by Jeff Sutherland.   Self-reflection Question: When was the last time you assumed a team's practice was wrong, only to discover it was a reasonable adaptation to their context? How might you investigate the "why" behind existing processes before proposing changes?   [The Scrum Master Toolbox Podcast Recommends]

Every team has them. The teammate who turns a one-word answer into a five-minute monologue. The developer who has not said a word in three retrospectives. The Product Owner who "adds context" to every user story before anyone gets a chance to read it. This episode is a high-energy, no-nonsense look at the over-talkers and under-talkers who quietly shape every meeting, and at the facilitation moves that turn a room of crickets and ramblers into a room of contributors. Expect a practical tour through the Explorer, Shopper, Vacationer, and Prisoner lens from Diana Larsen and Esther Derby's Agile Retrospectives, a fresh take on meeting personas like the Rambler, the Interrupter, the Silent Assassin, and the Ghost Participant, and a stack of techniques you can use this week:Sand timers in stand-ups. Parking lots that get used. Round-robin and popcorn share-outs. Intentionally crafted breakout rooms. Silent brainstorming. "Make space, take space" working agreements. And the most underused move of all, one-on-one coaching outside the meeting.The takeaway is simple and bracing. The goal of a great meeting is not equal talking time. The goal is meaningful contribution. Great facilitators do more than manage conversations. They create the conditions for better conversations to happen.

Gewinne ein Konferenzticket für die "Product at Heart": produktwerker.de/gewinnspiel/ Arne Kittler, einer der Gründer der "Product at Heart" Konferenz (früher bekannt als "MTP Engage"), spricht mit Tim über die Frage, was sich im Produktmanagement gerade grundlegend verändert und welche Fähigkeiten trotzdem unverzichtbar bleiben. Viele Teams spüren aktuell Druck aus mehreren Richtungen gleichzeitig. Wirtschaftliche Unsicherheit trifft auf neue technische Möglichkeiten durch generative KI und agentische Systeme bzw. agentic AI. Dadurch verändern sich Werkzeuge, Arbeitsweisen und Erwartungen an Produktmenschen quasi alle parallel. Arne beschreibt, warum sich diese Phase anders anfühlt als frühere Umbrüche rund um agile Methoden, Mobile oder Remote Arbeit und wie dies auf der Product at Heart thematisiert werden wird. Wer aktuell Verantwortung für ein Produkt trägt, erlebt oft widersprüchliche Erwartungen. Einerseits sollen Teams schneller liefern und neue Technologien ausprobieren. Andererseits fehlt vielen Organisationen eine klare Vorstellung davon, welche Probleme sie damit eigentlich lösen wollen. Genau dort setzt für Arne Kittler gute Produktarbeit an. Klarheit entsteht nicht durch neue Frameworks oder zusätzliche Prozesse. Sie entsteht, wenn Produktteams sauber unterscheiden zwischen kurzfristiger Begeisterung und echtem Nutzen für Kundinnen und Kunden. Im Produktmanagement zeigt sich das besonders deutlich in Discovery Arbeit, Priorisierung und strategischen Entscheidungen. Viele Diskussionen drehen sich heute um KI Funktionen. Die schwierigere Frage bleibt jedoch, welches Verhalten oder welches Bedürfnis sich dadurch wirklich verändert. Spannend ist der Blick auf die Themen, die trotz aller Veränderungen stabil bleiben. Arne spricht darüber, dass Unsicherheit schon immer Teil von Produktmanagement war. Neu ist eher die Geschwindigkeit, mit der sich Annahmen über Märkte, Nutzerverhalten und technische Möglichkeiten verschieben. Gerade deshalb gewinnen Fähigkeiten wie 'Orientierung geben', 'Verantwortung übernehmen' und 'gute Entscheidungen unter Unsicherheit treffen' weiter an Bedeutung. In vielen Unternehmen entstehen Probleme nicht wegen fehlender Technologie. Sie entstehen, weil Teams den Kontakt zu ihren Nutzerinnen und Nutzern verlieren oder weil Produktentscheidungen nur noch aus internen Erwartungen heraus entstehen. Moderne Werkzeuge und KI lösen dieses Problem nicht automatisch. Auch die Diskussion rund um Karrieren im Produktmanagement bekommt dadurch eine neue Richtung. Viele Produktmenschen fragen sich momentan, welche Rolle sie künftig noch spielen, wenn Analyse, Dokumentation oder Konzepte zunehmend automatisiert entstehen. Arne Kittler schaut darauf deutlich differenzierter: Wer Produktmanagement auf Ticketpflege oder reine Verwaltung reduziert, wird austauschbar. Wer dagegen Zusammenhänge erkennt, schwierige Gespräche moderiert und aus Unsicherheit Orientierung entwickelt, bleibt wertvoll. Besonders in größeren Organisationen zeigt sich oft, wie wichtig diese Fähigkeiten bleiben. Dort treffen wirtschaftliche Ziele, technische Möglichkeiten und unterschiedliche Interessen permanent aufeinander. Gute Produktmenschen schaffen es, daraus sinnvolle Entscheidungen für das Produkt abzuleiten. Die diesjährige Product at Heart Konferenz greift genau diese Spannungen auf. Das Motto "What changes? What remains?" beschreibt sehr gut, worum es im Produktmanagement gerade geht. Viele Methoden und Werkzeuge verändern sich sichtbar. Gleichzeitig bleiben Verantwortung, Kundennähe und der Umgang mit Unsicherheit zentrale Bestandteile guter Produktarbeit. Deshalb konzentriert sich die Diskussion nicht ausschließlich auf KI. Auch Themen wie Produktstrategie, Zusammenarbeit oder die Suche nach Klarheit im Alltag behalten ihren Platz. Wenn ihr direkt mit Arne Kittler Kontakt aufnehmen wollt, erreicht ihr ihn über sein LinkedIn-Profil oder über die Website seiner Firma Hey Clarity (hey-clarity.com)

Mukhtar Kadiri: The Three Qualities That Separate Great Product Owners From Those Who Just Drop Tickets The Great Product Owner: Decisive, Versatile, and Credible at Every Level 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.   "This person could hold his own at any level of the organization — with executives, with engineering leadership, and with the team." - Mukhtar Kadiri   Mukhtar describes the best product owner he ever worked with through three distinct qualities. First, this person could operate at any level — equally comfortable in a strategic conversation with executives and in a tactical session with the engineering team. Second, they had vast cross-functional knowledge. They weren't a specialist in any one domain, but they could hold intelligent, credible conversations with marketing, go-to-market, customer success, and engineering alike. And third — perhaps most critically — they were decisive. In ambiguous environments where nobody has done this before, teams need someone who will pick a direction and say "let's find out," even if the decision might be wrong. That decisiveness, combined with the ability to course-correct early, is what separates great product owners from those who leave teams waiting for direction that never comes.   Self-reflection Question: Which of these three qualities — operating at any level, cross-functional credibility, or decisiveness — is strongest in your product owner, and which one needs the most development? The Bad Product Owner: Not Owning the Backlog 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.   "If you don't have a strong product person, engineering just takes over the backlog. And that is dangerous, because it's product that is the representative of the customers." - Mukhtar Kadiri   Mukhtar has seen it happen repeatedly: when a product owner doesn't truly own the backlog, a strong engineering lead steps in and takes over prioritization by default. Things still get built — often beautiful, technically elegant solutions — but they don't produce business value because engineering lacks the customer intimacy that product should bring. The fix isn't simple, but Mukhtar identifies three levers. First, mentorship — pairing a junior product person with a more senior one to build confidence and skills. Second, building technical literacy — a product owner who can't meet engineering halfway will always be seen as an outsider dropping tickets. And third, closing the relationship gap between product and engineering. As Mukhtar points out, a product owner is technically a part of the team, but if the team doesn't feel like they're a part of the team, that gap becomes a chasm. There needs to be real overlap between engineering and product — not just shared meetings, but shared understanding.   Self-reflection Question: Is your product owner truly a member of the team — or are they just someone who shows up to drop tickets and disappear until the next sprint planning?   [The Scrum Master Toolbox Podcast Recommends]

Markus Andrezak spricht in dieser Folge mit Tim über AI im Produktmanagement und was man nach aktuellem Stand bereits alles damit als Produktmensch schon machen kann. Dabei kommen sie schnell zu einer Beobachtung, die viele Teams gerade im Alltag spüren. Während früher ein Großteil der Energie in Backlogpflege, Refinements und die Vorbereitung für die Entwicklung floss, verändert sich heute der Engpass in der Produktentwicklung. Wenn Code schneller entsteht und technische Umsetzung weniger Zeit kostet, geraten andere Fragen in den Vordergrund. Welche Probleme sind wirklich relevant? Wo entsteht echter Nutzen für Nutzerinnen und Nutzer? Und woran erkennt ein Produktteam früh genug, ob eine Idee überhaupt trägt? AI im Produktmanagement verändert damit nicht einfach einzelne Aufgaben. Die Verschiebung geht tiefer. Viele Produktmenschen arbeiten noch mit Routinen aus einer Zeit, in der Entwicklungskapazität der knappste Faktor war. Deshalb drehen sich Prozesse oft um Priorisierung, (politische) Absicherung und detaillierte Übergaben. Markus beschreibt, warum genau dieses Denken gerade unter Druck gerät. Wenn Teams innerhalb kürzester Zeit Prototypen bauen oder Produktideen testen können, verliert das aufwendige "Verwalten" von Anforderungen an Bedeutung. Dafür steigt der Druck, schneller gute Entscheidungen zu treffen und Unsicherheit besser auszuhalten. Wie Markus im Gespräch erwähnt, gibt es beim AI Thema immer wieder Parallelen zur frühen Internetzeit. Viele Regeln entstehen gerade erst. Rollen verändern sich. Praktiken werden neu sortiert. Genau deshalb wirkt AI im Produktmanagement momentan gleichzeitig chaotisch und voller Möglichkeiten. Wer heute schon nach fertigen Antworten sucht, wird schnell frustriert. Wer dagegen bereit ist zu experimentieren, Arbeitsweisen zu hinterfragen und eigene Erfahrungen zu sammeln, entdeckt schon jetzt konkrete Chancen für bessere Produktarbeit. Besonders spannend wird es dort, wo AI im Produktmanagement heute bereits praktisch schon eingesetzt wird. Nicht als magischer Ersatz für Produktarbeit, sondern als Werkzeug im täglichen Denken und Ausprobieren. Markus erzählt von Situationen, in denen Produktteams mit AI sehr schnell unterschiedliche Lösungsansätze erzeugen, Annahmen hinterfragen oder neue Perspektiven auf Nutzerprobleme gewinnen. Gerade in frühen Discovery-Phasen entsteht dadurch Tempo. Gleichzeitig aber warnt er davor, Geschwindigkeit mit Qualität zu verwechseln. Denn viele Teams produzieren plötzlich mehr Ideen, mehr Konzepte und mehr Artefakte, ohne klarer zu verstehen, welches Problem sie eigentlich lösen wollen. Product Owner sitzen oft zwischen Stakeholder-Erwartungen, Delivery-Druck und strategischen Fragestellungen. AI im Produktmanagement verschärft diese Spannung teilweise sogar. Wenn technische Umsetzung leichter wird, steigen häufig die Erwartungen aus dem Umfeld. Dann entsteht schnell die Vorstellung, dass Produktteams nun einfach deutlich mehr liefern müssten. Genau an diesem Punkt lohnt sich der Blick auf Wertschöpfung statt Auslastung. Markus und Tim sprechen darüber, warum Fokus gerade jetzt wichtiger wird und weshalb Produktmenschen lernen müssen, mit den neuen Möglichkeiten bewusst umzugehen statt jedem Hype hinterherzulaufen. Hier gehts zu Infos und Anmeldung zum beschriebenen Kurs "The AI Augmented PM" von Markus: academy.ueberproduct.de Zu diesem Thema passen diese älteren Episoden bzw. z.T. wurden diese Themen auch erwähnt: - Warum scheint die Product Owner Rolle so schwer zu sein? (ganz frühe Folge mit Markus Andrezak - immer noch sehr aktuell) - Mit dem Kano-Modell Kundenbedürfnisse besser verstehen Weitere Folgen mit Markus Andrezak: - Produktstrategie in die Praxis bringen - Unterschiedliche Strategieansätze - Gemeinsamkeiten und Unterschiede - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen?

Peter Merel: From Desk-Pounding to Harmony — How the Game of Go Transformed a Violent Product Owner, and Why Every Employee Should Think Like an Owner In this episode, we refer to The Agile Way by Peter Merel and The Great Game of Business by Jack Stack. The Great Product Owner: The Real Estate Visionary Who Built Channels of Learning Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "When a product owner brings an attitude of learning together, it doesn't just create psychological safety — it creates an active experimental mindset and a network of trust relationships that support each other in the learning process." - Peter Merel   The best product owner Peter has worked with is Ben White, one of three brothers and partners in Ray White — Australia's largest property management business, started by Ben's great-grandfather. Ben had a vision for transforming how property management works across the entire Australian industry. To realize this vision, he tried to bring an app to market — and failed. Not once, but twice, before succeeding on the third attempt. What made Ben exceptional wasn't his persistence alone, but that each failure became an opportunity to learn how to approach the problem differently. The product he finally brought to market was informed by all of that learning. Ben's real genius, Peter explains, is his ability to establish channels of learning — trust relationships that flow not just through the technical team, but throughout the entire business and back into product development. Without those trust relationships, psychological safety alone isn't enough. Peter also emphasizes that the product owner should be a servant leader, and points to Jack Stack's open book management model where every employee is motivated to think and act as a business owner. When everyone understands that the future of the business is their future, they all collaborate as product owners — and the need for desk-pounding disappears entirely.   Self-reflection Question: How many channels of learning does your product owner currently have — and are there trust relationships in the organization that could become active channels but haven't been tapped yet? The Bad Product Owner: The Violent Visionary Who Didn't Understand Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "The problem isn't the role of product owner. The problem is the relationship between product owner and everybody else." - Peter Merel   At Commonwealth Bank of Australia, Peter worked with a business executive who drove the development of a digital product that generated $2 billion in business for the bank. By any business measure, this person was extraordinarily successful. But as a product owner, he was terrible. He pounded desks, went red in the face, insisted that everything the team was doing was wrong, didn't trust anyone, and couldn't be trusted either. The core anti-pattern wasn't the shouting itself — it was that this person didn't understand what a collaborative relationship needed to be. Peter found a creative solution: he taught the executive the game of Go. Go rewards harmony — you lose by being too passive, and you lose by being too aggressive. Through Go, Peter taught the executive to create prompting questions, to work through others so they would carry concerns into meetings, and to provide answers rather than demands. Once the executive saw that collaboration was a more effective way to realize his own vision — faster, better, and more reliably — the behavior changed completely. The insight Peter shares is that before coaching behavior, you sometimes have to prove the business case for collaboration itself.   In this segment, we refer to The Agile Way by Peter Merel, which Peter now gives to product owners as a framework for understanding collaborative relationships.   Self-reflection Question: When you encounter a product owner who leads through demands rather than collaboration, have you considered showing them that collaboration is actually a faster path to getting what they want?   [The Scrum Master Toolbox Podcast Recommends]

Hebben producten nog wel toekomst met al het AI- en Agentic-geweld? En wat betekent dit voor jouw rol als Product Owner? Jochem gaat deze week in gesprek met Eric van der Loo over de drastische impact van AI op ons vakgebied. Want nu AI-tools in één dag software bouwen waar je vroeger maatwerk voor nodig had, staat onze manier van werken compleet op zijn kop. In deze aflevering bespreken ze:  • De toekomst van het product: waarom delivery makkelijker wordt en de User Interface dé onderscheidende factor is.  • Van Delivery naar Discovery: hoe jouw focus verschuift naar het stellen van de juiste vragen en het razendsnel valideren via prototypes.  • Voorkom achterstand: hoe je meebeweegt met de technologie om te voorkomen dat je de overbodige 'Cobol developer van de toekomst' wordt. Een must-listen voor elke toekomstgerichte PO! De Product Owner podcast is een initiatief van productowner.nl

BONUS: Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It Natalia Curusi co-authored a book that doesn't tell you what agile should look like — it tells you what actually happens when you try to transform an organization. Friday-night deployments, zombie teams going through the motions, transformations that met a wall of silence. In this episode, we unpack the real lessons from the front lines: how personal values drive the shift to agile, why some teams have all the ceremonies but none of the substance, and what systems thinking reveals about why transformations fail — or snap back. When Your Values Don't Match Your Ways of Working "I felt like there is a mismatch in my values, my moral values and principles, and customer-centric orientation. So when I found out about Agile around 2010, I understood — okay, this is the answer. Now I have the answer how I can map my moral values and principles with software delivery."   Natalia's journey to agile didn't start with a methodology — it started with a gut feeling that something was wrong. Working in large corporations in the early 2000s with fixed-scope contracts, late deployments, and scripts running directly in production, she sensed a disconnect between how work was done and how it should be done. When she moved to a smaller company around 2010 and experienced transparency, collaboration, and the freedom to ask any question without fear, she realized this was the agile mindset — even before she knew the term. The key insight: agile isn't something you adopt, it's something that aligns with values you may already hold. That alignment between personal principles and ways of working is what makes the difference between going through the motions and genuinely transforming how a team operates. Don't Be an Agile Zombie "The first thing I observe — if I go to some of the ceremonies and I see that stand-up becomes like a status meeting, and everybody is reporting to somebody. People are afraid to say some of the things, afraid to escalate risks or assumptions."   One of the strongest chapters in the book is titled "Don't Be an Agile Zombie." Natalia describes teams that have all the boards, all the roles, all the right meeting cadences — but nothing is actually changing. The Scrum Master becomes a secretary. The Product Owner is a proxy afraid to make decisions. The tell-tale signs? Fear and formality. When people report upward instead of collaborating sideways, when risks go unspoken because the environment punishes transparency, that's a watermelon project — green on the outside, red on the inside. Natalia's approach starts with observing the tone and dynamics in ceremonies. If the stand-up feels like a status report and not a coordination meeting, something deeper is broken. And her advice is direct: if an organization is delivering waterfall and happy with the predictability and value, that's fine — just call it what it is. Don't put lipstick on a pig. As Rebecca Homkes discussed on this podcast, the key is to communicate the truth with care, but communicate it nonetheless. Task-Driven vs. Value-Driven: The Real Spectrum "It's not right to say that you are agile if you are not. Just name the things how they are — name the things using the right word."   Rather than the old waterfall-vs-agile binary, a more useful lens is the spectrum between task-driven and value-driven product development. On the task-driven side, somebody creates the list of tasks — requirements, architecture document, design document — and a project manager distributes them. Teams execute but aren't asked to be creative or adaptable. On the value-driven side, what matters is the impact of what teams build. Value is discovered through the dynamic interaction of functionality with customers — it can't be predetermined. Most organizations sit somewhere on this spectrum, and many are slowly moving toward the value-driven end even if they don't call it agile. The practical takeaway: transformation should be tailored to where an organization actually is, not where a framework says it should be. The book argues for a pragmatic, hybrid approach rather than evangelical purity. Systems Thinking: Why Transformations Snap Back "We did a big agile transformation — five years of real transformation. Then the company was bought, merged with a bigger payment provider. And now they are working with SAFe. And that's the end of the story."   In the later part of the book, Natalia and her co-author move into systems thinking — Cynefin, the Iceberg Model, causal loop diagrams. Many agile practitioners stop before they get here because it feels academic. But Natalia argues it's essential, and she illustrates why with a real example: a payment company that went through five years of successful agile transformation using LeSS, only to be acquired by a larger organization that pushed SAFe — and the transformation snapped back. This is the basin of attraction concept: a system has to pass through a point of genuine disruption before it can settle into a new stable state. Without that, it returns to where it was. For practitioners looking to get started with systems thinking, Natalia recommends The Fifth Discipline by Peter Senge and learning to build causal loop diagrams — a practical tool that creates productive conversations about how organizational dynamics actually work. The Post-Agile Era: Beyond Labels "It's like comparing apples and orchestras. You cannot compare agile and AI — they are completely different things. Agile is not enough, but it's also not dead."   Natalia addresses the "Agile is dead" debate head-on. Her argument: comparing agile to AI is a category error. An apple cannot play an orchestra, and an orchestra cannot replace an apple — they serve entirely different purposes. AI can handle a significant portion of day-to-day tasks, but it lacks common sense, empathy, and the ability to read a room. Rather than declaring agile dead, Natalia sees a post-agile era — not one where agile disappears, but where we move beyond the label wars. The trends that matter aren't about whether agile is popular; they're about collaboration, adaptability, and understanding how teams and organizations actually work. We can finally talk about what matters in our industry without being pressured to label it. About Natalia Curusi Natalia Curusi is an Agile Coach at Endava with over 20 years in software delivery, specializing in agile transformations, delivery optimization, and systems thinking. She leads Asia Pacific initiatives driving business agility. She is co-author of From Resistance to Resilience: Practical Agile Lessons for Transformation.   You can link with Natalia Curusi on LinkedIn and visit her website at nataliacurusi.com. You can also join the Agile Continuum community on LinkedIn.

What does it really take to make AI work, not just technically, but organizationally? In this episode of the Scrum.org Community Podcast, host Dave West sits down with Dr. Alan Brown, researcher, advisor, and author of the new book Making AI Work for Britain, to explore the complex realities of AI adoption in large organizations and government.Drawing on decades of experience in enterprise digital transformation from Rational Software to IBM to advising public sector institutions, Alan unpacks why AI is both an evolutionary step and a fundamental disruption, and why most organizations are struggling to bridge the gap between technological capability and organizational readiness.Alan and Dave explore how lessons from the UK's digital government journey of consolidating demand, diversifying supply, offer a practical lens for every team navigating AI adoption today. They also dig into three principles Alan believes are at the heart of any disciplined approach to AI: value, risk, and trust and why that last one might be the most transformative idea yet for Scrum Teams.Whether you're a Scrum Master, Product Owner, or senior leader trying to make sense of AI in your organization, this conversation offers a grounded, thought-provoking framework for moving from pilot chaos to purposeful delivery.Book details can be found at https://futureofai.uk/Blog: Making AI Work: What Scrum Gets Right and Organizations Get Wrong

Podcast: Don't Panic! It's Just Data Guest: Jignesh Patel, Director of Product Strategy at Stibo Systems and Elsebeth Gundersen Jensen, Product Owner at NetsHost: Dr Joe Perez, Data Analytics Expert and Amazon Bestselling AuthorWe're living in times of an always-on digital economy where there's no room for data errors. In the recent episode of the Don't Panic It's Just Data podcast, host Dr Joe Perez, Data Analytics Expert and Amazon Bestselling Author, sat down with Jignesh Patel, Director of Product Strategy at Stibo Systems and Stibo Systems' customer, Elsebeth Gundersen Jensen, Product Owner at Nets. Perez pointed out that even the smallest inconsistency can "ripple completely across an entire operation, instantaneously." This reality is prompting enterprise tech leaders to rethink how they manage, govern, and use data, especially with the rapid growth of AI adoption.Overall, the guests send out a clear message – trusted, real-time data is now a crucial part of business infrastructure.Also Watch: From Chaos to Launch: Your Product is Ready, Your Data Isn'tWhat is the Hidden Cost of Untrusted Data?For large enterprises, especially those growing through mergers and acquisitions, fragmented data systems are almost unavoidable. Jensen noted that when combining multiple customer portfolios, inconsistencies often arise in even the simplest fields, like organisation numbers formatted differently in various systems.“When you bring in different customer portfolios, you will also get this scattered data picture that you don't want in a master data management system,” she explained.According to Patel, the lack of trusted data impacts four key areas which includes customer experience, revenue growth, decision-making, and operational efficiency. Without a unified customer view, enterprises struggle to offer personalised experiences or spot cross-sell opportunities. Moreover, analytics based on unreliable data undermine executive confidence and increase compliance risks.These issues are made worse by speed. Alluding to her observations, Jensen told Perez and Patel that modern customers expect contract changes or service interactions to be updated almost instantly. “They don't want to wait a day,” she stated. “Everything should be faster, better, and accurate.”Also Watch: Why is a Customer Data Strategy a Competitive Edge?How are Enterprises Mastering Intelligence?Traditionally, Master Data Management (MDM) has focused on creating the “golden record,” a single, reliable version of key business entities like customers or products. While this remains important, Patel believes this idea is changing quickly in the AI era.“MDM is moving beyond data correctness towards what I call mastering intelligence,” he said. “AI systems rely on trusted context—understanding what entities are, how they relate, and the business rules that apply.”This change is part of a larger transformation in enterprise architecture. Decision-making is no longer limited to human-driven dashboards; it is increasingly spreading across applications, analytics platforms, and AI agents acting in real time. In such a setup, inconsistent data does not just create errors but it can amplify it.“AI doesn't eliminate the need for MDM or data governance. It emphasises it,” stated Patel. For enterprises heavily investing in AI, this insight is vital. Without a strong data foundation, AI models might provide insights but not dependable results.As enterprises move toward AI-driven and even agent-based business models, the need for trusted data will grow even more important. Patel highlights new questions from the C-suite – How will AI agents find my products? Why isn't my business being recommended?The answer increasingly depends on structured, high-quality data. “AI success is dependent on trustworthy data,” Director of Product Strategy at Stibo Systems says. “MDM and governance are the foundation for the next generation of intelligent business systems.”For enterprise leaders, the key directive to note is in the race to implement AI, data trust is the competitive edge and not only the requirement. Key TakeawaysReal-time trusted data is essential for enterprise AI success and operational resilience.Poor data quality directly impacts customer experience, revenue growth, and compliance.Modern Master Data Management (MDM) is evolving from “golden records” to AI-ready data intelligence.Proactive data governance must replace reactive data cleanup to scale in real-time environments.A unified data model is the foundation for accurate, consistent, and AI-driven business insights.Chapters00:00 Introduction to Data Governance and MDM02:06 The Shift to Real-Time Data05:27 Business Risks of Lacking Trusted Data08:20 Growth Through Mergers and Acquisitions15:29 The Role of MDM in AI Initiatives20:02 Transitioning to Proactive Data Management22:01 Advice for CIOs on Managing Product DataFor more information, please visit em360tech.com and stibosystems.com. To learn more about AI in the MDM space and how they're progressing enterprise analytics intelligently, follow:Stibo Systems LinkedIn: @StiboSystemsStibo Systems X: @StiboSystemsStibo Systems YouTube: @StiboSystemsGlobalEM360Tech YouTube: @enterprisemanagement360EM360Tech LinkedIn: @EM360TechEM360Tech X: @EM360TechFollow: @EM360Tech on YouTube, LinkedIn and X#MDM #DataGovernance #EnterpriseAI #DataQuality #TrustedData #AIStrategy #RealTimeData #DigitalTransformation #StiboSystems #TechPodcast

Joe Finney is a Product Owner and MVP by day and builds productivity apps for Windows at night. When he is not programming he is birding, running, and enjoying tasty coffee and beer in Milwaukee.You can find Joe on the following sites:BlueskyBlogXGitHubMastodonPLEASE SUBSCRIBE TO THE PODCASTSpotifyApple PodcastsYouTube MusicAmazon MusicRSS FeedYou can check out more episodes of Coffee and Open Source on https://www.coffeeandopensource.comCoffee and Open Source is hosted by Isaac Levin

Viktor Glinka: The Curious Product Owner and the Disempowered One — How Scrum Masters Can Help POs Find Their Voice In this episode, we refer to product owner anti-patterns and product owner interviews on the Scrum Master Toolbox Podcast. The Great Product Owner: The Curious Negotiator Who Uses Data and Passion 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.   "Great product owners are always asking: what if? How can we do it differently? How can we simplify?" - Viktor Glinka   Viktor describes great product owners as fundamentally curious people who constantly look for simpler, better ways to do things. But curiosity alone isn't enough — they're also skilled negotiators who navigate conversations with teams, stakeholders, and customers. In scaled setups, their work shifts from clarification to prioritization, and they delegate effectively. Viktor highlights their visualization skills with a concrete example: one product owner showed stakeholders a work composition chart revealing that more than 50% of the team's work was technical debt, making it impossible to deliver new features. That single visualization changed the conversation. Great product owners are also systems thinkers who understand dynamics and root causes, avoiding local optimization. Viktor adds something rarely discussed in frameworks: mindfulness. Product owners face constant pressure, and the ability to make peace with decisions — to move forward without regret — is critical. They also share their passion and vulnerability with development teams, telling them personally why they want to build something. It's the emotional complement to data-driven negotiation.   Self-reflection Question: Does your product owner use data and visualization to negotiate with stakeholders, or do they rely on authority and deadlines? How could you help them build those skills? The Bad Product Owner: The Disempowered Middleman Who Can't Give Direction 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.   "This fear of not being allowed — it's an illusion. You can always do more. Just try. No one will fire you for a suggestion." - Viktor Glinka   For Viktor, the worst product owner anti-pattern isn't about skill or knowledge — it's about empowerment. He believes every person can learn to become a great product owner if they are empowered and trusted by the organization. The red flags are clear: when a product owner talks about deadlines and commitments but never about return on investment or outcomes, that's a sign they're being pushed rather than empowered. Viktor shares the story of a product owner who was struggling to give direction because stakeholders just wanted their features delivered. He was a middleman — afraid to communicate his own vision to the team, afraid to challenge stakeholders. But inside, there was a spark of passion about the product. Viktor helped him uncover it using a simple tool: the product vision canvas. They sat down together and put his thoughts on paper. Once the vision was written, the product owner started thinking about the next step on his own: "What if I show this to stakeholders? What if I tell them there's a better way?" The product vision canvas became the bridge from learned helplessness to ownership.   Self-reflection Question: Is your product owner telling themselves "I'm not allowed to" when they actually could do more? What's the smallest experiment you could run together to test that assumption?   [The Scrum Master Toolbox Podcast Recommends]

Las ofertas laborales de Product Engineer crecieron 53.6% en 2026. PostHog ($1.4B), Vercel ($9.3B) y Figma ($20B) ya dejaron de contratar developers tradicionales: lo que buscan son Product Engineers — o como Figma los llama, Product Builders. En este episodio, Oz y Tito Neira recorren qué es realmente un Product Engineer, por qué este perfil está unificando los roles de producto, diseño e ingeniería, y cómo la IA se volvió el acelerador imposible de ignorar.00:00 Intro y bienvenida00:43 ¿Qué es un Product Engineer?02:10 De ticket a producción sin ceremonias04:49 El problema de las dependencias en equipos06:30 ¿Puede un Product Owner ser Product Engineer?08:13 "Si tu trabajo no termina en Git, no existe"11:33 Dos tipos de developers14:40 Estadísticas del mercado laboral18:11 Empresas que lo hacen bien: PostHog, Vercel, Figma20:30 El developer que vive en la terminal23:26 Características del Product Engineer ideal27:05 Cuando la IA prioriza mejor que un humano29:41 ¿Es viable sin IA? La respuesta es no32:20 Recomendaciones para developers35:54 Superpoderes para el arquitecto de software39:09 Consejos para empresas42:24 Datos clave y reflexión final✩ CURSOS DISPONIBLES

Discover industrial AI at Hannover Messe with SAP's Matthias Deindl, covering embodied AI, productivity-boosting agents, and demos like ginger-shot packaging, digital twins, warehouse robots and partner integrations. Download the ⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠⁠episode transcript⁠⁠⁠⁠===== This episode explores industrial AI at Hannover Messe (20–24 April) with SAP's Matthias Deindl. Key topics include embodied AI (robots in production, logistics, asset management) and AI agents that enhance productivity and reduce errors. The SAP booth at HMI features a ginger-shot packaging demonstrator, digital twins, humanoid warehouse handling, CNC machining, and partner integrations. Matthias emphasises the importance of accurate, timely data, using SAP Business Data Cloud to enable autonomous tasks like AI-assisted tendering and robot-led inspections. The SAP booth at HMI features a ginger-shot packaging demonstrator, digital twins, humanoid warehouse handling, CNC machining, and partner integrations. The episode envisions seamless disturbance response, improved productivity for an ageing workforce, and stronger human–AI collaboration.  ===== Guest: Matthias DeindlMatthias Deindl is a digital transformation leader focused on discrete industries and supply chains, with more than 17 years of leadership in dynamic, cross-functional environments. At SAP, he currently leads end-to-end product management for Discrete Industries. Previously, he headed supply chain management initiatives across the global SAP Experience Centers network and oversaw the SAP S.Factory Walldorf, helping customers in process and discrete industries accelerate their digital transformation. Before joining SAP, Matthias served as a Group Leader and Product Owner in a corporate IoT startup at Bosch and worked as an Innovation Manager in Corporate Logistics. Earlier in his career, he was a Project Lead and Head of Department in R&D at RWTH Aachen. He has collaborated with customers across automotive, aviation, pharmaceuticals, mechanical engineering, and logistics. Matthias holds a Diplom in industrial engineering from the Karlsruhe Institute of Technology and a doctorate in mechanical engineering from RWTH Aachen.Host 1: Richard Howells⁠⁠⁠⁠Richard Howells⁠⁠⁠⁠ has been working in the Supply Chain Management and Manufacturing space for over 30 years. He is responsible for driving the thought leadership and awareness of SAP's ERP, Finance, and Supply Chain solutions and is an active writer, podcaster, and thought leader on the topics of supply chain, Industry 4.0, digitization, and sustainability.Host 2: Sin ToSin brings over 15 years of experience in the digital media and technology industry – primarily in marketing, business development, thought leadership, and editorial. At SAP, they ensure that SAP's supply chain solutions are properly visible with a focus on future trends and sustainable innovations as part of the Thought Leadership & Awareness Supply Chain Team.===== Show Links:SAP Digital Supply Chain: www.sap.com/scm Visit us at Hannover Messe (HMI): Hall 15, Booth F08Follow Us on Social Media : Matthias Deindl:LinkedIn: https://www.linkedin.com/in/mdeindl/   Richard Howells:LinkedIn: www.linkedin.com/in/richardjhowells Sin To: LinkedIn: www.linkedin.com/in/sin-to-5334208 SAP Digital Supply Chain:LinkedIn: www.linkedin.com/showcase/sapdsc/ Please give us a like, share, and subscribe to stay up-to-date on future episodes!  ===== Chapters: 00:00:00 Vision for AI Supply Chains00:01:51 Meet Matthias and Industrial AI Today00:02:14 Two AI Tracks Robots and Assistants00:03:30 Data Foundations and Business Data Cloud00:05:04 Deployment Challenges and Quick Win Use Cases00:06:46 Embodied AI Inspection Robots00:09:51 Resilience Roadmap Transparency to Agents00:12:25 Human Machine Collaboration at the SAP Booth00:15:41 Ecosystems and Partner Integration00:19:17 Closing and How to Find SAP at Hannover Messe

Nate Amidon: The Leadership Void — What Happens When Product Owners Forget They're Part of the Scrum Team In this episode, we refer to Nate's previous BONUS episode on the brief-execute-debrief cycle and alignment. The Great Product Owner: The Team Player Who Leads From the Trenches 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 best product owners are really part of the team. They attend all the ceremonies, they give their daily stand-up status, they're shoulder-to-shoulder in the trenches." - Nate Amidon   For Nate, the best product owners he's worked with share one defining trait: they act like teammates, not managers. They show up to daily stand-ups and report on what they worked on, what they completed, and what they're blocked on — just like everyone else. They listen to ideas from the team without being dismissive, recognizing that engineers often know the user just as well as they do. They don't treat the product owner role as a position of authority over the team, but as a different function within the same unit. Nate draws from his military background: leadership is "care and feeding of the people." When product owners internalize that the team's success is their success — when they feel genuine allegiance to the people they work with — backlogs get better organized, priorities become clearer, and collaboration happens naturally. As Vasco adds, alignment is the real purpose behind Scrum ceremonies, and when POs are there, alignment follows.   Self-reflection Question: As a product owner, do your team members see you as someone who is part of the team — or as someone the team works for? The Bad Product Owner: The Leadership Void That Creates Corporate Game of Thrones Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "It eventually becomes a leadership void on the team that someone will step up and fill — and usually it's an engineer, or the Scrum Master becomes a quasi-product owner." - Nate Amidon   Nate views the product owner role as fundamentally a leadership position — leadership of the backlog, prioritization, and the connection between business needs and team execution. When a PO doesn't embrace that responsibility, the symptoms are predictable: throwing half-baked stories over the fence with a "just figure it out" attitude, constantly shifting priorities without considering the downstream impact on a team that just spent two weeks building something, and being absent from the daily conversations that keep everyone aligned. What follows is what Nate calls a "leadership void" — someone else on the team, often an engineer or the Scrum Master, steps in as a quasi-product owner because the work still needs direction. Meanwhile, without a PO acting as a filter, stakeholders start shoulder-tapping the team directly, competing directors play corporate Game of Thrones over whose priorities win, and the team gets whiplashed between conflicting demands. The biggest red flag? When you hear the team say: "We just did what you told us."   Self-reflection Question: If your product owner disappeared for two weeks, would anyone on the team notice a gap in leadership and direction — or has someone already quietly stepped in to fill that void?   [The Scrum Master Toolbox Podcast Recommends]

Como comunicar decisões difíceis de priorização sem comprometer relacionamentos estratégicos cruciais para o negócio? Neste Enzimas, Diêgo Ivo Gonçalves, Product Owner na dti digital, traz dicas para transformar o temido 'não' em uma ferramenta de fortalecimento de vínculos com stakeholders. Ele compartilha estratégias práticas para alinhar expectativas desde o primeiro dia e posicionar negativas como escolhas consultivas que protegem investimentos. Ficou curioso? Então, dê o play!Assuntos abordados:Gestão de expectativas estratégica;Alinhamento desde o dia zero;Escuta ativa para stakeholders;Backlog como tabuleiro de investimentos;Transparência na comunicação;Links importantes:NewsletterDúvidas? Nos mande pelo LinkedinContato:  osagilistas@dtidigital.com.brOs Agilistas é uma iniciativa da dti digital, uma empresa WPP #enzimas #lideranca

Bhavin Shukla: The Adaptable Product Owner — How Progress Over Perfection Drives Real Value in Scrum In this episode, we refer to story mapping as a key tool for maintaining focus and alignment. The Great Product Owner: Embedding Prioritization as a Daily Discipline Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "She had this section called 'Not Required Anymore.' Every time, it was a very subtle and a very respectful way of saying to the team: great idea, but the goals changed. We don't need it anymore." - Bhavin Shukla   Bhavin describes a Product Owner who turned prioritization into a living discipline. She built a culture of co-creation where everyone contributed ideas to the backlog, but she also saw the biggest risk coming early: misalignment from siloed ideas. Her approach was to use story maps extensively in refinements and planning, communicating weekly with customers to collect feedback. When the direction changed — and it regularly did — she articulated the shift clearly: "Goals changed, here's what we're doing now." Her stroke of genius was a section on the story map called "Not Required Anymore," where deprioritized ideas landed respectfully. Nobody felt offended; they understood customers' needs had shifted. This created a culture where people kept contributing ideas courageously, knowing that even if priorities changed, their input was valued. The result was a team that could adapt without chaos, maintaining focus while embracing change.   Self-reflection Question: How does your Product Owner communicate changes in direction? Is there a respectful, transparent mechanism for showing the team what's no longer needed — and why? The Bad Product Owner: The No-Feedback Product Owner 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.   "I was looking for those keywords — a change in priorities, a change in the roadmap. Those conversations were missing. And when I asked about the roadmap, I got crickets." - Bhavin Shukla   Bhavin shares the story of a Product Owner who was brilliant at articulating value in the backlog — customer-centric stories, well-structured work. On the surface, everything looked great: goals were being met, the team was delivering. But something subtle was wrong. The roadmap never changed. Priorities never shifted. There were no conversations about customer feedback changing direction. When Bhavin got curious and asked to see the roadmap, he realized it was a static delivery plan, not a living document. The Product Owner wasn't collecting feedback from customers, so there was never a reason to adapt. The team was essentially building in a vacuum — shipping features nobody was validating. It's an anti-pattern that's easy to miss when the team is performing well on internal metrics but disconnected from real customer value.   Self-reflection Question: Is your team's roadmap a living document that changes based on customer feedback, or has it become a static delivery plan? When was the last time a priority genuinely shifted based on what you learned from users?   [The Scrum Master Toolbox Podcast Recommends]

Bhavin Shukla: Why Scrum Master Success Means Confronting the Ugly Truth With Data 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.   "Success is not always good vibes, good environment for us as Scrum Masters. For me, it's about confronting the reality, the ugly truth, which takes the team to tougher conversations, more constructive challenges." - Bhavin Shukla   Bhavin shares a pivotal moment in his career that redefined what success means for a Scrum Master. He was working with a fantastic team — great culture, people who believed in quality, knowledge sharing, strong bonds. But sprint goals weren't being met, and stakeholders were constantly chasing the Product Owner and Scrum Master for answers. Bhavin got his hands dirty with the data: lack of clarity on work, context switching, patterns emerging. When he presented the data to the team, he was met with silence — a confronting kind of silence. The team was essentially saying, "We were happy. Why would you do this to us?" Bhavin's response was direct: going for coffees and laughing together isn't the whole job. If he wasn't showing them reality, he couldn't look at himself in the mirror. The team eventually used that data to raise their own voice, pointing out systemic issues with external vendors and organizational constraints. The data gave them a platform to speak truth — not as blame, but as discovery.   Self-reflection Question: What conversations did you avoid this week that could have unlocked progress for your team? Are you bringing data to those conversations, or relying on vibes? Featured Retrospective Format for the Week: Newspaper Headline Retrospective Bhavin shares an unconventional use of the newspaper headline technique — typically used for roadmaps and vision — as a retrospective format. The idea is simple but powerful: ask the team to write the newspaper headline they want to see about themselves. What would the story say when they succeed? By authoring their own headline, the team takes ownership of the narrative — they define what success looks like, what must go right, and what risks could derail them. "Putting them in that newspaper headline, they authored the story. They own the accountability to make it successful," Bhavin explains. He also shares a second technique for Kanban teams under pressure: a rolling two-column whiteboard — "Frustration of the Day" and "Success of the Day" — with no meetings required, just real-time data capture that becomes a continuous retrospective, reviewed every 2-3 weeks.   [The Scrum Master Toolbox Podcast Recommends]

Suas reuniões com times técnicos geram decisões ou apenas mal-entendidos? Neste Enzimas, Júlia Faria Silva, Product Owner na dti digital, traz dicas para facilitar a comunicação entre times técnicos e executivos com foco em extrair respostas objetivas sobre o impacto real das entregas de tecnologia. Ela explica a diferença crucial entre o que é entregue e o que realmente gera valor, e como superar o desalinhamento que torna reuniões improdutivas. Ficou curioso? Então, dê o play!Assuntos abordados:Comunicação entre C-level e times técnicos;Desalinhamento em reuniões;Medição de impacto;Comunicação focada em resultados;Entregas x resultados.Links importantes:NewsletterDúvidas? Nos mande pelo LinkedinContato:  osagilistas@dtidigital.com.brOs Agilistas é uma iniciativa da dti digital, uma empresa WPP #enzimas #lideranca 

Iryna Stelmakh: The Firewall Product Owner, Turning PO Anti-Patterns Into Opportunities for Growth 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: Market-Oriented and Vision-Driven "Great product owners don't just manage backlog items — they own the product vision and make sure the team understands how their work creates real value." — Iryna Stelmakh   Iryna describes the best product owners she's worked with through three qualities. First, they understand the market and the users deeply. Second, they can explain the business logic behind decisions — not just what to build, but why it matters. Third, they work closely with the team and treat them as partners in solving problems, not executors of tasks. The best PO Iryna worked with was responsible for sharing the business mindset, giving the team perspective and the possibility to contribute beyond the technical work. Everything was organized around a shared goal, and the team understood how their work created real value. As Vasco observes, when a PO just drops tasks without explaining why they matter, the team becomes "just a pair of hands." Great product owners create allegiance through understanding.   Self-reflection Question: Does your product owner share enough business context that your team could independently suggest features or improvements — or are they only able to execute what they're told? The Bad Product Owner: The Firewall Who Blocks All Business Context "We were working without the product mindset, without the product vision." — Iryna Stelmakh   Iryna shares the story of what she calls the Firewall Product Owner — a PO who constantly said "I need to go ask someone" for every decision, but never brought back answers. The result: backlog items lacked clarity, priorities changed frequently, and the team couldn't understand the real product direction. They were working without a product mindset or vision. As Vasco frames it, this PO wasn't just a proxy — they were a firewall, blocking the team from accessing any business context or market knowledge. The team couldn't reach the market representatives because they didn't even know who was on the other side.   Iryna's approach to this kind of situation: escalate with suggestions, not just complaints. Turn problems into opportunities and extensions — propose bringing in a business analyst to support the PO, or suggest restructuring the communication between the business and technical sides. In her case, the client eventually recognized the problem and replaced the PO with someone who could actually bridge the gap. The new PO changed everything.   In this episode, we also refer to the concept of turning problems into opportunities.   Self-reflection Question: When your product owner is unable to provide timely answers, do you escalate with specific suggestions for improvement — or do you simply wait and hope things get better?   [The Scrum Master Toolbox Podcast Recommends]  

It's another Reddit grab bag as we answer some folks questions about career path options for Product Owners, how to get the most out of your 1:1 time with your manager, and whether Product Managers and Project Managers are interchangeable. Join the discussion on Reddit: https://www.reddit.com/r/AcceptanceCriteria/ And on the Discord: https://discord.gg/2Tyj8H9MFF The post E070: Taking control of your career direction through new roles, and other Reddit ?s first appeared on Acceptance Criteria.

Junaid Shaikh: Product Owner Anti-Patterns, From Team Owner to Product Owner, And The PO Who Got It Right Junaid opens with a line that cuts straight to the most common PO anti-pattern: "You are the product owner, not the team owner." When he sees a PO slipping into command-and-control mode, he asks them one question: "What is your role?" They say "Product Owner." He says: "Exactly. You own the product, not the team. If you were meant to own the team, we'd call you a project manager." The worst case he witnessed: a PO who was so possessive of "his" team that he required approval on everything — processes, tools, even holiday requests. In sprint planning, he would assign stories to individual team members ("Mr. X, you take this one"). He'd estimate the work himself, and when developers pushed back, he'd override them: "I was a developer, I know how long this takes." For approaching PO anti-patterns, Junaid has a deliberate style: he doesn't confront upfront. He observes, takes notes, and starts by solving a smaller impediment to demonstrate he's there to help. Once trust is built, he brings in coaching tools — first teaching the basics ("this is what the PO role is in Scrum"), then gradually coaching on specific anti-patterns observed in practice. He targets 10-15% improvement at a time. Six months later, you've already achieved 30-40% improvement. The best PO Junaid has worked with had four qualities: clear, concise communication; an open mindset willing to be coached; courage to say "no" when needed; and the discipline to define the "what" and leave the "how" to the team. This PO started with five sources of truth — Excel tabs, whiteboards, JIRA, and other tools. When Junaid pointed out that five sources of truth is the opposite of transparency (one of Scrum's three pillars), the PO asked for help. Junaid's response: "I can't do the push-ups for you." Together, they consolidated everything into one tool. The team was happier, and the PO managed the backlog much better. The key lesson: great product owners trust their team, communicate clearly, prioritize ruthlessly, and have the courage to say no. And they don't try to own the team. You can link with Junaid Shaikh on LinkedIn. [The Scrum Master Toolbox Podcast Recommends]

Hoje o papo é sobre algo que pode ou não ser polêmico. Neste episódio, mergulhamos na história, nos desafios, no presente e no futuro das pessoas profissionais agilistas que, muitas vezes, encontram empecilhos dentro da própria empresa na tentativa de colocar em prática a cultura ágil nas organizações. Vem ver quem participou desse papo! André David, o host que fala da receita do bolo Yago Oliveira, Coordenador de Conteúdo Técnico na Alura Igor Regis, especialista em TI no BB Cleidiane Silva, Product Owner na CI&T Links: Scrum Desenvolvimento ágil de software Kanban Team Topologies Garanta até 22% de desconto para estudar por até dois anos na Alura! TechGuide.sh, um mapeamento das principais tecnologias demandadas pelo mercado para diferentes carreiras, com nossas sugestões e opiniões. #7DaysOfCode: Coloque em prática os seus conhecimentos de programação em desafios diários e gratuitos. Acesse https://7daysofcode.io/ Produção e conteúdo: Alura Cursos de Tecnologia – https://www.alura.com.br Edição e sonorização: Rede Gigahertz de Podcasts

Nigel Baker: Accountability Requires Ability—Why Powerless Product Owners Are Sacrificial Lambs 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.   In this episode, we refer to the importance of product ownership and empowerment in Scrum teams. The Great Product Owner: The Empirical PO Who Navigated Like a Slalom Skier "He had an idea of the outcomes he had to achieve, and the solution itself—though he had strong beliefs about it—he was incredibly open-minded to feedback from the engineering teams. Most of the innovation came from his engineering teams." - Nigel Baker   The best Product Owner Nigel ever worked with operated with a startup mentality, even within a larger organization. This PO had a clear vision—not for a specific end solution, but for an end state of the world. He ran experiments, learned continuously, and had a remarkable ability to pivot smoothly during development.  Nigel compares him to a slalom skier: smoothly navigating from post to post, making it look natural rather than effortless. What made him extraordinary was his openness to feedback from engineering teams—most of the product's innovation actually came from the engineers suggesting possibilities, and this PO would absorb those ideas and weave them into the direction.  The engineering teams felt secure because they trusted his judgment. He didn't tell people to trust him—he demonstrated trustworthiness through consistent behavior. It was genuine servant leadership: not making a fuss about being in charge, but leading by showing new, cool, interesting behaviors that allowed everyone to follow naturally.   Self-reflection Question: Does your Product Owner have a vision for the end state of the world they're trying to create, or are they locked into a specific solution? The Bad Product Owner: The Powerless PO Who Can't Say Yes or No "Accountability requires ability. If they want you to take responsibility for this work, you have to have the ability to see that through. Without that, you're a sacrificial lamb." - Nigel Baker   Nigel has seen many PO anti-patterns, but the most damaging one is the powerless Product Owner—someone with all the skills of a business analyst but none of the authority to say yes or no. Commitments get made outside the team, direction can't be changed within sprints, and the whole experience gets crushed.  Early in his career, POs were powerful but IT-ignorant business people—dangerous, but at least they had authority. Today's anti-pattern is far worse: people playing the PO role without the O—the ownership. Nigel's approach is direct: he uses the phrase "accountability requires ability" to help the PO understand their position, then traces up the organizational line to find the person who actually holds real power.  He reveals to that person that they are, in fact, the Product Owner—and 9 times out of 10, they immediately delegate the authority officially to someone, which is exactly what was needed. That official delegation transforms a sacrificial lamb into a genuine Product Owner with the power to steer.   Self-reflection Question: Does your Product Owner have genuine authority to make decisions, or are they a sacrificial lamb accountable for outcomes they can't control?   [The Scrum Master Toolbox Podcast Recommends]

Nigel Baker: Why Scrum Masters Should Be Measured on Outcomes, Impacts, and Team Happiness 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.   "No customer's going to come to you and say, do you know why I bought your product? Your remarkable compliance with your internal development process. What they're interested in is outcomes and impacts." - Nigel Baker   Nigel challenges the traditional ways of measuring Scrum Master success. He points to tools like the Nokia test—which, he jokes, was neither a test nor invented by Nokia—as examples of process fidelity assessments that miss the point entirely. Compliance with a process tells you nothing about whether customers are satisfied or whether the team is delivering value. Instead, Nigel argues for measuring Scrum Masters on outcomes and impacts: customer satisfaction, revenue generation, and efficiencies—the same things a Product Owner gets judged on.  But he adds a crucial dimension that POs often overlook: team happiness. Not as an end goal, but as a leading indicator. Happy teams don't leave. Happy teams do better work. Team contentness is a KPI that signals whether the deeper success factors are in place. When your team is deeply unhappy, no amount of velocity or story completion will save you from attrition and decline.   Self-reflection Question: How are you currently measuring your success as a Scrum Master—on process compliance, or on the outcomes, impacts, and wellbeing your team actually delivers? Featured Retrospective Format for the Week: Keep It Fresh—A Different Format Every Sprint Nigel's answer to the "favorite retrospective format" question is deliberately controversial: he doesn't have one. His approach is to use a different format every single sprint. Retrospective formats, he argues, "age like milk"—by Sprint 12, asking "what should we do differently?" with the same structure produces diminishing returns. Novelty creates energy. He sometimes gets teams to invent their own formats, which produces some of the most forensic and intense retrospectives he's seen—teams building "superweapons" and then realizing they have to turn those weapons on themselves. But Nigel's most practical tip is using retrospective techniques inside the Sprint Review. The Review is a product retrospective, and stakeholders shouldn't sit "like Roman emperors in the Colosseum, watching the developers as gladiators." Instead, use facilitation methods to extract "sweet, juicy, honey-flavoured feedback" from stakeholders about what they'd change in the product.   [The Scrum Master Toolbox Podcast Recommends]

Prabhleen Kaur: The Art of Coaching Product Owners on What vs. How 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: Master of Stakeholder Relationships and the Power of No "The best PO is the person who has the superpower of saying no, and they can deal with the stakeholders with the same prowess." - Prabhleen Kaur   Prabhleen describes working with a Product Owner who managed multiple stakeholders—not just a handful, but a significant number with competing priorities. What made him exceptional was his deep understanding of each stakeholder's pulse and motivations. He knew when to push back and how to frame the "no" in a way that stakeholders could accept. This wasn't random resistance—it came from thorough preparation manifested in clear roadmaps that made most incoming work predictable for the team.  His user stories stood out for their richness in context: beyond the business requirements, they included information about who would be impacted, which proved invaluable for a team dealing with multiple interconnected systems.  He leveraged JIRA's priority field effectively, ensuring the moment anyone opened the board, they could immediately understand what mattered most. Prabhleen emphasizes that this PO understood his role as the "what" while respecting the team as the "how." By maintaining strong stakeholder relationships built on mutual understanding, he created space for the team to prepare, plan, and deliver without constant firefighting.   Self-reflection Question: Does your Product Owner have the preparation and stakeholder relationships needed to confidently say "no" when priorities compete, or does every request become an emergency? The Bad Product Owner: Technical Experts Who Manage the Sprint Backlog "The PO is the what, and the team is the how. When POs start directing the team about how to do things, the sprint goal gets compromised." - Prabhleen Kaur   Prabhleen addresses a common anti-pattern she's observed repeatedly: Product Owners with technical backgrounds who cross the line from "what" into "how." When POs come from developer or technical roles, their expertise can become a liability if they start prescribing solutions rather than defining problems.  They direct the team on implementation approaches, suggest specific technical solutions in user stories, and effectively manage the sprint backlog instead of focusing on the product backlog. The consequences are predictable: stories keep getting added or removed mid-sprint, the sprint goal becomes meaningless, and the team ends up delivering nothing because focus is constantly shifting.  Prabhleen's solution starts in backlog refinement, where she ensures conversations about technical approaches happen openly with the whole team during estimation. When a PO suggests a specific implementation, she facilitates discussion about alternatives, allowing the team to voice their perspective.  The key insight: everyone comes from a good place—the PO suggests solutions because they believe they're helping. The Scrum Master's role is to create space for the team to own the "how" while helping the PO see the value in stepping back.   Self-reflection Question: When your Product Owner has technical expertise, how do you help them contribute their knowledge without directing the team's implementation choices?   [The Scrum Master Toolbox Podcast Recommends]

Prabhleen Kaur: When Team Members Raise Concerns with Clarity, Not Anger 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.   "My idea of success as a Scrum Master is when you look around, you see motivated people, and when something goes wrong, they come to you not in anger, but with concern." - Prabhleen Kaur   Prabhleen offers a refreshing perspective on measuring success as a Scrum Master that goes beyond velocity charts and feature counts. She shares a pivotal moment when her team was in production, delivering relentlessly with barely any time to breathe. A team member approached her—not with frustration or blame—but with thoughtful concern: "This is not going to work out." He sat down with Prabhleen and the Product Owner, explaining that as the middle layer in an API creation team, delays from upstream were creating a cascading problem.  What struck Prabhleen wasn't just the identification of the issue, but how he approached it: with options to discuss, not demands to make. This moment crystallized her definition of success. When team members feel safe enough to voice concerns early, when they come with ideas rather than accusations, when they see themselves as part of the solution rather than victims of circumstances—that's when a Scrum Master has truly succeeded.  Prabhleen reminds us that while stakeholders may focus on features delivered, Scrum Masters should watch how well the team responds to change. That adaptability, rooted in psychological safety and mutual trust, is the true measure of a team's maturity.   Self-reflection Question: When problems emerge in your team, do people approach you with defensive anger or constructive concern? What does that tell you about the psychological safety you've helped create? Featured Retrospective Format for the Week: Keep-Stop-Happy-Gratitude Prabhleen shares her favorite retrospective format, born from necessity when she joined an established team with dismal participation in their standard three-column retrospectives. She transformed it into a four-column approach: (1) What should we keep doing, (2) What should we stop doing, (3) One thing that will make you happy, and (4) Gratitude for the team. The third column—asking what would make team members happy—opened unexpected doors. Suggestions ranged from team outings to skipping Friday stand-ups, giving Prabhleen real-time insights into team needs without waiting for formal working agreement sessions. The gratitude column proved even more powerful. "Appreciation brings a space where trust is automatically built. When every 15 days you're sitting with the team making a point to say thank you to each other for all the work you've done, everybody feels mutually respected," Prabhleen explains. This ties directly to the trust-building discussed in Tuesday's episode—using retrospectives not just to improve processes, but to strengthen the human connections that make teams resilient.   [The Scrum Master Toolbox Podcast Recommends]

Juliana Stepanova: Why "I'll Just Do It Myself" Is the Most Expensive PO Shortcut 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.   In this episode, we refer to previous discussions about team collaboration and Product Owner patterns. The Great Product Owner: Opening Up to the Team for Solutions "The PO who's not sitting and saying 'I know how it's right, I will solve it by myself,' but coming and saying 'Hey, let's think all together'—that's what gives very, very speed-up development into becoming a great PO." - Juliana Stepanova   Juliana describes the Product Owners she considers truly great as those who bring their challenges to the team rather than solving everything alone. Her example features a PO who was invited to recurring release meetings that consumed one and a half to two hours every two weeks—30 people in a room, largely a waste of time. Instead of suffering in silence or trying to fix it alone, this PO approached the team: "Hey guys, I have these meetings, and they're useless for me. How can we deal with that?" The team collaborated with the Scrum Master to explore multiple options.  Together, they developed a streamlined, semi-automatic system that reduced the process to 10 minutes without requiring anyone to sit in a room. This solution was so effective that it was eventually adopted across the entire company, eliminating countless hours of wasted meetings. The key insight: great POs see themselves as part of the team, not above it. They're open to solutions from anyone and understand that collaboration—not individual genius—drives real improvements.   Self-reflection Question: When facing challenges that seem outside the team's domain, do you bring them to the team for collaborative problem-solving, or do you try to solve them alone? The Bad Product Owner: The Loner Who Does Everyone's Job "To make it quicker, I will skip asking the designer, I will directly put it by myself. I learned how to design five years ago. But afterwards, it's neglecting the whole team—you don't take into account the UX, and actually you need to rework." - Juliana Stepanova   The anti-pattern Juliana sees most frequently is the "loner" PO—someone who takes on other roles to move faster. The classic example: a PO who bypasses the UX/UI designer because "I learned design five years ago, I'll just do it myself." This behavior seems efficient in the moment but creates multiple problems. It disrespects the expertise of team members, undermines the collaborative nature of agile development, and almost inevitably leads to rework when the shortcuts create quality gaps.  Juliana points out this isn't unique to POs—developers sometimes bypass testers for the same "efficiency" reasons. The solution isn't punishment but cultural reinforcement: helping people see the value of professional work, encouraging communication and openness, and building respect for each role's contribution. The key principle: if someone hasn't asked for help, don't assume they need yours. Focus on your own job, and offer assistance only when invited or when you explicitly ask "Do you need help?"   Self-reflection Question: When have you taken on someone else's role because it seemed faster, and what was the real cost of that shortcut?   [The Scrum Master Toolbox Podcast Recommends]

Juliana Stepanova: Trust Over Escalation — A Patient Approach to Difficult PO Relationships 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 team still believes it could be solved with proper communication to the PO. My idea is to really try, in a supportive way, to build trust, to encourage communication, and to come to the solution as a team altogether. This is like a win-win situation." - Juliana Stepanova   Juliana brings a challenge that many Scrum Masters will recognize: a Product Owner who doesn't want to be coached and whose behaviors are undermining Scrum rituals. The situation is complicated by organizational structure—the Scrum Master reports to the people department while the PO reports to the product department, creating misaligned directions with no common leadership thread.  The PO arrives at refinement meetings unprepared, writing user stories on the spot while eight team members sit idle for hours. When Juliana explores the root cause, she discovers the PO is genuinely overwhelmed with responsibilities outside the team. But here's the twist: this newly promoted PO is proud of the role and resistant to accepting help, preferring to say "just wait, I will manage it."  Rather than escalating—which Juliana notes would damage trust for years or potentially lose the PO entirely—she advocates for a patient, collaborative approach. The experiment she designs focuses on engaging more deeply with the PO's activities to understand which tasks could be delegated or eliminated, while continuing to build trust through support rather than confrontation. The team maintains hope that the PO will eventually accept help, choosing persistence over escalation.   In this segment, we talk about coaching Product Owners and building trust.   Self-reflection Question: When facing a resistant stakeholder, do you default to escalation, or do you invest in building the trust that enables genuine collaboration?   [The Scrum Master Toolbox Podcast Recommends]

This week on The GovNavigators Show, Robert and Adam are joined by Venice Goodwine, former CIO of the Department of the Air Force and current CIO and Product Owner at Arlo Solutions, for a candid conversation about leadership, culture, and change across government. Venice reflects on a remarkable career spanning more than three decades of active-duty and reserve service, senior executive roles at the Department of Agriculture and the Air Force, and hands-on leadership across nearly every military service. She shares how navigating wildly different organizational cultures shaped her leadership style, why mission understanding matters more than titles, and what it really takes to modernize enterprise IT at scale.The discussion also dives into major accomplishments, including IT-as-a-service transformations, cybersecurity improvements, early GenAI experimentation inside DoD, and lessons learned from retiring (twice!) and choosing to keep contributing. Venice closes with advice for today's public servants navigating uncertainty, efficiency mandates, and cultural resistance, emphasizing curiosity, coalition-building, and keeping the end mission in mind.Show Notes:H.R.7148: Consolidated Appropriations ActReform For ResultsWhat's on the GovNavigators' Radar:Feb 3: ITI's The Intersect 2026Feb 5: Shared Services Leadership Coalition Government Efficiency Roundtable

Agile in Construction: The Product Owner Role in Construction—Voice of the Customer Across Every Phase With Felipe Engineer-Manriquez 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. In this episode, we refer to Extreme Ownership by Jocko Willink and Team of Teams by General Stanley McChrystal, as well as our Agile in Construction episodes. The Great Product Owner: Bringing the Voice of the Customer to Every Decision "I want you to think like the owner, and bring that to the team meetings, because we can't have the owner in the meetings with us." - Felipe Engineer-Manriquez   The Product Owner role in construction is radically different from software—and Felipe has learned to find it in unexpected places. When Jeff Sutherland told his class to "tear up your business cards" because only three roles exist (Developer, Scrum Master, Product Owner), construction people were confused. Felipe's approach: ask the team who can bring the voice of the customer. Sometimes it's the superintendent, interfacing daily with charge nurses and doctors in a working hospital. Sometimes it's a project executive. Rarely, it's the project manager. The key is that the PO role changes across phases because every day in construction is brand new—the building is physically taking shape. Felipe studied military leadership in Extreme Ownership and Team of Teams and found strong product owner culture—leaders who brought customer voice to cell-level teams against hierarchical norms. Great product owners speak in terms of what the customer wants, transforming how teams prioritize and align naturally.   Self-reflection Question: Who on your team currently embodies the voice of the customer, and how might you coach them to bring that perspective more explicitly to every team interaction? The Bad Product Owner: When Gut Decisions Override Value "Value is a beneficial transformation of materials, information, or a combination of both. Let's not do things that don't transform information or materials." - Felipe Engineer-Manriquez   Felipe shares a powerful anti-pattern: owners who make gut decisions based on past project trauma without checking if conditions are still true. On a $100 million project, an owner repeatedly introduces work that doesn't add value—reacting to bad things that happened on previous projects, even when those conditions no longer exist. The result? Teams waste time on activities that don't transform materials or information. Felipe teaches teams an industrial engineering definition of value: "a beneficial transformation of materials, information, or a combination of both." Status updates that don't change behavior are waste. Markings on metal decking that will be buried under 5 inches of concrete are waste. The fix? Make the backlog visible and ask: "Where should we zipper this in so it has the most impact on transforming materials or information?" For construction, prioritization always comes back to getting the right materials in place, one time, at the right time—not touching things twice.   Self-reflection Question: When stakeholders introduce work based on past experiences, how do you help them evaluate whether those conditions still apply to the current situation?   [The Scrum Master Toolbox Podcast Recommends]

Cristina Cranga: Coaching Product Owners From Output Obsession to Value Conversations 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.   In this episode, we refer to the work of Esko Kilpi on conversations and episodes on Nonviolent Communication (NVC) on the podcast. The Great Product Owner: A People Person Who Clarifies Before Deciding   "He was comfortable saying 'I don't know yet. What do you think?' It was a bi-directional conversation, not just one-way." - Cristina Cranga   The best Product Owner Cristina worked with was fundamentally a people person and a leader—human skills, not just hard skills. What made him exceptional was his approach to conversation: he started by clarifying the problem first, then decided. By doing this, he separated requests from decisions and made trade-offs explicit.  He was comfortable admitting uncertainty, asking "What do you think?" and engaging the team in co-creation rather than issuing directives. Cristina emphasizes that between the PO and Scrum Master, there's a special bond—a strong leadership partnership that teams look to as a reference. She highlights the concept of "ask more, say less": when you ask questions, you collect information that leads to better, more validated decisions.  The communication process, as outlined in Nonviolent Communication by Marshall Rosenberg, has four components: observation, feelings, needs, and requests. Great POs embody this by treating uncertainty as part of their job, engaging teams more deeply, and connecting work to value rather than just output.   Self-reflection Question: How often does your Product Owner ask "What do you think?" and what would change if they separated requests from decisions more explicitly? The Bad Product Owner: Output Obsession and the Velocity Trap "Success is measured by how much is delivered, not what changes. Teams get faster, but not smarter." - Cristina Cranga   The worst Product Owner anti-pattern Cristina has witnessed is output obsession—measuring success by how much is delivered rather than what actually changes for users or the business. When velocity replaces outcomes as the primary metric, teams get faster but not smarter. Faster doesn't equal smarter. This anti-pattern is particularly dangerous in an AI-accelerated environment where delivery speed is no longer a constraint. The challenge for practitioners is shifting this mindset. The strongest POs make different choices: they own their decisions at the team level, make decisions explicit, treat uncertainty as part of the job, and connect work to value. When POs break free from output obsession, the results are powerful: faster alignment, no decision hallucinations, more engaged teams willing to experiment, and genuine connection between work and value.   In this segment, we refer to Nonviolent Communication by Marshall Rosenberg.   Self-reflection Question: If you removed velocity from your team's dashboard tomorrow, what conversations would emerge about actual value delivered?   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: The One Question That Transforms Messengers Into Product Owners The Great Product Owner: The Calm Navigator Who Shields the 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.   "He said "no" often, but he did it with such clarity that people respected it. It's not just no—it's giving the reason why." - Mohini Kissoon   Mohini has had the privilege of working with many great Product Owners, but one stood out for his calm demeanor and ability to navigate complex situations. Whatever stakeholders threw at him, he remained professional and calm—and critically, he never transferred that pressure onto the team. He had built strong relationships with stakeholders and was the go-to person who commanded respect across the organization.  When stakeholders demanded features that didn't align with team goals, he would acknowledge the request, explain the trade-offs, and offer to revisit it once the current direction was validated. He said no often, but with such clarity and reasoning that people respected his decisions.  This Product Owner also shielded the team from ad hoc requests, handling stakeholder bypass attempts so developers could maintain focus. He would only bring truly urgent items—like compliance issues—directly to the team.  With his helicopter view, he understood how incoming work would impact different stakeholders and parts of the business. Most importantly, he was a good listener who gave the team space to grow and experiment while challenging them constructively.   Self-reflection Question: When you work with your Product Owner, do they shield the team from chaos or pass it through unfiltered—and how might you help them develop that protective capability? The Bad Product Owner: The Messenger Who Couldn't Say No 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.   "When the team would ask 'why are we building this?' the answer would be 'because sales asked for it.' There was no triaging, no challenging stakeholders—just saying yes." - Mohini Kissoon   Mohini shares a story about a Product Owner who appeared to be doing everything right on paper: attending ceremonies, responding to questions, being present for the team, and working closely with stakeholders. But the team was constantly frustrated with scope creep, and the root cause was that this Product Owner was operating as a messenger, not a decision maker. She would bring requests from stakeholders directly into the backlog with no prioritization based on value and no pushback.  Major new work would appear at sprint planning that hadn't been discussed during backlog refinement. The team was committing to 100 story points but only completing 40, with items constantly carrying over.  When Mohini was brought in to help, she asked one simple question that changed everything: "What is the vision for your product?" The Product Owner couldn't answer—because nobody had ever asked her before.  Mohini ran a product vision workshop with her and key stakeholders, created a one-page strategy identifying target users, core problems, and success metrics, and established a working agreement that backlog items must align with identified goals. She also introduced prioritization sessions involving stakeholders. The transformation came when the Product Owner finally felt equipped to say no with informed reasoning.   Self-reflection Question: Does your Product Owner have a clear product vision they can articulate, and if not, what workshop or conversation could you facilitate to help them discover it?   [The Scrum Master Toolbox Podcast Recommends]

Mohini Kissoon: When Politeness Becomes the Enemy of Team Growth—Escaping the Conflict Avoidance Trap 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.   "Conflict isn't the enemy. It's when we're avoiding conflict that it becomes an issue for teams." - Mohini Kissoon   Mohini shares a story about the worst self-destructive pattern she has witnessed: teams that are overly polite to avoid addressing conflicts. She worked with a team that prided themselves on being collaborative and drama-free, but beneath that politeness was a hesitancy to have difficult conversations. It started small—in sprint planning, the Product Owner would propose unrealistic scope, and people would just nod and accept. Someone might say "that's quite ambitious," but no one would actually push back. In retrospectives, feedback was always wrapped in layers of positive framing. When a developer consistently delivered work that didn't meet the Definition of Done, no one called it out directly—they just quietly fixed it or worked around it. After three months, side conversations started emerging where people would pull Mohini aside to share concerns they would never voice in the room. The team was skipping the storming phase of the Tuckman model, and this avoidance eventually led to missed deadlines and frustrated stakeholders. The key learning: healthy conflict brings the energy teams need to innovate and grow.   In this segment, we talk about the Tuckman model and why the storming phase is essential for team development.   Self-reflection Question: Is your team's harmony genuine collaboration, or is it a facade hiding unspoken frustrations that will eventually surface at the worst possible moment? Featured Book of the Week: Turn the Ship Around by David Marquet Mohini discovered Turn the Ship Around by David Marquet at a time when she was working with multiple teams and feeling exhausted from being the person everyone looked to for answers. She thought that's what servant leadership meant, but she was actually creating dependency rather than capability. The book tells the story of how Marquet took command of the worst-performing submarine in the US Navy and transformed it into the best by fundamentally changing how leadership worked. "Instead of the traditional leader-follower model, he built a leader-to-leader structure where everyone was expected to think, decide, and own their work," Mohini explains.  The key insight was that we don't just empower teams—we need to build an environment where they can grow and don't need permission to excel. This shifted Mohini's approach: instead of saying "here's what I think we should do," she started asking "what have you tried so far? What do you intend to do next?" The book also emphasizes that pushing decision-making down requires providing the knowledge and context teams need to make good decisions.   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: Why the Best Product Owners Let Go of What They're Best At The Great Product Owner: The Humble Leader Who Served His 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.   "He was there, he was present, he was serving the team." - Carmela Then   Carmela worked with a Product Owner at a bank who embodied everything servant leadership should look like. This wasn't a PO who lorded his business expertise over the team—instead, he brought cookies, cracked jokes, and made everyone feel valued regardless of their role. He knew the product landscape intimately and participated in every refinement session, yet remained approachable and coachable.  When team members came to him confused about stakeholder requests, he willingly stepped in as a mediator. Perhaps most impressively, he actively worked to break down the hierarchical mindset that often plagues traditional organizations. In the beginning, testers felt they couldn't question the business analyst or Product Owner.  By the end, QA team members were confidently pointing out missing scenarios and use cases—and the PO would respond with genuine appreciation: "Oh yes! We missed it! Let's prioritize that story for the next sprint." This PO understood that his role wasn't to have all the answers, but to create an environment where anyone could contribute their expertise. The result was a truly flat, collaborative Scrum team operating exactly as Scrum was designed to work.   Self-reflection Question: How accessible are you to your team, and do you create an environment where anyone—regardless of role—feels comfortable challenging your thinking? The Bad Product Owner: When Expertise Becomes a Barrier to Collaboration Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "He knows everything himself, and everything is in his head. So nobody else knows what he has in his head." - Carmela Then   Carmela describes a Product Owner who wasn't a bad person—in fact, he was incredibly capable. He knew the business from front to back, understood the systems intimately from years of analyst work, and could even write pseudocode himself. The problem? His very competence became a barrier to team collaboration.  Because he knew so much, he struggled to articulate his ideas to others. Frustrated that developers couldn't read his mind, he started writing the code himself and handing it to developers with instructions to simply implement it. The result was disengaged developers who had no understanding of the bigger picture, and a PO who was drowning in work that wasn't his to do.  Carmela approached this with humility, asking what she calls "dumb questions" and requesting that he draw things on paper so she could understand. She made excuses about her "bad memory" to create documentation that could be shared with the whole team.  Over multiple Program Increments, she gently coached him to trust his team: "You are one person. Please let the team help you. The developers are great at what they do—if you share what you're trying to achieve, they can write code that's more efficient and easier to maintain." Eventually, he learned to let go of the coding and focus on what only he could do: sharing his deep business knowledge.   Self-reflection Question: As a leader, what tasks are you holding onto that you should be delegating—and what is your reluctance costing your team?   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: Why Teams Hate Agile (And How to Change That) Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "They just hate it. They absolutely hate it. They had Agile fatigue." - Carmela Then   Carmela describes what success looks like for a Scrum Master, and her answer might surprise you. Years ago, she might have pointed to metrics like cycle time. Today, she measures success by whether teams embrace Agile and Scrum rather than resent it.  She joined a team that was exhausted and bitter—their previous Scrum Master had been a micromanaging project manager in disguise. Stories were broken into disconnected tasks: one for development, one for testing, with no relationship between them. At the end of a sprint, nobody could answer whether something actually worked in production. The team hated Agile with a passion.  Carmela approached them differently—not as a threatening authority figure, but as a humble business analyst there to help. She let the Product Owner vent his frustrations about Agile in a retrospective.  Then, without preaching, she simply showed them another way: how to break down features properly, how to create end-to-end visibility, how to write stories that delivered actual value. Slowly, the team began to experience what Agile was meant to feel like. They stopped being "task deliverers" and started becoming value creators. The transformation wasn't overnight, but the result was a team that finally understood—and even appreciated—why Agile works.   Self-reflection Question: If you asked your team whether they love or hate Agile, what would they say—and are you brave enough to ask? Featured Retrospective Format for the Week: Emotional Seismograph Carmela recommends the Emotional Seismograph as her go-to retrospective format. The setup is simple but powerful: create a graph with the sprint days on the horizontal axis and emotion levels on the vertical (happy at the top, sad at the bottom). Each team member draws a line showing how they felt throughout the sprint. The visual result is striking—and the conversations it triggers are invaluable. Carmela focuses on the extremes: moments of great happiness and moments of stress. She has team members add sticky notes to explain those peaks and valleys, allowing common themes to emerge. Her philosophy is that positive emotions drive productivity: "When the team is having a positive experience throughout their workday, they're actually more productive. Stress is the silent killer—it makes people sick, takes them out physically and mentally, and people will just quit." By putting a finger on the emotional pulse of the team, Scrum Masters can identify what to continue doing and what needs to change to lift the team into a better experience.   [The Scrum Master Toolbox Podcast Recommends]

Carmela Then: From Requirements Chaos to Story Mapping Success—How Planning Transforms 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.   "We can't continue to do this. Something has to change." - Carmela Then   Carmela shares a story of organizational chaos that will resonate with many Agile practitioners. She joined a company where teams would jump straight into writing requirements without pausing to understand what they were trying to achieve. Vendor deliverables were thrown "over the fence" to internal technology teams with the assumption that everyone would magically know what to do. For almost a year, this pattern continued: teams writing stories on the fly while building, creating massive rework, confusion, and burnout.  The Product Owner faced constant stakeholder disappointment, having to explain what wasn't delivered and why. Then came the breakthrough moment—the PO reached out and said, "We can't continue to do this." Carmela introduced a structured approach: workshops that brought business stakeholders and subject matter experts together to walk through end-to-end business processes. She implemented story mapping—visualizing the journey from beginning to end, with each major step broken into smaller, actionable stories.  Critically, she built in feedback loops: playback sessions where the team validated their understanding with stakeholders before committing to development. The result? Teams could now distinguish between well-understood work they could start immediately and the "hairy" items that needed more investigation. The Product Owner could make informed prioritization decisions, and the entire team gained visibility into the bigger picture.   Self-reflection Question: How often does your team pause to map the full end-to-end journey before diving into requirements, and what might you be missing by skipping this step?   [The Scrum Master Toolbox Podcast Recommends]

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