Die Produktwerker

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

Johannes Geske im Gespräch mit Tim Wie bitte? In nur wenigen Wochen von der Idee zur Marktreife eines Produkts? Wie soll das denn bitte gehen? Tim hat Johannes Geske als Gast dazu eingeladen, denn er hat als Product Owner im Kundenauftrag für eine weltweit aktives B2B Unternehmen gezeigt, wie sowas mit streng hypothesen-getriebenem Vorgehen gelingen kann. In nur drei Sprints wurde durch iterativ-inkrementelles Vorgehen im Zusammenspiel mit intensiver Product Discovery ein release-fähiges Produkt für rund 15.000 Kunden des Auftragnehmers geschafften. Das Scrum Team von Johannes Geske war allerdings zuvor schon komplett eingespielt und in der Zusammenarbeit entsprechend erfahren, so dass es hier keine Lernkurve der Teamentwicklung gab, sondern der komplette Fokus auf ein schnelles Lernen durch Feedback gelegt werden konnte. Johannes nennt solch ein Setup "Plug & Play Scrum Team". Konkret wurden durch das Team einige Hypothesen bereits während jedes Sprints durch Kundenbesuche und unmittelbares User-Feedback zum Produkt Inkrement verifiziert bzw. eben auch einige falsifiziert. Letzteres ist eigentlich besonders "schön", denn diese Ideen muss man dann ja auch gar nicht umsetzen und vermeidet Verschwendung. In seinem Erfahrungsbericht spricht Johannes Geske über die Learnings dieses Vorgehens, wie z.B. klare Problem-Fokussierung, wie Vertrauen beim Kunden für dieses Vorgehen erworben wurde sowie die Festpreis-Beauftragung je Sprint durch den Kunden, d.h. z.B. auch die Go/NoGo-Entscheidung nach jedem Sprint. Für alle, die sich Details in Ruhe durchlesen wollen, hat Amazing Outcomes eine vom Kunden freigegebene Case Study erstellt. Diese gibt's hier: https://amazing-outcomes.de/de/what-we-offer/plug-and-play-scrum-team-fuer-ihr-projekt Mehr über Johannes Geske und sein Team erfahrt ihr auf der Webseite von Amazing Outcomes: https://amazing-outcomes.de/. Gerne freut er sich auch über den direkten Kontakt zu euch - am besten per Mail (hello@amazing-outcomes.de) oder LinkedIn, wo ihr ihm auch folgen solltet: https://linkedin.com/in/johannesgeske/ Passende Episoden aus unserem eigenen Podcast rund um dieses Thema sind: Agiler Festpreis – Chancen & Grenzen dieser Vertragsform Das Problem mit dem Minimal Viable Product Welche Erfahrung habt ihr schon mit streng hypothesengetriebener Entwicklung gemacht? Wie gelangt ihr von einer Idee zur Marktreife? 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

Beate Radics im Gespräch mit Dominique Mehr über Beate erfahrt ihr auf ihrem LinkedIn-Profil.

Oliver und Tim im Gespräch Hast du schon einmal von "Organisatorischen Schulden" gehört? Wir nutzen den Begriff in Analogie zu "Technischen Schulden" und beziehen uns damit auf organisatorische "Abkürzungen", das (bewusste) Weglassen von Scrum Elementen oder einer Vernachlässigung agiler Ideen und Prinzipien in Organisationen, die langfristig zu Problemen und damit natürlich auch zu Kosten führen. In dieser Podcast-Episode beschäftigen sich Tim und Oliver mit diesem Thema und zeigen vor allem auf, wie organisatorische Schulden auch deinen Erfolg als Product Owner beeinflussen können. Als Product Owner oder agile Produktmanager bist du möglicherweise schon mit den Herausforderungen konfrontiert worden, die sich aus der Einführung von Scrum oder anderen agilen Methoden in deine Organisation ergeben können. Mal gibt es noch keinen Scrum Master, mal fehlt die Zeit für Reviews oder Retrospektiven. Oder du musst als Product Owner für drei oder vier Scrum Teams parallel wirken. Oliver und Tim erklären zunächst ihr Verständnis vom Begriff der "Organisatorische Schulden" und zeigen die Vorteile und Nachteile auf, wenn ich Organisationen im Rahmen der agilen Transformation oder bei der Einführung von Scrum in die organisatorische Schuld begeben. Denn, wenn man dies ganz bewusst macht, kann dies absolut Sinn machen - genau wie bewusst eigegangene "Technische Schulden", um ein Produkt oder Feature schneller an den Markt zu bekommen und mit ihm früher Outcome erzeugen zu können. Die beiden zeigen dann im Hauptteil eine ganze Reihe von Beispielen für organisatorische Schulden auf, die sie in ihrer Arbeit als agile Coaches und Berater erlebt haben. Dabei diskutieren sie, wie man sie erkennt und vor allem wie sie auf die Product Owner Rolle wirken. Natürlich gibt es aber auch wieder konkrete Tipps, wie du als Product Owner oder agiler Produktmanager mit organisatorischen Schulden umgehen kannst. Also, hör rein in die neueste Episode "Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner" und erfahre, wie du dich als PO von ihnen nicht aus der Erfolgsspur bringen lässt. Im Gespräch werden folgende ältere, aber immer noch wertvolle, Episoden aus unserem eigenen Podcast rund um dieses Thema erwähnt: Product Owner ohne Scrum Master – geht das? Technische Schulden und wie wir als Produkt Owner damit umgehen Dein Freund der Scrum Master Hast du dich schon mal bewusst mit dem Begriff der Organisatorischen Schulden beschäftigt? Wie geht ihr in eurer Organisation damit um - egal ob ihr das Phänomen so oder anders benennt? Wir freuen uns, wenn du eure 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 und Dominique im Gespräch Wie immer setzt sich der Inhalt dieser Folge in Beziehung zu anderem Wissen. Daher hier die Liste der Referenzen, die in dieser Folge genannt wurden: Crossing the chasm von Geoffrey Moore Das POEM (https://productownership.de/poem/ ) von Oliver und Tim Die vier Wissensdomänen der Produktentwicklung (https://www.designik.de/2018/08/die-vier-wissensdomaenen-der-produktentwicklung/ ) Folge über das Evidence Based Management (https://produktwerker.de/evidence-based-management/ ) Folge übers "Nein Sagen" (https://produktwerker.de/nein-sagen-als-product-owner/ )