Der Product Owner als Key Account Manager

Bild: Pexels / Christina Morillo - Lizenz

Eine der zentralen Vorraussetzungen von agiler Produktentwicklung ist die Etablierung von so genannter Product Ownership. Um für den eigenen Fortschritt nicht auf andere angewiesen zu sein wird eine möglichst starke Focussierung angestrebt. Ein einziges crossfunktionales Team exklusiv für ein Produkt, mit allen Berechtigungen es verändern und modifizieren zu dürfen. Nur so ist das schnelle Inspect & Adapt möglich, das den Kern aller agilen Vorgehensweisen bildet.

Der de facto Standard dieser Umsetzungen ist mittlerweile Scrum, das in seinen Teams sogar eine explizite Rolle für Product Ownership hat, sinnigerweise Product Owner genannt. Richtig umgesetzt ist der nicht nur ein einfacher Business Analyst oder Anforderungsmanager sondern er entwickelt sein Produkt langfristig und strategisch weiter, hat den Überblick über vergangene Entscheidungen und hält Kontakt zu dessen Anwendern und Stakeholdern.

Soweit die Theorie. In den meisten Fällen ist sie anwendbar, in einigen allerdings nicht. Im Agentur-Umfeld kommt es beispielsweise vor, dass Teams für einzelne Sprints an Kunden verkauft werden um an dessen Systemen zu arbeiten, in Konzernen kann es sein, dass die Zuordnung eines Teams zu einem Produkt nur so lange anhält wie die dahinterstehende Fachabteilung Projektbudget hat. In diesen und vergleichbaren Fällen springen Teams und Product Owner regelmässig von Produkt zu Produkt.

Um die negativen Effekte dieser ständigen Wechsel zumindest in Grenzen zu halten findet man in manchen Unternehmen eine Ausgestaltung der Product Owner-Rolle die in Teilen einem Key Account Manager entspricht, also dem Hauptbetreuer eines wichtigen Kunden oder Auftraggebers. Für diesen ist der jeweilige Product Owner dann der primäre Ansprechpartner in der Anwendungsentwicklung, selbst dann wenn es um verschiedene (weiter)zu entwickelnde Produkte geht.

Was in einer solchen Konstellation weiterhin möglich ist, ist eine dauerhafte Beziehung zu wichtigen Anwender- und Stakeholdergruppen. Andere Auswirkungen können zumindest abgeschwächt werden: die Kontextwechsel werden tendenziell weniger, da die Wahrscheinlichkeit steigt auch zukünftig wieder mit den Produkten zu tun haben, und vergangene Erfahrungswerte können in diesen Fällen wiederverwertet werden.

Ganz ersetzen kann eine solche Konstellation echte Product Ownership nicht (alleine deshalb nicht weil zwischendurch andere Teams daran arbeiten können), in den oben genannten Konstellationen ist sie aber eine gute Möglichkeit dem zumindest so nah zu kommen wie möglich.