PO-Days 2024 Tag 1: Produktmanagement für Infrastruktur, Opportunity Solution Tree, Führungskompetenzen, Wettgrößen & PO-Rolle

Am ersten Tag der Product Owner Days ging es um das Produktmanagement für Infrastrukturprodukte, einen praktischen Anwendungsfall zum Opportunity Solution Tree, Führungskompetenzen für Product Owner:innen, Wettgrößen im Entwicklungsprozess und die Rolle von Product Ownership.

Leider konnte ich nicht von Anfang an dabei sein. Daher fehlen hier die Eröffnungs-Keynote und der erste Session-Slot. In diesem Beitrag findest Du die Zusammenfassungen der einzelnen Beiträge, die ich mir angehört habe.

Infrastruktur als Produkt

Im Vortrag von Dominik Kress stand das Produktmanagement für Infrastrukturprodukte im Fokus. Dominik, der für die Kubernetes-Plattform bei Giant Swarm zuständig ist, teilte seine Ansichten und Methoden, wie Infrastrukturprojekte erfolgreich als Produkte geführt werden können.

Dominik versteht unter Produktmanagement den Prozess bestehend aus Exploration und Delivery. Exploration umfasst Strategie, Priorisierung und Discovery. Delivery umfasst Refinement, Development und Iteration. Produktmanagement an sich ist für ihn das Management von Risiken.

Zentrale Erkenntnisse waren für mich:

• Den Wertbeitrag von Infrastrukturprodukten explizit transparent machen: Infrastrukturprodukte generieren für sich allein keinen direkten Wert für Kund:innen. Sie unterstützen vielmehr die Produkte und Teams im Unternehmen, die den direkten Kundennutzen schaffen. Der indirekte Nutzen von Infrastrukturprodukte kann und sollte durch User Needs Mapping transparent gemacht werden. Das hilft, damit andere Teams verstehen, welchen Wertbeitrag Plattformteams für sie, Kund:innen und Unternehmen stiften.

• Verschiedene Kund:innen und Anwender:innen verstehen: Infrastrukturprodukte bedienen oft eine Vielzahl von vor allem internen Anwender:innen. Plattform-Teams müssen sowohl Kaufentscheider:innen und Entwickler:innen glücklich machen. Infrastrukturprodukte werden darüber hinaus nicht nur von Menschen, sondern auch von Maschinen genutzt. Personas und Jobs-to-be-done helfen, um die unterschiedlichen Zielgruppen und deren Bedürfnisse zu verstehen.
• Metriken sind das Wichtigste im Discovery von Infrastrukturprodukten: Metriken spielen eine wichtige Rolle der Exploration, auch bei Infrastrukturprodukten. Hierbei sind besonders qualitative Metriken wertvoll, da sie ein tieferes Verständnis der Nutzerbedürfnisse ermöglichen. Dominik betont die Wichtigkeit von regelmäßigem Kontakt mit den Anwender:innen bzw. Stakeholdern von Infrastrukturprodukten. Darüber hinaus machen Metriken den Wert eines Infrastrukturproduktes für Kaufentscheider:innen und Anwender:innen sichtbar.
• Bei Infrastruktur Produkten ist die Schnittstelle (wahrscheinlich) eine API: In der Regel haben Infrastrukturprodukte keine grafische Bedienoberfläche, sondern werden mittels API angebunden bzw. genutzt. Das erfordert von POs für Infrastrukturprodukten, dass sie ein tiefes technisches Wissen und Verständnis benötigen. POs müssen den abstrakten technischen Kontext ihrer Produkte verstehen können. Nachdem sie sich nicht nur auf technische Aspekte konzentrieren können, empfiehlt Dominik eine enge Zusammenarbeit bei technischen Fragestellungen mit Entwickler:innen. Außerdem können visuelle Methoden, wie User Story Mapping oder Product Journey Value Map, helfen, dass technische Verständnis zu fördern.

Buchtipp: Team Topologies – organizing business and technology teams for fast flow

Mehr Product Ownership durch die Rosinen-Rolle-Rückwärts

Juliana Brell (sipgate) ging in ihrem Beitrag der Frage nach, wie man als Product Owner:in damit umgehen kann, wenn ein Stakeholder:innen mit einer konkreten Lösungsidee zu ihnen kommen und eine Umsetzung erwarten. Menschen lieben ihre Ideen. Dadurch kann es schnell passieren, dass die eigene Idee schnell mal wichtiger wird, als das eigentliche Ziel.

„Product Discovery heißt Bauchgefühl mit Daten zu füttern.“.

Sie erläuterte ihr Vorgehen an einem konkreten Fall. In diesem wurde die Umsetzung eines „Workspaces für mehr Kollaboration“ gewünscht. Bei tieferem Nachfragen wurde deutlich, dass nicht so ganz klar war, warum diese Anforderung umgesetzt werden soll. Anstatt gegen die Idee zu argumentieren, griff sie diese auf und kam über eine Rolle rückwärts auf des Pudels Kern.

Der Weg:

1. Im ersten Schritt wurde das Ziel konkretisiert, das erreicht werden soll. Dabei stellte es sich heraus, dass es eigentlich um eine Verbesserung des Verhältnisses von Free-Usern zu Pro-Usern ging.
2. Auf Basis dieses Ziels bekamen Manager:innen, Entwickler:innen und andere Kolleg:innen im Rahmen eines Brainstormings die Möglichkeit Ideen für die Erreichung des Ziels einzubringen. Es ging dabei darum den verschiedenen Bachgefühlen einen Raum zu geben.
3. Die zahlreichen Ideen wurde so gruppiert und visualisiert, dass klarer wurde, was sich dahinter verbirgt. Das Ganze wurde in ein einem Baum visualisiert, der ausgehend von der Zieldefinition über Idee zu möglichen Optionen führt. Dieser Opportunity Solution Tree zeigte am Ende das Ziel, Sub-Ziele, Optionen und Lösungsideen auf einen Blick.

• Der Baum beinhaltet viele Dinge, die mit einer bestimmten Unsicherheit behaftet sind. Es sind mehr Annahmen als validierte Erkenntnisse. Es wurde bewertet, bei welchen Hypothesen sich die Beteiligten wie sicher sind.
• Zum Auflösen der Unsicherheiten, wurden entsprechende Datenquellen identifizieren und Daten beschafft. Sinnvolle Datenquellen können beispielsweise sein: CRM, BI, Abrechnung, Kundenbetreung, Produktsdaten, Support-Communitys, Analytics, Bedürfnisse. Manche Datenquellen waren zu diesem Zeitpunkt verfügbar. Andere mussten erst noch erschlossen werden. Mit Hilfe einer Impact-Effort-Matrix konnte eingeschätzt werden, wie sich die nötigen Daten mit wenig Aufwand beschaffen lassen.
• Die gesammelten Daten wurden in eine Form gebracht, die für die Beteiligten einfach zu nutzen war. (Beispiele: Nutzerprofile und Personas)
• Aus den Daten wurden dann validierte Erkenntnisse abgeleitet und im Baum ergänzt. Auf diese Weise wird schnell offensichtlich, welche Optionen und Lösungsideen tatsächlich funktionieren können.
• Danach wird konkrete Aufgabenpaket in das Backlog übernommen. Das waren beispielsweise „Prototypen für Lösungsideen bauen“, „Offene Research-Fragen klären“,

Ihr sinngemäßes Fazit: Wenn jemand mit einer Idee zu Dir kommt, dann nimm die Idee und gehe rückwärts. Generiere ganz viele Ideen & Optionen, validiere die und entscheidet, was konkret zu tun ist, um das Ziel zu erreichen.

Essential Leadership Skills für Produktrollen

Simonetta Batteiger sprach über die Führungskompentenzen von Product Owner:innen. POs arbeiten in der Regel als fachliche Führungskräfte und benötigen dafür die entsprechenden Kompetenzen. Diese kommen in den Trainings- und Weiterbildungsangeboten meist aber etwas zu kurz. Außerdem sehen sich POs teilweise nicht als Führungskräfte oder trauen sich nicht Führung zu übernehmen.

Zu Beginn ging sie auf den Begriff „Leadership“ ein. Leadership ist für Simonetta die Kunst eine Gruppen von Menschen zu motivieren, auf ein gemeinsames Ziel hinzuarbeiten. Es geht um die Befähigung von Menschen, damit sie gemeinsam etwas erreichen können, was sie allein nicht schaffen würden. Leadership bedeutet Energie zu managen, zuerst bei sich selbst und dann bei anderen.

Produktrollen, wie Product Owner:innen, können fast nichts, was zu einem erfolgreichen Release und Vermarktung führt, alleine bewältigen. Sie sind auf die Zusammenarbeit mit anderen angewiesen. Dafür sind aus ihrer Sicht drei Führungskompetenzen essentiell:

• Orientierung geben,
• Coaching Habits und
• Team Building

Teams brauchen eine Orientierung und eine Richtung, damit sie ein gemeinsames Ziel erreichen und Tätigkeiten sinnvoll priorisieren können. Orientierung ensteht u.a. durch eine gemeinsam getragene Produktvision. Diese beschreibt, was am Ende anders sein soll. Aus dieser Vision wird eine Strategie abgeleitet, die beschreibt, welche Probleme gelöst und welche Themen dafür bearbeitet werden sollen. Sie empfiehlt den „Decision Stack“ von Martin Eriksson als Tool für die Strategiearbeit.

Coaching Habits helfen die Wirksamkeit von Teams durch Coaching zu verbessern. Das bedeutet konkret Zuhören, Annahme einer guten Intention, Denken in Perspektiven, emotionale Selbstkontrolle und die Arbeit an Vision & Werten. Gutes Zuhören heißt nicht nur sich auf die Menschen zu fokussieren, sondern auch deren Kontext zu berücksichtigen. Coaches gehen davon aus, dass die Menschen bzw. ihre Coachees mit guten Intentionen an ihre Arbeit herangehen. Coaches versuchen in Perspektiven zu denken, weil jeder Mensch aus der eigenen Perspektive heraus denkt und handelt. Emotionale Selbstkontrolle ist schwer, besonders, wenn Menschen gestresst sind. Das heißt im Wesentlichen, an der Fähigkeit zu arbeiten unter Druck ruhig zu bleiben und resilient auf Herausforderungen sowie Misserfolge zu reagieren. Es hilft dabei, wenn man seine eigenen Trigger kennt und daran arbeitet mit diesen gut umgehen zu können. Die Arbeit an einer gemeinsamen Vision und Werten schafft die Grundlage für eine gute Zusammenarbeit sowie eigenverantwortliches Handeln im Team.

Team-Building ist in der Softwareentwicklung essenziell. Ein gutes Team zeichnet sich durch psychologische Sicherheit, Verlässlichkeit, Struktur & Klarheit, Bedeutsamkeit und Wirksamkeit aus. Psychologische Sicherheit entsteht u.a. durch die Verhaltensweise von Führungskräften, deren Umgang mit Fehlern, Lob und Transparenz. Verlässlichkeit braucht gemeinsam Vereinbarungen und ein Handeln nach dem Prinzip „Ich tue, was ich sage.“. Struktur und Klarheit entsteht durch Rollenklärung, Roadmaps, OKR, Strategie und Vision. Bedeutsamkeit entsteht durch Werte, Vision und Produktprinzipien. Wirksamkeit entsteht durch Vision und die Messung des Fortschritts in Richtung der Vision.

Buchtipps:

• „Good Strategy, Bad Strategy“
• “A thin book of trust”
• „Product Vision is Science Fiction”
• The Decision Stack

Skaliertes Produktmanagement mit den 5 Ts

Ralph Jocham (effective agile) stellte in seinem Beitrag einen Ansatz vor, um Product Ownership für Produkte zu skalieren, an denen mehrere Teams arbeiten.

„Product Owner:innen sind dafür verantwortlich, den Wert eines Produktes für Kund:innen und das Unternehmen zu maximieren.“

Skalierung von Product Ownership beginnt damit, was POs praktisch tun. Product Owner:innen sollten sich auf die Wertmaximierung fokussieren. Sie sollten keine operativen Tätigkeiten im Team übernehmen. POs sollten sich als Unternehmer:innen im Unternehmen verstehen. Sie sollten sich nicht auf das Schreiben von Backlog-Items, die Klärung von fachlichen Fragen oder die Budgetbeschaffung fokussieren. Sie sollten das Produkt mit Product Vision, Product Strategy und Value Discovery strategisch vorantreiben. Sie stellen sicher, dass in der Delivery der angestrebte Wert entsteht. Dafür schaffen sie Orientierung und übergeben die Verantwortung für die Umsetzung an ihre Teams.

Ralphs Ansatz nach, nutzen POs, die mit mehreren Produktteams an einem Produkt arbeiten, nur ein Product Backlog und ein Sprint Review für alle Teams. Um eine fachliche Steuerung zu ermöglichen ordnen die den Teams fachliche Expert:innen zu. Diese brechen die Produktstrategie in „Product Themes“ herunter. Auch er betont, dass Produktteams direkten Kontakt mit Kund:innen und Stakeholdern haben sollten. Sie sollten dafür über geeignete Tools zum Einbezug dieser Personen verfügen. (z.B. Nutzungsdaten, Befragungen, A/B-Testing) Dies ist die Voraussetzung autonome Arbeitsweise. Die konsistente Vorgehensweise der Teams in Bezug auf Architektur, Testing usw. wird in diesem Ansatz über Chapters oder Gilden sichergestellt.

Product Flow: Mit Kanban die täglichen Fragen an Product Owner beantworten

Felix Rink (ProKanban) veranschaulichte in seinem Vortrag, wie wichtig kleine Losgrößen oder Wetteinsätze für die Arbeit von Product Owner:innen sind. Dabei ging er auf wesentliche Kanban-Prinzipien und -Metriken ein.

POs müssen Entscheidungen treffen, selbst, wenn sie nicht alle Fakten kennen. Um das Risiko zu begrenzen, hilft es dabei in kleinen Wetten zu denken.

Felix verdeutlichte das anhand einer statistischen Simulation namens „Gamblers Ruin“. Dabei spielen zwei Spieler mit gleichen Fähigkeiten, gleichem Budget und gleichem Wetteinsatz ein Spiel über mehrere Runden bis einer Pleite ist. Die Wahrscheinlichkeit, dass beide Spieler ruiniert sind, ist gleich. Die Frage ist nun welcher der drei Parameter Fähigkeit, Budget oder Höhe des Einsatzes (Wettgröße) die Wahrscheinlichkeit des Ruins deutlich senkt bzw. des Gewinns deutlich erhöht. Er zeigte sehr anschaulich, dass die Höhe des Einsatzes bzw. die Wettgröße den höchsten Einfluss auf die Wahrscheinlichkeit von Gewinn bzw. Ruin hat.

Das lässt sich auf die Arbeit von Product Owner:innen übertragen. Um die Erfolgswahrscheinlichkeit zu erhöhen, sollten sie die Wettgröße, die sie mit ihrer Entscheidung eingehen, so klein wie möglich halten. Kleinere Wetten bedeuten häufigere Wetten und damit geringeres Risiko. Die Wettgröße des POs ist die Größe des Paketes, was entwickelt werden soll, und die damit verbundene Durchlaufzeit durch den Entwicklungsprozess bis zu dem Zeitpunkt, an dem die Daten über den Produkterfolg vorliegen.

„Eines der größten Hindernisse für Flow ist die Arbeit an zu großen Einheiten.“

Um die Durchlaufzeit besser einschätzbar zu machen, bietet Kanban ein Konstrukt namens „Work in progress“-Limit (WIP). Dies beschreibt und begrenzt die Anzahl der Arbeitspakete, an denen gleichzeitig gearbeitet wird. Das sorgt dafür, dass die Durchlaufgeschwindigkeit im Entwicklungsprozess konstant bleibt. Welches WIP-Limit passend ist, muss dabei jedes Team für sich individuell herausfinden.

Im agilen Umfeld ist es eine Herausforderung den Zeitpunkt der Fertigstellung vorherzusagen. Er empfiehlt sich bei der Schätzung des Fertigstellungs-Zeitpunktes an der durchschnittlichen Durchlaufzeit der Arbeitspakete zu orientieren. Mit Hilfe einer Monte Carlo-Simulationen kann ermittelt werden, wie viele Arbeitspakete bis zu einem bestimmten Zeitpunkt unter den gegebenen Umständen fertig werden.

Die Rolle „Product Owner“: gestern, heute, morgen

In der Podiumsdiskussion diskutierten Silke Kanes, Ina Einemann, Simonetta Batteiger und Ralph Jocham, über die Rolle „Product Owner:in“. Die Diskussion wurde von von Stepfan Roock und Ralf Lethmate moderiert.

Die wesentlichen Erkenntnisse aus der Diskussion:

POs gestern: In den Anfängen lag der Fokus der PO-Rolle vorrangig auf der schnelleren Auslieferung von Produkten. Das Product Backlog wurde als detaillierter Plan missverstanden, was zu überladenen Backlogs mit tausenden Items führte. POs kamen oft aus der Technik und mussten sich zusätzliches Wissen in den Bereichen User Experience und Business aneignen. POs hatten früher vor allem eine verwaltende und begutachtende Tätigkeit.

POs heute: Die Rolle des POs hat sich mittlerweile erheblich erweitert und professionalisiert. In der heutigen schnelllebigen Markt- und Arbeitsumgebung ist die PO-Rolle strategischer und umfasst die Schaffung von Wert sowohl für Kund:innen als auch für das Unternehmen. Die Rolle ist zunehmend von Verständnis für Anwender:innen und Wirtschaftlichkeit geprägt. Backlogs sind kleiner und fokussierter geworden, und POs werden als strategische Entscheider:innen und motivierende Führungskräfte innerhalb ihrer Teams gesehen. Die PO-Rolle wird in den Unternehmen unterschiedlich gelebt.

POs morgen: Die Zukunft der PO-Rolle wurde mit Unsicherheit und Neugier betrachtet. Es wurde diskutiert, ob die Rolle sich in Richtung einer noch stärkeren Integration in Produktmanagementfunktionen entwickeln oder ob Entwicklungsteams zunehmend selbst die Produktverantwortung übernehmen könnten. Die Nutzung von neue KI wurden als potenzielle Einflussfaktoren auf die Entwicklung der PO-Rolle erörtert. Die Runde war sich einig, dass sich durch KI die Arbeit von POs verändern wird. Die Grundprinzipien der PO-Tätigkeit, wie z.B. das adaptive Planen oder eigenverantwortliche Teams werden jedoch bleiben.

Die Diskussion verdeutlichte, dass die Rolle des Product Owners einem ständigen Wandel unterliegt, getrieben durch Veränderungen in der Arbeitswelt, Technologie und Marktbedürfnissen. Während sich die Rolle weiterentwickelt, bleibt die zentrale Herausforderung, echten Wert für Kund:innen und Unternehmen zu schaffen. Die Expert:innen betonten die Bedeutung von Flexibilität, kontinuierlichem Lernen und der Anpassungsfähigkeit an neue Herausforderungen als Schlüsselqualifikationen für erfolgreiche POs in der Zukunft.

World Cafe „Product Ownership – Was ist das und wo liegen die Herausforderungen?“

Der erste Tag endete mit einem World Cafe, auf dem die Fragen

• „Was ist Product Ownership?“,
• „Vor welchen Herausforderungen stehen POs?“ und
• „Was hast Du Dir vom ersten Tag als Impulse mitgenommen?“

diskutiert wurden. Antworten aus den verschiedenen Gruppen lassen sich wie folgt zusammenfassen:

Was ist Product Ownership?

Product Ownership umfasst das Produkt-, Risiko- und Anforderungsmanagement mit einer ganzheitlichen Verantwortung für den Erfolg eines Produkts. Es bedeutet, den Wert für Kunden und Unternehmen zu maximieren, indem man sicherstellt, dass jedes Produktinkrement echte Outcomes liefert. Product Owner:innen sorgen für die Wirtschaftlichkeit des Produkts und agieren unternehmerisch. Sie verstehen sich als fachliche Führungskräfte, die lateral führen, und als Unternehmer:innen im Unternehmen, die wesentlich zum Unternehmenserfolg beitragen.

POs arbeiten im Wesentlichen im Problemraum. Zentrale Aufgaben sind dabei die Entwicklung der Produktvision und Produktstrategie, Orientierung des Teams auf die Produktvision, effektives Stakeholder-Management, Priorisierung und Entscheidungsfindung. Sie wahren das Gleichgewicht zwischen Perfektion und Pragmatismus. POs treffen Entscheidungen und stehen für die Konsequenzen ein – positive und negative. Sie managen ihre Stakeholder aktiv, indem sie ihnen gut zuhören und echte Kundenprobleme herauskristallisieren. Sie übersetzen und vermitteln zwischen Produktentwicklungsteam und Stakeholdern. Sie sorgen für eine realistische Erwartungshaltung bei ihren Stakeholdern.

Sie schreiben nicht nur gute User Stories, sondern coachen als Servant Leader ihr Team, motivieren es und fördern eine Kultur der geteilten Verantwortung. POs werden mit einer Vielzahl von Anforderungen und Aufgaben konfrontiert. Das Setzen und Halten eines sinnvollen Fokus sowohl für ihr Team als auch sich selbst ist essentiell. Das bedeutet für sie das Delegieren von operativen Tätigkeiten.

Sie navigieren durch Unsicherheiten mit Mut, Leidenschaft für ihr Produkt, fachlicher Expertise, Führungskomptenzen und einem aktiven Gestaltungswillen. Sie denken und handeln nutzerzentriert. Sie nutzen Informationen und Daten aus regelmäßigem Kundenkontakt und Kundenfeedback als Entscheidungsbasis. Darüber lernen sie schnell, was nicht funktioniert.

Aktuelle Herausforderungen für POs

Product Owner:innen stehen vor vielfältigen und komplexen Herausforderungen.

Eine davon ist das effektive Stakeholder-Management, bei dem es gilt, verschiedene Interessengruppen bei Laune zu halten, gegensätzliche Ziele zu balancieren und Vertrauen aufzubauen. Dies erfordert die Fähigkeit, aktiv zuzuhören und die richtigen Fragen zu stellen.

Hinzu kommt die Herausforderung der lateralen Führung, bei der POs ohne disziplinarische Verantwortung Teams leiten müssen.

Die Selbststeuerung in einem Umfeld, in dem zahlreiche Themen gleichzeitig angegangen werden müssen, verlangt von POs, multidisziplinäres Wissen – sowohl fachlich als auch technisch. POs müssen häufig viele Themen gleichzeitig koordinieren und bearbeiten. POs müssen in der Lage sein, ihren Fokus zu halten, auch in stressigen Situationen ruhig zu bleiben, um einen Burnout zu vermeiden.

POs stehen vor der Herausforderung, dass ihre Teams nicht immer über die nötigen Erfahrungen und Kompetenzen verfügen. Es mangelt in vielen Unternehmen an Senior -Rollen oder Expert:innen.

Ein weiteres Problem stellt der oft zu geringe Kontakt mit Kund:innen dar. Das Sammeln von Kundenfeedback dauert oft zu lange.

Schnelles Experimentieren und “Fail Fast”-Prozess zu etablieren, um schnell aus Fehlern zu lernen, ist ebenfalls nicht einfach umzusetzen.

Die Transformation aus traditionellen Rollen wie dem Projektmanagement hin zum Product Ownership und Produktmanagement bringt zusätzliche Unsicherheiten mit sich.

Ein weiteres Hindernis kann die mangelnde Klarheit der PO-Rolle für andere Personen im Unternehmen sein, was dazu führen kann, dass Entscheidungen nicht respektiert werden.

Unklare Unternehmensvisionen und -strategien erschweren die Ausrichtung des Produkts und die Arbeit der POs zusätzlich.

Die Dynamik und Gesundheit des Teams zu bewahren sowie Budgets zu beschaffen und zu managen, sind weitere Herausforderungen, vor denen POs stehen.

Aus dem ersten Konferenztag nehmen Teilnehmenden folgende Impulse herauskristallisiert

Am ersten Tag der Product-Owner-Days konnten die Teilnehmenden eine Vielzahl an Impulsen für ihre Arbeit in Product Ownership und Produktmanagement mitnehmen.

Es wurde deutlich, dass eine stärkere Ausrichtung auf Produktmanagement innerhalb der Product Ownership und eine Vertiefung in die Discovery-Phase essentiell sind.

Die Stärkung von Führungskompetenzen und dabei insbesondere ein besseres Stakeholder-Management waren häufig genannte Impulse. Stakeholder könnten als zweites Team begriffen werden, dem POs intensiver zuhören und mit dem sie gemeinsam die echten Kundenprobleme identifizieren müssen, bevor voreilig Lösungen entwickelt werden.

Die Bedeutung des Teilens von Verantwortung mit dem gesamten Entwicklungsteam und das Delegieren von Aufgaben wurden hervorgehoben.

Die Arbeit in hybriden Umgebungen, in denen Teams sowohl agil als auch nicht-agil arbeiten, verlangt von POs viel Flexibilität.

Häufig wurde auch über die Nutzung von Metriken und KPIs zur Verbesserung der eigenen Arbeit sowie des Entwicklungsprozesses gesprochen. Es wurde beispielsweise über die Reduzierung von “Time to Delivery“ gesprochen, um schnell und effektiv auf Marktbedürfnisse reagieren zu können. In diesem Zusammenhang war das Arbeiten mit kleinen Losgrößen bzw. richtig geschnittenen Arbeitspakten zur Risikominimierung ein Thema. Ein weitere Impuls war das Schließen der Lücke zwischen Vision und der Erstellung des Backlogs.

In Bezug auf Kommunikation wurde über die zielgruppengerechte Aufbereitung von Inhalten, die Fokussierung auf Outcomes statt auf Features, und die Unterstützung von Diskussionen durch Visualisierung wurden als wichtige Ansätze betont.

Die Wertschätzung für andere Perspektiven, ein tiefes Verständnis für die eigene Rolle sowie die Klärung von Entscheidungsbefugnissen und Verantwortung waren weitere wichtige Take-Away.

Siehe auch

• Gesamtfazit zu den Product Owner Days 2024
• Tag 2: Outcome Based Roadmaps, Bedürfnisse & Erwartungen, Yogis & Jedis, Product Operating Model, Early Startup