Product Owner (PO)
Der Product Owner verantwortet Priorisierung.
Er sorgt dafür, dass das Team an den wertvollsten Themen arbeitet – in der richtigen Reihenfolge und mit klarem Fokus.
Der PO entscheidet nicht über Architektur. Er entscheidet über Reihenfolge und Scope.
1. Kurzdefinition
Ein Product Owner:
- priorisiert das Backlog
- klärt Anforderungen
- definiert Akzeptanzkriterien
- trifft Scope-Entscheidungen
- schützt Fokus
Er ist verantwortlich für Wert-Reihenfolge –
nicht für Delivery-Umsetzung.
2. Kernverantwortung
Der PO entscheidet:
- Was kommt zuerst?
- Was lassen wir bewusst weg?
- Was ist „gut genug“?
- Welche Risiken akzeptieren wir?
- Wann stoppen wir ein Feature?
Priorisierung bedeutet immer:
bewusst Nein sagen.
3. Was macht ein PO konkret?
3.1 Backlog-Verantwortung
- Priorisieren nach Business-Wert
- Abhängigkeiten transparent machen
- Scope stabil halten
- Work-in-Progress begrenzen
Ein Backlog ist kein Wunschzettel.
3.2 Anforderungen klären
- Ziel und Kontext erklären
- Akzeptanzkriterien definieren
- Edge Cases sichtbar machen
- Nicht-funktionale Anforderungen abstimmen
Unklare Anforderungen sind Rework.
3.3 Fokus schützen
- Scope-Creep verhindern
- Ad-hoc-Wünsche kanalisieren
- Stakeholder-Erwartungen managen
- „Fast fertig“ verhindern
Fokus ist ein Produktivitätsfaktor.
4. Schnittstellen der Rolle
4.1 Mit dem Software Architect
- Nicht-funktionale Anforderungen klären
- Risiko-Transparenz herstellen
- Qualität bewusst entscheiden
- technische Konsequenzen verstehen
Ein PO muss Architektur nicht entwerfen –
aber ihre Auswirkungen verstehen.
4.2 Mit dem Team
- Kontext liefern
- Zielbild erklären
- Akzeptanzkriterien präzisieren
- Feedback aufnehmen
Teams brauchen Klarheit, nicht Mikromanagement.
4.3 Mit Stakeholdern
- Erwartungen moderieren
- Prioritäten erklären
- „Warum jetzt?“ beantworten
- Konflikte strukturieren
Der PO ist Filter – nicht Durchleiter.
4.4 Mit Delivery
- Releases nach Wert priorisieren
- Risiken transparent machen
- Definition of Done respektieren
- nicht-funktionale Qualität mittragen
5. PO vs. PM
| Product Owner | Product Manager |
|---|---|
| Priorisierung | Strategie |
| Backlog | Markt |
| Umsetzungsebene | Richtungsebene |
| Sequenzierung | Positionierung |
| Scope-Entscheidung | Investitionsentscheidung |
In kleinen Organisationen kann eine Person beide Rollen tragen. In komplexen Umfeldern ist Trennung sinnvoll.
6. Was der PO nicht ist
- kein Projektmanager
- kein Budget-Verantwortlicher
- kein Ersatz für Führung
- kein technischer Entscheider
- kein reiner „Feature-Schreiber“
Ein PO ohne Priorisierungsautorität ist wirkungslos.
7. Typische Anti-Patterns
- Backlog ohne klare Reihenfolge
- Ständiger Scope-Wechsel
- Akzeptanzkriterien fehlen
- Alles ist „High Priority“
- PO als Eskalations-Sammelstelle
- „Quality First“ ohne Budget
Solche Muster erzeugen:
- Kontextwechsel
- Delivery-Stress
- versteckte Risiken
8. PO im Qualitätskontext
Stufe 1:
- Fokus auf Speed und Lernzyklen
Stufe 2:
- Definition of Done durchsetzen
- klare Akzeptanzkriterien
Stufe 3:
- Stabilität und Qualität mitpriorisieren
Stufe 4–5:
- regulatorische Anforderungen verstehen
- Traceability unterstützen
- Scope-Disziplin entscheidend
Qualität ist immer auch eine Priorisierungsentscheidung.
9. Kurzcheck
Ein PO erfüllt seine Rolle, wenn:
- klare Prioritäten existieren
- Scope stabil ist
- Teams wissen, was „fertig“ bedeutet
- Stakeholder verstehen, warum etwas später kommt
- Risiken bewusst akzeptiert werden
Kernaussage
Der Product Owner schützt Fokus.
Er entscheidet nicht nur, was gebaut wird – sondern in welcher Reihenfolge.
Ohne klare Priorisierung wird selbst das beste Team ineffizient.