Die Produktwerker

Häufig erwähnt

• Obi
• Andrea
• Lukas
• Dominik
• Gemini
• KI
• Apple Podcast
• Fußball-WM
• Köln
• LLM
• Olli

1. Product Owner Communities etablieren
   05.12., 06:0005.12.2022, 06:0000:35:02

   Dominique & Oliver im Gespräch Für Organisationen entsteht durch die agile Produktentwicklung eine besondere Herausforderung. Wissen muss innerhalb eines Teams aber auch darüber hinaus ausgetauscht und weitergegeben werden. Eine mittlerweile bewährte Möglichkeit des teamübergreifenden Austauschs bieten beispielsweise Communities of Practice. In diesen tauschen sich Menschen zu einem bestimmten Themengebiet aus und lernen voneinander. Dominique und Oliver sprechen daher in dieser Folge über Product Owner Communities, den Communities of Practice für Product Owner. In der Praxis begegnen uns Product Owner Communities in ganz unterschiedlicher Form. Von Buchclubs hin zu Lerngruppen und Orten für kollegiale Fallberatung besprechen die beiden verschiedene Erscheinungsformen der PO Communities, klären aber auch, wie man als EInzelkämper oder Einzelkämpferin von einer externen Community profitieren kann. Folgende Referenzen haben Oliver und Dominique in dieser Folge erwähnt: Cultivating Communities of Practice von Wenger, McDermott und Snyder (https://www.amazon.de/Cultivating-Communities-Practice-Managing-Knowledge/dp/1578513308) Der interne UX-Stammtisch - Entwicklung einer Community of Practice für UX-Professionals im Unternehmen (https://dl.gi.de/handle/20.500.12116/5472) Agiles Produktmanagement mit Scrum - Roman Pichler (https://www.romanpichler.com/romans-books/agile-product-management-with-scrum/) Rund um die Vernetzung und die Weiterentwicklung von Product Ownern empfehlen wir euch noch folgende Folgen: Als Product Owner erfolgreich zusammenarbeiten (https://produktwerker.de/als-product-owner-erfolgreich-zusammenarbeiten/) Das Product Owner Team (/https://produktwerker.de/product-owner-team/) Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern (https://produktwerker.de/sei-dein-eigenes-produkt/) Welche Erfahrungen hast du beim Aufbau von Product Owner Communities gemacht? Was hat gut und was vielleicht auch gar nicht funktioniert? Wenn du Tipps, Tricks und Erfahrungen für uns alle hast, freuen wir uns über dein Feedback. Auch der Austausch hier ist eine Art der Community und des gemeinsamen Lernens. Daher freuen wir uns besodners über einen Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker). Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

2. Eine Produktstrategie ohne Canvas erarbeiten
   28.11., 06:0028.11.2022, 06:0000:36:30

   Tim Herbig im Gespräch mit Oliver Wir haben in diesem Podcast schon öfter über die Bedeutung der Produktstrategie für Product Owner und agile Produktmanager gesprochen. Will ich eine Produktstrategie entwickeln, dann greifen viele Product Owner auf die bekannten Templates und Cavases zurück. Tim Herbig, Product Coach und Author aus Erfurt, teilt im Gespräch mit Oliver seine Gedanken, wie das Erarbeiten der Produktstrategie auch ohne diese Tools gelingen kann. Die beiden starten die Diskussion mit einer Definition von Produktstrategie. Hier referenziert Tim auf das Buch von Roger Martin. Spannend ist die kritische Haltung von Tim, dass die komplette Strategie meist nicht in Workshops durch das Ausfüllen eines der gängigen Canvases entsteht. Für Bestandteile der Strategie, wie beispielsweise die Produktvision oder eine Wettbewerbsanalyse macht ein Workshopformat hingegen wieder viel Sinn. Tim erläutert darüber hinaus, wie ich OKRs und Produktstrategie sinnvoll miteinander verbinden kann. Seine These: Ohne eine nützliche Produktstrategie kann ich keine sinnvolle OKRs definieren. Abschließend reflektieren die beiden, wen ich an dem Strategie-Erstellungsprozess beteiligen und welche Bestandteile erarbeitet werde sollten, damit die Produktstrategie mich auch in meiner Arbeit unterstützt. Wie immer schließt die Folge mit konkreten Tipps und Tricks ab. Folgende Bücher und Blogbeiträge haben Tim und Oliver in dieser Folge erwähnt: Newsletter von Tim -> https://herbig.co/newsletter/ Roger Martin - Playing to Win -> https://www.amazon.de/Playing-Win-Strategy-Really-Works/dp/142218739X/ Ravi Metha - Product Strategy Stack -> https://www.reforge.com/blog/the-product-strategy-stack Tim Herbig - Product Strategy Ressources Hub https://herbig.co/product-strategy-hub/ Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

3. Wer nimmt User Stories ab?
   21.11., 06:0021.11.2022, 06:0000:36:04

   Dominique und Tim im Gespräch In Trainings, Workshops und Coachings bekommen wir immer wieder Fragen zur Abnahme von User Stories gestellt. Grund genug, zu diesem Thema mal eine Episode aufzunehmen. Dominique und Tim nähern sich dem Thema über die Frage, was denn überhaupt eine Abnahme ist und wo sie sonst stattfindet. Schnell wird klar, dass es sich dabei um Vertragssituationen handelt. Hierbei nimmt der Auftraggeber die Leistung des Auftragnehmer ab. Das Allein zeigt schon, dass die Frage im agilen Kontext eines Scrum Teams vielleicht falsch gestellt ist. Es besteht kein Vertragsverhältnis zwischen Product Owner und Developern, daher ist im engeren Sinne auch nichts abzunehmen. User Stories und andere Product Backlog Elemente enthalten dagegen sogenannte Akzeptanzkriterien, die wir auch in einer anderen Folge schon mal ausführlich betrachtet haben. Es geht also eher um die Frage, wann eine erstellte Lösung im Hinblick auf das zu lösende Problem als akzeptabel gelten kann. Die beiden diskutieren also, wie man die Akzeptanz einer User Story organisieren kann und welche Rolle dabei die Definition of Done spielt. Dabei geht es natürlich auch um die Frage, wann hierfür der beste Zeitpunkt innerhalb des Sprints ist. Und was passiert, wenn eine User Story nicht "abnahmefähig" ist? Wie üblich gibt es gegen Ende der Folge noch besondere Tipps, wie man mit der Frage zur Abnahme von User Stories umgehen kann. Die folgenden anderen Episoden unseres Podcasts passen zu diesem Thema: Akzeptanzkriterien richtig einsetzen Arten von Product-Backlog-Einträgen: Was gibt's neben User Stories noch? Die Definition of Done aus Sicht von Product Ownern Habt ihr die Diskussionen auch, von wem und wann die User Stories abgenommen werden sollen? Wie regelt ihr das? Wenn du Tipps für uns alle hast, würden wir uns über deinen Input freuen? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist. Und wir freuen uns, wenn du deine eigenen Erkenntnisse 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 (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

4. Von der Produktstrategie zum Product Backlog
   14.11., 06:0014.11.2022, 06:0000:34:44

   Roman Pichler im Gespräch mit Dominique In dieser Folge unterhält sich Dominique mit Roman Pichler über das Thema Produktstrategie. Roman hat gerade erst eine neue Auflage seines Buchs Strategize veröffentlicht und die beiden nehmen dies zum Anlass, um über dieses wichtige Thema zu sprechen. Roman sieht dabei die Produktstrategie als einen Plan bzw. den Weg wie man eine Produktvision erreichen möchte. Die beiden sprechen auch über die Probleme beim Entwickeln von Strategien. Oft beobachtet Roman beispielsweise, dass in einer Organisation gar nicht richtig klar ist, was das Produkt ist. Daneben sieht er auch eine fehlende Bevollmächtigung der Produktmanager bzw. Scrum Product Ownern. Aus der Produktstrategie werden dann Teilziele abgeleitet und eine zielorientierte Roadmap entwickelt. Mit Hilfe der zielorientierten Roadmap können Entwicklungsteams angeleitet und Stakeholder miteinander abgestimmt werden. Von Feature Roadmaps rät Roman dabei aber explizit ab, da es ihm weniger um die Auslieferung von Features geht, sondern mehr um das Erreichen von Zielen. Ein besondere Idee hat Roman noch für die Überführung der Strategie ins Product Backlog. Das aktuelle Product Goal wird als alleiniges Kriterium für die Elemente im Product Backlog genommen und nur Elemente, die auf dieses Ziel einzahlen sollten im Backlog aufgenommen werden. Damit wird das Product Backlog recht schlank aber sehr auf das Produktziel fokussiert. Roman war bereits einmal bei uns zu Gast und hat darüber gesprochen, welche Herausforderungen und Praktiken bestehen, um als Product Owner zu führen (https://produktwerker.de/how-to-lead-in-product-management/). Wenn euch das Thema Produktstrategie interessiert, empfehlen wir euch noch folgende Folgen: The Product Field (https://produktwerker.de/product-field/) Eine Produktstrategie entwickeln (https://produktwerker.de/produktstrategie-entwickeln/) Wardley Mapping - Produktstrategie ist wie Schach (https://produktwerker.de/wardley-mapping/)

5. Hilfe, ich habe das Problem-Produkt geerbt!
   07.11., 06:0007.11.2022, 06:0000:35:11

   Oliver und Tim im Gespräch Als PO verantworten wir in der Regel nicht ein einziges Produkt während unseres langjährigen Product Owner Lebens. Produkte kommen und gehen, wir entwickeln neue Ideen oder begleiten ehemalige Cash-Cows bis ans Ende ihres Produktlebenszykluses. Und es kann vorkommen, dass wir das „Problem Produkt“ erben, an dem niemand in unserer Organisation gerne arbeiten möchte. In dieser Folge sprechen Oliver und Tim über genau diese Situation. Wir können dann als Product Owner nicht auf der grünen Wiese agieren, sondern spielen nun eher im "Brown Field". Häufig bringt die Übernahme solch eines Produktes eine Reihe von Problemen mit sich: Es ist nur noch schwer erweiterbar oder wartbar, es existieren sehr viele Abhängigkeiten zu anderen Produkten oder Mitarbeitenden. Darüber hinaus lässt auch die Verfügbarkeit/Stabilität zu wünschen übrig. Oliver und Tim reflektieren in dieser Folge, an welchen Symptomen wir erkennen können, dass wir an solch einem Problem Produkt arbeiten. Und sie gehen in ihrer Diskussion einen Schritt weiter, indem sie möglichen Ursachen auf den Grund gehen. Die Folge schließt mit unterschiedlichen Lösungsansätzen ab. Was kann ich al sProduct Owner ganz konkret tun, wenn ich mich in der oben beschriebenen Situation befinde? Hierzu geben Oliver und Tim wie gewohnt eine Reihe von praktischen Tipps und Beispiele aus der eigenen Product Owner Praxis.

6. Kennt Kanban Product Owner?
   31.10., 06:0031.10.2022, 06:0000:48:35

   Michael Mahlberg im Gespräch mit Tim Wir sprechen in unserem Podcast über Product Owner und meinen damit implizit Scrum Product Owner. Doch was ist eigentlich mit Kanban und Product Ownern? Kennt Kanban POs? Über diese und viele weitere Fragen spricht Tim in dieser Folge mit Michael Mahlberg, Geschäftsführer von The Consulting Guild GmbH. Als Berater und Begleiter in großen Veränderungsvorhaben und ausgewiesener Kanban-Experte teilt Michael zu Beginn dieser Episode seine Sicht auf die Unterschiede zwischen Scrum und Kanban. Kanban ist Change und startet bei dem, was schon da ist. Die beiden stellen fest, dass die Definition von Product Owner sehr schwammig ist. Diese Unschärfe bezieht sich nicht nur auf die dreiviertel Seite an Beschreibung im Scrum Guide sondern auch in der Interpretation vieler Organisationen. Es gilt, die Frage zu beantworten: Welche Art von Product Owner wollen wir in dem jeweiligen Kontext einsetzen. Michael führt anschließend aus, was Kanban generell zu Rollen sagt. Und ergänzt seine persönlichen Beobachtungen aus der eigenen Beraterpraxis. Wie immer schließen wir mit Tipps und Tricks für dich als PO ab. Weitere Quellen Aufzählungs-Text- Michael Mahlberg: Why are there no Product Owners in Kanban Kanban University: The Official Guide to the Kanban Method Buchempfehlung: Essential Kanban Condensed David Anderson: Kanban - Successful evolutionary change for your technology business Falls du Kontakt mit Michael aufnehmen möchtest, kannst du ihn gerne über Webseite seiner Firma (http://consulting-guild.de/) oder gerne auch direkt via Mail unter mm@consulting-guild.de kontaktieren. Folgt uns Produktwerker auf LinkedIn -> https://bit.ly/3gWanpT Twitter -> https://bit.ly/3NitkPy Youtube -> https://bit.ly/3DIIvhF Infoletter (mit Terminen für unsere kostenfreien Events) -> https://bit.ly/3Why63K

7. Der agile Festpreis - Chancen & Grenzen dieser Vertragsform
   24.10., 06:0024.10.2022, 06:0000:42:55

   Oliver und Tim im Gespräch Manchmal erfordert das Umfeld einer Produktentwicklung mit einem externen Entwicklungspartner eine Umsetzung als "Agiler Festpreis", also einer bestimmten Vertragsform. Was das heißt, wie man es erfolgreich angehen kann und welche Erfahrungen wir damit schon gemacht haben, besprechen Oliver und Tim in dieser Folge. Kaum eine agile Produktorganisation wird sich vermutlich darum reißen, in einem Festpreis-Konstrukt ein Produkt zu entwickeln, aber die Rahmenbedingungen können wir uns in der Realität nicht immer "backen". So gibt es natürlich immer noch viele Produktvorhaben, die in Form eines Projektes gestartet werden und bei dem ein externer Dienstleister zum Einsatz kommt. Bei der Beauftragung von extern Dienstleistungsunternehmen fordern zunehmend mehr Einkaufsabteilungen großes Organisationen oder Konzerne dabei die Beauftragung als "Festpreis", d.h. nicht mehr in Form eines Dienstleistungsvertrags ("Time & Material"). Wie passt das aber zu einer agilen Vorgehensweise? Auch wenn ein agiler Festpreis nach unserer Beobachtung in letzter Zeit zwar zunehmend seltener als Vertragsform vorkommt, als noch vor einigen Jahren, ist es spannend sich dieses Konstrukt noch mal zusammen anzusehen. Vermutlich ist die Forderung nach einem agilen Festpreis auch eher einem nicht agilen Umfeld geschuldet. D.h. die Budgetierungs- und Einkaufsprozesse des Unternehmens sind noch nicht auf die Vorgehensweise einer agilen Produktentwicklung eingestellt. Somit ist ein "Agiler Festpreis" u.E. letztlich nur ein Hilfskonstrukt, um eine agile Produktentwicklung im Kontext eines nicht agilen Organisationsumfeldes starten zu können. Tim berichtet von seinen Erfahrungen eines großen agilen Festpreis-Projektes, das er in einem Konzernumfeld zusammen mit einem externen Entwicklungsdienstleister eingeführt und umgesetzt hat. Tipps was, was er heute anders machen würde und was damals geholfen hat, die Entwicklung letztlich positiv umzusetzen. Tim verweist im Gespräch rund um das Thema Team "Estimation Game" auf die Folge Agiles Schätzen: Magic Estimation. Eine weitere gute Episode unseres Podcast zu dem Themenkomplex ist sicherlich auch "Zusammenarbeit mit einem externen Team vom Dienstleister". Aber auch andere Folgen haben sich schon mit den Dienstleister-Kontext beschäftigt. Mögliche Quellen, um tiefer in das Thema einzusteigen: Stefan Roock, Fritz-Ulli Pieper: Agile Verträge - Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche Boris Gloger, Andreas Opelt et al: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge Hast du selber schon Erfahrungen mit der Vertragsform "Agiler Festpreis" gemacht? Wenn ja, welche Tipps hast du für uns alle? Wir sind wirklich sehr neugierig zu erfahren, welches Vorgehen in deinem Kontext erfolgreich ist/war. Wir freuen uns, wenn du deine eigenen Erkenntnisse mit uns in einem Kommentar des Blog-Artikels teilst oder auf unserer Produktwerker LinkedIn-Seite.

8. Kennst du deine "Inneren Antreiber" als Product Owner?
   17.10., 06:0017.10.2022, 06:0000:48:13

   Christian Klein im Gespräch mit Tim "Seine Inneren Antreiber zu kennen, ist der erste Schritt, um negativen Wirkungen in Stresssituationen entgegenwirken zu können." sagt unsere heutiger Gast Christian Klein, Systemischer Coach und Scrum Master sowie Geschäftsführer von paragraph eins. Tim beleuchtet mit Christian in dieser Episode das Phänomen der sogenannten "Inneren Antreiber", die sich aus dem Kontext der Transaktionsanalyse ergeben haben. "Beeil' Dich!", "Sei perfekt!", "Mach' es allen recht!", "Streng dich an!" und "Sei stark!" sind diese Inneren Antreiber laut Transaktionsanalyse. Daneben gibt es aber z.B. von Kaluza noch die beiden Beobachtungen "Sei vorsichtig!" und "Ich kann nicht!". Nach einer Erklärung der Herkunft und der Ausprägung der einzelnen Treiber - sowie einer Abgrenzung zu den sogenannten Glaubenssätzen - erläutert Christian auch anhand persönlicher Beispiele, wie diese grundsätzlich positiven Verhaltensmuster unter Stress auch umschlagen können und uns im Fortkommen behindern mögen. Um seine eigenen inneren Antreiber zu erkennen, kann der "Antreiber Test" helfen. Ihr findet ihn neben weiteren Erklärungen zu den Inneren Antreibern in einer gut strukturierten Darstellung auch der folgenden Seite von paragraph eins: hier. In der Folge nehmen Tim und Christian auch Bezug auf die folgenden älteren Episoden aus unserem Podcast: Nein sagen als Product Owner Verantwortung als Product Owner übernehmen Wenn ihr Kontakt zu Christian Klein aufnehmen möchtet und mehr mit ihm über dieses oder andere Themen sprechen möchtet, erreicht ihr ihn am Besten via E-Mail (christian.klein@paragraph1.de). Oder vernetzt euch auf LinkedIn mit ihm. Wie bewusst gehst du mit dem Thema "Innere Antreiber" oder Glaubenssätze um? Hast du dich schon mal dabei erwischt, dass sie dein Handeln in einer nicht hilfreichen Weise beeinflussen? Lass uns gerne daran teilhaben. Wir freuen uns, wenn ihr eure eigenen Erfahrungen oder Gedanken mit uns in einem Kommentar hier oder auf unserer Produktwerker LinkedIn-Seite teilt. Und falls euch der Podcast gefällt, freuen wir uns auch immer über eine Bewertung in der von euch favorisierten Podcast-App.

9. Mit mehreren Product Roadmaps arbeiten?
   10.10., 06:0010.10.2022, 06:0000:39:31

   Tim und Oliver im Gespräch Zu Product Roadmaps gibt es in unseren Veranstaltungen immer sehr viele Fragen der Teilnehmenden. Obwohl wir bereits vor einiger Zeit eine immer noch aktuelle und interessante Folge zu Agile Product Roadmaps veröffentlicht haben, ist es wichtig, dass sich Tim und Oliver erneut zu dem Thema unterhalten. Denn bei ihnen geistert die Idee im Kopf herum, ob Product Owner nicht mit mehreren Product Roadmaps arbeiten sollten. Wichtig für die Einordnung dieses Gedanken ist eine Abgrenzung von Project und Product Roadmaps. Daher starten die beiden auch mit einer Unterscheidung von Produkt- und Projektdenken in die Episode. Nun sind die Informationsbedürfnisse der Stakeholder und Nutzer eines Produktes sehr heterogen. Denn alle brauchen verschiedene Daten auf sich stark unterscheidenden Detailierungsgraden, um selber zielgerichtet weiterarbeiten zu können. Tim und Oliver haben sich die gängigen Typen und Templates von Product Roadmaps angesehen und kritisch in Bezug auf die vorab analysierten Informationsbedürfnisse bewertet. Dabei stellen sie den Gedanken vor, ob es hilfreich ist, alle diese Infos in eine Roadmap zu packen oder ob mit mehreren Product Roadmaps arbeiten nicht zielführender ist. Natürlich hinterfragen sie die Idee kritisch. Ist der zu zusätzliche Aufwand gerechtfertigt, führen mehrere Product Roadmaps nicht zu Verwirrung? **Quellen aus der Folge ** ProdPad: https://www.prodpad.com/resources/roadmap-course/ Roman Pichler: GO Product Roadmap John Cutler on Twitter Die Produktwerker Box: Agile Product Roadmaps - das Ende der Gant-Charts Im LinkedIn-Post rund um das Thema dieser Folge gab es eine interessante Diskussion. Dabei hat die von uns geschätzte Kollegin Büşra Coşkuner (Product Management Coach) auf ihren Artikel Agile Roadmaps in Practice verwiesen, in dem sie ihren Ansatz mehrere Roadmap Sichten zu nutzen anschaulich darstellt (inkl. Visualisierung). Insofern können wir Euch diesen Artikel auch sehr empfehlen.

10. Die spannendsten Fragen aus meinen Product Owner Trainings
    03.10., 06:0003.10.2022, 06:0000:39:35

    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

11. Welche Social Skills brauchen Product Owner
    26.09., 06:0026.09.2022, 06:0000:38:22

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

12. Was die Einführung von OKR für Product Owner bedeutet
    19.09., 06:0019.09.2022, 06:0000:45:36

    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.

13. Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis
    12.09., 06:0012.09.2022, 06:0000:43:07

    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.

14. Dienstleister-Steuerung durch eine Retained-Orga - ein Erfahrungsbericht
    05.09., 06:0005.09.2022, 06:0000:44:09

    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.

15. Culture Hacks für mehr Produktorientierung
    29.08., 06:0029.08.2022, 06:0000:41:33

    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.

16. Skalierung der Product Owner-Rolle mit den 5Ts
    22.08., 06:0022.08.2022, 06:0000:52:34

    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.

17. Gedankenaustausch: Was kommt nach UX?
    15.08., 06:0015.08.2022, 06:0000:25:17

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

18. Als Product Owner erfolgreich zusammenarbeiten
    08.08., 06:0008.08.2022, 06:0000:35:56

    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.

19. Biases und wie ich als Product Owner damit umgehen kann
    01.08., 06:0001.08.2022, 06:0000:33:46

    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.

20. Spielend Product Discovery und Delivery unter einen Hut bringen
    25.07., 06:0025.07.2022, 06:0000:44:58

    Konstantin Diener im Gespräch mit Tim Product Discovery soll uns helfen Produktrisiken bei komplexen Problemstellungen frühzeitig zu erkennen und Lösungen zu finden, die von Nutzer:innen wertgeschätzt und nutzbar sind, während wir sie als Team bauen und wirtschaftlich betreiben können. Also lasst kontinuierliche Product Discovery und Delivery Hand in Hand einher gehen! Klingt dir zu theoretisch? Na, dann hör' dir mal das ganz praktische Problem von Konstantin Diener und seinen Leuten bei cosee an! In kürzester Zeit galt es, ein physisches Produkterlebnis wie die Essener Brettspiel-Messe SPIEL in eine digitale, Pandemie-gerechte Form zu übersetzen, die für Besucher:innen und Messeveranstalter gleichermaßen erfolgreich sein musste. Im Gespräch mit Tim liefert Konstantin einen lebhaften Erfahrungsbericht, wie ihnen das durch eine enge Verzahnung von Product Discovery und Delivery gelungen ist. Offensichtlich hätte das Team in diesem engen Zeitrahmen auch schlichtweg gar keine Zeit für eine vorgeschaltete Discovery oder Analyse-Phase gehabt. Also wurde das Problem zur Lösung: ultra-kurze Zyklen und kontinuierliches Nutzer-Feedback führten zu einer sehr gut funktionierenden Messe SPIEL.digital. Details zum besprochenen Projekt, die SPIEL.digital zu erstellen findet man direkt hier auf den Seiten von cosee und zudem ein sehenswertes Video mit einem Vortrag von Konstantin Diener über das gesamte Projekt der SPIEL.digital. Ein Interview aus Sicht von Product Owner und Scrum Masterin über das Projekt ist auch sehr spannend. Zudem gibt es einen Erfahrungsbericht zur Home Office Erfahrung von cosee gibt es bei ihnen im Blog. Konstantin nennt im Gespräch folgende Quellen: Teresa Torres: Continuous Discovery Habits Gojko Adzic: Specification by Example Julia Grace von Slack: Talk über Clarity Diese Folge steht auch mit den folgenden Episoden in einem engen Kontext rund um Product Discovery: Product Discovery in Scrum integrieren (mit Juliana Brell) Kontinuierliche Product Discovery in Teams etablieren (mit Jan Kiekeben) Outcome Goals und Product Discovery (mit Tim Herbig) Wie verbindet ihr Discovery und Delivery bei euch in der Produktentwicklung? Was sagt ihr zu diesem Erfahrungsbericht über die Digitalisierung der SPIEL? Was hat euch begeistert? Lasst uns gerne an euren Erfahrungen 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.