Die Produktwerker – Details, episodes & analysis

Die ersten Wochen in einer neuen Rolle als Product Owner können überwältigend sein. Als neuer PO steht man vor vielen Herausforderungen, gleichzeitig bietet sich aber unserer Meinung nach auch eine einmalige Chance: den Rahmen für die Produktentwicklung so zu setzen, dass man langfristig Spaß an der Arbeit hat und effektiv agieren kann. In dieser Folge diskutieren Dominique und Oliver vier Schritte, die sich als Orientierungshilfe für die ersten Wochen eignen: 1. KONTEXT VERSTEHEN UND BEZIEHUNGEN AUFBAUEN Bevor man sich in operative Aufgaben stürzt, sollte der Fokus darauf liegen, den Kontext des Produkts und der Organisation zu erfassen. Es geht zu Beginn vor allem darum, relevante Stakeholder kennenzulernen, die Produktvision zu verstehen und die Erwartungen der Beteiligten zu klären. Diese Phase legt das Fundament für alle weiteren Schritte und hilft dabei, spätere Entscheidungen fundiert treffen zu können. 2. RAHMEN FÜR DIE ENTWICKLUNG FESTLEGEN Sobald der Kontext in dem man sich als Product Owner bewegt klarer ist, gilt es, den Rahmen für die Produktentwicklung zu definieren. Dabei spielen sowohl das Aufsetzen eines gut strukturierten Backlogs als auch die Festlegung von Arbeitsweisen im Team eine zentrale Rolle. In diesem Schritt geht es vorangig darum, ein gemeinsames Verständnis zu schaffen, wie gearbeitet und welche Prioritäten gesetzt werden sollen. 3. DELIVERY UND DISCOVERY VEREINEN Ein häufiger Stolperstein in der Produktentwicklung ist die Trennung von kontinuierlicher Lieferung (Product Delivery) und der Entdeckung neuer Optionen und Lösungen (Product Discovery). Beides sollte Hand in Hand gehen. Der Fokus liegt darauf, diese Denkweise im Team zu verankern und sicherzustellen, dass das Product Backlog sowohl kurzfristige Lieferziele als auch explorative Aufgaben berücksichtigt. 4. ZIELE DEFINIEREN UND LANGFRISTIG AUSRICHTEN Darüber hinaus macht es Sinn, konkrete Outcome-Ziele zu definieren. Dominique und Oliver machen in der Episode klar, dass es hier nicht nur um das Setzen von Sprintzielen, sondern vor allem um übergeordnete Ziele wie Produk Goal, Quartalsziele oder KPIs geht. Diese geben allen Beteiligten eine klare Richtung und ermöglichen es, den Fortschritt regelmäßig zu reflektieren und anzupassen. Wichtig ist für die beiden hierbei, solche Ziele nicht zu früh zu formulieren. EIN LANGFRISTIGER ANSATZ Die beschriebenen vier Schritte sind nicht als starre Abfolge zu verstehen, sondern sollten regelmäßig reflektiert und angepasst werden. Auch nach mehreren Monaten lohnt es sich, immer wieder einen Schritt zurückzugehen und zu prüfen, ob der Rahmen noch passt oder ob der Fokus neu justiert werden muss. Am Ende bleibt es entscheidend, dass man als PO nicht nur operativ gefordert ist, sondern sich auch strategische Freiräume schafft, um das Produkt langfristig erfolgreich zu machen. Oliver und Dominique möchten mit diesen Impulsen Product Ownern für die ersten Wochen eine Idee an die Hand geben, wie ihr sinnvoll startet und euren Weg in der Produktentwicklung erfolgreich gestalten könnt.

Guerilla Discovery – das ist ein vielleicht zunächst mal unbekannter oder ungewöhnlicher Begriff. Gemeint ist damit ein unterschwelliger und kontinuierlicher Weg, um Nutzereinblicke zu gewinnen, selbst wenn das Umfeld nicht ideal für tiefergehende Discovery-Prozesse ist. In dieser Episode ist Tobias Morauf, Senior Product Manager bei cosee, zu diesem Thema der Gesprächsgast von Tim. Er gibt spannende Einblicke in seine Art, für mehr Product Discovery zu sorgen - selbst wenn kein Budget bzw. kein expliziter Wille in seinem Produktkontext bzw. Projekt vorhanden ist, nach mehr Product Discovery zu streben. Wie das genau funktioniert und welche praktischen Tipps dabei helfen, beleuchten wir in dieser Folge unseres Podcasts. Unter Guerilla Discovery versteht Tobias ein Vorgehen, bei der Product Discovery nicht aufwendig und formal durchgeführt wird, sondern unterschwellig aber kontinuierlich in den Produktalltag integriert wird. Ziel ist es, trotz knapper Ressourcen und begrenztem Spielraum wertvolle Erkenntnisse zu sammeln. Ein zentraler Gedanke dabei: Discovery braucht oft weniger Zeit und Aufwand, als man denkt. Ein griffiges Beispiel, das Tobias Morauf aus seiner Praxis teilt, zeigt eindrucksvoll, wie dieser Ansatz funktioniert. In einem Projekt ging es um die Migration eines Systems, bei dem es eine klare Feature-Liste von der IT-Abteilung gab. Doch Tobias bemerkte schnell, dass es eine Diskrepanz zwischen den Anforderungen der IT und den tatsächlichen Bedürfnissen des Kundenservice gab. Statt einfach die bestehenden Anforderungen umzusetzen, entschied er sich, den Kundenservice direkt zu beobachten – ganz unauffällig und ohne großes Aufsehen. Durch diese einfache Maßnahme konnte Tobias feststellen, dass einige der ursprünglich geplanten Features überflüssig waren, während andere, wie die Möglichkeit, Kunden zu sperren oder zu anonymisieren, viel wichtiger waren. Diese Erkenntnisse führten nicht nur zu einer besseren Lösung, sondern halfen auch, unnötigen Aufwand zu vermeiden – ganz im Sinne von Jeff Pattons Prinzip: „Maximiere den Outcome, während du den Output minimierst.“ Um Guerilla Discovery erfolgreich in der Praxis umzusetzen, schlägt Tobias einen Ansatz in fünf Schritten vor: Stakeholder überzeugen: Oft gibt es Widerstände, wenn es um zusätzliche Discovery geht. Hier hilft es, mit gezielten Fragen und Annahmen zu arbeiten, statt sofort mit großen Konzepten oder umfangreichen Interviews zu starten. Nutzer verstehen: Der direkte Kontakt zum Nutzer ist essenziell. Wenn dieser nicht möglich ist, helfen kleine, kontinuierliche Beobachtungen und das Hinterfragen bestehender Annahmen. Im kleinen Rahmen experimentieren: Discovery kann auch in kleinen Schritten stattfinden. Es muss nicht immer der große Wurf sein. Auch kurze Beobachtungen oder Gespräche können wertvolle Einsichten liefern. Scope-Creep beachten: Jedes Projekt hat ein Budget, sei es finanziell oder zeitlich. Ein Teil dieses Budgets sollte bewusst für Discovery verwendet werden, da dies langfristig zu besseren Entscheidungen führt und letztlich Ressourcen spart. Den Scrum Master einbinden: Sollte es zu Widerständen im Team kommen, empfiehlt Tobias, den Scrum Master als Verbündeten zu gewinnen. Dieser kann oft helfen, Konflikte zu moderieren und den Fokus auf die Nutzerbedürfnisse zu lenken. Ein zentraler Punkt, den Tobias betont, ist der Mut, den Guerilla Discovery erfordert. Man muss halt aus der eigenen Komfortzone heraustreten und vielleicht auch mal anecken. Doch genau hier liegt der Schlüssel: Wer bereit ist, kleine Schritte zu gehen und immer wieder hinterfragt, kann selbst in einem schwierigen Umfeld wertvolle Erkenntnisse gewinnen. Fazit: Kleine Aktionen, große Wirkung Tobias’ Ansatz zeigt, dass Product Discovery nicht immer aufwendig oder formell sein muss. Durch gezielte, kleine Maßnahmen können auch in einem schwierigen Umfeld wichtige Erkenntnisse gewonnen werden.

Was sind Pirate Metrics? Das auch als das AARRR-Modell bekannte Set von Metriken hat vor allem im Bereich des Growth Marketing starke Verbreitung und Bekanntheit. Unser Gast Timothy Krechel ist Head of Digital Product Consulting bei Qvest Digital und nutzt die Pirate Metrics auch gerne in der Arbeit von Produktmanagern. Zunächst ergründen Tim und Timothy im Gespräch, was das Akronym "AARRR" bedeutet und woher der Begriff "Pirate Metrics" kommt. Ja - tatsächlich ist hier die Analogie zum furchteinflößenden Ruf von Piraten der profane Grund. Die Abkürzung AARRR steht hingegen für die fünf wichtigsten Funnel-Schritte, auf die sich jedes Unternehmen konzentrieren sollte: „Acquisition“ (Akquisition), „Activation“ (Aktivierung), „Revenue“ (Umsatz), „Retention“ (Kundentreue) und „Referral“ (Empfehlungen). Das Modell hilft, die Customer Journey und die bevorzugten Kanäle der Nutzer besser zu verstehen und in (strategischen) Diskussionen entsprechende Klarheit herzustellen. Außerdem ermöglichen diese sogenannten "Pirate Metrics", umsetzbare Ziele je Funnel-Step festzulegen. Timothy Krechel erklärt dann jeden Schritt des AARRR-Modells im Detail und zusammen mit Tim wird das Verständnis anhand von Beispielen geschärft. Natürlich gibt es noch andere Funnel-Ansätze als die Pirate Metrics. Aber gerade für transaktionsbasierte Geschäftsmodelle ist eine solche Funnel-Darstellung hilfreich. Tim zeigt auch Beispiele aus dem Produktportfolio der Produktwerker zu den einzelnen Steps auf. Spannend wird dann die Frage, wie das AARRR-Modell konkret zu nutzen ist und vor allem, wie es mir als Product Owner helfen kann. Hier gibt der Gast Timothy Krechel wertvolle Impulse, wie die Pirate Metrics in den Alltag als Product Owner integriert werden können. Abschließend zeigt Timothy aber auch die Schwächen der Pirate Metrics auf, um ein rundes Bild zu zeichnen. Passende Podcast-Folgen rund um das Thema Customer Journey: - Mit Customer Journey Maps arbeiten - Customer Journey Management im Konzern - ein Erfahrungsbericht Wenn ihr weitere Fragen an Timothy habt oder mit ihm Kontakt aufnehmen möchtet, vernetzt euch am besten via LinkedIn mit ihm oder schreibt an [email protected]. Weiteren wertvollen Content von und mit Timothy Krechel gibt es in den Product Lunches von Qvest Digital. Kanntest du die Pirate Metrics? Und nutzt ihr sie auch in der Praxis bei euch?Wie bindest du dann das AARRR-Modell in deine Arbeit als Product Owner ein? 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

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.

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: Manche Product Owner arbeiten in einem Scrum Kontext 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 dieses Thema eines der großen Missverständnisse in der agilen Produktcommunity. 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, ist es auch ein guter Zeitpunkt die eigene Sichtweise zu formulieren. Dominique und Oliver starten mit einer Reflexion eines Beitrags von Roman Pichler zu "Six Types of Product Owner", der in diesem Podcast schon in der einen oder anderen Episode zitiert wurde. Fokus legen beide aber auf den Scrum Product Owner 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 konkretisieren Oliver und Dominique darüber hinaus auch sehr klar ihren eigenen Standpunkt. Sie klären, dass in Produktwerker-Podcast sehr häufig der Scrum Product Owner im Mittelpunkt der Diskussionen steht. Wie immer schließt diese Episode mit konkreten Tipps & Tricks ab.

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: https://www.linkedin.com/in/nam-hoang-dong-187b2a30/ 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: https://www.linkedin.com/company/produktwerker.

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.

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.

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

Über die Zusammenarbeit von Product Ownern mit Stakeholder*innen, Nutzer*innen 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 (https://produktwerker.de/product-owner-im-skalierten-umfeld/) - Das Product Owner Team (https://produktwerker.de/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 (https://produktwerker.de/als-product-owner-erfolgreich-zusammenarbeiten/) teilst oder auf unserer Produktwerker LinkedIn-Seite (https://www.linkedin.com/company/produktwerker).