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