Christian Fahl im Gespräch mit Dominique In der Folge kommen wir auf verschiedene Themen zu sprechen. Christian hatte einen Prototyp mittels No-Code-Tools erstellt. Falls euch die Möglichkeiten von No-Code interessieren empfehlen wir euch die Folge "Wie No-Code Tools Produktteams helfen" (https://produktwerker.de/no-code-tools/). Auch haben wir im Gespräch das Konzept eines Minimal-Viable-Product angesprochen zu dem ihr unbedingt die Folge "Das Problem mit dem Minimal Viable Product" (https://produktwerker.de/das-problem-mit-dem-minimal-viable-product/) hören solltet, denn immer wieder ergeben sich aus dem Konzept Probleme. Ansonsten empfiehlt Christian noch das Buch "The 7 Habits of Highly Effective People" von Stephen R. Covey, dass im bei seiner Reise sehr geholfen hat.

Oliver & Tim im Gespräch Gegen Ende eines jeden Jahres kommen die Thema Budget- und Roadmapplanung wieder auf die Tagesordnung. Und in die Planung dieser jährliche Roadmap werden wir als Product Owner*in dann intensiv eingebunden. Aber lohnt der Aufwand, den wir in diese Themen investieren? Tim und Oliver diskutieren diese Themen vor allem auf Basis ihrer eigenen Erfahrungen. Nachdem die beiden reflektiert haben, warum eine jährliche Planung für viele Unternehmen immer noch wichtig ist, geben sie einen kurzen Überblick über die Unterschiede zwischen Projekt- und Produkt-Roadmaps. Da aber die Mehrzahl unserer Ideen für die Produktentwicklung nicht funktionieren oder zumindest mehrere Iteration brauchen, bis sie die Business-Ziele generieren können die wir uns erhofft haben, stellt sich die Frage, ob eine jährliche Roadmapplanung auch wegen der Kompexität und Unsicherheiten im eigenen Produktkontext überhaupt sinnvoll ist. Tim und Oliver bieten in dieser Folge einige Lösungsansätze, wie man besser mit Roadmaps umgehen und arbeiten kann. Wir immer teilen die beiden zum Abschluss der Episode Tipps und Tricks.

Andreas Hinderks im Gespräch mit Dominique Der Berufsstand der UX-Professionals hat in den letzten Jahren eine Differenzierung erlebt, und es sind neue Teildisziplinen entstanden. Eine dieser Disziplinen ist das UX-Management, und mittlerweile gibt es einige Menschen, die die Verantwortung als UX-Manager in Projekten und Organisationen übernehmen. Durch ihre Arbeit prägen sie die Produktentwicklung; es lohnt sich also zu fragen, was das genau ist und wie diese Disziplin Menschen in Verantwortungspositionen als Product Owner, Product Manager oder Product Lead bei der Entwicklung großartiger Produkte unterstützt. Dazu haben wir den UX-Experten Andreas Hinderks eingeladen, der nicht nur beruflich viel mit dem Thema zu tun hat, sondern auch intensiv dazu forscht. Wir klären also zunächst, was UX-Management ist, was manche vielleicht darunter verstehen und wie sich diese Tätigkeit in den Kontext der Produktentwicklung einfügt. Dabei wird schnell deutlich, dass Management nicht ohne Strategie, Ziele und Ressourcen gedacht werden kann. Für Produkte sollten also idealerweise Ziele für eine gute UX gesetzt, eine Strategie zur Zielerreichung festgelegt und die angemessenen Ressourcen zugeteilt werden. Dass dies am besten im Team funktioniert, versteht sich fast von selbst, denn es geht um die Schaffung von Erlebnissen für Menschen. Natürlich tauschen wir uns mit Andreas auch über gute und schlechte Praktiken aus, damit nicht dieselben Fehler wiederholt werden müssen. Nach einigen Prognosen zur Zukunft des UX-Managements gibt Andreas zum Schluss noch einige weitere hilfreiche Tipps zum Thema UX-Management für Product Owner.

Dominique und Tim im Gespräch Velocity ist in der agilen Softwareentwicklung, vor allem in Scrum, weit verbreitete Metrik, die die Arbeitsmenge eines Teams in einem Sprint misst. Aber ihre Nutzung birgt auch bestimmte Grenzen, die Tim und Dominique in dieser Folge kritisch hinterfragen. Velocity, meist in Story Points gemessen, gibt an, wie viel ein Team in einem (durchschnittlich) Sprint leistet. Sie ist hilfreich für die Sprint-Planung und kann die Vorhersagbarkeit verbessern. Doch als reine Output-Metrik vernachlässigt sie wichtige Aspekte wie Outcome und die Qualität der Arbeit. Ein kritischer Punkt, den Tim und Dominique betonen, ist, dass Velocity eine relative Größe ist, die nur innerhalb eines Teams Bedeutung hat. Der Vergleich von Velocity zwischen verschiedenen Teams ist problematisch und kann vorsichtig gesagt mindestens zu Missverständnissen führen. In der Diskussion heben die beiden hervor, dass Teams Velocity als Werkzeug zur Reflexion nutzen sollten, nicht als starres Ziel. Es geht darum, den tatsächlichen Wert und die Qualität der Arbeit zu verbessern - nicht um die reine Liefergeschwindigkeit als Selbstzweck. Andere Metriken, die Kundenzufriedenheit und Outcome zu messen, erscheinen sogar wichtiger zu sein. Interessanter Weise wurde die Velocity früher in Scrum Trainings viel stärker betont. Zusammen mit dem allgemeinen Trend, mehr Wert auf Outcome bzw. Wirkung zu legen, statt eine reine Product Delivery zu fokussieren, wird auch in den Trainings immer seltener über Velocity gesprochen. Neben den Problemen und Fehlern im Umgang mit Velocity betrachten Dominique und Tim natürlich auch die Vorteile des Einsatzes dieser Metrik. Weiterhin geben sie Tipps zum richtigen Einsatz von Velocity. In dieser Folge wird auf diese Episoden im Gespräch verwiesen: Wann ist das fertig? Keine Ahnung, wir sind ja agil! Forecasting in der agilen Produktentwicklung Evidence Based Management - eine empirische Suche nach Wert Nutzt ihr bei euch Velocity als Metrik? Wenn ja, wie gelingt es euch, dass diese Metrik auch positiv im Hinblick auf den Wert des entwickelten Produkts wirkt und nicht zu einem Team-Kontrollinstrument verkommt? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks 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. 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]

Zum Jahresanfang bietet sich oft das Setzen von persönlichen Zielen an Zu Beginn des Jahres bietet es sich an einmal Gedanken zu den eigenen, ganz persönlichen Zielen im neuen Jahr zu machen. In dieser Folge teilt Dominique eigene Erfahrungen und Tipps rund um das Setzen effektiver, persönlicher Ziele – sowohl für das Produkt als auch für die persönliche Entwicklung. Das Setzens von Zielen ist entscheidend, um einen klaren Fokus zu erzeugen. Ein zentrales Thema ist schon ein echter Klassiker: smarte Ziele. Diese Methode hilft dabei, Ziele zu definieren, die spezifisch, messbar, erreichbar, relevant und zeitgebunden sind. Ein besonderer Fokus liegt darauf, wie diese Prinzipien auf die einzigartigen Herausforderungen von Product Ownern und Product Leadern angewandt werden können. Persönliche Ziele, die greifbar und messbar werden, können in der Regel besser erreicht werden. Gerade Produktverantwortlichen müsste es besonders leicht fallen diese Ziele anschließend auch zu bewerten und in eine Reihenfolge zu bringen. Für die persönliche Entwicklung bedeuten klare Ziele: Von der Steigerung spezifischer Kompetenzen bis hin zur Bedeutung von Work-Life-Balance mit den richtigen Maßnahmen die richtigen Schritte gehen. Vielzuoft entscheiden sich Menschen für kurzfristige Belohnungen und vbergessen dabei, dass längerfristige Ziel im Blick zu behalten. Dazu wurden in dieser Folge einige praxisnahe Tipps und Methoden geteilt. Vorgestellt wurden verschiedene Tools und Apps zur Zielverfolgung sowie Zeitmanagement-Strategien, die speziell für die Bedürfnisse von Product Ownern und Product Leadern zugeschnitten sind.

Zum Jahresende bietet sich oft eine persönliche Reflexion an In dieser besonderen Zeit des Jahres, wo wir einen Moment innehalten und das Vergangene reflektieren, möchte ich meine Gedanken und Erfahrungen zum Thema Reflexion mit euch teilen. Diese Zeilen begleiten unsere Podcastfolge, in der Dominique ausführlich über Reflexion spricht, ein Thema, das unserer Meinung nach für Product Owner, Product Manager und Product Leads gleichermaßen relevant ist. Reflexion ist ein wesentlicher Bestandteil des agilen Produktmanagements, bekannt durch Praktiken wie die Retrospektive. Es geht um mehr als nur das Zusammenfassen vergangener Ereignisse; es ist eine Gelegenheit, aus Erfahrungen zu lernen und sich persönlich sowie beruflich weiterzuentwickeln. Für uns ist es wichtig, regelmäßig innezuhalten und sowohl berufliche als auch private Erlebnisse zu reflektieren. Dominiques Reflexionstechniken, die er gerne empfiehlt: Das weiße Blatt: Hierbei man sich stumpf mit einem leeren Blatt Papier hin und notiert alles, was einem zum vergangenen Jahr einfällt. Dies kann zu einer Mindmap oder Sketch Note werden und hilft, die eigenen Gedanken zu ordnen und neue Perspektiven zu gewinnen. Klingt irgendwie zu simpel aber hilft. Reflektionsgespräche: Diese Gespräche führt man mit vertrauten Personen, um Feedback zu bekommen und die eigenen Gedanken weiterzuentwickeln. Es geht hierbei nicht nur um Kritik, sondern um das Erkennen neuer Möglichkeiten und das Ausloten unterschiedlicher Perspektiven. In der Regel reichen zwei bis drei Gespräche. Die persönliche Retrospektive: Nicht nur am Jahresende sondern einmal im Monat kann man sich die Zeit nehmen für eine tiefgehende Reflexion der eigenen Aktivitäten und Entscheidungen. Dies beinhaltet das Durchgehen des eigenen Kalenders und Trello-Boards, um zu verstehen, was man erreicht hat und was noch aussteht. Reflektieren allein genügt nicht. Es geht darum, Konsequenzen aus den eigenen Erkenntnissen zu ziehen. Das bedeutet, Entscheidungen zu treffen, Ziele zu setzen und konkrete Maßnahmen zu ergreifen, um das Beste aus der eigenen Zeit und den eigenen Fähigkeiten herauszuholen. Und nach einer intensiven Reflexionsphase ist es wichtig, sich auch zu belohnen. Das kann eine Aussicht auf neue Ziele sein, eine kleine Freude wie ein leckeres Essen oder einfach die Zufriedenheit, sich selbst Zeit und Raum für persönliches Wachstum gegeben zu haben. Wir hoffen, dass diese Einblicke euch als Impulse dienen und euch gleichzeitig ermutigen die notwendige Zeit für Reflexion zu nehmen. Nutzt die ruhige Zeit zwischen den Jahren, um über das vergangene Jahr nachzudenken und Pläne für die Zukunft zu schmieden. In diesem Sinne wünschen wir euch besinnliche Feiertage und einen guten Start ins neue Jahr!

Tim und Dominique im Gespräch 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? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks 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. 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]

Thomas Gläser im Gespräch mit Tim "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 Liberating Structures: 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? Falls du den einen oder anderen Aspekt deiner Erfahrungen oder Tipps & Tricks 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. 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]

Jacob Pawlik im Gespräch mit Dominique Für Product Owner spielt die tägliche Interaktion mit Softwareentwicklern eine Schlüsselrolle. Sie sind die Stakeholde, mit denen wir im täglichen Arbeiten mit am häufigsten zu tun haben. Von den ganzen Diskussionen über die Absprachen zu Anforderungen bis hin zu gemeinsamen Entscheidungen – die Dynamik dieser Beziehung beeinflusst wesentlich den Erfolg der Produktentwicklung. Um tiefer in diese Beziehung einzutauchen hat Dominique in dieser Folge das Vergnügen, mit Jacob Pawlik (https://www.linkedin.com/in/jacob-pawlik/) zu sprechen. Jacob ist Head of WebTec bei der Scopevisio AG und bringt eine wertvolle Perspektive in unser Gespräch ein: die Erwartungen von Entwicklern an Product Owner. Hauptthemen unserer Diskussion: Entwicklererwartungen: Was genau erwartet ein Developer von einem Product Owner? Jacob beleuchtet diese Frage aus seiner Erfahrung. Produktvision: Wie wichtig ist die Produktvision aus der Sicht eines Entwicklers und wie beeinflusst sie die tägliche Arbeit? Augenhöhe und Hierarchien: Warum sind diese Aspekte entscheidend und wie sollte man mit ihnen umgehen, um eine effektive Zusammenarbeit zu fördern? Red Flags in der Zusammenarbeit: Jacob teilt seine Einsichten darüber, was in der Zusammenarbeit mit einem Product Owner als Warnsignal gelten kann. Refinement, Planning und Review: Was braucht ein Product Owner wirklich für diese Prozesse? Was erwartet ein Entwickler in diesen Phasen? Die Retrospektive mit Product Ownern: Ein Blick auf die Bedeutung und Durchführung effektiver Retrospektiven. No-Gos für Product Owner: Jacob spricht über häufige Fehler, die Product Owner vermeiden sollten. Tipps zur Verbesserung der Zusammenarbeit: Abschließend gibt Jacob praktische Ratschläge, wie Product Owner die Zusammenarbeit mit Entwicklern verbessern können. Diese Episode bietet tiefe Einblicke in die Beziehung zwischen Product Ownern und Entwicklern. Wir hoffen, dass ihr diese Folge genauso aufschlussreich findet wie wir. Aber vielleicht habt ihr auch andere Erfahrungen gemacht oder habt eine abweichende Meinung. Lasst es uns gerne wissen. Entweder als Kommentar zum Blogpost dieser Folge oder bei einem der Posts auf Social Media.

Thomas Götten im Gespräch mit Tim 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 bzw. via E-Mail. 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! Falls du den einen oder anderen Aspekt deiner Insights oder Tipps & Tricks 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. 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]