Die Produktwerker

Laura Marwede & Dominique im Gespräch Wenn wir mit mehreren Teams an einem umfangreichen Projekt arbeiten, stellt sich oft auch im Design die Frage nach einer systematischen Vorgehensweise. Eine strukturierte Möglichkeit hierfür ist die Implementierung eines Designsystems. In dieser Folge wollen wir untersuchen, wann sich ein Designsystem in der Produktentwicklung lohnt und vor allem aus der Sicht der Product Owner beantworten. Dafür haben wir Laura Marwede eingeladen, Head of UX & Strategy bei TEAM23, die sich mit ihrem Team bereits seit geraumer Zeit mit diesem Thema beschäftigt. Sie ist somit die ideale Person, um Dominique in dieser Episode Rede und Antwort zu stehen. Der potenzielle Mehrwert von Designsystemen liegt darin, dass sie einen konsistenten und strukturierten Ansatz für die Gestaltung und Entwicklung von Produkten bieten. Sie bestehen aus einer Sammlung von Komponenten, Stilen, Richtlinien und Prinzipien, die als Grundlage für das gesamte Design einer Anwendung oder eines Produkts dienen. Designsysteme fördern die Konsistenz und Einheitlichkeit in der Produktentwicklung. Durch die Verwendung vordefinierter Komponenten und insbesondere Stile können wir als Product Owner sicherstellen, dass das Erscheinungsbild und die Benutzererfahrung unserer Produkte einheitlich sind. Zudem können Designsysteme den Entwicklungsprozess beschleunigen, da wir nicht jedes Mal von Grund auf neu beginnen müssen. Ein Großteil der Gestaltungsentscheidungen ist bereits getroffen, was Zeit und Ressourcen spart. Es gibt jedoch auch potenzielle Nachteile bei der Verwendung von Designsystemen. Insbesondere der anfängliche Aufwand für die Erstellung eines Designsystems sollte nicht unterschätzt werden. Es erfordert Zeit und Ressourcen, um die richtigen Komponenten und Stile zu definieren und das Designsystem aufzubauen. Wenn dann jedoch immer wieder Diskussionen über das Design entstehen, wird der eigentliche Vorteil eines Designsystems nicht realisiert. Wann sollten wir als Product Owner also Designsysteme nutzen? Die Antwort ist: Es kommt drauf an. Wenn ein Produktteam wächst und das Produkt selbst eine gewisse Größe erreicht hat, kann die Einführung eines Designsystems die Zusammenarbeit erleichtern und die Konsistenz sicherstellen. Es wird dann zu einem nützlichen Werkzeug für die Produktgestaltende.

Tim und Oliver im Gespräch Findet euer Sprint Review ohne Stakeholder statt? Oder kommen sie nur sporadisch? Tatsächlich ist das ein häufiges Problem in der Praxis und führt in der Arbeit mit Scrum zu ernsthaften Problemen. Tim und Oliver besprechen zunächst die Gründe, warum diese Situation eintreten kann. Danach diskutieren sie, welche Effekte das Fehlen von Stakeholdern im Sprint Review auf den Erfolg der agilen Produktentwicklung haben kann. Natürlich sind die Ideen und Vorschläge der beiden, wie man die Situation ändern kann, besonders spannend. Wie kann es gelingen, dass (wieder) mehr Stakeholder regelmäßig beim Sprint Review dabei sind und aktiv ihr wertschätzendes und konstruktives Feedback einbringen? Wie kann man es dem Umfeld bewusst machen, dass es wichtig ist, zu kommen und Feedback auf den aktuellen Stand der Entwicklung zu geben. Dabei ist auch wichtig, den Stakeholdern auch mit Respekt auf Augenhöhe zu begegnen und ihnen explizit zu sagen, wenn nichts Wesentliches für ihren Bereich in diesem Sprint dem Inkrement hinzugefügt wurde. Aber auch für den Fall, dass das alles nicht hilft und am Ende dann doch das Sprint Review ohne Stakeholder stattfinden muss, hauen die beiden noch einige, z.T. sehr kreative, Tipps raus. Diese Podcast-Episoden passen zum Thema "Sprint Review ohne Stakeholder" bzw. wurden erwähnt: Als Product Owner im Sprint Review Seine Stakeholder kennen und richtig analysieren Umgang mit schwierigen Stakeholdern Stakeholder Community Wer nimmt User Stories ab? Dein Freund der Scrum Master Warum scheint die Product Owner Rolle so schwer zu sein? (Gast: Markus Andrezak) Nutze Story Mapping, um mit Stakeholdern über Outcome zu sprechen Hast du auch das Problem, dass eure Stakeholder nicht zum Sprint Review kommen? Wie geht ihr damit um und welche guten Tipps habt ihr noch für uns und alle anderen Product Owner? Wir freuen uns, wenn du deine Erfahrungen aus der Praxis mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite. Folgt uns 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]

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