Podcasts about product owners

Alf Dobbert-Baums: The Two-Country Scrum Team and the Rapport That Never Showed Up 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 did not quite go as planned. I was really humbled." - Alf Dobbert-Baums   Alf was new in the company. His boss walked over with a setup that already sounded like a warning: two development teams in two countries, two locations in Germany, a "difficult" Product Owner — and a quick "do you want to take it?" Alf said sure. Everything happened on video chat. Every meeting, every conversation, every attempt to read the room — through a window that closed the moment the call ended. The rapport never built. The PO stayed difficult. Alf eventually got pulled from the team. Looking back, he saw what the video chat had hidden: the crossed arms, the eyes drifting to email, the small in-between moments that turn coworkers into colleagues. The fix wasn't a tool — it was a flight. Visit the other location. Run a workshop with a real goal ("how do we want to work together?", "what's hard about our setup?"). Build a positive anchor before anything goes wrong, not after. And when you do go, don't lead with the failures — lead with what could be possible together.   In this episode, we refer to the practice of building team working agreements as a way to create rapport without putting people on the defensive.   Self-reflection Question: When was the last time you saw the people you work with face-to-face — and what conversations are you still postponing because they only happen well in person?   [The Scrum Master Toolbox Podcast Recommends]

Mirco Gerling: The Hydra Product Owner and the PO Who Made Trust Possible 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: Precision That Builds Team Trust 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 always had an answer, or if he didn't have the answer, he tried to ask the clients, the users, the stakeholders." - Mirco Gerling   In pharmaceutical software, the wrong dose can kill someone. So when Mirco worked with a PO in that domain, precision wasn't a virtue — it was a survival requirement. The PO wrote meticulous user stories in classic "As a user, I want… so that…" format with very good acceptance criteria. The developers always knew what done meant. And when, mid-sprint, the team spotted a gap — "Is 80% tolerance of 100% or 80% of all?" — the PO was there, asking the right people, refining or splitting the story, never letting ambiguity ship. Even when half the team was out sick in winter, the remaining developers could deliver because the user stories were clear enough to stand on their own. Stories linked to automated tests. Each acceptance criterion traceable to the test that proved it. The result: a team that trusted their PO. As Mirco puts it, that trust came from one thing — the PO had already done the work needed to help the team understand what to do and how they'd know it was done.   Self-reflection Question: What's the level of precision in your team's user stories signaling to your developers about how much you trust them — and how much you've prepared for them? The Bad Product Owner: The Hydra PO with Seven Heads 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 the developers had questions, the people said: 'it's not my ticket, it's not my story.'" - Mirco Gerling   Five Scrum teams. One Product Owner. Seven requirements engineers writing user stories alongside. Eight people doing the work of product ownership — and nobody owning any of it. Developers learned quickly that asking a question meant being bounced from one requirements engineer to another. "It's not my ticket." The eight-person PO group split into two sub-teams who, when they spoke about each other, used "you" and "they" instead of "we." Decisions made in week one collided with decisions made in week three. Mirco's intervention: treat the PO group like a Scrum team. Eight people is a team-sized group. Run retrospectives with them. Get them communicating as a unit instead of as parallel individuals. The one anchor that kept things from completely falling apart was the single PO at the top, who could still say "this feature we need at the end of the year, the other can wait." Without unified prioritization, the hydra has no direction — just seven heads pulling in seven ways.   Self-reflection Question: Where in your product organization are decision-makers proliferating without a shared mandate — and what's the cost in clarity for the teams downstream?   [The Scrum Master Toolbox Podcast Recommends]

www.iotusecase.com#Verwaltungsschale #IIoTIn dieser Episode des IoT Use Case Podcasts spricht Co-Host Dr. Peter Schopf mit Michael Knoblich, Product Owner bei XITASO, und Hans Michael Krause, Director Ecosystem ctrlX World bei Bosch Rexroth. Im Mittelpunkt steht die Frage, wie aus der Verwaltungsschale – der Asset Administration Shell – in der Modellfabrik von Bosch Rexroth in Ulm konkrete Produktionsflexibilität wird.ZusammenfassungAusgangspunkt ist ein bekanntes Problem: Neue Maschinen lassen sich nur mühsam in bestehende Linien integrieren, weil Linien-SPS starr programmiert sind und Daten in Subsystemen mit unterschiedlicher Semantik brechen. Die Verwaltungsschale dient als standardisierte Datenschnittstelle – im Werk und über Unternehmensgrenzen hinweg.In der Modellfabrik bekommt jede Maschine und jedes Modul eine Verwaltungsschale. Über eine Asset Orchestration Platform modelliert Bosch Rexroth die Linie per Businesslogik statt fester SPS-Programmierung und rekonfiguriert flexibel zwischen AGVs und Maschinen. XITASO unterstützt bei der standardisierten Erstellung; ein frühes Beispiel ist das digitale Typenschild bei WITTENSTEIN. Die Verwaltungsschale bleibt dabei eine Technologie neben OPC UA und MQTT – entscheidend ist die Wahl je Use Case.Die größte Hürde ist die Erstellung der Verwaltungsschale selbst. Krause rät, klein an der vermuteten Bottleneck-Maschine anzufangen und erst Datentransparenz zu schaffen, bevor die Linie orchestriert wird. Knoblich lenkt den Blick auf OT/IT und ein gemeinsames Zielbild: Am Ende seien es die Menschen, die man mitnehmen muss.Das nimmst du mitAls größte Einstiegshürde erscheint die Erstellung der Verwaltungsschale selbst – für Brownfield-Maschinen bietet XITASO dafür einen SPS-Funktionsbaustein.Auf Basis der Verwaltungsschale lässt sich eine Linie über eine Asset Orchestration Platform per Businesslogik modellieren, statt sie starr in die Linien-SPS zu programmieren.Die Verwaltungsschale ist eine Technologie von mehreren; für Bewegungskommandos eignet sich MQTT, für Sensorsignale OPC UA.Wer OEE verbessern will, beginnt an der vermuteten Bottleneck-Maschine: erst Verluste transparent machen, dann orchestrieren.-----Relevante Folgenlinks:Peter (https://www.linkedin.com/in/peter-schopf/)Hans Michael (https://www.linkedin.com/in/hansmichaelkrause/)Michael (https://www.linkedin.com/in/michael-knoblich/)

Aliu Adewale: The Over-Communicator vs. The Over-Ambitious—Two Patterns Every Scrum Master Should Recognize Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes. The Great Product Owner: The Over-Communicator Who Negotiated Every Scope Change Read the full Show Notes and search through the world's largest audio library on Agile and Scrum directly on the Scrum Master Toolbox Podcast website: http://bit.ly/SMTP_ShowNotes.   "This is a guy who over-communicates everything." - Aliu Adewale   The best Product Owner Aliu ever worked with did something simple that almost no PO does. Before each refinement, he'd pull up the Jira board, record himself walking through every user story, explaining acceptance criteria, talking through the end goal one ticket at a time—and post the video to the team a day or two ahead. This was before Loom existed. The result: refinement felt less like discovery and more like "walking it back"—the team arrived already prepared, with real questions, ready to engage. He still attended every refinement and never missed a comment in Jira. But the second skill Aliu names matters even more: negotiation. This PO never let scope creep into a sprint mid-stride without consulting the team first. "If we add these two requests from leadership, what's the impact? Do we need to take something out?" And if the team said no, he didn't force it. He went back to leadership and named the consequence: "If we add this, here's what happens. Are you okay with that?" Over-communication and negotiation—two skills that protect the team and the product at the same time.   Self-reflection Question: When was the last time your PO asked the team's permission before adding work mid-sprint? The Bad Product Owner: The Over-Ambitious PO Who Never Said 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.   "Every yes to something unimportant is a no to what matters." - Aliu Adewale   The Product Owner Aliu names as the anti-pattern is the over-ambitious PO—the one who never says no. Never to stakeholders, never to the business, never to a new feature request. He never considered the size of the team or the capacity of the team. He was blind to it. Underneath the behavior, Aliu sees a pattern: POs who want to keep their job by saying yes, stakeholders who keep asking because they think they have to, and a team on probation that doesn't feel safe pushing back. The damage compounds—more features delivered, less value per feature, and eventually the team itself starts to break. Aliu's framing is sharp: "More features don't equal more value. Sometimes more is just less." The job of the Scrum Master here is to coach the PO on when to say no, when to say yes, and how to recognize that on the phone in front of you right now, 90% of the features in that app you're staring at—you never use them. Built. Shipped. Ignored.   In this segment, we refer to Product Owner anti-patterns and the courage required to challenge stakeholder demands.   Self-reflection Question: Is your PO measuring success by features shipped, or by features used?   [The Scrum Master Toolbox Podcast Recommends]

Aliu Adewale: Success Is Living the Five Scrum Values—And Asking the Team If You Are 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.   "Trust is the foundation of empowerment. When you trust your team, they will deliver beyond your expectation." - Aliu Adewale   For Aliu, success as a Scrum Master is concrete: the team is living the five Scrum values—commitment, focus, openness, respect, and courage—and the organization is getting real value from their work. Commitment shows up in how the team holds itself to a Sprint goal. Focus shows up in how they protect that goal from noise. Openness reduces conflict because nothing festers in the dark. Respect, Aliu reframes powerfully: respect for someone's background comes before respect for their skill set—because in a team where people come from different countries, religions, and skill sets, that's the foundation everything else sits on. And courage shows up when a team can tell a Product Owner or a stakeholder that no, this can't be done in this Sprint, and we need to talk about it. But the values alone aren't success—the test is whether the team is delivering value frequently to the organization. The way Aliu keeps himself honest is uncomfortable but simple: he sends a survey to his team and asks them to tell him how he's doing on communication, on risk mitigation, on empowering them to reach stakeholders directly. He starts the assessment cycle the moment he joins—asking the organization what success looks like in this role in the next three months—and he refuses to "get carried away" and stop asking.   Self-reflection Question: Have you ever sent your team a survey asking them to rate you—and acted on what they said? Featured Retrospective Format for the Week: Start, Stop, Continue Aliu's go-to retrospective is the classic Start, Stop, Continue. Three questions—What should we start doing? What should we stop doing? What should we continue doing?—and the team has the structure they need to pinpoint their own shortcomings and decide what to do about them. The reason it works so well, Aliu argues, is the psychological safety the simplicity creates. There's no jargon, no clever framework, no facilitator gimmick to hide behind. Experienced and self-organizing teams especially thrive with it because they can name what's not working without you having to call it out for them. As a Scrum Master, when your team starts pointing at their own gaps without your prompt, that's the moment you should applaud yourself—you coached them into the space where they can do it.   [The Scrum Master Toolbox Podcast Recommends]

If Your ScrumMaster Only Runs Meetings... You're Wasting Your Best LeaderAsk ten people what a ScrumMaster does, and you're likely to hear ten different answers."They run the Daily Stand-up.""They schedule Sprint Planning.""They update Jira.""They remove impediments.""They're the Agile coach.""They're the team's project manager."Some of those answers are partially correct.Most of them are incomplete.And that's becoming one of the biggest challenges facing Agile organizations today.Somewhere along the way, many companies unintentionally shrank one of the most influential leadership roles on an Agile team into something much smaller.A meeting facilitator.A calendar manager.A process referee.Someone who reminds everyone when the Sprint Review starts.That's not what the ScrumMaster role was designed to be.In fact, if that's all your ScrumMaster is doing...You're probably missing the greatest opportunity that role has to offer.Let's imagine two ScrumMasters.The first arrives every morning with a checklist.Start the Daily Scrum.Update the board.Send reminders.Schedule Retrospectives.Close completed stories.Generate reports.Stay organized.Nothing wrong with those activities.They're important.But now let's look at a second ScrumMaster.This person notices that two team members have stopped collaborating.They coach a Product Owner struggling to prioritize competing stakeholder requests.They help leadership understand why multitasking is slowing delivery.They facilitate a difficult conversation before it becomes a lasting conflict.They identify organizational policies that create unnecessary delays.They mentor new leaders.They build trust across departments.They help people solve problems they didn't even realize existed.Which ScrumMaster creates greater long-term value?The answer seems obvious.Yet many organizations still spend far more time measuring the first set of activities than the second.Why?Because administration is visible.Leadership often isn't.You can see a meeting on a calendar.You can't always see trust being built.You can count completed ceremonies.It's much harder to measure improved communication.You can track whether a Retrospective happened.It's much more difficult to quantify whether people actually feel safe speaking honestly during it.That's the challenge.The most valuable work ScrumMasters perform often happens between the ceremonies.Not during them.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

Welkom bij een gloednieuwe aflevering van de Product Owner podcast, dé plek voor jouw wekelijkse dosis product-inspiratie. Vandaag duiken we diep in de praktijk met twee absolute rotten in het vak. Jochem gaat deze week met Henny en Dolf van de Product Owner Group in gesprek. In deze aflevering bespreken ze: Hoe 'product owner land' er momenteel écht voorstaat in Nederland. Wat jij als startende PO kunt leren van doorgewinterde freelancers met ervaring bij meer dan 10 verschillende organisaties. Of het traditionele agile team op de schop gaat en we straks überhaupt nog wel Scrum Masters hebben. Een must listen voor iedere PO die sneller wil groeien door de ultieme inside tips en fouten van ervaren rotten te stelen. De Product Owner podcast is een initiatief van productowner.nl

AI Can Write User Stories... So What Does the Product Owner Do Now?If artificial intelligence can write user stories...What exactly is the Product Owner supposed to do?It's a fair question.Over the past year, we've watched AI tools generate acceptance criteria, organize backlogs, summarize stakeholder interviews, identify duplicate requirements, estimate effort, draft release notes, and even suggest Sprint Goals.Tasks that once required hours can now be completed in minutes.Some see that as a threat.I see it as an opportunity.Because for years, many organizations unintentionally reduced the Product Owner role to backlog management.Write stories.Prioritize tickets.Attend meetings.Answer developer questions.Repeat.Those activities are important.But they were never the reason the Product Owner role was created.The Product Owner exists for one purpose above all others.To maximize value.Not backlog size.Not story count.Not velocity.Value.That's where artificial intelligence changes everything.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

Gunnar Fischer: From Staying in Your Line to The Connected Product Owner—Two Patterns Every Scrum Master Should Recognize The Great Product Owner: The Connected PO Who Makes Information Flow 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 Product Owner didn't need to be the smartest person in the room, but everybody knew, okay, this is a really smart guy." - Gunnar Fischer   The best Product Owner Gunnar ever worked with was what he calls the connected PO. This person had a deep professional network—inside the company and with the customer—and could talk to anyone: a colleague, the client, a brand-new team member they were onboarding. They were socially sharp without being shallow. They could disagree clearly, even harshly, and then turn around and say, "now let's talk about something else," with kindness. When this PO said no, it was a no people respected; when they said yes, it was a yes people trusted, because everyone knew the PO could push back. The praise behind their back matched the praise in the room. They had a private life, too—not married to the job, which made them a more well-rounded human. But the specifically Product Owner skill Gunnar names is this: they could look at the product across different time horizons—what does it need to do in one month, three months, one year—and they kept juggling functionality, contracts, customer situation, and economic reality at the same time. Their technical background helped, but they understood the line: "It's not my job to be the technically most savvy guy, but I'm willing to share my knowledge with everybody." As Gunnar puts it, the difference between a subject matter expert and a Product Owner is that the Product Owner makes the information flow.   Self-reflection Question: Does your Product Owner make information flow across the team, the customer, and management—or are they hoarding context as the "expert"? The Bad Product Owner: The Stay-in-Your-Line, Accept-Your-Fate PO 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 manage the backlog, you do the customer calls, you write the user stories—but you were not involved in any of the bigger decisions." - Gunnar Fischer   The anti-pattern Gunnar sees most often isn't malice—it's resignation. Most Product Owners aren't given the access or the permissions they need to be successful, and so they accept their fate. They manage the backlog, take the customer calls, write the user stories, sometimes talk to management—but they aren't part of the bigger decisions: ROI on a feature, whether to build it at all, the product vision a year out. Management keeps those decisions to itself, and the accept-your-fate PO doesn't challenge that arrangement. They stay in their line. They don't push back when sales drops in an urgent request that ruins the plan. They don't challenge the developers when an estimate feels wrong. They become very protective of the things they can control—their privileges, their processes, the artifacts—and when the bad times come, they get thrown under the bus. Gunnar's diagnosis is direct: the role of a great PO is to have constructive, respectful disagreements at every level—with the client, with management, with the team—and to be okay disappointing people. "Once you see that people go down to the mechanics, then it's a really bad smell, I would say." Saying yes to everything doesn't make you safe; it makes you replaceable.   In this segment, we refer to Geoff Watts' Scrum Mastery and its line about the great Scrum Master being dispensable and wanted—a frame that applies to Product Owners just as well.   Self-reflection Question: Where in the past month did your Product Owner say "yes" when the right answer was a respectful "no, not yet"?   [The Scrum Master Toolbox Podcast Recommends]

Der Rechtsmarkt verändert sich schneller, als viele es für möglich gehalten hätten. Wolters Kluwer hat gerade seine globale Studie „Future Ready Lawyer 2026" veröffentlicht und die Zahlen sind eindeutig:92 % der Jurist:innen nutzen inzwischen mindestens ein KI-Tool im Arbeitsalltag. 62 % sparen dadurch wöchentlich zwischen 6 und 20 % ihrer Zeit. Und 52 % berichten sogar von Umsatzsteigerungen nach Einführung von KI.In der neuen recode.law-Folge sprechen unsere Mitglieder Marie und Jeremias mit Philipp Stock, Product Owner der Rechercheplattform Wolters Kluwer Online, über: die spannendsten Ergebnisse der Studie im Vergleich zu 2024 warum sich Kanzleien und Rechtsabteilungen durch KI immer weiter angleichen wie Organisationen mit Risiken wie „Schatten-KI", Datenschutz und fehlenden Schulungen umgehen sollten und was Studierende & Berufseinsteiger:innen heute konkret lernen sollten, um wirklich „future ready" zu seinDie ganze Studie findet ihr hier: https://www.wolterskluwer.com/de-de/know/future-ready-lawyer-2026

Bad Agile Is Dying... And That's the Best News Agile Has Had in YearsAgile isn't dying.Bad Agile is.And honestly...that's fantastic news.For nearly two decades, organizations around the world raced to become "Agile."Some invested heavily in coaching.Others purchased new software.Many reorganized entire departments.Unfortunately, somewhere along the journey, a surprising number of organizations confused Agile with process.Stand-ups became status meetings.Sprint Planning became project planning.Retrospectives became complaint sessions.Story points became performance metrics.Velocity became a management scorecard.Scrum Masters became meeting coordinators.Product Owners became backlog administrators.The framework remained.The mindset quietly disappeared.Over time, employees became frustrated.Executives questioned the investment.Teams felt overwhelmed by ceremonies that no longer seemed connected to delivering value.Then something predictable happened.Organizations didn't reject Agile.They rejected bad experiences disguised as Agile.That's an important distinction.- [website] ⁠⁠⁠⁠⁠⁠https://www.agiledad.com/⁠⁠⁠⁠⁠⁠- [instagram] ⁠⁠⁠⁠⁠⁠https://www.instagram.com/agile_coach/⁠⁠⁠⁠⁠⁠- [facebook] ⁠⁠⁠⁠⁠⁠https://www.facebook.com/RealAgileDad/⁠⁠⁠⁠⁠⁠- [Linkedin] ⁠⁠⁠⁠⁠⁠https://www.linkedin.com/in/leehenson/

In dieser Folge spricht Susanna mit Lösungsfinder Severin über seinen Karriereweg bei der FI-SP. Vom Einstieg über seine Masterarbeit und die Softwareentwicklung bis zur Rolle als Product Owner in der OSPlus Factory berichtet er, wie Mut, Offenheit für neue Ideen und Eigeninitiative seinen Weg geprägt haben. Außerdem gibt er spannende Einblicke in seinen Arbeitsalltag und erzählt, wie er bereits nach 15 Monaten Product Owner wurde.

“We have twelve scrum masters. Why is nothing working?” If you have ever asked some version of that question, this episode is for you.Kate Megaw, Anu Smalley and Ryan Smith dig into the challenge they hear in almost every class they teach, a real lack of role clarity. Companies send a strong project manager to a two day course, hand them a new title, and then wonder why nothing changes. The honest answer is that nobody ever defined what the role is actually accountable for. This episode unpacks the difference between roles and accountabilities, why a scrum master is not optional, and how to define seats around outcomes instead of titles. Along the way Kate and Anu have a friendly fight over RACI, whether it hardens into swim lanes or serves as a living guiding light, and what responsible really means at a startup versus a large enterprise.What we cover:“We have twelve scrum masters, why is nothing working?”Roles vs. accountabilities, and why the org chart liesThe RACI debate: swim lanes vs. guiding lightThe kitchen sink job description with 45 impossible dutiesStart with outcomes, not titles, and revisit at every kickoff

What happens when a team buys the board, holds the ceremonies, and completely misses the point?The team at EM Solutions Inc. officially went Agile. They have the Scrum board. They have the standups. They have the retrospectives. They even have an Elmo doll.What they don't have is the mindset.Meet Brett — the Product Owner who treats the backlog like a throne. Dina — the Scrum Master, five-foot-three and impossible to move. Henry — who eats half the croissants before anyone else arrives and grabs the cleanest stories before planning starts. Shri — who built a checklist for the checklist. Vlad — for whom everything is a fire alarm. Dominic — whose Daily Scrum updates reference events from 2019. Paula — who cannot write a single line of code without a pairing partner. Julia — who turns every sprint review into a three-course meal when everyone ordered a snack. And Barry — the VP who says he supports Agile and then tries to bribe Vlad in the parking lot.Into this beautifully broken team walks Phill — trainer, coach, and a man who has the laminated cards to prove he has seen all of this before.Agile Circus is a business fable built around twelve real dysfunctions that real teams live with every day. Every chapter delivers the chaos in full, hilarious detail — then lands the coaching lesson: Manifesto values, sprint mechanics, planning poker, velocity, user stories, retrospectives that produce real commitments, and the truth no certification exam covers: the badge is not the achievement. The behavior is.The Agile book that makes the learning stick because you will not stop laughing long enough to put it down.Perfect for: PMP® and PMI-ACP® candidates, Scrum Masters, Product Owners, Agile coaches, project managers, engineering leaders, and anyone who has ever survived a forty-seven-minute Daily Scrum.Phill Akinwale — OPM3, PMP®, PMI-ACP®, PMI-RMP®, CSM — trainer, coach, host of pmradio.org.Get your copy. Update your Elmo. Let's move on.

Oliver und Tim sprechen in dieser Folge darüber, warum viele Product Owner auf bessere Rahmenbedingungen warten und sich damit oft selbst ausbremsen. Im Alltag fehlt die Produktvision, Prioritäten bleiben unklar oder wichtige Entscheidungen kommen nicht voran. Solche Situationen kennen viele. Der Reflex ist häufig, auf Führungskräfte, Stakeholder oder andere Teams zu zeigen und von diesen eine Lösung zu erwarten. Genau dort beginnt jedoch ein Muster, das wenig verändert. Wer dauerhaft darauf wartet, dass andere den ersten Schritt machen, gibt einen Teil seines eigenen Gestaltungsspielraums aus der Hand. Warte nicht darauf, dass das Umfeld perfekt wird, bevor du Verantwortung übernimmst. Besonders spannend ist die Frage nach dem eigenen Antrieb. Viele Produktmenschen können sehr präzise beschreiben, was in ihrer Organisation nicht funktioniert. Deutlich schwieriger wird es oft bei der Antwort auf die Frage, warum sie ihr Produkt eigentlich voranbringen wollen. Wer für sich keine Richtung erkennt, landet schnell im Beschwerdemodus. Dann dreht sich die Aufmerksamkeit vor allem um Hindernisse. Aber warte nicht darauf, dass jemand anderes Sinn und Orientierung liefert. Beschäftige dich mit dem Wert deines Produkts, mit den Menschen, die es nutzen, und mit dem Beitrag, den du selbst leisten möchtest. Daraus entsteht auch Energie für Veränderung. Fehlende Strategien oder unklare Ziele sind häufige Auslöser für Frust. Viele Product Owner wünschen sich eine klare Unternehmensstrategie, bevor sie Entscheidungen treffen oder Diskussionen glauben weitertreiben zu können. Dieser Wunsch ist nachvollziehbar. Trotzdem hilft Abwarten selten weiter. Also warte nicht, bis jede Antwort von oben kommt. Suche das Gespräch, stelle Fragen und mache sichtbar, welche Entscheidungen ohne Orientierung schwerfallen bzw. auf Basis welcher Hypothesen du vorangehen wirst. Wer aktiv Zusammenhänge aufzeigt und konkrete Vorschläge einbringt, erhöht die Chance auf Klarheit deutlich stärker als jemand, der lediglich auf Missstände hinweist. Ähnlich verhält es sich bei der Zusammenarbeit mit Stakeholdern. Wenn Anforderungen ungefiltert ins Team gelangen oder jede Aufgabe höchste Priorität erhält, entsteht schnell das Gefühl von Kontrollverlust. Viele Product Owner sehen das Problem sehr klar, bleiben aber in der Rolle der Beobachtenden. Warte nicht darauf, dass andere plötzlich anders arbeiten. Schaffe Transparenz über Auswirkungen, führe Priorisierungsdiskussionen und suche Verbündete. Einfluss entsteht selten durch die formale Rolle allein. Er wächst durch Initiative, durch Kommunikation und durch den Mut, schwierige Gespräche zu führen. Produktverantwortung bedeutet deshalb mehr als Backlog Pflege und Sprint Planung. Sie beginnt dort, wo Menschen ihr Umfeld aktiv mitgestalten. Niemand kann alle organisatorischen Probleme allein lösen. Darum geht es auch nicht. Entscheidend ist die Haltung, mit der man auf Herausforderungen blickt. Warte nicht auf die perfekte Organisation, die ideale Strategie oder die nächste Entscheidung von oben. Nutze den Handlungsspielraum, den du heute hast. Oft ist er größer, als es auf den ersten Blick erscheint. Im Gespräch wird von Tim und Oliver auf folgende ältere Episoden verwiesen: - Umgang mit Produktrisiken - Als Product Owner dein Zeitmanagement in den Griff bekommen - Trotz Hierarchie durchsetzungsstark als Product Owner agieren Wo wartest du aktuell noch darauf, dass andere etwas verändern? Vielleicht fehlt eine klare Richtung. Vielleicht blockieren Priorisierungskonflikte oder schwierige Abstimmungen mit Stakeholdern den Fortschritt. Oft gibt es mehr Handlungsspielraum, als auf den ersten Blick sichtbar wird. Vielleicht hat diese Folge dir auch bereits geholfen Dinge in die eigene Hand zu nehmen. Teilt eure Geschichten und Erfahrungen doch mit uns und der Community. Hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

What happens when a team buys the board, holds the ceremonies, and completely misses the point?The team at EM Solutions Inc. officially went Agile. They have the Scrum board. They have the standups. They have the retrospectives. They even have an Elmo doll.What they don't have is the mindset.Meet Brett — the Product Owner who treats the backlog like a throne. Dina — the Scrum Master, five-foot-three and impossible to move. Henry — who eats half the croissants before anyone else arrives and grabs the cleanest stories before planning starts. Shri — who built a checklist for the checklist. Vlad — for whom everything is a fire alarm. Dominic — whose Daily Scrum updates reference events from 2019. Paula — who cannot write a single line of code without a pairing partner. Julia — who turns every sprint review into a three-course meal when everyone ordered a snack. And Barry — the VP who says he supports Agile and then tries to bribe Vlad in the parking lot.Into this beautifully broken team walks Phill — trainer, coach, and a man who has the laminated cards to prove he has seen all of this before.Agile Circus is a business fable built around twelve real dysfunctions that real teams live with every day. Every chapter delivers the chaos in full, hilarious detail — then lands the coaching lesson: Manifesto values, sprint mechanics, planning poker, velocity, user stories, retrospectives that produce real commitments, and the truth no certification exam covers: the badge is not the achievement. The behavior is.The Agile book that makes the learning stick because you will not stop laughing long enough to put it down.Perfect for: PMP® and PMI-ACP® candidates, Scrum Masters, Product Owners, Agile coaches, project managers, engineering leaders, and anyone who has ever survived a forty-seven-minute Daily Scrum.Phill Akinwale — OPM3, PMP®, PMI-ACP®, PMI-RMP®, CSM — trainer, coach, host of pmradio.org.Get your copy. Update your Elmo. Let's move on.

Aimé Flemm: Output Owners vs Activators — Two Product Owners Who Defined Aimé's Career 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, Aimé reflects on two Product Owners — one who showed him what greatness looks like, and one who taught him the cost of structural malpractice. The contrast is structural as much as personal. The Great Product Owner: The PO As Activator "Our product owner was really able to persuade the larger group of 60 people and activate them." - Aimé Flemm   When Aimé's company moved to LeSS, they collapsed seven Product Owners down to four — and effectively one head PO who had to step up. "All of a sudden had this one product owner who needed to step up his game — to become this leader who's visionary, who has some kind of charisma." The structure forced the role to grow. The new PO had to lead 60 people, not five. And he did it. Not by writing more stories or shoving work harder, but by becoming an activator — visionary, charismatic, able to rally people behind a product direction. Aimé's framing: structure created the conditions for greatness. Reduce PO count, increase scope per PO, and the role has to step into real product leadership. "It doesn't happen too often that you get the opportunity to really have THE product owner in the company, and just the one."   Self-reflection Question: Does your structure give your PO room to be a leader — or does it force them to be a story-writer for one team? The Bad Product Owner: The Team-Manager-In-Disguise "What this product owner really did was just managing the team. He had the power to hire and fire, to decide on promotions, pay raises." - Aimé Flemm   Aimé's second PO ever was the opposite of an activator. He was a team manager in disguise — with full hire/fire authority and control over promotions and pay raises. He showed up about 15 minutes a week. "Just telling them, 'oh yeah, this is good, you should do this and do this,' and then he was gone for the rest of the week." What followed was textbook decay: an avoidant team, no initiative, refusing workshops and improvement work. "It became a collection of individuals, all on their own island. Just fixing their own work, just to make sure that they looked good." Aimé himself couldn't push back — his own job security ran through the same person. As Vasco named it in the conversation: these aren't product owners — they're output owners. Work-shovers. Proxies. The dynamic kills product value over time, because nobody is steering toward the customer.   Self-reflection Question: Is your PO an activator who rallies people behind a vision — or a proxy who shoves work from one inbox to another?   [The Scrum Master Toolbox Podcast Recommends]

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]

Everything is a fire. Everything is priority number one.  And by tomorrow, the number one priority has changed again. Sound familiar?In this episode, Kate Megaw, Anu Smalley, and Ryan Smith dig into the challenge they hear at almost every client and leadership class: a real lack of prioritization.  Not just inside the sprint, but across the whole organization, where teams get handed a brand new top priority every single day.When everything is important, nothing is important.  Constant reprioritizing whipsaws teams, burns people out, and leaves a trail of half-finished work and rising tech debt.  Jerry Weinberg's research found you can lose 20 to 40 percent of productivity every single time you switch context, so three projects can leave you down 60 to 80 percent.In this episode, we discuss:Why a lack of prioritization is really a sign that your stakeholders are not alignedThe real cost: burnout, rework, tech debt, lost innovation, and the context-switching taxWhy this is a leadership problem, not a team problem, and why the team always gets blamedUsing the sprint to hold the line and protect work the team has committed toEmergent requests as a better signal than velocity for how often the team gets interruptedMoSCoW for sorting the must-haves from the nice-to-havesThe 20/20 approach from Innovation Games for a truly ordered backlogThe impact-effort matrix for spotting quick wins and killing low-value workBuy-a-feature with stakeholders and a limited budgetThe wins on the board debate: put easy wins up first, or dig into why the big thing is bigEvery time someone says yes, it consumes time, money, and attention.  Prioritization is the discipline of protecting all three.Referenced in this episode: Jerry Weinberg's research on the cost of context switching, the 20/20 prioritization method from Innovation Games, the MoSCoW method, and the Eisenhower impact-effort matrix.

Já pensou em criar uma ferramenta interna e colocá-la no ar em menos de dois meses — mesmo sem ser da área de tecnologia?

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.

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]

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]

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.

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]

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]

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

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]

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]

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]