Die Produktwerker (Tim Klein, Dominique Winter, Oliver Winter)

In dieser Folge geht es um die Herausforderungen und Chancen des Produktmanagements in regulierten Branchen. Tim spricht heute mit Deniz Dogan, Product Management Consultant bei den Product People, über die spezifischen Anforderungen, die auf Product Owner in regulierten Umfeldern zukommen. Regulierung stellt natürlich häufig eine Hürde dar, weil sie viele Freiheiten während der Produktentwicklung einschränkt. Doch dies sollte nicht nur als Beschränkung gesehen werden. Vielmehr bietet die Gesetzeslage oft auch Spielraum, wie Regelungen umgesetzt werden, was Raum für kreative Lösungen schafft. Ein Beispiel in dieser Folge ist der Digital Services Act (DSA), bei dem zwar Vorgaben zu Transparenz und Meldemöglichkeiten erfüllt werden müssen, aber nicht festgelegt ist, wie dies genau zu geschehen hat. Hier zum Beispiel hat Deniz Dogan durch sorgfältige Analyse der Vorgaben und enge Zusammenarbeit mit dem Compliance-Team innovative Ansätze gefunden, um Anforderungen effizient zu erfüllen, ohne unnötigen Aufwand zu erzeugen. Die enge Zusammenarbeit mit Compliance-Teams ist besonders wichtig, um das Produktmanagement in regulierten Branchen zu erleichtern. Deniz betont in dieser Folge, wie wichtig es ist, frühzeitig und proaktiv den Dialog mit diesen Abteilungen zu suchen. Oft wird aus Unsicherheit lieber ein konservativer Ansatz gewählt, der jedoch nicht immer nötig ist. Indem Product Owner die gesetzlichen Rahmenbedingungen genau verstehen und kritisch hinterfragen, können sie unnötige Aufwände vermeiden und gleichzeitig rechtskonform bleiben. So wird aus einem vermeintlichen Hindernis eine Gelegenheit für Produktverbesserungen und damit eine echte Chance. Besonders in regulierten Branchen zeigt sich zudem, dass Vorschriften oft nicht eindeutig sind, was Raum für Interpretation lässt. Dies führt zu Ambiguität, die zwar zusätzliche Komplexität schafft, aber auch Gestaltungsspielräume eröffnet. Dies bietet eine Chance, Wettbewerbsvorteile zu erzielen, indem Unternehmen die Anforderungen nicht nur erfüllen, sondern die Art wie sie die Erfüllung dieser Regulation meistern zu einem Selling Point machen. Ein Beispiel hierfür ist die Barrierefreiheit, bei der sich Unternehmen durch besonders proaktive Maßnahmen im Markt differenzieren können. Letztlich kommt es darauf an, als Product Owner nicht nur die Vorschriften zu erfüllen, sondern den Mehrwert darin zu erkennen, wie ein Produkt dadurch besser und sicherer gestaltet werden kann. Wer bereit ist, die Regeln genauer unter die Lupe zu nehmen und in den Dialog mit den richtigen Stakeholdern zu gehen, kann auch in streng regulierten Märkten innovativ agieren und sich einen Vorsprung verschaffen. Im Produktmanagement in regulierten Branchen geht es also nicht nur darum, sich an Gesetze zu halten, sondern diese auch als Chance zu nutzen, Produkte nachhaltig besser zu machen. Diese früheren Folgen werden in dieser Episode referenziert: - Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt - Barrierefreiheit von digitalen Produkten - Umgang mit schwierigen Stakeholdern Wer weitere Fragen an Deniz hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über die Product People (getproductpeople.com). Von Deniz Dogan gibt es zudem auch ein englisches Webinar der Product People auf YouTube zum Thema ”Product Management in regulated industries: Navigating the Digital Service Act”. Wir hoffen, dass du einige neue Impulse zum Thema reguliertes Umfeld aus den Erfahrungen von Deniz Dogan ableiten konntest. Bist du selber vielleicht auch im Produktmanagement und von Regulation betroffen? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite.

Finanzen sind trocken? Von wegen! In der neuesten Folge der Produktwerker geht es um ein Thema, das für Product Owner oft unter dem Radar bleibt, aber entscheidend für ihre Karriere ist: Finanzwissen. Tim spricht mit Simonetta Batteiger, einer erfahrenen Product Leadership Coachin, über die Relevanz von Zahlen im Produktmanagement und Finanzwissen für Product Owner. Warum sollten sich Product Owner mit Finanzwissen beschäftigen? Viele verstehen intuitiv, wie wichtig Nutzerzentrierung ist, doch die wirtschaftliche Perspektive eines Produkts wird oft vernachlässigt. Simonetta, die selbst eine Karriere im Finance-Bereich startete, bevor sie ins Produktmanagement wechselte, macht deutlich: Wer als Product Owner langfristig erfolgreich sein will, sollte die Zahlen verstehen. Umsatz, Kosten, Marge – diese Faktoren bestimmen nicht nur den Erfolg eines Produkts, sondern auch den eigenen Karriereweg. Product Owner stehen häufig vor der Herausforderung, den Mehrwert ihrer Arbeit für das Unternehmen greifbar zu machen. Ein gut durchdachter Business Case kann hier den entscheidenden Unterschied machen. Wer zeigen kann, wie Produktentscheidungen den Umsatz steigern oder Kosten optimieren, verschafft sich Gehör bei Stakeholdern und Führungsebenen. Gerade in Zeiten wirtschaftlicher Unsicherheit wird das Finanzwissen für Product Owner immer relevanter. Simonetta betont, dass es kein Hexenwerk ist, sich dieses Wissen anzueignen. Ein guter erster Schritt ist der Austausch mit dem Finanzteam: Welche Metriken sind im Unternehmen wirklich relevant? Auf welche KPIs achtet die Geschäftsleitung? Wer diese Fragen stellt, zeigt Initiative und stärkt seine Position als strategische Gestalterin seines Produkts. Auch das Thema Budgetierung kommt im Gespräch auf. Viele Product Owner empfinden den id.R. jährlichen Budgetierungsprozess als Hürde, doch wer ihn versteht, kann ihn aktiv nutzen. Die Budgetplanung ist die beste Gelegenheit, um sich notwendige Ressourcen für das nächste Jahr zu sichern – sei es für neue Teammitglieder, Weiterbildungen oder technische Infrastruktur. Wer Finanzwissen in die eigene Arbeit integriert, trifft nicht nur fundiertere Entscheidungen, sondern stärkt auch seine Rolle im Unternehmen. Ein weiterer wichtiger Punkt: Finanzwissen hilft dabei, mit anderen Abteilungen auf Augenhöhe zu sprechen. Ob mit dem Finanzteam, der Geschäftsführung oder dem Sales-Bereich – wer ihre Sprache spricht und mit Zahlen argumentieren kann, wird ernster genommen und kann seine Roadmap selbstbewusster verteidigen. Ein Product Owner, der Finanzwissen mitbringt, ist weniger austauschbar und steigert seine Karrierechancen erheblich. Wer sich weiterbilden möchte, findet zahlreiche Ressourcen, von Online-Kursen bis hin zu internen Trainings. Simonetta bietet selbst eine regelmäßige Kursreihe für eine kleine Kohorte an, die speziell für Produktmenschen entwickelt wurden. Ihr abschließender Rat: Einfach mal das Gespräch mit dem Finanzteam suchen und neugierig sein. Finanzwissen für Product Owner ist kein Nice-to-have, sondern ein echter Karriere-Booster. Kontakt zu Simonetta Batteiger nehmt ihr am Besten über ihre LinkedIn-Seite auf. Weiterführende Links: - Infos & Buchung zum angesprochenen Kurs von Simonetta: Business and Finance - Concepts for Product and Tech Leaders - Post von Simonetta aus Mind the Product: Finance skills for product people - Blogpost Simonetta Batteiger: So you want a high performing product team? - Blogpost Simonetta Batteiger: How to think and talk about business impact Diese früheren Podcast-Folgen wurden erwähnt: - Leadership Skills für Produktmenschen (Gast. Simonetta Batteiger) - Business KPIs die Product Owner kennen sollten - Produktmanager in einem Startup - Erfahrungsbericht eines Buchhalters

Diesmal geht es um ein Thema, das in der Produktentwicklung oft zu kurz kommt: Well-Being. Während Produktverantwortliche intensiv daran arbeiten, ihre Software effizienter, benutzerfreundlicher und funktionaler zu gestalten, bleibt eine zentrale Frage häufig unbeachtet: Wie beeinflussen digitale Produkte das langfristige Wohlbefinden ihrer Nutzerinnen und Nutzer? Zu Gast ist Tim-Can Werning, Wirtschaftspsychologe und Forscher zum Thema Wohlbefinden im Kontext von Technologie. Er beschreibt, wie Produkte nicht nur kurzfristig nützlich, sondern auch langfristig förderlich für das subjektive Wohlbefinden sein können. Dabei verweist er auf das Konzept des Subjective Well-Being, das neben allgemeiner Lebenszufriedenheit auch die domänenspezifische Zufriedenheit umfasst. Gerade Letzteres ist spannend für Produktverantwortliche, denn viele Menschen nutzen Software nicht freiwillig, sondern als Teil ihres Arbeitsalltags. Die Auswirkungen auf ihre Zufriedenheit gehen daher über den Arbeitsplatz hinaus. Ein Schlüsselkonzept in der Psychologie, das für die Produktgestaltung relevant ist, ist die Selbstbestimmungstheorie. Sie benennt drei grundlegende psychologische Bedürfnisse: Autonomie, Kompetenzerleben und soziale Eingebundenheit. Diese Faktoren beeinflussen, wie motiviert und zufrieden Menschen mit einer Tätigkeit oder einem digitalen Produkt sind. Ein Beispiel aus dem Gespräch zeigt, wie eine Sportuhr durch ihre Art des Feedbacks dem Nutzenden entweder ein Erfolgserlebnis verschaffen oder ihm das Gefühl von Unzulänglichkeit vermitteln kann. Eine unüberlegte Gestaltung kann so das Wohlbefinden ungewollt negativ beeinflussen. Langfristigkeit in der Produktentwicklung ist ein spannendes Thema. Oft wird Erfolg an kurzfristigen KPIs gemessen. Doch was passiert, wenn Nutzer:innen ein Produkt über Monate oder Jahre hinweg verwenden? Welche langfristigen Auswirkungen hat es auf ihr Wohlbefinden? Ein positives Beispiel liefert das Computerspiel Anno 1800, das nach einer gewissen Spielzeit Pausen vorschlägt, um exzessives Spielen zu vermeiden und das Wohlbefinden der Nutzer:innen zu schützen. Hier zeigt sich, dass bewusste Produktgestaltung weit über kurzfristige Interaktionen hinausgeht. Das Well-Being sollte also als integraler Bestandteil der Produktentwicklung gesehen werden. Denn am Ende profitieren nicht nur die Nutzer:innen von besser durchdachten Produkten, sondern auch Unternehmen, deren Software langfristig als positiv wahrgenommen wird.

Gast der heutigen Episode ist eine Expertin zum Thema Product Leadership - Christiane Mehling, Head of Product & Design VoD bei der Mediengruppe RTL. Gemeinsam mit ihrem Team ist sie in der Produktverantwortung für das Streaming-Angebot TVNOW. Oliver fragt Christiane nach den Herausforderungen und ihren persönlichen Erfahrungen, die erste Product Ownerin in einem großen Unternehmen gewesen zu sein, welches ein erstes Scrum Team quasi als Experiment gestartet hatte. Was hat funktioniert? Wie ist es gelungen, tatsächlich mehr und mehr Ownership für das Produkt zu übernehmen und auf welche Fragen stieß Christiane, als das Unternehmen von einem auf sechs Teams skalierte. Loslassen und Vertrauen Nachdem sie nun für mehrere Product Ownerinnen verantwortlich war, konzentrierte sie sich mehr auf die strategischen Aufgaben. Und lernte in operativen Fragen loszulassen und ihrem Produktteam zu vertrauen. Inspiriert von David Marquets [Buch "Turn the ship around"](https://www.amazon.de/Turn-Ship-Around-Building-Breaking/dp/1591846404) entwickelten sie eine gemeinsame Vorstellung, wie ein Zusammenspiel in ihrem individuellen Kontext funktionieren könnte. Kommende Herausforderung Als den nächsten, logischen Schritt hin zu Product Leadership zieht Christiane eine Coachingausbildung in Betracht. Weniger Expert Leader, noch mehr Catalyst Leader ist ihr Ziel. So begeistert, wie sie darüber erzählt, glauben wir, dass ihr auch dieser Schritt gelingen wird. Im Lauf der Episode gibt Christiane zahlreiche Tipps & Tricks aus ihrer eigenen Erfahrung für den Weg hin zu einer Product Leaderin. Wer einen detaillierteren Eindruck von Christiane bekommen möchte, dem sei dieses [Video](https://www.streamingzukunft.de/product-owner) empfohlen. Sie sucht aktuell noch Menschen, die ihr Produktteam verstärken möchten.

Wir haben einen Website-Relaunch vollzogen und dabei versucht, agil und inkrementell vorzugehen. Das ist aber gar nicht so einfach, weil das auch nicht jede Agentur mitmacht, die man ggf. dafür braucht. Einiges an dieser Produktentwicklung hat gut geklappt - bei anderen Sachen haben wir selbst mal wieder eine Menge gelernt. Wir berichten, welche User Probleme und Business Needs uns initial dazu gebracht haben, unser "Produkt" Website nochmal grundlegend zu überarbeiten und wie wir diese Aufgabe angegangen sind. Natürlich berichten wir auch darüber was gut geklappt hat und über unsere Fehler. Natürlich kämpfen auch wir selbst mit der Frage, wann es "gut genug" ist bzw. wann das Ergebnis unserem Anspruch genügt um live zu gehen. Tim und Oli berichten zudem, wie sie die Zusammenarbeit mit der Agentur agil gestalten konnten und welche Erfolgsmetriken sich die Produktwerker selber für den Website-Relaunch gesetzt haben. Ein großes Problem welches wir mit dem Website-Relaunch lösen wollen, ist die bessere Auffindbarkeit von unseren ganzen älteren Podcast-Folgen. Da steckt noch soviel wertvoller Content drin, aber bei nun schon 211 Episoden fand man diese "Perlen" gar nicht mehr so einfach. In den üblichen Podcast-Playern ist das eh nahezu unmöglich, aber auf unserer Website gab es halt auch nur eine unsäglich lange Liste. Also haben wir nun eine Schlagwortsuche und vor allem eine Filterung nach thematischen Kategorien eingebaut. Insbesondere zu dieser neuen Podcast-Suche wollen wir euch nun ganz herzlich um euer Feedback bitten und geben euch im Gegenzug die Chance einen tollen Preis zu gewinnen. Geht einfach auf der Website auf die Seite Podcast und klickt auf den Feedback-Button. Unser allen Einsendungen von Feedback verlosen wir einen Platz in unserem Strategietraining am 23./24.April in Köln. Zu dieser Episode passen diese älteren Folgen: - Als Product Owner auf Seiten einer Agentur - Zusammenarbeit mit einem UX-Dienstleister - Der Product Owner aus Sicht eines Dienstleisters Wir möchten uns an dieser Stelle ausdrücklich bei unserem geschätzten Kooperationspartner Webrunners und Geschäftsführer Adrien Simon bedanken. Insbesondere gilt aber unser Dank Finja Kolzem, die für und mit uns verantwortlich die neue Seite gebaut hat. Danke für Deinen großartigen Einsatz liebe Finja! Ebenfalls geht ein großes Dankeschön an Marek Nowacki (snckbl media) für unser überarbeitetes Corporate Design. Welche Erfahrungen habt ihr evtl. schon mal bei der Erstellung einer neuen Website gemacht? Inwiefern war das für euch inkrementell machtbar und hattet ihr dafür einen passenden Dienstleister bzw. Agentur, die dabei mitgespielt hat? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Zum Jahreswechsel werfen wir zu Dritt mal einen Blick nach vorne und schauen uns unseren Wunschzettel an. Welches sind unsere Wünsche für 2022? Na, gut - nicht irgendwelche Wünsche, sondern explizit aus dem Kontext von Product Ownern. Oliver Winter, Dominique Winter und Tim Klein haben jeweils drei eigene Wünsche in den Ring geworfen und auf einen gemeinsamen zehnten Wunsch konnten wir uns dann auch noch einigen… Entstanden ist ein interessantes Gespräch mit einem bunten Reigen von wichtigen Themen zur aktuellen Situation und Rolle von Product Ownern. Durch das Gespräch gibt es kompakte Impulse und Hinweise, wo auch ihr in eurem organisatorischen Umfeld mal hingucken könntet. Vielleicht könnt ihr einzelne Produktwerker Wünsche für 2022 dann ja bereits bei euch in der Wirklichkeit erfüllen. Unsere 10 Wünsche für 2022: 1.) Scrum nur dort einsetzen, wo Scrum auch hingehört 2.) Cross-funktionale Teams über die Softwareentwicklung hinaus etablieren 3.) Klarheit, dass "SAFe Product Owner" ungleich "Scrum Product Owner" ist 4.) Integration von Product Discovery in Scrum 5.) "Erlebnisse" als Outcome der Produktentwicklung etablieren 6.) Mehr Fokus auf Produktmanagement in Scrum Product Owner Trainings 7.) Echte Product Roadmaps! 8.) Mut, auch unpopuläre aber wichtige Entscheidungen zu treffen 9.) Mehr "JA" sagen, anstatt so viel "NEIN" sagen zu müssen 10.) Mehr Zeit für die eigene Weiterentwicklung als Product Owner nehmen Im Laufe des Gesprächs nennen Tim, Dominique und Oliver folgende Bücher bzw. Artikel: - Marty Cagan: Empowered (im Kontext der "Empowered Product Teams") - Roman Pichler - Six Types of "Product" Owners - Marty Cagan: The Four Big Risks - Teresa Torres: Continuous Discovery Habits - Jeff Patton / Jeff Gothelf: Dual Track Development - Nacho Bassino: Product Direction - C. Todd Lombardo et al.: Product Roadmaps Relaunched - Robbin Schuurman / Willem Vermaak: 50 Arten, Nein zu sagen Zudem wurde auf die beiden folgenden Podcast-Episoden verwiesen: - Verantwortung übernehmen als Product Owner (mit Andy Schliep) - Sei Dein eigenes Produkt! Und am Ende empfiehlt Tim als Content-Quelle für die eigene Weiterentwicklung unsere recht neue "Produktwerker Box" (im Menü zu finden oder direkt unter https://produktwerker.de/box/) Wir würden uns auch echt freuen zu hören, was Eure Wünsche für 2022 denn so sind! Alles nur "weiter so"? Oder woran wollt ihr etwas verändern, z.B. an der Organisation und en Rahmenbedingungen arbeiten? Und worin wollt ihr euch selbst weiterentwickeln? Wenn euch die Folge gefallen hat würden wir uns über Feedback freuen - v.a. in Spotify, in Apple Podcast oder der von euch genutzten Podcast-App sowie als Kommentar in unserem Blog-Post auf der Website.

Wenn wir mit mehreren Teams an einem umfangreichen Projekt arbeiten, stellt sich oft auch im Design die Frage nach einer systematischen Vorgehensweise. Eine strukturierte Möglichkeit hierfür ist die Implementierung eines Designsystems. In dieser Folge wollen wir untersuchen, wann sich ein Designsystem in der Produktentwicklung lohnt und vor allem aus der Sicht der Product Owner beantworten. Dafür haben wir Laura Marwede eingeladen, Head of UX & Strategy bei TEAM23, die sich mit ihrem Team bereits seit geraumer Zeit mit diesem Thema beschäftigt. Sie ist somit die ideale Person, um Dominique in dieser Episode Rede und Antwort zu stehen. Der potenzielle Mehrwert von Designsystemen liegt darin, dass sie einen konsistenten und strukturierten Ansatz für die Gestaltung und Entwicklung von Produkten bieten. Sie bestehen aus einer Sammlung von Komponenten, Stilen, Richtlinien und Prinzipien, die als Grundlage für das gesamte Design einer Anwendung oder eines Produkts dienen. Designsysteme fördern die Konsistenz und Einheitlichkeit in der Produktentwicklung. Durch die Verwendung vordefinierter Komponenten und insbesondere Stile können wir als Product Owner sicherstellen, dass das Erscheinungsbild und die Benutzererfahrung unserer Produkte einheitlich sind. Zudem können Designsysteme den Entwicklungsprozess beschleunigen, da wir nicht jedes Mal von Grund auf neu beginnen müssen. Ein Großteil der Gestaltungsentscheidungen ist bereits getroffen, was Zeit und Ressourcen spart. Es gibt jedoch auch potenzielle Nachteile bei der Verwendung von Designsystemen. Insbesondere der anfängliche Aufwand für die Erstellung eines Designsystems sollte nicht unterschätzt werden. Es erfordert Zeit und Ressourcen, um die richtigen Komponenten und Stile zu definieren und das Designsystem aufzubauen. Wenn dann jedoch immer wieder Diskussionen über das Design entstehen, wird der eigentliche Vorteil eines Designsystems nicht realisiert. Wann sollten wir als Product Owner also Designsysteme nutzen? Die Antwort ist: Es kommt drauf an. Wenn ein Produktteam wächst und das Produkt selbst eine gewisse Größe erreicht hat, kann die Einführung eines Designsystems die Zusammenarbeit erleichtern und die Konsistenz sicherstellen. Es wird dann zu einem nützlichen Werkzeug für die Produktgestaltende.

Die Formulierung von einem Sprint-Ziel als Produkt Owner ist nicht einfach. Dominique, Tim und Oliver klären daher zu Beginn dieser Folge, was sie unter einem Sprint-Ziel überhaupt verstehen. Der neue Scrum Guide von 2020 wertet das Sprint-Ziel als Commitment auf das Sprint-Backlogs auf. Grund dafür ist u.a. die Wichtigkeit, als Scrum-Team Fokus hin auf ein gemeinsames Ziel zu schaffen. Wir geben Euch zahlreiche Beispiele aus der Praxis für die Formulierung von einem Sprint-Ziel als Produkt Owner, den Einsatz im Sprint und Überprüfung der Zielerreichung. Und wir hoffen, dass unsere Tipps & Tricks Euch für die tägliche Arbeit weiterhelfen.

Schon im Scrum Guide wird klar formuliert, dass Scrum Master in bestimmten Fragestellungen ihre Product Owner unterstützen sollen. Als ausgewiesenen Experten für die Scrum Master Rolle haben wir uns daher erneut Alexander Kylburg eingeladen. Er ist schon mindestens 15 Jahre in der agilen Szene und vor allem im Rheinland ein sehr engagiertes Mitglied der Agile Community. So hat er den Kölner Scrumtisch nahezu von Tag 1 begleitet und die regelmäßige Agile Cologne als bedeutende agile Konferenz zusammen mit anderen vor über 10 Jahren ins Leben gerufen. Tim bespricht mit Alexander zunächst mal, wie er die Verantwortlichkeit von Scrum Mastern versteht und wie sie selbst ihre Scrum Master weiterbilden. Natürlich auch, wie man als Scrum Master überhaupt in die Product Owner Themen reinkommen kann. Spannend ist seine Einschätzung, wie gut bzw. intensiv Scrum Master heutzutage ihre Product Owner unterstützen. Was muss ein Scrum Master dafür wissen, um eine wertvolle methodische Unterstützung bzw. entsprechendes Coaching leisten zu können? Aber de beiden kommen im Gespräch auch an den üblichen Problemen vorbei: Was ist, wenn sich der der Product Owner vielleicht gar nicht helfen lassen will bzw. faktisch der Scrum Master keinen entsprechenden Zugang zum Product Owner findet? Genauso kann sich das Problem auch andersrum darstellen: der Product Owner "zieht" den Scrum Master in inhaltliche und operative Arbeit hinein und missachtet dabei die eigentliche Rolle des Scrum Masters. Darüber hinaus gibt es in dieser Folge auch praktische Tipps, wie sich Scrum Master das entsprechende Wissen aneignen können und auf Augenhöhe bleiben können. Das von Alexander Kylburg mehrfach erwähnte "Agile Coaching Growth Wheel" ist in Toolbox (empfehlenswert!) von paragraph eins gut und detailliert beschrieben: paragraph1.de/toolbox/das-agile-coaching-growth-wheel Das Toleranz Modell und das am Ende erwähnte Kartenspiel "Toleranz Poker" könnt ihr dort ebenfalls finden. Auf folgende ältere Folgen wird im Laufe des Gesprächs verwiesen: - Konflikte zwischen Scrum Master und Product Owner (mit Gast Alexander Kylburg - Dein Freund der Scrum Master Wer mit Alexander Kylburg oder seiner Firma paragraph eins (paragraph1.de) in Kontakt treten möchte, erreicht ihn am Besten auf seinem LinkedIn-Profil. Übrigens ist paragraph eins ein sehr geschätzter Kooperationspartner von uns. Wir hoffen, dass du mit dieser Folge wertvolle Ideen bekommen hast, wie du als Scrum Master oder Product Owner ein gutes Sprint Review gestalten kannst. Welche Erfahrungen hast Du selber gemacht und magst darüber berichten? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Folge tauschen sich Tim und Oliver zu agilen Praktiken aus. Sie geben dabei Einblicke in ihre persönliche Vorlieben: Welche agile Praktiken funktionieren? Und welche funktionieren für sie nicht? Tim und Oliver teilen, welche Tools sie in ihren Werkzeugkoffer packen, um ihrer Verantwortung als Product Owner gerecht zu werden. Diese Folge ist ein wilder Ritt von der Produktvision bis hin zum Product Backlog. Dabei wird auf eine ganze Reihe von früheren Podcast-Folgen Bezug genommen: - Wie die Produktvision hilft, Product Ownern eine Richtung zu geben - Agile Product Roadmaps - Story Mapping nutzen, um über Outcome zu sprechen - Das Product Goal und seine Bedeutung für Product Owner - Dein Freund der Scrum Master Oliver erwähnt das Buch Continuous Discovery Habits (von Teresa Torres). Hier die Übersicht zu den agilen Praktiken und Canvas aus dieser Episode: - Empathy Map Canvas - Value Propositiom Canvas - Product Vision Board - GO Product Roadmap .- Opportunity Solution Tree

Oft genug wird in Organisationen ein Product Owner Team implementiert. Aber steht denn nicht im Scrum Guide, dass die Product Owner Verantwortung nicht bei einem Komitee liegen darf? Dominique und Oliver diskutieren daher in dieser Episode die Vor- und Nachteile von Product Owner Teams. Anhand von Beispielen aus der eigenen Praxis zeigen Dominique & Oliver Gründe auf, die dazu führen können, in einer Produktentwicklung nicht nur mit einem Product Owner zu arbeiten. Dabei darf natürlich ein Blick auf Skalierungsframeworks wie Nexus, LeSS und SAFe nicht fehlen. Ein weiterer Schwerpunkt der Folge liegt darauf, zu reflektieren ob und wann PO Teams tatsächlich sinnvoll sein können. Welche Formen von Abreitsaufteilung unter den Product Owner sollte dabei gegeben sein. Und welche Rolle spielen die Developer und die Fachabteilungen in der Organisation, um weiterhin schnell und effizient Produktentscheidungen treffen zu können.

Als Product Owner stehen wir oft im Rampenlicht. Eine ausgeprägte Präsenz ist daher hilfreich. Wie wir eine Präsenz entwickeln und welche Aspekte dabei besonders wichtig sind, bespricht Dominique mit Alexandra Klingor. Zu ihren Gesprächsthemen gehören beispielsweise der Umgang mit Unsicherheitsgesten, die Frage "Wie wirke ich authentisch?" und welche Bedeutung Präsenz in einer Führungsrolle einnimmt. Wenn Ihr Rückfragen an Alexandra Klingor habt oder sie z.B. für einen Workshop bei Euch anfragen wollt, dann schreibt Ihr gerne via XING: https://xing.to/alexklingor Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Planning Poker ist ein weit verbreitete Technik, wenn es darum geht im agilen Kontext zu schätzen. Dabei kann ein Team durch gemeinsames Schätzen und einem gezielten Austausch von Argumenten sich nach und nach ein gemeinsames mentales Modell erarbeiten. Schätztungen, die so entstehen werden anschließend zur Priorisierung und Planung eingesetzt. Die Grundlage für Planning Poker bildet im Grunde eine Technik namens Breitband-Delphi, bei der auch mehrere Experten zusammen ein Urteil abgeben und sich zwischen ihren individuellen Aussagen abstimmen dürfen. In dieser Folge besprechen Oliver und Dominique welche Rolle die Technik für Product Owner hat und an welchen Stellen sie vielleicht noch wertstiftend eingesetzt werden kann. Nach der Klärung, woher die Technik eigentlich kommt sprechen die beiden über den konkreten Ablauf und mögliche Einsatzzwecke. Außerdem denken die beiden auch darüber nach, welche Vor- und Nachteile die Technik hat. Gerade um die Nachteile sollten Product Owner wissen, damit sie mit den Ergebnissen einer solchen Schätzung umgehen können bzw. wissen an welchen Stellen Ergebnisse vielleicht auch mal hinterfragt werden sollten. Oliver und Dominique schließen wie immer mit einigen Tipps, die ihrer Erfahrung nach dabei helfen noch ein wenig mehr aus der Planung mittels Planning Poker herauszuholen. Im Gespräch wird auf folgende anderen Folgen verwiesen: - Agiles Schätzen: Magic Estimation (https://produktwerker.de/magic-estimation/) Folgende Referenzen finden wir in dem Kontext wertvoll: - The Original Paper (https://wingman-sw.com/articles/planning-poker) - Planning Poker auf der Website von Mountain Goat Software (https://www.mountaingoatsoftware.com/agile/planning-poker) Darüber hinaus empfiehlt sich bei Gelegenheit ein Blick in das Buch "Agile Estimating and Planning" von Mike Cohn, auch wenn es mittlerweile an einigen Stellen etwas in die Jahren gekommen ist.

Die Aussage "Agile is dead" macht aktuell die Runde und sorgt für lebhafte Diskussionen auch in der Product-Owner-Community. Ist das Ende agiler Methoden wirklich erreicht, oder handelt es sich um eine missverstandene These? In dieser Folge der Produktwerker spricht Kai Simons mit Oliver über diese Frage und mögliche Auswirkungen auf Product Owner. Kai Simons, Gründer von Agile Growth und Certified Scrum-Trainer der Scrum Alliance, beleuchtet, warum der Ruf nach dem "Tod von Agilität" in der Luft liegt. Dabei sieht er die Wurzeln dieser Aussage weniger in einem Versagen der agilen Prinzipien, sondern vielmehr in der Art und Weise, wie diese umgesetzt wurden. "Agile Methoden sind leicht zu verstehen, aber schwer zu meistern", betont Kai. Viele Organisationen scheitern nicht an den Ideen, sondern an der konsequenten Transformation und den Rahmenbedingungen, die dafür notwendig sind. Für Product Owner bringt diese Diskussion einige Herausforderungen und Chancen mit sich. Die Rolle erfordert nicht nur fachliche Expertise, sondern auch Leadership-Qualitäten und die Fähigkeit, eine klare Produktvision zu entwickeln und zu kommunizieren. Kai teilt aus seiner Erfahrung, wie oft die falschen Personen diese Verantwortlichkeiten übernehmen, ohne den nötigen Mut, Entscheidungen zu treffen oder die strategische Weitsicht mitzubringen. Dieses Missverständnis trägt zu dem Frust bei, der Agilität als gescheitert erscheinen lässt. Ein zentraler Punkt der Diskussion ist das Vertrauen – sowohl in die eigenen Fähigkeiten als Product Owner als auch in das Team und die Organisation. Nur wenn Product Owner und Teams das Vertrauen aufbauen und halten können, lassen sich agile Prinzipien effektiv umsetzen. Die Verbindung zwischen den agilen Werten und der Realität im Unternehmen ist entscheidend. In vielen Fällen fehlen jedoch die Unterstützung durch Scrum Master oder ein Verständnis dafür, wie die Zusammenarbeit mit Entwicklern gestaltet werden muss, um langfristig erfolgreich zu sein. "Agile is dead" muss nicht das Ende agiler Methoden bedeuten. Vielmehr ist es eine Chance, den ursprünglichen Kern agiler Ansätze wiederzuentdecken und neu zu beleben. Es geht um kontinuierliches Lernen, ehrliches Feedback und die Bereitschaft, an sich selbst und den eigenen Prozessen zu arbeiten. Für Product Owner heißt das konkret: Die Bereitschaft, Führungsqualitäten zu entwickeln, sich mit den Bedürfnissen des Teams auseinanderzusetzen und die agile Transformation aktiv mitzugestalten. Wer also glaubt, Agilität sei tot, sollte genau hinhören: Agilität lebt dort weiter, wo Menschen mutig Verantwortung übernehmen, wo Teams und Organisationen bereit sind, Veränderungen zu wagen, und wo die Prinzipien nicht als Checkliste, sondern als Leitlinien für echte Zusammenarbeit verstanden werden.

In dieser Folge unseres Product Owner Podcast sprechen Dominique & Oliver über die agile Praktik Magic Estimation. Und natürlich legen sie den Fokus ihrer Diskussion auf den besonderen Nutzen dieser Schätzmethode für Produkt Owner. Die Idee geht ursprünglich auf einen Vorschlag von Lowell Lindstrom aus dem Jahr 2008 zurück. Er nannte seine Idee „Affinity Estimation“. Boris Gloger griff den Ansatz auf und überarbeitete diesen zu Magic Estimation. Das Magische: sehr viele Product Backlog Items in sehr kurzer Zeit durchschätzen, um beispielsweise für ein bestimmtes Release eine grobe Idee zu einem Termin abgeben zu können. Dominique erläutert, wie er eine solche magische Schätzsession vorbereitet und dann mit dem Team durchführt. Er teilt viele hilfreiche Tipps und Tricks, die auch die Aufgaben eines Product Owners nach einer solchen Session betreffen: Wir überführe ich die Schätzungen ins Product Backlog? Und warum macht es Sinn, die Ergebnisse der Schätzungen im Product Backlog besonders zu markieren?

Wie bitte? In nur wenigen Wochen von der Idee zur Marktreife eines Produkts? Wie soll das denn bitte gehen? Tim hat Johannes Geske als Gast dazu eingeladen, denn er hat als Product Owner im Kundenauftrag für eine weltweit aktives B2B Unternehmen gezeigt, wie sowas mit streng hypothesen-getriebenem Vorgehen gelingen kann. In nur drei Sprints wurde durch iterativ-inkrementelles Vorgehen im Zusammenspiel mit intensiver Product Discovery ein release-fähiges Produkt für rund 15.000 Kunden des Auftragnehmers geschafften. Das Scrum Team von Johannes Geske war allerdings zuvor schon komplett eingespielt und in der Zusammenarbeit entsprechend erfahren, so dass es hier keine Lernkurve der Teamentwicklung gab, sondern der komplette Fokus auf ein schnelles Lernen durch Feedback gelegt werden konnte. Johannes nennt solch ein Setup "Plug & Play Scrum Team". Konkret wurden durch das Team einige Hypothesen bereits während jedes Sprints durch Kundenbesuche und unmittelbares User-Feedback zum Produkt Inkrement verifiziert bzw. eben auch einige falsifiziert. Letzteres ist eigentlich besonders "schön", denn diese Ideen muss man dann ja auch gar nicht umsetzen und vermeidet Verschwendung. In seinem Erfahrungsbericht spricht Johannes Geske über die Learnings dieses Vorgehens, wie z.B. klare Problem-Fokussierung, wie Vertrauen beim Kunden für dieses Vorgehen erworben wurde sowie die Festpreis-Beauftragung je Sprint durch den Kunden, d.h. z.B. auch die Go/NoGo-Entscheidung nach jedem Sprint. Für alle, die sich Details in Ruhe durchlesen wollen, hat Amazing Outcomes eine vom Kunden freigegebene Case Study erstellt. Diese gibt's hier: https://amazing-outcomes.de/de/what-we-offer/plug-and-play-scrum-team-fuer-ihr-projekt Mehr über Johannes Geske und sein Team erfahrt ihr auf der Webseite von Amazing Outcomes: https://amazing-outcomes.de/. Gerne freut er sich auch über den direkten Kontakt zu euch - am besten per Mail (hello@amazing-outcomes.de) oder LinkedIn, wo ihr ihm auch folgen solltet: https://linkedin.com/in/johannesgeske/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: - Agiler Festpreis – Chancen & Grenzen dieser Vertragsform - Das Problem mit dem Minimal Viable Product Wie bitte? In nur wenigen Wochen von der Idee zur Marktreife eines Produkts? Wie soll das denn bitte gehen? Tim hat Johannes Geske als Gast dazu eingeladen, denn er hat als Product Owner im Kundenauftrag für eine weltweit aktives B2B Unternehmen gezeigt, wie sowas mit streng hypothesen-getriebenem Vorgehen gelingen kann. In nur drei Sprints wurde durch iterativ-inkrementelles Vorgehen im Zusammenspiel mit intensiver Product Discovery ein release-fähiges Produkt für rund 15.000 Kunden des Auftragnehmers geschafften. Das Scrum Team von Johannes Geske war allerdings zuvor schon komplett eingespielt und in der Zusammenarbeit entsprechend erfahren, so dass es hier keine Lernkurve der Teamentwicklung gab, sondern der komplette Fokus auf ein schnelles Lernen durch Feedback gelegt werden konnte. Johannes nennt solch ein Setup "Plug & Play Scrum Team". Konkret wurden durch das Team einige Hypothesen bereits während jedes Sprints durch Kundenbesuche und unmittelbares User-Feedback zum Produkt Inkrement verifiziert bzw. eben auch einige falsifiziert. Letzteres ist eigentlich besonders "schön", denn diese Ideen muss man dann ja auch gar nicht umsetzen und vermeidet Verschwendung. In seinem Erfahrungs Welche Erfahrung habt ihr schon mit streng hypothesengetriebener Entwicklung gemacht? Wie gelangt ihr von einer Idee zur Marktreife? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Welches Mindset ist für einen Product Owner eigentlich hilfreich? Das bespricht Tim mit Dennis Willkomm (Agile Coach). Dennis klärt uns über den Dreiklang eines Mindsets auf und erklärt was es mit Denken, Fühlen und Handeln auf sich hat. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Wir werden in diesem Podcasts Themen rund um die Rolle von Product Ownern besprechen. Hier eine kurze Vorstellung des Podcasts und von uns. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Als Product Owner treffen wir ständig Entscheidungen. Priorisierung des Product Backlogs, Festlegen eines Sprintziels, das nächste Ziel auf der Product Roadmap oder die vielen anderen, kleinen Dinge im Alltag. Warum das Entscheiden eher einem Pokerspiel als einem Schachspiel gleicht und Product Owner wie Pokerspieler denken sollten, darüber sprechen Tim und Oliver in dieser Episode. Die zwei Faktoren, die das Ergebnis einer Entscheidung entscheiden, sind die Qualität des Entscheidungsprozesses und Glück. Diese These formuliert Annie Duke, professionelle amerikanische Pokerspieler in ihrem Buch “Thinking in Bets”. Dieses in Wetten denken ist ein gutes Gedankenmodell für Product Owner. Denn bei jeder Entscheidung existiert ein gewisses Maß an Unsicherheit. Wichtig ist zu wissen, wie hoch meine Gewinnchancen sind und was ich einsetzen muss, wenn ich diese Wette eingehe. So kann ich wie im Poker den Anteil guter Wetten erhöhen und erfolgreicher sein. Der zweite, auch im Produktkontext hilfreiche Gedanke ist, nicht vom Ergebnis einer Entscheidung auf die Qualität der Entscheidung zu schließen. Dies folgt aus der Komponente Glück, denn selbst wenn ich zu 95% sicher bin, können die 5% doch eintreten. Wenn ich als Product Owner wie ein Pokerspieler mich nicht zu sehr von den Ergebnissen beeinflussen lasse, dann werde ich beispielsweise selbstbewusster auftreten und meine Entscheidung nachträglich den Stakeholdern begründen können.

Ist ein Proxy Product Owner sinnvoll? Wann und warum kann es diese Rolle geben? Wie kann man dieses Anti-Pattern überwinden oder im Zweifel auch damit umgehen? Zunächst mal erklären Tim und Dominique, was ein Proxy Product Owner ist bzw. was dies bedeutet. Auch die vielfältigen Gründe weshalb eine solche Rolle in bestimmten Situationen anzutreffen ist, werden erläutert. Besonders oft, sieht man eine solche Aufstellung, wenn das Scrum Team von einem Dienstleister gestellt wird, die Product Ownerin aber vom Auftraggeber gestellt wird. Letztlich ist der Einsatz einer Proxy Product Owner Rolle jedoch ein Anti-Pattern in Scrum. Insofern diskutieren die beiden, zu welchen Problemen es in der agilen Produktentwicklung durch solch eine Konstellation kommen kann. Spannend sind dann die Empfehlungen von Dominique und Tim, wie die Situation überwunden werden kann, also wie man diese "organisatorische Schuld" und somit die Proxy Product Owner Rolle wieder loswerden kann. Letztlich ist der Einsatz eines Proxy-PO auch recht nah dran an der Frage, ob und wie eine Arbeit mit zwei Product Ownern in einem Team möglich ist - dies war das Thema der letzten Folge. Im Zweifel also auch hier nochmal reinhören. Manchmal mag es aber auch Situationen geben, in denen - zumindest für einen bestimmten Zeitraum - mit dieser Rolle gelebt werden muss. Auch hierfür geben die beiden Empfehlungen ab, wie man dies möglichst gut meistern kann. Das Gespräch endet wie gewohnt mit Tipps & Tricks im Umgang mit der Herausforderung "Proxy Product Owner". Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt in dieser Folge erwähnt: - Den Wert des Produktes maximieren - Ein Scrum Team, zwei Product Owner. Geht das? - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Der Product Owner aus Sicht eines Dienstleisters - Zusammenarbeit mit dem externen Team eines Dienstleisters Warst du auch schon mal als Proxy-PO im Einsatz oder hast eine solche Situation in einem Team erlebt? Was war der Grund, dass dort ein Product Owner Proxy eingesetzt wurde? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch weitere gute Tipps, wie der Einsatz einer solchen Rolle sinnvoll und wertstiftend gelingen kann. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Tim, Dominique und Oliver haben im Product Owner Podcast von Die Produktwerker schon in der einen oder anderen Folge über die Notwendigkeit einer Produkt Vision gesprochen. In dieser Episode geht es aber primär um die UX Vision bzw. das UX Vision Canvas, welches Dominique Winter in den letzten Jahren entwickelt und mit dem er in vielen Organisationen sehr erfolgreich gearbeitet hat. Das ist Grund genug, dass sich Oliver mit Dominique in der aktuellen Episode über das Thema ausführlich unterhalten haben. Die beiden starten in das Gespräch mit der Frage, warum es sich als Produktentwicklungsteam lohnen kann, auch eine UX Vision zu erarbeiten. Dominique teilt in der Diskussion seine reichhaltigen Erfahrungen, wie man an die Erstellung dieses Artefaktes herangehen sollte. Dabei kann das UX Vision Canvas bei vielen Fragestellungen und Perspektivwechsel gut unterstützen. Selbstverständlich ist das Befüllen der Felder des UX Vision Canvas kein Selbstzweck, sondern spannend wird es erst, wenn man in der täglichen Arbeit als Product Owner auch mit der abgestimmten UX Vision arbeitet. Auch hierzu teilt Dominique wieder viele Learnings aus der Praxis. Er hat einige Beispiele dabei, wie ich diese UX Vision nutzen kann und welche Herausforderungen dabei zu beachten sind. Wie jede Podcastfolge schließen die Beiden mit Tipps & Tricks ab. Die beiden starten in das Gespräch mit der Frage, warum es sich lohnen kann, auch eine UX Vision zu erarbeiten. Dominique teilt in der Diskussion seine reichhaltigen Erfahrungen, wie man an die Entwicklung herangehen sollte. Dabei kann das UX Vision Canvas gut unterstützen. Natürlich ist das Ausfüllen des UX Vision Canvas kein Selbstzweck, sondern spannend wird es erst, wenn man in der täglichen Arbeit als Product Owner auch mit der UX Vision arbeitet. Auch hierzu teilt Dominique wieder viele Learnings aus der Praxis, wie ich diese UX Vision nutzen kann und welche Herausforderungen dabei zu beachten sind. Wie jede Podcastfolge schließen die Beiden mit Tipps & Tricks ab.

In dieser Folge sprechen Dominique und Oliver über Triggerpunkte gesprochen – sowohl unsere persönlichen als auch diejenigen, die wir in Produktorganisationen erleben. Diese Punkte können starke emotionale Reaktionen und Konflikte auslösen und sind oft tief in den Strukturen und Spannungen einer Organisation verwurzelt. In der Episode möchten wir die wichtigsten Erkenntnisse und einige Strategien vorstellen, wie man in Produktorganisationen diese Triggerpunkte erkennen und damit umgehen kann. Triggerpunkte sind Themen oder Ereignisse, die intensive emotionale Reaktionen hervorrufen. Sie können in vielen verschiedenen Kontexten auftreten, von gesellschaftlichen Themen wie Gender-Sternchen bis hin zu spezifischen organisatorischen Veränderungen. In der Arbeitswelt können Triggerpunkte zu Konflikten und Spannungen führen, die die Zusammenarbeit und Produktivität beeinträchtigen. Typische Triggerpunkte in Produktorganisationen Änderungen in der Produktstrategie Eine plötzliche Änderung der Produktstrategie, die nicht ausreichend kommuniziert oder begründet wird, kann bei den Betroffenen zu Unzufriedenheit und Widerstand führen. Produktverantwortliche müssen oft Entscheidungen umsetzen, die sie nicht nachvollziehen können, was das Gefühl der Ungerechtigkeit verstärken kann. Neue Tools und Prozesse Die Einführung neuer Tools oder Prozesse ohne Rücksprache mit dem Team kann starke negative Reaktionen auslösen. Dies gilt insbesondere, wenn die neuen Werkzeuge die bisherigen Arbeitsweisen erheblich verändern und zusätzliche Belastungen verursachen. Organisatorische Veränderungen Veränderungen in der Teamzusammensetzung oder organisatorische Umstrukturierungen können bestehende Spannungen verstärken. Wenn beliebte Teammitglieder versetzt oder entlassen werden, kann dies das Vertrauen und die Moral im Team beeinträchtigen. Mangelnde Kommunikation und Einbeziehung Eine unzureichende Kommunikation seitens der Führungsebene und das Gefühl, nicht in Entscheidungsprozesse einbezogen zu werden, können starke emotionale Reaktionen hervorrufen. Oft fühlen sich Mitarbeiter ungerecht behandelt oder nicht wertgeschätzt. Ursachen und Auslöser von Triggerpunkten Die Ursachen für Triggerpunkte liegen oft in tief verwurzelten Überzeugungen und Werten. Diese können durch mangelnde Transparenz, unzureichende Kommunikation oder das Fehlen von Ressourcen und Unterstützung verstärkt werden. Ein Gefühl der Ungerechtigkeit oder ungleiche Behandlung kann ebenfalls ein starker Auslöser sein. Strategien zum Umgang mit Triggerpunkten Offene und transparente Kommunikation fördern Eine klare und transparente Kommunikation ist entscheidend, um Triggerpunkte zu vermeiden oder zu entschärfen. Indem man die Gründe hinter Entscheidungen erläutert und die Betroffenen frühzeitig einbezieht, kann man Missverständnisse und Widerstände reduzieren. Vertrauen aufbauen Vertrauen ist die Grundlage für jede erfolgreiche Zusammenarbeit. Führungskräfte sollten durch ihr Verhalten Vertrauen schaffen, indem sie sich öffnen, Schwächen zeigen und die Meinungen und Bedürfnisse der Mitarbeiter ernst nehmen. Ressourcen bereitstellen Um mit neuen Herausforderungen umzugehen, benötigen Teams ausreichende Ressourcen und Unterstützung. Schulungen und Weiterbildungen können helfen, die Kompetenzen zu erweitern und die Arbeitsbelastung zu bewältigen. Kulturelle Veränderungen anstoßen Eine positive Unternehmenskultur, die auf Vertrauen, Offenheit und Zusammenarbeit basiert, kann langfristig dazu beitragen, Triggerpunkte zu minimieren. Führungskräfte sollten diese Kultur vorleben und kontinuierlich fördern. Sprache bewusst wählen Die Wahl der Worte kann einen großen Unterschied machen. Anstatt Begriffe zu verwenden, die negative Assoziationen hervorrufen, sollte man neutralere oder positivere Formulierungen wählen, um Widerstände zu vermeiden.

Was mache ich als Product Owner ohne Scrum Master Unterstützung? Also, falls meine Organisation denkt, dass man sich einen Scrum Master sparen kann oder die/der mehrere Teams gleichzeitig betreut. Sollte ich als Product Owner diese Lücke ausfüllen - denn mein Ziel ist ja der maximale Erfolg meines Produktes. Dominique und Tim diskutieren zunächst die Gründe, warum es in Teams keinen Scrum Master geben könnte. Und stellen fest, dass es diese dysfunktionale Situation wesentlich häufiger gibt als man denkt. Dann gehen sie den Problemen nach, die durch das Fehlen eines Scrum Masters entstehen können. Welche Optionen haben wir als Product Owner in dieser Situation? Sollten die Verantwortlichkeiten des Scrum Master im Team aufgeteilt werden? Laut aktuellem Scrum Guide ist das unserer Meinung nach prinzipiell möglich. Wir raten allerdings dringend davon ab, sowohl Product Owner als auch Scrum Master Verantwortlichkeiten gleichzeitig zu übernehmen. Das Team besser zu machen, durch Inspect & Adapt der Zusammenarbeit ist nicht euer Job. Trotzdem versuchen Tim & Dominique in dieser Folge euch Tipps zu geben, wie ihr mit dieser Situation besser umgehen könnt.

Manche Produkte bringen ihre ganz eigenen Herausforderungen mit. Eine besondere Zielgruppe kann so eine Besonderheit sein. Dominique unterhält sich in dieser Folge mit Daniela Mainzer (https://www.linkedin.com/in/daniela-mainzer-121a5616b/) und Daniel Haupt (https://www.xing.com/profile/Daniel_Haupt2/cv) von Super RTL über die Besonderheiten der Entwicklung von Produkten für Kinder. Und wer jetzt denkt, was soll es da schon an Besonderheiten geben... Kinder sind nicht gleich Kinder. Alleine von Vorschülern hin zu Grundschülern ergeben sich viele verschiedene Ausprägungen was Lesen und Mediennutzung angeht. Außerdem sind Eltern immer irgendwie mit dabei und müssen ebenso mitgedacht werden. Ebenso ist es spannend, wie beispielsweise mit Werbung umgegangen wird oder UX Design und User Research mit Kindern funktioniert. Wir danken Daniela und Daniel sehr, dass sie uns an ihren Erfahrungen teilhaben lassen und hoffen euch damit wieder ein paar spannende Impulse für eure Arbeit mitgeben zu können. Wenn euch die Folge gefallen hat freuen wir uns über Feedback, gerne in eurem Podcatcher oder auf unserer Website unter produktwerker.de.

Am Ende eines Sprints findet das Sprint Review statt, um das Produktinkrement zu inspizieren. Unser Verhalten als Product Owner kann viel dazu beitragen, diesen Termin möglichst wertvoll zu gestalten. Wie einem Product Owner dies gelingen kann, darüber haben Dominique, Oliver und Tim miteinander diskutiert. Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Die Herausforderung als Product Owner lässt einen oft unter dem Druck stehen, alles gleichzeitig zu managen. Wir stellen die brennende Frage: Was mache ich, wenn ich als Product Owner keine Zeit für alles, was ich tun möchte, muss oder sollte, habe? Das Empfinden, keine Zeit zu haben, entsteht oft erst einmal dadurch, dass viel Arbeit liegen bleibt oder man zumindest das Gefühl hat, sich nicht mit den wichtigen Dingen beschäftigen zu können. Man ist getrieben und fühlt sich oft fremdgesteuert. Das Erste, was man dann machen sollte, ist, die eigene Zeit und vor allem den Einsatz der eigenen Zeit zu erheben. Durch das Mittracken der eigenen Zeit und das kritische Analysieren der Ergebnisse (Inspect & Adapt) bieten sich Einblicke, wie man effektiver arbeiten kann. Die wichtigste Methode dabei ist, mehr Fokus herzustellen. Wir diskutieren bewährte Methoden, um den Arbeitsalltag besser zu strukturieren. Von der Anlage eines Backlogs für eigene Aufgaben über die Pomodoro-Technik bis hin zum Einsatz eines Bullet Journals – diese Techniken helfen dabei, den Fokus zu schärfen und produktiver zu sein. Oft ist der Fokus aber gar nicht so schnell herstellbar. Daher haben wir Tipps besprochen, wie man sofort mehr Zeit gewinnen kann. Wir erörtern, wie das Ausschalten von E-Mail-Benachrichtigungen, das Verkürzen von Meetings, das Einfordern von Meeting-Agendas und der Grundsatz „Nach drei E-Mails lieber anrufen“ den Arbeitstag effizienter gestalten können. Zudem betonen wir die Wichtigkeit, feste Fokuszeiten im Kalender zu planen und diese auch einzuhalten. Für die langfristige Perspektive besprechen wir Strategien wie das Setzen von regelmäßigen Terminblockern im eigenen Kalender, das Delegieren von Aufgaben und den Aufbau einer Stakeholder-Community. Diese Ansätze unterstützen nicht nur eine bessere Zeiteinteilung, sondern auch eine effiziente und effektive Zusammenarbeit. Abschließend teilen wir einige Ratschläge, darunter die Kraft des Bullet Journals, um sich jeden Morgen auf die wichtigste Aufgabe zu konzentrieren, bevor digitale Geräte eingeschaltet werden. Außerdem betonen wir die Bedeutung eines nachhaltigen Arbeitstempos (sustainable pace), das langfristigen Erfolg sichert und das Einplanen von Pausen beinhaltet. Am Ende muss man schon fast sagen, dass keine Zeit zu haben eine Lüge ist. Ehrlicherweise heißt es nämlich oft, dass andere Sachen wichtiger sind. Wir würden uns aber freuen, wenn ihr uns schreibt, wie ihr damit umgeht keine Zeit zu haben. Was sind eure Techniken, Strategien und Tipps, die ihr mit andern Teilen könnt? Gerne hier als Kommentar oder auf LinkedIn.

OKR als Methodik um Ziele zu setzen und zu verfolgen ist seit einigen Jahren auch bei uns in Deutschland in aller Munde. Daher, eigentlich schon lange überfällig, wollen wir uns auch mit dem Thema OKR beschäftigen und haben uns eine Expertin eingeladen, die langjährige Zuhörer*innen bereits kennen dürften. An der Seite von Dominique steht Stefanie Götten als Expertin und sie tauschen sich zum Thema mit einem klaren Fokus aus: Was bedeutet die Einführung von OKR für uns in unserer Verantwortung als Product Owner. Stefanie war bereits bei uns im Podcast zu Gast. In der Folge "Dein Freund der Scrum Master" (https://produktwerker.de/dein-freund-der-scrum-master/) war sie schon einmal bei uns zu Gast. Mehr zu Stefanie findet ihr unter https://www.linkedin.com/in/stefanie-g%C3%B6tten/. Welche Erfahrungen hast du rund um die Einführung und Nutzung von OKR gesammelt. Teilst du unsere Meinungen und Erfahrungen oder widersprichts du? Lass uns gerne daran teilhaben. Wir freuen uns, wenn du dein eigenes Verständnis mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilst. Und falls dir der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von dir favorisierten Podcast-App.

Nachdem wir bereits über die agilen Schätzmethoden Magic Estimation und Planning Poker in vorherigen Podcastfolgen gesprochen haben, geht es in dieser Episode um NoEstimates. Dominique und Oliver sprechen darüber, warum sie auch "Nicht-Schätzen" in diese Reihe der Praktiken einordnen. Statt beispielsweise mit der Fibunacci-Reihe zu agieren werden bei NoEstimates in der Regel die Anzahl der Items gezählt und so Prognosen anhand von historischen Daten erstellt. Dominique und Oliver schauen auf die grundsätzlichen Schwierigkeiten, sofern ich als Product Owner mit Schätzungen arbeite. Sie diskutieren die eine oder andere Dysfunktion und die Gefahr, sich zu sehr auf Fristen und Product Delivery zu konzentrieren. Nachdem so die Motivation sich mit NoEstimates zu beschäftigen geklärt ist, geht es im Kern der Folge um die Voraussetzungen, die ich schaffen muss. Und natürlich werfen Oliver und Dominique auch einen kritischen Blick auf Schwierigkeiten, die bei dieser Methode aufkommen kann. Wie immer runden persönliche Tipps aus dem eigenen beruflichen Werdegang diese Episode ab. Dominique empfiehlt folgende YouTube-Videos für einen Einstieg in das Thema: NoEstimates von Vasco Duarte NoEstimates von Allen Holub

Es gibt viel zu tun und die Ideen werden nicht weniger. Schnell stellt sich dann das Gefühl ein, dass das eigene Team einfach zu klein ist und man das gar nicht alles schaffen kann. Es sind halt einfach zu wenige Entwickler im Team. Dominique und Oliver sprechen in dieser Folge darüber, wann der Eindruck zu weniger Entwickler entsteht und welche Lösungsstrategien wir als Product Owner haben. Dazu müssen wir aber zuerst klären: Ist die geringe Teamgröße das Problem oder vielmehr das Symptom für ein anderes Problem. Ausgehend von dieser Frage entstand eine spannende Diskussion über mögliche Gründe, warum wir als Product Owner den Eindruck haben können, dass wir zu wenige Entwickler im Team haben. Das kann zum Beispiel damit zusammenhängen, welche Erwartungshaltungen an Output und/oder Outcome wir (Stakeholder, aber auch wir selbst) stellen. Auch ein sehr volles Product Backlog kann diesen Eindruck direkt erhöhen; der Zufluss ist größer als die Umsetzung. Vielleicht entsteht der Eindruck zu weniger Entwickler aber auch, weil nicht alle notwendigen Fertigkeiten im Team vorhanden sind (z. B. weil die Sprintziele nicht erreicht werden). Nichtsdestotrotz sprechen die beiden über konkrete Lösungsstrategien. Dazu gehören zum Beispiel ein stärkerer Fokus auf Priorisierung, das Outsourcen von Aufgaben oder das stringente Verfolgen der Produktvision und des Product Goals. Durch die Unterstützung durch Scrum Master und Team können verschiedene Lösungen aufgedeckt und umgesetzt werden, die wir vielleicht alleine gar nicht auf dem Schirm gehabt hätten. Wenn ihr mehr zu einzelnen Themen erfahren wollt, haben wir hier noch ein paar passende Folgen für euch: - Sprintziele: https://produktwerker.de/sprint-ziel-als-product-owner/ - Priorisieren von Anforderungen: https://produktwerker.de/priorisieren-von-anforderungen/ - Produktvision: https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/ - Product Goal: https://produktwerker.de/das-product-goal-und-seine-bedeutung-fuer-product-owner/

„Nein sagen ist eine Kernkompetenz eines jeden Product Owners.“ Diese Aussage wird häufig wie ein Mantra unreflektiert wiederholt und an uns Produkt Owner kommuniziert. Oliver und Dominique versuchen in dieser Folge unseres Product Owner Podcast einmal kritisch auf die Aussage zu gucken. Und die beiden nähern sich generell der Herausforderung des Neinsagens. Nachdem Oliver & Dominique sich darüber ausgetauscht haben, ob und warum Nein sagen wichtig ist, teilen die beide Situationen aus ihrer eigenen Historie, in denen das Wort ihnen persönlich schwer gefallen ist. Intensiv reflektieren sie, was man bei einer Ablehnung von Wünschen oder Features beachten sollte und welche Arten von Nein sagen unterschieden werden können. Spannend ist der Gedanke, ob wir als Produkt Owner nicht viel mehr über das JA sagen nachdenken sollten. Dann zu oft Nein zu kommunizieren ist evtl nur ein Umweg zu mehr Fokus und es kann einem auf Dauer auch emotional nicht gut tun. Wie in jeder Folge, schließen Dominique & Oliver mit Tipps und Tricks das Thema ab. Weitere Informationsquellen und Links: Video: Agile Product Ownership in a nutshell - Henrik Kniberg Buch: 50 Arten Nein zu sagen - Schuurman & Vermaak In dieser Folge haben Dominique und Oliver auf folgende andere Episoden verwiesen: Verantwortung als Product Owner übernehmen - mit Andreas Schliep

In dieser Folge spricht Dominique mit Tim und Oli über die Schwierigkeit ein gemeinsam abgestimmtes Verständnis der Produkt Owner Rolle in Deiner Organisation zu entwickeln. Manchmal geht es dabei um die Befugnisse, mal mehr um die Frage der Aufgabenbereiche und zuletzt steht auch häufig die Frage im Raum, welche Skills und Fähigkeiten von der Product Owner Rolle erwartet werden können. Tim und Oli erläutern Ihren Ansatz, im Rahmen eines Workshops entlang des von den beiden entwickelten Modells "POCC" (Product Ownership Context Canvas) die PO-Rolle gemeinsam im situativen Kontext zu betrachten. Dabei erfolgt die Diskussion entlang von acht Dimensionen: - Product - Stakeholder - Process - Structure - Skills - Team - Adaptability - Values Auf dieser Basis kann Ziel-Zustand in Form eines Role Model Canvas entwickelt werden. Um sich dort hinzuentwickeln, wird von den beiden ein iterativer Zyklus mit Hypothesen und Experimenten vorgeschlagen, um den Fokus auf die größten Differenzen zur Ziel-Situation zu legen. Tim und Oli bieten diesen Workshop als Inhouse-Veranstaltung an. Falls Ihr auch als Einzelperson Interesse an einem offenen Training hättet, meldet Euch einfach unverbindlich. Bei entsprechender Nachfrage organisieren die beiden auch einen offenen Workshop. Wie immer freuen wir uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker. Wir sind gespannt zu hören, wie Ihr in Eurer Organisation die Product Owner definiert und wie ihr dabei vorgeht. Im Gespräch wurden die folgende Modelle und Praktiken angesprochen: - POCC: Product Ownership Context Canvas (https://productownership.de) - Drei-Horizonte-Modell von Produkten von Steve Blank, The Lean Definition of the Three Horizons of Innovation; auf Basis von McKinseys “Three Horizons of Innovation” by Baghai, Coley and White - PO Skill Matrix auf Basis von Marty Cagan "Coaching Tools – The Assessment" (https://svpg.com/coaching-tools-the-assessment/) - Role Model Canvas von Christian Botta: http://www.visual-braindump.de/role_model_canvas/

In dieser Folge setzen wir uns intensiv mit den verschiedenen Verantwortungen auseinander, die ein Product Owner während des gesamten Produktlebenszyklus übernimmt. Oft sprechen wir hier nämlich eher allgemein von den Aufgaben eines Product Owners, aber es ist wichtig zu verstehen, dass sich diese im Laufe der Zeit verändern und anpassen. Nach einer Einführung in die verschiedenen Phasen des Produktlebenszyklus werfen wir einen genaueren Blick auf jede einzelne Phase und die Aufgaben von uns als Product Owner. In der Einführungs- und Entwicklungsphase liegt der Fokus zum Beispiel darauf, Marktbedürfnisse zu identifizieren und Ideen sowie Konzepte zu entwickeln. In dieser Phase geht es also darum, schnell zu lernen, indem wir beispielsweise Prototypen entwickeln und Produktideen testen. Gleichzeitig wird die Wirtschaftlichkeit und die langfristige Bereitstellung des Produkts hinterfragt. Die Wachstumsphase ist geprägt von der Zusammenarbeit mit Vertrieb und Marketing, um die Kluft zu überwinden, die vor der Nutzung des Produkts durch die frühe Mehrheit der potenziellen Kunden steht (siehe dazu auch das Buch "Croissing the chams" von Geoffrey Moore). Hier ist es wichtig, die Preisstrategie zu entwickeln oder zu überprüfen und die Produktstrategie entsprechend anzupassen. In der Reife- und Sättigungsphase liegt der Schwerpunkt darauf, Marktanteile zu maximieren und die Produktqualität kontinuierlich zu verbessern. Neue Marktsegmente können gegebenenfalls erschlossen werden, indem zusätzliche Produktfunktionen (weiter-)entwickelt werden. Die Degenerationsphase kennzeichnet das Ende des Produktlebenszyklus. In dieser Phase sollten Product Owner nach Möglichkeiten suchen, das Produkt oder die Technologie umzustellen, um den Nutzen des Produkts sinnvoll zu verlängern. Es wird auch über die Einstellung des Produkts nachgedacht, um die Kunden nicht eifnach von heut auf morgen im Stich zu lassen. Am Ende bleibt noch, dass sich die verschiedenen Phasen für uns als Product Owner unterschiedlich anfühlen. Nicht in jeder Phase fühlt man sich gleich wohl. Daher empfehlen wir jedem, sich dieser Veränderungen bewusst zu sein und so zu erkennen, in welcher Phase man den größten Mehrwert in seiner Verantwortung schaffen kann. Genauso wie sich vielleicht die Zusammensetzung eines Teams sich je nach Phase des Lebenszyklus anpasst geht auch an uns die Veränderung nicht spurlos vorbei. Welche Erfahrungen habt ihr während der verschiedenen Phasen gesammelt? Gibt es Tipps, die ihr gerne anderen mitteilen wollt? Wir freuen uns immer über eure Geschichten! Teilt sie gerne hier in den Kommentaren oder auf unserer LinkedIn-Seite (https://www.linkedin.com/company/produktwerker/).

Kerstin Neumann gibt einen spannenden Einblick und Erfahrungsbericht in ihr Verständnis von Kundenzentrierung. Sie berichtet, wie sie selbst in ihrem Umfeld Impulse gibt und damit das Thema "Product" und "Sicht des Nutzers" nach vorne treibt. Lesetipps von Kerstin zum Thema Kundenzentrierung: - Annie Dunham: 12 Things Every Product Manager Should Do in Their First 30 Days at a New Company - Andreas Diehl: Customer Centricity – Zehn Methoden für eine höhere Kundenzentrierung - Petra Wille: Gefährliche Annahmen – wie ihr das Risiko minimiert, falsch zu liegen - Whitepaper: CX-MANAGEMENT ERFOLGREICH UMSETZEN. Praxistipps zur Überwindung von Silogrenzen und zur nachhaltigen Implementierung - Matt Watkinson: The Ten Principles Behind Great Customer Experiences Im Gespräch verweist Kerstin zudem auf unsere Podcast-Folge zum Storytelling: Mit Storytelling andere von deinen Produktideen überzeugen Falls ihr direkt mit Kerstin in Kontakt kommen oder ihr folgen wollt: - https://www.linkedin.com/in/kerstin-neumann-abb01312/ - https://www.xing.com/profile/Kerstin_Neumann31/ Wenn euch die Folge gefällt freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

In dieser Folge dreht sich alles um das Arbeiten als Product Owner im Home Office. Seit der Corona-Pandemie ist Home Office für viele POs zur Normalität geworden, was sowohl Chancen als auch Herausforderungen mit sich bringt. Oliver und Dominique diskutieren, wie sich die Verantwortung eines Product Owners durch die veränderten Arbeitsbedingungen verschoben hat und welche Auswirkungen dies auf die tägliche Arbeit hat. Eine der größten Veränderungen betrifft die Kommunikation besonders mit dem eigenen Team. Obwohl die virtuelle Kommunikation via Slack oder Videokonferenzen viele spannende Möglichkeiten bietet, gibt es Aspekte, die im Home Office schwerer umsetzbar sind. Spontane Gespräche oder das schnelle „Zurufen“ einer Frage im Teamraum vor Ort fehlen, was den Austausch im Team verlangsamen kann. Product Owner müssen darüber hinaus darauf achten, dass trotz Remote-Arbeit keine wichtigen Informationen verloren gehen. Andererseits bietet das Home Office aber auch einige Vorteile: Die Flexibilität ermöglicht es, sich besser auf bestimmte Aufgaben zu fokussieren und tiefere, ungestörte Arbeit zu leisten. Eine weitere kommunikative Herausforderung ist es, die Beziehung zu den Stakeholdern zu pflegen. Im Büro gibt es diverse Möglichkeit sich informell auszutauschen – etwa an der Kaffeemaschine – während im Home Office solche Gelegenheiten fehlen. Hier sind kreative Ansätze gefragt, um den Kontakt nicht nur formell, sondern auch auf einer persönlichen Ebene aufrechtzuerhalten. Ein „Stakeholder-Daily“ könnte beispielsweise helfen, die Entscheidungsprozesse zu beschleunigen, indem regelmäßige kurze Meetings stattfinden. Doch Arbeiten im Home Office bietet nicht nur Hürden, sondern auch einige neue Chancen. Product Owner können durch die zunehmende Flexibilität Jobmöglichkeiten im gesamten deutschsprachigen Raum, oder sogar darüber hinaus, wahrnehmen. Zudem verbessern digitale Tools wie Miro oder Confluence die Zusammenarbeit und die Dokumentation. Das Arbeiten im virtuellen Raum ermöglicht es, transparenter zu agieren und Prozesse effizienter zu gestalten. Ein großer Vorteil des Home Offices ist auch die Möglichkeit, den eigenen Arbeitsrhythmus flexibler zu gestalten. Product Owner können tiefer in Aufgaben eintauchen, ohne von äußeren Faktoren im Büro abgelenkt zu werden. Auf eines sollte man aber achten: Die klare Trennung zwischen Arbeit und Privatleben fällt oft schwer, besonders wenn man nicht in einem separaten Arbeitszimmer, sondern vielleicht am Küchentisch arbeitet. Insgesamt gibt diese Folge praktische Tipps, wie du die Herausforderungen des Home Offices meistern kannst. Als PO solltest du deinen Arbeitsalltag aktiv gestalten und nicht einfach nur den Umständen ausgeliefert sein.

Eine Organisation beginnt agil zu arbeiten und benötigt dann Product Owner:innen. Oft werden ehemalige Projektleiter oder Teamleiter als Product Owner:innen bestellt. Dass sich durch diese Veränderung bestimmte Herausforderungen ergeben, liegt nahe. Dies zeigt sich auch in eurem Wunsch, sich einmal über dieses Thema zu unterhalten. Daher sprechen in dieser Folge Dominique und Tim über den Übergang von der alten Verantwortung zur neuen. Im Gespräch wird schnell deutlich, dass es einige Verhaltensweisen gibt, die Projektleiter:innen durchaus hilfreich sein können, aber auch andere, die Schwierigkeiten verursachen. Projektleiter:innen sind oft sehr auf die Auslieferung fokussiert, wobei der Output über dem Outcome steht. Auch die direkte Zuweisung von Aufgaben an Personen mag Projektleiter:innen nützlich sein, aber im agilen Kontext als Product Owner wird dieses Verhalten nicht gut funktionieren. Ähnliches gilt auch für Teamleiter:innen. Die Aufgaben der Personalentwicklung und der Personalbeschaffung fallen schlichtweg weg, sobald man die Verantwortung als Product Owner übernimmt. Das macht den Wandel nicht so einfach. Dabei kann vor allem Transparenz helfen. Damit ist nicht nur die Zusammenarbeit mit dem Team und den Stakeholdern gemeint, sondern auch die persönliche Reflexion. Ehemalige Rollenmuster müssen bewusst umgedeutet werden. Feedbackgeber wie das Team, insbesondere im Rahmen der Retrospektive, und Menschen in der Verantwortung als Scrum Master können dabei hilfreich sein. Diese spielen eine besonders wichtige Rolle, weshalb eine agile Transformation ohne Scrum Master, besonders für Personen aus den vorherigen Rollen als Projektleiter oder Teamleiter, schwierig ist. Dennoch ist eine solche Veränderung gut möglich. Im Gespräch wurde auf folgende Folgen verwiesen: - POEM – Product Ownership Evolution (https://produktwerker.de/poem-product-ownership-evolution-model/) - Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern (https://produktwerker.de/sei-dein-eigenes-produkt/) Außerdem erwähnten die beiden noch folgende Quellen: - Das Role Model Canvas (https://www.visual-braindump.de/role_model_canvas/) - Blogpost von Roman Pichler "Be a Balanced Product Leader not a Feature Broker or Product Dictator" (https://www.romanpichler.com/blog/be-a-balanced-product-leader-not-a-feature-broker-or-product-dictator/) - Blogpost von Roman Pichler "Six Types of “Product” Owners” (https://www.romanpichler.com/blog/six-types-of-product-owners/) Wenn ihr selbst aus der Projekt- oder Teamleitung heraus in die Verantwortung als Product Owner gekommen seid freuen wir uns über eure Erfahrungen. Teilt sie gerne im Blogpost zur Folge als Kommentar oder auf unserer LinkedIn-Companyseite als Kommentar. Diese Folge ist übrigens auch unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!

In dieser Folge sprach Dominique mit Hendrik Neumann über seinen Werdegang und seine Erfahrungen aus der Verantwortung als Teamleiter Produktmanagement bei Chefkoch. Hendrik erzählt uns, warum ihn die Verantwortung als Product Owner gereizt hat und wie er schließlich Teamleiter wurde. Er führt uns durch die Herausforderungen, die diese Rolle mit sich brachten und wie er seine Aufgabe als Führungskraft ausgelebt hat. Natürlich schließt er mit ein paar Tipps, die er anderen mitgeben möchte, die sich in eine ähnliche Richtung entwickeln. Mehr zu Hendrik findet ihr unter https://www.xing.com/profile/Hendrik_Neumann18/cv.

In dieser Folge dreht sich alles um ein Thema, das viele Product Owner in der Praxis betrifft: Mehrere Backlogs. Obwohl die Regel im agilen Kontext „Ein Produkt, ein Product Backlog“ lautet, zeigt die Realität oft andere Szenarien. Dominique und Tim erklären wie man als Product Owner damit umgehen kann, wenn man gezwungen ist, mehr als ein Backlog zu verwalten. Bei mehreren Backlogs gibt es einige Herausforderungen. Oft entstehen sie, wenn ein Team an mehreren Produkten oder Services arbeitet, was die Organisation von Prioritäten erschwert. Ein weiteres häufiges Szenario ist die Aufteilung von Aufgaben nach Prozessschritten, etwa ein separates UX-Backlog oder ein Bug-Backlog. Diese unterschiedlichen Quellen und Aufteilungen führen leicht zu einem Verlust der Übersicht. Was ist wirklich wichtig, und welches Backlog hat Vorrang? Product Owner stehen dann oft vor der Frage, wie sie die Transparenz wahren und gleichzeitig strategisch arbeiten können, ohne sich in operativen Details zu verlieren. Die Lösung liegt häufig in einer besseren Organisation und klaren Strukturen. Statt mehrere Backlogs isoliert zu pflegen, empfiehlt es sich, alle Aufgaben in einem System wie Jira zu bündeln und mit Labels oder Filtern zu arbeiten. Dies erleichtert die Priorisierung und schafft eine „Single Source of Truth“ für alle Beteiligten. Zudem kann es sinnvoll sein, Ideen oder potenzielle Features zunächst außerhalb des eigentlichen Product Backlogs zu sammeln. Diese sollten jedoch nicht als zusätzliche Backlogs betrachtet werden, sondern als unterstützende Tools im Discovery-Prozess. Sobald eine Idee reif genug ist, gehört sie ins Product Backlog, um die Arbeit des Teams zu strukturieren und zu priorisieren. Ein weiterer Ansatz ist die Visualisierung der Arbeitsprozesse. Indem die Reise von Ideen und Anforderungen durch den Produktentwicklungsprozess sichtbar gemacht wird, können Teams und Stakeholder besser verstehen, wo welche Prioritäten liegen und welche Schritte nötig sind, um Ziele zu erreichen. Gleichzeitig gilt: Mut zur Einfachheit. Nicht jede Idee oder jedes Feedback muss umgesetzt werden. Wer mutig genug ist, Überflüssiges zu eliminieren, schafft Raum für das Wesentliche. Am Ende gilt vor allem: Für Product Owner, die mit mehreren Produkten und Backlogs arbeiten, ist eine klare Priorisierung entscheidend. Wenn spontane Aufgaben auftreten, hilft eine vorab festgelegte Rangordnung, Konflikte zu vermeiden und die Effizienz zu steigern. Weitere Tipps bekommt ihr in Folgen zu ähnlichen Themen: - Product Backlog organisieren (https://produktwerker.de/product-backlog-organisieren/) - Features wegwerfen - was braucht es dafür außer Mut? (https://produktwerker.de/features-wegwerfen/) - Das Product Goal und seine Bedeutung für Product Owner (https://produktwerker.de/das-product-goal-und-seine-bedeutung-fuer-product-owner/) - LeSS aus Product Owner Sicht und aktuelle Skalierungstrends (https://produktwerker.de/less-als-po/) - Product Principles (https://produktwerker.de/product-principles/)

Was ist ein Produkt? Und ist eine Dienstleistung ein Produkt? Beides sind oft gehörte Fragen. Dominique und Tim greifen diese Fragen auf und diskutieren in dieser Episode rund um den Produktbegriff. Zunächst gucken sie sich gängige Definitionen an. Ein übliches Produktverständnis umfasst auch Services bzw. Dienstleistungen. Oft fällt es Organisationen aber noch schwer, die Frage zu klären "Was ist ein Produkt" und wie schneiden wir dementsprechend die jeweiligen Teams rund um die Produkte. Aber was ist, wenn ich als Product Owner nach diesen Definitionen gar kein "Produkt" habe? Vielleicht verantwortet man also eine Komponente, ein Feature oder eine Plattform. Kann man dann dennoch produkthaft vorgehen? Und was ist mit internen Produkten? Sind das eher Anwendungen oder kann man sie auch als Produkt bezeichnen? In diesem Zusammenhang diskutieren die beiden auch kurz, ob und wann eine API ein Produkt ist und wann nicht. Am Rande sprechen die beiden auch nochmal über die Abgrenzung von Nutzer und Kunde. Auch hier werden in der Praxis die Begriffe oft etwas zu nachlässig verwandt. Empfohlene Quellen zur Frage "Was ist ein Produkt": - Marty Cagan (svpg): What is a Product? - Definition "Was ist ein Produkt" aus dem Scrum Guide - Roman Pichler "Six Types of a "Product" Owner" In dieser Episode empfohlene Podcast Folgen: - Vom Projektleiter oder Teamleiter zum Product Owner - Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis - Wardley Mapping - Produktstrategie wie ein Schachspiel - POEM - Product Ownership Evolution Model - Evidence Based Management - eine empirische Suche nach Wert Kennst du diese Fragestellung "Was ist Produkt"? Wird die Diskussion bei euch auch im Rahmen des Produktschnitts geführt? Wie definiert ihr eure Produkte? Und wie geht ihr mit Dienstleistungen bzw. Services um? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Wie blickt ein Vorstand auf die Verantwortlichkeit eines Product Owners? Wie kann Product Ownern eine gute Zusammenarbeit mit dem Vorstand gelingen? Diese und weitere Fragen diskutieren Silke Kanes, Vorständin Produkte bei der Scopevisio AG, und Tim in dieser Podcast-Folge. Die Ansichten von Silke bringen eine weitere, äusserst bereichernde Perspektive auf die Aufgaben der Product Owner Rolle und agiler Produktmanager. Zunächst mal geht es um die Erwartungen des Vorstands an die Rolle von Produktverantwortlichen. Dabei gibt es durchaus auch die Aufgabe, dem Vorstand die PO-Rolle zu erklären bzw. ein Verständnis für sie zu entwickeln. Silke Kanes hat selber durch ihre lange Karriere in Produktpositionen (aber auch in einigen anderen Bereichen) viel in der Zusammenarbeit mit Vorständen gelernt und zugleich auch Product Owner in ihrem Umfeld entwickelt. Daher hat sie auch interessante Tipps, auf welche Art ein Product Owner mit den fraglichen Themen bis zum Vorstand durchdringen kann. Tim und Silke besprechen weiterhin das Thema, wie man am klug mit dem Vorstand kommuniziert? Letztlich fällt die Herausforderung zur Zusammenarbeit mit dem Vorstand in den Bereich des Stakeholder Managements. Hier müssen Product Owner und Produktmanager einfach fit sein und viele Erfahrungen sammeln, um mit ihren Anliegen durchzudringen. Weitere Podcast-Folgen, auf die Silke und Tim im Laufe des Gesprächs zu sprechen kommen: - Stakeholder Community - Mit Storytelling andere von deinen Produktideen überzeugen - Data-Fluent Product Manager Silke Kanes freut sich über den Kontakt zu euch. Für weitere Fragen oder Anliegen erreicht ihr sie am besten auf LinkedIn. Folgt ihr dort auch gerne. Ansonsten bietet ihre persönliche Homepage (silkekanes.com) mit ihrem Blog auch einen schönen Blick "hinter die Kulissen" ihres spannenden Werdegangs. Welche Erfahrungen hast du in der Zusammenarbeit zwischen Vorstand und Product Owner gemacht? Uns interessiert hier sowohl die Sichtweise der POs als auch von Führungskräften. Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Episode unseres Product Owner Podcast ist erneut Daniel Hommel zu Gast. Daniel spricht mit Oliver über das Thema "Coaching Skills als Product Owner entwickeln". Nachdem die erste Folge der beiden schwerpunktmäßig das Coachen von Product Ownern diskutierte, reflektieren sie dieses mal, ob Coaching Skills und eine Coaching Haltung hilft, den Job besser erledigen zu können. Wir möchten vorausschicken, dass es sich bei Coaching nicht um die Basis Skills als Product Owner handelt. Es gibt definitiv andere Fähigkeiten, die ich zuerst lernen und verbessern sollte. Aber Coaching kann etwas sein, was meine Skill sinnvoll ergänzt. Denn Coaching dient dazu, mehr Klarheit zu erhalten und neue Perspektiven zu entdecken - eine Herausforderung vor der jede Product Owner häufig genug steht. Daniel und Oliver fokussieren sich auf drei Bereiche: Zuhören, auch über das gesprochene Wort hinaus - Spiegeln - offene Fragen stellen. Dabei behandeln sie auch diverse Fragentechniken, wie z.B. die Wunderfrage, Skalenfragen oder zirkuläre Fragen aus dem systemischen Coaching. Ein weiteres Thema ist Clean Language und NLP. Alles in allem bietet das Gespräch viele Impulse, um sich als Product Owner dem Thema Coaching zu nähren und sich dennoch von dem Verantwortungsbereich eines Scrum Master klar abzugrenzen. Alle in der Folge erwähnten Literaturempfehlungen findest du auf [unser Webseite](https://produktwerker.de/coaching-skills/)

Der heutige Arbeitsmarkt zeigt einen klaren Wandel. Teilzeitmodelle werden immer beliebter. Daher beschäftigen wir uns in dieser Folge mit dem Konzept als Product Owner in Teilzeit. Wir sprechen nicht nur über die Gründe sondern besonders über Vor- und Nachteile und insbesondere über die Herausforderungen. Product Owner in Teilzeit müssen sich stark fokussieren. Die Zeit ist begrenzt, mehr noch als bei einer Vollzeitstelle. Und oft gibt es für die Teilzeitstelle auch noch einen Grund, der eine absolute Flexibilität erschwert. Product Owner müssen daher sicherstellen, dass sie die richtigen Aktivitäten durchführen. Wann findet man die Zeit mit den Stakeholdern und auf welcher Flughöhe befindet man sich hauptsächlich? Hier helfen bestimmte Techniken wie beispielsweise das Product Ownership Evolution Modell oder Delegation Poker. Wichtig ist aber in erster Linie, dass Product Owner vor lauter operativer Arbeit nicht vergessen auch einen großen Teil ihrer Zeit auf strategische Aktivitäten zu legen. Da die Zeit aber so beschränkt ist können (und manchmal müssen) Aufgaben an das Team abgegeben werden. Beispielsweise sollte das Team in User Tests eingebunden oder mit Supportern wie UX-Dienstleistern zusammengearbeitet werden. Daher kann ein Teilzeitmodell sogar eine Chance sein eine PO-Rolle zu etablieren, die sich auf das Wichtigste konzentriert: Den erzeugten Wert zu maximieren. Wir freuen uns über euer Feedback, besonders, wenn ihr auch Erfahrungen als PO in irgendeiner Form eines Teilzeitmodells habt. Gern auf LinkedIn oder unserem Blog.

In dieser Folge der Produktwerker geht es darum, wie Product Roadmaps in der täglichen Arbeit eingesetzt werden können. Zu Beginn eines Jahres investieren viele Product Owner und Produktmanager viel Energie in die Erstellung einer Product Roadmap. Doch was passiert danach? Die Roadmap, die oft als Ergebnis intensiver Diskussionen und strategischer Planung entsteht, ist kein statisches Dokument, sondern ein dynamisches Werkzeug, das den Alltag von Produktteams prägen sollte. Eine Product Roadmap gibt die Richtung vor. Sie bildet die Brücke zwischen der Produktvision und den operativen Aufgaben im Backlog. Damit wird sie zur Operationalisierung der Produktstrategie und hilft dabei, Entscheidungen fundierter zu treffen. Gerade in Gesprächen mit Stakeholdern bietet sie eine klare Orientierung, welche Outcomes und Ziele im Fokus stehen. Anstatt über einzelne Features zu diskutieren, lenkt die Roadmap die Aufmerksamkeit auf die übergeordneten Ziele und erlaubt es, neue Anforderungen kritisch zu hinterfragen. Im Scrum-Kontext erweist sich die Product Roadmap als besonders nützlich. Ob im Sprint Planning, bei der Formulierung eines Sprintziels oder im Sprint Review – die Roadmap sorgt für eine klare Verbindung zwischen Vision, Strategie und operativer Umsetzung. Sie zeigt auf, wie das aktuelle Sprintziel auf die langfristigen Produktziele einzahlt. Darüber hinaus unterstützt sie Product Owner, den Fokus zu behalten, etwa in Diskussionen über Prioritäten oder neue Feature-Wünsche. Auch im Kontext von Product Discovery bietet die Roadmap Orientierung. Unsicherheiten, die bei der Entwicklung auftreten, können systematisch angegangen werden. Sie ermöglicht es, Hypothesen oder Annahmen gezielt zu priorisieren und ihre Relevanz für das Gesamtbild zu bewerten. Dabei wird der iterative Charakter der Roadmap deutlich: Neue Erkenntnisse führen zu Anpassungen, um sicherzustellen, dass das Produkt den Anforderungen des Marktes gerecht wird. Product Roadmaps in der täglichen Arbeit einzusetzen erfordert Engagement und Disziplin. Sie ist mehr als nur ein Dokument – sie ist ein zentraler Bestandteil der Produktarbeit und unterstützt dabei, langfristige Ziele mit den täglichen Aufgaben zu verbinden. Indem sie regelmäßig reflektiert und angepasst wird, trägt sie dazu bei, die Produktentwicklung effektiv und zielgerichtet zu gestalten.

Wie sieht der Arbeitsmarkt für Product People derzeit aus? Was kann ich aus Bewerbungssicht tun? Auf was können Unternehmen achten, um bessere KandidatInnen zu finden? Wir haben dazu den auf Product Owner spezialisierten Headhunter Denny Meier sowie Lars Haßler befragt. Letzterer hat derzeit durch seine aktive Suche nach einer Product Leader Stelle einen aktuellen Eindruck von der Marktsituation. Zunächst gibt uns Denny nochmals eine Einschätzung zur Gehaltssituation verschiedener Level und Branchen und gibt seine Einschätzung zum Problem Gender-Pay-Gap. Aktuelle Zahlen zu offenen Stellen und der Entwicklung der letzten Monate runden das Bild ab. Ein weiterer Schwerpunkt sind Tipps, auf die BewerberInnen bei der Suche achten sollten. Wenn ihr Kontakt zum Headhunter Denny Meier von Adaptive aufnehmen möchtet, kontaktiert ihn am besten via LinkedIn. Denny freut sich auch über Anfragen von Product Ownern, die aktuell nicht nach einem neuen Job suchen. Auch Lars Haßler freut sich über Eure Kontaktaufnahme via LinkedIn.

Mit der "Jobs-to-Be-Done"-Theorie (JTBD) lassen sich unterschiedliche Dimensionen von Kundenbedürfnissen wunderbar erklären. So kann man schön unterscheiden, welche Bedürfnisse das Produkt oder ein Service bedient. Oder, um es im Wording der Jobs-to-Be-Done Theorie zu sagen: für die Erledigung welchen Jobs dieses Produkt vom Nutzer beauftragt wird. Unser Gast Peter Rochel ist zusammen mit Eckhart Böhme sicherlich das führende Gespann, das es im deutschsprachigen Raum rund um die JTBD-Theorie gibt. Aber die beiden halten sich nicht mit der Theorie auf, sondern nutzen sie in ihrer praktischen Innovationsarbeit und Produktentwicklung. Und genau darum geht diese Podcast-Folge. Zunächst erklären wir natürlich erst noch mal Herkunft, Aufbau und Idee der Jobs-to-Be-Done Theorie. Aber dann geht es vor allem um die Anwendungen in den sogenannten JTBD-Interviews. Beispiele solcher Interviews könnt ihr im Podcast "Innovate+Upgrade" von Peter Rochel auch mal komplett anhören - echt spannend. Und im letzten Teil stellt Peter auch noch dass von ihm und Eckhart entwickelte spannende "Wheel of Progress®" vor. Das ganze ist ein super hilfreicher Canvas, um die JTBD-Interviews sehr strukturiert dokumentieren zu können. So macht man z.B. alle Kräfte, den jeweiligen Kontext und den dem Produkt (oder Service) zugeschriebenen erstrebten Fortschritt explizit. Wertvolle Quellen rund um "Jobs-to-Be-Done": - JTBD.de – die deutschsprachige Community für die Jobs to Be Done (JTBD)-Theorie, inkl. einer guten Erklärung der JTBD-Theorie - Clayton M. Christensen: Besser als der Zufall: "Jobs to Be Done" - die Strategie für erfolgreiche Innovation (Original: Competing Against Luck) - Das Original-Video zum bekannten "Milkshake"-Beispiel von Clayton M. Christensen: https://youtu.be/sfGtw2C95Ms - Shot: Was ist ein JTBD? (Kurzerklärung): https://oberwasser-consulting.de/der-job-to-be-done-jtbd/ - dort gibt es auch noch andere Shots - Webinar von Peter Rochel bei Mr. Kundenbrille: https://oberwasser-consulting.de/praxistalk-mit-mr-kundenbrille/ - Kompakte Beispiele zu JTBD-Kundeninterviews im Podcast-Format: https://oberwasser-consulting.de/tag/kundeninterviews/ Wenn ihr Peters Aktivitäten weiter verfolgen, direkten Kontakt zu Peter Rochel aufnehmen wollt oder er euch in euren Innovationsherausforderungen helfen kann, findet ihn im Web unter https://oberwasser-consulting.de/ sowie bei Facebook, Twitter, LinkedIn, Xing oder per Mail: p.rochel@oberwasser-consulting.de Kanntet ihr "Jobs-to-Be-Done" schon oder und nutzt ihr sogar schon JTBD-Interviews? Oder wie kommt ihr den wahren Kundenbedürfnissen ansonsten auf die Schliche? Lasst uns gerne an euren Erfahrungen oder auch eurer Kritik teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Das Product Backlog ist die eine einzige Stelle, an der wir Arbeit organisieren, die für unser Produkt getan werden soll. Klassischerweise ist das Product Backlog eine priorisierte Liste. Aber muss es das sein? Wichtig ist doch vor allem die Priorisierung, oder? In dieser Folge unterhalten sich Oliver und Dominique über weitere Alternativen, wenn es um eine gute Organisation des Product Backlogs geht. Alternativen lassen sich schnell finden. Einige Methoden sind recht bekannt, wie beispielsweise die User Story Map. Hier bewegen wir uns entlang der User Journey und organisieren das Product Backlog in zwei Dimensionen. Aber auch andere Methoden wie Classes of Work können hilfreiche Übersicht geben. Hierbei wird die Arbeit in verschiedene Arten aufgeteilt und seperat voneinander priorisiert. Und dann gibt es noch Alternativen aus anderen Bereichen wie beispielsweise ein Funnel Backlog, bei dem wir uns mehr darauf konzentrieren, welche Arbeiten in welchen Funnelbereichen gerade notwendig sind. Und dann sind da noch Impact Maps, Vorgangsknotennetzpläne und einige mehr. Am Ende haben die alternativen Organisationsformen alle ihre Vor- und Nachteile. in unserer Arbeit als Product Owner, Product Manager und Product Leader müssen wir daher abwägen, welche Art sich gerade mehr als andere anbietet. Mal kann das Aufzeigen von Abhängigkeiten wichtiger sein, mal die absolute Serrialisierung von Arbeit. Oft hängt es am Ende auch an der Zusammenarbeit mit der eigenen Stakeholdercommunity.

Muss ich als Product Owner den Erfolg von User Stories messen? Reicht es nicht aus, wenn die Story "done" ist? Der Scrum Guide sagt jedenfalls nichts explizites dazu. Oliver und Tim klären daher zunächst mal die Frage, aus welcher Idee von Scrum man man diesen Bedarf ableiten könnte. Sie beziehen sich demnach auf das "Überprüfen" (engl.: inspect) als einer der drei Säulen der Scrum Theorie. Demnach soll man neben den Scrum Artefakten auch den Fortschritt in Richtung der vereinbarten Ziele häufig und sorgfältig überprüfen. Nun sind User Stories wahrlich keine Artefakte des Scrum Frameworks und so könnte man sagen, dass die Akzeptanzkriterien einer Story in Verbindung mit der Definition of Done gut genug sind, um den Erfolg einer User Story zu bewerten. Darüber hinaus, begutachten wir ja auch im Sprint Review das Product Increment. Kann dies vielleicht als Erfolgsmessung herhalten? In der Reflektion sehen Tim und Oliver hier das Problem, dass ich am Ende eines Sprints in der Regel noch nicht genau beziffern kann, ob z.B. ein erfolgreich gebautes und evtl. sogar bereits ausgeliefertes Feature wirklich schon etwas bewirkt und damit Wert liefert. Also müssen wir uns fragen: was heißt denn hier überhaupt "Erfolg" von User Stories messen? Schnell kommt man auf eine Outcome-Betrachtung und es wird deutlich, dass ich einige zeitverzögerte Wirkungen von ausgelieferten Features beachten muss. Wir müssen also sogenannte "Lagging Indicators" begutachten und messen. Aber wie kann das in Scrum klappen und wie kann ich es vor allem organisieren, um den Erfolg von User Stories messen zu können, wenn denn der Outcome oft erst zeitverzögert sichtbar wird? Hierzu stellen Oliver und Tim einige Ideen vor und geben Anregungen für die Umsetzung. Im Lauf des Gesprächs wird an verschiedenen Stellen immer mal wieder Bezug auf andere Folgen unseres Podcasts genommen. Wenn Du also die folgenden, zum Teil älteren, Episoden noch nicht kennst bzw. dir die Themen in der Tiefe noch nicht so vertraut sind, könnte es sich lohnen, sie dir jetzt mal anzuhören. - Erfolgreich mit User Stories arbeiten - Akzeptanzkriterien richtig einsetzen - Das Product Goal und seine Bedeutung für Product Owner - Agile Product Roadmaps - Das Sprint-Ziel als Product Owner nutzen - Als Product Owner im Sprint Review Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

In dieser Folge des Produktwerker Podcasts sprechen Oliver und Tim mit Roman Pichler über sein neues Buch "How to Lead in Product Management: Practices to Align Stakeholders, Guide Development Teams, and Create Value Together". Uns interessierte welche Motivation zu dem Buch führte und was Product Owner neben den methodischen Skills noch brauchen, um in ihrer Rolle erfolgreich zu sein. Wir sind gespannt zu hören, welche Herausforderungen Ihr als Product Owner im Kontext Führung seht und welche Empfehlung Ihr anderen geben könnt. Wie immer freuen wir uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Eine Folge zum Impact Mapping war dringend überfällig! Über diese sehr starke Praktik im Produktmanagement spricht Tim Klein daher mit Büşra Coşkuner aus Zürich. Sie ist Product Management Coach und eine der absoluten Expertinnen zum Impact Mapping im deutschsprachigen Raum. Tim liebt ja bekanntlich eh quasi alle Mapping Techniken, weil sie durch die Visualisierung für so viel mehr Klarheit sorgen und Entscheidungen sowie Zusammenhänge explizit machen. Daher setzt er diese Methode auch schon viele Jahre selber ein. Büşra hat den Ansatz aber nochmal weiterentwickelt (Adjusted Impact Map) und ist sehr erfahren in ihrer Anwendung mit Produktteams. Die Praktik wurde insbesondere durch Gojko Adzic und sein (sehr dünnes) Buch "Impact Mapping: Making a big impact with software products and projects" bekannt. Viele weitere Erklärungen und Ressourcen findet ihr auf impactmapping.org. Impact Mapping klärt insbesondere die Frage, was wir versuchen bzw. umsetzen könnten, damit bestimmte Akteure ihr Verhalten in einer Art und Weise verändern, die eine (positive) Wirkung auf ein von uns verfolgtes Businessziel haben könnte. Gemeinsam sucht man also Zusammenhänge von "Why" - "Who" - "How" und "What" und visualisiert sie in einer Art Mindmap. Während die ursprüngliche Idee in dieser Reihenfolge erfolgt, schlägt Büşra Coşkuner vor, auch mal eine "Reverse Impact Map" auszuprobieren. Das Vorgehen erklärt sie in ihrem entsprechenden Blog-Artikel (busra.co/post/the-reverse-impact-map-and-mindset-shift-voodoo). Ein weiterer guter passender Artikel von ihr beleuchtet den Outcome-Fokus sowie den Zusammenhang zu OKR (Outcome-focus with Impact Mapping: busra.co/post/mini-series-outcome-focus-with-impact-mapping/). Es lohnt sich übrigens sehr, ihrem Blog zu folgen! Wie im Gespräch von Büşra bereits angeboten, hat sie uns dankenswerter Weise auch ihre zwei Templates aus den Übungen ihres Trainings zur Verfügung gestellt: Template 1: Wenn man z.B. schon weiß, dass man etwa bestimmtes umsetzen möchte, wäre ein Aufbau für einen Mini-Pitch: In order to achieve [IMPACT], we want to help/make [ACTOR] to/with [OUTCOME] with/by [OUTPUT]. Our riskiest assumptions are [ASSUMPTION 1], [ASSUMPTION 2], [ASSUMPTION 3]. …und falls dieser Detail-Level erwünscht ist: We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], …[EXPERIMENT n] Template 2: Wenn wir es noch nicht wissen, weil da ganz fette Annahmen dahinterstecken und wir mehr Daten brauchen: We believe that by [doing this output] --> Solution for [these people] --> Actor we'll achieve [This Outcome] --> Impact which we believe will lead to [this business result] --> Goal We'll know if we are right, when we achieve [quant. or qual. indicators or results]. We'll test our assumption with these experiments: [EXPERIMENT 1], [EXPERIMENT 2], … [EXPERIMENT n] Weitere Podcast-Folgen und Quellen, auf die Tim und Büşra im Laufe des Gesprächs hinweisen: - Data-Fluent Product Manager (mit Büşra) - Outcome Goals & Product Discovery (mit Tim Herbig) - Evidence Based Management - eine empirische Suche nach Wert (mit Boris Steiner und Glenn Lamming) - Opportunity Solution Trees von Teresa Torres (producttalk.org/opportunity-solution-tree/) Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr LinkedIn Profil (linkedin.com/in/busra-coskuner/) mit ihr verbinden. Kanntest du Impact Mapping bereits vorher? Hast du eventuell selbst schon mal an einer solchen Mapping Session in Präsenz oder Remote teilgenommen? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Die ersten Wochen in einer neuen Rolle als Product Owner können überwältigend sein. Als neuer PO steht man vor vielen Herausforderungen, gleichzeitig bietet sich aber unserer Meinung nach auch eine einmalige Chance: den Rahmen für die Produktentwicklung so zu setzen, dass man langfristig Spaß an der Arbeit hat und effektiv agieren kann. In dieser Folge diskutieren Dominique und Oliver vier Schritte, die sich als Orientierungshilfe für die ersten Wochen eignen: 1. KONTEXT VERSTEHEN UND BEZIEHUNGEN AUFBAUEN Bevor man sich in operative Aufgaben stürzt, sollte der Fokus darauf liegen, den Kontext des Produkts und der Organisation zu erfassen. Es geht zu Beginn vor allem darum, relevante Stakeholder kennenzulernen, die Produktvision zu verstehen und die Erwartungen der Beteiligten zu klären. Diese Phase legt das Fundament für alle weiteren Schritte und hilft dabei, spätere Entscheidungen fundiert treffen zu können. 2. RAHMEN FÜR DIE ENTWICKLUNG FESTLEGEN Sobald der Kontext in dem man sich als Product Owner bewegt klarer ist, gilt es, den Rahmen für die Produktentwicklung zu definieren. Dabei spielen sowohl das Aufsetzen eines gut strukturierten Backlogs als auch die Festlegung von Arbeitsweisen im Team eine zentrale Rolle. In diesem Schritt geht es vorangig darum, ein gemeinsames Verständnis zu schaffen, wie gearbeitet und welche Prioritäten gesetzt werden sollen. 3. DELIVERY UND DISCOVERY VEREINEN Ein häufiger Stolperstein in der Produktentwicklung ist die Trennung von kontinuierlicher Lieferung (Product Delivery) und der Entdeckung neuer Optionen und Lösungen (Product Discovery). Beides sollte Hand in Hand gehen. Der Fokus liegt darauf, diese Denkweise im Team zu verankern und sicherzustellen, dass das Product Backlog sowohl kurzfristige Lieferziele als auch explorative Aufgaben berücksichtigt. 4. ZIELE DEFINIEREN UND LANGFRISTIG AUSRICHTEN Darüber hinaus macht es Sinn, konkrete Outcome-Ziele zu definieren. Dominique und Oliver machen in der Episode klar, dass es hier nicht nur um das Setzen von Sprintzielen, sondern vor allem um übergeordnete Ziele wie Produk Goal, Quartalsziele oder KPIs geht. Diese geben allen Beteiligten eine klare Richtung und ermöglichen es, den Fortschritt regelmäßig zu reflektieren und anzupassen. Wichtig ist für die beiden hierbei, solche Ziele nicht zu früh zu formulieren. EIN LANGFRISTIGER ANSATZ Die beschriebenen vier Schritte sind nicht als starre Abfolge zu verstehen, sondern sollten regelmäßig reflektiert und angepasst werden. Auch nach mehreren Monaten lohnt es sich, immer wieder einen Schritt zurückzugehen und zu prüfen, ob der Rahmen noch passt oder ob der Fokus neu justiert werden muss. Am Ende bleibt es entscheidend, dass man als PO nicht nur operativ gefordert ist, sondern sich auch strategische Freiräume schafft, um das Produkt langfristig erfolgreich zu machen. Oliver und Dominique möchten mit diesen Impulsen Product Ownern für die ersten Wochen eine Idee an die Hand geben, wie ihr sinnvoll startet und euren Weg in der Produktentwicklung erfolgreich gestalten könnt.

In dieser Folge spricht Dominique mit Eva-Maria Schön über die Herausforderungen des agilen Requirement Engineering und wie wir sie als Product Owner meistern können. Zu den großen Herausforderungen gehören die Abhängigkeiten zu anderen Teams, die Selbstständigkeit der Teams, ein fehlender Blick auf das große Ganze, die kontinuierliche Pflege von Anforderungen, Anforderungn von den Nutzern einsammeln und das Einbinden der Stakeholder. (Siehe dazu auch https://www.researchgate.net/publication/316116540_Key_Challenges_in_Agile_Requirements_Engineering). Mehr über Eva findet ihr auf LinkedIn: https://de.linkedin.com/in/evamariaschoen Wir sind gespannt zu hören, wie Ihr als Product Owner ein agiles Requirement Engineering einsetzt und welche Erfahrungen ihr dabei gesammelt habt. Wie immer freuen wir uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Das Sprint Planning ist für Product Owner ein wichtiges Event in Scrum. Dennoch passieren oft zahlreiche Fehler im Hinblick auf Selbstorganisation und Product Ownership des ganzen Teams. Zudem fühlt das Planning sich für viele Product Owner auch häufig eher merkwürdig an. Oliver und Dominique berichten von ihren eigenen Erfahrungen und welche Fehler ihnen selbst im Sprint Planning schon unterlaufen sind. Im Gespräch beleuchten die beiden das Event aus Sicht des Product Owners. Dabei geht es sowohl um die Zweck, den das Planning für den Product Owner erfüllen soll, welche Vorbereitungen man treffen sollte und letztlich wie ich ein gutes Sprint Planning als Product Owner gestalte. Die Ergebnisse aus dem Sprint Planning haben einen großen Einfluss auf den Erfolg eines Sprints. Daher ist es so wichtig, die drei grundsätzlichen Fragestellungen gut zu bearbeiten: Warum, Was und Wie? Warum? Als Product Owner solltest Du einen Vorschlag machen, warum es Sinn macht, in den nächsten Sprint zu investieren und damit dem Team auch die Relevanz erklären können. Den Kontext für das kommende Sprintziel geben dabei Produktvision, Roadmap und Product Goal. Was? In diesem Schritt erfolgt die Auswahl der Product Backlog Elemente und ihre Übernahme in das Sprint Backlog durch bzw. gemeinsam mit den Developern. Dabei sollte der Fokus darauf liegen, was zur Erfüllung des Sprintziels notwendig ist und nicht ob die Auslastung aller Teammitglieder sichergestellt ist. Schließlich wollen wir primär den Wert des Produkts maximieren und nicht die Auslastung optimieren. Wie? Während die Developer in diesem Schritt planen, wie sie während der Iteration vorgehen wollen, um das Sprint Goal zu erreichen, nimmt der Product Owner eine passive Rolle ein und steht mindestens für weitere Rückfragen und Entscheidungen zur Verfügung. Stolperfalle: hier geht es ums Planen, wie das Team das "Wie" angeht - noch nicht um die (technische) Konzeption und Lösungsfindung an sich! Als Ergebnis vom Sprint Planning haben wir ein vollständiges Sprint Backlog. Dies umfasst das Sprintziel, die ausgewählten Items und den gemeinsam erstellten Plan für Umsetzung.

Wie wahrscheinlich ist es, dass ihr diese Folge anderen Product Ownern weiterempfehlen würdet? Diese Art der Frage kennen wahrscheinlich sehr viele von uns. Der Net Promotor Score (kurz NPS), ist eine sehr weit verbreitete Form, wenn es um die Erhebung von Kundenfeedback geht. Dabei hat er neben seinen Vorzügen auch ein paar Schwierigkeiten. Grund genug, dass sich Oliver und Dominique intensiver dazu austauschen und ihre Erfahrungen teilen. Die beiden beginnen mit einer Einführung, damit wir eine gemeinsame Ausgangsbasis haben. Wie wird der NPS eigentlich berechnet und wie ist seine Geschichte? Sobald der NPS erhoben ist, stellt sich schnell die Frage, wann der Net Promotor Score des eigenen Produkts eigentlich gut ist. Keine einfach zu beantwortende Frage, der wir uns aber versuchen anzunähern. Ausgehend von der Einordnung, wann ein NPS-Wert gut oder schlecht ist besprechen wir verschiedene Hinweise, die beim Einsatz des Net Promoter Scores berücksichtigt werden sollten. Ein paar weitere Quellen zum NPS möchten wir euch gerne mitgeben: - The One Number You Need to Grow von Frederick F. Reichheld (https://hbr.org/2003/12/the-one-number-you-need-to-grow) - What is a Good Net Promoter Score? (https://www.retently.com/blog/good-net-promoter-score/) - Würden Sie diese Methode einem Freund empfehlen? von Stefan Ruf (https://www.anovum.com/publikationen/VSMS_2007_CM_NPS_StefanRuf_anovum.pdf) - Warum der Net Promoter Score schädlich ist (https://blog.seibert-media.net/blog/2018/02/02/warum-der-net-promoter-score-schaedlich-ist-und-was-ux-professionals-deswegen-tun-koennen-teil-2/) Im Zusammenhang mit dieser Episode solltet ihr auch diese Podcast-Folgen anhören: - Erfolgreiche Nutzerinterviews führen (https://produktwerker.de/erfolgreiche-nutzerinterviews-fuehren/) - Impulse für ganzheitliche Kundenzentrierung (https://produktwerker.de/ganzheitliche-kundenzentrierung/) Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Was sollte ich in meiner Verantwortung als Product Owner wirklich niemals tun? Was sind absolute NoGos? Oliver spricht in dieser Folge mit Mick Hohmann über seine persönlichen Erkenntnisse zu diesem Thema. Mick hat 5 NoGos mitgebracht, die er in der Diskussion ausführlich erläutert: 1. Product Owner ist nicht Teil des Teams oder wird nicht so wahrgenommen 2. Product Owner übernimmt Scrum Master Aufgaben 3. Das Fehlen einer Produktvision 4. Fehlendes Wissen über Wert & Kosten 5. Nutzer als Stakeholder wird vergessen Und Mick hat dann als Bonus noch ein weiteres NoGo dabei, welches an dieser Stelle aber noch nicht erraten wird. ;) Solltest du den einen oder andere Punkt auch bei dir erkennen, dann kann sicher der Scrum Master weiterhelfen. Wir empfehlen daher gerne die Episode "Mein Freund der Scrum Master" mit Steffi Götten, weil wir dort einige Lösungsansätze zur Überwindung der NoGos besprochen haben.

In der Produktentwicklung spielen Kreativitätstechniken eine essenzielle Rolle. Sie dienen dazu, innovative Ideen zu generieren und den Entwicklungsprozess auf neue Bahnen zu lenken. In dieser Folge sprechen Tim und Dominique darüber, wie Kreativitätstechniken innerhalb der agilen Propduktentwicklung beispielsweise mit Scrum eingesetzt werden können. Viele setzen auf das altbewährte Brainstorming, aber es zeigt sich oft, dass diese Methode ihre Grenzen hat. Eines der Hauptprobleme liegt in der sozialen Erwünschtheit, die oft die Qualität der generierten Ideen beeinträchtigt. Brainstorming, führt regelmäßig dazu, dass Teilnehmende sich selbst zensieren oder Ideen aus Angst vor Ablehnung zurückhalten. Hier setzt das Brainwriting an, eine Alternative, die in diesem Kontext häufig als hilfreicher erachtet wird. Durch die Möglichkeit, Ideen schriftlich zu notieren, wird der soziale Druck reduziert. Alle Teilnehmenden können ihre eigenen Gedanken ohne Hemmungen aufschreiben, was zu einer größeren Bandbreite kreativer Ansätze führt. Ein weiterer Ansatz, der sich bewährt hat, ist die 635-Methode. Hierbei formulieren sechs Teilnehmende jeweils drei Ideen in fünf Minuten. Diese Ideen werden dann an die nächsten sechs Teilnehmenden weitergereicht, die darauf aufbauend neue Ideen generieren. Durch diese iterative Vorgehensweise entstehen in kurzer Zeit eine Vielzahl an Ideen, ohne dass der Einfluss sozialer Faktoren die Kreativität einschränkt. Da an der Produktentwicklung aber viele Köpfe beteiligt sind, bieten sich auch Techniken an, bei denen Menschen jeweils die gleiche Denkperspektive einnehmen. Beispielsweise haben sich Edward de Bonos Denkhüte als nützliches Instrument erwiesen. Diese metaphorischen Hüte repräsentieren verschiedene Denkrichtungen, die in der Gruppe durchgespielt werden können. Jeder Hut steht für eine andere Sichtweise: neutral, emotional, optimistisch, kritisch, kreativ und strukturiert. Indem die Teilnehmenden bewusst in diese verschiedenen Rollen schlüpfen, entsteht eine facettenreiche Betrachtung des Problems, die zu vielseitigen Lösungsansätzen führen kann. Dominique empfiehlt hier aber, dass alle Teilnehmenden immer die gleiche Perspektive einnehmen und nicht einjeder einen anderen Hut zur gleichen Zeit trägt. Eine weitere Methode, die sich bewährt hat, ist die Walt-Disney-Methode. Sie nutzt die Rollen des Träumers, Realisten und Kritikers, um eine Idee aus unterschiedlichen Blickwinkeln zu betrachten. Dadurch werden sowohl visionäre Ansätze als auch praktische Umsetzbarkeit beleuchtet, was zu ausgewogeneren und umsetzungsfähigen Ideen führen kann. -- Empfehlungen -- Wir möchten euch an dieser Stelle das Buch "How to have creative ideas" (ISBN 978-0-09-191048-8) von Edward de Bono empfehlen. Als persönliche Empfehlung von Dominique hier noch ein hervoragender Vortrag von John Cleese zum Thema Kreativität im Management: https://www.youtube.com/watch?v=Pb5oIIPO62g&ab_channel=VideoArts Passend zum Thema Kreativität hier ein paar weitere Folgen: - Als Product Owner im Sprint Review (https://produktwerker.de/als-product-owner-im-sprint-review/) - Mit Storytelling andere von Deinen Produktideen überzeugen (https://produktwerker.de/storytelling-fuer-product-owner/) - Visual Leadership für Product Owner (https://produktwerker.de/visual-leadership-product-owner/)

Produktqualität ist ein Thema, das Product Owner immer wieder vor Herausforderungen stellt. In der neuesten Episode der Produktwerker sprechen Oliver und Dominique darüber, wie Product Owner das Bewusstsein für Qualität im gesamten Team stärken können. Denn schlechte Produktqualität kann nicht nur die Nutzererfahrung negativ beeinflussen, sondern auch den Arbeitsfluss des Teams stören und langfristig viele negative Folgen verursachen. Die Verantwortung für die Produktqualität wird in vielen agilen Produktteams unterschiedlich wahrgenommen. Während Entwickler häufig die technische Qualität in den Fokus stellen, müssen Product Owner sicherstellen, dass das Produkt nicht nur funktional, sondern auch nutzerzentriert und nachhaltig entwickelt wird. Hier entsteht schnell ein Spannungsfeld zwischen Geschwindigkeit und Sorgfalt. Oliver und Dominique sind sich einig: Qualität, egal über welche Perspektive man spricht, ist nicht verhandelbar. In einem iterativen Entwicklungsprozess muss Qualität von Anfang an mitgedacht und konsequent umgesetzt werden, damit ein stabiles, erweiterbares und zukunftsfähiges Produkt entsteht. Auf der einen Seite ist die äußere Produktqualität wichtig, also wie Nutzer das Produkt erleben. Um sicherzustellen, dass ein Produkt einen Beitrag zur Problemlösung leisten kann, ist es wichtig, die Erwartungshaltung von Nutzern genau zu kennen und Metriken zur Messung der Nutzererfahrung zu etablieren. Product Owner können Qualität in den Fokus rücken, indem sie diese Metriken nicht nur bei der Entwicklung neuer Features berücksichtigen, sondern auch in Reviews und strategische Entscheidungen mit einfließen lassen. Ebenso bedeutend ist die innere Qualität, also die technische Exzellenz des Produkts. Ein schlecht strukturierter Code kann langfristig zu Problemen führen, die die Entwicklung verlangsamen und Innovationen erschweren. Daher ist es wichtig, dass Product Owner Raum für technische Verbesserungen und nachhaltige Entwicklungspraktiken wie automatisierte Tests oder Refactoring schaffen. Hier sollten sie mit Entwicklern und dem Scrum Master offen diskutieren, wie viel Zeit für technische Qualität eingeplant wird, um langfristig effizient zu bleiben. Ein weiterer Faktor ist die Zusammenarbeit im Team. Qualität entsteht nicht nur durch technisches Können, sondern auch durch gute Kommunikation, klare Verantwortlichkeiten und Vertrauen. Product Owner sollten in Retrospektiven gezielt das Thema Produktqualität ansprechen und gemeinsam mit dem Team reflektieren, welche Maßnahmen Qualität langfristig sichern können. Auch psychologische Sicherheit spielt eine Rolle: Teammitglieder müssen sich trauen, Probleme offen anzusprechen, um Verbesserungen anzustoßen. Ein starkes Qualitätsbewusstsein entsteht nicht von heute auf morgen. Es erfordert kontinuierliche Aufmerksamkeit, einen gemeinsamen Anspruch an Exzellenz und eine Kultur der Zusammenarbeit. Product Owner haben dabei die Aufgabe, das Thema Qualität immer wieder ins Bewusstsein zu rufen und durch ihr eigenes Verhalten vorzuleben. Denn nur so kann langfristig ein Produkt entstehen, das sowohl technisch robust als auch für Nutzer wertvoll ist.

Durch das Refinement wird das Product Backlog zu einem gut gepflegten Product Backlog und ist dadurch ein wichtiges Werkzeug für Product Owner. Tim und Dominique unterhalten sich in dieser Folge über das Refinement des Product Backlogs und welche Bedeutung es für uns als Product Owner hat. Zu Beginn klären wir erst einmal, was Refinement eigentlich ist und wie es in Scrum passt. Das Refinement wird zwar oft als Termin gesehen, ist aber eigentlich ein Prozess. Deshalb sprechen wir über den allgemeinen Ablauf des Refinements, wer alles mitwirkt und was wir als Product Owner vorbereiten sollten. Wir sind nämlich davon überzeugt, dass wir neben Vision und Product Goal auch eine aktuelle Roadmap dabei haben sollten. Dank dem Refinement haben wir dann nicht nur ein gepflegtes Product Backlog; wir erhalten auch neuen Input für die Priorisierung von Product Backlog Items und erlangen ein Verständnis über Umfang, Kosten, Risiken und anderer Aspekte der ganzen Backlog Items. Wir können daher dank des Refinements bessere Entscheidungen treffen. Und wie in jeder Folge wollen wir mit ein paar Tipps abschließen. Habt ihr beispielsweise mal daran gedacht das Refinement eines bestimmten Themas als Product Backlog Item einzuplanen, damit im nächsten Sprint an diesem Thema gearbeitet wird? In der Folge erwähnen wir übrigens kurz das Product Backlog Refinement Canvas, eine gut geeignete Vorlage, um sich eine strukturierte Übersicht zu machen. Ihr findet es unter https://www.kaizenko.com/the-product-backlog-refinement-canvas/ Wenn ihr noch mehr über das Product Backlog hören wollt, dann empfehlen wir euch die folgenden Folgen: - Das Product Backlog (https://produktwerker.de/product-backlog/) - Ist dein Product Backlog voll bzw. zu groß? (https://produktwerker.de/product-backlog-voll/) - Product Backlog Einträge sind nicht nur User Stories! (https://produktwerker.de/product-backlog-eintraege/) Wenn euch dieser Podcast gefällt, freuen wir uns auch über eine positive Bewertung in eurer Podcast App oder als Feedback per Mail an podcast@produktwerker.de oder via Instagram oder Twitter (@produktwerker).

Ist Product Operations nur ein neuer Hype oder handelt es sich um das "Next Big Thing" im Bereich Produktmanagement? Tim hat für dieses Thema Felix Stein, Geschäftsführer der Agile Process GmbH, zu Gast. In dieser Episode besprechen die beiden, wie wichtig es ist, eine klare Definition von Product Operations zu haben und wie diese Definition das Verständnis und die Verwendung von Product Operations im Unternehmen verbessern kann. Felix & Tim beleuchten daher die verschiedenen Definitionen von Product Operations von bekannten Branchenexperten wie Marty Cagan, Melissa Perry und John Cutler. Marty Cagan kritisiert, dass der Begriff Product Operations oft für wenig hilfreiche Interpretationen im Bereich Produktmanagement verwendet wird und grenzt "Production Operations" von "Product Operations" ab. Marty bezieht sich positiv auf die Definition von The Force Multiplier Model, die er selbst prägt und die sich auch auf die Product Operations Definition von Melissa Perri bezieht. Tim und Felix diskutieren diese Definition und wie sie sich von den anderen Definitionen, wie The Reincarnated PMO Model, The Two-in-a-Box PM Model, The Delegated Product Leader Model, Production Operations Rebranding Model, The Product Marketing Manager Rebranding Model unterscheidet, die Marty kritisch beleuchtet. Spannend ist, dass Melissa Perri wird bald ein Buch zu Product Operations veröffentlichen. Detailliertere Informationen zu dem kommenden Buch findest du auf productoperations.com. Quellen & Links Felix Stein war schon mal als Gast in diesem Podcast. Thema der Folge 117 war damals „Product Ownership im Konzernumfeld“ (https://produktwerker.de/po-im-konzern/) Folgende Quellen werden im Gespräch zitiert: John Cutler (Post): https://cutlefish.substack.com/p/tbm-4552-what-is-productops Marty Cagan (Post): https://www.svpg.com/product-ops-overview/ Melissa Perri (kommendes Buch): https://www.productoperations.com/ Melissa Perri: Escaping The Build Trap https://www.amazon.de/-/en/Melissa-Perri/dp/149197379X

Warum sollte Product Discovery einen wichtigen Bestandteil in der Produktentwicklung spielen? Wie kann Discovery-Arbeit in Scrum integriert werden? Das besprechen Tim und Oli mit dem erfahrenen Certified Scrum Trainer Heiko Stapf von Emendare aus Karlsruhe, der ebenso als Innovations- & Produktmanager sowie Agiler Coach arbeitet. Natürlich erklärt Heiko zunächst auch erstmal, was er unter Product Discovery versteht und wie er es definiert. Mehr zu Heiko Stapf findet ihr auf https://www.emendare.de/team/heiko-stapf/ Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Wir haben Markus Andrezak und Sohrab Salimi zum gemeinsamen Gespräch mit Dominique und Tim eingeladen. Während Sohrab und Tim eher aus der Businessecke kommen, haben Markus und Dominique ihr Standbein in der Nutzer-Domäne. Aus dieser feinen Mischung entstand ein intensives Gespräch darüber, worauf Product Owner (mehr) achten sollten bzw. wie man beide Welten auch gut verbinden kann. Unser Flow war so gut, dass diese Episode ausnahmsweise mal etwas länger ist. Wir sind überzeugt, dass sich die Zeit lohnt, mit zwei solch ausgewiesenen Produktmanagement Experten und Trainern mal tiefer einzusteigen. So ging es auch intensiver in die Themen Change und Business Agility. Am Ende geben Markus und Sohrab ihre wertvollen Tipps, was man lernen, lesen und hören sollte, um gut in die Product Owner Rolle hineinzuwachsen oder in ihr besser zu werden. Ein toller Satz der hängen bleibt: "Agile Produktentwicklung gibt Dir Sicherheit im Vorgehen, um die Unsicherheit in den Anforderungen ertragen zu können". Diese Folge ist voll von solch starken Analogien und lebhaften Beispielen. Markus und Sohrab waren auch schon zu Beginn unseres Podcasts zu Gast. Ihre immer noch sehr lohnenswerten und oft gehörten Folgen legen wir euch daher zudem ans Herz: - Markus Andrezak in Folge 3: "Warum scheint die Product Owner Rolle so schwer zu sein?" - Sohrab Salimi in Folge 11: "Product Owner als Agile Leader" Im Gespräch nennen Sohrab und Markus eine Menge Quellen: - Eric Ries: Lean Startup - Alex Osterwalder & seine Arbeiten auf Strategyzer - Fallstudie MAN über "Agilität in der Automobilentwicklung" - HBR-Artikel "Embracing Agile" - Roger L. Martin: Playing to Win - How Strategy Really Works - Erika Hall: Just Enough Research - Claudia Kotchka bzgl. Design Thinking bei Procter & Gamble - Buch über Pixar von Ed Catmull: "Die Kreativitäts-AG - Wie man die unsichtbaren Kräfte überwindet, die echter Inspiration im Wege stehen" - Podcast mit Yvon Chouinar‪d‬ über die Geschichte von Patagonia - Buch von Reed Hastings: Keine Regeln - Warum Netflix so erfolgreich ist - Buch Clayton M. Christensen: The Innovator's Solution - Warum manche Unternehmen erfolgreicher wachsen als andere - Buch Clayton M. Christensen: The Innovators Dilemma - Warum etablierte Unternehmen den Wettbewerb um bahnbrechende Innovationen verlieren - Podcast How I build this von Guy Raz Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram, LinkedIn bzw. auf Twitter @produktwerker.

In dieser Folge spricht Tim mit Sabina Lammert über Visualisierung und wie man sie wirkungsvoll als Product Owner einsetzen kann. Was ist alles Visualisierung? Wie gut muss ich zeichnen können? Ist das Kunst oder kann es jede/r? Wir streifen durch die üblichen Aufgaben von Product Ownern und beleuchten, an welchen Stellen Euch Visualisierung bei Eurer Arbeit helfen kann. Wie immer freuen wir uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker. Wir sind gespannt zu hören, ob und wie Visualisierung für Euch als Product Owner hilfreich ist. Im Gespräch wurden die folgenden Quellen angesprochen: - Sketchnote Leitfadens für lernOS: https://www.slideshare.net/cogneon/lernos-sketchnoting-leitfaden-version-04 - Agile Short Stories: https://os-agility.de/agile-short-stories/

Was sind No-Code Tools? Manchmal auch Low-Code Tools genannt. An welchen Stellen im Produktmanagement können Produktteams davon profitieren? Tim hat die No-Code Expertin Lilith Brockhaus von visualmakers.de zu Gast und bespricht mit ihr die spannende Frage, ob und wie No-Code Tools Produktteams bei der Produktentwicklung helfen können. Dabei geht es zu Beginn natürlich erstmal um die Frage, was No-Code Tools (und auch Low-Code Tools) überhaupt sind. Ziemlich schnell macht Lilith klar, dass sie nicht glaubt, dass tatsächliche Programmierung bzw. coden damit obsolet wird. Vielmehr ergeben sich für Nicht-Programmierer neue Chancen, ihre Ideen schneller auszudrücken und mit Nutzern zu testen. Ihre These: es verändert sich hierdurch etwas in der Zusammenarbeit der Teams. Tim sieht zudem den großen Wert von No-Code Tools im Rahmen der Stakeholder-Kommunikation und eben grundsätzlich Ideen schnell und einfach mal ausprobieren zu können und halt auch mit weniger "Werkstolz-Schmerzen" das Gebaute wieder wegzuwerfen. Lilith gibt zudem eine ganze Reihe von Empfehlungen von No-Code Tools, die sie im Rahmen der Produktentwicklung einsetzen würde. - softr.io - levity.ai - make.com bzw. zapier.com - bubble.io - airtable.com bzw. seatable.io - bannerbear.com - webflow.com Auf der VisualMakers Website gibt es zu einigen dieser Tools auch hilfreiche Tutorials und eine Tool-Übersicht. Zum Abschluss reden die beiden noch über die mögliche Datenschutz-Problematik und die Chancen und Grenzen der Skalierung beim Einsatz von No-Code bzw. Low-Code. Hierzu empfiehlt Lilith, sich die Erfahrung von FINN mal anzusehen: https://www.visualmakers.de/case-study/finn-x-make Um tiefer ins Thema No-Code rein zu kommen, bietet VisualMakers kostenlose No-Code Einsteiger Kurse an: https://www.visualmakers.de/no-code-online-training Tiefer rein, kommt ihr dann mit dem Rapid Prototyping Bootcamp: https://basics.visualmakers.de/rapid-prototyping Tim empfiehlt auch explizit, den VisualMakers Podcast und ist bereits großer Fan. Dort könnt ihr noch viel mehr von Lilith Brockhaus und Alex Sprogis und ihren tollen Gästen hören. Mehr über Lilith Brockhaus erfahrt ihr auf der VisualMakers Website: https://www.visualmakers.de/. Gerne freut sie sich auch über den direkten Kontakt zu euch - am Besten per LinkedIn, wo ihr ihr auch folgen solltet: https://www.linkedin.com/in/lilith-brockhaus/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: - Wie hole ich User Feedback mit Kundeninterviews ein? - Das Problem mit dem Minimal Viable Product Habt ihr schon Erfahrung beim Einsatz von No Code Tools bei euch im Produktteam? Und wenn ja, wie helfen sie euch und welche Tools habt ihr im Einsatz? Wir freuen uns, wenn du deine deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/no-code-tools/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Evidence-Based Management (EBM) ist ein Denkansatz (Framework), welcher euch helfen kann, in der Organisation über den Wert eurer gelieferten Produktentwicklungen zu reflektieren. Mit EBM kann man diesen Wert messen, managen und so versuchen, ihn kontinuierlich zu steigern. Beim EBM wird die Verbesserung von Ergebnissen, die Reduzierung von Risiken und die Optimierung von Investitionen fokussiert. Das Denkmodell basiert auf den Arbeiten von Ken Schwaber und Scrum.org. Dort findet ihr auch die meisten Ressourcen zu EBM. Aus diesem Grund ist EBM auch Teil der Lerninhalte der Product Owner Trainings der Scrum.org. Unsere Gäste in dieser Episode, Boris Steiner und Glenn Lamming, sind beide Professional Scrum Trainer bei Scrum.org. Glenn und Boris geben v.a. gerne zusammen als Team ihre Trainings und insbesondere Product Owner Trainings. Sie sind in ihrer Arbeit sehr auf Outcome orientiert und ausgewiesene Experten für Evidence-Based Management. EBM basiert auf der Betrachtung von vier Key Value Areas: - des Unrealized Value (UV) - Zeigt den Wert an, der dem Kunden oder Benutzer heute geliefert wird - des Current Value (CV) - der Wert, der durch die Erfüllung aller potenziellen Bedürfnisse von Kunden oder Anwendern realisiert werden könnte - der Ability to Innovate (A2I) - Misst die Fähigkeit, eine neue Funktionalität zu liefern, die die Bedürfnisse von Kunden oder Anwendern besser erfüllen könnte - der Time to Market (T2M) - Bewertet die Fähigkeit, neue Funktionalitäten, Dienstleistungen oder Produkte schnell liefern zu können Wenn ihr mit Boris und Glenn in Kontakt kommen wollt bzw. an ihren Trainings interessiert seid, bekommt ihr über folgende Wege Kontakt zu den beiden. Boris Steiner: https://www.linkedin.com/in/borissteiner/ bzw. https://www.borissteiner.com/ Glenn Lamming: https://www.linkedin.com/in/glennlamming/ bzw. https://www.glennlamming.com/ Literaturempfehlungen: - https://www.scrum.org/resources/evidence-based-management - The Evidence-Based Management Guide von Scrum.org: https://scrumorg-website-prod.s3.amazonaws.com/drupal/2020-12/EBM%20Guide%202020_1.pdf - https://www.scrum.org/resources/blog/becoming-agile-evidence-based-management - https://www.youtube.com/watch?v=W_9HuzL99gA - https://www.scrum.org/resources/lessons-learned-implementing-evidence-based-management - https://www.scrum.org/resources/blog/measuring-agility - https://www.scrum.org/resources/blog/when-are-smart-goals-not-so-smart Diese Episode steht auch in Zusammenhang zur Folge mit Tim Herbig "Outcome Goals und Product Discovery". Falls ihr die noch nicht gehört habt, könnte es sich lohnen, dies jetzt nachzuholen.

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.

Was für eine großartige Episode! Florian Meyer gelingt es, dieses wirklich komplizierte Thema sehr greifbar zu erklären. Wir konzentrieren uns für den Einstieg v.a. auf das Artefakt der "Wardley Map" und streifen den ganzen Strategiezyklus des "Wardley Mappings" nur oberflächlich. Unser Ziel war es aber auch nie, euch das komplette Wardley Mapping zu erklären, sondern einen guten ersten Impuls zu setzen, damit ihr euch nach diesem Einstieg für das Thema interessiert und einen guten Einstieg ins weitere Material findet. Wir glauben, das ist Florian im Gespräch mit Tim gelungen. Als Einstieg vor den originalen Wardley Videos empfehlen wir Euch den deutschen Vortrag von Markus Andrezak von der LeanDUS14 ansehen: (https://leandus.de/veranstaltung/lean-dus-14-innovation-produkt-experiment). Dort erklärt Markus ab der 32.Minute die Wardley Maps (ab der 50.Minute kommt dann nochmals etwas zu Wardley): https://leandus.de/veranstaltung/lean-dus-14-innovation-produkt-experiment Und danach empfehlen wir das Original auf Vimeo anzusehen: Simon Wardley: Crossing the river by feeling the stones: vimeo.com/189984496 Ansonsten haben wir weiter unten noch sie superguten YouTube Playlists mit einer super Übersicht über alle von Florian Meyer empfohlenen Videos aufgeführt. Literatur: - Simon Wardley: On being lost (link.medium.com/80CYi8tSYV) - John Boyd zu OODA-Loops im Buch The Fighter Pilot Who Changed the Art of War - Sun Tsu ("Sunzi"): Die Kunst des Krieges https://de.wikipedia.org/wiki/Die_Kunst_des_Krieges_(Sunzi) YouTube Channels/Playlists: - Wardley Mapping (Videos auf Deutsch) - Wardley Mapping (Allgemeine Videos) - Wardley Maps Channel - Ben Mosior Hired Thought (Videos) Tools: - Strategie-Phrasen-Generator: "What is my Strategy?" - Miro-Vorlage von Ben Mosior und Miro-Artikel - Super Tool Übersicht von Ben Mosior: https://learnwardleymapping.com/tools/ - Online-Tool von Damon Skelhorn inkl. Visual Studio Extension: https://onlinewardleymaps.com/ - Tool von Excalidraw https://excalidraw.com/ - Wardley's Doctrine (universally useful patterns that a user can apply regardless of context) https://doctrine.wardleymaps.com

Diesmal dreht sich alles um das spannende Thema AI Tools für Produktmanagement. Tim Klein spricht mit Alexej Antropov, dem Entwickler des sogenannten KI-Radars. Dieses Radar bietet eine strukturierte Übersicht über die Vielzahl von KI-Tools im Produktmanagement und gibt damit eine gute Orientierung. Alexej erklärt, wie er aus seiner Erfahrung und intensiven Recherche diesen Überblick geschaffen hat, der Product Ownern und Produktmanagern einen tollen Marktüberblick der wichtigsten AI Tools in der schnelllebigen Welt der KI-Technologien gibt. Das KI-Radar ist so konzipiert, dass es nach Rollen und Anwendungsfällen in der Produktentwicklung strukturiert ist. Egal, ob man als Designer, Product Owner, Engineer oder im Team tätig ist – das Radar hilft, relevante Tools zu entdecken und deren Reifegrad einzuschätzen. Das Radar umfasst dabei nicht nur etablierte Anwendungen wie Microsoft Copilot, sondern auch experimentelle und vielversprechende Tools. Seine Motivation ist es, die Innovationskraft von Teams zu steigern und das Thema KI pragmatisch und praxisnah in den Arbeitsalltag zu integrieren. Im Gespräch hebt Alexej Antropov hervor, dass die Nutzung von KI-Tools seines Erachtens nicht nur die Effizienz erhöhen kann, sondern auch völlig neue Möglichkeiten eröffnet; etwa beim schnellen Erstellen von Prototypen oder der Analyse von Nutzerinterviews. Ein besonderer Fokus liegt dabei auf der Frage, wie Unternehmen das Potenzial von KI erschließen können, ohne sich in der Komplexität des Themas zu verlieren. Alexej empfiehlt eine iterative Herangehensweise: klein anfangen, experimentieren und lernen. Das Radar selbst ist ein dynamisches Projekt, das sich durch kontinuierliches Feedback (auch von euch!) und neu entdeckte Tools weiterentwickelt. Alexej sieht es als Community-Tool, das also auch durch Beiträge anderer Produktmenschen lebt. Datenschutz und die europäische Gesetzgebung sind für ihn wichtige Kriterien bei der Auswahl der Tools, was das Radar besonders für Unternehmen in der EU attraktiv machen dürfte. Wer sich als Produktmensch mit KI auseinandersetzt, hat die Chance, nicht nur effizienter im Produktmanagement zu arbeiten, sondern auch frühzeitig neue Kompetenzen zu entwickeln. Doch wie fängt man an mit KI zu nutzen? Alexej rät: Einfach Machen! Denn jeder muss irgendwo anfangen. Sein Tipp lautet daher: Geht das Thema einfach in eurem eigenen Tempo an, Hauptsache ihr beginnt damit. Das KI-Radar bietet hierfür eine wertvolle Orientierungshilfe und guten Startpunkt. Es lädt dazu ein, neugierig zu sein und die Möglichkeiten von KI aktiv zu nutzen. Wertvolle Quellen: - Das KI-Radar für Produktmanagement & Software-Entwicklung findet ihr in der jeweils aktuellen Fassung hier: https://www.beyondbacklog.de/p/das-ki-radar-fur-produktmanagement-und-software-entwicklung - Alexej hat sein KI Radar auch schon mal in einem sehr guten Talk (auf Englisch) vorgestellt. Zu diesem Talk findet ihr hier eine sehr gute und detaillierte Darstellung: https://www.beyondbacklog.de/p/product-tank-munich-orga-fitness-in-the-age-of-ai-tool-radar-web-product-development-dovetail-miro-juttu-claude-uizard - Miro im AI Einsatz (inkl. Link zum Prototyping) und den Post von Alexej dazu gibt es hier: https://www.beyondbacklog.de/p/auswerten-von-kunden-interviews-mit-miro-ai-guide-template Folgende ältere Podcast-Episoden werden von Tim im Gespräch genannt, die super zu dieser Folge passen: - AI als Wingman für Product Owner - Produktentwicklung von AI Produkten - Wie No-Code Tools Produktteams helfen können - Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt Wer weitere Fragen an Alexej hat oder ihm selber gute AI Tools für Produktmanagement empfehlen kann, die er noch nicht auf seinem Radar hat, erreicht ihn am besten über sein LinkedIn Profil (linkedin.com/in/alexejantropov/) oder per Mail: alexej@valuerebels.com. Seine Website und vor allem seinen Newsletter findet ihr unter beyondbacklog.de

Damit Product Owner erfolgreich sein können, muss die gesamte Organisation ihre Entscheidungen respektieren. Das hat aber manchmal auch damit zu tun, wie viel Sicherheit Product Owner durch ihr Auftreten vermitteln. Genau dabei hilft kompetentes Auftreten. Es geht nicht darum, ob man kompetent ist, sondern ob man das auch seinen Mitmenschen vermitteln kann. Letztlich geht es um die Erzeugung von Vertrauen, Sicherheit und Zuversicht. In dieser Folge unterhalten sich Oliver und Dominique über kompetentes Auftreten als Product Owner. Während Kompetenz eigentlich bedeutet, dass man wiederholt bestimmte Handlungen erfolgreich durchführen und Probleme lösen kann, ist das kompetente Auftreten das Vermitteln dieser Fähigkeit im Vorfeld. Dabei spielt beispielsweise auch der erste Eindruck eine wichtige Rolle, mittlerweile sogar online. Während bei einem Treffen in Präsenz Körperpflege udn sicheres Auftreten helfen ist online ein gutes Mikrofon und eine vernünftige Ausleuchtung hilfreich. Aber auch die Sprechweise ist wichtig. Reden wir zu schenll oder zu langsam, fällt das direkt darauf zurück wie kompetent uns unser Gegenüber einschätzt. Ein weiteres, wichtiges Mittel, dass die beiden im Gespräch aufführen sind sogenannte Stegreifreden. Es geht darum spontan zu einem bestimmten Thema sprechen zu können. Oft hilft dabei eine Struktur, die es uns erlaubt sorgfälltig aber konzentriert ein Thema zu erläutern. Existiert beispielsweise ein Problem mit unserem Produkt, können wir allen Interessierten zuerst die Auswirkung beschreiben, dann unseren aktuellen Kenntnisstand schildern und dann berichten welche Schritte wir unternehmen, damit das Problem beseitigt wird.

Outcome Goals sind für Produktteams eine Voraussetzung, damit sie sinnvoll Product Discovery machen können. Zu diesem wichtigen Thema haben wir uns Tim Herbig eingeladen. Tim ist Product Management Experte, der neben Beratung und Coaching auch auf vielen internationalen Konferenzen zum Thema Outcome Goals und Product Discovery als Speaker auftritt. Oli klärt mit Tim, wass er genau unter Product Discovery versteht und wie sein Ansatz ist, Produktteams das Thema näher zu bringen. Dabei versucht er weniger dogmatisch zu sein, als einige andere bekannte Frameworks. Seine Gedanken dazu hat er auf seiner Website in einem Resourcen Hub zusammengefasst. Zum Arbeiten im Problemraum gehört nicht nur, dass Nutzerproblem zu verstehen. Für Product Owner ist es ebenso wichtig, auch das Businessproblem verstehen zu wollen. Welche Aufgaben ich dabei in der Product Owner Roll habe und wie ich mein Team, welches aktuell sehr auf Delivery fokussiert ist in Richtung Discovery zu bewegen - zu all diesen Themen gibt Tim Tipps & Tricks.

Wie wir als Product Owner die Produktvision in unserem eigenen Kontext erfolgreich einbinden war bereits ein Thema in unserem Podcast. In dieser Folge wollen wir verstehen in welcher Art und Weise die Unternehmensvision für unsere Arbeit als Product Owner relevant ist. Daher sprechen in dieser Folge Tim und Dominique darüber, wie Product Owner die Unternehmensvision in unserer Arbeit integrieren können. Dabei streifen die beiden nicht nur die leidliche Frage wodurch sich eine Vision von einer Mission unterscheidet, sondern auch welchen Einfluss eine solche Vision/Mission für die Entwicklung eines Produktes spielt. Besonders relevant wird die Unternehmensvision beispielsweise wenn mehrere Produkte aus ihr abgeleitet werden. Selbst bei Unternehmen, bei denen es scheint, dass nur ein Produkt existiert (z. B. Instagram) existieren doch meist mehrere Produkte (Instagram für Unternehmen, Instagram für Werbetreibende usw.). Auch zeigen Dominique und Tim auf, dass es hilfreich wäre, die Unternehmensvision in regelmäßigen Abständen im Rahmen des Plannings und des Reviews allen Beteiligten noch einmal in Erinnerung zu rufen. Alleine schon die Frage, in welcher Art und Weise das eigene Produkt bzw. der Wertzuwachs im letzten Sprint auf die Unternehmensvision einzahlt, kann durchaus erhellend sein. Hier stellt sich dann auch die Frage, durch welche Kennzahlen wir unseren Fortschritt in Richtung Produktvision erkennen und wir begründen können warum das auch zu Erreichung der Unternehmensvision wertvoll ist. Am Ende bleibt vor allen ein Appell an alle Product Owner, dass wenn sie die Unternehmensvision nicht kennen, sie diese in Erfahrung bringen sollten. Das Produkt mit seiner Vision sollten wir nämlich in die Unternehmensvision eingliedern. Übrigens haben wir uns zum Thema Produktvision schon einige Inhalte zusammengesucht. Ihr findet sie unter https://produktwerker.de/herausforderung/produktvision-erstellen/. Die Folge zur Produktvision findet ihr unter https://produktwerker.de/wie-die-produktvision-hilft-product-ownern-eine-richtung-zu-geben/.

Wie kann ich wertvolles Feedback von Nutzern einholen? Oliver spricht mit Dominique über die Anlässe und verschiedene Techniken, um von Nutzern zu erfahren, wie sie dein Produkt wahrnehmen. Dabei können Kundeninterviews eine hilfreiche Technik sein. Wie man sie vorbereitet, führt und die Ergebnisse nachbereitet, wird im Gespräch erklärt. In dieser Folge konzentrieren wir uns v.a. auf das Feedback während der Delivery Phase. So können wir mit ersten Inkrementen schnell lernen und ggf. Anpassungen am Produkt oder einzelnen Features vornehmen. Im Gespräch wird auf folgende Techniken und Quellen verwiesen: - Tipps und Tricks für das Interview im Usability Test: https://www.user-experience-blog.de/2014/11/anwender-befragen-tipps-und-tricks-fuer-das-interview-im-usability-test/ - Think Aloud Test: https://de.wikipedia.org/wiki/Thinking_Aloud_Test - 5-Sekunden-Test: http://usability-test-guide.rapidusertests.com/de/articles/3147797-5-sekunden-tests-wie-wirkt-dein-produkt-in-den-ersten-funf-sekunden Wir freuen uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

Als Product Owner ist es essenziell, sich kontinuierlich weiterzuentwickeln und die richtigen Werkzeuge für die tägliche Arbeit zu nutzen. In der neuesten Episode der Produktwerker geht es genau darum: Welche Methoden für Product Owner sind wirklich relevant? Eine der wichtigsten Grundlagen ist die Produktvision. Hier hilft das Product Vision Canvas bzw. das Product Vision Board (von Roman Pichler), um ein gemeinsames Verständnis im Team und mit Stakeholdern zu schaffen. Ob mit dem Framework von Roman Pichler oder dem Positioning Statement von Geoffrey Moore – entscheidend ist, dass die Produktvision klar und lebendig bleibt. Eng verknüpft mit der Produktvision ist das Thema Roadmapping. Klassische, feature-getriebene Roadmaps sind längst überholt. Stattdessen setzen erfahrene Product Owner auf Outcome-orientierte Roadmaps, etwa in Form der Now-Next-Later-Roadmap. Dabei geht es nicht darum, starre Zeitpläne einzuhalten, sondern den Fokus auf die gewünschten Wirkungen zu legen. Für eine sinnvolle Planung ist außerdem Story Mapping unverzichtbar. Diese Methode hilft, eine holistische Sicht auf das Produkt zu behalten, Features sinnvoll zu priorisieren und das Team in die richtige Richtung zu steuern. Jeff Patton hat mit dem User Story Mapping eine Praxis entwickelt, die das Verständnis für Wirkungsschnitte und Priorisierung stärkt. Ein weiteres wertvolles Tool im Werkzeugkasten eines Product Owners ist der Opportunity Solution Tree (OST), bekannt aus Teresa Torres’ Buch Continuous Discovery Habits. Der OST ermöglicht es, Business-Ziele mit Kundenbedürfnissen zu verknüpfen und den besten Weg zur Lösung abzuleiten. Etwas älter, aber genauso wirksam ist das Impact Mapping von Gojko Adzic – ein strukturierter Ansatz, um zu visualisieren, welche Akteure ihr Verhalten ändern müssen, damit das Produkt erfolgreich wird. In der täglichen Arbeit von Product Ownern spielen Annahmen eine große Rolle. Doch oft sind diese weder hinterfragt noch belegt. Hier kommt das Assumption Mapping ins Spiel. Mit dieser Methode von David J. Bland lassen sich Annahmen systematisch priorisieren und durch gezielte Experimente validieren. Auch das Arbeiten mit User-Feedback gehört zu den essenziellen Methoden für Product Owner. Hier hilft der Interview-Snapshot aus Teresa Torres’ Discovery-Ansatz, um strukturierte Erkenntnisse aus Nutzerinterviews zu ziehen. In Kombination mit dem Value Proposition Canvas von Alexander Osterwalder lassen sich die relevanten Pain Points und Gains der Nutzer noch klarer herausarbeiten. Natürlich darf auch das Thema User Stories nicht fehlen. Diese Technik ermöglicht eine nutzerzentrierte Formulierung von Anforderungen. Doch User Stories sind nur so gut wie ihre Akzeptanzkriterien und die Fähigkeit, sie sinnvoll zu schneiden. Deshalb ist es entscheidend, nicht nur das Schreiben, sondern auch das Splitting von User Stories zu beherrschen. Ein weiterer Bereich, der oft unterschätzt wird, ist das Stakeholder-Management. Ohne eine gezielte Strategie kann die Vielzahl an Stakeholdern schnell zur Herausforderung werden. Das Power-Interest-Grid hilft dabei, die richtigen Prioritäten zu setzen und Stakeholder effektiv einzubinden. Daneben sehen wir noch eine elfte Methode, quasi als "Bonus-Thema", das in den letzten Jahren immer wichtiger wird: AI-Prompting. Die Fähigkeit, mit Tools wie ChatGPT oder Perplexity effizient zu arbeiten, kann für Product Owner einen enormen Vorteil bringen – sei es für die Generierung von Ideen, die Analyse von Feedback oder die Strukturierung von Informationen. AI wird zunehmend zum Wingman für Product Owner und sollte daher als fester Bestandteil des Methodensets verstanden werden. Diese zehn Methoden für Product Owner sind nicht nur theoretische Konzepte, sondern praxisbewährte Werkzeuge, die den Alltag eines POs erleichtern und das Produktmanagement auf ein neues Level heben. Welche dieser Methoden setzt du bereits ein? Und welche fehlt deiner Meinung nach in dieser Liste?

Wie etabliert man eine kontinuierliche Product Discovery in den Produktteams? Jan Kiekeben, Discovery Coach bei XING, gibt im Gespräch mit Tim Einblicke in seine Arbeit. Herausgekommen ist ein interessanter Erfahrungsbericht. Zunächst klärt Tim mit Jan Kiekeben erstmal sein Verständnis von Product Discovery und Jan erzählt von seiner Lernreise, die ihn in diese Position geführt hat. Besonders spannend (und vielleicht auch mutig) ist auch die Art und Weise, wie Jan zu der Rolle gekommen ist. Hierzu teilt er auch seinen ganz persönlichen Tipp. Wie geht Jan das Coaching an? Warum schnappt er sich vor allem das sog. Product Trio? Wie geht er dabei in der Regel vor und wie lange begleitet er ein Team? Folgende Bücher werden in dieser Folge genannt: - Marty Cagan - EMPOWERED: Ordinary People, Extraordinary Products - Teresa Torres - Continuous Discovery Habbits - Michael Bungay Stanier: The Coaching Habit: Wie Sie mit Fragen führen und dabei das Potenzial Ihrer Mitarbeiter entfesseln Die empfohlene Masterclass von Teresa Torres findet ihr hier: https://learn.producttalk.org/p/cdh-master-class Diese Folge steht in engem Zusammenhang zum Erfahrungsbericht von Juliana Brell zur ähnlichen Herausforderung bei sipgate: Product Discovery in Scrum integrieren. Weitere Content-Empfehlungen gibt's bei uns in der Produktwerker Box (produktwerker.de/box). Dort gibt's zur Herausforderung Product Discovery eine Menge von uns ausgewählten und empfohlenen Content: Product Discovery um Wissen zu generieren Ihr könnt gerne Kontakt zu Jan Kiekeben aufnehmen. Er freut sich über den Austausch zur Implementierung von kontinuierlicher Product Discovery in Produktteams. Ihr erreicht Jan am Besten via XING (https://www.xing.com/profile/Jan_Kiekeben/) oder per LinkedIn (https://www.linkedin.com/in/jan-kiekeben/). Probiert ihr auch bereits, in euren Teams kontinuierliche Product Discovery zu etablieren? Wenn ja, wie macht ihr das? Wenn nein, woran hapert es noch? 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.

Wenn man bislang per Auftragsentwicklung eine Anwendung gebaut hat und sich von vermeintlichen Vertriebserfordernissen oder mächtigen B2B-Partern hat treiben lassen, reift oft der Wunsch: Lasst uns nun endlich ein klares Produkt formen! Wir besprechen in dieser Folge den steinigen Weg hin zu einer fokussierten Produktentwicklung. Oliver und Tim diskutieren zunächst, wie es zu diesem Wunsch, ein klares Produkt zu bauen kommt. Sie beleuchten die Symptome, die zu einer "verwurschtelten" Anwendung kommt, die quasi alles kann - aber nichts richtig gut. Welche Konsequenzen hat der Beschluss, nun "ein Produkt" zu bauen? Und sind die Auswirkungen einer solchen Entscheidungen den Organisationen überhaupt bewusst? Es werden Praktiken aufgezeigt, die helfen, aus einer Auftragsentwicklung kommend zu entscheiden, was ins künftige Produkt einfließen soll (und was nicht). Oliver und Tim betrachten auch die Stolperfallen, die man bei einem solchen Versuch beachten sollte und liefern am Ende ihre persönlichen wichtigsten Tipps im Umgang mit diesem Thema. Im Gespräch verweisen Oliver und Tim auf Themen und Praktiken, die wir bereits in früheren Episoden dieses Podcasts schon mal ausführlicher behandelt haben. Sofern ihr diese noch nicht kennt, dürfte es sich lohnen, diese beiden Folgen im Kontext zum aktuellen Thema nochmal in Ruhe anzuhören: - Story Mapping nutzen, um über Outcome zu sprechen - Wardley Mapping – Produktstrategie ist wie Schach Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Eine Frage, die immer wieder aufkommt, ist die nach dem notwendigen technischen Wissen, dass man in der Verantwortung als Product Owner braucht. Dominique und Tim stellen sich in dieser Folge diese Frage und teilen ihre Erfahrungen sowie ihre Einschätzung dazu. Dazu muss man sich zuerst fragen, warum die Frage nach dem technischen Verständnis eigentlich aufkommt. Das kann einerseits an dem zugang zur Verantwortung als Product Owner liegen. Wenn man vorher in verwandten Rollen wie beispielswerise Business Analyst, oder Softwareentwickler gearbeitet hat, bringt man fast schon natürlich ein technisches Verständnis mit. Das könnte zumindest ein Grund sein, warum viele Product Owner bereits ein solches Verständnis haben und dadurch die Erwartungshaltung ihres Umfeldes entsprechend prägen. Ob das technische Verständnis aber immer hilft ist auch fraglich. Immerhin hat das Team in ihrer Domäne Expertenwissen und so manch ein Product Owner kann nicht aus der eigenen Haut und will mitmischen. Am Ende geht es aber in erster Linie darum, dass die Menschen, die zusammen versuchen ein erfolgreiches Produkt zu entwicklen miteinander sprechen können. Sie müssen sich gegenseitig verstehen. Daher ist ein sehr grundsätzliches technisches Verständnis durchaus hilfreich. Es mus snicht umfangreich sein und ein Informatikstudium ist garantiert zu viel des Guten. Wir haben in dieser Folge auf folgende Folgen verwiesen: - Stellenausschreibungen für Product Owner (https://produktwerker.de/product-owner-stellenausschreibungen/) - Vom Entwickler zum Product Owner (https://produktwerker.de/vom-entwickler-zum-produkt-owner/) - Wie No-Code Tools Produktteams helfen (https://produktwerker.de/no-code-tools/) Darüber hinaus haben wir folgende Quellen genutzt: - Six types of a “product” owners von Roman Pichler (https://www.romanpichler.com/blog/six-types-of-product-owners/) - The Product Trio von Teresa Torres (https://www.producttalk.org/2021/05/product-trio/) - Code it! (Coding Courses for Kids) (https://code-it-studio.de/) Diese Folge ist unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!

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 (https://www.linkedin.com/company/produktwerker).

In dieser Folge ist Bernd Joussen zu Gast. Bernd ist Agile Coach, Mediator und Trainer und hat seinen Schwerpunkt auf der Entwicklung von Teams. Ein zentraler Bestandteil seiner Arbeit liegt auf dem Thema Retrospektiven. Mit Oliver spricht er daher über die Herausforderungen zwischen Product Owner und Developer - aus Sicht eines Scrum Master. Oliver und Bernd ergründen, wo und warum Herausforderungen zwischen Product Owner und Developer entstehen. Liegt es an der oft fehlenden Produktvision oder an der schlechten Kommunikation - oder eventuell sogar an beiden Faktoren. Damit sich aus dem Scrum Team ein echtes Team entwickeln kann, sollte man die gegenseitigen Erwartungshaltungen klären und im Blick behalten. Bernd vertritt dabei den Standpunkt, dass man den Gegenüber einladen sollte, über die eigene Sicht nachzudenken. Diese und andere Tipps, wie ich mit den in dieser Episode diskutierten Herausforderungen umgehen kann, werden dir als Product Owner helfen, erfolgreicher in deiner Rolle agieren zu können. Freue dich auf ein spannendes und sehr erkenntnisreiches Gespräch! Wenn ihr mehr über Bernd Joussen erfahren möchtet, dann findet ihr mehr Informationen auf seiner Webpage unter https://der-teamdynamo.de. Oder ihr verbindet euch direkt mit Bernd via LinkedIn. Bernd bietet auf der Plattform jeden zweiten Dienstag um 08:00 Uhr ein Lean Coffee zum Thema Retrospektiven an.

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.

Diesmal wollen wir uns der besonderen Herausforderung der Entwicklung einer Omnichannel widmen. Unser Gast Christoph Herrmann ist Head of Product der Kaufland-App bei Kaufland E-Commerce. Im Gespräch mit Tim gibt er einen Erfahrungsbericht, was die Entwicklung eines digitalen Produkts, also einer App, im Kontext des stationären Handels so besonders macht. Da die App im Rahmen der Omnichannel-Strategie von Kaufland auch im Markt bzw. ganz konkret "am Regal" zum Einsatz kommt, werden hier die Grenzen eines typischen Digitalprodukts deutlich verlassen. Es geht also um sehr unterschiedliche Zielgruppen und die Verzahnung mit den Handelsprozessen in den Märkten. Dies führt natürlich zu besonderen Herausforderungen bei Product Discovery, User Feedback Zyklen usw. und macht eine solche Produktentwicklung schon etwas spezieller. Darüber sprechen Christoph Herrmann und Tim Klein in dieser Folge - nachdem erstmal die Frage geklärt wurde, was überhaupt der Begriff Omnichannel bedeutet. Um folgende Themen geht es danach: Wie laufen Sprint Reviews ab? Wie gelingt die Zusammenarbeit mit Stakeholdern? Sicherlich kann man aus diesen Fragestellungen auch dann wichtige Impulse ziehen, wenn man nicht im Omnichannel-Umfeld unterwegs ist. Zu dieser Episode passt auch gut die kürzlich erschienene Folge "Wieviel technisches Wissen muss ich als Product Owner haben?" Wer weitere Fragen an Christoph Herrmann hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil: linkedin.com/in/christophherrmann/ Bist du an der Entwicklung eines ähnlichen Produkts beteiligt? Müsst ihr auch, im Rahmen einer Omnichannel Strategie neben den digitalen Kanälen den stationären Handel im Auge behalten? Welche Herausforderungen sind da bei euch aufgetreten? Wie habt ihr das gut in den Griff bekommen? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Ist der Product Owner eine laterale Führungskraft? Hat man in der Verantwortung als Product Owner auch Führungsverantwortung? Und wenn ja, wie stellt sie sich dar? Tim und Dominique klären in dieser Episode zunächst mal die Frage, was denn unter lateraler Führung zu verstehen ist und ob man als Product Owner grundsätzlich eine Führungsrolle inne hat. Dies leben Unternehmen tatsächlich auch sehr unterschiedlich und oft hängt es auch davon ab, welches Ansehen und Rollenverständnis im Rahmen der Produktentwicklung der Product Owner Verantwortlichkeit zugestanden wird. Es kommt also sehr oft auf das Hierarchieverständnis innerhalb der Organisation an, ob ein Product Owner als laterale Führungskraft im Unternehmen wirken kann. Die Herausforderung ist dann, ohne formale Macht eine (inhaltliche) Führung zu übernehmen. Führung bezieht sich für Product Owner dann vor allem für das Produkt und die Führung im Sinne der zielgerichteten Ausrichtung des Scrum Teams auf Produktvision und Produktziele. Eine entscheidende Frage ist aber auch, wie sich die Stakeholder gegenüber der Product Owner Rolle verhalten bzw. ob sie einen Product Owner als laterale Führungskraft akzeptieren. Ferner diskutieren die beiden Produktwerker aber auch, wo laterale Führung ggf. nicht hilft oder vielleicht sogar schädlich ist. Mit einer zusammenfassenden Betrachtung der Vorteile von lateraler Führung als Product Owner schließt die Folge ab. Das Thema war übrigens ein Hörerwunsch. Wir freuen uns immer wieder, wenn ihr uns Themenvorschläge macht. Im Gespräch wird auf diese Folgen verwiesen: Das Product Operating Model von Marty Cagan Introvertiert als Product Owner - geht das? Stakeholder Community Product Principles Und diese Literaturempfehlungen gab es: Patrick Lencioni: The Five Dysfunctions of a Team Geoff Watts: Product Mastery Wie ist eure Meinung? Kann die Product Owner die Verantwortlichkeit so leben, dass er bzw. sie als laterale Führungskraft zu wirken? Sind bei euch im Unternehmen Product Owner Führungskräfte bzw. werden als solche betrachtet? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

In dieser Folge des Produktwerker-Podcast dreht sich alles um Continuous Delivery aus der Perspektive eines Product Owners. Dominique und Oliver beleuchten die Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous  Deployment und tauschen sich darüber aus, wie wichtig diese Praktiken auch für Produktmenschen sind, um kontinuierlich Mehrwert zu liefern. Continuous Delivery hingegen ermöglicht im Gegensatz zu früher üblichen umfangreichen Releases, kleinere Änderungen regelmäßig auszuliefern und diese frühzeitig in produktionsnahen Umgebungen zu testen. Einer der wichtigsten Argumente für Continuous Delivery ist die Risikominimierung. Durch kontinuierliches Testen in Staging-Umgebungen lassen sich potenzielle Probleme frühzeitig erkennen und beheben, bevor sie live gehen. Dies erhöht nicht nur die Qualität, sondern schafft auch Sicherheit für den Product Owner und das Team. Dominique und Oliver diskutieren in diesem Kontext den Einsatz von Feature-Toggles, mit denen Funktionen gezielt für bestimmte Nutzergruppen aktiviert werden können, um Feedback zu erhalten und die Einführung neuer Features zu kontrollieren. Durch Continuous Delivery wird der Übergang von der Entwicklung zur Auslieferung fließender und transparenter, was wiederum die Zusammenarbeit und Abstimmung mit Stakeholdern erleichtert. Continuous Delivery bekomme ich als Product Owner nicht geschenkt, es erfordert eine Investition in technische Infrastrukturm welche letztendlich die Produktqualität und die Liefergeschwindigkeit verbessert. Dabei sollte das Team regelmäßig reflektieren, wie viel Aufwand bei der Integration und Auslieferung erforderlich ist, um den Nutzen einschätzen zu können. Continuous Delivery hilft somit, kontinuierlich wertvolle und getestete Produktinkremente bereitzustellen und ermöglicht es Product Ownern, flexibler auf Veränderungen zu reagieren und schneller auf die Bedürfnisse der Nutzer einzugehen.

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" (https://susancain.net/7-ways-to-use-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 (https://www.linkedin.com/company/produktwerker).

Der individuelle organisatorische Kontext, in dem wir als Product Owner agieren können, ist mit entscheidend für unsere eigene Wirksamkeit. Grund genug einmal explizit auf die Rolle von HR in agilen Transformationen zu schauen. Dafür ist Jennifer Rolle von den hr pioneers bei Tim zu Gast in unserem Podcast. Jennifer begleitet Unternehmen bei ihren agilen Transformationsprozessen. Zu Beginn ihres Gesprächs berichtet Jennifer, wann uns warum HR in der Regel in den Veränderungsprozess mit involviert wird. Ausgehend von dem Wissenstand über neu entstehende Rollen und Verantwortlichkeiten reflektieren die beiden, welche Probleme es beispielsweise bei der Ausgestaltung dieser neuen Rollen und der Etablierung in Fachbereichen gibt - vor allem bei einem nicht klar kommunizierten Verständnis der Unterschiede zwischen Job & Rolle oder Product Owner & Product Manager. In der spannenden Diskussion kommen Tim und Jennifer auch an den Themen Führungsrolle als Product Owner, Gehaltsdiskussion und interne Bewerbungsprozesse auf eine PO Rolle vorbei. Spannend sind die Einblicke, wie der HR Bereich unterstützen kann, in die neue Verantwortlichkeit hineinzuwachsen. Die Episode schließt wie üblich mit ganz praktischen Tipps für Dich als Product Owner ab. Referenzen aus dieser Folge: Agile HR Manager Training (Certified) -> https://hr-pioneers.com/leistungen/trainings/certified-agile-hr-manager/ Interessante, zum Thema passende Folgen: - Welche Aufgaben gehören zur Product Owner Rolle?: https://produktwerker.de/verstaendnis-product-owner-rolle-entwickeln/ - Ownership verpflichtet: https://produktwerker.de/ownership-verpflichtet/ - Product Owner als Agile Leader: https://produktwerker.de/product-owner-als-agile-leader/ Kontakt zu Jennifer Jennifer freut sich, wenn Du bei Fragen mit ihr Kontakt aufnimmst. Am einfachsten schreibst Du sie über ihr LinkedIn-Profil (https://www.linkedin.com/in/jennifer-rolle-9b8a48108/) an. Sie freut sich auch über ein Email, alle Kontaktdaten findest Du auf ihrer Profilseite bei den hr pioneers (https://hr-pioneers.com/hrp_team/jennifer-rolle/). Folgt uns Produktwerker: - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

Wenn Unternehmen nicht genügend interne Product Owner haben, beauftragen sie zunehmend Interim Product Owner. Meist wird dabei in Form eines zeitlich befristeten Projektauftrags (der idR mehrfach verlängert wird), eine Person gesucht, die als Product Owner woanders schon Erfahrung gesammelt hat. Das beauftragende Unternehmen erhofft sich so Methodenwissen über die Verantwortlichkeit ("Rolle") von außen in die Firma zu bekommen. Aber auch wenn dabei versucht wird, jemanden mit fachlicher Erfahrung des eigenen spezifischen Produktkontexts oder Branche zu finden, gelingt dies nur selten. Denn tatsächlich erscheinen zum einen gar nicht so viele (erfahrene) externe Product Owner verfügbar zu sein - und dass dann auch noch der fachliche Kontext passt, erscheint eher wie ein glücklicher Zufall. Wir haben uns daher Thomas Götten eingeladen, der als Selbständiger solche Aufträge als "Technischer Product Owner" übernimmt. Zum einen will Tim natürlich erstmal verstehen, was das Besondere an einem technischen Product Owner für Thomas ist. Als Product Owner in Festanstellung hatte Thomas viele Jahre Erfahrung sammeln können und ist fest "methodenfest". Das wissen wir, weil wir ihn schon recht lange kennen. Aber vielleicht ist das ja eben auch besonders wichtig, wenn man als Interim Product Owner arbeitet - schließlich darf man sich ja auch nicht vom System des Auftraggebers "verbiegen" lassen, so dass man letztlich als eine Art Zombie Product Owner endet. Es folgt eine spannende Diskussion über Vor- und Nachteile, kein explizites Fachwissen in der Kundendomäne mitzubringen. Natürlich muss man offen und aufgeschlossen sein, aber eine der Schwierigkeiten ist ja allein schon die Akzeptanz bei den Mitarbeitenden beim Kunden. Thomas berichtet von seinen spannenden Erfahrungen bei einem Spielzeughersteller und v.a. aus dem noch ungewöhnlicheren Feld der internationalen Kunstlogistik. Bei einem solch spitzen Produkt stellt sich die Frage nach Externen mit Branchenerfahrung vermutlich noch nicht einmal. Thomas Götten teilt also seine eigenen Learnings aus den letzten Aufträgen als Interim Product Owner und die beiden diskutieren u.a. die folgenden Fragen: Hast man als externer PO die gleichen "Rechte" & "Pflichten" wie ein interner PO? Wie geht man mit "Erbe" um - also wenn ein volles Product Backlog etc. übernommen werden muss, welches man ggf. gar nicht komplett versteht. Wieviel "Invest" in Team, Beziehung etc, lohnen sich, wenn man als Externer unterwegs ist und die Aufträge i.d.R. zwischen 6 und 12 Monaten dauern? Auf diese älteren Episoden unseres Podcasts verweisen Tim und Thomas im Laufe des Gesprächs: - Dein Freund der Scrum Master - Was die Einführung von OKR für Product Owner bedeutet - Wieviel technisches Wissen muss ich als Product Owner haben? - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Event Storming: Verständnis für komplexe Produkte schaffen Wer weitere Fragen an Thomas Götten hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite joettis.com. Hast du schon Erfahrungen mit Interim Product Ownern gesammelt? Wie lief der Einsatz eines zeitlich befristeten Product Owner bei euch ab? Oder warst du wie Thomas selber schon als externer Product Owner ohne Domänenwissen im Einsatz? Wir sind gespannt, von euren Ergebnissen zu hören! Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Produktstrategie ist ein herausforderndes Thema – unterschiedlichste Strategieansätze, sperrige Begriffe, hohe Erwartungen und der Druck, „richtig“ zu entscheiden, machen es vielen schwer, sich darauf einzulassen. Doch genau hier setzt diese Folge der Produktwerker an. Zusammen mit dem Strategiexperten Markus Andrezak beleuchtet Oliver, wie Product Owner:innen sich effektiv mit Strategieansätzen auseinandersetzen können, ohne in lähmenden Perfektionismus zu verfallen. Was euch immer klar sein sollte: Strategie ist kein abgeschottetes Konzept für eine exklusive Gruppe in einem Unternehmen. Es geht vielmehr darum, klare, bewusste Entscheidungen zu treffen, die Orientierung geben und sich kontinuierlich anpassen lassen. Ansätze wie das Playing-to-Win-Framework von Roger Martin machen dies greifbar. Anstatt einen starren Plan zu schaffen, bietet das Framework die Möglichkeit, flexibel und iterativ zu arbeiten. Ein weiterer wichtiger Punkt ist die regelmäßige Beschäftigung mit Strategie. Markus betont, dass Strategie nicht in einmaligen Offsites entsteht, sondern in kleinen, stetigen Schritten, die Teil des Arbeitsalltags werden. Regelmäßige Reflexionen – zum Beispiel in Meetings oder Sprint Reviews – helfen, Klarheit zu schaffen und die Strategie an den aktuellen Kontext anzupassen. Diese Routine trainiert nicht nur die Fähigkeit, über Strategie zu sprechen, sondern verbessert auch die Kommunikation innerhalb des Teams. Doch es gibt nicht das eine richtige Framework. Vielmehr geht es darum, aus den vielen Strategieansätzen einen Ansatz zu wählen, der zu den eigenen Bedürfnissen und dem Team passt. Ein zentraler Tipp für Product Owner:innen ist, klein anzufangen und iterativ vorzugehen. Das Ziel ist, Strategieansätze so in den Arbeitsalltag zu integrieren, dass sie praktikabel bleiben und echten Mehrwert schaffen. Wer das schafft, wird feststellen, wie sehr eine klare Strategie die tägliche Arbeit erleichtert – sei es bei der Priorisierung des Backlogs oder der Zieldefinition für das Team. Diese früheren Folgen werden in dieser Episode referenziert: - Produktstrategie in die Praxis bringen - mit Markus Andrezak - The Product Field - Framework - The Decision Stack Und diese anderen älteren Folgen können wir in diesem Kontext empfehlen: - Eine Produktstrategie entwickeln - Von der Produktstrategie zum Product Backlog (mit Roman Pichler) - Eine Produktstrategie ohne Canvas erarbeiten (mit Tim Herbig) Frühere Folgen mit Markus Andrezak: - Warum scheint die Product Owner Rolle so schwer zu sein? (Folge 3 und immer noch eine der meistgehörten Folgen!) - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (neben Markus auch mit Sohrab Salimi - und durch die zwei Experten ausnahmsweise etwas länger als sonst) Wer weitere Fragen an Markus Andrezak hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil oder über seine Webseite (ueberproduct.de). Weitere Infos zum Lernen in der "Strategy Collective Cohorte" gibt es bei der überproduct Academy.

Obwohl der Scrum Guide definiert, dass der Product Owner nur eine Person und kein Gremium sein soll, sehen wir in der Realität vieler Organisationen, dass die Product Ownership auf mehrere Personen aufgeteilt wird. Tim und Oliver analysieren in dieser Folge unterschiedliche Ausprägungen von Shared Product Ownership. Welche Herausforderungen entstehen, welche Vorteile hat ein solches Szenario und welche Nachteile muss ich in Kauf nehmen? In ihrem Gespräch kommen die beiden zu Schluss, dass es einige Kontexte gibt, in denen Shared Product Ownership sinnvoll sein kann, unabhängig davon was der Scrum Guide definiert. Natürlich schließen Oliver und Tim auch diese Folge wieder mit praktischen Tipps und Tricks ab, die Dir bei geteilter Verantwortung helfen können. Links auf in der Folge erwähnte Quellen: - Talk von Markus Andrezak - Roman Pichlers Blogpost - Podcastfolge: Ein Scrum Team, zwei POs - geht das?

Krisen entstehen immer wieder. Die Corona-Krise ist in ihrer Tragweite ungewöhnlich stark. Aber auch eine drohende Insolvenz ist für ein Unternehmen eine Krise. Wir nehmen die aktuelle Situation zum Anlass, das Verhalten von guten Product Ownern in Krisen zu reflektieren. Dazu sprechen Tim und Dominique mit Andreas Wittler. Andreas ist Agile Coach bei der Media-Saturn IT-Services und bildet unter Anderem ein Scrum-Team in der Lombardai (Italien) aus. Dort ist die Krise besonders hart und normales Arbeit so gut wie nicht mehr möglich. Mitglieder seines Teams sind persönlich oder in ihrem persönlichen Umfeld ganz konkret betroffen. Wir beschäftigten uns z.B. mit den folgenden Fragen: - Wie ist die aktuelle Situation einzuordnen? - Wie gehe ich als Product Owner mit der Situation um? - Welche Auswirkungen hat die Situation auf mein Produkt? - Was macht die Krise mit mir als Mensch? - Was sollte ich jetzt nicht machen? Wir sind gespannt zu hören, wie ihr als Product Owner mit Krisen umgeht und welche Empfehlen ihr Anderen geben könnt. Wie immer freuen wir uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.

In dieser Folge geht es um den Umgang mit schwierigen Stakeholder. Tim und Oliver sprechen über Situationen, in denen man als Product Owner die Zusammenarbeit mit einzelnen Stakeholdern als anstrengend und wenig zielführend empfindet. Oft prallen dann unterschiedliche Interessen aufeinander. Allerdings ohne dass diese Interessenunterschiede für die beteiligten Personen transparent werden. Tim & Oliver sprechen über Konfliktstrategien für Product Owner im Umgang mit Stakeholdern und geben Tipps in Bezug auf bestimmte Symptome. Dabei widmen sie sich auch explizit HiPPOs (Highest Payed Persons Opinion). Ein Aspekt dabei ist, wie ich mich als Product Owner gegenüber hohen Führungshierachien verhalten und positionieren sollte.

Manchmal erfordert das Umfeld einer Produktentwicklung mit einem externen Entwicklungspartner eine Umsetzung als "Agiler Festpreis", also einer bestimmten Vertragsform. Was das heißt, wie man es erfolgreich angehen kann und welche Erfahrungen wir damit schon gemacht haben, besprechen Oliver und Tim in dieser Folge. Kaum eine agile Produktorganisation wird sich vermutlich darum reißen, in einem Festpreis-Konstrukt ein Produkt zu entwickeln, aber die Rahmenbedingungen können wir uns in der Realität nicht immer "backen". So gibt es natürlich immer noch viele Produktvorhaben, die in Form eines Projektes gestartet werden und bei dem ein externer Dienstleister zum Einsatz kommt. Bei der Beauftragung von extern Dienstleistungsunternehmen fordern zunehmend mehr Einkaufsabteilungen großes Organisationen oder Konzerne dabei die Beauftragung als "Festpreis", d.h. nicht mehr in Form eines Dienstleistungsvertrags ("Time & Material"). Wie passt das aber zu einer agilen Vorgehensweise? Auch wenn ein agiler Festpreis nach unserer Beobachtung in letzter Zeit zwar zunehmend seltener als Vertragsform vorkommt, als noch vor einigen Jahren, ist es spannend sich dieses Konstrukt noch mal zusammen anzusehen. Vermutlich ist die Forderung nach einem agilen Festpreis auch eher einem nicht agilen Umfeld geschuldet. D.h. die Budgetierungs- und Einkaufsprozesse des Unternehmens sind noch nicht auf die Vorgehensweise einer agilen Produktentwicklung eingestellt. Somit ist ein "Agiler Festpreis" u.E. letztlich nur ein Hilfskonstrukt, um eine agile Produktentwicklung im Kontext eines nicht agilen Organisationsumfeldes starten zu können. Tim berichtet von seinen Erfahrungen eines großen agilen Festpreis-Projektes, das er in einem Konzernumfeld zusammen mit einem externen Entwicklungsdienstleister eingeführt und umgesetzt hat. Tipps was, was er heute anders machen würde und was damals geholfen hat, die Entwicklung letztlich positiv umzusetzen. Tim verweist im Gespräch rund um das Thema Team "Estimation Game" auf die Folge "Agiles Schätzen: Magic Estimation". Eine weitere gute Episode unseres Podcast zu dem Themenkomplex ist sicherlich auch "Zusammenarbeit mit einem externen Team vom Dienstleister". Aber auch andere Folgen haben sich schon mit den Dienstleister-Kontext beschäftigt. Mögliche Quellen, um tiefer in das Thema einzusteigen: - Stefan Roock, Fritz-Ulli Pieper: Agile Verträge - Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche - Boris Gloger, Andreas Opelt et al: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge

Lars Böhnke ist sicherlich ein Paradebeispiel für einen Produktmanager im Startup. Dabei ist er gelernter Buchhalter. Das wiederum kann einem aber auch ganz gut helfen, wenn man wie Lars für das Produktmanagement des Startups (bzw. inzwischen fast schon ScaleUp) candis.io zuständig ist. CANDIS erleichtert die Abrechnung und revolutioniert das Rechnungsmanagement, inklusive prüfungssicherer Anbindung an DATEV usw. Macht das Spaß, als Produktmanager im Startup für so ein "trockenes" Thema zu arbeiten? Lars schon! Denn warum es ihm soviel Spaß macht, wird euch nach dieser Podcast-Folge auch klar sein. Wer von uns kann in der Praxis schon wirklich behaupten, dass er/sie durchschnittlich rund zehnmal pro Woche ausführlich mit Kunden spricht, um neue Hypothesen zu validieren und Nutzerprobleme besser zu verstehen? Die Haltung in Bezug auf Kundenfeedback und Product Discovery, die uns Lars im Gespräch rübergebracht hat, steckt nicht nur an, sondern macht einfach gute Laune und gibt echt gute Anregungen. In ähnlichem Kontext hatte uns Kerstin Neumann in der Episode auch schon "Impulse für ganzheitliche Kundenzentrierung" aus dem Startup Leben gegeben. Hört euch das im Zweifel auch nochmal an. Lars empfiehlt im Gespräch u.a. folgende Quellen bzw. beruft sich auf folgende Autoren: - Marty Cagan: The Four Big Risks (Blogartikel) - Teresa Torres: Continuous Discovery Habits (Buch) - Alan Klement auf Revealed: Jobs to be Done. Understanding Needs. Predicting Adoption (kostenfreies Online-Buch) Wer mehr über Lars erfahren möchte bzw. mit ihm in den Austausch kommen erreicht ihn sehr gut auf Twitter (@larsboehnke). Ansonsten per Mail (lars@candis.io) oder auf LinkedIn (https://www.linkedin.com/in/lboehnke/)

Zur 100. Folge haben wir uns ein kleines Experiment ausgedacht und wollen Menschen, die uns in den letzten zwei Jahren begleitet haben wieder zu Wort kommen lassen. Dazu haben ihnen wir ihnen diese Fragen gestellt: - Was ist Deiner Meinung nach das (nächste) wichtigste Thema in den kommenden 12 Monaten, welches wir in der Produktmanager/Product Owner-Community diskutieren werden? - Was ist der eine Satz, den du am liebsten jedem/r Product Owner:in mitgeben möchtest? - Was wünscht Du uns Produktwerkern für die kommenden 100 Folgen? In dieser Folge werden wir daher viele ehemalige Gäste wieder hören und halten uns selbst mal etwas zurück. Wenn ihr nach der Folge mehr über unsere Gäste in dieser Folge erfahren wollt, und Lust auf eine ganze Folge mit ihnen habt, findet ihr hier nun die ganzen Links :-) Sohrab Salimi (https://www.scrum-academy.de/trainers/sohrab-salimi/) - Apr 2020 Product Owner als Agile Leader (https://produktwerker.de/product-owner-als-agile-leader/) - Feb 2021 Auf Business oder Nutzer fokussieren als PO? (https://produktwerker.de/business-oder-nutzer/) Indra Burkart (https://www.youtube.com/c/indraburkart) - Mai 2021 Mit Customer Journey Maps arbeiten (https://produktwerker.de/customer-journey-maps/) Johannes Schartau (https://de.linkedin.com/in/johannes-schartau) - Mai 2020 Wie Liberating Structures Dir als Product Owner helfen (https://produktwerker.de/mit-liberating-structures-als-product-owner-zombie-scrum-entkommen/) Katja Busch (https://de.linkedin.com/in/katja-busch-525b9820) - Apr 2021 Die Relevanz von UX den eigenen Stakeholdern vermitteln (https://produktwerker.de/die-relevanz-von-ux-vermitteln/) Tim Herbig (https://herbig.co/) - Nov 2020 Outcome Goals und Product Discovery (https://produktwerker.de/outcome-goals-product-discovery/) Steffi Götten (https://www.linkedin.com/in/steffi-g%C3%B6tten/) - Aug 2020 Dein Freund der Scrum Master (https://produktwerker.de/dein-freund-der-scrum-master/) Heiko Stapf (https://www.emendare.de/team/heiko-stapf/) - Feb 2020 Welche Rolle sollte Product Discovery in der Arbeit von Product Ownern spielen? (https://produktwerker.de/welche-rolle-sollte-product-discovery-in-der-arbeit-von-product-ownern-spielen/) Sabina Lammert (https://de.linkedin.com/in/sabina-lammert-14abb512b) - Jul 2020 Visual Leadership für Product Owner (https://produktwerker.de/visual-leadership-product-owner/) Björn Schotte (https://de.linkedin.com/in/bjoernschotte) - Dez 2019 Der Product Owner aus Sicht eines Dienstleisters (https://produktwerker.de/der-product-owner-aus-sicht-eines-dienstleisters/) - Nov 2020 Product Owner im skalierten Umfeld (https://produktwerker.de/product-owner-im-skalierten-umfeld/) Eva-Maria Schön (https://de.linkedin.com/in/evamariaschoen) - Juni 2020 Requirements Engineering im Agilen meistern (https://produktwerker.de/agiles-requirements-engineering-meistern/) Boris Steiner (https://www.borissteiner.com/) und Glenn Lamming (https://www.glennlamming.com/) - Jun 2021 Evidence Based Management (https://produktwerker.de/evidence-based-management/) Vielen Dank für eurer Interesse und auf die nächsten 100 und mehr Folgen. :-)

Die Gründung eines eigenen Unternehmens ist eine faszinierende und reizvolle Angelegenheit, besonders für Personen, die in der Produktentwicklung tätig sind. Diese Tätigkeit ermöglicht es, eigene Produkte intensiver zu formen und persönliche Ideen Wirklichkeit werden zu lassen. Ein interessanter Ansatz hierbei ist das Ausgründen aus einem Konzern. Für Positionen wie Product Owner, Product Manager oder Product Lead kann dies eine attraktive Option sein. In diesem Zusammenhang haben wir uns mit Christian Fahl unterhalten, der das Unternehmen Loql als Ausgründung aus der REWE Group mit ins Leben gerufen hat. Christian ist heue Product Lead bei Loql und teilt seine Erfahrungen über den Gründungsprozess und wie alles für ihn begann. Besonders aufschlussreich sind die Schritte, die er noch vor der eigentlichen Ausgründung unternommen hat. Diese Phase ist nicht ohne Herausforderungen, auf die Christian ebenfalls eingeht. Seine persönliche Perspektive und Erfahrungen bieten hierbei spannende Einblicke. Ein weiterer wichtiger Aspekt der Ausgründung ist die Zusammenarbeit zwischen dem neu gegründeten Unternehmen und dem Mutterkonzern. Auch hierzu liefert Christian interessante Informationen. Zum Abschluss gibt er noch einige Ratschläge, die ihm im Rückblick geholfen haben, den Prozess der Unternehmensgründung zu erleichtern.

In dieser Podcastfolge wird Oliver seinen Frust über Stellenausschreibungen für Product Owner los. Denn gefühlt wurden noch nie mehr Product Owner gesucht, aber die Inhalte der Jobausschreibungen lassen auf ein bedenkliches Bild auf die Verantwortlichkeiten schließen. Oliver teilt seine Einschätzung anhand von vielen, konkreten Beispielen aus Stellenausschreibungen auf LinkedIn und Stepstone. Oft lassen auch die Jobtitel, wie Team Product Owner oder Technischer Product Owner auf den Aufgabenbereich und das Verständnis des ausschreibenden Unternehmens schließen. Natürlich gibt Oliver auch Tipps, auf welche Details ich als wechselwilliger PO achten sollte. Was sind Elemente von wirklich guten Stellenausschreibungen und welche Informationen zu dem potentiell neuen Product sollte ich im Vorstellungsgespräch einfordern. Die Folge schließt mit zahlreichen konkreten Tipps und Tricks ab.

Jeder macht Fehler und jeder sammelt Erfahrungen. Wie oft denken wir uns dabei, hätten wir das doch früher gewusst. Als das einem von uns vor kurzem wieder mal passiert ist haben wir uns entschieden unsere bisherigen Erfahrungen zu reflektieren und zu sammeln, was wir gerne zu Beginn gewusst hätten. Daher sprechen Oliver und Dominique in dieser Folge über all die Erkenntnisse und Erfahrungen, die sie gerne vorher gewusst hätten. Sie sprechen über Themen wie dem Schnitt der eigenen Verantwortung, die Gesamtheit aller Aufgaben, den eigenen Wirkungskontext, Nutzen verschiedener Backlogs, den Umgang mit anderen Disziplinen und vielem mehr. Im Gespräch verweisen die beiden auf das Buch "Escaping the Build Trap: How Effective Product Management Creates Real Value" von Melissa Perri. In diesem geht es vor allem darum nicht immer nur neue Features zu bauen, sondern das Produkt als Ganzes weiterzuentwickeln und ggf. auch mal Features zu entfernen, wenn sie keinen Mehrwert liefern. Was die Rolle als Product Owner angeht referenziert Oliver auf das "POEM", ein Instrument zum besseren Verständnis der Product Ownership. Mehr dazu findet ihr hier: https://productownership.de/poem/ Und nun ist es auch an euch eure Erfahrungen zu teilen. Was hättet ihr gerne vorher schon gewusst?

In dieser Folge unterhält sich Dominique mit Daniel Ley, einem erfahrenen UX Strategy Manager darüber, wie wir erfolgreich Nutzerinterviews führen können. Wir bauen unsere Produkte schließlich nicht für uns sondern für andere Menschen. Darum liegt es nahe sich auch mit Menschen aus dem Kreis der erwarteten Nutzer und Nutzerinnen zu unterhalten, um herauszufinden was sie bewegt und welche wichtigen Aspekte wir bei der Produktgestaltung berücksichtigen sollten. Daniel arbeitet als UX Strategy Manager im Innovationsteam von Amadeus. Dort validiert er gemeinsam mit Kollegen aus aller Welt neue Geschäftsideen nach dem Lean Startup Prinzip. Er organisiert darüber hinaus das UX Bonn Meetup (http://uxbn.de/) mit und begeistert sich für alle Themen rund um mechanische Armbanduhren, Möbeldesign und Architektur. Mehr zu Daniel findet ihr unter https://www.linkedin.com/in/daniel-ley-171729a1/ Im Gespräch verweist Daniel auf folgende Inhalte: - Tomer Sharon - How to ask questions : https://www.youtube.com/watch?v=8tiuWYs5Z-A Talking to Humans : https://www.amazon.de/Talking-Humans-Success-understanding-customers-ebook/dp/B00NSUEUL4 - Transkription Service Trint : https://trint.com Darüber hinaus hat Daniel noch ein paar weitere Tipps für uns: - Get better data from user studies: 16 interviewing tips - https://library.gv.com/get-better-data-from-user-studies-16-interviewing-tips-328d305c3e37 - How to do a user interview (from Google Ventures updated) - https://www.youtube.com/watch?v=Qq3OiHQ-HCU - What people are really doing - https://vimeo.com/7099570 - Validating Product Ideas - https://www.amazon.de/Validating-Product-Ideas-Through-Research/dp/1933820292 Wenn euch die Folge gefällt, freuen wir uns über eine positive Bewertung in eurer Podcast App oder als Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Instagram oder Twitter.

Wir sprechen in dem “Die Produktwerker” Podcast häufig über Digitalprodukte, da wir alle aus diesem Kontext kommen. Grund genug, mit Bernadette von Wittern einmal eine Expertin für Product Management für Hardwareprodukte einzuladen. Sie hat lange Jahre als Produktmanagerin in der Medizintechnik gearbeitet bevor sie 2020 mit ihrem Unternehmen Product Lounge den Schritt in die Selbständigkeit gewagt hat. Nachdem Bernadette einleitend ihr Verständnis von Produktmanagement geteilt hat, sprechen Oliver und Bernadette über die unterschiedlichen Aufgabenbereiche und Verantwortlichkeiten. Sie teilt dabei spannende Ergebnisse einer aktuellen Studie, die sie im Rahmen der Überarbeitung eines Produktmanagement Buches durchgeführt hat. Daraus kann man einen guten Überblick über das “state of the art” für Product Management für Hardwareprodukte bekommen: Welche Aufgaben haben Produktmanager wirklich? Was sind typische Herausforderungen im Joballtag? Was macht Produktmanager erfolgreich und persönlich zufrieden? Bernadette und Oliver schließen die Folge, indem sie auch auf Gehälter und die immer noch existierende Unterschiede zwischen Frauen und Männer blicken. Wie immer schließt die Folge mit Tipps und Tricks.

"Wir werden das Produkt einstellen - es ist zwar noch erfolgreich, passt aber nicht mehr zur künftigen Unternehmensstrategie." Wenn man solch eine Entscheidung hört, ist klar, dass das Ende des Produktlebenszyklus naht. Aber bis dahin ist ja eben auch noch ein Weg zu gehen, für den es ein motiviertes Team braucht. Der Ramp Down eines Produktes gehört schließlich unzweifelhaft auch zur Produktentwicklung. Zu Beginn des Jahres hat XING (bzw. die New Work SE) die durchaus erfolgreichen Produktbereiche XING Events und XING Gruppen eingestellt, um die eigenen Kräfte zu bündeln und den Fokus auf die neu gewählte Strategie zu legen. Ein wirklich mutiger Schritt. Unser heutiger Gast Thomas Gläser, Director Product Experience bei der New Work SE, hat dies hautnah miterlebt und musste (oder wohl besser gesagt "durfte") diese spannende Phase als verantwortlicher Product Leader begleiten. Im Gespräch mit Tim berichtet er, wie er die Motivation für die letzte Produktphase im Team hochgehalten hat und wie er sich selbst dabei gefühlt hat. Eine spannende Diskussion über eine Erfahrung, die nur wenige Produktmenschen machen dürfen. Im Gespräch werden die folgenden Quellen genannt: - Killed by Google (killedbygoogle.com) - Liberating Structures: Ecocycle Planning (liberatingstructures.de/ecocycle-planning/) - Aufräumen mit Methode: Analogie zu Marie Kondo - Buch von Ernest Becker: The Denial of Death Zu dieser Episode passt auch gut diese ältere Folge: - Features wegwerfen - was braucht es dafür außer Mut? Wer mit Thomas Gläser in Kontakt treten möchte, guckt sich am Besten mal seine persönliche Webseite (thomasglaeser.de) an oder folgt ihm auf LinkedIn. Dort teilt er regelmäßig seine Gedanken zu Produktthemen und über die diversen Veranstaltungen auf denen er aktiv ist. Zudem freut sich Thomas zur Kontaktaufnahme auch über eine direkte E-Mail an ich@thomasglaeser.de. Hast du auch schon mal die Erfahrung "Produkt einstellen" gemacht? Welche Überlegungen gab es bei euch? Welche Befürchtungen hattest du, die sich am Ende vielleicht gar nicht eingestellt haben? Wir sind gespannt, von euren Ergebnissen zu hören! Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerker auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Was sind Pirate Metrics? Das auch als das AARRR-Modell bekannte Set von Metriken hat vor allem im Bereich des Growth Marketing starke Verbreitung und Bekanntheit. Unser Gast Timothy Krechel ist Head of Digital Product Consulting bei Qvest Digital und nutzt die Pirate Metrics auch gerne in der Arbeit von Produktmanagern. Zunächst ergründen Tim und Timothy im Gespräch, was das Akronym "AARRR" bedeutet und woher der Begriff "Pirate Metrics" kommt. Ja - tatsächlich ist hier die Analogie zum furchteinflößenden Ruf von Piraten der profane Grund. Die Abkürzung AARRR steht hingegen für die fünf wichtigsten Funnel-Schritte, auf die sich jedes Unternehmen konzentrieren sollte: „Acquisition“ (Akquisition), „Activation“ (Aktivierung), „Revenue“ (Umsatz), „Retention“ (Kundentreue) und „Referral“ (Empfehlungen). Das Modell hilft, die Customer Journey und die bevorzugten Kanäle der Nutzer besser zu verstehen und in (strategischen) Diskussionen entsprechende Klarheit herzustellen. Außerdem ermöglichen diese sogenannten "Pirate Metrics", umsetzbare Ziele je Funnel-Step festzulegen. Timothy Krechel erklärt dann jeden Schritt des AARRR-Modells im Detail und zusammen mit Tim wird das Verständnis anhand von Beispielen geschärft. Natürlich gibt es noch andere Funnel-Ansätze als die Pirate Metrics. Aber gerade für transaktionsbasierte Geschäftsmodelle ist eine solche Funnel-Darstellung hilfreich. Tim zeigt auch Beispiele aus dem Produktportfolio der Produktwerker zu den einzelnen Steps auf. Spannend wird dann die Frage, wie das AARRR-Modell konkret zu nutzen ist und vor allem, wie es mir als Product Owner helfen kann. Hier gibt der Gast Timothy Krechel wertvolle Impulse, wie die Pirate Metrics in den Alltag als Product Owner integriert werden können. Abschließend zeigt Timothy aber auch die Schwächen der Pirate Metrics auf, um ein rundes Bild zu zeichnen. Passende Podcast-Folgen rund um das Thema Customer Journey: - Mit Customer Journey Maps arbeiten - Customer Journey Management im Konzern - ein Erfahrungsbericht Wenn ihr weitere Fragen an Timothy habt oder mit ihm Kontakt aufnehmen möchtet, vernetzt euch am besten via LinkedIn mit ihm oder schreibt an hello@timothy.de. Weiteren wertvollen Content von und mit Timothy Krechel gibt es in den Product Lunches von Qvest Digital. Kanntest du die Pirate Metrics? Und nutzt ihr sie auch in der Praxis bei euch?Wie bindest du dann das AARRR-Modell in deine Arbeit als Product Owner ein? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. **Folgt uns Produktwerkern auf** - LinkedIn -> https://bit.ly/3gWanpT - Twitter -> https://bit.ly/3NitkPy - Youtube -> https://bit.ly/3DIIvhF - Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Als PO verantworten wir in der Regel nicht ein einziges Produkt während unseres langjährigen Product Owner Lebens. Produkte kommen und gehen, wir entwickeln neue Ideen oder begleiten ehemalige Cash-Cows bis ans Ende ihres Produktlebenszykluses. Und es kann vorkommen, dass wir das „Problem Produkt“ erben, an dem niemand in unserer Organisation gerne arbeiten möchte. In dieser Folge sprechen Oliver und Tim über genau diese Situation. Wir können dann als Product Owner nicht auf der grünen Wiese agieren, sondern spielen nun eher im "Brown Field". Häufig bringt die Übernahme solch eines Produktes eine Reihe von Problemen mit sich: Es ist nur noch schwer erweiterbar oder wartbar, es existieren sehr viele Abhängigkeiten zu anderen Produkten oder Mitarbeitenden. Darüber hinaus lässt auch die Verfügbarkeit/Stabilität zu wünschen übrig. Oliver und Tim reflektieren in dieser Folge, an welchen Symptomen wir erkennen können, dass wir an solch einem Problem Produkt arbeiten. Und sie gehen in ihrer Diskussion einen Schritt weiter, indem sie möglichen Ursachen auf den Grund gehen. Die Folge schließt mit unterschiedlichen Lösungsansätzen ab. Was kann ich al sProduct Owner ganz konkret tun, wenn ich mich in der oben beschriebenen Situation befinde? Hierzu geben Oliver und Tim wie gewohnt eine Reihe von praktischen Tipps und Beispiele aus der eigenen Product Owner Praxis.

Wie können wir den Kundenwert von Produktmerkmalen besser analysieren und verstehen? Das nach Noriaki Kano benannte Kano-Modell (von 1978) bietet hierfür einen wunderbaren Ansatz, um Features und Produktideen im Hinblick auf die damit erreichbare Kundenzufriedenheit besser bewerten zu können. Es hilft, Kundenwünsche zu identifizieren. Oli und Tim erklären, wie insbesondere das "Kano-Interview" als hilfreiche Praktik für die Produktentwicklung funktioniert. Zudem bieten wir euch einen Einblick, wie wir diese Technik auch selber für unsere aktuelle Entwicklung einer Produktidee ("Die Produktwerker-Box") nutzen. Auch (bzw. gerade) weil Die Produktwerker-Box erst ein Prototyp ist ("MVP to learn"), freuen wir uns, wenn ihr unser Kano-Interview hierzu kurz durchführt. Für dieses Kano-Interview nutzen wir das auch im Podcast besprochene Tool Kano+ (http://kano.plus) der Karlsruher Firma Usertimes Solutions GmbH. Eine gute Darstellung rund um das Kano-Modell findet ihr auch hier: https://t2informatik.de/wissen-kompakt/kano-modell

Wir sprechen in unserem Podcast über Product Owner und meinen damit implizit Scrum Product Owner. Doch was ist eigentlich mit Kanban und Product Ownern? Kennt Kanban POs? Über diese und viele weitere Fragen spricht Tim in dieser Folge mit Michael Mahlberg, Geschäftsführer von The Consulting Guild GmbH. Als Berater und Begleiter in großen Veränderungsvorhaben und ausgewiesener Kanban-Experte teilt Michael zu Beginn dieser Episode seine Sicht auf die Unterschiede zwischen Scrum und Kanban. Kanban ist Change und startet bei dem, was schon da ist und lässt sich wunderbar mit Scrum verbinden. Die beiden stellen fest, dass die Definition von "Product Owner" sehr schwammig ist. Diese Unschärfe bezieht sich nicht nur auf die dreiviertel Seite an Beschreibung im Scrum Guide, sondern auch in der Interpretation vieler Organisationen. Es gilt, die Frage zu beantworten: Welche Art von Product Owner wollen wir in dem jeweiligen Kontext einsetzen. Michael führt anschließend aus, was Kanban generell zu Rollen sagt. Und ergänzt seine persönlichen Beobachtungen aus der eigenen Beraterpraxis. Wie immer schließen wir mit Tipps und Tricks für dich als PO ab. Weitere Quellen, die Michael empfiehlt, um sich noch detaillierter mit dem Thema auseinander zu setzen: - Michael Mahlberg: Why are there no Product Owners in Kanban (http://agile-aspects.michaelmahlberg.com/2019/07/why-are-there-no-product-owners-in.html) - Kanban University: The Official Guide to the Kanban Method - Buch zu Kanban-Grundlagen: Essential Kanban Condensed - Das "Blaue Buch" von David J. Anderson: KANBAN - Successful evolutionary change for your technology business Falls du Kontakt mit Michael aufnehmen möchtest, kannst du ihn gerne über Webseite seiner Firma (http://consulting-guild.de/) oder gerne auch direkt via Mail unter mm@consulting-guild.de kontaktieren.

Was kann eine Product Owner Zertifizierung bringen? Lohnt es sich nach dem CSPO/PSPO I weiter zu machen? Oder was sollte ich sonst tun, um mich erfolgreich in der PO-Rolle weiterzuentwickeln? In dieser Folge mit Björn Jensen geht's um die Frage, wie man sich als Product Owner weiterbilden kann und welche Rolle Zertifizierungen dabei spielen können. Als Scrum Master ist es vielleicht naheliegend, Trainings wie Moderation, Konfliktmanagement usw. zu machen. Aber als PO? Was für Schritte machen hier Sinn? Wir sind gespannt zu hören, was Ihr zum Thema Zertifizierungen und Weiterbildung als Product Owner zu sagen habt. Folgende Podcasts werden von Björn empfohlen: - Marcus Andrezak: Stories Connecting Dots - Reid Hoffmann: Masters of Scale - Guy Raz: How I Built this - Mike Fishbein: This is Product Management Folgendes Buch erwähnt Björn zudem: Vineet Nayar: Zuerst der Mitarbeiter, dann der Kunde - Stellen Sie das konventionelle Management auf den Kopf Wie immer freuen wir uns über Euer Feedback auf produktwerker.de, per Mail an podcast@produktwerker.de oder via Twitter an @produktwerker.