Wie kann man die PO-Rolle skalieren?

Gespeichert von Erik Wegner am/um
Aufmacherbild

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