Felix Rink im Gespräch mit Oliver Die Frage nach einem konkreten Liefertermin für ein bestimmtes Feature begegnet uns als Product Owner immer und immer wieder. Aber wie steht es eigentlich generell mit einer Vorhersagbarkeit in der agilen Produktentwicklung? Dazu sprechen Oliver und Felix Rink, Kanban Coach und Trainer bei ProKanban.org. Die mit Augenzwinkern gemeinte Aussage "Wann ist das Feature fertig? Keine Ahnung, wir sind ja agil!" hat aber durchaus einen ernsten Hintergrund. Denn nach subjektivem Gefühl der beiden findet man eine solche Einstellung durchaus häufiger in der Praxis. Und manchmal kann man den Eindruck gewinnen, dass die agile Community sich generell mit Vorhersagbarkeit in komplexen Umfeldern schwer tut. Felix Rink erklärt, warum er es trotzdem wichtig findet, dass gerade ein Product Owner in der Lage sein sollte, eine verständliche Aussage auf Fragen nach Lieferterminen von Features geben zu können. Anschließend klären Oliver Winter und Felix Rink Hintergründe, worin das Problem liegt, wenn Dinge einfach nun mal so lange dauern wie sie dauern. Und natürlich hat Felix auch eine Lösungsidee mitgebracht. Sich durch Messungen und Analysen Transparenz über die eigene Leistungsfähigkeit zu schaffen, wird auch bei der Vorhersagbarkeit unterstützen. Dabei können bestimmte Flow Metriken hilfreich sein. Wie immer endet die Podcastfolge mit konkreten Tipps und Tricks. In der Episode erwähnte Podcast-Folgen • Assumption Mapping • Kennt Kanban Product Owner? Um mit Felix Rink Kontakt aufzunehmen, um ggf. weitere Fragen zu klären, erreicht man ihn am einfachsten über sein LinkedIn-Profil. Welche Erfahrung hast Du mit dem Thema dieser Podcastfolge gemacht? Wie gehst Du mit Nachfragen zu konkreten Lieferterminen von Seiten der Stakeholder um? 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 Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver & Dominique im Gespräch Fast schon nur am Rande empfehlen wir euch auch die Folge zu "Sei dein eigenes Produkt!", in der Dominique von seinem Weiterentwicklungsansatz für Product Owner spricht. -> https://produktwerker.de/sei-dein-eigenes-produkt/ Als weiterführende Literatur können wir übrigens das Buch "Überzeugt!" von Jack Nasher empfehlen. Hier finden sich viele hilfreiche Hinweise und Tipps dazu, wie man im Allgemeinen kompetenter auftritt. -> https://jacknasher.com/publikationen/

Jürgen Meurer im Gespräch mit Tim Was hat Event Storming mit dem Bullshit-Asymmetrie-Prinzip (auch bekannt als "Brandolinis Gesetz") zu tun? Diese und noch viel wichtigere Fragen, besprechen wir in dieser Podcast-Folge mit Jürgen Meurer. Event Storming ist eine Praktik, die ursprünglich aus dem Domain Driven Design (DDD) stammt. Die Erfindung der Methode wird Alberto Brandolini zugeschrieben. Ja genau - der mit dem gleichnamigen Gesetz: „Das Widerlegen von Schwachsinn erfordert eine Größenordnung mehr an Energie als dessen Produktion.“ Zurück zum Thema: Event Storming ist ein (Groß)Gruppenformat, um das verteilte Wissen über eine fachlich-technische Domäne in einem Workshop explizit zu machen und so ein "gemeinsam geteiltes mentales Modell" zu entwickeln. Kurz: alle die dabei waren kapieren den Gesamtzusammenhang der Fragestellung plötzlich viel besser. Gerade im Kontext komplexer Produktentwicklung eignet sich diese Methode somit sehr gut, ein gemeinsames Verständnis zu schaffen. Sie kann damit eine tolle Grundlage für Story Mapping oder Customer Journey Mapping bieten - aber auch für die Erstellung klassischer Projekt Strukturpläne. Du kannst Event Storming sowohl für bestehende Produkte anwenden, als auch in der Entwicklung komplett neuer Produkte und Services einsetzen. Jürgen Meurer, setzt diese Methode bereits seit vielen Jahren erfolgreich bei seinen verschiedenen Arbeitgebern an. Inzwischen ist Jürgen als Agile Coach aktiv, hat aber auch lange als Product Owner und Scrum Master gearbeitet. Damit ist er übrigens auch ein interessantes Beispiel für den Weg, sich vom Product Owner zum Scrum Master bzw. Agile Coach zu entwickeln. Seine letzten Stationen waren Studitemps, Freeyou, AXA und nun SHOP APOTHEKE bzw. Redcare Pharmacy. Quellen und Links zum Event Storming Jürgen Meurer empfiehlt die folgenden Quellen, um mehr über Event Storming zu lernen: zentrale Webseite zum Thema: eventstorming.com Buch von Alberto Brandolini (online verfügbar): Introducing EventStorming - An act of Deliberate Collective Learning Brandolinis Gesetz, auch Bullshit-Asymmetrie-Prinzip genannt Weitere Themen zu bestimmten Podcast-Folgen, auf die Tim im Laufe des Gesprächs hinweist: Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Mit Customer Journey Maps arbeiten Jürgen Meurer freut sich über den Kontakt zu euch. Für weitere Fragen rund um das Thema und zu seinen Erfahrungen erreicht ihr ihn am besten auf seinem LinkedIn-Profil. Kanntest du Event Storming bereits vorher? Hast du eventuell selbst schon mal an einer solchen Session teilgenommen? 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 Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Tim & Oliver diskutieren Assumption Mapping in der Produktentwicklung. Sie betonen die Notwendigkeit, Annahmen zu hinterfragen und experimentelles Lernen zu fördern. Der Umgang mit Unsicherheiten, die Priorisierung von Hypothesen und die Bedeutung von Discovery und Problemverständnis werden erklärt. Assumption Mapping hilft, Risiken zu kommunizieren und Misserfolge zu vermeiden.

Silke Kanes im Gespräch mit Tim Wie blickt ein Vorstand auf die Verantwortlichkeit eines Product Owners? Wie kann Product Ownern eine gute Zusammenarbeit mit dem Vorstand gelingen? Diese und weitere Fragen diskutieren Silke Kanes, Vorständin Produkte bei der Scopevisio AG, und Tim in dieser Podcastfolge. Die Ansichten von Silke bringen eine weitere, äusserst bereichernde Perspektive auf die Aufgaben der Product Owner Rolle und agiler Produktmanager. Zunächst mal geht es um die Erwartungen des Vorstands an die Rolle von Produktverantwortlichen. Dabei gibt es durchaus auch die Aufgabe, dem Vorstand die PO-Rolle zu erklären bzw. ein Verständnis für sie zu entwickeln. Silke Kanes hat selber durch ihre lange Karriere in Produktpositionen (aber auch in einigen anderen Bereichen) viel in der Zusammenarbeit mit Vorständen gelernt und zugleich auch Product Owner in ihrem Umfeld entwickelt. Daher hat sie auch interessante Tipps, auf welche Art ein Product Owner mit den fraglichen Themen bis zum Vorstand durchdringen kann. Tim und Silke besprechen weiterhin das Thema, wie man am klug mit dem Vorstand kommuniziert? Letztlich fällt die Herausforderung zur Zusammenarbeit mit dem Vorstand in den Bereich des Stakeholder Managements. Hier müssen Product Owner und Produktmanager einfach fit sein und viele Erfahrungen sammeln, um mit ihren Anliegen durchzudringen. Weitere Podcastfolgen, auf die Silke und Tim im Laufe des Gesprächs zu sprechen kommen: Stakeholder Community Mit Storytelling andere von deinen Produktideen überzeugen Data-Fluent Product Manager Silke Kanes freut sich über den Kontakt zu euch. Für weitere Fragen oder Anliegen erreicht ihr sie am besten auf LinkedIn. Folgt ihr dort auch gerne. Ansonsten bietet ihre persönliche Homepage (silkekanes.com) mit ihrem Blog auch einen schönen Blick "hinter die Kulissen" ihres spannenden Werdegangs. Welche Erfahrungen hast du in der Zusammenarbeit zwischen Vorstand und Product Owner gemacht? Uns interessiert hier sowohl die Sichtweise der POs als auch von Führungskräften. 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 Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> [https://bit.ly/3Why63K]

Oliver & Dominique im Gespräch In dieser Folge wurde auf folgende Quellen verwiesen: Das Product Ownership Evolution Modell (https://productownership.de/poem/) Delegation Poker (https://management30.com/practice/delegation-poker/)

Büşra Coşkuner im Gespräch mit Oliver Als Produktmanagerin und Product Ownerin sollte ich die relevanten Daten zu meinem Produkt kennen. Und diese Daten dann für die Entscheidungsfindung heranziehen. Oliver hat sich in dieser Podcast-Folge die Product Management Coach und Trainerin Büşra Coşkuner eingeladen, um in das Thema Data-Fluent Product Manager, gute Metriken und hilfreiche Frameworks einzutauchen. Zu Beginn des Gesprächs reflektieren die beiden, dass Entscheidungen nach ihren Erfahrungen in der Produktentwicklung in der Regel noch zu sehr aus dem Bauch heraus getroffen werden. Daten können dabei helfen, die Qualität von Entscheidungen zu verbessern. Allerdings sollte ich als PO nicht in die Falle laufen, zu viele Daten zu sammeln, sondern mich auf die wirklich relevanten Daten zu konzentrieren. Die Beschäftigung mit Frameworks kann ein Startpunkt sein, die Sprache der Daten zu erlernen - spricht ein Data-Fluent Product Manager zu werden. So kann ich Kommunikation verändern und bei meinen Stakeholdern Vertrauen schaffen. Denn Wissen führt ihrer Meinung nach zu Vertrauen. Wie immer schließt die Folge mit ganz praktischen Tipps und Tricks von unserer Gesprächspartnerin. Falls Du mit Büşra Kontakt aufnehmen oder ihr folgen möchtest, kannst Du Dich über ihr LinkedIn Profil mit ihr verbinden. Sie schreibt regelmäßig auf LinkedIn und hat auch einen sehr guten Blog zu diversen Themen für Product Manager.

Tim und Dominique im Gespräch Der Produktschnitt im Kontext der agilen Organisationsentwicklung bezieht sich auf die Aufteilung der Teams rund um die Entwicklung eines Produkts oder einer Produktlinie. Es geht darum, die Teams so zu strukturieren, dass sie effektiv und effizient zusammenarbeiten können, um die Produktentwicklung voranzutreiben. Durch eine kluge Aufteilung der Verantwortlichkeiten wird sichergestellt, dass jedes Team über eine klare Aufgabe verfügt und seine Expertise in diesem Bereich entwickeln kann. Der Produktschnitt spielt eine entscheidende Rolle bei der Förderung agiler Prinzipien und der Maximierung des Produkterfolgs. Durch die Aufteilung der Teams nach Produkten, Produktkomponenten oder Kundensegmenten wird eine hohe Spezialisierung ermöglicht. Jedes Team kann sich auf seinen zugewiesenen Bereich konzentrieren und ein tiefes Verständnis entwickeln, was zu schnelleren und effizienteren Ergebnissen führt. Gleichzeitig fördert der Produktschnitt die Zusammenarbeit zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Genauso kann sich dies aber auch gegenteilig auswirken, wenn zu große Abhängigkeiten zwischen den Teams entstehen. Ansätze für den Produktschnitt Es gibt verschiedene Ansätze zur Aufteilung der Teams im Produktschnitt, die je nach den Anforderungen und Gegebenheiten der Organisation gewählt werden können. Eine Möglichkeit besteht darin, die Teams nach Produktkomponenten oder den Schritten eines Transaktionsprozesses zu strukturieren. Jedes Team ist dann für einen bestimmten Teil des Produkts verantwortlich und trägt die Verantwortung für dessen Entwicklung und Verbesserung. Eine andere Option besteht darin, die Teams nach Kunden- oder Marktsegmenten oder Regionen zu gliedern, sodass jedes Team auf die Bedürfnisse und Anforderungen einer bestimmten Zielgruppe spezialisiert ist. Eine dritte Möglichkeit ist die Aufteilung nach spezifischen Funktionen, bei der jedes Team bestimmte Aufgaben oder Funktionen übernimmt, unabhängig vom Produkt oder Kundensegment. Die Teamstruktur im Rahmen des Produktschnitts hat viele Vorteile. Einer der wichtigsten Vorteile ist, dass die Teams sich auf spezifische Bereiche fokussieren und ein tiefes Verständnis für diese entwickeln können. Dadurch können sie effektiver arbeiten und spezifischer einen ganz bestimmten Teil des Produkts verbessern, da sie sich auf ihre spezielle Expertise und ein tiefes Nutzerverständnis konzentrieren können. Gleichzeitig erfordert der Produktschnitt die Zusammenarbeit und den Wissensaustausch zwischen den Teams, um sicherzustellen, dass die verschiedenen Teile des Produkts gut aufeinander abgestimmt sind. Die Wahl der geeigneten Teamstruktur hängt von verschiedenen Faktoren ab, wie zum Beispiel der Komplexität des Produkts, den Anforderungen der Kunden und den vorhandenen Ressourcen. Es ist wichtig, die Teamstruktur kontinuierlich zu evaluieren und anzupassen, um sicherzustellen, dass die Teams effektiv arbeiten und dass das Produkt schnell und effizient entwickelt wird. Ein Produktschnitt kann bei der agilen Produktentwicklung viele Vorteile bringen, aber es gibt auch einige mögliche Probleme, die bei der Implementierung auftreten können. Eine große Herausforderung besteht darin, die Abhängigkeiten zwischen den verschiedenen Teams zu managen. Wenn die Teams unabhängig voneinander arbeiten, kann es zu Verzögerungen kommen, wenn eines der Teams nicht rechtzeitig fertig wird oder auf die Arbeit eines anderen Teams angewiesen ist. Ein weiteres Problem ist die Komplexität der Koordination, insbesondere bei größeren Produkten oder Organisationen. Es ist wichtig, effektive Kommunikations- und Koordinationsmechanismen zu etablieren, um sicherzustellen, dass alle Teams auf dem gleichen Stand sind und effektiv zusammenarbeiten können. Ein weiteres mögliches Problem ist die Gefahr der Silo-Bildung. Wenn die Teams zu stark in ihre spezifischen Bereiche eingebunden sind, kann dies dazu führen, dass sie isoliert voneinander arbeiten und wenig Einblick in die Arbeit der anderen Teams haben. Dies kann die Zusammenarbeit und den Informationsaustausch beeinträchtigen und zu ineffizienten Prozessen führen. Um dem entgegenzuwirken, ist es wichtig, den Fokus auf die Gesamtvision des Produkts zu halten und Mechanismen zu schaffen, die eine enge Zusammenarbeit und den Austausch von Informationen zwischen den Teams fördern. Zum Thema dieser Episode passt auch diese Folge sehr gut: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Kurz nach unserer Veröffentlichung ist gerade ein anderer deutschsprachiger Podcast, der SoftwareArchitekTOUR-Podcast, über fachliches Schneiden mittels Domain Driven Design (DDD) erschienen. Hier erfolgt die Betrachtung aus eher aus technischer Sicht von erfahrenen Software-Architekten: Episode 93: Domain-driven Transformation – Mit DDD Legacy-Systeme transformieren Welche Erfahrung habt ihr schon mit den verschiedenen Teamstrukturen in der Produktentwicklung gemacht? Waren sie positiv oder gab es Probleme? 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 Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Nader Fadl im Gespräch mit Tim Fake Door Tests werden genutzt, um das Interesse und die potenzielle Nachfrage für ein Produkt zu testen, bevor es tatsächlich entwickelt oder eingeführt werden. Letztlich kann dies ein entscheidender Schritt zum Problem-Solution-Fit sein. Tim hat mit Nader Fadl einen Experten zu Gast, der in dem Themenfeld promoviert sowie als Dozent für Markenkommunikation und Marketing Analytics aktiv ist. Nader geht somit von der wissenschaftlichen Seite an Methoden des User Testing heran, zugleich aber auch als Praktiker. So hat er mit seinem StartUp experial durch den Einsatz von No-Code und KI eine stark vereinfachte und schnelle Möglichkeit zur Umsetzung von Fake Door Tests geschaffen. Falls ihr diese Testing-Methode noch nicht kennt: Bei Fake Door Tests wird quasi eine "falsche Tür" erstellt, wie zum Beispiel eine eigene Landing Page oder ein Menüpunkt, Teaser o.ä. in bestehenden Apps oder Webseiten, die jeweils das Produkt oder die Dienstleistung bewerben. Potenzielle Kunden können auf diese "Tür" klicken oder reagieren, und basierend auf ihrem Verhalten und Feedback wird entschieden, ob es sich lohnt, das Produkt oder die Dienstleistung tatsächlich zu entwickeln. Es ist also Teil der Product Discovery, um dem Value Risk zu begegnen (hierzu haben sind in diesem Podcast bereits verschiedene Episoden erschienen). Es ermöglicht Unternehmen somit, wertvolle Informationen zu sammeln, um fundierte Entscheidungen zu treffen und Ressourcen effizient einzusetzen. Folgende Podcast-Episoden passen zu diesem Thema: Kontinuierliche Product Discovery in Teams etablieren Welche Rolle Product Discovery in der Arbeit von Product Ownern spielen sollte Wer weitere Fragen an Nader Fadl hat oder von ihm bei der Durchführung schneller Experimente unterstützt werden möchte, kann mit ihm am Besten via LinkedIn, per Mail (nader@experial.ai) oder über die Webseite experial.ai in Kontakt treten. Oder ihr folgt seinem StartUp experial auf LinkedIn. Welche Erfahrung habt ihr schon mit Fake Door Tests gemacht? Scheiten sie bei euch auch meist an der Umsetzungsdauer? Man redet vielleicht drüber, setzt sich aber am Ende dann doch nicht ein und vertraut auf sein Bauchgefühl? 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 Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (u.a. mit Hinweisen auf Konferenzen, Empfehlungen, Terminen für unsere kostenfreien Events usw.) -> https://bit.ly/3Why63K

Dominique und Tim im Gespräch In dieser Folge referenzieren wir folgende Folgen: Produktmanager im Startup – ein Erfahrungsbericht (https://produktwerker.de/produktmanager-im-startup/) Fähigkeiten sehr guter Product Owner (https://produktwerker.de/fahigkeiten-eines-po/) Seine Stakeholder kennen und richtig analysieren (https://produktwerker.de/stakeholder-analysieren/) Sei dein eigenes Produkt! (https://produktwerker.de/sei-dein-eigenes-produkt/)