Die Produktwerker

Heiko Stapf im Gespräch mit Oliver In dieser Folge ist Heiko Stapf bei uns zu Gast. Heiko ist für uns einer der Experten für agiles Produktmanagement im deutschsprachigen Raum und zeitgleich erfahrener Certified Scrum Trainer der Scrum Alliance. Aus seinen Product Owner Trainings hat er die spannendsten Fragen der Teilnehmer mitgebracht, die er gemeinsam mit Oliver diskutiert. Im ersten Teil der Episode dreht sich alles um Vorhersagbarkeit und Planung. Was sollte ich als Product Owner tun, wenn vor allem aus dem Management viel Verbindlichkeit und Commitment von mir erwartet wird? Welche Auswirkungen hat diese Erwartungshaltung auf Product Roadmaps. Eine weitere spannende Frage aus dem PO Training ist die Frage nach der Priorisierung, vor allem des Product Backlogs. Die Diskussion führt Heiko und Oliver dann zwangsläufig zur Zusammenarbeit mit Stakeholdern. Wie sollte ich priorisieren, falls meine Stakeholder konkurrierende Ziele haben? Insgesamt sehr spannende Themen mit Relevanz für jeden Produkt Owner. Und eine angeregte Diskussion zwischen den beiden, aus der du hoffentlich den einen oder anderen Impuls mitnehmen kannst. Im Gespräch verweisen die beiden auf folgende Quellen: John Cutler: Suitably Detailed Roadmap Items‌ Martin Eriksson: The Decision StackThe Decision Stack

Dominique und Tim im Gespräch Im Alltag müssen wir alle ständig mit anderen Menschen interagieren, sei es Small Talk, eine heiße Diskussion oder einfach nur das stille Zuhören eines Gegenübers. Dabei kommt es dauerhaft, auch wenn es nur unterbewusst ist, zum Einsatz unserer Social Skills. Als Product Owner*in ist man da nicht ausgeschlossen. Ob man mit einem Scrum Team arbeitet oder sich mit Stakeholdern austauscht, Social Skills können den Unterschied zwischen einem guten und einem schlechten PO machen. Darum unterhalten sich Tim und Dominique dieses mal über die verschiedenen Social Skills und sozialen Kompetenzen die vor allem für POs relevant sind. Dabei erkunden sie Unterschiede zwischen Hard und Soft Skills, und teilen ihre Gedanken über unterschiedliche Social Skills wie Empathie oder dem aktiven Zuhören. Dabei kommen sie aber auch zu Fragen wie "Ist Humor ein Social Skill?" oder "Kann man Social Skills einfach so lernen?". Selbst außerhalb der Rolle als PO ist es nicht schlecht sich seiner Social Skills bewusst zu sein, daher kann man viele Aspekte dieser Folge auch nutzen, um selbst mehr über die interaktion mit anderen Menschen nachzudenken. Quellen/Bücher: https://www.harvardbusiness.org/5-key-human-skills-to-thrive-in-the-future-digital-workplace/ Der KODE® KompetenzAtlas (https://www.kodekonzept.com/wissensressourcen/kode-kompetenzatlas/) Empathie. In: Dorsch: Lexikon der Psychologie. Hogrefe Verlag, Göttingen 2017, ISBN 978-3-456-85643-8 Geoff Watts: Product Mastery (https://www.inspectandadapt.com/product/product-mastery) Roman Pichler: Leadership im Produktmanagement (https://dpunkt.de/produkt/leadership-im-produktmanagement/) Relevante Podcast-Folgen: Wie kann ich mit mehr Präsenz als Product Owner auftreten? (mit Alexandra Klingor) https://produktwerker.de/mehr-prasenz-als-product-owner/ Herausforderungen zwischen Product Owner & Developer (mit Bernd Joussen) https://produktwerker.de/herausforderungen-productowner-developer/ ‌

Steffi Götten im Gespräch mit Dominique OKR als Methodik um Ziele zu setzen und zu verfolgen ist seit einigen Jahren auch bei uns in Deutschland in aller Munde. Daher, eigentlich schon lange überfällig, wollen wir uns auch mit dem Thema OKR beschäftigen und haben uns eine Expertin eingeladen, die langjährige Zuhörer*innen bereits kennen dürften. An der Seite von Dominique steht Stefanie Götten als Expertin und sie tauschen sich zum Thema mit einem klaren Fokus aus: Was bedeutet die Einführung von OKR für uns in unserer Verantwortung als Product Owner. Stefanie war bereits bei uns im Podcast zu Gast. In der Folge "Dein Freund der Scrum Master" (https://produktwerker.de/dein-freund-der-scrum-master/) war sie schon einmal bei uns zu Gast. Mehr zu Stefanie findet ihr unter https://www.linkedin.com/in/stefanie-g%C3%B6tten/. Welche Erfahrungen hast du rund um die Einführung und Nutzung von OKR gesammelt. Teilst du unsere Meinungen und Erfahrungen oder widersprichts du? Lass uns gerne daran teilhaben. Wir freuen uns, wenn du dein eigenes Verständnis mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilst. Und falls dir der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von dir favorisierten Podcast-App.

Dominique im Gespräch mit Oliver Fragt man drei Product Ownerinnen, was sie als ihre Verantwortlichkeit ansehen, so erhält man vier sehr unterschiedliche Antworten. In vielen Fällen ist eine Ursache für die Vielfalt der Rolleninterpretationen, dass manche als Product Owner im Scrum Kontext arbeiten und andere wiederum als SAFe Product Owner. Es ist also an der Zeit, dass Oliver und Dominique über die Gemeinsamkeiten und Unterschiede sprechen. Denn aus ihrer Perspektive ist es dieses Thema eines der großen Missverständnisse - ein Scrum PO ist etwas komplett anderes als ein SAFe PO. Und nachdem einige Beiträge und Meinungen in den letzten Wochen in die Timeline der beiden gespült wurden, auch ein guter Zeitpunkt die eigene Sichtweise zu konkretisieren. Dominique und Oliver starten mit einer Reflexion eines Beitrags von Roman Pichler zu "Six Types of Product Owner", der in diesem Podcast schon einmal in der einen oder anderen Episode zitiert wurde. Fokus legen beide aber auf den Scrum PO und den SAFe Product Owner. Wo liegen die Gemeinsamkeiten, welche Unterschiede findet man. Nach einem Blick in den Scrum Guide und in die detaillierteren Erläuterungen in SAFe wird auf die eine oder andere Äusserung von Kollegen referenziert, u.a. Sohrab Salimi oder Heiko Stapf. Natürlich artikulieren Oliver und Dominique auch sehr klar ihren eigenen Standpunkt und klären, dass auch in diesem Podcast sehr häufig der Scrum Product Owner im Mittelpunkt der Diskussionen steht. Wie immer schließt diese Episode mit einigen konkreten Tipps & Trick ab.

Nam Hoang-Dong im Gespräch mit Tim Nam Hoang-Dong berichtet über seine Erfahrung als Product Leader einer Retained-Organisation im Gespräch mit Tim, d.h. wie sich die Steuerung eines großen externen Dienstleisters als Produktverantwortlicher anfühlt. Nam hat eine langjährige Erfahrung im Handel (MediaMarkt, ESPRIT, Thalia) und spricht in dieser Folge v.a. über die Zeit bei Esprit in die auch die agile Transformation des damaligen Dienstleisters fiel. Als Retained-Organisation wird dabei eine (meist) kleinere Einheit verstanden, die den beauftragten Dienstleister steuert. In der Praxis geschieht dies häufig nach Outsourcing-Prozessen. Hier im Beispiel vom Fashion-Händler ESPRIT wurde das ganze Online-Business über viele Jahre in dieser Form aufgebaut und betrieben. D.h. auch die (agile) Produktentwicklung des ESPRIT Onlineshops geschah auf diese Weise. Tim war damals auf der Seite des Dienstleisters im Einsatz und hat die Veränderung der Dienstleister-Beziehung daher aus anderem Blickwinkel beobachten können. Mit einigen Jahren Abstand kommt es somit zu einer interessanten Reflexion der Transformation. Aber auch die Frage, was Nam aus dieser Erfahrung an Learning in seine neue Rolle als IT-Verantwortlicher bei Thalia mitgenommen hat, spielen im Gespräch eine Rolle. In Summe ergibt sich also ein toller Erfahrungsbericht eines Product Leaders im Handelskontext aus dem sicherlich einige Impulse gezogen werden können. Folgendes Buch nennt Tim im Verlauf des Gesprächs: Robbin Schuurman/Willem Vermaak: 50 Arten, Nein zu sagen Im Zusammenhang mit dieser Podcast-Episode über die Arbeit als Retained-Organisation möchten wir euch auch nochmal diese älteren folgen im Kontext der Dienstleister-Zusammenarbeit als Herz legen: Zusammenarbeit mit einem externen Team vom Dienstleister Der Product Owner aus Sicht eines Dienstleisters Als Product Owner auf Seiten einer Agentur Wenn ihr mit Nam Hoang-Dong persönlich in Kontakt treten möchtet oder weitere Fragen an ihn habt, freut er sich über eure Anfrage bzw. Nachricht auf seinem LinkedIn-Profil. Welche Learnings habt ihr aus der Zusammenarbeit mit und Steuerung von Dienstleistern gezogen? Kennt ihr vielleicht auch solch ein Konstrukt einer Retained-Organisation? Lasst uns gerne an euren Erfahrungen, Tipps oder auch eurer Meinung teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Oliver im Gespräch mit Dominique Wer kennt sie nicht, die kleinen Life Hacks, die durch minimale Veränderungen das Leben ein klein wenig leichter machen sollen. Der Ansatz der Culture Hacks dient dazu die Kultur einer Organisation zu verändern, aber eben mit kleinen Schritten. Gleichzeitig beziehen sich Culture Hacks auf Veränderungen im informellen Bereich. Es geht eben nicht darum direkt eine neue Rolle, neue Meetings oder andere Formalismen einzuführen. Oliver und Dominique sprechen in dieser Folge über Culture Hacks, die nach ihrer Erfahrung gut auf die Kultur der Organisation einwirken können. Sie stellen aber auch heraus, dass Culture Hacks immer Experimente sind und kein Erfolgsversprechen mit sich bringen. Beispielsweise kann man versuchen die Kultur der Organisation mittels geteilter O-Töne der Menschen, die das Produkt benutzen, mehr Richtung Erlebnisorientierung zu bringen. Wenn Mitarbeitende durch viele Meetings keine Zeit haben sich zu einem allgemeinen PO-Austausch zu treffen, bietet sich vielleicht ein gemeinsames Mittagessen an. Oder man teilt seine persönlichen Gedanken über aktuelle Produktthemen häufiger per SMS, Instantmessaging oder Mail und versucht so Gespräche anzustoßen. Rund um das Thema Kultur haben wir noch ein paar weitere spannende Folgen für euch: Diversity in der Produktentwicklung (https://produktwerker.de/diversity-in-der-produktentwicklung/) Die Relevanz von UX den eigenen Stakeholdern vermitteln (https://produktwerker.de/die-relevanz-von-ux-vermitteln/) Auf Business oder Nutzer fokussieren als PO? (https://produktwerker.de/business-oder-nutzer/) Falls ihr noch weitere Tipps habt, wie man mit kleinen Maßnahmen die Kultur deiner Organisation verändern kann, lasst es uns gerne wissen. Wie sind eure Erfahrungen und welchen Herausforderungen musstest ihr euch dabei stellen? Wir freuen uns, wenn ihr eure eigenen Sichtweisen mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker) teilt.

Ralph Jocham im Gespräch mit Tim Bei all den verschiedenen Skalierungsoptionen, die es heute gibt, scheint es, als gäbe es nur wenig Einigkeit darüber, wie man die Rolle des PO skalieren kann. Ralph Jocham, der Autor des Bestsellers "The Professional Product Owner", ist nach einem sehr interessanten Talk auf dem Scrum Day 2022 mit dieser Thema bei Tim zu Gast im Produktwerker-Podcast. Ralph stellt fünf Delegationsmodelle für Product Owner vor, die unabhängig von den vorhandenen Skalierungsmöglichkeiten abgeleitet werden können. Je nach individuellem Kontext können diese Delegationsmodelle einzeln oder in Kombination eingesetzt werden. Nachdem die beiden in ihrem Gespräch noch einmal auf das grundsätzliche Verständnis für die Rolle des Product Owner eingehen, fokussieren sie sich anschließend auf das Thema Skalierung. Die zu diesem Zweck vorgestellten fünf Delegationsmodelle (5Ts) sind: Taktisches Delegationsmodell - lassen Sie andere dabei helfen, das Product Backlog und andere taktische Dinge zu verwalten Technisches Delegationsmodell - bauen Sie Ihre Arbeit in das Produkt ein Team-Delegationsmodell - delegieren Sie an die Teammitglieder, lassen Sie sie mit den Kunden sprechen Temp-Delegationsmodell - weisen Sie jedem Team einen Vertreter zu, bis die Teams autark sind Themen-Delegationsmodell - schaffen Sie Vertreter (SMEs) für verschiedene Produktbereiche, die die Teams konsultieren können Natürlich schließt auch diese Episode mit praktischen Tipps und Tricks unseres Gastes.

Was in Dominiques Kopf gerade so vorgeht Mit dieser Folge wagen wir ein kleines Experiment. Einer von uns spricht über einen Gedanken, der ihn gerade umtreibt und erhofft sich mit euch in einen Dialog zu treten. Dazu seid ihr alle herzlich eingeladen auf die Seite dieser Folge zu gehen und in den Kommentaren eure Perspektive auf die Gedanken zu teilen. Hier könnt ihr mitmachen -> https://produktwerker.de/gedankenaustausch-was-kommt-nach-ux/ Dominique spricht diesmal über seine Gedanken, welche Gestaltungsaspekte nach der UX kommen können und wirft dabei einen Blick in eine mögliche Zukunft in 30 Jahren. Vor 30 Jahren war noch eher Usability und die Benutzbarkeit relevant. Aus der Usability hat sich dann im Laufe der Zeit die UX entwickelt. Für Produkte wurde die Metapher des Werkzeugs verwendet. Der Gestaltungsaspekt der UX ist aber auf das Erleben der Interaktion fokussiert und wir versuchen insbesondere ein positives Erleben zu erzeugen. Menschen haben jedoch bezogen auf die Interaktion mit Produkten oft eine Aneinanderreihung von Episoden der Nutzung und der Nicht-Nutzung. Die Summe dieser Episoden erzeugt bei Menschen ggf. eine Beziehung zum Produkt. Dominique ist davon überzeugt, dass nach wir uns von der reinen Nutzbarkeit hin zum Erleben der Interaktion bewegt haben und zukünftig noch stärker in die Gestaltung der Beziehungsebene bewegen werden. Es geht dann nicht mehr nur darum EIN positives Erlebnis, sondern eine Historie aus positiven Erlebnissen zu schaffen, die eine emotionale Bindung der ein oder anderen Art zwischen User und Produkt ermöglicht. Besonders durch Automaten, die viel natürlicher mit dem Menschen kommunizieren wird der Aspekt des Partners stärker. Selbstverständlich brauchen wir weiterhin UX als Gestaltungsaspekt. Ohne positive Nutzungserlebnisse schaffen wir keine positive Nutzerbeziehung. Genauso braucht ein gutes Nutzungserlebnis eine gute Benutzbarkeit. Was bedeutet das für die Ausarbeitung zukünftiger Verantwortlichkeiten? Wahrscheinlich wird mehr Fokus auf die User Journey außerhalb der einzelnen Nutzungsepisode gelegt. Es werden Fragen geklärt wie: Wie sollen Nutzer die Beziehung zu dem Produkt empfinden oder wie ermöglichen wir eine emotionale Bindung? Produkte werden so zu emotional aufgeladenen Artefakten des Lebens. Die mögliche Metapher ist dann der Partner und wir müssen uns klar haben, welche Werte und Prinzipien das Produkt in der Beziehung und nach außen vertritt. Auch müssen wir verstehen, was es besonders macht. Die Entwicklung einer Persönlichkeit des Produkts erfolgt durch Austausch, bzw. Interaktion. Es gibt im Buch Gamestorming eine gut dazu passende Übung (Pinocchio-Produkt-Übung). Stell dir vor, dein Produkt erwacht auf einmal zum Leben. Welchen Charakter hat es und wofür kämpft es? Hedonische Aspekte fließen wahrscheinlich stark in die Bildung der Beziehung ein. Eine Beziehung macht auch was mit einem selbst. Customer Relation und User Relation wirken stark auf einander ein, je nach Produkt. Die Beziehungsebenen werden einen Einfluss aufeinander haben. Hier wird sich aber im Laufe der Zeit eine Abtrennung der Fachdisziplinen entwickeln. Es werden aber auch Probleme durch die Fokussierung entstehen. Die Integration von UX als Gestaltungsaspekt in die Entwicklungsvorgänge von Organisationen ist im Moment auf breiter Flur zum Beispiel noch nicht abgeschlossen. Wie bei UX werden neue Fähigkeiten und Fertigkeiten gebraucht und nicht alle UX-Professionals haben diese bereits. Es wird eine Diffundierung der neue Fachdisziplin geben, die erst nach längerer Zeit konsolidiert werden wird. Jetzt aber genug von Dominiques Gedanken. Wie seht ihr das? Was ist eure Meinung? Teilt es mit allen unter https://produktwerker.de/gedankenaustausch-was-kommt-nach-ux/.

Oliver und Dominique im Gespräch Über die Zusammenarbeit von Product Ownern mit Stakeholderinnen, Nutzerinnen und so weiter haben wir schon mehrfach gesprochen. Aber immer wieder gibt es auch Kontexte, in denen wir als Product Owner mit anderen Product Ownern zusammenarbeiten. Diesen Kontexten begegnen wir insbesondere in größeren Organisationen, in denen mehrere Teams mit jeweils eigenen Product Ownern an einem großen Produkt zusammen arbeiten. Da werden große Produkte so geschnitten, dass verschiedene Product Owner gemeinsam mit ihren Teams Teil-Produkte verantworten. Aus der Skalierung mit mehreren Produktteams für ein Produkt ergibt sich in der Praxis häufig das ein oder andere Problem. Beispielsweise wirkt das Gesamtprodukt nicht mehr wie aus einem Guss, eben weil es auch von verschiedenen Menschen mit unterschiedlichen Sichtweisen entwickelt wurde. Wenn jedes Teil-Produkt sein eigenes (Teil-)Product Backlog hat, wird es mit der gemeinsamen Priorisierung kompliziert. Oft hängen auch die Metriken der jeweiligen Teil-Produkte nicht ganz sauber zusammen. Viele Probleme, die auch beim Zusammenarbeiten der Product Owner auftauchen und dort in irgendeiner Art gelöst werden sollen. Weitere spannende Folgen rund um das Zusammenarbeiten findet ihr hier: Als Product Owner im skalierten Umfeld Das Product Owner Team Habt ihr euch mit dem Thema schon mal beschäftigt? Wie geht ihr selbst damit um? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

Dominique und Oliver im Gespräch Biases sind Verzerrungen bzw. systematische Fehler in der Beurteilung von Information. Der bekannteste ist vielleicht der sogenannte "Cognitive Bias", eine kognitive Verzerrung. Letztlich beeinflussen sie unser Urteilsvermögen und durch subjektive Eindrücke und beeinflussen so auch Entscheidungen von Product Ownern. Objektivität wird somit erschwert, denn Menschen neigen dazu, alle Schlussfolgerungen zu akzeptieren, die in ihr Glaubenssystem passen, ohne diese gründlich zu hinterfragen. Umgekehrt neigen wir dazu, Behauptungen abzulehnen, die nicht in unser Glaubenssystem passen, auch wenn sie durchaus logisch sein könnten. Oliver und Dominique nehmen sich in dieser Folge dieses Phänomen aus der Verhaltenspsychologie mal vor, erklären es anhand von Beispielen und versuchen auch mal zu reflektieren, wie Product Owner in ihren Entscheidungen von so etwas betroffen sind. Weitere Biases, die in dieser Episode u.a. behandelt werden: Dunning Kruger Effekt = Tendenz von wenig kompetenten Menschen, das eigene Können zu überschätzen und die Kompetenz anderer zu unterschätzen Confirmation Bias = Neigung, Informationen so zu interpretieren, dass sie die eigenen Erwartungen einfach nur bestätigen Implicit Bias = das Produkt so bauen, wie man es sich selber wünscht bzw. vorstellt, d.h. von sich auf andere schließen IKEA-Effekt = die Neigung, selbst zusammengebauten Gegenständen im Vergleich zu fertig gekauften Massenprodukten mehr Wertschätzung entgegenzubringen. In Bezug auf Software: alles selber programmieren zu wollen, anstatt Standard-Software einzubinden Effort justification Bias = Wenn wir Aufwand in etwas investiert haben, wird es als wertvoller betrachtet, als wenn wir objektiv drauf schauen würden Verlustaversion = Die Tendenz, Verluste höher zu gewichten als Gewinne Und dies sind letztlich auch alles Fallen, in die wir als Product Owner reinlaufen können. Oliver und Dominique geben daher Tipps, was man gegen diese "Störenfriede" tun kann oder zumindest, wie man damit als Product Owner besser umgehen kann. Ein tolles Buch, was sich letztlich auch um das Thema der Biases dreht ist "Schnelles Denken, langsames Denken" von Daniel Kahneman (englischer Originaltitel: Thinking, Fast and Slow). Kahneman verfolgt anhand vieler Beispiele aus seiner Forschung die folgende These: es gibt zwei Arten des Denkens: Das schnelle, instinktive und emotionale System 1 und das langsamere, Dinge durchdenkende und logischere System 2. Zum Thema "Biases" passt auch diese frühere Folge aus diesem Podcast sehr gut: Decision Poker und Entscheidungsverfahren Kano-Modell um Kundenbedürfnisse zu verstehen Habt ihr euch mit dem Thema schon mal beschäftigt? Wie geht ihr selber damit um? Lasst uns gerne an euren Erfahrungen oder auch euren Herausforderungen teilhaben. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.