Technical Product Owner (TPO). Ein toller Name, ein toller Job! Nur leider schwierig die Rolle zu leben und sie umzusetzen im beruflichen Alltag.
Was dieser Job theoretisch sein sollte, was er praktisch ist und ob er für euer Unternehmen oder eure neue Herausforderung geeignet ist, wird in diesem Beitrag detailiert beschrieben. Anhand meiner persönlichen 2-jährigen Erfahrung damit, werde ich die Vor-, aber auch die Nachteile aufzählen, auf die ich gestoßen bin. Abschließen werde ich diesen Beitrag, mit einer Empfehlung wie man es besser machen könnte.
Was dieser Job theoretisch, was er praktisch ist und ob er für Euer Unternehmen oder Eure neue Herausforderungen geeignet ist, hierfür möchte ich Euch in diesem Beitrag die Kriterien mitgeben. Anhand meiner persönlichen 2-jährigen Erfahrung als TPO werde ich die Vor- und die Nachteile benennen. Abschließen werde ich diesen Beitrag mit einer Empfehlung, wie man es besser machen könnte.
Was genau ist ein (TPO)
Technical Product Owner?
Eine eierlegende Wollmilchsau!
Ziemlich genau so würde ich die Position des TPO (aka Technical Product Owners) beschreiben. Aber bevor es zu plakativ wird, lass ich euch mal an meinem ersten direkten Kontakt mit dieser Position schriftlich teilhaben.
Das erste mal dass ich von dieser Rolle hörte, war noch vor meiner Zeit bei ayfie. Was ich mir bis dato unter der Position vorgestellt hatte, war ein klassischer Product Owner mit technischer Erfahrung. Ich will nicht lügen – genau das ist die Position auch in der Theorie, aber…
Mit meinem Beginn bei ayfie, habe ich diese Rolle eingenommen, für insgesamt 3 Teams – zwei an unseren Core Products und eines für ein “Grüne Wiese” Nebenprojekt. Heruntergebrochen aufs Wesentliche, bestand mein Aufgabenbereich für diese drei Teams aus mindestens folgenden zwei Rollen:
- Ein Product Owner & Manager, der die Roadmap festlegt, den Kunden kennt, eine Vision vom Produkt hat, agil auf Markt-Veränderungen reagiert und Epics und Tickets schreibt, die maßgebend sind für die Arbeit die daraufhin vom restlichen Team verrichtet wird.
aber auch… - Eine technisch affine Person, am besten mit einem starken Entwickler-Background, die technische Requirements festlegen und im Zweifel entscheiden kann. Aktiv am Code arbeiten soll er nicht – er ist eher der dirigierende Part, trifft aber finale Entscheidungen, wenn das Team selbst sich nicht einigt.
Eine Traumstelle für jeden, der Affinität für beide Welten hat, oder sich die jeweils andere der beiden Welten noch aneignen möchte. Allerdings ist diese Position noch sehr jung und nicht wirklich verbreitet, was viele Missverständnisse hervorrufen kann, sehr oft tut und in meinem Fall auch getan hat.
Wie man oben schon sieht, ist das Portfolio dass man als TPO mitbringen muss, doch sehr facettenreich und herausfordernd. Da man die komplette Kontrolle über den gesamten Lebenszyklus und Entwicklungsweg des Produktes in den Händen trägt muss man sehr verantwortlich damit umgehen. Um das beste herauszuholen für die Firma, das Team und das Produkt, müssen technische und auch produktrelevante Entscheidungen vereint werden.
Der TPO agiert also einheitlich im Namen des Produktes und (!!) der IT. Obwohl die beiden Bereiche ziemlich oft antagonistisch agieren, müssten sie in einer optimalen Welt zusammen halten – für das Wohl der Firma.
Der unausgesprochene dritte Teil der Rolle
Allerdings bleibt es in den meisten Fällen einer TPO Rolle, nicht nur bei den beiden oben erwähnten Aufgaben. Hinzu kommt ein wesentliches Aufgabengebiet, das das an sich gut durchdachte Produkt & IT Konstrukt ins wanken bringt:
- Disziplinarische Führungskraft, mit hoher emotionaler Intelligenz, der sich um die Mitarbeiter, das Team und den Menschen hinter diesen Personen kümmert. Ob dies nun durch One-on-Ones passiert, oder einen anderen Weg, ist dem TPO selbst überlassen.
Dieses Verantwortungsgebiet, kennt ihr sicherlich auch von anderen Job Beschreibungen. So zum Beispiel beim Engineering Manager, Teamleiter, disziplinarische Führungskraft usw.
Warum unausgesprochen? Nunja, weil es in den meisten Beschreibungen von TPO Rollen weg gelassen wird, aber in einem Team doch irgendwie ausgefüllt werden muss. Und da der TPO den Großteil der administrativen Arbeit in einem Team alleine ausfüllt, kann er diesen auch gleich mit übernehmen – So der Wunsch.
Und seien wir mal ehrlich: Nur sehr wenige Firmen stellen Personen ein, die sich einzig und allein um die Mitarbeiter, deren Weiterentwicklung und dem Teamgefüge kümmern. Meistens sind das hybride Rollen ….
Hybride Rollen
Da die meisten Firmen kaum jemanden einstellen würden, der sich Vollzeit mit den Mitarbeitern beschäftigt (obwohl es gar nicht mal so unklever wäre…), entstanden in der Vergangenheit hybride Positionen wie zB. der Engineering Manager. IT Entscheidungsträger auf Teamebene, die selber noch am programmieren sind und nebenebei führen sie One-on-Ones und entwickelen ihre Mitarbeiter weiter.
Einen TPO einstellen, ist ein Commitment. In dem Moment wo man dies tut, bleibt kein weiterer Platz für einen weiteren “Manager”, da die großen Bereiche IT und Produkt vom TPO schon abgefrühstückt werden. Einer, allerdings, muss die Aufgaben eines disziplinarischen Leiters ausfüllen, was in diesen Fällen dann der TPO übernimmt. Dies allerdings verkompliziert seine Rolle unnötigerweise und lässt sie aufwandsmäßig explodieren.
Hält man sich allerdings an bestimmte Vorgaben und ist man sehr explizit in der Beschreibung und Definition der Position des TPOs, kann dies einem Hauptgewinn extrem nahe kommen.
Warum diese Rolle genau das ist, was sich jede Firma wünsche sollte, werde ich in den kommenden Absätzen erläutern.
Warum sich Produkt und Technik (eigentlich) beißen.
In einem “klassischen” Setup einer Organisationsstruktur – wie es aktuell gelehrt und gelebt wird in den meisten Betrieben – gibt es eine klare Aufteilung zwischen Produkt und IT. Dies beginnt im Team und der Abteilung und führt hoch bis zum VP Level (je nach größe der Firma). Ein VP IT und zusätzlich ein VP Product sind definitiv keine Seltenheit aktuell. Dort werden dann Entscheidungen konsolidiert, “ausdiskutiert” und daraufhin wird gemeinsam entschieden welchen Weg man geht.
Allerdings ist es so, dass Produkt und Vertriebs-Entscheidungen antagonistisch sind zu den Wünschen und Bedürfnissen der IT und vice versa – zumindest in den meisten Fällen. Ein Beispiel dafür ist die technische Schuld die aufgebaut wird, damit man Deadlines einhält und Requirements erfüllt, auf die man sich zuvor geeinigt hat.
Diese Schuld aufzubauen, ist oft ein Wunsch des Produktes, da man zeitlich früher Features releasen kann; Die Schuld abzubauen eher der IT, da sie ihr Leben dauerhaft erschwärt.
(Und genau hier möchte ich auf das Wort “eigentlich” in meinem Absatztitel eingehen. An sich haben beide Parteien den selben Schmerz bei so einer Entscheidung… sie verlangsamt die weitere Entwicklung enorm. Hacks finden ihren Weg in den Code, um die man dann in der Zukunft herumbauen muss. Dies kostet Zeit, Planung und viele Nerven)
Dysbalancen im Entscheider-Team gefährden die Firma
Wenn es dann darum geht, das gerade eben erwähnte Gespräch zu führen, bedarf es zwei gleichberechtigte Parteien. Besteht allerdings in der Zusammenarbeit der zwei Parteien eine Dysbalance, weil eine Partei in Diskussionen/Gesprächen stärker ist als die andere, verliert jeweils eine Partei und die andere gewinnt.
Betrachtet man die Momentaufnahme ist es gut, da man sich (ungewollt zwar) auf etwas geeinigt hat und weiter macht.
Betrachtet man dies aber im Ganzen – und zwar aus Sicht des Wohles der Firma – ist dort etwas passiert das man nicht will. Eine der beiden Parteien drängt die Ausrichtung der Firma, in eine bestimmte Richtung. Dies kann entweder zu einer übertrieben produktgetriebenen Richtung in der Entwicklung führen, oder auch zu einer übertrieben technikgetrieben Richtung.
Ein perfektes Beispiel dafür, wie unterschiedlich dies sein kann, will ich euch an Hand eines ganz besonderen Meetups erklären, das ich vor ca 2 Jahren persönlich erleben durfte.
Clash of Companies!
Ein von meinem ehemaligen Chef organisiertes Treffen von Mitarbeitern dreier komplett unterschiedlicher Firmen, öffnete mir damals die Augen. Es machte mir glasklar, was für Konsequenzen dieses Ungleichgewicht zwischen Produkt und IT für die Firmenausrichtung hat. Wir hatten dort eine ziemlich offene Diskussion über die aktuellen Machtverhältnisse der jeweiligen Firma und was dies für Nachteile mit sich bringt.
Auf der einen Seite waren Personen aus dem mittleren Management einer großen Münchner Fintech Company, bei der die Ausrichtung der Firma rein über das Produkt und den Vertrieb gesteuert wurde. Technische Schuld abarbeiten wurde kaum genehmigt, da die Produktentwicklung dadurch stagniert und potentiell viel Geld verloren geht.
Die zweite Partei, waren Personen meines ehemeligen Arbeitgebers AutoScout24, in der die Machtverhältnisse eher auf Seiten der IT lag. Die Produktabteilung hatte die Jahre zuvor bereits einige Dämpfer abbekommen, die sie enorm geschwächt hatte. Technische Schuld gab es kaum, da die Produktabteilung nicht das Standing hatte, dies einzufordern. Die IT konnte machen was sie wollte, sie hat den Alltag diktiert.
Und da kommt der TPO ins Spiel …
So stand ich nun da bei dem Event, und hörte mir beide Seiten an; und gab auch beiden Seiten Recht.
Allerdings, haben mir die Vorteile, aber auch die enormen Nachteile von einer Situation in der eine Partei “mächtiger” ist als die andere, sehr zu Denken gegeben. Dies bekommt man nur sehr selten so klar vor Augen gezeigt, wie bei so einem Treffen von unterschiedlichen Kulturen.
Zugleich aber, habe ich mit jeder Minute die verstrich, mehr und mehr die Vorteile einer Rolle gesehen, die Verantwortung für beide Bereiche einer Firma oder eines Produktes hat – wie es bei mir damals der Fall war.
Mal ist er die Produkt-Person, mal der IT Manager. Mal denkt er aus Sicht des Kunden, mal aus Sicht des Business-Menschen und mal aus Sicht des Entwicklers. Aber… er denkt immer aus der Sicht der Firma und nicht nur durch die Brille einer der beiden, respektive drei Parteien.
So ein Event empfehle ich jedem, der sehen möchte wie Firmen denken und agieren, die unausgeglichene Mächte innerhalb der Firma haben. Gewollt (wie bei Firma A) oder ungewollt (wie bei AutoScout24).
Meine Erfahrung mit der Position
Da ich bei AutoScout24 sehr viel direkt und indirekt mit Produkt gearbeitet habe, habe ich mich der Rolle gewachsen gefühlt. Allerdings waren mir einige Dinge vorher nicht bewusst, die ich schmerzhaft spüren und lernen musste!
Aus eigener Erfahrung, kann ich im Nachhinein fünf Sachen dazu sagen:
- Die Position ist pure Schizophrenie!
“Diese Änderung ist essentiell für die Stabilität und Wartbarkeit des Codes”, und zugleich …
“Wir können die Produkt-Entwicklung nicht stagnieren lassen, der Kunde geht uns auf die Barrikaden”. Beides aus meinem Mund.
Aber auch:
“Lasst uns das hinhacken, damit wir rechtzeitig zum nächsten Release den Bug gefixt haben und danach machen wir es schön”, und zugleich …
“Ich weiss, wir wollten es schön machen, aber es geht nicht, da wir sonst 3 Millionen Euro verlieren werden”.
- Es kostet Unmengen an Kraft,
von der wir Menschen nicht unendlich viel haben. Sich selber, mit einer anderen Brille zu hinterfragen, zu challengen und gegen sich selbst zu argumentieren, ist eine der anstrengendsten Aufgaben die ich die letzten Jahre erfüllen musste.
- Für die Firma ein Gewinn, für den TPO nicht immer…
Wenn einer bei der Besetzung und Festlegung so einer Position gewinnen kann, dann ist es die Firma. Der Verlierer ist immer der TPO, sehr pauschalisiert und provokant behauptet.
Er wird mit jeder Entscheidung die er trifft, sowohl richtig liegen, aber auch falsch. Ein Stückchen Niederlage ist bei jeder Entscheidung immer dabei.
Ein Stückchen Sieg aber auch, muss man fairerweise sagen ;)
- Ein TPO sollte keine disziplinarische Verantwortung haben!
Die Expertise die ein TPO mit sich bringt, lässt keinen Platz für weitere Fähigkeiten und noch mehr Verpflichtungen und Verantwortung. Er soll sich auf das Business fokussieren, damit die Arbeitsplätze für die Mitarbeiter auch in der Zukunft gesichert bleiben. Business aus Sicht des Produktes, aber auch Business aus Sicht der IT.
Die disziplinarische Führung muss aus einer anderen Quelle kommen, die ihre Stärken auch auf genau diesem Gebiet besitzt. Nur gibt es solche expliziten People-Manager Positionen kaum.
(Kurzer Einwand: Es ist machbar alles drei Gebiete zu verantworten, allerdings nur unter der Voraussetzung, dass der TPO ein einziges Team verantwortet und nicht mehrere und die entsprechenden Skills vorab schon mitbringt …)
- Der TPO braucht einen Leader, der ihm zuhört.
Vor allem wegen den Punkten #1, #2 und #3 dieser Liste, sehe ich es als essentiell (!!) dass der TPO eine Führungskraft (VP, CPO, CTO) hat, die sich Zeit für ihn nimmt, ihm zuhört, ihm hilft wenn er mal Hilfe braucht. Mit ihm gemeinsam muss er dann versuchen, die Schwachstellen dieser Position auszumerzen, damit alle Beteiligten von dieser Position profitieren.
Mir persönlich (als Ilias) ist der disziplinarische Führungsteil sehr wichtig im beruflichen Alltag. Dem entsprechend war ich neben den oben erwähnten Belastungen die die Rolle TPO so mit sich bringt, auch persönlich daran interessiert Weiterentwicklungsgespräche mit den Entwicklern zu führen, feste 1-on-1s zu haben und für die Team-Motivation, das Commitment und die Accountability zu sorgen!
Mein Vorschlag für interessierte Firmen lautet …
Geht das Experiment ein und implementiert die Rolle eines TPO’s in eurem Unternehmen, falls eure Firmengröße, euer wirtschaftlicher Stand und die Stimmung innerhalb der Firma so etwas zulassen. Es ist es auf jeden Fall Wert!
Ob ihr das nun selber verkörpern wollt, oder euch wünscht dass es ein anderer in eurem Unternehmen macht, spielt dabei keine Rolle. Schafft den benötigten Platz um dieser Position Leben einzuhauchen und ihr werdet zu 100% mit vielen Erfahrungen und Learnings aus diesem Experiment gehen. Die einen mit dem Bewusstsein dass diese Position das ist, was sie Jahre lang gebraucht haben … und die anderen mit dem Wissen, dass diese Stelle nicht in die Firmen-Struktur passt.
Allerdings solltet ihr euch vorher Gedanken über das Aufgabengebiet machen und dies schriftlich verewigen, da es sonst zu vielen Missverständnissen führen kann. Hier ist eine Liste potentieller Punkte die man in so einer Vereinbarung auf jeden Fall besprechen und beschließen sollte:
- Was gehört zu den Aufgaben des TPO’s in eurer Firma
- Was gehört NICHT in sein Aufgabengebiet
- Wer übernimmt die Aufgaben die der TPO nicht in seiner Job description hat? (zB disziplinarische Führung)
- An wen reportet der TPO? An die IT? An das Produkt? An beide?
- Wer ist die Ansprechperson, die für den TPO da ist, wenn er jemanden braucht?
Fazit
Die Rolle des TPO ist wunderbar. Sie vereint zwei große Entscheidungsträger und Parteien eines Teams/Abteilung in einer Person, die Entscheidungen zum Wohle der Firma/des Teams trifft, aus einem Guss und einer Hand.
Da der Druck und die Verantwortung die auf dieser Rolle lastet doch enorm ist, muss man sehr exakt in der Rollenbeschreibung sein. Die ansonsten daraus resultierte Überfrachtung wirkt enorm kontraproduktiv und löst den gegenteiligen Effekt aus, von dem was man eigentlich erreichen wollte.
Ein TPO muss sich auf seine zwei Kerngebiete konzentrieren müssen (so lächerlich sich “zwei Kerngebiete” auch anhören). Wenn er neben den beiden Bereichen Produkt und IT, den disziplinarischen Teil (sprich: Teams und Mitarbeiter führen) ebenfalls übernimmt, wird einer, oder alle drei Bereiche sehr drunter leiden.
Mit diesem Beitrag möchte ich mich auch bei meinem ehemaligen Arbeitgeber https://www.ayfie.com/ bedanken, bei dem ich diese doch relativ neue Position kennenlernen und leben durfte, neben einigen weiteren Aufgabengebieten.
Ich bin sehr gespannt auf eure Meinung dazu und falls vorhanden auch eure Erfahrung mit der Position “Technical Product Manager”. Bei Fragen rund um das Thema TPO, stehe ich natürlich gerne zur Verfügung. Ob hier in den Kommmentaren oder über LinkedIn – meldet euch einfach.
