Die Produktwerker
About
Available on
Community
216 episodes
Die Herausforderung als Product Owner lässt einen oft unter dem Druck stehen, alles gleichzeitig zu managen. Wir stellen die brennende Frage: Was mache ich, wenn ich als Product Owner keine Zeit für alles, was ich tun möchte, muss oder sollte, habe? Das Empfinden, keine Zeit zu haben, entsteht oft erst einmal dadurch, dass viel Arbeit liegen bleibt oder man zumindest das Gefühl hat, sich nicht mit den wichtigen Dingen beschäftigen zu können. Man ist getrieben und fühlt sich oft fremdgesteuert. Das Erste, was man dann machen sollte, ist, die eigene Zeit und vor allem den Einsatz der eigenen Zeit zu erheben. Durch das Mittracken der eigenen Zeit und das kritische Analysieren der Ergebnisse (Inspect & Adapt) bieten sich Einblicke, wie man effektiver arbeiten kann. Die wichtigste Methode dabei ist, mehr Fokus herzustellen. Wir diskutieren bewährte Methoden, um den Arbeitsalltag besser zu strukturieren. Von der Anlage eines Backlogs für eigene Aufgaben über die Pomodoro-Technik bis hin zum Einsatz eines Bullet Journals – diese Techniken helfen dabei, den Fokus zu schärfen und produktiver zu sein. Oft ist der Fokus aber gar nicht so schnell herstellbar. Daher haben wir Tipps besprochen, wie man sofort mehr Zeit gewinnen kann. Wir erörtern, wie das Ausschalten von E-Mail-Benachrichtigungen, das Verkürzen von Meetings, das Einfordern von Meeting-Agendas und der Grundsatz „Nach drei E-Mails lieber anrufen“ den Arbeitstag effizienter gestalten können. Zudem betonen wir die Wichtigkeit, feste Fokuszeiten im Kalender zu planen und diese auch einzuhalten. Für die langfristige Perspektive besprechen wir Strategien wie das Setzen von regelmäßigen Terminblockern im eigenen Kalender, das Delegieren von Aufgaben und den Aufbau einer Stakeholder-Community. Diese Ansätze unterstützen nicht nur eine bessere Zeiteinteilung, sondern auch eine effiziente und effektive Zusammenarbeit. Abschließend teilen wir einige Ratschläge, darunter die Kraft des Bullet Journals, um sich jeden Morgen auf die wichtigste Aufgabe zu konzentrieren, bevor digitale Geräte eingeschaltet werden. Außerdem betonen wir die Bedeutung eines nachhaltigen Arbeitstempos (sustainable pace), das langfristigen Erfolg sichert und das Einplanen von Pausen beinhaltet. Am Ende muss man schon fast sagen, dass keine Zeit zu haben eine Lüge ist. Ehrlicherweise heißt es nämlich oft, dass andere Sachen wichtiger sind. Wir würden uns aber freuen, wenn ihr uns schreibt, wie ihr damit umgeht keine Zeit zu haben. Was sind eure Techniken, Strategien und Tipps, die ihr mit andern Teilen könnt? Gerne hier als Kommentar oder auf LinkedIn.
Als Product Owner und Produktmanager führe ich in unterschiedlicher Art und Weise. Daher blickt Oliver in dieser Podcastfolge gemeinsam mit Simonetta Batteiger erneut auf das Thema Leadership Skills. Simonetta arbeitet als Beraterin, Trainerin und zertifizierte Coachin für Produktführungskräfte und Executives und legt dabei auch einen Fokus auf Inclusive Leadership. Denn ihrer Meinung nach ist erfolgreiche Produktarbeit Führungsarbeit. Zu Beginn des Gespräches teilt Simonetta ihre Sicht, warum Leadership für mich als Product Owner so wichtig ist. Deshalb gilt es natürlich auch zu klären, was Leadership überhaupt ist und wie das mit der Verantwortlichkeit als Produktmensch zusammenpasst. Simonetta hat in einem Talk auf den PO Days bereits drei essentielle Skills geteilt. In der Podcastfolge mit Oliver gehen die beiden auf die einzelnen Aspekte noch einmal detaillierter ein. Erstens ist es elementar, dass die Richtung in die unser Produkt entwickelt werden soll, klar ist und von allen Beteiligten verstanden wird. Als Produktmanager obliegt mir vor allem dafür zu sorgen, dass eine Vision, eine Strategie und eine Product Roadmap existiert und diese kommuniziert werden. Zweitens kann jede Führungskraft Coaching Habbits entwickeln, die in der Zusammenarbeit mit anderen Menschen helfen können. Und drittens gestalte ich das Team, mit dem ich das Produkt entwickle, auch immer bis zu einem gewissen Punkt mit. Denn in unserer Verantwortlichkeit werden wir niemals alleine agieren und alleine erfolgreich sein können
Für diese Folge haben wir uns in der Vorbereitung richtig Zeit genommen. Wir wollten ursprünglich über alle typischen Fallen sprechen, in die Product Owner immer wieder tappen. Herausgekommen ist eine Sammlung von 10 Fallen, die Product Owner immer wieder machen. Eine Top 10? Vielleicht. Aber in erster Linie die 10 Fehler, die unserer Meinung nach am dringensten vermieden werden sollten. Die Reihenfolge ist natürlich keine Priorisierung. Je nach Kontext sind andere Fallen kritischer, wichtig oder häufiger. Aber genug der Einleitung. Hier unsere 10 Fehler, in die Product Owner immer wieder tappen: - Nicht auf sich selbst achten - Zum Projektleiter werden - Übernahme von Scrum Master Tätigkeiten - Selbstorganisation des Teams stören - Keine Klarheit über die Rolle haben - Schlechte Stakeholder-Kommunikation - Kundenbedürfnisse zu wenig wahrnehmen - Keine Insights sammeln - Die Produktvision aus den Augen verlieren - In Lösungen statt in Opportunities denken Wir glauben daran, dass diese 10 Fallen immer wieder auftreten und das wir uns als Product Owner dessen bewusst sein müssen. Für einige werden es andere Fallen sein aber am Ende geht es doch darum ein erfolgreiches Produkt zu entwickeln und sich dabei auch wohl zu fühlen. Wir sollten den Wert unserer Arbeit für uns, unser Team, unser Produkt und unserer Organisation steigern. Die Auswahl ist natürlich sehr subjektiv. Das ist uns vollkommen klar. Wir glauben aber dennoch vielleicht den ein oder anderen Impuls bieten zu können. Und wer weiß, vielleicht machen wir bald zu jeder dieser Fallen eine eigene Folge. Vorher aber die Frage an euch, welche Falle euch immer und immer wieder begegnen, entweder weil ihr selbst hineingeratet oder andere dabei beobachtet. Lass gerne einen Kommentar mit euren Erfahrungen hier oder auf dem Post bei LinkedIn.
Wir haben einen Website-Relaunch vollzogen und dabei versucht, agil und inkrementell vorzugehen. Das ist aber gar nicht so einfach, weil das auch nicht jede Agentur mitmacht, die man ggf. dafür braucht. Einiges an dieser Produktentwicklung hat gut geklappt - bei anderen Sachen haben wir selbst mal wieder eine Menge gelernt. Wir berichten, welche User Probleme und Business Needs uns initial dazu gebracht haben, unser "Produkt" Website nochmal grundlegend zu überarbeiten und wie wir diese Aufgabe angegangen sind. Natürlich berichten wir auch darüber was gut geklappt hat und über unsere Fehler. Natürlich kämpfen auch wir selbst mit der Frage, wann es "gut genug" ist bzw. wann das Ergebnis unserem Anspruch genügt um live zu gehen. Tim und Oli berichten zudem, wie sie die Zusammenarbeit mit der Agentur agil gestalten konnten und welche Erfolgsmetriken sich die Produktwerker selber für den Website-Relaunch gesetzt haben. Ein großes Problem welches wir mit dem Website-Relaunch lösen wollen, ist die bessere Auffindbarkeit von unseren ganzen älteren Podcast-Folgen. Da steckt noch soviel wertvoller Content drin, aber bei nun schon 211 Episoden fand man diese "Perlen" gar nicht mehr so einfach. In den üblichen Podcast-Playern ist das eh nahezu unmöglich, aber auf unserer Website gab es halt auch nur eine unsäglich lange Liste. Also haben wir nun eine Schlagwortsuche und vor allem eine Filterung nach thematischen Kategorien eingebaut. Insbesondere zu dieser neuen Podcast-Suche wollen wir euch nun ganz herzlich um euer Feedback bitten und geben euch im Gegenzug die Chance einen tollen Preis zu gewinnen. Geht einfach auf der Website auf die Seite Podcast und klickt auf den Feedback-Button. Unser allen Einsendungen von Feedback verlosen wir einen Platz in unserem Strategietraining am 23./24.April in Köln. Zu dieser Episode passen diese älteren Folgen: - Als Product Owner auf Seiten einer Agentur - Zusammenarbeit mit einem UX-Dienstleister - Der Product Owner aus Sicht eines Dienstleisters Wir möchten uns an dieser Stelle ausdrücklich bei unserem geschätzten Kooperationspartner Webrunners und Geschäftsführer Adrien Simon bedanken. Insbesondere gilt aber unser Dank Finja Kolzem, die für und mit uns verantwortlich die neue Seite gebaut hat. Danke für Deinen großartigen Einsatz liebe Finja! Ebenfalls geht ein großes Dankeschön an Marek Nowacki (snckbl media) für unser überarbeitetes Corporate Design. Welche Erfahrungen habt ihr evtl. schon mal bei der Erstellung einer neuen Website gemacht? Inwiefern war das für euch inkrementell machtbar und hattet ihr dafür einen passenden Dienstleister bzw. Agentur, die dabei mitgespielt hat? 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 Produktwerkern 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
Ist der Product Owner eine laterale Führungskraft? Hat man in der Verantwortung als Product Owner auch Führungsverantwortung? Und wenn ja, wie stellt sie sich dar? Tim und Dominique klären in dieser Episode zunächst mal die Frage, was denn unter lateraler Führung zu verstehen ist und ob man als Product Owner grundsätzlich eine Führungsrolle inne hat. Dies leben Unternehmen tatsächlich auch sehr unterschiedlich und oft hängt es auch davon ab, welches Ansehen und Rollenverständnis im Rahmen der Produktentwicklung der Product Owner Verantwortlichkeit zugestanden wird. Es kommt also sehr oft auf das Hierarchieverständnis innerhalb der Organisation an, ob ein Product Owner als laterale Führungskraft im Unternehmen wirken kann. Die Herausforderung ist dann, ohne formale Macht eine (inhaltliche) Führung zu übernehmen. Führung bezieht sich für Product Owner dann vor allem für das Produkt und die Führung im Sinne der zielgerichteten Ausrichtung des Scrum Teams auf Produktvision und Produktziele. Eine entscheidende Frage ist aber auch, wie sich die Stakeholder gegenüber der Product Owner Rolle verhalten bzw. ob sie einen Product Owner als laterale Führungskraft akzeptieren. Ferner diskutieren die beiden Produktwerker aber auch, wo laterale Führung ggf. nicht hilft oder vielleicht sogar schädlich ist. Mit einer zusammenfassenden Betrachtung der Vorteile von lateraler Führung als Product Owner schließt die Folge ab. Das Thema war übrigens ein Hörerwunsch. Wir freuen uns immer wieder, wenn ihr uns Themenvorschläge macht. Im Gespräch wird auf diese Folgen verwiesen: Das Product Operating Model von Marty Cagan Introvertiert als Product Owner - geht das? Stakeholder Community Product Principles Und diese Literaturempfehlungen gab es: Patrick Lencioni: The Five Dysfunctions of a Team Geoff Watts: Product Mastery Wie ist eure Meinung? Kann die Product Owner die Verantwortlichkeit so leben, dass er bzw. sie als laterale Führungskraft zu wirken? Sind bei euch im Unternehmen Product Owner Führungskräfte bzw. werden als solche betrachtet? 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
Diesmal hatten wir das Vergnügen, Annette Greil (https://www.linkedin.com/in/annette-greil-7a6333107/) zu begrüßen, die ihr Rollenverständnis und ihre Erfahrungen als Product Coach bei der METRO.digital mit uns teilte. Product Coaching befähigt die Organisation über traditionelle Produktentwicklung hinauszugehen, um letztendlich herausragende Produkte zu entwickeln. Eine typische Woche im Leben eines Product Coaches, so Annette, gibt es eigentlich nicht. Sie verbringt ihre Zeit mit einer Vielzahl von Aufgaben, von Einzelgesprächen mit Teammitgliedern über die Moderation von Workshops bis hin zur Analyse von Produktstrategien und der Optimierung von Arbeitsabläufen. Product Coaches arbeiten intensiv mit Product Ownern, Product Managern und Product Leadern zusammen. Die erforderlichen Kompetenzen für diese Rolle sind ebenso vielfältig, einschließlich starker Kommunikationsfähigkeiten, Empathie, einem tiefen Verständnis für Produktmanagement-Praktiken und einer ausgeprägten Fähigkeit, komplexe Probleme zu lösen. Die digitale Landschaft ändert sich rasant, und als Coach muss man sich kontinuierlich weiterbilden, um auf dem neuesten Stand der besten Praktiken und Technologien zu bleiben. Annette schließt nicht nur mit einigen wertvollen Tipps für angehende Product Coaches ab, sondern wagt auch einen Blick in die Zukunft. Wie wird sich das Product Coaching in den kommenden Jahren verändern? In der Folge haben wir kurz auch auf unsere OKR Folge referenziert. Hört dort auch gerne rein, um mehr über OKR und ihre Rolle für Product Owner zu erfahren -> https://produktwerker.de/okr-product-owner/
Dominique und Oliver greifen in dieser Episode eine Frage auf, die uns vor einiger Zeit ein Zuhörer mit einem Augenzwinkern gestellt hat: “Wann lohnen sich Product Owner?” Und vor allem, wann lohnt es sich nicht, diese Verantwortlichkeit in Unternehmen zu etablieren. Aus der Diskussion ergibt sich eine gute Zusammenfassung, was aus ihrer Sicht einen Product Owner ausmacht bzw. bei welchen Rahmenbedingungen man von einem Product Owner sprechen kann. Sofern ich die im Scrum Guide formulierte Vorstellung eines POs ernst nehme, gewinnen Teams durch eine bevollmächtigte Product Owner vor allem drei Dinge: klare Verantwortlichkeit bei Produktentscheidungen, Entscheidungsgeschwindigkeit und Fokus auf die Kunden- und Unternehmenbedürfnisse. Wichtig ist hierbei, dass POs auch Produktmanager sein dürfen und können. Förderung von Agilität Als besonders wichtig stellen Dominique und Oliver heraus, dass auch ein Product Owner ein besseres Verständnis für Hypothesen getriebenes Arbeiten und Produktentscheidungen unter Unwissenheit in seinem eigenen Umfeld entwickeln kann. Auch hier kann die Einführung der Rolle lohnenswert sein. Die beiden Gesprächspartner diskutieren natürlich auch die Kehrseite der Medaille, nämlich wann Product Owner auch nicht wirklich weiterhelfen. Und wie immer schließen sie die Podcastfolge mit praktischen Tipps & Tricks aus dem eigenen persönlichen Erfahrungsschatz ab.
In dieser Folge haben wir Marcel Mellor, Product Lead von sipgate, zum Thema "Innovation im Unternehmen" zu Gast. Marcel ist Produktstratege und spannender Weise auch Science Fiction Autor, was ja per se schon nah an innovativen Themen ist. Tim diskutiert im Rahmen eines Erfahrungsberichts zum Innovationsprodukt "satellite" mit Marcel, wie Innovation im Unternehmen gelingen kann und ob und wie eine Innovation z.B. in einem sprint-basiertem Ansatz wie Scrum gut gelingen kann. Natürlich steht zu Beginn die Frage, was Innovation für Marcel bedeutet und wie er ganz persönlich zu dem Interesse an Innovationsarbeit gekommen ist? Besonders spannend sind die Learnings, die Marcel Mellor im Zuge der Innovationsreise mit dem Produkt satellite selbst für sich über Innovation gelernt hat. Die beiden diskutieren, welche Erfolgsfaktoren und Hindernisse sie für Innovation im Unternehmen sehen. Ein Bezug zu Innovation und KI darf dabei natürlich auch nicht fehlen. In Summe ist ein sehr inspirierender Erfahrungsaustausch mit einem echten Innovationsprofi entstanden. Empfohlene Quelle zum Thema Innovation im Unternehmen: - Steven Johnson:- Aufzählungs-Text Wo gute Ideen herkommen: Eine kurze Geschichte der Innovation Diese alten Episoden wurden im Gespräch erwähnt: - Mit Storytelling andere von Deinen Produktideen überzeugen - Warum scheint die Product Owner Rolle so schwer zu sein? (mit Markus Andrezak) - Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen? (mit Markus Andrezak und Sohrab Salimi) Wenn ihr mehr Content von Marcel Mellor hören bzw. lesen wollt, folgt ihm auf LinkedIn oder hört einen seiner beiden Podcasts: - Podcast: "Skalierbar" (mit David Ranftler) - Podcast: Tech is Good - Das aktuelle Buch von Marcel Mellor: Das Register - Personal Website: marcelmellor.com Und falls ihr euch für das Product "satellite" näher interessiert, gibt's hier alle Infos: https://satellite.me/ Wird echt Innovation im Unternehmen aus Deiner Sicht durch agile Frameworks wie z.B. behindert oder gefördert? Oder hälst Du die Wahl des Ansatzes für unerheblich für den Erfolg der Innovation? 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
Das Product Backlog ist die eine einzige Stelle, an der wir Arbeit organisieren, die für unser Produkt getan werden soll. Klassischerweise ist das Product Backlog eine priorisierte Liste. Aber muss es das sein? Wichtig ist doch vor allem die Priorisierung, oder? In dieser Folge unterhalten sich Oliver und Dominique über weitere Alternativen, wenn es um eine gute Organisation des Product Backlogs geht. Alternativen lassen sich schnell finden. Einige Methoden sind recht bekannt, wie beispielsweise die User Story Map. Hier bewegen wir uns entlang der User Journey und organisieren das Product Backlog in zwei Dimensionen. Aber auch andere Methoden wie Classes of Work können hilfreiche Übersicht geben. Hierbei wird die Arbeit in verschiedene Arten aufgeteilt und seperat voneinander priorisiert. Und dann gibt es noch Alternativen aus anderen Bereichen wie beispielsweise ein Funnel Backlog, bei dem wir uns mehr darauf konzentrieren, welche Arbeiten in welchen Funnelbereichen gerade notwendig sind. Und dann sind da noch Impact Maps, Vorgangsknotennetzpläne und einige mehr. Am Ende haben die alternativen Organisationsformen alle ihre Vor- und Nachteile. in unserer Arbeit als Product Owner, Product Manager und Product Leader müssen wir daher abwägen, welche Art sich gerade mehr als andere anbietet. Mal kann das Aufzeigen von Abhängigkeiten wichtiger sein, mal die absolute Serrialisierung von Arbeit. Oft hängt es am Ende auch an der Zusammenarbeit mit der eigenen Stakeholdercommunity.
Die Gründung eines eigenen Unternehmens ist eine faszinierende und reizvolle Angelegenheit, besonders für Personen, die in der Produktentwicklung tätig sind. Diese Tätigkeit ermöglicht es, eigene Produkte intensiver zu formen und persönliche Ideen Wirklichkeit werden zu lassen. Ein interessanter Ansatz hierbei ist das Ausgründen aus einem Konzern. Für Positionen wie Product Owner, Product Manager oder Product Lead kann dies eine attraktive Option sein. In diesem Zusammenhang haben wir uns mit Christian Fahl unterhalten, der das Unternehmen Loql als Ausgründung aus der REWE Group mit ins Leben gerufen hat. Christian ist heue Product Lead bei Loql und teilt seine Erfahrungen über den Gründungsprozess und wie alles für ihn begann. Besonders aufschlussreich sind die Schritte, die er noch vor der eigentlichen Ausgründung unternommen hat. Diese Phase ist nicht ohne Herausforderungen, auf die Christian ebenfalls eingeht. Seine persönliche Perspektive und Erfahrungen bieten hierbei spannende Einblicke. Ein weiterer wichtiger Aspekt der Ausgründung ist die Zusammenarbeit zwischen dem neu gegründeten Unternehmen und dem Mutterkonzern. Auch hierzu liefert Christian interessante Informationen. Zum Abschluss gibt er noch einige Ratschläge, die ihm im Rückblick geholfen haben, den Prozess der Unternehmensgründung zu erleichtern.
Gegen Ende eines jeden Jahres kommen die Thema Budget- und Roadmapplanung wieder auf die Tagesordnung. Und in die Planung dieser jährliche Roadmap werden wir als Product Owner*in dann intensiv eingebunden. Aber lohnt der Aufwand, den wir in diese Themen investieren? Tim und Oliver diskutieren diese Fragen vor allem auf Basis ihrer eigenen Erfahrungen. Nachdem die beiden reflektiert haben, warum eine jährliche Planung für viele Unternehmen immer noch wichtig ist, geben sie einen kurzen Überblick über die Unterschiede zwischen Projekt- und Produkt-Roadmaps. Da aber die Mehrzahl unserer Ideen für die Produktentwicklung nicht funktionieren oder zumindest mehrere Iteration brauchen, bis sie die Business-Ziele generieren können die wir uns erhofft haben, stellt sich die Frage, ob eine jährliche Roadmapplanung auch wegen der Kompexität und Unsicherheiten im eigenen Produktkontext überhaupt sinnvoll ist. Tim und Oliver bieten in dieser Folge einige Lösungsansätze, wie man besser mit Roadmaps umgehen und arbeiten kann. Wir immer teilen die beiden zum Abschluss der Episode Tipps und Tricks.
Der Berufsstand der UX-Professionals hat in den letzten Jahren eine Differenzierung erlebt, und es sind neue Teildisziplinen entstanden. Eine dieser Disziplinen ist das UX-Management, und mittlerweile gibt es einige Menschen, die die Verantwortung als UX-Manager in Projekten und Organisationen übernehmen. Durch ihre Arbeit prägen sie die Produktentwicklung; es lohnt sich also zu fragen, was das genau ist und wie diese Disziplin Menschen in Verantwortungspositionen als Product Owner, Product Manager oder Product Lead bei der Entwicklung großartiger Produkte unterstützt. Dazu haben wir den UX-Experten Andreas Hinderks eingeladen, der nicht nur beruflich viel mit dem Thema zu tun hat, sondern auch intensiv dazu forscht. Wir klären also zunächst, was UX-Management ist, was manche vielleicht darunter verstehen und wie sich diese Tätigkeit in den Kontext der Produktentwicklung einfügt. Dabei wird schnell deutlich, dass Management nicht ohne Strategie, Ziele und Ressourcen gedacht werden kann. Für Produkte sollten also idealerweise Ziele für eine gute UX gesetzt, eine Strategie zur Zielerreichung festgelegt und die angemessenen Ressourcen zugeteilt werden. Dass dies am besten im Team funktioniert, versteht sich fast von selbst, denn es geht um die Schaffung von Erlebnissen für Menschen. Natürlich tauschen wir uns mit Andreas auch über gute und schlechte Praktiken aus, damit nicht dieselben Fehler wiederholt werden müssen. Nach einigen Prognosen zur Zukunft des UX-Managements gibt Andreas zum Schluss noch einige weitere hilfreiche Tipps zum Thema UX-Management für Product Owner.
Velocity ist in der agilen Softwareentwicklung, vor allem in Scrum, weit verbreitete Metrik, die die Arbeitsmenge eines Teams in einem Sprint misst. Aber ihre Nutzung birgt auch bestimmte Grenzen, die Tim und Dominique in dieser Folge kritisch hinterfragen. Velocity, meist in Story Points gemessen, gibt an, wie viel ein Team in einem (durchschnittlich) Sprint leistet. Sie ist hilfreich für die Sprint-Planung und kann die Vorhersagbarkeit verbessern. Doch als reine Output-Metrik vernachlässigt sie wichtige Aspekte wie Outcome und die Qualität der Arbeit. Ein kritischer Punkt, den Tim und Dominique betonen, ist, dass Velocity eine relative Größe ist, die nur innerhalb eines Teams Bedeutung hat. Der Vergleich von Velocity zwischen verschiedenen Teams ist problematisch und kann vorsichtig gesagt mindestens zu Missverständnissen führen. In der Diskussion heben die beiden hervor, dass Teams Velocity als Werkzeug zur Reflexion nutzen sollten, nicht als starres Ziel. Es geht darum, den tatsächlichen Wert und die Qualität der Arbeit zu verbessern - nicht um die reine Liefergeschwindigkeit als Selbstzweck. Andere Metriken, die Kundenzufriedenheit und Outcome zu messen, erscheinen sogar wichtiger zu sein. Interessanter Weise wurde die Velocity früher in Scrum Trainings viel stärker betont, Zusammen mit dem allgemeinen Trend, mehr Wert auf Outcome bzw. Wirkung zu legen, statt eine reine Product Delivery zu fokussieren, wird auch in den Trainings immer seltener über Velocity gesprochen. Neben den Problemen und Fehlern im Umgang mit Velocity betrachten Dominique und Tim natürlich auch die Vorteile des Einsatzes dieser Metrik. Weiterhin geben sie Tipps zum richtigen Einsatz von Velocity. In dieser Folge wird auf diese Episoden im Gespräch verwiesen: - Wann ist das fertig? Keine Ahnung, wir sind ja agil! - Forecasting in der agilen Produktentwicklung - Evidence Based Management - eine empirische Suche nach Wert Nutzt ihr bei euch Velocity als Metrik? Wenn ja, wie gelingt es euch, dass diese Metrik auch positiv im Hinblick auf den Wert des entwickelten Produkts wirkt und nicht zu einem Team-Kontrollinstrument verkommt? 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
Zu Beginn des Jahres bietet es sich an einmal Gedanken zu den eigenen, ganz persönlichen Zielen im neuen Jahr zu machen. In dieser Folge teilt Dominique eigene Erfahrungen und Tipps rund um das Setzen effektiver, persönlicher Ziele – sowohl für das Produkt als auch für die persönliche Entwicklung. Das Setzens von Zielen ist entscheidend, um einen klaren Fokus zu erzeugen. Ein zentrales Thema ist schon ein echter Klassiker: smarte Ziele. Diese Methode hilft dabei, Ziele zu definieren, die spezifisch, messbar, erreichbar, relevant und zeitgebunden sind. Ein besonderer Fokus liegt darauf, wie diese Prinzipien auf die einzigartigen Herausforderungen von Product Ownern und Product Leadern angewandt werden können. Persönliche Ziele, die greifbar und messbar werden, können in der Regel besser erreicht werden. Gerade Produktverantwortlichen müsste es besonders leicht fallen diese Ziele anschließend auch zu bewerten und in eine Reihenfolge zu bringen. Für die persönliche Entwicklung bedeuten klare Ziele: Von der Steigerung spezifischer Kompetenzen bis hin zur Bedeutung von Work-Life-Balance mit den richtigen Maßnahmen die richtigen Schritte gehen. Vielzuoft entscheiden sich Menschen für kurzfristige Belohnungen und vbergessen dabei, dass längerfristige Ziel im Blick zu behalten. Dazu wurden in dieser Folge einige praxisnahe Tipps und Methoden geteilt. Vorgestellt wurden verschiedene Tools und Apps zur Zielverfolgung sowie Zeitmanagement-Strategien, die speziell für die Bedürfnisse von Product Ownern und Product Leadern zugeschnitten sind.
In dieser besonderen Zeit des Jahres, wo wir einen Moment innehalten und das Vergangene reflektieren, möchte ich meine Gedanken und Erfahrungen zum Thema Reflexion mit euch teilen. Diese Zeilen begleiten unsere Podcastfolge, in der Dominique ausführlich über Reflexion spricht, ein Thema, das unserer Meinung nach für Product Owner, Product Manager und Product Leads gleichermaßen relevant ist. Reflexion ist ein wesentlicher Bestandteil des agilen Produktmanagements, bekannt durch Praktiken wie die Retrospektive. Es geht um mehr als nur das Zusammenfassen vergangener Ereignisse; es ist eine Gelegenheit, aus Erfahrungen zu lernen und sich persönlich sowie beruflich weiterzuentwickeln. Für uns ist es wichtig, regelmäßig innezuhalten und sowohl berufliche als auch private Erlebnisse zu reflektieren. Dominiques Reflexionstechniken, die er gerne empfiehlt: Das weiße Blatt: Hierbei man sich stumpf mit einem leeren Blatt Papier hin und notiert alles, was einem zum vergangenen Jahr einfällt. Dies kann zu einer Mindmap oder Sketch Note werden und hilft, die eigenen Gedanken zu ordnen und neue Perspektiven zu gewinnen. Klingt irgendwie zu simpel aber hilft. Reflektionsgespräche: Diese Gespräche führt man mit vertrauten Personen, um Feedback zu bekommen und die eigenen Gedanken weiterzuentwickeln. Es geht hierbei nicht nur um Kritik, sondern um das Erkennen neuer Möglichkeiten und das Ausloten unterschiedlicher Perspektiven. In der Regel reichen zwei bis drei Gespräche. Die persönliche Retrospektive: Nicht nur am Jahresende sondern einmal im Monat kann man sich die Zeit nehmen für eine tiefgehende Reflexion der eigenen Aktivitäten und Entscheidungen. Dies beinhaltet das Durchgehen des eigenen Kalenders und Trello-Boards, um zu verstehen, was man erreicht hat und was noch aussteht. Reflektieren allein genügt nicht. Es geht darum, Konsequenzen aus den eigenen Erkenntnissen zu ziehen. Das bedeutet, Entscheidungen zu treffen, Ziele zu setzen und konkrete Maßnahmen zu ergreifen, um das Beste aus der eigenen Zeit und den eigenen Fähigkeiten herauszuholen. Und nach einer intensiven Reflexionsphase ist es wichtig, sich auch zu belohnen. Das kann eine Aussicht auf neue Ziele sein, eine kleine Freude wie ein leckeres Essen oder einfach die Zufriedenheit, sich selbst Zeit und Raum für persönliches Wachstum gegeben zu haben. Wir hoffen, dass diese Einblicke euch als Impulse dienen und euch gleichzeitig ermutigen die notwendige Zeit für Reflexion zu nehmen. Nutzt die ruhige Zeit zwischen den Jahren, um über das vergangene Jahr nachzudenken und Pläne für die Zukunft zu schmieden. In diesem Sinne wünschen wir euch besinnliche Feiertage und einen guten Start ins neue Jahr!
Was ist ein Produkt? Und ist eine Dienstleistung ein Produkt? Beides sind oft gehörte Fragen. Dominique und Tim greifen diese Fragen auf und diskutieren in dieser Episode rund um den Produktbegriff. Zunächst gucken sie sich gängige Definitionen an. Ein übliches Produktverständnis umfasst auch Services bzw. Dienstleistungen. Oft fällt es Organisationen aber noch schwer, die Frage zu klären "Was ist ein Produkt" und wie schneiden wir dementsprechend die jeweiligen Teams rund um die Produkte. Aber was ist, wenn ich als Product Owner nach diesen Definitionen gar kein "Produkt" habe? Vielleicht verantwortet man also eine Komponente, ein Feature oder eine Plattform. Kann man dann dennoch produkthaft vorgehen? Und was ist mit internen Produkten? Sind das eher Anwendungen oder kann man sie auch als Produkt bezeichnen? In diesem Zusammenhang diskutieren die beiden auch kurz, ob und wann eine API ein Produkt ist und wann nicht. Am Rande sprechen die beiden auch nochmal über die Abgrenzung von Nutzer und Kunde. Auch hier werden in der Praxis die Begriffe oft etwas zu nachlässig verwandt. Empfohlene Quellen zur Frage "Was ist ein Produkt": - Marty Cagan (svpg): What is a Product? - Definition "Was ist ein Produkt" aus dem Scrum Guide - Roman Pichler "Six Types of a "Product" Owner" In dieser Episode empfohlene Podcast Folgen: - Vom Projektleiter oder Teamleiter zum Product Owner - Scrum Product Owner vs. SAFe Product Owner - ein Missverständnis - Wardley Mapping - Produktstrategie wie ein Schachspiel - POEM - Product Ownership Evolution Model - Evidence Based Management - eine empirische Suche nach Wert Kennst du diese Fragestellung "Was ist Produkt"? Wir die Diskussion bei euch auch im Rahmen des Produktschnitts geführt? Wie definiert ihr eure Produkte? Und wie geht ihr mit Dienstleistungen bzw. Services 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
"Wir werden das Produkt einstellen - es ist zwar noch erfolgreich, passt aber nicht mehr zur künftigen Unternehmensstrategie." Wenn man solch eine Entscheidung hört, ist klar, dass das Ende des Produktlebenszyklus naht. Aber bis dahin ist ja eben auch noch ein Weg zu gehen, für den es ein motiviertes Team braucht. Der Ramp Down eines Produktes gehört schließlich unzweifelhaft auch zur Produktentwicklung. Zu Beginn des Jahres hat XING (bzw. die New Work SE) die durchaus erfolgreichen Produktbereiche XING Events und XING Gruppen eingestellt, um die eigenen Kräfte zu bündeln und den Fokus auf die neu gewählte Strategie zu legen. Ein wirklich mutiger Schritt. Unser heutiger Gast Thomas Gläser, Director Product Experience bei der New Work SE, hat dies hautnah miterlebt und musste (oder wohl besser gesagt "durfte") diese spannende Phase als verantwortlicher Product Leader begleiten. Im Gespräch mit Tim berichtet er, wie er die Motivation für die letzte Produktphase im Team hochgehalten hat und wie er sich selbst dabei gefühlt hat. Eine spannende Diskussion über eine Erfahrung, die nur wenige Produktmenschen machen dürfen. Im Gespräch werden die folgenden Quellen genannt: - Killed by Google (killedbygoogle.com) - Liberating Structures: Ecocycle Planning (liberatingstructures.de/ecocycle-planning/) - Aufräumen mit Methode: Analogie zu Marie Kondo - Buch von Ernest Becker: The Denial of Death Zu dieser Episode passt auch gut diese ältere Folge: - Features wegwerfen - was braucht es dafür außer Mut? Wer mit Thomas Gläser in Kontakt treten möchte, guckt sich am Besten mal seine persönliche Webseite (thomasglaeser.de) an oder folgt ihm auf LinkedIn. Dort teilt er regelmäßig seine Gedanken zu Produktthemen und über die diversen Veranstaltungen auf denen er aktiv ist. Zudem freut sich Thomas zur Kontaktaufnahme auch über eine direkte E-Mail an ich@thomasglaeser.de. Hast du auch schon mal die Erfahrung "Produkt einstellen" gemacht? Welche Überlegungen gab es bei euch? Welche Befürchtungen hattest du, die sich am Ende vielleicht gar nicht eingestellt haben? Wir sind gespannt, von euren Ergebnissen zu hören! 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
Für Product Owner spielt die tägliche Interaktion mit Softwareentwicklern eine Schlüsselrolle. Sie sind die Stakeholde, mit denen wir im täglichen Arbeiten mit am häufigsten zu tun haben. Von den ganzen Diskussionen über die Absprachen zu Anforderungen bis hin zu gemeinsamen Entscheidungen – die Dynamik dieser Beziehung beeinflusst wesentlich den Erfolg der Produktentwicklung. Um tiefer in diese Beziehung einzutauchen hat Dominique in dieser Folge das Vergnügen, mit Jacob Pawlik (https://www.linkedin.com/in/jacob-pawlik/) zu sprechen. Jacob ist Head of WebTec bei der Scopevisio AG und bringt eine wertvolle Perspektive in unser Gespräch ein: die Erwartungen von Entwicklern an Product Owner. Hauptthemen unserer Diskussion: - Entwicklererwartungen: Was genau erwartet ein Developer von einem Product Owner? Jacob beleuchtet diese Frage aus seiner Erfahrung. - Produktvision: Wie wichtig ist die Produktvision aus der Sicht eines Entwicklers und wie beeinflusst sie die tägliche Arbeit? - Augenhöhe und Hierarchien: Warum sind diese Aspekte entscheidend und wie sollte man mit ihnen umgehen, um eine effektive Zusammenarbeit zu fördern? - Red Flags in der Zusammenarbeit: Jacob teilt seine Einsichten darüber, was in der Zusammenarbeit mit einem Product Owner als Warnsignal gelten kann. - Refinement, Planning und Review: Was braucht ein Product Owner wirklich für diese Prozesse? Was erwartet ein Entwickler in diesen Phasen? - Die Retrospektive mit Product Ownern: Ein Blick auf die Bedeutung und Durchführung effektiver Retrospektiven. - No-Gos für Product Owner: Jacob spricht über häufige Fehler, die Product Owner vermeiden sollten. - Tipps zur Verbesserung der Zusammenarbeit: Abschließend gibt Jacob praktische Ratschläge, wie Product Owner die Zusammenarbeit mit Entwicklern verbessern können. Diese Episode bietet tiefe Einblicke in die Beziehung zwischen Product Ownern und Entwicklern. Wir hoffen, dass ihr diese Folge genauso aufschlussreich findet wie wir. Aber vielleicht habt ihr auch andere Erfahrungen gemacht oder habt eine abweichende Meinung. Lasst es uns gerne wissen. Entweder als Kommentar zum Blogpost dieser Folge oder bei einem der Posts auf Social Media.
Wenn Unternehmen nicht genügend interne Product Owner haben, beauftragen sie zunehmend Interim Product Owner. Meist wird dabei in Form eines zeitlich befristeten Projektauftrags (der idR mehrfach verlängert wird), eine Person gesucht, die als Product Owner woanders schon Erfahrung gesammelt hat. Das beauftragende Unternehmen erhofft sich so Methodenwissen über die Verantwortlichkeit ("Rolle") von außen in die Firma zu bekommen. Aber auch wenn dabei versucht wird, jemanden mit fachlicher Erfahrung des eigenen spezifischen Produktkontexts oder Branche zu finden, gelingt dies nur selten. Denn tatsächlich erscheinen zum einen gar nicht so viele (erfahrene) externe Product Owner verfügbar zu sein - und dass dann auch noch der fachliche Kontext passt, erscheint eher wie ein glücklicher Zufall. Wir haben uns daher Thomas Götten eingeladen, der als Selbständiger solche Aufträge als "Technischer Product Owner" übernimmt. Zum einen will Tim natürlich erstmal verstehen, was das Besondere an einem technischen Product Owner für Thomas ist. Als Product Owner in Festanstellung hatte Thomas viele Jahre Erfahrung sammeln können und ist fest "methodenfest". Das wissen wir, weil wir ihn schon recht lange kennen. Aber vielleicht ist das ja eben auch besonders wichtig, wenn man als Interim Product Owner arbeitet - schließlich darf man sich ja auch nicht vom System des Auftraggebers "verbiegen" lassen, so dass man letztlich als eine Art Zombie Product Owner endet. Es folgt eine spannende Diskussion über Vor- und Nachteile, kein explizites Fachwissen in der Kundendomäne mitzubringen. Natürlich muss man offen und aufgeschlossen sein, aber eine der Schwierigkeiten ist ja allein schon die Akzeptanz bei den Mitarbeitenden beim Kunden. Thomas berichtet von seinen spannenden Erfahrungen bei einem Spielzeughersteller und v.a. aus dem noch ungewöhnlicheren Feld der internationalen Kunstlogistik. Bei einem solch spitzen Produkt stellt sich die Frage nach Externen mit Branchenerfahrung vermutlich noch nicht einmal. Thomas Götten teilt also seine eigenen Learnings aus den letzten Aufträgen als Interim Product Owner und die beiden diskutieren u.a. die folgenden Fragen: Hast man als externer PO die gleichen "Rechte" & "Pflichten" wie ein interner PO? Wie geht man mit "Erbe" um - also wenn ein volles Product Backlog etc. übernommen werden muss, welches man ggf. gar nicht komplett versteht. Wieviel "Invest" in Team, Beziehung etc, lohnen sich, wenn man als Externer unterwegs ist und die Aufträge i.d.R. zwischen 6 und 12 Monaten dauern? Auf diese älteren Episoden unseres Podcasts verweisen Tim und Thomas im Laufe des Gesprächs: - Dein Freund der Scrum Master - Was die Einführung von OKR für Product Owner bedeutet - Wieviel technisches Wissen muss ich als Product Owner haben? - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Event Storming: Verständnis für komplexe Produkte schaffen Wer weitere Fragen an Thomas Götten hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite joettis.com. Hast du schon Erfahrungen mit Interim Product Ownern gesammelt? Wie lief der Einsatz eines zeitlich befristeten Product Owner bei euch ab? Oder warst du wie Thomas selber schon als externer Product Owner ohne Domänenwissen im Einsatz? Wir sind gespannt, von euren Ergebnissen zu hören! 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
Diesmal wollen wir uns der besonderen Herausforderung der Entwicklung einer Omnichannel widmen. Unser Gast Christoph Herrmann ist Head of Product der Kaufland-App bei Kaufland E-Commerce. Im Gespräch mit Tim gibt er einen Erfahrungsbericht, was die Entwicklung eines digitalen Produkts, also einer App, im Kontext des stationären Handels so besonders macht. Da die App im Rahmen der Omnichannel-Strategie von Kaufland auch im Markt bzw. ganz konkret "am Regal" zum Einsatz kommt, werden hier die Grenzen eines typischen Digitalprodukts deutlich verlassen. Es geht also um sehr unterschiedliche Zielgruppen und die Verzahnung mit den Handelsprozessen in den Märkten. Dies führt natürlich zu besonderen Herausforderungen bei Product Discovery, User Feedback Zyklen usw. und macht eine solche Produktentwicklung schon etwas spezieller. Darüber sprechen Christoph Herrmann und Tim Klein in dieser Folge - nachdem erstmal die Frage geklärt wurde, was überhaupt der Begriff Omnichannel bedeutet. Um folgende Themen geht es danach: Wie laufen Sprint Reviews ab? Wie gelingt die Zusammenarbeit mit Stakeholdern? Sicherlich kann man aus diesen Fragestellungen auch dann wichtige Impulse ziehen, wenn man nicht im Omnichannel-Umfeld unterwegs ist. Zu dieser Episode passt auch gut die kürzlich erschienene Folge "Wieviel technisches Wissen muss ich als Product Owner haben?" Wer weitere Fragen an Christoph Herrmann hat oder mit ihm in Kontakt treten möchte, erreicht ihn am besten über sein LinkedIn-Profil: linkedin.com/in/christophherrmann/ Bist du an der Entwicklung eines ähnlichen Produkts beteiligt? Müsst ihr auch, im Rahmen einer Omnichannel Strategie neben den digitalen Kanälen den stationären Handel im Auge behalten? Welche Herausforderungen sind da bei euch aufgetreten? Wie habt ihr das gut in den Griff bekommen? 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
Die Integration von UX-Professionals in ein Scrum-Team stellt eine echte Herausforderung dar und erfordert ein tiefes Verständnis für die verschiedenen Charaktere, die in diesem Prozess auftreten können. In dieser Folge spricht Dominique mit Florian Holzhäuser (https://www.linkedin.com/in/florian-holzh%C3%A4user-1429b113b/) von IT Sonix (https://www.itsonix.eu/) über seine Erfahrungen und Erkenntnisse, um diese Herausforderung zu meistern. Florian identifizierte vier mögliche Charaktere, wie UX-Professionals ins Scrum-Team eingebunden werden können: Prediger, Mentor, Macher und Daywalker. Jeder dieser Charaktere bringt unterschiedliche Perspektiven und Fähigkeiten mit sich, die sich auf die Art der Zusammenarbeit im Scrum-Team auswirken können. Der Charakter hängt dabei von verschiedenen Faktoren ab, darunter das verfügbare Budget und die Menge der Arbeit. Der "Prediger" ist jemand, der leidenschaftlich die Bedeutung von UX im Entwicklungsprozess predigt. Dieser Charakter kann dazu beitragen, das Bewusstsein im Team zu schärfen und die Bedeutung einer benutzerzentrierten Herangehensweise zu betonen. Die Integration eines Predigers kann besonders nützlich sein, wenn das Team wenig Erfahrung mit UX hat und einen Anstoß für einen Paradigmenwechsel benötigt. Der "Mentor" spielt eine Schlüsselrolle bei der Anleitung und Schulung des Teams im Bereich UX. Dieser Charakter bringt nicht nur Fachkenntnisse, sondern auch didaktische Fähigkeiten mit sich. Durch den Mentor können Teammitglieder ihre Fähigkeiten im Bereich UX verbessern, was langfristig zu einem selbstständigeren und kompetenteren Team führen kann. Der "Macher" ist jemand, der direkt an den UX-Aufgaben arbeitet und praktische Lösungen liefert. Dieser Charakter ist besonders effektiv, wenn schnelle Ergebnisse erforderlich sind und das Team direkte Unterstützung in der Umsetzung von UX-Praktiken benötigt. Die Integration eines Machers kann jedoch budgetintensiver sein, da möglicherweise mehr Ressourcen benötigt werden. Schließlich gibt es den "Daywalker", der flexibel zwischen den verschiedenen Welten wechseln kann. Dieser Charakter ist anpassungsfähig und kann je nach den Anforderungen des Teams in verschiedene Rollen schlüpfen. Die Integration eines Daywalkers kann die Flexibilität des Teams verbessern und sicherstellen, dass die UX-Professionals nahtlos in den Scrum-Prozess integriert werden. Insgesamt verdeutlicht diese Diskussion, dass die Integration von UX-Professionals in Scrum-Teams nicht nur eine organisatorische Herausforderung ist, sondern auch eine Chance bietet, die Qualität der Produkte durch eine stärkere Fokussierung auf die Benutzererfahrung zu verbessern. Es wird deutlich, dass die Vielfalt der Charaktere innerhalb der UX-Professionals einen positiven Einfluss auf die Agilität und Effektivität von Scrum-Teams haben kann.
Eine Organisation beginnt agil zu arbeiten und benötigt dann Product Owner:innen. Oft werden ehemalige Projektleiter oder Teamleiter als Product Owner:innen bestellt. Dass sich durch diese Veränderung bestimmte Herausforderungen ergeben, liegt nahe. Dies zeigt sich auch in eurem Wunsch, sich einmal über dieses Thema zu unterhalten. Daher sprechen in dieser Folge Dominique und Tim über den Übergang von der alten Verantwortung zur neuen. Im Gespräch wird schnell deutlich, dass es einige Verhaltensweisen gibt, die Projektleiter:innen durchaus hilfreich sein können, aber auch andere, die Schwierigkeiten verursachen. Projektleiter:innen sind oft sehr auf die Auslieferung fokussiert, wobei der Output über dem Outcome steht. Auch die direkte Zuweisung von Aufgaben an Personen mag Projektleiter:innen nützlich sein, aber im agilen Kontext als Product Owner wird dieses Verhalten nicht gut funktionieren. Ähnliches gilt auch für Teamleiter:innen. Die Aufgaben der Personalentwicklung und der Personalbeschaffung fallen schlichtweg weg, sobald man die Verantwortung als Product Owner übernimmt. Das macht den Wandel nicht so einfach. Dabei kann vor allem Transparenz helfen. Damit ist nicht nur die Zusammenarbeit mit dem Team und den Stakeholdern gemeint, sondern auch die persönliche Reflexion. Ehemalige Rollenmuster müssen bewusst umgedeutet werden. Feedbackgeber wie das Team, insbesondere im Rahmen der Retrospektive, und Menschen in der Verantwortung als Scrum Master können dabei hilfreich sein. Diese spielen eine besonders wichtige Rolle, weshalb eine agile Transformation ohne Scrum Master, besonders für Personen aus den vorherigen Rollen als Projektleiter oder Teamleiter, schwierig ist. Dennoch ist eine solche Veränderung gut möglich. Im Gespräch wurde auf folgende Folgen verwiesen: - POEM – Product Ownership Evolution (https://produktwerker.de/poem-product-ownership-evolution-model/) - Sei dein eigenes Produkt! – als PO seine Weiterentwicklung steuern (https://produktwerker.de/sei-dein-eigenes-produkt/) Außerdem erwähnten die beiden noch folgende Quellen: - Das Role Model Canvas (https://www.visual-braindump.de/role_model_canvas/) - Blogpost von Roman Pichler "Be a Balanced Product Leader not a Feature Broker or Product Dictator" (https://www.romanpichler.com/blog/be-a-balanced-product-leader-not-a-feature-broker-or-product-dictator/) - Blogpost von Roman Pichler "Six Types of “Product” Owners” (https://www.romanpichler.com/blog/six-types-of-product-owners/) Wenn ihr selbst aus der Projekt- oder Teamleitung heraus in die Verantwortung als Product Owner gekommen seid freuen wir uns über eure Erfahrungen. Teilt sie gerne im Blogpost zur Folge als Kommentar oder auf unserer LinkedIn-Companyseite als Kommentar. Diese Folge ist übrigens auch unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!
Eine Frage, die immer wieder aufkommt, ist die nach dem notwendigen technischen Wissen, dass man in der Verantwortung als Product Owner braucht. Dominique und Tim stellen sich in dieser Folge diese Frage und teilen ihre Erfahrungen sowie ihre Einschätzung dazu. Dazu muss man sich zuerst fragen, warum die Frage nach dem technischen Verständnis eigentlich aufkommt. Das kann einerseits an dem zugang zur Verantwortung als Product Owner liegen. Wenn man vorher in verwandten Rollen wie beispielswerise Business Analyst, oder Softwareentwickler gearbeitet hat, bringt man fast schon natürlich ein technisches Verständnis mit. Das könnte zumindest ein Grund sein, warum viele Product Owner bereits ein solches Verständnis haben und dadurch die Erwartungshaltung ihres Umfeldes entsprechend prägen. Ob das technische Verständnis aber immer hilft ist auch fraglich. Immerhin hat das Team in ihrer Domäne Expertenwissen und so manch ein Product Owner kann nicht aus der eigenen Haut und will mitmischen. Am Ende geht es aber in erster Linie darum, dass die Menschen, die zusammen versuchen ein erfolgreiches Produkt zu entwicklen miteinander sprechen können. Sie müssen sich gegenseitig verstehen. Daher ist ein sehr grundsätzliches technisches Verständnis durchaus hilfreich. Es mus snicht umfangreich sein und ein Informatikstudium ist garantiert zu viel des Guten. Wir haben in dieser Folge auf folgende Folgen verwiesen: - Stellenausschreibungen für Product Owner (https://produktwerker.de/product-owner-stellenausschreibungen/) - Vom Entwickler zum Product Owner (https://produktwerker.de/vom-entwickler-zum-produkt-owner/) - Wie No-Code Tools Produktteams helfen (https://produktwerker.de/no-code-tools/) Darüber hinaus haben wir folgende Quellen genutzt: - Six types of a “product” owners von Roman Pichler (https://www.romanpichler.com/blog/six-types-of-product-owners/) - The Product Trio von Teresa Torres (https://www.producttalk.org/2021/05/product-trio/) - Code it! (Coding Courses for Kids) (https://code-it-studio.de/) Diese Folge ist unsere Antwort auf eine Frage aus der Community. Wenn auch ihr eine Frage habt, die wir in einer Folge unbedingt mal beantworten sollten, lasst es uns gerne wissen. Schickt dazu gerne eine Mail an feedback@produktwerker.de. Wir freuen uns auf eure Fragen!
"Ich denke die Konferenz als Produkt - nicht nur als das Event, denn ich bin auch als Gründer immer schon in der Produktmanager-Rolle gewesen" sagt unser heutiger Gast Stefan Vosskötter, Founder und Gründer, u.a. vom Digitale Leute Summit. Aus Sicht der Teilnehmenden ist eine Konferenz vermutlich vor allem ein Lernprodukt, eine Vernetzungsplattform oder halt ein großes Partyerlebnis. Aber aus Anbieter- und Veranstaltersicht stehen wohl oft eher der Event-Charakter und die Herausforderungen das Event Managements im Vordergrund. Doch wenn eine Konferenz über Jahre erfolgreich ist und auch den unterschiedlichsten Rahmenbedingungen des Marktes oder der Gesellschaft (z.B. Pandemie) trotz, dann hilft es eine Konferenz als Produkt zu verstehen. Und aus diesem Blickwinkel der Produktentwicklung betrachtet Tim Klein heute mit seinem Gast Stefan Vosskötter die Entwicklung einer Konferenz. Wie ist es zu der Idee gekommen? Was ist die Produktvision, wie ist die Wettbewerbssituation, welche Zielgruppen spreche ich an? Dies mögen noch die eher üblichen Fragestellungen bei der Organisation einer Konferenz sein. Und diese Fragen lassen sich im Zweifel auch auf Inhouse Konferenzen und Veranstaltungen übertragen. Doch die Unterhaltung der beiden geht deutlich darüber hinaus und beleuchtet die folgenden Fragen: - Welche Hypothesen standen zu Beginn im Raum? - Welche Experimente habt ihr durchgeführt? Welche davon waren erfolgreich? Welche sind fehlgeschlagen oder sogar krachend gescheitert? - Welche grundsätzlichen Learnings habt ihr über die Jahre gemacht - insbesondere aus der Remote-Zeit? - Was sind eigentlich Features eines Konferenzproduktes? - Wie sieht die Roadmap des Produkts aus? - Und wie lässt sich ein Produkt denn überhaupt hypothesenbasiert entwickeln, welches nur einmal im Jahr eine Iteration ausgeliefert wird? Aus dieser Betrachtung einer Konferenz aus dem Blickwinkel der Produktentwicklung lassen sich daher auch sicherlich spannende Impulse für das eigene Produkt ableiten. Also: einfach mal über den Tellerrand schauen - bzw. hier "hören"! Weitere Erfahrungsberichte über die Entwicklung nicht ganz alltäglicher Produkte findet ihr in diesen früheren Episoden: - Product Owner für mein Buch - ein Erfahrungsbericht - Meine Erfahrung als Product Owner von JOYclub Wer weitere Fragen an Stefan Vosskötter hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil. Neugierig bzgl. des Digitale Leute Summit und den StartUp-Aktivitäten von Stefan geworden? Dann gibt es weitere Infos unter digitale-leute.de bzw. deutsche-startups.de. Dass wir viele Konferenz- und Eventveranstalter in der unserer Hörerschaft haben glauben wir zwar nicht. Aber vielleicht organisierst du ja stattdessen eine Inhouse Konferenz, einen Learning Day, Agile Day oder ähnliches bei euch im Unternehmen? Betrachtet ihr dabei auch diese Konferenz als Produkt? 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
POEM steht für "Product Ownership Evolution Model" wurde 2017 von den beiden Produktwerkern Oliver Winter und Tim Klein erfunden und entwickelt. Es ist ein Modell, welches hilft mehr Product Ownership in einer Organisation zu etablieren. Es unterstützt dabei, die aktuell gelebte und zukünftig angestrebte Ausgestaltung der Product Ownership, vor allem im Sinne der Entscheidungsverantwortung, zu visualisieren, zu diskutieren und so gemeinsam weiterzuentwickeln. Auf diesen Ergebnissen aufbauend kann das Modell genutzt werden, um Verantwortlichkeiten für die Product Ownership zwischen den Rollen verbindlich(er) zu vereinbaren. Letztlich kann so auch ein möglicher Coaching-Bedarf der handelnden Personen/Rollen identifiziert werden, den Scrum Master und/oder Agile Coaches abdecken müssen. Oliver Winter und Tim Klein, die beiden Erfinder des Models, beleuchten in dieser Episode noch mal die Entstehungsgeschichte von POEM und welches Problem sie dazu führte, die Fragestellung von Entscheidungsverantwortung expliziter machen zu wollen. Die beiden erklären die Idee hinter dem Tool und erläutern Aufbau und Mechanik des Modells. Weiterhin beleuchten Sie seine Stärken und Schwächen und geben insbesondere Tipps und Hinweise, wie man POEM als Hilfsmittel in der Diskussion besonders effektiv einsetzen kann. So können insbesondere Scrum Master, Agile Coaches und Organisationsentwickler:innen - aber natürlich auch Product Owner - das Modell wirkungsvoll einsetzen. Download des POEM Templates inkl. Erklärungen zur Anwendung hier: produktwerker.de/poem/ In dieser Episode empfohlene Podcast Folgen: - Organisatorische Schulden beeinflussen deinen Erfolg als Product Owner - Welche Aufgaben gehören zur Product Owner Rolle? (POCC - Product Ownership Context Canvas) - Wie No-Code Tools Produktteams helfen können - Tim's Gastauftritt zu POEM und POCC im Podcast "Mein Scrum ist kaputt" (Folge 103) Auswahl von Videos zum Product Ownership Evolution Model - Aufzeichnung Produktwerker Live-Event: Product Ownership mit POEM klären (https://youtu.be/HlSaFp4PNJ0) - Talk beim Telekom Agilista Barcamp 2020: "POEM - Product Ownership Evolution Model" (youtu.be/zBQcqkejAAU) - Tools4AgileTeams 2017: "POEM – Product Owner Evolution Model" (youtube.com/watch?v=dpjSNsClayw) Bücher, in denen POEM empfohlen wird: - Frank Düsterbeck, Ina Einemann: Product Ownership meistern - Sabina Lammert et al.: Das große Handbuch Digitale Transformation: 222 Methoden und Instrumente für mehr Wandlungsfähigkeit im Unternehmen Wie sind deine Erfahrungen mit Product Ownership? Wie macht ihr die Verteilung von Entscheidungsverantwortung explizit? Habt ihr dabei vielleicht sogar schon einmal POEM (Product Ownership Evolution Model) genutzt? Welche Erfahrungen habt ihr dabei gemacht? Hat sich durch den Einsatz etwas an der Diskussion des Themas verändert? 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
Man kann es wohl als besondere Herausforderung bezeichnen, Product Owner im Konzern zu sein. Die Frage ist dann immer, wie viel Produktverantwortung habe ich überhaupt oder anders gesagt: mit wie vielen anderen Menschen muss ich mir diese Verantwortung teilen? Tim hat heute Daniel Dubbel von der DB Systel zu Gast, um dieses diese Fragestellungen zu besprechen. Daniel ist langjähriger und erfahrener Agile Coach bei der DB Systel, dem internen IT-Unternehmen im DB Konzern. Daniel ist dort eine Führungskraft und in der Rolle als Agility Master aktiv an der Organisationsentwicklung des Unternehmens beteiligt. Im Rahmen dieser Verantwortung hat er die DB Systel auch im sogenannten DACH30 Netzwerk vertreten, einem Zusammenschluss von 30 Konzernunternehmen aus Deutschland, Österreich und der Schweiz, die sich seit einigen Jahren viermal im Jahr regelmäßig treffen, um über Agilität in solch großen Unternehmen zu diskutieren. In diesem Zuge wurden auch Diskussionen zu agilen Rollen im Konzern geführt und in sogenannte "Mindeststandards für Unternehmensagilität" entwickelt. Da es hierbei natürlich auch um die Product Owner Verantwortlichkeit ging, fanden wir es besonders spannend, Daniel Dubbel als Gast für diese Folge einzuladen und mit ihm darüber zu sprechen, was für Product Owner im Konzern vielleicht besonders oder anders ist. Aber auch bzgl. DACH30 wollte Tim wissen: Was war die Motivation, solche expliziten Rollenbeschreibungen für Konzernagilität zu definieren? Und inwiefern unterscheidet sich die Product Owner Rolle, die in diesen Mindeststandards als "Value-Verantwortlicher" beschrieben wird, vom Product Owner, wie er im Scrum Guide definiert wird? Einen spannenden Ausflug machen die beiden auch noch zur Fragestellung, wie Kunden und Nutzer im Konzernumfeld eingebunden werden können. Am Ende des Gesprächs gibt Daniel Dubbel auch noch seine ganz persönlichen Tipps für Product Owner im Konzern. Tim verweist im Gespräch u.a. auf das "Lean Coffee für Agilität in Versicherungen", einer freiwilligen, ehrenamtlichen Netzwerk-Initiative, von Mitarbeitenden aus Versicherungsunternehmen. Alle sechs Wochen treffen sich hier Angestellte aus Unternehmen der Versicherungsbranche in einem selbstorganisierten, geschützten Raum. Wer festangestellt in einem Versicherungsunternehmen arbeitet, kann sich in der LinkedIn-Gruppe anmelden und bekommt dort dann die Einladungen mit. Achtung: Berater und Vertriebler werden explizit nicht in die Gruppe aufgenommen! Hier der Link zur Gruppe "Lean Coffee Agilität in Versicherungen" (linkedin.com/groups/12715252/). Die "Mindeststandards für Unternehmensagilität" von 30 börsennotierten Großunternehmen aus Deutschland, Österreich und der Schweiz sowie drei deutschen Beratungsunternehmen sind in folgendem Artikel von Daniel Dubbel sehr gut dokumentiert: https://www.inspectandadapt.de/agile-rollen-kompetenzen/ Frühere Episoden unseres Podcasts passen gut zur aktuellen Folge: - Product Ownership im Konzernumfeld mit Felix Stein - Customer Journey Management im Konzern - ein Erfahrungsbericht mit Martin Sallge Wer weitere Fragen an Daniel Dubbel hat oder mit ihm in Kontakt treten möchte, erreicht ihn am Besten über sein LinkedIn-Profil oder über seine Webseite inspectandadapt.de. Welche Erfahrungen hast Du als Product Owner im Konzern bislang gesammelt? Wie lässt sich die Product Owner Verantwortung im Konzernumfeld leben? 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
In vielen der vorherigen Podcastfolgen haben wir immer wieder einzelne Verhaltensmuster von Product Owner*innen angesprochen, die wir als Produktwerker eher kritisch sehen. Daher war es an der Zeit, eine Episode zu veröffentlichen, in denen Dominique und Oliver einmal viele relevante Antipattern an einer Stelle zusammenfassen. So bekommst Du als PO die Chance, diese Antipattern mit Deinem Verhalten zu vergleichen und ggf. kritisch zu hinterfragen, ob Du an dem einen Muster arbeiten möchtest. Die beiden klären zuerst ihr Verständnis von Antipattern, unter denen sie Lösungsansätze verstehen, die ungünstig oder schädlich für den Erfolg der eigenen Produktentwicklung oder des eigenen Unternehmens sind. Dabei unterteilen Oliver und Dominique diese PO Antipattern in drei Bereiche: eigenes Verhalten, Zusammenarbeit mit den Developer bzw. Produktentwicklungsteam und Kommunikation mit den Stakeholdern. Wir üblich versuchen die beiden auch ganz konkrete Beispiele aus ihrer eigenen Erfahrung sowie Tipps und Tricks zu nennen, wie ich an mir als Product Owner:in arbeiten kann, um wirksamer in meiner Rolle zu werden. ANDERE PODCASTFOLGEN, AUF DIE VERWIESEN WIRD Nein sagen als Product Owner Dein Freund der Scrum Master Seine Stakeholder kennen und richtig analysieren Epic. Sinnvoll oder nicht?
Wer sich in der UX-Community bewegt, kam in den letzten Monaten nicht um das Thema UX-Writing herum. Durch den richtigen Text an der richtigen Stelle soll das Nutzererlebnis verbessert werden. Grund genug, dass wir mal einen tieferen Blick in das Thema werfen und uns auch fragen, wie Product Ownern, Product Managern und Product Leadern UX-Writing helfen kann, bessere Produkte zu entwickeln. In dieser Folge spricht Dominique mit Tilman Büttner (https://www.linkedin.com/in/tilmanbuettner/), Senior UX Writer der Modulr.Design GmbH und Mitglied des Arbeitskreises UX-Writing der German UPA (https://germanupa.de/arbeitskreise/arbeitskreis-ux-writing), dem Berufsverband der deutschen UX-Professionals. Tilman erklärt, was UX-Writing ist und wie es sich beispielsweise vom klassischen Texten unterscheidet. Dabei wird schnell klar, dass sich hierbei ein großes Potenzial für den Erfolg oder Misserfolg von Produkten ergibt. Das beliebteste Beispiel sind Darstellungen eines Produkts ohne seine textlischen Inhalte. Da versteht man schnell, dass Bilder alleine nicht ausreichen und das jedes Wort relevant sein kann. Daher sprechen die beiden auch darüber, wie man eigentlich gute Texte für das eigene Produkt schreibt. Beispielsweise ist die Tonalität wichtig. Dabei zeigt sich auch der klare Bezug zum Beispiel zur UX-Vision (https://produktwerker.de/ux-vision/) und dem absichtsvollen Gestalten der User Experience. Aber wie immer gibt es einige Fehler, die vermieden werden können. Über diese spricht Tilman in der Folge ausführlich und gibt uns somit Tipps und Tricks, wie wir einerseit smit UX-Writern zusammenarbeiten sollten aber auch wie wir notfalls ohne UX-Writer wenigstens etwas bessere Texte verfassen können. Wer über diese Folge hinaus noch Unterstützung sucht, dem sei die kostenlose Einführung ins UX Writing vom "UX Writing Hub" (https://course.uxwritinghub.com/free_course) empfohlen. Auch der Blog auf derselben Website ist für Interessierte empfehlenswert. Ein paar weitere praktische Tipps gibt es darüber hinaus auf der Website der Nielsen Norman Group (https://www.nngroup.com/articles/ux-writing-study-guide/). In einer langen Serie aus Artikeln und Videos bereitet sie das Thema gut verständlich auf.
Als Product Owner kann ich im Alleingang niemals erfolgreich sein. Ohne Team bist Du nichts! Grund genug, für Dominique und Oliver einmal auf die Bedeutung des Teams für Product Owner zu schauen. Die beiden diskutieren dabei sowohl über die Developer– als auch über die Stakeholder–Seite und geben wie immer eine ganze Reihe von Tipps und Tricks aus der eigenen Praxis. Natürlich ist es spannend, was der Scrum Guide zum Team sagt und welche Auswirkungen dies auf die Arbeit der Product Ownerin hat. Besondere Wichtigkeit kommt der Zusammenstellung des Teams und der Fähigkeiten / Skills der eigenen Teammitglieder zu. Hier motivieren Oliver & Dominique, sich als PO einzumischen und zu positionieren, damit wir im möglichst optimalen Kontext unterwegs sein können. Mit Unterstützung des Scrum Masters müssen wir uns alle weiterentwickeln. Dabei ist das Mindset der Teammitglieder von Bedeutung, die beiden empfehlen eher auf interessierte, lernwillige Allrounder mit einer besonderen Expertise zu setzen als auf Spezialisten.
Die Transformation hin zum Product Operating Model ist das neue zentrale Thema von Marty Cagan seit diesem Sommer. Er hat es Ende Juli in London im Rahmen des TRANSFORMED Workshops vorgestellt. Unser heutiger Gesprächsgast Sohrab Salimi war vor Ort in London und tauscht sich dazu mit Tim Klein. Tim war seinerseits im letzten Jahr drei Tage im Coach-the-Coaches Retreat von und mit Marty Cagan und seinen Kollegen der svpg. Dort wurden die ersten Ansätze zum Product Operating Model auch schon angesprochen. Das ganze wird sich dann ab kommendem Frühjahr (vermutlich März 2024) im neuen Marty Cagan Buch "TRANSFORMED" nachlesen lassen. Von Sohrab, der ein sehr gern bei uns gesehener und somit wiederkehrender Gast bei uns im Podcast ist, können wir also quasi von echtem Insider-Wissen, zumindest aber mit Infos aus erster Hand, profitieren. Falls ihr Sohrab noch nicht kennt: Sohrab ist Gründer & CEO der Scrum Academy GmbH und seit fast zehn Jahren Certified Scrum Trainer® sowie Certified Agile Leadership Educator der Scrum Alliance, wo er bis Ende 2020 Mitglied des Board of Directors war. Wer noch mehr wissen möchte, hört sich am besten nochmal eine der weiteren Folgen mit ihm an: - Sohrab Salimi in Folge 11: "Product Owner als Agile Leader" - Sohrab Salimi in Folge 54: "Business- oder Nutzersicht: Welchen Blickwinkel sollte ein PO einnehmen?" (mit Markus Andrezak) Weitere passende Quellen zum Product Operating Model - Vortrag von Marty Cagan "Moving to the product operating model" im Webinar der Product-Led Alliance (https://my.demio.com/recording/fISWhQJb) - Weitere Vorab-Infos zum kommenden Buch von Marty Cagan "TRANSFORMED" (https://www.svpg.com/transformed/) - Agile Insights Interview von Sohrab Salimi im Gespräch mit Marty Cagan: Product Leadership (https://www.agile-academy.com/de/agile-leader/product-leadership/) - Teresa Torres bei Product at Heart: Even You Can Do Continuous Discovery. Bringing the Discovery Habits to Every Organization (https://productatheart.com/) Wenn du mit Sohrab Salimi direkt in Kontakt treten möchtest, folge ihm am Besten auf LinkedIn oder kontaktiere ihn über sein LinkedIn-Profil. Eine weitere Empfehlung ist seinen regelmäßigen LinkedIn-Newsletter zu folgen. Hier teilt es immer wieder (i.d.R. wöchentlich) tolle Leadership Tipps und Gedanken. Hast du bereits vom Product Operating Model gehört? Oder seid ihr anderweitig auf der Transformationsreise zu einem produktzentrierten Organisationsmodell? Wir freuen uns, wenn du deine Erfahrungen bzw. Überlegungen 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
