Die Produktwerker

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:

Folgende ältere Podcast-Episoden werden von Tim im Gespräch genannt, die super zu dieser Folge passen:

Wer weitere Fragen an Alexej hat oder ihm selber gute AI Tools für Produktmanagement empfehlen kann, die er noch nicht auf seinem Radar hat, erreicht ihn am besten über sein LinkedIn Profil oder per Mail: [email protected].

Seine Website und vor allem seinen Newsletter findet ihr unter beyondbacklog.de

Wir hoffen, dass du einige neue Impulse für deine Arbeit im Produktmanagement rund ums Thema AI Tools aus den Erfahrungen von Alexej Antropov mitnehmen konntest. Welche KI Tools nutzt du selber und für was setzt du sie ein? 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.

Folgt uns Produktwerkern auf

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/).

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:

Bernd empfiehlt im Gespräch folgende Tools und Bücher:

Tim erwähnt noch das "How To Work With Me"-Manual, welches auf der Idee von Claire Hughes Johnson ("How to work with Claire") basiert. Weitere Erklärungen gibt's hier.

Wer weitere Fragen an Bernd Joussen hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil oder über seine Webseite (der-teamdynamo.de).

Wir hoffen, dass du einige neue Impulse zum Thema Konflikte mit Stakeholdern aus den Erfahrungen von Bernd Joussen ableiten konntest. Welche typischen Konflikte mit Stakeholdern hast du selber und wie gehst du damit um? 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.

Folgt uns Produktwerkern auf

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:

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.

Wir hoffen, dass du wichtige Anstöße und Infos aus den Erfahrungen, die Denny Meier mit uns geteilt hat, ableiten konntest. Wie guckst du aktuell auf den Jobmarkt für Product Owner und Produktmanager? Wir Produktwerker freuen uns, wenn du deine Gedanken zu diesem Thema mit uns und den anderen Hörerinnen und Hörern teilst. Welche Info hat dich besonders überrascht oder was siehst du anders? 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.

Folgt uns Produktwerkern auf

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:

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.

Von Deniz Dogan gibt es zudem auch ein englisches Webinar der Product People 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.

Folgt uns Produktwerkern auf

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 Solutions 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:

Wenn du weitere Fragen an Peter Rochel hast oder mit ihm in Kontakt treten möchtest, erreichst du ihn ganz einfach über sein LinkedIn-Profil.

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. 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.

Folgt uns Produktwerkern auf

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 Nutzerinnen 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 Entwicklerinnen über Support-Teams bis hin zu Stakeholder:innen – auf den gleichen Wissensstand gebracht werden. Oft gibt es während eines Releases eine Downtime, die Nutzerinnen vorher mitgeteilt werden muss. Hierbei sollte der Zeitpunkt für das Release so gewählt werden, dass möglichst wenige Nutzerinnen 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. :-)