Episoder
-
Diesmal dreht sich alles um das spannende Thema AI Tools für Produktmanagement. Tim Klein spricht mit Alexej Antropov, dem Entwickler des sogenannten KI-Radars. Dieses Radar bietet eine strukturierte Übersicht über die Vielzahl von KI-Tools im Produktmanagement und gibt damit eine gute Orientierung. Alexej erklärt, wie er aus seiner Erfahrung und intensiven Recherche diesen Überblick geschaffen hat, der Product Ownern und Produktmanagern einen tollen Marktüberblick der wichtigsten AI Tools in der schnelllebigen Welt der KI-Technologien gibt.Das KI-Radar ist so konzipiert, dass es nach Rollen und Anwendungsfällen in der Produktentwicklung strukturiert ist. Egal, ob man als Designer, Product Owner, Engineer oder im Team tätig ist – das Radar hilft, relevante Tools zu entdecken und deren Reifegrad einzuschätzen. Das Radar umfasst dabei nicht nur etablierte Anwendungen wie Microsoft Copilot, sondern auch experimentelle und vielversprechende Tools. Seine Motivation ist es, die Innovationskraft von Teams zu steigern und das Thema KI pragmatisch und praxisnah in den Arbeitsalltag zu integrieren.Im Gespräch hebt Alexej Antropov hervor, dass die Nutzung von KI-Tools seines Erachtens nicht nur die Effizienz erhöhen kann, sondern auch völlig neue Möglichkeiten eröffnet; etwa beim schnellen Erstellen von Prototypen oder der Analyse von Nutzerinterviews. Ein besonderer Fokus liegt dabei auf der Frage, wie Unternehmen das Potenzial von KI erschließen können, ohne sich in der Komplexität des Themas zu verlieren. Alexej empfiehlt eine iterative Herangehensweise: klein anfangen, experimentieren und lernen.Das Radar selbst ist ein dynamisches Projekt, das sich durch kontinuierliches Feedback (auch von euch!) und neu entdeckte Tools weiterentwickelt. Alexej sieht es als Community-Tool, das also auch durch Beiträge anderer Produktmenschen lebt. Datenschutz und die europäische Gesetzgebung sind für ihn wichtige Kriterien bei der Auswahl der Tools, was das Radar besonders für Unternehmen in der EU attraktiv machen dürfte.Wer sich als Produktmensch mit KI auseinandersetzt, hat die Chance, nicht nur effizienter im Produktmanagement zu arbeiten, sondern auch frühzeitig neue Kompetenzen zu entwickeln. Doch wie fängt man an mit KI zu nutzen? Alexej rät: Einfach Machen! Denn jeder muss irgendwo anfangen. Sein Tipp lautet daher: Geht das Thema einfach in eurem eigenen Tempo an, Hauptsache ihr beginnt damit. Das KI-Radar bietet hierfür eine wertvolle Orientierungshilfe und guten Startpunkt. Es lädt dazu ein, neugierig zu sein und die Möglichkeiten von KI aktiv zu nutzen.Wertvolle Quellen:- Das KI-Radar für Produktmanagement & Software-Entwicklung findet ihr in der jeweils aktuellen Fassung hier: https://www.beyondbacklog.de/p/das-ki-radar-fur-produktmanagement-und-software-entwicklung- Alexej hat sein KI Radar auch schon mal in einem sehr guten Talk (auf Englisch) vorgestellt. Zu diesem Talk findet ihr hier eine sehr gute und detaillierte Darstellung: https://www.beyondbacklog.de/p/product-tank-munich-orga-fitness-in-the-age-of-ai-tool-radar-web-product-development-dovetail-miro-juttu-claude-uizard- Miro im AI Einsatz (inkl. Link zum Prototyping) und den Post von Alexej dazu gibt es hier: https://www.beyondbacklog.de/p/auswerten-von-kunden-interviews-mit-miro-ai-guide-templateFolgende ältere Podcast-Episoden werden von Tim im Gespräch genannt, die super zu dieser Folge passen:- AI als Wingman für Product Owner- Produktentwicklung von AI Produkten- Wie No-Code Tools Produktteams helfen können- Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstütztWer weitere Fragen an Alexej hat oder ihm selber gute AI Tools für Produktmanagement empfehlen kann, die er noch nicht auf seinem Radar hat, erreicht ihn am besten über sein LinkedIn Profil (linkedin.com/in/alexejantropov/) oder per Mail: [email protected] Website und vor allem seinen Newsletter findet ihr unter beyondbacklog.de
-
Das Abbrechen eines Sprints ist ein seltenes, aber einschneidendes Ereignis im agilen Arbeiten. Aber wann ist es sinnvoll, einen Sprint abzubrechen, und was passiert danach? Obwohl Sprints selten abgebrochen werden, kann dies unter bestimmten Umständen hilfreich und richtig sein, um Zeit und Ressourcen zu sparen.
Ein zentraler Aspekt rund um die Idee einen Sprint abzubrechen ist die Rolle des Sprintziels. Wenn ein Sprintziel während des Sprints obsolet wird, sei es durch neue Erkenntnisse, technologische Hürden oder strategische Entscheidungen, ist dies ein klarer Grund für einen Sprintabbruch. Zum Beispiel kann eine Änderung auf Kundenseite dazu führen, dass eine zuvor geforderte Funktionalität gar nicht mehr benötigt wird. Oder es stellt sich während der Arbeit heraus, dass eine geplante technische Lösung so nicht umsetzbar ist. In solchen Situationen stehen Product Owner:innen in der Verantwortung, die richtige Entscheidung zu treffen. Schließlich hat nur er oder sie die Befugnis, einen Sprint abzubrechen.
Ein Sprintabbruch erfordert jedoch neben Mut auch eine durchdachte Kommunikation. Das Team und andere Stakeholder:innen müssen einbezogen werden, um die Situation zu bewerten und eine fundierte Entscheidung zu treffen. Dabei wird oft deutlich, dass Transparenz und Zusammenarbeit wichtig sind, um den nächsten Schritt zu planen. Nach dem Abbruch des Sprints gilt es dann gemeinsam zu analysieren, welche Arbeitsergebnisse weiterhin verwertbar sind und welche nicht. Eine Retrospektive hilft, die Arbeitsweise zu reflektieren und mögliche Verbesserungen zu identifizieren. Ein Sprintabbruch kann daher auch eine wertvolle Gelegenheit sein, innezuhalten und sich neu auszurichten. Eine klare Orientierung hilft, den nächsten Sprint effektiv zu planen und das Team auf die neuen Ziele einzustimmen.
Dominique und Oliver fragen sich in der Folge auch ob Sprints nicht oft genug abgebrochen werden. Oft fehlt es an klar definierten Sprintzielen oder der Fähigkeit, den Fortschritt während des Sprints zu messen. Diese Faktoren können dazu führen, dass Teams zu lange an Aufgaben festhalten, die nicht den richtigen Mehrwert für Nutzer:innen bieten.
Am Ende bleibt, dass es für Product Owner:innen essenziell ist, die Auswirkungen eines Sprintabbruchs zu berücksichtigen und die verbleibende Zeit sinnvoll zu nutzen. Der Abbruch eines Sprints ist kein Zeichen von Scheitern, sondern ein Schritt, der dabei hilft, den Fokus auf das Wesentliche zu richten.
-----------------
Ein Sprintabbruch ist selten. Daher interessiert es uns sehr, wie eure Erfahrungen dabei sind. Habt ihr bereits einen Sprint abgebrochen und was habt ihr dabei gelernt? Was könnt ihr anderen mit auf den Weg geben? Schreibt es gerne in den Kommentaren des zur Folge gehörenden Blogbeitrags (https://produktwerker.de/wann-breche-ich-einen-sprint-ab-und-was-mache-ich-danach/) oder auf LinkedIn (https://www.linkedin.com/company/produktwerker/). -
Mangler du episoder?
-
In dieser Folge geht's darum Konflikte mit Stakeholdern zu meistern. Konflikte sind im Produktmanagement fast unvermeidlich, da unterschiedliche Interessengruppen oft widersprüchliche Ziele verfolgen. Bernd Joussen, ein erfahrener Coach für Teamentwicklung und Konfliktmanagement (und zugleich auch Konflikt-Mediator), teilt im Gespräch mit Tim seine Einsichten darüber, wie Product Owner solche Spannungen und konfliktbeladenen Situationen erfolgreich handhaben können.
Ein Konflikt, so erklärt Bernd, entsteht, wenn zwei oder mehr Parteien unterschiedliche Interessen verfolgen und mit ihren Ansprüchen bzw. Erwartungshaltungen aufeinandertreffen. Er betont die Bedeutung einer bewussten Abgrenzung zwischen strukturellen und zwischenmenschlichen Konflikten. Während die einen oft aus widersprüchlichen Unternehmenszielen resultieren, etwa durch fehlende strategische Orientierung oder technische Limitierungen, betreffen die anderen eher persönliche oder teaminterne Spannungen.
In Organisationen gibt es typische Konfliktfelder, wie das Ringen um begrenzte Ressourcen oder unterschiedliche Prioritäten, etwa zwischen Marketing und Produktentwicklung. Solche Spannungen verschärfen sich oft, wenn Stakeholder ihre Interessen stark durchsetzen wollen. Hier können Product Owner ansetzen, indem sie eine Kultur der Empathie und des gegenseitigen Verständnisses fördern. Bernd empfiehlt das Johari-Fenster hierfür als hilfreiches Tool, das den Teammitgliedern dabei hilft, blinde Flecken aufzudecken und durch bewusstes Teilen eigener Bedürfnisse Vertrauen zu stärken.
Ein weiterer wertvoller Tipp von Bernd ist die sogenannte Konflikt-Map, ein visuelles Werkzeug, das die Beziehungen und Spannungen zwischen verschiedenen Akteuren anschaulich darstellt. Mit Blitzen und Pfeilen lassen sich so problematische Verbindungen oder Kommunikationslücken verdeutlichen. Diese Methode schafft Klarheit und hilft dem gesamten Team, Konfliktmuster zu erkennen und gezielt anzugehen.
Für Bernd ist es wichtig eine gesunde Streitkultur zu pflegen. Konflikte können das Team stärken, wenn sie konstruktiv geführt werden, denn sie bieten Raum für Innovation und Weiterentwicklung. Product Owner können diese Dynamik unterstützen, indem sie regelmäßig Feedback einholen und lernen, souverän mit Kritik umzugehen. Hierfür ist das Buch "Radical Candor" von Kim Scott hilfreich, das praxisnahe Ansätze für eine ehrliche und respektvolle Kommunikation vermittelt.
Als praxisnahen Tipp für alle, die ihre Zusammenarbeit verbessern wollen stellt Tim das „How-to-work-with-me“-Dokument vor. Hierbei handelt es sich um eine Art "Bedienungsanleitung für mich selbst", die persönliche Präferenzen und Bedürfnisse beschreibt, damit das Team besser auf mich (und meine Eigenarten und Erwartungshaltungen an den Umgang mit mir) eingehen kann. Dies stärkt nicht nur die Kommunikation, sondern kann auch helfen, potenziellen Konflikten präventiv entgegenzuwirken.
Diese Folge mit Bernd Joussen verdeutlicht, dass Konflikte mit Stakeholdern zum Alltag eines Product Owners gehören und nicht vermieden, sondern konstruktiv genutzt werden sollten. Ihr als Product Owner solltet euch daher nicht scheuen, externe Unterstützung durch Coaches oder Mediatoren wie Bernd hinzuzuziehen, um die Konfliktlösung zu erleichtern und die Zusammenarbeit im Team zu fördern.
Diese früheren Folgen werden in dieser Episode referenziert:
- Umgang mit schwierigen Stakeholdern
- Herausforderungen zwischen Product Owner und Developer (frühere Folge mit Bernd Joussen)
- Stakeholder Community
- Konflikte zwischen Scrum Master und Product Owner
Bernd empfiehlt im Gespräch folgende Tools und Bücher:
- Johari Fenster
- Conflict Map
- Birgit Schumacher: Psychologische Sicherheit
- Manfred Prior: MiniMax-Interventionen
- Kim Scott: Radical Candor
- Friedrich Glasl: Konfliktmanagement
- Market of Skills
Tim erwähnt noch das "How To Work With Me"-Manual. -
n dieser Podcastfolge widmen sich Oliver & Tim dem Thema Produktrisiken und beleuchten, welche Herausforderungen Product Owner im Hinblick auf die Risikobetrachtung meistern sollten. Jede Produktentwicklung beinhaltet Risiken mit denen man sich auseinandersetzen und bewusst mit ihnen umzugehen muss. Als Product Owner liegt es im Kern ihrer Verantwortung, mögliche Risiken frühzeitig zu erkennen und Strategien zu entwickeln, um diese zu minimieren.
Die beiden sprechen über die Einteilung von Produktrisiken in vier Kategorien: Usability-Risiken (Nutzbarkeit für den Kunden), Value-Risiken (Mehrwert für den Kunden), Business Viability-Risiken (wirtschaftliche Tragfähigkeit) und Feasibility-Risiken (Machbarkeit). Es ist entscheidend, als Product Owner ein Bewusstsein für diese unterschiedlichen Risikobereiche zu entwickeln. Das Verständnis der Kundenbedürfnisse und die fortlaufende Evaluation des Marktes helfen, mögliche Value-Risiken zu reduzieren. Denn nur ein Produkt, welches tatsächlich einen Mehrwert bietet, hat langfristig Bestand.
Bei den Business Viability-Risiken liegt der Fokus auf der wirtschaftlichen Tragfähigkeit des Produkts. Ein Produkt mag den Nutzern gefallen und technisch machbar sein, dennoch kann es an einem rentablen Geschäftsmodell scheitern. Es ist dabei von entscheidender Bedeutung, die strategische Ausrichtung des Unternehmens zu berücksichtigen und sicherzustellen, dass das Produkt langfristig den wirtschaftlichen Erfolg unterstützt.
Ein wichtiger Aspekt, der in dieser Folge angesprochen wird, ist die Notwendigkeit, über rein technische Risiken hinaus auch ethische Aspekte zu berücksichtigen. Hier kommen Tim und Oliver auf das sogenannte ethische Risiko zu sprechen, bei dem es darum geht, ob ein Produkt moralisch vertretbar ist und im Einklang mit den ethischen Grundsätzen der Organisation steht.
Kontinuierliche Product Discovery und die enge Zusammenarbeit mit Stakeholdern können dabei helfen, Produktrisiken frühzeitig zu identifizieren und durch gezielte Tests und Experimente zu mindern. Produktideen werden in der Entstehungsphase auf Annahmen geprüft und in Hypothesen überführt, um auf Basis der Ergebnisse Entscheidungen zu treffen, bevor es in die Product Delivery geht. Dabei kann die Zusammenarbeit in einem sogenannten „Product Trio“ aus Product Owner, Designer und Engineers wertvolle Perspektiven für die Risikobetrachtung eröffnen.
Diese Folge bietet praxisnahe Einblicke und viele anschauliche Beispiele, wie Product Owner im täglichen Umfeld Produktrisiken bewerten und Strategien entwickeln können, um Unsicherheiten zu managen und die Erfolgsaussichten ihrer Produkte zu steigern. -
Wie sieht die Jobsituation für Product Owner und digitale Produktmanager zum Ende des Jahres 2024 aus?
Tim spricht in dieser Episode mit Recruiting-Experte Denny Meier über die aktuelle Marktlage und die Trends für Product Owner und digitale Produktmanager. Denny Meier ist tief drin im Markt für Product Owner und Produktmanager, da er sich schon vor Jahren auf die Vermittlung und Suche von Festangestellten mit solchen Expertisen spezialisiert hat.
Denny taucht erstmal tief in die Zahlenwelt ein und bespricht mit Tim u.a., wie sich die Jobtitel und die Anforderungen in diesen Rollen verändern. Dabei geht es aber auch um die Entwicklung des Rollenverständnisses: weg von der reinen Verwaltung des Backlogs hin zu einem stärker wertorientierten Ansatz.
Ein weiterer Schwerpunkt der Folge liegt auf der Gehaltssituation und auch dem Gender Pay Gap: wie sehen die aktuellen Gehaltszahlen aus, und welche Unterschiede bestehen zwischen den Geschlechtern? Spannend ist dabei auch der Vergleich bzw. Entwicklung zur Gehalts- und Jobsituation für Product Owner im Jahr 2020, als Denny Meier schon mal in unserem Podcast zu Gast war.
Für Senior-Positionen zeigt Denny die zunehmende Bedeutung organisatorischer Themen, Führungskompetenzen und die auch Organisationsentwicklung bei der Suche nach Kandidatinnen und Kandidaten auf. Denny teilt auch Einblicke in die verschiedenen Branchen, die besonders stark nach Talenten suchen.
Abschließend gehen die beiden darauf ein, welchen Hintergrund die Leute in diesen Rollen häufig mitbringen und geben wertvolle Tipps für alle, die sich auf der Suche nach einer passenden Position im Produktmanagement befinden. Natürlich ist die Jobsituation für Product Owner und digitale Produktmanager derzeit etwas angespannter, aber gute Chancen gibt es für spannende Profile nach wie vor. Gute Leute werden halt irgendwie immer gesucht.
Auf diese früheren Folgen wird im Laufe der Episode verwiesen:
Sich als Product Owner auf die Bewerbung vorbereiten - Gast: Denny Meier
Der Arbeitsmarkt für Product Owner & Product Leader (Juli 2020) - Gast: Denny Meier
AI als Wingman für Product Owner
Sei dein eigenes Produkt! – Weiterentwicklung für Product Owner
Wenn ihr in den direkten Austausch mit Denny kommen wollt oder weitere Fragen habt, erreicht ihr ihn am besten über sein LinkedIn-Profil. Natürlich könnt ihr ihn auch gerne als suchendes Unternehmen oder als suchende Kandidatin bzw. Kandidat direkt via LinkedIn ansprechen. -
In dieser Folge des Produktwerker-Podcast dreht sich alles um Continuous Delivery aus der Perspektive eines Product Owners. Dominique und Oliver beleuchten die Unterschiede zwischen Continuous Integration, Continuous Delivery und Continuous Deployment und tauschen sich darüber aus, wie wichtig diese Praktiken auch für Produktmenschen sind, um kontinuierlich Mehrwert zu liefern. Continuous Delivery hingegen ermöglicht im Gegensatz zu früher üblichen umfangreichen Releases, kleinere Änderungen regelmäßig auszuliefern und diese frühzeitig in produktionsnahen Umgebungen zu testen.
Einer der wichtigsten Argumente für Continuous Delivery ist die Risikominimierung. Durch kontinuierliches Testen in Staging-Umgebungen lassen sich potenzielle Probleme frühzeitig erkennen und beheben, bevor sie live gehen. Dies erhöht nicht nur die Qualität, sondern schafft auch Sicherheit für den Product Owner und das Team. Dominique und Oliver diskutieren in diesem Kontext den Einsatz von Feature-Toggles, mit denen Funktionen gezielt für bestimmte Nutzergruppen aktiviert werden können, um Feedback zu erhalten und die Einführung neuer Features zu kontrollieren.
Durch Continuous Delivery wird der Übergang von der Entwicklung zur Auslieferung fließender und transparenter, was wiederum die Zusammenarbeit und Abstimmung mit Stakeholdern erleichtert. Continuous Delivery bekomme ich als Product Owner nicht geschenkt, es erfordert eine Investition in technische Infrastrukturm welche letztendlich die Produktqualität und die Liefergeschwindigkeit verbessert. Dabei sollte das Team regelmäßig reflektieren, wie viel Aufwand bei der Integration und Auslieferung erforderlich ist, um den Nutzen einschätzen zu können.
Continuous Delivery hilft somit, kontinuierlich wertvolle und getestete Produktinkremente bereitzustellen und ermöglicht es Product Ownern, flexibler auf Veränderungen zu reagieren und schneller auf die Bedürfnisse der Nutzer einzugehen. -
In dieser Folge geht es um die Herausforderungen und Chancen des Produktmanagements in regulierten Branchen. Tim spricht heute mit Deniz Dogan, Product Management Consultant bei den Product People, über die spezifischen Anforderungen, die auf Product Owner in regulierten Umfeldern zukommen.
Regulierung stellt natürlich häufig eine Hürde dar, weil sie viele Freiheiten während der Produktentwicklung einschränkt. Doch dies sollte nicht nur als Beschränkung gesehen werden. Vielmehr bietet die Gesetzeslage oft auch Spielraum, wie Regelungen umgesetzt werden, was Raum für kreative Lösungen schafft. Ein Beispiel in dieser Folge ist der Digital Services Act (DSA), bei dem zwar Vorgaben zu Transparenz und Meldemöglichkeiten erfüllt werden müssen, aber nicht festgelegt ist, wie dies genau zu geschehen hat. Hier zum Beispiel hat Deniz Dogan durch sorgfältige Analyse der Vorgaben und enge Zusammenarbeit mit dem Compliance-Team innovative Ansätze gefunden, um Anforderungen effizient zu erfüllen, ohne unnötigen Aufwand zu erzeugen.
Die enge Zusammenarbeit mit Compliance-Teams ist besonders wichtig, um das Produktmanagement in regulierten Branchen zu erleichtern. Deniz betont in dieser Folge, wie wichtig es ist, frühzeitig und proaktiv den Dialog mit diesen Abteilungen zu suchen. Oft wird aus Unsicherheit lieber ein konservativer Ansatz gewählt, der jedoch nicht immer nötig ist.
Indem Product Owner die gesetzlichen Rahmenbedingungen genau verstehen und kritisch hinterfragen, können sie unnötige Aufwände vermeiden und gleichzeitig rechtskonform bleiben. So wird aus einem vermeintlichen Hindernis eine Gelegenheit für Produktverbesserungen und damit eine echte Chance.
Besonders in regulierten Branchen zeigt sich zudem, dass Vorschriften oft nicht eindeutig sind, was Raum für Interpretation lässt. Dies führt zu Ambiguität, die zwar zusätzliche Komplexität schafft, aber auch Gestaltungsspielräume eröffnet. Dies bietet eine Chance, Wettbewerbsvorteile zu erzielen, indem Unternehmen die Anforderungen nicht nur erfüllen, sondern die Art wie sie die Erfüllung dieser Regulation meistern zu einem Selling Point machen. Ein Beispiel hierfür ist die Barrierefreiheit, bei der sich Unternehmen durch besonders proaktive Maßnahmen im Markt differenzieren können.
Letztlich kommt es darauf an, als Product Owner nicht nur die Vorschriften zu erfüllen, sondern den Mehrwert darin zu erkennen, wie ein Produkt dadurch besser und sicherer gestaltet werden kann. Wer bereit ist, die Regeln genauer unter die Lupe zu nehmen und in den Dialog mit den richtigen Stakeholdern zu gehen, kann auch in streng regulierten Märkten innovativ agieren und sich einen Vorsprung verschaffen.
Im Produktmanagement in regulierten Branchen geht es also nicht nur darum, sich an Gesetze zu halten, sondern diese auch als Chance zu nutzen, Produkte nachhaltig besser zu machen.
Diese früheren Folgen werden in dieser Episode referenziert:
- Guerilla Discovery - wenn der Kontext Product Discovery nicht aktiv unterstützt
- Barrierefreiheit von digitalen Produkten
- Umgang mit schwierigen Stakeholdern
Wer weitere Fragen an Deniz hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über die Product People (getproductpeople.com).
Von Deniz Dogan gibt es zudem auch ein englisches Webinar der Product People auf YouTube zum Thema ”Product Management in regulated industries: Navigating the Digital Service Act”.
Wir hoffen, dass du einige neue Impulse zum Thema reguliertes Umfeld aus den Erfahrungen von Deniz Dogan ableiten konntest. Bist du selber vielleicht auch im Produktmanagement und von Regulation betroffen? Wenn du deine Tipps und Erfahrungen aus der Praxis mit den anderen Hörerinnen und Hörern teilen möchtest, dann hinterlasse gerne einen Kommentar unterm Blog-Artikels oder auf unserer Produktwerker LinkedIn-Seite. -
In dieser Folge dreht sich alles um das Arbeiten als Product Owner im Home Office. Seit der Corona-Pandemie ist Home Office für viele POs zur Normalität geworden, was sowohl Chancen als auch Herausforderungen mit sich bringt. Oliver und Dominique diskutieren, wie sich die Verantwortung eines Product Owners durch die veränderten Arbeitsbedingungen verschoben hat und welche Auswirkungen dies auf die tägliche Arbeit hat.
Eine der größten Veränderungen betrifft die Kommunikation besonders mit dem eigenen Team. Obwohl die virtuelle Kommunikation via Slack oder Videokonferenzen viele spannende Möglichkeiten bietet, gibt es Aspekte, die im Home Office schwerer umsetzbar sind. Spontane Gespräche oder das schnelle „Zurufen“ einer Frage im Teamraum vor Ort fehlen, was den Austausch im Team verlangsamen kann. Product Owner müssen darüber hinaus darauf achten, dass trotz Remote-Arbeit keine wichtigen Informationen verloren gehen. Andererseits bietet das Home Office aber auch einige Vorteile: Die Flexibilität ermöglicht es, sich besser auf bestimmte Aufgaben zu fokussieren und tiefere, ungestörte Arbeit zu leisten.
Eine weitere kommunikative Herausforderung ist es, die Beziehung zu den Stakeholdern zu pflegen. Im Büro gibt es diverse Möglichkeit sich informell auszutauschen – etwa an der Kaffeemaschine – während im Home Office solche Gelegenheiten fehlen. Hier sind kreative Ansätze gefragt, um den Kontakt nicht nur formell, sondern auch auf einer persönlichen Ebene aufrechtzuerhalten. Ein „Stakeholder-Daily“ könnte beispielsweise helfen, die Entscheidungsprozesse zu beschleunigen, indem regelmäßige kurze Meetings stattfinden.
Doch Arbeiten im Home Office bietet nicht nur Hürden, sondern auch einige neue Chancen. Product Owner können durch die zunehmende Flexibilität Jobmöglichkeiten im gesamten deutschsprachigen Raum, oder sogar darüber hinaus, wahrnehmen. Zudem verbessern digitale Tools wie Miro oder Confluence die Zusammenarbeit und die Dokumentation. Das Arbeiten im virtuellen Raum ermöglicht es, transparenter zu agieren und Prozesse effizienter zu gestalten.
Ein großer Vorteil des Home Offices ist auch die Möglichkeit, den eigenen Arbeitsrhythmus flexibler zu gestalten. Product Owner können tiefer in Aufgaben eintauchen, ohne von äußeren Faktoren im Büro abgelenkt zu werden. Auf eines sollte man aber achten: Die klare Trennung zwischen Arbeit und Privatleben fällt oft schwer, besonders wenn man nicht in einem separaten Arbeitszimmer, sondern vielleicht am Küchentisch arbeitet.
Insgesamt gibt diese Folge praktische Tipps, wie du die Herausforderungen des Home Offices meistern kannst. Als PO solltest du deinen Arbeitsalltag aktiv gestalten und nicht einfach nur den Umständen ausgeliefert sein. -
In der aktuellen Folge des Produktwerker-Podcasts dreht sich alles um ein spannendes Thema für Product Owner: die Progress Design Map. Tim hat erneut den Experten Peter Rochel von UXTO zu Gast, der zusammen mit seinem Team eine Weiterentwicklung des klassischen Value Proposition Canvas vorstellt. Mit der Progress Design Map will UXTO den Jobs-to-de-Done Prozess auf ein neues Level heben, indem die Herausforderungen und Grenzen des Value Proposition Canvas im Rahmen des "Wheel of Progress" angegangen werden.
Peter gibt zunächst eine kurze Einführung in das Jobs-to-be-Done-Konzept, das in der Produktentwicklung dafür sorgt, die Bedürfnisse und Aufgaben der Kunden besser zu verstehen. Wie Peter erklärt, war das Value Proposition Canvas bislang zwar ein guter Anfangspunkt, aber in der Praxis stößt es oft an seine Grenzen. Besonders bei der Frage, wie ein Produkt über verschiedene Entwicklungsphasen hinweg optimal gestaltet und am Markt positioniert werden kann, hatte der Canvas Schwächen gezeigt.
Hier setzt die Progress Design Map an. Sie ist speziell darauf ausgelegt, die Erkenntnisse aus Kundeninterviews und der kontinuierlichen Marktforschung zu strukturieren und direkt in die Produktentwicklung einzubringen. Im Gegensatz zum herkömmlichen Value Proposition Canvas berücksichtigt die neue Methode die fünf unterschiedlichen Phasen, die ein Kunde durchläuft – die Passive Suche, Aktive Suche, Entscheidung, Erste Nutzung und Wiederholte Nutzung.
Peter Rochel erklärt, dass es darum geht, gezielt zu entscheiden, welche Features und Funktionen in welchem Entwicklungsstadium des Produkts priorisiert werden. Statt wahllos alles zu entwickeln, liegt der Fokus darauf, die wertvollsten Fortschritte für den Kunden zu erzielen und dabei nicht unnötig Ressourcen zu verschwenden. Gerade in den frühen Phasen, so Peter, sei es wichtig, den Kunden nicht mit zu vielen Details zu überfordern. Erst wenn ein konkreter Bedarf erkennbar ist, wird das Produkt sukzessive weiterentwickelt.
Tim und Peter diskutieren auch die Bedeutung von Ereignissen, die das Kundenverhalten beeinflussen. Sie sprechen über die "limitierenden Kontexte", in denen ein Produkt genutzt wird, und wie diese den Entwicklungsprozess beeinflussen sollten. Peters Beispiel hier ist die Nutzung einer App für urbane Mobilität bei schlechtem Netzempfang oder Regen. Hier wird schnell klar, dass es nicht nur um technische Features geht, sondern darum, wie diese in spezifischen Nutzungsszenarien wirklich einen Fortschritt für den Nutzer bringen.
Ein gutes Problemverständnis ist entscheidend, um nicht nur Produkte, sondern echte Lösungen zu liefern. Peter plädiert dafür, frühzeitig Feedback von echten Nutzern zu sammeln und dieses gezielt in die Weiterentwicklung einfließen zu lassen. So wird vermieden, dass sich ein Backlog mit irrelevanten Features füllt, die später mühsam wieder aussortiert werden müssen.
Für alle, die tiefer in das Thema einsteigen möchten, empfiehlt Peter die Nutzung der Progress Design Map, welche bald unter Creative Commons frei verfügbar ist. Es ist ein starkes Werkzeug, um die komplexen Zusammenhänge im Innovationsprozess besser zu strukturieren und als Team effizienter zu arbeiten. Die Progress Design Map ist ein Schritt in Richtung einer noch nutzerzentrierteren und datengetriebenen Arbeitsweise. Hört rein und erfahrt, wie ihr eure Produktentwicklung optimieren und eure Produkte noch erfolgreicher machen könnt!
Die frühere Folge zur "Jobs-to-be-Done" Methode mit Gast Peter Rochel findet ihr hier:
- Mit "Jobs to Be Done"-Interviews zum besseren Kundenverständnis
Wir hoffen, dass du einige neue Impulse zum Thema Kundenverständnis aus den Erfahrungen von Peter Rochel ableiten konntest. Bist du selber vielleicht auch aktiv in der Nutzung des Value Proposition Canvas? Dann schau dir mal die Progress Design Map als spannende Weiterentwicklung an. -
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 [email protected].
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? - Se mer
