Die Produktwerker

In dieser Folge unseres Podcasts dreht sich alles um die Herausforderungen und Best Practices rund um die Releaseplanung, insbesondere der Planung und Umsetzung großer Releases. Wir beleuchten dabei, wie wichtig es für Product Owner ist, die Releaseplanung bewusst und vorausschauend zu gestalten. Gerade in agilen Teams, die nach Scrum arbeiten, gibt es oft das Missverständnis, dass am Ende eines jeden Sprints ein Release erfolgen muss, obwohl es doch lediglich heißt, dass das Inkrement potentiell auslieferungsfähig ist (es erfüllt laut Scrum Guide die Definition of Done). Es ist also möglich das Ende eines Sprints und den Zeitpunkt eines Releases voneinander zu entkoppeln. Denn nicht jede potenziell auslieferbare Funktion muss ja sofort live gehen. Ein zentrales Thema ist diesmal die Frage, wann ein Release sinnvoll ist. Product Owner müssen einen klaren Mehrwert für die Nutzer*innen identifizieren , bevor sie den finalen Schritt gehen. Ein Release ist mehr als nur das Bereitstellen von neuen Funktionen. Es erfordert eine detaillierte Planung, um den tatsächlichen Nutzen und Wert zu maximieren. Dabei gilt es, Abhängigkeiten zwischen verschiedenen Teams und Systemen im Auge zu behalten. Ein weiterer wichtiger Punkt, den wir in der Folge ansprechen, ist die Kommunikation während der Releaseplanung. Sowohl intern als auch extern müssen alle Beteiligten – von Entwickler*innen über Support-Teams bis hin zu Stakeholder:innen – auf den gleichen Wissensstand gebracht werden. Oft gibt es während eines Releases eine Downtime, die Nutzer*innen vorher mitgeteilt werden muss. Hierbei sollte der Zeitpunkt für das Release so gewählt werden, dass möglichst wenige Nutzer*innen betroffen sind, wie etwa mitten in der Nacht. Wir diskutieren auch, wie man mit Problemen umgeht, die während eines Releases auftreten können. Es ist wichtig, dass bereits vor dem Release einen klaren Entscheidungsprozess definiert wird, falls unerwartete Schwierigkeiten auftreten. Für große Releases empfiehlt sich außerdem das Konzept des Feature-Toggles, mit dem bestimmte Funktionen gezielt aktiviert oder deaktiviert werden können, um potenzielle Probleme schnell zu identifizieren. Ehrlicherweise sind wir eher Freunde von kontinuierlicher Bereitstellung von Produktveränderungen statt von großen Releases. Aber auch unserer Erfahrung nach gibt es manchmal einfach gute Gründe. Wir würde uns aber wirklich über eure Erfahrungen rund um die Planug großer Releases freuen, denn so können wir besser voneinander lernen. Teilt eure Erfahrungen und Tipps gerne auf unserer Website in den Kommentaren. :-)

Diesmal geht es um ein Thema, das in der digitalen Produktentwicklung noch oft unterschätzt wird: Barrierefreiheit. Mit den Experten Marcel Bertram und Daniel Diener, beide Gründer von A11YPLAN, sprechen wir in dieser Folge über die Bedeutung von Barrierefreiheit in digitalen Produkten und warum sie nicht nur für Menschen mit Behinderungen relevant ist. Barrierefreiheit ist nämlich weit mehr ist als eine rechtliche Notwendigkeit. Barrierefreie Produkte schaffen generell bessere Nutzererlebnisse. Sie sorgen dafür, dass keine Stolpersteine im Weg stehen, wenn Menschen digitale Services nutzen möchten. Egal ob jemand blind ist, vorübergehend eine Einschränkung hat (weil man beispielsweise ein Kind auf einem Arm trägt) oder schlichtweg unter schlechten Lichtverhältnissen arbeitet – ein gutes UX-Design und barrierefreie digitale Produkte machen das Leben leichter. Und das betrifft am Ende uns alle, denn jeder von uns kann in Situationen kommen, in denen eine Website oder App schwerer zugänglich wird. Auch Dinge wie eine langsame Internetverbindung oder schlecht designte mobile Seiten können Hindernisse darstellen und das kennen wir wahrscheinlich alle irgendwo. Barrierefreiheit bedeutet also nicht nur, sich auf spezielle Nutzergruppen zu konzentrieren, sondern das gesamte Produkt so zu gestalten, dass es für jeden einfach nutzbar ist. Seit der Einführung des European Accessibility Act, der ab Juni 2025 gilt, müssen Unternehmen, die digitale Produkte oder Services anbieten, barrierefreie Angebote schaffen – und das nicht nur für neue Websites, sondern auch für bestehende, wenn sie wesentliche Aufrufe erfahren. Doch Marcel und Daniel machen klar: Barrierefreiheit ist nicht nur eine Frage des Gesetzes. Sie ist vielmehr ein klarer Business Case: Gut zugängliche Produkte reduzieren Supportanfragen, erhöhen die Kundenzufriedenheit und steigern den Umsatz. Die Berücksichtigung von Barrierefreiheit in der Produktentwicklung spart nicht nur Kosten, sondern ist auch eine langfristige Investition in die Kundenzufriedenheit. Für Product Owner, die sich bisher noch nicht intensiv mit dem Thema beschäftigt haben, empfehlen Marcel und Daniel, mit einer Bestandsaufnahme zu beginnen. Hier gibt es bereits zahlreiche Tools wie Google Lighthouse oder Deque, die automatisierte Prüfungen durchführen können. Doch das allein reicht nicht: Eine manuelle Überprüfung und echte Nutzertests mit Menschen, die Einschränkungen haben, sind unerlässlich, um sicherzustellen, dass das Produkt wirklich barrierefrei ist. Am Ende der Folge, wie immer, geben die beiden Experten praktische Tipps für den Einstieg in die Welt der Barrierefreiheit. Empathie ist dabei ein zentraler Punkt: Product Owner sollten sich aktiv mit der Frage auseinandersetzen, wie Menschen mit Einschränkungen ihre Produkte nutzen. Eine einfache Übung kann schon sein, auf dem eigenen Smartphone die Barrierefreiheits-Einstellungen zu testen oder Menschen aus dem eigenen Umfeld dabei zu beobachten, wie sie mit den Produkten interagieren. Barrierefreiheit ist keine Herausforderung, die Unternehmen vor sich herschieben sollten. Sie ist ein Schlüssel zu besseren Produkten, zufriedeneren Nutzern und langfristigem Erfolg. Wenn du als Product Owner dein Produkt auf das nächste Level heben willst, führt kein Weg an einer barrierefreien Gestaltung vorbei.

In dieser Folge geht es um ein Thema, das viele Product Owner kennen, aber nicht immer richtig verstehen: Business KPIs. Welche Kennzahlen sind für die Arbeit eines Product Owners tatsächlich relevant und wie beeinflussen sie die Produktentwicklung sowie den Erfolg eines Unternehmens? Gemeinsam sprechen Dominique und Tim über die verschiedenen Metriken, die Product Owner kennen sollten, um fundierte Entscheidungen treffen zu können – von der Conversion Rate bis hin zum Customer Lifetime Value (CLV). Die Frage, die immer wieder aufkommt: Welche KPIs sind für mich als Product Owner wirklich relevant? Business KPIs sind nicht einfach nur eine Kennzahl, sondern ein besonderer Indikator, der hilft, Entscheidungen zu treffen. KPIs sind also mehr als nur Zahlen – sie geben Aufschluss darüber, wie das Produkt genutzt wird und wo Handlungsbedarf besteht. Ein Beispiel ist die Conversion Rate (CR). Sie misst, wie viele Nutzerinnen und Nutzer von einem bestimmten Punkt (z. B. Besuch der Webseite) zu einem gewünschten Endzustand (z. B. Kauf) wechseln. Diese Kennzahl ist nicht nur im Marketing relevant, sondern gibt auch wichtige Einblicke in die Nutzung eines Produkts. Ähnlich verhält es sich mit der Churn Rate, die anzeigt, wie viele Nutzer das Produkt wieder verlassen – ein kritischer Indikator für die langfristige Bindung. Besonders spannend ist die Diskussion um den Umsatz (Revenue) und den Unterschied zwischen Umsatz und Gewinn. Viele Unternehmen konzentrieren sich stark auf steigende Umsatzzahlen, doch wie Tim klarstellt, sind hohe Umsätze natürlich nichts wert, wenn die Kosten explodieren. Hier wird deutlich, wie wichtig es ist, auch auf andere Kennzahlen wie die Customer Acquisition Costs (CAC) zu achten, die die Kosten für die Gewinnung neuer Kunden darstellen. Werden diese Kosten zu hoch, kann das Wachstum langfristig nicht nachhaltig sein. Die Customer Retention Rate (CRR) ist ein weiterer KPI, die für Product Owner von großer Bedeutung ist. Sie zeigt, wie gut es einem Unternehmen gelingt, bestehende Kunden zu halten. Gerade in der digitalen Produktwelt, wo es oft günstiger ist, bestehende Kunden zu binden, anstatt neue zu akquirieren, kann diese Kennzahl entscheidend sein. Besonders spannend ist die Diskussion über den Customer Lifetime Value (CLV). Diese Kennzahl gibt an, wie viel ein Kunde im Laufe seiner gesamten Beziehung mit einem Unternehmen wert ist. Für Product Owner, die Subscription-Modelle oder wiederkehrende Käufe managen, ist dies eine zentrale Größe. Sie hilft dabei, langfristig zu planen und zu verstehen, wie viel ein Unternehmen in die Akquise eines Kunden investieren kann, ohne am Ende Verluste zu machen. Besonders deutlich wird im Gespräch der beiden, wie wichtig es ist, den Zusammenhang zwischen diesen Business KPIs und der täglichen Arbeit als Product Owner zu verstehen. Es reicht nicht aus, nur zu wissen, was ein CLV oder eine Conversion Rate ist – man muss auch in der Lage sein, diese Kennzahlen in konkrete Handlungen umzusetzen, sei es durch die Optimierung von Prozessen oder durch die Anpassung von Produkten. Business KPIs sind für Product Owner also mehr als bloße Zahlen. Sie sind der Kompass, der dabei hilft, den Kurs eines Produkts zu bestimmen und fundierte Entscheidungen zu treffen. Dabei ist es wichtig, die KPIs nicht isoliert zu betrachten, sondern immer im Zusammenhang mit der übergeordneten Strategie des Unternehmens. Product Owner sollten den Mut haben, Fragen zu stellen, wenn sie auf eine unbekannte Begriffe oder Kennzahlen stoßen, und sich die Zeit nehmen, diese zu verstehen. Denn wie Tim und Dominique in der Episode betonen: Oftmals wissen auch die anderen Stakeholder nicht genau, worum es bei einer bestimmten KPI geht – ein klarer Kommunikationsprozess hilft allen Beteiligten, auf dem gleichen Stand zu sein. Hilfreiche ältere Folge des Podcasts passend zum Thema: - Den Wert des Produktes maximieren Wir hoffen, dass du einige neue Impulse zum Thema Business KPI mitnehmen konntest.

Es erscheint gar nicht so leicht, Produktstrategie in die Praxis zu bringen und deren erfolgreiches Wirken zu spüren. In der neuesten Folge des Produktwerker-Podcasts hatten wir das Vergnügen, mit Markus Andrezak, einem Experten in Sachen Produktstrategie, über dieses Thema zu sprechen. Als zweiten Gast hat sich Tim Klein, der Moderator dieser Folge, zudem Oliver Winter, unseren Experten für Strategie und Trainer unserer Produktstrategie-Trainings dazu geholt. Oliver ist diesmal also in der für ihn ungewöhnlichen Rolle als Gast dabei. Tim taucht mit Markus und Oliver tief in in die Frage ein, wie man das Thema Produktstrategie in der Praxis umsetzt, d.h. wie man Produktstrategie in die Praxis bringen und im oft chaotischen Alltag eines Product Owners zum Leben und damit zur Wirkung erwecken kann. Unklarheit als Zeichen fehlender Strategie Markus bringt es auf den Punkt: Wenn Unklarheiten in deinem Team oder deiner Organisation aufkommen, ist dies ein klares Zeichen dafür, dass eine Produktstrategie fehlt oder zumindest nicht klar definiert ist. Doch was tun, wenn du nicht gleich mit großen, überwältigenden strategischen Plänen beginnen möchtest? Hier kommt u.a. die „Challenge-Driven-Strategy“ ins Spiel, ein Konzept, das Markus am Ende des Gesprächs vorstellt. Schritt für Schritt zu mehr Klarheit Statt sofort die gesamte Strategie des Unternehmens auf den Prüfstand zu stellen, empfiehlt Experte Markus Andrezak, Schritt für Schritt vorzugehen. Er rät u.a. dazu, mit dem Produktteam regelmäßige Meetings einzuführen, in denen spezifische Probleme diskutiert und gelöst werden. Der Schlüssel dabei: Diese Treffen sollten immer ein konkretes Ziel haben und nicht in endloses Geplänkel abdriften. Durch diesen kontinuierlichen Prozess wird nicht nur die Zusammenarbeit im Team gestärkt, sondern es entsteht auch langsam, aber sicher eine strategische Ausrichtung des Produkts bzw. Services. Oliver ergänzt Markus’ Vorschlag, indem er betont, wie wichtig es ist, sich als Product Owner auf wenige, aber dafür wesentliche Themen zu konzentrieren. In vielen Teams geht der Fokus verloren, weil zu viele Baustellen gleichzeitig bearbeitet werden. Hierbei hilft es, sich auf die wirklich wichtigen Probleme zu konzentrieren und diese konsequent zu verfolgen. Fazit: Strategie ist kein Hexenwerk Die vielleicht wichtigste Erkenntnis aus dieser Folge? Strategiearbeit muss nicht immer als solche benannt oder formell angegangen werden. Häufig entsteht eine solide Strategie einfach durch die kontinuierliche, fokussierte Lösung von Problemen. Wenn du als Product Ownerin also das Gefühl hast, dass in deinem Produktteam oder deiner Organisation der strategische rote Faden fehlt, dann beginne einfach damit, die größten Unklarheiten aus dem Weg zu räumen – und beobachte, wie sich daraus nach und nach eine klare Produktstrategie entwickelt. Während des Gesprächs wird auch auf die alte, gute Folge mit Florian Meyer verwiesen: Wardley Mapping - Produktstrategie wie ein Schachspiel. Und im Intro natürlich auch auf die beiden super 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) Wenn du weitere Fragen an Markus Andrezak hat oder mit ihm grundsätzlich in Kontakt kommen möchtest, erreichst du ihn am besten über sein LinkedIn-Profil. Was er ansonsten so treibt und vor allem, was hinter seiner überproduct Academy und dem neuen Angebot "The Strategy Collective" steckt, findest du auf seiner Website ueberproduct.de heraus. Wir hoffen, dass du einige neue Impulse zum Thema 'Produktstrategie in der Praxis' aus den Erfahrungen von Markus und Oliver ableiten konntest. Wenn du deine Tipps und Erfahrungen aus der Praxis teilen möchtest, dann hinterlasse gerne einen Kommentar.

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.

Guerilla Discovery – das ist ein vielleicht zunächst mal unbekannter oder ungewöhnlicher Begriff. Gemeint ist damit ein unterschwelliger und kontinuierlicher Weg, um Nutzereinblicke zu gewinnen, selbst wenn das Umfeld nicht ideal für tiefergehende Discovery-Prozesse ist. In dieser Episode ist Tobias Morauf, Senior Product Manager bei cosee, zu diesem Thema der Gesprächsgast von Tim. Er gibt spannende Einblicke in seine Art, für mehr Product Discovery zu sorgen - selbst wenn kein Budget bzw. kein expliziter Wille in seinem Produktkontext bzw. Projekt vorhanden ist, nach mehr Product Discovery zu streben. Wie das genau funktioniert und welche praktischen Tipps dabei helfen, beleuchten wir in dieser Folge unseres Podcasts. Unter Guerilla Discovery versteht Tobias ein Vorgehen, bei der Product Discovery nicht aufwendig und formal durchgeführt wird, sondern unterschwellig aber kontinuierlich in den Produktalltag integriert wird. Ziel ist es, trotz knapper Ressourcen und begrenztem Spielraum wertvolle Erkenntnisse zu sammeln. Ein zentraler Gedanke dabei: Discovery braucht oft weniger Zeit und Aufwand, als man denkt. Ein griffiges Beispiel, das Tobias Morauf aus seiner Praxis teilt, zeigt eindrucksvoll, wie dieser Ansatz funktioniert. In einem Projekt ging es um die Migration eines Systems, bei dem es eine klare Feature-Liste von der IT-Abteilung gab. Doch Tobias bemerkte schnell, dass es eine Diskrepanz zwischen den Anforderungen der IT und den tatsächlichen Bedürfnissen des Kundenservice gab. Statt einfach die bestehenden Anforderungen umzusetzen, entschied er sich, den Kundenservice direkt zu beobachten – ganz unauffällig und ohne großes Aufsehen. Durch diese einfache Maßnahme konnte Tobias feststellen, dass einige der ursprünglich geplanten Features überflüssig waren, während andere, wie die Möglichkeit, Kunden zu sperren oder zu anonymisieren, viel wichtiger waren. Diese Erkenntnisse führten nicht nur zu einer besseren Lösung, sondern halfen auch, unnötigen Aufwand zu vermeiden – ganz im Sinne von Jeff Pattons Prinzip: „Maximiere den Outcome, während du den Output minimierst.“ Um Guerilla Discovery erfolgreich in der Praxis umzusetzen, schlägt Tobias einen Ansatz in fünf Schritten vor: Stakeholder überzeugen: Oft gibt es Widerstände, wenn es um zusätzliche Discovery geht. Hier hilft es, mit gezielten Fragen und Annahmen zu arbeiten, statt sofort mit großen Konzepten oder umfangreichen Interviews zu starten. Nutzer verstehen: Der direkte Kontakt zum Nutzer ist essenziell. Wenn dieser nicht möglich ist, helfen kleine, kontinuierliche Beobachtungen und das Hinterfragen bestehender Annahmen. Im kleinen Rahmen experimentieren: Discovery kann auch in kleinen Schritten stattfinden. Es muss nicht immer der große Wurf sein. Auch kurze Beobachtungen oder Gespräche können wertvolle Einsichten liefern. Scope-Creep beachten: Jedes Projekt hat ein Budget, sei es finanziell oder zeitlich. Ein Teil dieses Budgets sollte bewusst für Discovery verwendet werden, da dies langfristig zu besseren Entscheidungen führt und letztlich Ressourcen spart. Den Scrum Master einbinden: Sollte es zu Widerständen im Team kommen, empfiehlt Tobias, den Scrum Master als Verbündeten zu gewinnen. Dieser kann oft helfen, Konflikte zu moderieren und den Fokus auf die Nutzerbedürfnisse zu lenken. Ein zentraler Punkt, den Tobias betont, ist der Mut, den Guerilla Discovery erfordert. Man muss halt aus der eigenen Komfortzone heraustreten und vielleicht auch mal anecken. Doch genau hier liegt der Schlüssel: Wer bereit ist, kleine Schritte zu gehen und immer wieder hinterfragt, kann selbst in einem schwierigen Umfeld wertvolle Erkenntnisse gewinnen. Fazit: Kleine Aktionen, große Wirkung Tobias’ Ansatz zeigt, dass Product Discovery nicht immer aufwendig oder formell sein muss. Durch gezielte, kleine Maßnahmen können auch in einem schwierigen Umfeld wichtige Erkenntnisse gewonnen werden.

Wir haben Dr. Janna Lipenkova mit dem Thema Produktentwicklung von AI Produkten zu Gast. Sie ist eine ausgewiesene und langjährige Expertin auf dem Feld von KI und NLP hat ihren Doktor in Computerlinguistik gemacht. Nachdem sie mehrere Jahre mit KI und NLP sowohl im akademischen als auch in der Industrie gearbeitet hat, hat sie inzwischen zwei eigene Unternehmen in dem Bereich gegründet, die jeweils künstliche Intelligenz nutzen, um modernste Business Intelligence bereitzustellen und helfen, intelligentere Entscheidungen, Strategien und Umsetzungen zu fördern. Zudem arbeitet sie derzeit als Autorin an einem Buch über die Entwicklung von Produkten mit KI, was bald erscheinen wird ("The Art of AI Product Management - a guide for product managers") Im Gespräch mit Tim gibt Janna zunächst ihr Definition von AI Systemen und stellt auf dieser Basis das von ihr entwickelte holistische mentale Modell vor, welches sie für die Produktentwicklung von AI Produkten empfiehlt. Sie folgt bei den drei grundsätzlichen Dimensionen des Produktmanagement (Technologie, UX, Business). Innerhalb dieser Dimensionen zeigt sie dann verschiedene Komponenten, auf, die man besonders bei der Produkte Entwicklung von AI Produkten beachten sollte. Im Bereich Technologie schlägt sie die Bereiche "Data" und "Intelligence" vor. Auf ihre Sicht zu UX von AI Produkten gehen wir in diesem Gespräch nicht so intensiv ein. Sie hat dies in einem tollen Talk beim ProductTank Cologne zuletzt sehr ausführlich getan. In der Dimension Business schlägt sie die besondere Beachtung der beiden Komponenten "Value" und "Opportunity" vor und erläutert jeweils, was sie damit meint. Quellen aus diesem Gespräch: - Artikel "Mental model of an AI system" - Buch von Dr. Janna Lipenkova für Produktmanager: The Art of AI Product Management Wer mit Janna direkt in Kontakt treten möchte oder noch weitere Fragen an sie hat, erreicht sie am besten über ihr LinkedIn Profil. Mehr über ihr Unternehmen Anacode und ihr StartUp EQUINTEL findet ihr im Netz. Wir hoffen, dass Du einige neue Impulse aus den Erfahrungen von Dr. Janna Lipenkova ziehen konntest. Bist Du selber vielleicht schon im Rahmen der Produktentwicklung von AI Produkten aktiv? Was ist dabei für Dich anders? 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

Diesmal widmen wir uns dem Thema Künstliche Intelligenz (KI) und beleuchten, wie diese die Rolle des Product Owners transformieren kann. Tim und Oliver diskutieren die Chancen und Herausforderungen, die sich durch den Einsatz von KI-Tools im Produktmanagement ergeben. Künstliche Intelligenz ist mehr als nur ein Buzzword. Sie bietet Product Ownern die Möglichkeit, ihre Arbeitsweise zu revolutionieren. KI bietet nicht nur die Chance, Prozesse zu optimieren, sondern auch die Arbeitsweise in der Produktentwicklung grundlegend zu verändern. Dabei ist KI mehr als nur ChatGPT, auch wenn KI häufig mit Anwendungen wie ChatGPT gleichgesetzt wird. Machine Learning, Generative AI und spezialisierte Technologien wie Large Language Models (LLMs) sind nur einige Beispiele für die Bandbreite an Möglichkeiten. Tim erklärt, dass es wichtig ist, über ChatGPT hinauszublicken und andere KI-Anwendungen zu entdecken, die im Produktmanagement nützlich sein können. Im Gespräch werden zahlreiche Beispiele für den Einsatz von KI im Produktmanagement angesprochen: - Stakeholder-Kommunikation: KI kann bei der Erstellung von Release Notes unterstützen und Storytelling durch die Generierung von Bildern und Videos bereichern. - Produktstrategie und -vision: Mit KI-Tools lassen sich komplexe Dokumente wie der Amazon Six-Pager einfacher erstellen, indem die anfängliche Hürde des leeren Blattes überwunden wird. - Wettbewerbsanalyse: KI kann helfen, Nutzerrezensionen des Wettbewerbs auszuwerten, um Differenzierungsvorteile oder neue Feature-Ideen zu entdecken. - Datenanalyse: Mit KI können umfangreiche Datenmengen effizient analysiert werden, um wertvolle Insights zu gewinnen, z. B. durch die Auswertung von Hörstatistiken. Ein zentraler Punkt, den Tim hervorhebt, ist die Notwendigkeit, KI im Dialog zu nutzen. Es reicht nicht aus, nur gute Prompts zu schreiben. Vielmehr sollte KI wie ein Mitarbeiter behandelt werden, der Kontext und klare Anweisungen benötigt. So können KI-Tools effektiver genutzt werden und wertvolle Unterstützung bieten. Beim Einsatz von KI-Tools müssen Datenschutz und ethische Überlegungen berücksichtigt werden. Product Owner sollten sich aktiv dafür einsetzen, KI-Tools im Unternehmen nutzen zu dürfen, dabei jedoch stets die datenschutzrechtlichen Rahmenbedingungen beachten müssen. Abschließend zeigt die bisherige Erfahrung, dass KI-Tools die Arbeit von Product Ownern bereichern können. Es geht darum, KI als unterstützenden Assistenten zu sehen, der hilft, Aufgaben effizienter zu gestalten, ohne die menschliche Rolle zu ersetzen. Wenn ihr mehr hören wollt, empfehlen wir euch anschließend die Folge "Wie No-Code Tools Produktteams helfen". Ein paar nützliche Tipps zum Einsatz von KI im Sprint Review gab es in der Folge "Was macht ein gutes Sprint Review aus?". Tim hatte auch bereits im Januar 2023 ein "Interview" mit ChatGPT zur PO Rolle geführt - diese Episode hieß "Was weiß künstliche Intelligenz schon über Produktentwicklung?" Wie sieht es bei euch aus? Nutzt ihr schon KI-Tools in eurer Arbeit als Product Owner, Product Manager und Product Leads? Wir sind gespannt von euren Erfahrungen zu hören. Gerne hier als Kommentar, auf unserer LinkedIn-Page oder direkt als Mail an info@produktwerker.de.  Wie sieht es bei euch aus? Nutzt ihr schon KI-Tools in eurer Arbeit als Product Owner, Product Manager und Product Leads? Wir sind gespannt von euren Erfahrungen zu hören. Wir freuen uns, wenn du deine Meinung zu KI und deine Einschätzung für KI in der Produktentwicklung mit uns in einem Kommentar des Blog-Artikels (https://produktwerker.de/ai-als-wingman-fuer-product-owner/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker).

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.

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