Die Produktwerker Archiv

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

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?

Wie läuft eigentlich ein richtig gutes Sprint Review? Mit unserem Gast Jan Lensing bespricht Tim dieses Thema nun auf Basis der konkreten Praxiserfahrungen von Jan. Jan ist Scrum Master bei der Firma comnovo - ein spannendes Industrieunternehmen mit Hardware- und Software-Produkten rund um die Entwicklung von Assistenzsystemen für die Intralogistik. Also sehr vereinfacht gesagt, damit man nicht von Gabelstaplern (in allen möglichen Dimensionen) überfahren wird. In diesem Kontext wird nach Scrum gearbeitet und über einen SAFe-Ansatz skaliert. Wir haben uns natürlich schon in früheren Folgen unseres Podcast um das Sprint Review gekümmert. Dennoch geben gerade die vielen Praxisbeispiele nochmal richtig wertvolle Impulse für dieses Scrum Event. Im Gespräch wird sowohl die gute Vorbereitung als auch die gelungene Durchführung eines Reviews besprochen. Zur Vorbereitung gilt natürlich schon die Frage, wann und wie lange man es durchführt sowie wie man die wichtigsten Stakeholder am besten einlädt. Bei der Verbesserung ihrer Sprint Reviews hat Jan Lensing tolle Ideen mitgebracht, die er mit seinen Teams bereits ausprobiert. Auf folgende ältere Folgen wir im Laufe des Gesprächs verwiesen: - Als Product Owner im Sprint Review - Sprint Review ohne Stakeholder - Wer nimmt User Stories ab? - Plattform Team Product Owner: eine besondere Herausforderung Hier noch der Link zum Video "Staplerfahrer Klaus" - ein echter Evergreen aus dem Jahr 2000 und damals vermutlich eines der ersten Videos, was richtig viral ging. Wer mit Jan Lensing in Kontakt treten möchte, um evtl. noch weitere Rückfragen zu klären, erreicht ihn am Besten auf seinem LinkedIn-Profil. 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 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.

Wir Produktwerker werden immer häufiger als Impulsgeber für interne Veranstaltungen angefragt. Und so gerne wir solche Mandate auch annehmen, fragen wir uns, wo denn die ganzen Product Owner bei den vielen Konferenzen, Meetups oder Online-Webinaren eigentlich sind. Daher appellieren Tim und Oliver in der aktuellen Podcastfolge an alle POs: Geht raus aus eurem Gebäude, holt euch Hilfe und seid keine Einzelkämpfer. Zu Beginn der Episode teilen die Beiden ihre persönlichen Beobachtungen von Konferenzen, aber auch die Beteiligung an aktuellen Diskussionen beispielsweise auf LinkedIn oder X. Tim und Oliver kommen zu dem Schluss, dass meist mehr Scrum Master & Agile Coaches solche Angeboten annehmen als Product Owner, obwohl es theoretisch gleich viele von ihnen geben müsste. Was sind mögliche Gründe, dass Product Owner nicht so oft derartige Angebote wahrnehmen. Warum suchen sie wenig Hilfe von anderen Product Ownern? Ist der eigenen Workload zu groß, die Energie zu gering oder ist es der Glaube, dass der Kontext, in denen andere POs arbeiten zu unterschiedlich ist als dass man selber etwas lernen kann? Auf alle Fälle entstehen so einige Probleme, die Tim und Oliver auch diskutieren. Und wie in jeder Podcastfolge haben die Beiden aber auch zahlreiche Ideen mitgebracht, falls man an der eigenen Situation etwas verändern möchte. Wir immer schließt die Episode mit einigen Tipps und Tricks ab, die Du sofort umsetzen kannst.

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

Es ist Sommer und der Product Owner macht Urlaub - echt jetzt? Geht das überhaupt? Immerhin ist die Rolle ja ohne dedizierte Stellvertretung in Scrum ausgelegt. Die Frage stellen sich jetzt zu Beginn der Urlaubszeit im Sommer sicherlich wieder einige Teams und Product Owner oft auch selbst. Dominique und Tim diskutieren darüber und sind sich grundsätzlich einig: dass ein Product Owner Urlaub macht ist unerlässlich, um sich zu erholen und wieder Kraft zu tanken. Die Vorstellung, dass ein Product Owner unersetzlich seien, kann problematisch sein. Mit den richtigen Maßnahmen lassen sich Probleme während der Abwesenheit jedoch minimieren. Denn ohne gute Vorbereitung und eine vernünftige Übergabe kann es sonst wirklich problematisch für den Erfolg der Produktentwicklung werden. Eine gute Vorbereitung ist besonders entscheidend. Wichtig ist, dass alle relevanten Prozesse und Entscheidungen dokumentiert sind. Das Team sollte frühzeitig über den geplanten Urlaub informiert und Aufgaben sowie Verantwortlichkeiten klar delegiert werden. Ein gründlicher Wissenstransfer sorgt dafür, dass die Vertretung vom Product Owner Zugriff auf alle notwendigen Dokumente und Ressourcen hat. Zudem sollte das Product Backlog gepflegt und Sprintziele klar definiert werden, um Transparenz über den Status der Produktentwicklung zu gewährleisten. Während der Abwesenheit des POs muss die Kommunikation mit dem Team und den Stakeholdern klar geregelt sein. Es sollte klar sein, wer die Ansprechpartnerin ist und wie Eskalationswege aussehen. Die Erreichbarkeit des POs im Notfall sollte ebenfalls geklärt sein. Manchmal kann das Sinn machen. Nach dem Urlaub ist es wichtig, die Aufgaben und Verantwortlichkeiten schrittweise wieder zu übernehmen und sich über den aktuellen Stand zu informieren. Die während der Abwesenheit getroffenen Entscheidungen sollten explizit besprochen werden. In der Retrospektive kann besprochen werden, wie sich die Abwesenheit auf das Team ausgewirkt hat und welche Verbesserungen für die Zukunft vorgenommen werden können. Tim und Dominique empfehlen, sich auch auf unvorhergesehene Abwesenheiten vorzubereiten und nach dem Urlaub nicht sofort wieder zu 100% in den Arbeitsalltag einzusteigen. Eine gut vorbereitete Abwesenheit ist nicht nur möglich, sondern auch wichtig für die nachhaltige Entwicklung des Produkts und die eigene Erholung. In der Episode wird auch auf diese älteren Podcast-Folgen Bezug genommen: - POEM - Product Ownership Evolution Model - Dein Freund der Scrum Master Wie geht ihr mit dem Thema des Urlaubs vom Product Owner um? Vielleicht hast du ja auch Tipps für andere Product Owner, wie ihr das so löst und welche Erfahrungen ihr da schon gemacht habt? 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 unseres Podcasts dreht sich alles um das wichtige Thema der Nachhaltigkeit in der digitalen Produktentwicklung. Unser Gast, Thorsten Jonas, Experte für digitale Nachhaltigkeit und Gründer des Sustainable UX Network, teilt seine umfangreiche Erfahrung und wertvolle Einblicke mit uns. Thorsten erklärt, was digitale Nachhaltigkeit wirklich bedeutet, und zeigt auf, wie Unternehmen durch gezielte Maßnahmen ihre digitalen Produkte umweltfreundlicher gestalten können. Er spricht über die Herausforderungen, denen Organisationen begegnen, wenn sie nachhaltige Praktiken einführen, und wie diese überwunden werden können. Wir erfahren, welche Tools und Methoden Thorsten und sein Team im Sustainable UX Network nutzen, um Nachhaltigkeit in den gesamten Produktdesignprozess zu integrieren. Thorsten gibt zudem praktische Tipps, wie man mit einfachen Schritten beginnen kann, digitale Produkte nachhaltiger zu machen. Ein besonderes Highlight der Folge sind Thorstens konkrete Handlungsempfehlungen für sofort umsetzbare Maßnahmen, um den CO2-Fußabdruck digitaler Produkte zu reduzieren und langfristig nachhaltigere Prozesse zu etablieren. Hört rein und lasst euch inspirieren, wie ihr eure digitale Produktentwicklung nachhaltig gestalten könnt!

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.

Wie entwickelt man eigentlich Produkte, die Kunden wirklich lieben? Diese Herausforderung kennen viele von uns. Unser Gesprächspartner ist diesmal Ulf Schubert, ein erfahrener UX-Experte, der uns wertvolle Einblicke und praktische Tipps dazu geben kann. Ulf weißt direkt am Anfangdarauf hin, dass es nicht genügt, ein Produkt nur optisch ansprechend zu gestalten. Der Schlüssel liegt darin, die verschiedenen Anforderungen und Erwartungen der Nutzenden zu verstehen und auszubalancieren. Es geht darum, ein holistisches Design zu schaffen, das sowohl visuell als auch interaktiv ansprechend ist und die Bedürfnisse der Nutzer erfüllt. Es ist außerdem schwer, sich allein durch technischen Fortschritt zu differenzieren. Stattdessen sollten Unternehmen schnell die Bedürfnisse ihrer Kund:innen erkennen und diese besser als die Konkurrenz erfüllen. Der Fokus sollte darauf liegen, die Erwartungen der Kund:innen zu übertreffen, um Begeisterung zu erzeugen und dadurch positive Mundpropaganda zu fördern. Ein zentraler Punkt in dem Gespräch war die Methodik. Ulf betonte, dass es nicht die Methode an sich ist, die entscheidend ist, sondern wie flexibel und spielerisch man mit ihr umgeht. Er hob das Konzept der Product Discovery hervor, bei dem vier Fragen im Mittelpunkt stehen: Welche Bedürfnisse gibt es? Wie müssen wir sie erfüllen? Können wir das technisch umsetzen? Und erreicht das unsere geschäftlichen Ziele? Für erfolgreiches Produktmanagement ist es essentiell, kontinuierlich von den Kunden zu lernen und sich anzupassen. Dies erfordert sowohl eine hohe Kundenkompetenz als auch einen datenbasierten Ansatz. Teams sollten regelmäßig Feedback einholen und Nutzungsdaten analysieren, um schnell auf Veränderungen reagieren zu können. Empathie spielt dabei eine zentrale Rolle. Ulf betonte, wie wichtig es ist, dass Teams die Bedürfnisse und Erwartungen der Nutzer verstehen und sich in deren Lage versetzen können. Dies kann durch direkte Interaktion mit den Kunden, etwa durch Besuche vor Ort oder Teilnahme an Nutzertests, erreicht werden. Zum Abschluss des Gesprächs gab Ulf zwei wesentliche Tipps: - Nehmt euch Zeit, Empathie für die Kund:innen zu entwickeln. Hört zu und beobachtet sie genau, um deren Bedürfnisse und Erwartungen zu verstehen. - Erweitert eure Perspektive und betrachtet das Produktdesign ganzheitlich. Eine gute Lösung ist immer ein Zusammenspiel verschiedener Aspekte – technischer, fachlicher und gestalterischer Natur. Durch diese Ansätze können Produkte entwickelt werden, die nicht nur funktional und ansprechend sind, sondern die Kund:innen wirklich lieben. Ein Produkt, das Bedürfnisse erfüllt und Erwartungen übertrifft, schafft Begeisterung und langfristige Zufriedenheit.

Zack! Gerade wurde dir mitgeteilt, dass du nun plötzlich Product Owner sein sollst. Puh, was heißt das und was wird ab jetzt von mir erwartet? Diese Situation kommt gar nicht so selten vor - nach unserer Beobachtung vor allem in größeren Unternehmen. Oliver und Tim beleuchten die verschiedenen Kontexte und Situationen in denen dies geschehen kann und erklären damit ein Stück weit, wie es dazu kommt. Ihre Beobachtungen basieren auf ihrer langjährigen Erfahrungen in agilen Transformationen sowie auch aus ihrer Mentoring- und Trainingspraxis bei der Begleitung von (neuen) Product Ownerinnen und Produktorganisationen im Umbruch. Vor allem liefern die beiden aber Empfehlungen und Tipps, wie man selbst mit so einer Herausforderung umgehen kann. Wie kann ich diese neue Rolle dabei vielleicht sogar aktiv gestalten? Vieles hängt dabei daran, mehr Rollenklarheit herzustellen (Stichwort: Erwartungsmanagement). Genauso wichtig ist aber auch, die mögliche eigene Unsicherheit offen anzusprechen und sich bei "Umlernen" von seinem direkten Teamumfeld helfen zu lassen. Auf diese Podcast-Folgen wird im Gespräch verwiesen: - Welche Aufgaben gehören zur Product Owner Rolle? - Stellenausschreibungen für Product Owner - WTF? - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Plattform Team Product Owner: eine besondere Herausforderung - Vom Projektleiter oder Teamleiter zum Product Owner - POEM - Product Ownership Evolution Model - Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner - Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Weitere empfohlene Quellen zur Herausforderung plötzlich Product Owner zu sein: - Video "Story-Mapping" im Produktwerker-YouTube-Kanal - Matt LeMay: Product Management in Practice (zu den "CORE Skills") - Beispielhafter Artikel zur “How to Work with Me” Idee mit weiterführenden Links und Templates: https://www.linkedin.com/pulse/how-work-me-document-senia-maymin/ Kennst du die Situation, plötzlich Product Owner zu sein? Gab's oder gibt es das in deinem Umfeld vielleicht auch? Wie hast du das empfunden oder was hast du beobachtet? Vielleicht hast du ja auch Tipps für andere Product Owner? 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 Podcast-Episode tauchen Dominique und Oliver tief in das Konzept des "The Decision Stack" ein und diskutieren, welche Erkenntnisse ein Product Owner aus dem mentalen Model von Martin Eriksson ziehen kann. Das Thema, was die meisten Product Owner, mit denen wir als Produktwerker arbeiten dürfen, tagtäglich beschäftigt, ist die Priorisierung der Anforderungen und die Sortierung der Product Backlog Items. Unserer Erfahrung nach handelt es sich bei dieser Herausforderungen gar nicht um das eigentliche Problem sondern ist lediglich das Symptom für das Fehlen einer angestimmten, logischen Vorgehensweise auf visionärer, strategischer und taktischer Ebene. Oliver und Dominique teilen daher zu Begin der Folge unterschiedliche Situationen aus ihrer eigenen Praxis. Für die Lösung dieser Herausforderungen bietet der Decision Stack ein strukturiertes aber dennoch einfaches mentales Model an, um mit komplexen Entscheidungen auf allen Flughöhen umgehen zu können. Oliver erklärt die einzelnen Elemente, Product Vision, Product Strategy, Objectives, Opportunities und Tasks und wie diese zusammenhängen. Im nächsten Schritt konkretisieren die beiden das Model für den Kontext eines Produkt Owners. Dominique und Oliver überlegen, wann und wie wir als Product Owner den Decision Stack effektiv in der täglichen Arbeit einsetzen können, um zielgerichteter agile unser Produkt weiterzuentwickeln. Wie immer schließt die Folge mit praktischen Tipps und Tricks ab. Martin Eriksson hat auf seiner Webseite eine ganze Reihe von Informationen, Slides und Videos zum Decision Stack geteilt. Der Gründer der Mind the Product Bewegung kündigt auch ein eigens Buch zu dem Thema an. Wir wünschen Dir wie immer vielen neue Impulse für Deine eigene Arbeit als Product Owner.

Immer häufiger trifft man auf Product Owner von einem Plattform Team. Schnell kommen dann die Fragen auf, ob und wie die Ideen eines klassischen Scrum Product Owners anwendbar sind. Was ist das Produkt? Was sind in diesem Fall die Kunden bzw. besser gesagt die Nutzer? Ganz offensichtlich ergeben sich aus solchen Rahmenbedingungen eine Reihe von ganz speziellen Herausforderungen. Daher nehmen sich Dominique Winter und Tim Klein in dieser Folge des Themas an. Entsprechend klären sich zunächst mal die Frage, was genau hinter dem Begriff des Plattform Teams steckt und wie es sich von den Experience Teams abgrenzt. Unter den besonderen Herausforderungen heben sie hervor, sich nicht in die Ecke eines internen Dienstleisters drängen zu lassen. Auch wenn man als ein solcher Product Owner keinen externen Marktzugang hat, ist der Aufbau eines echten Problemverständnisses der (internen) Nutzer aus den sog. Experience Teams sehr wichtig. Auch Stakeholder Management bekommt als Product Owner eines Plattform Teams eine besondere Bedeutung. In der Regel hat man ja mehrere andere Teams, dem eine solche Plattform zur Nutzung bereitgestellt wird. Schnell können dadurch unterschiedliche oder auch widersprüchliche Anforderungen herangetragen werden. Die eigene Plattform muss aber gemäß der eigenen Produktvision in eine geplante Richtung entwickelt werden. Die Gefahr, es jedem internen Stakeholder Recht zu machen und damit mit der Plattform zum Spielball der Kräfte zu werden, ist ansonsten sehr hoch. Es geht also letztlich darum, den Wert der eigenen Plattform als Lösung für die Probleme der Experience Teams im Blick zu behalten und die Plattform Lösung als gestaltende Product Ownerin zu führen. In dieser Folge wird auf diese Quellen referenziert: - Podcast-Folge: Vom Entwickler zum Product Owner - Buch: Manuel Pais und Matthew Skelton: "Team Topologies: Organizing Business and Technology Teams for Fast Flow" - Buch: Marty Cagan: "EMPOWERED" Bist du evtl. selber auch Product Owner in einem Plattform Team oder arbeitest du in bzw. mit einer solchen Teamkonstellation? Welche Herausforderungen erlebst du ähnlich, welche weiteren siehst du noch? Und hast du ergänzende Tipps für die Situation auf Basis deiner eigenen Erfahrung? 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 Podcast-Folge widmen wir uns der Herausforderung, OKR in der Praxis sinnvoll einzusetzen. Tim hat dafür die Expertin und Autorin Christina Lange zu Gast. Sie ist freiberuflich OKR Coach und hauptberuflich Head of Agile und Lead Digital Academy bei der METRO.digital. Christina erlebt also seit vielen Jahren OKR in der Praxis und kennt daher auch die praktischen Probleme und Grenzen bei Nutzung und Einführung von Objectives & Key Results (OKR). Zunächst definiert sie, was OKR überhaupt sind und wie sie funktionieren. Wir diskutieren, in welchen Situationen OKR besonders effektiv eingesetzt werden können und welche Vorteile sie im Vergleich zu anderen Zielsetzungsmethoden bieten. Gleichzeitig beleuchten wir auch die Grenzen von OKR und wann sie möglicherweise nicht die beste Wahl sind. Ein wichtiger Aspekt ist die Einführung von OKR in Unternehmen. Hier teilt Christina Lange ihre Erfahrungen und Tipps, um einen erfolgreichen Start mit OKR zu gewährleisten, inkl. der Strategien zur Bewältigung von Problemen mit bzw. den "Missbrauch" von OKR. Besonders interessant ist für unseren Podcast natürlich die Rolle von Product Ownern im OKR Kontext. Tim bespricht mit Christina, wie Product Owner OKR nutzen können, um ihre Produktstrategie zu unterstützen, und welche Herausforderungen sich dabei ergeben können. Des Weiteren wird beleuchtet, wie OKR mit Scrum zusammenpassen und wie sie sich grundsätzlich in agile Arbeitsweisen integrieren lassen. Abschließend betrachten wir die Anwendung von OKR im Kontext von Product Discovery und wie sie die Produktentwicklung und Innovationsprozesse unterstützen können. Erwähnte Podcast-Episoden: - Product Coaching - Gast: Annette Greil - Was die Einführung von OKR für Product Owner bedeutet - Gast: Stefanie Götten Erwähnte und empfohlene Bücher & Quellen: - Christina Lange: OKR in der Praxis: Objectives & Key Results – Beispiele, Hacks, Erfahrungen - Ben Lamorti: The OKRs Field Book: A Step-by-Step Guide for Objectives and Key Results Coaches - John Doerr: Measure What Matters - How Google, Bono, and the Gates Foundation Rock the World with OKRs - Christina Wodtke: Radical Focus: Achieving Your Most Important Goals with Objectives and Key Results - Bart Den Haak: Moving the Needle With Lean OKRs: Setting Objectives and Key Results to Reach Your Most Ambitious Goal - Blog von Filipe Castro: OutcomeEdge.com Falls du weitere Fragen hast und gerne Kontakt zu Christina Lange aufnehmen möchtest, dann verbinde dich mit ihr über ihr LinkedIn-Profil. Sie freut sich über deine Nachricht. Weiterhin möchten wir euch den Blog von Christina Lange ans Herz legen: pragmaticchange.com Welche Erfahrungen habt ihr mit der Einführung von Objectives & Key Results gemacht? Wie fühlen sind OKR in der Praxis bei euch an und wie arbeitest du als Product Owner mit den OKR? Kannst du sie in deine Arbeit einbinden? 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