Product Owner, User Centered Product Owner, UX Product Owner: Beschreiben alle drei Bezeichnungen die gleiche Rolle oder gibt es Unterschiede? Welche Vorteile bringt ein Nutzerfokus dem Produkt und welchen Herausforderungen sind wir unterwegs begegnet?
Wir betrachten hier die einzelnen Ausprägungen, berichten über unsere Erfahrungen und den Mehrwert von Nutzerfokus in der Rolle des Product Owner (PO).
Nutzer im Mittelpunkt - was heißt das?
Nicht nur wer sich mit UX auseinandersetzt weiß, dass eine Software von der Akzeptanz durch ihre Nutzer abhängig ist. Durch User Stories und ähnliche Werkzeuge versuchen gerade agile Teams seit Längerem, sich die Bedürfnisse der Anwender schon während der Entwicklung vor Augen zu halten. Ebenso häufig kommt es in unserem Projektalltag aber vor, dass eben diese Werkzeuge zu Floskeln verkommen. Es begegnen uns immer häufiger Product Owner mit Nutzerfokus oder Anfragen nach solchen. Über die Jahre sind uns drei Ausprägungen dieser Rolle begegnet:
Product Owner - die offizielle Definition
Scrum.org definiert den Product Owner, als den Verantwortlichen für die Wertmaximierung eines Produktes:
"A Scrum Product Owner is responsible for maximizing the value of the product resulting from the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals."
Was dieser Definition jedoch fehlt, ist ein Blick auf die Nutzer und wie man mit ihren Bedürfnissen umgehen soll. Scrum möchte Software als solche, nicht nur diejenigen mit einem Nutzerinterface bedienen. Und dafür braucht man nicht zwangsläufig eine Nutzerbrille.
Diese Definition ermöglicht uns einen sehr breiten Stand, stellt keine Expertenrolle des Teams über eine andere. Wir erleben, dass gerade technikaffine POs sich nah an dieser Variante bewegen. Gerade bei Software ohne Nutzerinteraktion lassen sich sehr effizient Ziele erreichen.
In unserem Projektalltag kommt es immer wieder dazu, dass Produkte so zwar fertig werden, jedoch nicht zwangsläufig gut nutzbar sind. “Wert” wird der Nutzerinteraktion eher zögerlich zugeordnet. Das begegnet uns insbesondere dann, wenn keine harte Metrik wie “Nutzer bezahlt etwas” am Ende des Produktes steht.
User Centered Product Owner
"Ein User Centered Product Owner zu sein heißt, die Interessen und Bedürfnisse der Nutzer zu vertreten. Zudem sollte er in der Lage sein technische Implikationen seiner Produktentscheidungen zu verstehen. Die Akzeptanz durch Nutzer spielt eine große Rolle."
Beim Verfassen und Bearbeiten von Aufgaben steht der Gedanke “Welcher Mehrwert entsteht hier für den Nutzer?” präsent zur Diskussion. Diese Sichtweise ermöglicht, dass das Team Features direkt mit dem Nutzer verprobt. Features starten als Hypothesen, die für den Kunden funktionieren oder noch Schliff brauchen, bis sie umgesetzt werden.
Wir finden es wichtig, darauf zu achten, dass die Konzept-, Design- und Technikprozessse integriert sind, dabei in aktivem Dialog stehen. Je stärker der User Centered PO daran interessiert ist, mehr über die Nutzer zu erfahren, desto deutlicher profitiert das Produkt - und damit der Nutzer.
Auch haben wir festgestellt, dass ein Duo aus Product Owner und UX-Konzepter im Austausch ein effektives Team bilden können.
User Experience Product Owner
"Ein User Experience Product Owner besitzt fundiertes Handwerkszeug aus dem Bereich UX. Ebenso wird tiefes Verständnis für Business, Technik und Nutzer abgebildet. Ein UX-PO ist in der Lage, eigenständig den Spagat zwischen Nutzen und Machbarkeit zu bewältigen."
Schon zu Beginn eines Tickets versuchen wir als UX-PO, den für Nutzer erzeugten Mehrwert in den Vordergrund zu stellen. Ist der Wert für den Nutzer unklar, werden Maßnahmen ergriffen, um diesen zu schärfen. Damit wird sichergestellt, dass wir mit keiner Expertise - UX eingeschlossen - Produktteile erzeugen, die unnötig für den Nutzer sind.
Als UX-PO ist man also nicht “nur UX mit PO-Hut”. Man findet blinde Flecken in der Sicht auf den Nutzer, erhebt Erkenntnisse und verarbeitet sie in Ticket und Backlog. Das bedeutet natürlich auch Kompromisse zu treffen, wo sie nötig sind.
Den richtigen Product Owner-Typ für die Aufgabe wählen
Unsere Erfahrung zeigt, dass ein PO, der Entscheidungen an Hand von Nutzerbedürfnissen trifft, einen höheren Mehrwert für das Projekt und Produkt generiert:
- Tickets können mit Ergebnissen aus Nutzertests schärfer beschrieben werden.
- Der Wert einzelner Tickets wird mit Nutzerfeedback greif- und messbarer.
- Das Team arbeitet als Ganzes auf ein nutzbares Produkt hin.
- Das finale Produkt entspricht den Bedürfnissen des Nutzers und wird akzeptiert.
Auch wenn die Vorstellung schmackhaft ist, in jedem Projekt einen UX-PO zu platzieren, haben wir gelernt dass die Wahl sehr kontextabhängig sein sollte. Wenn man beispielsweise den existierenden PO dazu befähigen möchte, zukünftig UX-PO zu sein, macht es Sinn einen Sparringspartner zu stellen. Dieser unterstützt das Team als Konzepter und gleichzeitig den PO dabei, Entscheidungen zukünftig besser zu treffen.
Bei komplexen Projekten mit vielen Teams kann es herausfordernd sein, geteilte Rollen auszufüllen - sowohl Konzepte zu erstellen, als auch das Backlog zu verwalten. An dieser Stelle empfehlen wir häufig einen zusätzlichen Konzepter für das Projekt einzuplanen.
Es gibt unterschiedliche Ausprägungen der Rolle “Product Owner”, uns ist es grundsätzlich wichtig, dass der Nutzer bei Entscheidungen eine Stimme hat.
