Die Produktwerker

Dominique im Gespräch mit Oliver Fragt man drei Product Ownerinnen, was sie als ihre Verantwortlichkeit ansehen, so erhält man vier sehr unterschiedliche Antworten. In vielen Fällen ist eine Ursache für die Vielfalt der Rolleninterpretationen, dass manche als Product Owner im Scrum Kontext arbeiten und andere wiederum als SAFe Product Owner. Es ist also an der Zeit, dass Oliver und Dominique über die Gemeinsamkeiten und Unterschiede sprechen. Denn aus ihrer Perspektive ist es dieses Thema eines der großen Missverständnisse - ein Scrum PO ist etwas komplett anderes als ein SAFe PO. Und nachdem einige Beiträge und Meinungen in den letzten Wochen in die Timeline der beiden gespült wurden, auch ein guter Zeitpunkt die eigene Sichtweise zu konkretisieren. Dominique und Oliver starten mit einer Reflexion eines Beitrags von Roman Pichler zu "Six Types of Product Owner", der in diesem Podcast schon einmal in der einen oder anderen Episode zitiert wurde. Fokus legen beide aber auf den Scrum PO und den SAFe Product Owner. Wo liegen die Gemeinsamkeiten, welche Unterschiede findet man. Nach einem Blick in den Scrum Guide und in die detaillierteren Erläuterungen in SAFe wird auf die eine oder andere Äusserung von Kollegen referenziert, u.a. Sohrab Salimi oder Heiko Stapf. Natürlich artikulieren Oliver und Dominique auch sehr klar ihren eigenen Standpunkt und klären, dass auch in diesem Podcast sehr häufig der Scrum Product Owner im Mittelpunkt der Diskussionen steht. Wie immer schließt diese Episode mit einigen konkreten Tipps & Trick ab.

Nam Hoang-Dong im Gespräch mit Tim Nam Hoang-Dong berichtet über seine Erfahrung als Product Leader einer Retained-Organisation im Gespräch mit Tim, d.h. wie sich die Steuerung eines großen externen Dienstleisters als Produktverantwortlicher anfühlt. Nam hat eine langjährige Erfahrung im Handel (MediaMarkt, ESPRIT, Thalia) und spricht in dieser Folge v.a. über die Zeit bei Esprit in die auch die agile Transformation des damaligen Dienstleisters fiel. Als Retained-Organisation wird dabei eine (meist) kleinere Einheit verstanden, die den beauftragten Dienstleister steuert. In der Praxis geschieht dies häufig nach Outsourcing-Prozessen. Hier im Beispiel vom Fashion-Händler ESPRIT wurde das ganze Online-Business über viele Jahre in dieser Form aufgebaut und betrieben. D.h. auch die (agile) Produktentwicklung des ESPRIT Onlineshops geschah auf diese Weise. Tim war damals auf der Seite des Dienstleisters im Einsatz und hat die Veränderung der Dienstleister-Beziehung daher aus anderem Blickwinkel beobachten können. Mit einigen Jahren Abstand kommt es somit zu einer interessanten Reflexion der Transformation. Aber auch die Frage, was Nam aus dieser Erfahrung an Learning in seine neue Rolle als IT-Verantwortlicher bei Thalia mitgenommen hat, spielen im Gespräch eine Rolle. In Summe ergibt sich also ein toller Erfahrungsbericht eines Product Leaders im Handelskontext aus dem sicherlich einige Impulse gezogen werden können. Folgendes Buch nennt Tim im Verlauf des Gesprächs: Robbin Schuurman/Willem Vermaak: 50 Arten, Nein zu sagen Im Zusammenhang mit dieser Podcast-Episode über die Arbeit als Retained-Organisation möchten wir euch auch nochmal diese älteren folgen im Kontext der Dienstleister-Zusammenarbeit als Herz legen: Zusammenarbeit mit einem externen Team vom Dienstleister Der Product Owner aus Sicht eines Dienstleisters Als Product Owner auf Seiten einer Agentur Wenn ihr mit Nam Hoang-Dong persönlich in Kontakt treten möchtet oder weitere Fragen an ihn habt, freut er sich über eure Anfrage bzw. Nachricht auf seinem LinkedIn-Profil. Welche Learnings habt ihr aus der Zusammenarbeit mit und Steuerung von Dienstleistern gezogen? Kennt ihr vielleicht auch solch ein Konstrukt einer Retained-Organisation? Lasst uns gerne an euren Erfahrungen, Tipps oder auch eurer Meinung teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Oliver im Gespräch mit Dominique Wer kennt sie nicht, die kleinen Life Hacks, die durch minimale Veränderungen das Leben ein klein wenig leichter machen sollen. Der Ansatz der Culture Hacks dient dazu die Kultur einer Organisation zu verändern, aber eben mit kleinen Schritten. Gleichzeitig beziehen sich Culture Hacks auf Veränderungen im informellen Bereich. Es geht eben nicht darum direkt eine neue Rolle, neue Meetings oder andere Formalismen einzuführen. Oliver und Dominique sprechen in dieser Folge über Culture Hacks, die nach ihrer Erfahrung gut auf die Kultur der Organisation einwirken können. Sie stellen aber auch heraus, dass Culture Hacks immer Experimente sind und kein Erfolgsversprechen mit sich bringen. Beispielsweise kann man versuchen die Kultur der Organisation mittels geteilter O-Töne der Menschen, die das Produkt benutzen, mehr Richtung Erlebnisorientierung zu bringen. Wenn Mitarbeitende durch viele Meetings keine Zeit haben sich zu einem allgemeinen PO-Austausch zu treffen, bietet sich vielleicht ein gemeinsames Mittagessen an. Oder man teilt seine persönlichen Gedanken über aktuelle Produktthemen häufiger per SMS, Instantmessaging oder Mail und versucht so Gespräche anzustoßen. Rund um das Thema Kultur haben wir noch ein paar weitere spannende Folgen für euch: Diversity in der Produktentwicklung (https://produktwerker.de/diversity-in-der-produktentwicklung/) Die Relevanz von UX den eigenen Stakeholdern vermitteln (https://produktwerker.de/die-relevanz-von-ux-vermitteln/) Auf Business oder Nutzer fokussieren als PO? (https://produktwerker.de/business-oder-nutzer/) Falls ihr noch weitere Tipps habt, wie man mit kleinen Maßnahmen die Kultur deiner Organisation verändern kann, lasst es uns gerne wissen. Wie sind eure Erfahrungen und welchen Herausforderungen musstest ihr euch dabei stellen? Wir freuen uns, wenn ihr eure eigenen Sichtweisen mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker) teilt.

Ralph Jocham im Gespräch mit Tim Bei all den verschiedenen Skalierungsoptionen, die es heute gibt, scheint es, als gäbe es nur wenig Einigkeit darüber, wie man die Rolle des PO skalieren kann. Ralph Jocham, der Autor des Bestsellers "The Professional Product Owner", ist nach einem sehr interessanten Talk auf dem Scrum Day 2022 mit dieser Thema bei Tim zu Gast im Produktwerker-Podcast. Ralph stellt fünf Delegationsmodelle für Product Owner vor, die unabhängig von den vorhandenen Skalierungsmöglichkeiten abgeleitet werden können. Je nach individuellem Kontext können diese Delegationsmodelle einzeln oder in Kombination eingesetzt werden. Nachdem die beiden in ihrem Gespräch noch einmal auf das grundsätzliche Verständnis für die Rolle des Product Owner eingehen, fokussieren sie sich anschließend auf das Thema Skalierung. Die zu diesem Zweck vorgestellten fünf Delegationsmodelle (5Ts) sind: Taktisches Delegationsmodell - lassen Sie andere dabei helfen, das Product Backlog und andere taktische Dinge zu verwalten Technisches Delegationsmodell - bauen Sie Ihre Arbeit in das Produkt ein Team-Delegationsmodell - delegieren Sie an die Teammitglieder, lassen Sie sie mit den Kunden sprechen Temp-Delegationsmodell - weisen Sie jedem Team einen Vertreter zu, bis die Teams autark sind Themen-Delegationsmodell - schaffen Sie Vertreter (SMEs) für verschiedene Produktbereiche, die die Teams konsultieren können Natürlich schließt auch diese Episode mit praktischen Tipps und Tricks unseres Gastes.

Was in Dominiques Kopf gerade so vorgeht Mit dieser Folge wagen wir ein kleines Experiment. Einer von uns spricht über einen Gedanken, der ihn gerade umtreibt und erhofft sich mit euch in einen Dialog zu treten. Dazu seid ihr alle herzlich eingeladen auf die Seite dieser Folge zu gehen und in den Kommentaren eure Perspektive auf die Gedanken zu teilen. Hier könnt ihr mitmachen -> https://produktwerker.de/gedankenaustausch-was-kommt-nach-ux/ Dominique spricht diesmal über seine Gedanken, welche Gestaltungsaspekte nach der UX kommen können und wirft dabei einen Blick in eine mögliche Zukunft in 30 Jahren. Vor 30 Jahren war noch eher Usability und die Benutzbarkeit relevant. Aus der Usability hat sich dann im Laufe der Zeit die UX entwickelt. Für Produkte wurde die Metapher des Werkzeugs verwendet. Der Gestaltungsaspekt der UX ist aber auf das Erleben der Interaktion fokussiert und wir versuchen insbesondere ein positives Erleben zu erzeugen. Menschen haben jedoch bezogen auf die Interaktion mit Produkten oft eine Aneinanderreihung von Episoden der Nutzung und der Nicht-Nutzung. Die Summe dieser Episoden erzeugt bei Menschen ggf. eine Beziehung zum Produkt. Dominique ist davon überzeugt, dass nach wir uns von der reinen Nutzbarkeit hin zum Erleben der Interaktion bewegt haben und zukünftig noch stärker in die Gestaltung der Beziehungsebene bewegen werden. Es geht dann nicht mehr nur darum EIN positives Erlebnis, sondern eine Historie aus positiven Erlebnissen zu schaffen, die eine emotionale Bindung der ein oder anderen Art zwischen User und Produkt ermöglicht. Besonders durch Automaten, die viel natürlicher mit dem Menschen kommunizieren wird der Aspekt des Partners stärker. Selbstverständlich brauchen wir weiterhin UX als Gestaltungsaspekt. Ohne positive Nutzungserlebnisse schaffen wir keine positive Nutzerbeziehung. Genauso braucht ein gutes Nutzungserlebnis eine gute Benutzbarkeit. Was bedeutet das für die Ausarbeitung zukünftiger Verantwortlichkeiten? Wahrscheinlich wird mehr Fokus auf die User Journey außerhalb der einzelnen Nutzungsepisode gelegt. Es werden Fragen geklärt wie: Wie sollen Nutzer die Beziehung zu dem Produkt empfinden oder wie ermöglichen wir eine emotionale Bindung? Produkte werden so zu emotional aufgeladenen Artefakten des Lebens. Die mögliche Metapher ist dann der Partner und wir müssen uns klar haben, welche Werte und Prinzipien das Produkt in der Beziehung und nach außen vertritt. Auch müssen wir verstehen, was es besonders macht. Die Entwicklung einer Persönlichkeit des Produkts erfolgt durch Austausch, bzw. Interaktion. Es gibt im Buch Gamestorming eine gut dazu passende Übung (Pinocchio-Produkt-Übung). Stell dir vor, dein Produkt erwacht auf einmal zum Leben. Welchen Charakter hat es und wofür kämpft es? Hedonische Aspekte fließen wahrscheinlich stark in die Bildung der Beziehung ein. Eine Beziehung macht auch was mit einem selbst. Customer Relation und User Relation wirken stark auf einander ein, je nach Produkt. Die Beziehungsebenen werden einen Einfluss aufeinander haben. Hier wird sich aber im Laufe der Zeit eine Abtrennung der Fachdisziplinen entwickeln. Es werden aber auch Probleme durch die Fokussierung entstehen. Die Integration von UX als Gestaltungsaspekt in die Entwicklungsvorgänge von Organisationen ist im Moment auf breiter Flur zum Beispiel noch nicht abgeschlossen. Wie bei UX werden neue Fähigkeiten und Fertigkeiten gebraucht und nicht alle UX-Professionals haben diese bereits. Es wird eine Diffundierung der neue Fachdisziplin geben, die erst nach längerer Zeit konsolidiert werden wird. Jetzt aber genug von Dominiques Gedanken. Wie seht ihr das? Was ist eure Meinung? Teilt es mit allen unter https://produktwerker.de/gedankenaustausch-was-kommt-nach-ux/.

Oliver und Dominique im Gespräch Über die Zusammenarbeit von Product Ownern mit Stakeholderinnen, Nutzerinnen und so weiter haben wir schon mehrfach gesprochen. Aber immer wieder gibt es auch Kontexte, in denen wir als Product Owner mit anderen Product Ownern zusammenarbeiten. Diesen Kontexten begegnen wir insbesondere in größeren Organisationen, in denen mehrere Teams mit jeweils eigenen Product Ownern an einem großen Produkt zusammen arbeiten. Da werden große Produkte so geschnitten, dass verschiedene Product Owner gemeinsam mit ihren Teams Teil-Produkte verantworten. Aus der Skalierung mit mehreren Produktteams für ein Produkt ergibt sich in der Praxis häufig das ein oder andere Problem. Beispielsweise wirkt das Gesamtprodukt nicht mehr wie aus einem Guss, eben weil es auch von verschiedenen Menschen mit unterschiedlichen Sichtweisen entwickelt wurde. Wenn jedes Teil-Produkt sein eigenes (Teil-)Product Backlog hat, wird es mit der gemeinsamen Priorisierung kompliziert. Oft hängen auch die Metriken der jeweiligen Teil-Produkte nicht ganz sauber zusammen. Viele Probleme, die auch beim Zusammenarbeiten der Product Owner auftauchen und dort in irgendeiner Art gelöst werden sollen. Weitere spannende Folgen rund um das Zusammenarbeiten findet ihr hier: Als Product Owner im skalierten Umfeld Das Product Owner Team Habt ihr euch mit dem Thema schon mal beschäftigt? Wie geht ihr selbst damit um? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Dominique und Oliver im Gespräch Biases sind Verzerrungen bzw. systematische Fehler in der Beurteilung von Information. Der bekannteste ist vielleicht der sogenannte "Cognitive Bias", eine kognitive Verzerrung. Letztlich beeinflussen sie unser Urteilsvermögen und durch subjektive Eindrücke und beeinflussen so auch Entscheidungen von Product Ownern. Objektivität wird somit erschwert, denn Menschen neigen dazu, alle Schlussfolgerungen zu akzeptieren, die in ihr Glaubenssystem passen, ohne diese gründlich zu hinterfragen. Umgekehrt neigen wir dazu, Behauptungen abzulehnen, die nicht in unser Glaubenssystem passen, auch wenn sie durchaus logisch sein könnten. Oliver und Dominique nehmen sich in dieser Folge dieses Phänomen aus der Verhaltenspsychologie mal vor, erklären es anhand von Beispielen und versuchen auch mal zu reflektieren, wie Product Owner in ihren Entscheidungen von so etwas betroffen sind. Weitere Biases, die in dieser Episode u.a. behandelt werden: Dunning Kruger Effekt = Tendenz von wenig kompetenten Menschen, das eigene Können zu überschätzen und die Kompetenz anderer zu unterschätzen Confirmation Bias = Neigung, Informationen so zu interpretieren, dass sie die eigenen Erwartungen einfach nur bestätigen Implicit Bias = das Produkt so bauen, wie man es sich selber wünscht bzw. vorstellt, d.h. von sich auf andere schließen IKEA-Effekt = die Neigung, selbst zusammengebauten Gegenständen im Vergleich zu fertig gekauften Massenprodukten mehr Wertschätzung entgegenzubringen. In Bezug auf Software: alles selber programmieren zu wollen, anstatt Standard-Software einzubinden Effort justification Bias = Wenn wir Aufwand in etwas investiert haben, wird es als wertvoller betrachtet, als wenn wir objektiv drauf schauen würden Verlustaversion = Die Tendenz, Verluste höher zu gewichten als Gewinne Und dies sind letztlich auch alles Fallen, in die wir als Product Owner reinlaufen können. Oliver und Dominique geben daher Tipps, was man gegen diese "Störenfriede" tun kann oder zumindest, wie man damit als Product Owner besser umgehen kann. Ein tolles Buch, was sich letztlich auch um das Thema der Biases dreht ist "Schnelles Denken, langsames Denken" von Daniel Kahneman (englischer Originaltitel: Thinking, Fast and Slow). Kahneman verfolgt anhand vieler Beispiele aus seiner Forschung die folgende These: es gibt zwei Arten des Denkens: Das schnelle, instinktive und emotionale System 1 und das langsamere, Dinge durchdenkende und logischere System 2. Zum Thema "Biases" passt auch diese frühere Folge aus diesem Podcast sehr gut: Decision Poker und Entscheidungsverfahren Kano-Modell um Kundenbedürfnisse zu verstehen Habt ihr euch mit dem Thema schon mal beschäftigt? Wie geht ihr selber damit um? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Konstantin Diener im Gespräch mit Tim Product Discovery soll uns helfen Produktrisiken bei komplexen Problemstellungen frühzeitig zu erkennen und Lösungen zu finden, die von Nutzer:innen wertgeschätzt und nutzbar sind, während wir sie als Team bauen und wirtschaftlich betreiben können. Also lasst kontinuierliche Product Discovery und Delivery Hand in Hand einher gehen! Klingt dir zu theoretisch? Na, dann hör' dir mal das ganz praktische Problem von Konstantin Diener und seinen Leuten bei cosee an! In kürzester Zeit galt es, ein physisches Produkterlebnis wie die Essener Brettspiel-Messe SPIEL in eine digitale, Pandemie-gerechte Form zu übersetzen, die für Besucher:innen und Messeveranstalter gleichermaßen erfolgreich sein musste. Im Gespräch mit Tim liefert Konstantin einen lebhaften Erfahrungsbericht, wie ihnen das durch eine enge Verzahnung von Product Discovery und Delivery gelungen ist. Offensichtlich hätte das Team in diesem engen Zeitrahmen auch schlichtweg gar keine Zeit für eine vorgeschaltete Discovery oder Analyse-Phase gehabt. Also wurde das Problem zur Lösung: ultra-kurze Zyklen und kontinuierliches Nutzer-Feedback führten zu einer sehr gut funktionierenden Messe SPIEL.digital. Details zum besprochenen Projekt, die SPIEL.digital zu erstellen findet man direkt hier auf den Seiten von cosee und zudem ein sehenswertes Video mit einem Vortrag von Konstantin Diener über das gesamte Projekt der SPIEL.digital. Ein Interview aus Sicht von Product Owner und Scrum Masterin über das Projekt ist auch sehr spannend. Zudem gibt es einen Erfahrungsbericht zur Home Office Erfahrung von cosee gibt es bei ihnen im Blog. Konstantin nennt im Gespräch folgende Quellen: Teresa Torres: Continuous Discovery Habits Gojko Adzic: Specification by Example Julia Grace von Slack: Talk über Clarity Diese Folge steht auch mit den folgenden Episoden in einem engen Kontext rund um Product Discovery: Product Discovery in Scrum integrieren (mit Juliana Brell) Kontinuierliche Product Discovery in Teams etablieren (mit Jan Kiekeben) Outcome Goals und Product Discovery (mit Tim Herbig) Wie verbindet ihr Discovery und Delivery bei euch in der Produktentwicklung? Was sagt ihr zu diesem Erfahrungsbericht über die Digitalisierung der SPIEL? Was hat euch begeistert? Lasst uns gerne an euren Erfahrungen oder auch eurer Meinung teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Oliver und Tim im Gespräch Das Konzept "Geber, Nehmer oder Tauscher?" von Adam Grant hat's uns angetan. Oliver Winter und Tim Klein besprechen daher sein Buch "Geben und Nehmen - Warum Egoisten nicht immer gewinnen und hilfsbereite Menschen weiterkommen" (im Original: "Give and Take: Why Helping Others Drives Our Success"). Zunächst mal wird natürlich erläutert, was hinter der Idee von Adam Grant steckt und was Geber, Nehmer oder Tauscher sind. Neben dem Verständnis der einzelnen Verhaltens-Ausprägungen von Geber, Nehmer oder Tauscher sind einige Erkenntnisse besonders erstaunlich: so zerfallen die Geber in zwei unterschiedlich erfolgreiche Cluster - als Geber ist man also weder per se weniger erfolgreich noch in jedem Fall erfolgreicher als Nehmer oder Tauscher. Und warum sind die meisten Menschen im Privaten "Geber", aber im Berufsumfeld verhalten sich die meisten dann doch als Tauscher oder sogar als Nehmer? Anschließend geht's um die Frage, was dieses Konzept für Product Owner bedeuten kann. Kann man auch in der Product Owner Rolle als Geber erfolgreicher sein? Was ist, wenn man nur mit Nehmern oder Tauschern zusammenarbeiten muss? Insbesondere Adams Grants Empfehlungen zu "Powerless Communication" (siehe YouTube-Empfehlung) und der "5-Minuten-Gefallen" können Product Ownern aus Sicht von Tim und Oliver vermutlich sehr gut helfen. Das Buch hat Oliver und Tim sehr beeindruckt und beide sprechen daher eine ganz klare Lese-Empfehlung aus: Adam Grant: Geben und Nehmen - Warum Egoisten nicht immer gewinnen und hilfsbereite Menschen weiterkommen Weitere Empfehlungen: TEDx-Talk von Adam Grant zum Thema "The power of powerless communication" Blog-Artikel von Susan Cain "7 Ways to Use the Power of Powerless Communication" Diese Folge steht auch mit den folgenden Episoden in einem engen Kontext: Coaching Skills als Product Owner entwickeln (mit Daniel Hommel) Introvertiert als Product Owner - geht das? (mit Timon Royer) Kanntest du das Buch schon? Wie agierst du als Product Owner und unterscheidet es sich von deinem privaten Verhalten? Hast du "Powerless Communication" (vielleicht unbewusst) schon mal ausprobiert? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Dominique und Tim im Gespräch An welchen Dingen scheitern Product Owner? Was kann alles im Weg stehen oder schief gehen? Welche Rahmenbedingungen schaden dem erfolgreichen Wirken von Product Ownern? Tim und Dominique haben eine ganze Reihe von Punkten zusammengetragen die Probleme bereiten können. Im Gespräch werden diese kritisch beleuchtet, z.T. werden Hintergründe und zu Grunde liegende Probleme besprochen. Herausgekommen ist eine Folge, bei der wir den Finger, besser gesagt beide Hände, mal tief in die Wunden organisatorischer, methodischer und auch persönlicher Unzulänglichkeiten legen. Sicherlich kann diese Episode daher gut zur Selbstreflexion dienen: Welche dieser Punkte trifft in meinem Kontext zu? Was habe ich auch schon erlebt? Wo kann ich selber noch Dinge verändern? Sicherlich treten viele dieser Herausforderungen oder Probleme nur vereinzelt oder in leicht abgewandelter Form auf, aber in irgendeiner Art und Weise haben wir Produktwerker diese Phänomene alle schon mal hier und da angetroffen. Tim und Dominique gucken zunächst auf den Bereich von Organisation und dem Kontext in dem die Produktentwicklung stattfindet. Als nächstes Cluster schauen sie sich alles an, was mit dem Zusammenspiel und der Kommunikation mit anderen zu tun hat (Stakeholder, Team, …). Danach geht es um das eigene Verhalten in der Product Owner Rolle, was je nach dem zu Problemen führen kann. Auch das eigene Rollenverständnis kann im Wege stehen. Und schließlich gehts noch um fehlendes Können, also mangelndes Wissen oder Ausbildung. Product Owner können also aus vielfältigen Gründen scheitern. Wir wünschen uns aber, dass ihr erfolgreich seid und wollen euch mit dieser Folge eine ganze Reihe von Warnhinweisen an den Wegesrand stellen, so dass ihr die Untiefen der eigenen Lernreise früh genug erkennen könnt. Quellen, die genannt werden: Blog-Artikel von Roman Pichler: Be a Balanced Product Leader, not a Feature Broker or Product Dictator Im Gespräch verweisen Dominique und Tim u.a. auch diese älteren Folgen unseres Podcasts, die super zum Thema "Woran scheitern Product Owner?" passen: Herausforderungen zwischen Product Owner & Developer Nein sagen als Product Owner Sind die PO bei euch gut unterwegs? Welche Bedingen machen es bei euch schwierig? Was meint ihr: woran scheitern Product Owner bei euch - oder sind früher vielleicht gestrauchelt, aber jetzt bekommt ihr es besser hin? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.