Add new comment

Im Produktwerker-Podcast wird das Thema »Skalierung der Product-Owner-Rolle mit den fünf T« besprochen.

Hört den Podcast unbedingt an, die Mitschrit hier kann nicht alle Aspekte wiedergeben.

Zu Beginn werden einige Begriffe genauer erläutert:

• Definition für Produkt: es löst ein Problem, es vereinfacht etwas für den Nutzer
• Definition Product Ownership: vereint Strategie, Vision, Umsetzung, Discovery, Delivery
• Definition Product Owner (PO): soll Strategie und taktische Umsetzung zusammenbringen und verantworten
• Definition Produktmanager: sieht nur Produkt, gibt die Umsetzung von sich weg
• Produktmanager ist die Stellenbeschreibung, PO ist die Rolle in einem Framework wie Scrum
• Product Owner: braucht ein Modell, wohin das ganze Unternehmen will
• Entwickler sind selbstorganisiert und crossfunktional, d. h. es gibt die Fähigkeiten zu Business-Analyse, UX-Design

Hinleitung

Erste Frage: Was ist unser Produkt? Antwort: meist sehr groß. Komponenten sind auch Produkte, lösen aber noch nicht die Probleme für den Markt.

Organisation soll sein:

• Eine Person ist Produkt Owner
• Es gibt nur Produkt Backlog
• Es gibt mehrere Entwicklungsteams

PO ist verantwortlich (accountable) für das Produkt, viele strategische Aufgaben liegt dort.
In der Realität: operative oder taktische Aufgaben fallen an

Fehlende Zeit für Wettbewerbsvergleiche und Marktbeobachtungen, Benutzerbefragungen

Falsches Verhalten: User Stories bestellen Lösungen. Besser: Probleme zu beschreiben, die zu lösen sind
Definition für User Story: it's a promise for a conversation to take place.
Meist wird die Vorlage als User Story angesehen: As <role> I want <task> so that <value>.

PO-Grade

• Scribe, Proxy: Wissenstransfer aber kein Besitz (ownership) eines Produkts
• Business Representative: Person aus der Fachdomäne
• Sponsor: Hoheit über Budget, darf über Einsatz entscheiden um bestmöglichen Wert zu schaffen
• Entrepreneur: Strategischer Blick, gestalterisches Wirken

Product Owner ist ein Querschnittsthema durch alle Schichten, aber nicht beliebig breit skalierbar

Taktisches Delegationsmodell

• PO: gibt Strategie vor
• Zuarbeiten erfolgen durch Stabsstellen-ähnliche Personen
• es entsteht eine PO-Blase, starke Trennung von der Entwicklung

Technisches Delegationsmodell

• das Produkt liefert Rückmeldung, z. B.
• Metriken: wie oft wird eine Funktion genutzt
• Benutzerrückmeldung: Ich hätte gern eine Funktion ...
• A/B-Testing im Produkt
• negativen Wert erkennen: die neue Funktion wird nicht verwendet oder wird anders verwendet. Warum ist das so? Wo war die Annahme falsch?
• Ziel: Kontinuierliche Discovery im Produkt verankern

Team-Delegationsmodell

• Verantwortung an das Entwicklungsteam übertragen
• Entwickler werden kleine Product Owner
• Das Team darf und soll mit Stakeholdern und Kunden kommunizieren
• Interdisziplinäres Denken und Handeln fördern
• Kundenaspekt wirkt stark ein durch die kurzen Kommunikationswege
• Team muss Aufgabe übernehmen wollen

Temporäres Delegationsmodell

• Proxy-ähnliches Modell für kurzfristige Überbrückung, = organisatorische Schuld
• Festlegung eines Überprüfungsdatums, ob die Maßnahme weiter erforderlich ist
• Dokumentation der Entscheidung, Dauer der Maßnahme
• als Vorgängerstufe zur Team-Delegation denkbar

Themen-Delegationsmodell

• Detailfragen werden durch Subject Matter Experts bearbeitet