Die Produktwerker

Tim und Dominique im Gespräch In der Produktentwicklung spielen Kreativitätstechniken eine essenzielle Rolle. Sie dienen dazu, innovative Ideen zu generieren und den Entwicklungsprozess auf neue Bahnen zu lenken. In dieser Folge sprechen Tim und Dominique darüber, wie Kreativitätstechniken innerhalb der agilen Propduktentwicklung beispielsweise mit Scrum eingesetzt werden können. Viele setzen auf das altbewährte Brainstorming, aber es zeigt sich oft, dass diese Methode ihre Grenzen hat. Eines der Hauptprobleme liegt in der sozialen Erwünschtheit, die oft die Qualität der generierten Ideen beeinträchtigt. Brainstorming, führt regelmäßig dazu, dass Teilnehmende sich selbst zensieren oder Ideen aus Angst vor Ablehnung zurückhalten. Hier setzt das Brainwriting an, eine Alternative, die in diesem Kontext häufig als hilfreicher erachtet wird. Durch die Möglichkeit, Ideen schriftlich zu notieren, wird der soziale Druck reduziert. Alle Teilnehmenden können ihre eigenen Gedanken ohne Hemmungen aufschreiben, was zu einer größeren Bandbreite kreativer Ansätze führt. Ein weiterer Ansatz, der sich bewährt hat, ist die 635-Methode. Hierbei formulieren sechs Teilnehmende jeweils drei Ideen in fünf Minuten. Diese Ideen werden dann an die nächsten sechs Teilnehmenden weitergereicht, die darauf aufbauend neue Ideen generieren. Durch diese iterative Vorgehensweise entstehen in kurzer Zeit eine Vielzahl an Ideen, ohne dass der Einfluss sozialer Faktoren die Kreativität einschränkt. Da an der Produktentwicklung aber viele Köpfe beteiligt sind, bieten sich auch Techniken an, bei denen Menschen jeweils die gleiche Denkperspektive einnehmen. Beispielsweise haben sich Edward de Bonos Denkhüte als nützliches Instrument erwiesen. Diese metaphorischen Hüte repräsentieren verschiedene Denkrichtungen, die in der Gruppe durchgespielt werden können. Jeder Hut steht für eine andere Sichtweise: neutral, emotional, optimistisch, kritisch, kreativ und strukturiert. Indem die Teilnehmenden bewusst in diese verschiedenen Rollen schlüpfen, entsteht eine facettenreiche Betrachtung des Problems, die zu vielseitigen Lösungsansätzen führen kann. Dominique empfiehlt hier aber, dass alle Teilnehmenden immer die gleiche Perspektive einnehmen und nicht einjeder einen anderen Hut zur gleichen Zeit trägt. Eine weitere Methode, die sich bewährt hat, ist die Walt-Disney-Methode. Sie nutzt die Rollen des Träumers, Realisten und Kritikers, um eine Idee aus unterschiedlichen Blickwinkeln zu betrachten. Dadurch werden sowohl visionäre Ansätze als auch praktische Umsetzbarkeit beleuchtet, was zu ausgewogeneren und umsetzungsfähigen Ideen führen kann. -- Empfehlungen -- Wir möchten euch an dieser Stelle das Buch "How to have creative ideas" (ISBN 978-0-09-191048-8) von Edward de Bono empfehlen. Als persönliche Empfehlung von Dominique hier noch ein hervoragender Vortrag von John Cleese zum Thema Kreativität im Management: https://www.youtube.com/watch?v=Pb5oIIPO62g&ab_channel=VideoArts Passend zum Thema Kreativität hier ein paar weitere Folgen: Als Product Owner im Sprint Review (https://produktwerker.de/als-product-owner-im-sprint-review/) Mit Storytelling andere von Deinen Produktideen überzeugen (https://produktwerker.de/storytelling-fuer-product-owner/) Visual Leadership für Product Owner (https://produktwerker.de/visual-leadership-product-owner/)

Rainer Gibbert im Gespräch mit Dominique Im Verlauf des Produktlebenszyklus müssen wir immer wieder Teile des Produkts verändern, aktualisieren oder an neue Erkenntnisse anpassen. Dies ist notwendig, um auch in Zukunft den Mehrwert unseres Produkts zu erhalten oder vielleicht sogar noch mehr Wert zu schaffen. Auf der anderen Seite haben Menschen, die unser Produkt schon länger nutzen, Zeit investiert, um die Bedienung zu erlernen. Jede Veränderung am Produkt bedeutet daher einen neuen Lernaufwand. Verständlicherweise lehnen Menschen Veränderungen ab, wenn sie den Nutzen nicht erkennen, nicht verstehen oder zumindest nicht nachvollziehen können. In dieser Folge spricht Dominique mit Rainer Gibbert, Leiter der Produktentwicklung bei der Star Finanz GmbH. Rainer hielt auf der Workings Products 2023 einen Vortrag zu diesem Thema. Immerhin ist er momentan für ein Produkt verantwortlich, das bereits seit 25 Jahren existiert. Viele Menschen haben sich an die Benutzung gewöhnt. Rainer diskutiert darüber, wie man damit umgehen kann, wenn Produktänderungen abgelehnt werden, und er erläutert, wie man diese Änderungen erfolgreich einführen kann. Er teilt mit, welche Vorbereitungen getroffen werden müssen, damit möglichst viele Menschen auf die neuen Funktionen, Änderungen und allgemeinen Anpassungen umsteigen. Wenn ihr nach dem Podcast noch einige Erkenntnisse nachlesen möchtet, empfehlen wir euch Rainers Artikel auf https://www.produktbezogen.de/produktaenderungen-warum-nutzer-sie-hassen/. Weitere Informationen zu Rainer findet ihr auch auf seinem LinkedIn-Profil unter: https://www.linkedin.com/in/rainergibbert/ Wenn ihr eigene Erfahrungen zu dem Thema gesammelt habt, lasst es uns gerne auf LinkedIn oder auf dem Blogbeitrag zu dieser Folge wissen. Wir freuen uns auf eure Erfahrungen.

Tim & Dominique im Gespräch Ist ein Proxy Product Owner sinnvoll? Wann und warum kann es diese Rolle geben? Wie kann man dieses Anti-Pattern überwinden oder im Zweifel auch damit umgehen? Zunächst mal erklären Tim und Dominique, was ein Proxy Product Owner ist bzw. was dies bedeutet. Auch die vielfältigen Gründe weshalb eine solche Rolle in bestimmten Situationen anzutreffen ist, werden erläutert. Besonders oft, sieht man eine solche Aufstellung, wenn das Scrum Team von einem Dienstleister gestellt wird, die Product Ownerin aber vom Auftraggeber gestellt wird. Letztlich ist der Einsatz einer Proxy Product Owner Rolle jedoch ein Anti-Pattern in Scrum. Insofern diskutieren die beiden, zu welchen Problemen es in der agilen Produktentwicklung durch solch eine Konstellation kommen kann. Spannend sind dann die Empfehlungen von Dominique und Tim, wie die Situation überwunden werden kann, also wie man diese "organisatorische Schuld" und somit die Proxy Product Owner Rolle wieder loswerden kann. Letztlich ist der Einsatz eines Proxy-PO auch recht nah dran an der Frage, ob und wie eine Arbeit mit zwei Product Ownern in einem Team möglich ist - dies war das Thema der letzten Folge. Im Zweifel also auch hier nochmal reinhören. Manchmal mag es aber auch Situationen geben, in denen - zumindest für einen bestimmten Zeitraum - mit dieser Rolle gelebt werden muss. Auch hierfür geben die beiden Empfehlungen ab, wie man dies möglichst gut meistern kann. Das Gespräch endet wie gewohnt mit Tipps & Tricks im Umgang mit der Herausforderung "Proxy Product Owner". Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt in dieser Folge erwähnt: Den Wert des Produktes maximieren Ein Scrum Team, zwei Product Owner. Geht das? Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Der Product Owner aus Sicht eines Dienstleisters Zusammenarbeit mit dem externen Team eines Dienstleisters Warst du auch schon mal als Proxy-PO im Einsatz oder hast eine solche Situation in einem Team erlebt? Was war der Grund, dass dort ein Product Owner Proxy eingesetzt wurde? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch weitere gute Tipps, wie der Einsatz einer solchen Rolle sinnvoll und wertstiftend gelingen kann. 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 & Tim im Gespräch Es gibt Situationen, in denen eine Organisation sich entscheidet, zwei Product Owner einem Scrum Team zuzuordnen. Also zwei Menschen sollen sich diese Verantwortlichkeit teilen: gemeinsam das Product Backlog managen, gemeinsam mit dem Scrum Team die Scrum Events durchführen usw. - auch wenn der Scrum Guide das definitiv anders beschreibt: Ein Team sollte genau eine Product Ownerin ("The Product Owner is one person, not a committee.") und ein Product Backlog haben. Aber in der gelebten Realität sieht man das schon mal anders. Wie kommt es dazu und geht das denn überhaupt? Tim und Dominique nennen in dieser Podcast-Folge die Gründe, wegen derer sich Organisationen für mehr als eine Product Ownerin entscheiden. Anschließen diskutieren sie die Risiken und Schwächen einer solchen Situation - insbesondere vor dem Hintergrund ihrer eigenen Erfahrungen mit solchen Konstellationen. Tim berichtet z.B. von einem Versuch, vier PO für ein Team zu installieren. Der Versuch scheiterte allerdings ziemlich schnell. Natürlich zeigen die beiden auch Lösungsansätze auf, um die Situation zu überwinden und diese "organisatorische Schuld" abzubauen. Wie kann es gelingen, das ganze auf nur einen Product Owner zu reduzieren? Abschließend besprechen die beiden aber auch, was geschehen müsste oder gegeben sein muss, um (zur Not) auch mit mehr als einem PO zu arbeiten. Diese Podcast-Episoden passen zum Thema bzw. wurden erwähnt: Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner Product Owner in Teilzeit Wie die Produktvision hilft, Product Ownern eine Richtung zu geben Warum scheint die Product Owner Rolle so schwer zu sein? (Gast: Markus Andrezak) Hast du das auch schon mal erlebt: zwei PO in einem Scrum Team? Was war der Grund, dass ihr euch so aufgestellt habt? Und welche Erfahrung habt ihr dabei gemacht? Vielleicht hast du noch gute Tipps, wie eine solche Konstellation gelingen kann. 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]

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.