Zwischen Kundenanforderung, Scrum-Team und Entwicklung – die Arbeit eines Product Owners

Unternehmen brauchen Software-Produkte. Software braucht Entwickler. Und Letztere müssen wissen, was ihre Produkte leisten sollen. Das Bindeglied zwischen all dem: der Product Owner (PO). Doch was macht dieser genau? Im Interview erklärt unser PO Nico Pohlenz was hinter seiner Berufsbezeichnung steckt.

 

Nico, zuerst einmal: Was genau sind deine Aufgaben als Product Owner?

Nun, ich bin quasi die Schnittstelle zwischen Business und Entwicklung – ein Vermittler zwischen unseren Kunden, unseren internen Teams sowie Management und Vertrieb. Dabei beobachte ich, was unsere User – das sind Banken und deren Kunden – brauchen. Ich stehe im stetigen Austausch mit den Instituten, nehme ihre Anforderungen und Wünsche auf und übersetze sie ins Technische, damit die Entwickler leichter arbeiten können. Das geschieht zum Beispiel in Form von User Stories, Drafts oder Skizzen. Die Anforderungen trage ich in Backlogs ein – Listen von Aufgaben an das gesamte sogenannte Scrum-Team.

 

Was ist das, ein Scrum-Team? Kannst du das kurz beschreiben?

Na klar. Als Product Owner bin ich Teil eines solchen Teams. Scrum ist dabei ein Rahmen zur Organisation von Arbeitsgruppen, die mit komplexen Aufgaben zu tun haben – wie eben der Softwareentwicklung. Ein Scrum-Team besteht aus drei Rollen: dem Scrum Master, der als Prozessmanager agiert, den Entwicklern, die für die technische Umsetzung zuständig sind und dem Product Owner.

Bei Saxess haben wir unterschiedliche Scrum-Teams. So gibt es ein Team, das sich ausschließlich um die Entwicklung unserer eigenen Produkte kümmert, etwa fidas.BMS. Und dann gibt es die ZR-Teams, die die bestehenden Zentralregulierungsportale spezifischer Kunden betreuen und weiterentwickeln. Ich bin Teil eines solchen ZR-Teams, das für Banken zuständig ist.

 

Ist die Weiterentwicklung euren Lösungen immer kundengetrieben?

Jein, als PO schaue ich natürlich auch selbst, wie etwa die Nutzererfahrung der Bankkunden oder der Workflow der Institute verbessert werden könnten. Allerdings sind gerade Banken an die hohen Anforderungen des eigenen Geschäfts und der eigenen Kunden stark gebunden. Daher kommen sie meist schon mit eigenen Ideen auf uns zu – etwa für neue Module, Features oder Strategien. Ich berate, priorisiere und vermittle dann, aber die Kunden haben das letzte Wort, die finale Entscheidungsgewalt. Im Grunde bin ich somit „nur“ ein Proxy Product Owner – ich agiere stellvertretend für die Kunden, aber ohne vollständige Entscheidungsbefugnis.

 

Was ist für deine Arbeit als PO besonders wichtig?

Es geht immer darum, unterschiedliche Erwartungshaltungen auszubalancieren – was will der eine und was kann der andere umsetzen. Als Vermittler zwischen Kunde, Entwicklung und Management habe ich damit eine herausgehobene Position mit einer gewissen Vorbildfunktion. Schließlich bin ich eine zentrale Ansprechperson für alle. Vertrauen aufzubauen, ist daher essenziell – nur so kann ich gut priorisieren und fundiert beraten.

Grundlage dafür sind regelmäßige Abstimmungen mit Kunden und im Team, klare Erwartungen und eine offene Feedback-Kultur. Transparente Kommunikation ist für meine Arbeit unverzichtbar. Außerdem brauche ich Flexibilität, gutes Zeitmanagement und die Fähigkeit, sinnvoll zu priorisieren: Kundenanforderungen können sich schnell ändern, Deadlines sind oft eng und die Entwickler müssen wissen, welche Anpassungen am wichtigsten sind. Außerdem ist der interne Austausch mit anderen Teams wichtig: Welche Probleme hatten andere? Wie sind sie damit umgegangen? So können wir voneinander lernen.

Vielen Dank für das Interview, Nico.

Sie haben Fragen zu den Aufgaben und Herausforderungen eines POs? Wenden Sie sich gern an den Experten selbst.