Produktdenken für Plattformteams

Dieses Transkript wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Jörg: Hallo und herzlich willkommen zu dieser Folge von CTO Need to Know. Mein Name ist Jörg Müller und in diesem Podcast sprechen wir regelmäßig über Herausforderungen und Erfahrungen rund um das Thema Organisation in der IT. Heute dreht es sich besonders um ein Thema, welches die Entwicklung und die Organisation von internen Plattformteams betrifft, was ich sehr spannend finde. Mein Gast dazu heute ist Christoph Steinlehner. Möchtest du dich kurz vorstellen?

Christoph: Ja, klar, super gerne. Erstmal vielen Dank, dass ich hier sein kann, Jörg. Mein Name, wie du gesagt hast, ist Christoph Steinlehner. Ich arbeite als Product Coach und Consultant, das heißt, ich helfe Produktmanagern und Produktleadern, bessere Entscheidungen zu treffen. Ich kam zu dem Thema, weil ich einen Hintergrund in Webdesign, dann Design und dann Product hatte, immer mit viel Technologieaspekt. Ich habe in ganz unterschiedlichen Unternehmen gearbeitet und dabei sehr oft mit Teams, die nicht Customer Facing sind, also von Infrastrukturteams bis hin zu Teams, die internes Tooling gemacht haben, gerade in großen, komplexen Unternehmen.

Jörg: Ich finde das total spannend. Wir hatten uns ja vorher schon ein bisschen darüber unterhalten und tatsächlich habe ich auch mal vor ungefähr 15 Jahren ein Team geleitet, das Plattformthemen gemacht hat. Damals hieß das, glaube ich, noch nicht ganz so. Wir nannten das damals Standard Tools and Processes. Insofern finde ich das eine sehr interessante andere Perspektive auf das Thema, mit dir darüber zu reden. Gab es denn ein paar besondere Erfahrungen, die du gemacht hast, wo du gesagt hast, das läuft mir immer wieder über den Weg, deswegen muss ich mich unbedingt mal mit diesem Thema beschäftigen?

Christoph: Ich weiß gar nicht, das war gar nicht jetzt so eine bewusste Entscheidung, ich muss mich jetzt mit dem Thema beschäftigen. Als ich noch in aktiven Rollen war, habe ich zum Beispiel bei Taxfix, aber auch bei Heartbeat im Medizinbereich, wirklich internes Tooling für interne Nutzer als Produktmanager betreut. Da kam das Thema auf und dann bin ich auch immer wieder in Infrastrukturthemen reingekommen. Gerade als ich in der Beratung war, ich war jetzt drei Jahre in den USA, ich bin seit letztem Sommer erst wieder zurück in Deutschland, und habe da sehr viel mit großen Banken gearbeitet. Ich glaube, das kennen wahrscheinlich auch viele Zuhörer: Wenn man in so einem großen Unternehmen ist und in die IT-Landschaft guckt, dann gibt es sehr viele Teams, die entweder andere Teams als Konsumenten ihrer Produkte oder ihrer IT-Capabilities haben, oder auch andere Kollegen von Regulatorik über HR und so weiter. Der Großteil der IT guckt oft nach intern und daher kam ich mehr oder weniger ein bisschen wie die Jungfrau zum Kind zu dem Thema.

Jörg: Vielleicht lass uns mal für die Zuhörer kurz damit anfangen zu sagen, was ist denn eigentlich so ein Plattformteam? Wo kommt der Begriff her? Was macht so ein Plattformteam?

Christoph: Ja, total gerne. Ich benutze den Plattformbegriff relativ holistisch und orientiere mich dabei an Team Topologies, was bestimmt viele kennen von Matthew Skelton und Manuel Pais. Es geht im Prinzip um alle Technologieteams, die nicht am Endkonsumenten sind und mehrere interne Teams mit eigener Technologie unterstützen.

Jörg: Ich habe zwar jetzt selbst schon gesagt, dass ich das gemacht habe, aber ich stelle die Frage trotzdem: Was sind denn so typische Produkte von so einem Plattformteam?

Christoph: Das ist sehr interessant, weil es ziemlich breit gefächert sein kann. Teilweise ist es eine API, sozusagen das Interface. Wenn ich über die Produkte spreche, gehen wir mal auf das Interface, sozusagen, was ist die Schnittstelle, wie wird es benutzt? Das kann eine API sein, das kann ein SDK sein. Das kann aber auch eine grafische Oberfläche sein. Alles, was sowohl Tooling ist, als auch irgendwelche technischen Fähigkeiten, die ein Team auf Systemebene betreut. Aber natürlich spreche ich von Produkten nicht, wenn man nur sagt, ja, das ist das Datenbankteam oder so, sondern es geht wirklich darum, einen speziellen Workflow zu ermöglichen, eine spezielle Fähigkeit dem Unternehmen intern bereitzustellen.

Jörg: Wir waren damals ein Team von drei Personen. Ist das eine typische Größe oder was kennst du da so für übliche Größen von Plattformteams?

Christoph: Es ist relativ breit, würde ich sagen. In der Tat sehe ich auch öfters kleine Teams, besonders in den Anfangsphasen, die oft aus anderen Teams herausbrechen. Man hat ein größeres Team und die fangen so undercover etwas an und dann bricht man das heraus. Aber die Teams können auch mal zehn Leute sein, können auch mal 15 Leute werden, aber 15 Leute ist schon wirklich die Obergrenze, würde ich sagen.

Jörg: Ja, wäre auch ein bisschen größer als so das typische Scrum Team. Das wären wahrscheinlich dann schon mehrere Teams möglicherweise. Von wem bekommt so ein Team seine Aufträge?

Christoph: Jetzt gehen wir gleich ins Eingemachte. Die Aufträge, das kommt sehr darauf an. Typischerweise würde ich sagen, oder idealerweise, fangen wir mal mit dem Ideal an. Idealerweise sucht sich so ein Plattformteam selbst die Aufträge. Also wirklich versteht selbst, welchen strategischen Impact es bringen kann und entwickelt demnach. Es ist dann natürlich in die IT-Strategie eingebaut, ist irgendwie in die Produktstrategie eingebaut und so. Üblicherweise, wie man es meistens sieht, gibt es bestimmte Teams, die Konsumenten sind, die natürlich Anforderungen formulieren, Wünsche formulieren beziehungsweise auch einfach Bedürfnisse haben. Und dann gibt es natürlich oft Regulatorik intern, Legal intern, IT-Architektur und so weiter. Jeder, der irgendwie da herumschwirrt, ist oft ein Stakeholder. Das ist auch, glaube ich, oft die Herausforderung für so Plattformteams, dass sie ein sehr kompliziertes Stakeholder-Gemengelage oft um sich sehen.

Jörg: Ja, da kann ich mich noch gut reinversetzen. Ganz viele Leute, die etwas von einem wollen auf der einen Seite und auf der anderen Seite die Herausforderung, dass man als Plattformteam gerne als Kostenfaktor gesehen wird. Das heißt, Mehrwert, weiß ich nicht, ob man da Mehrwert schafft oder wie lässt sich jetzt eigentlich Mehrwert messen? Das ist also, ich kenne die Diskussion sehr stark. Mit deinen Erfahrungen, gibt es Möglichkeiten, mich als Plattformteam zu begründen, würde ich jetzt fast sagen, also zu sagen, hey, das ist der Mehrwert, den ich schaffe?

Christoph: Ja, auf jeden Fall. Ich glaube, das ist total wichtig, das gut zu formulieren, weil wie du sagst, oft ist es das Cost Center. Das ist halt so ein bisschen so, sind halt Operational Costs oder sonst was und man muss das halt machen. Kennen wir alles von Cloud Movement, ja, man muss halt jetzt in die Cloud und dann gibt es eine vage Vorstellung, dass man jetzt total viel Geld spart, merkt danach, dass man gar nicht so viel Geld gespart hat, aber vielleicht ganz viele neue Dinge kann. Und genau da setze ich halt auch vom Produktmanagement an, zu sagen, okay, was ermögliche ich denn überhaupt? Was möchte ich denn überhaupt in meinem Unternehmen ermöglichen? Und gerade bei Plattformen geht es dann oft um Skalierungseffekte. Kann ich etwas einem anderen Team, was jetzt zum Beispiel drei Teams das Gleiche machen, kann ich das bündeln und in eine Plattform bringen? Und kann ich spezifische Aktionen von Leuten, also wirklich, was macht jemand mit der Plattform? Er kann schneller deployen. Was bringt uns das dann wirklich, wenn man das durchdekliniert bis zum Bilanzlevel eigentlich? Was ich mache, ist wirklich mit KPIs zu formulieren, wie man von, okay, wir ermöglichen jetzt fünf Teams, das und das schneller zu machen oder das und das nicht mehr zu machen. Dafür können sie andere Sachen machen und was bedeutet das denn? Um eben rauszukommen aus dem so, ja, wahrscheinlich sparen wir Geld oder vielleicht gewinnen wir auch mehr, aber das ist ja oft sehr nebulös formuliert. Und daher, glaube ich, kommt es auch oft dann mit dem Kostenfaktor, weil jemand aus dem Business, der Controller, guckt darauf und ist so, ja, das Team kostet uns hier eine Million im Jahr. Ist halt so, weil die IT hat gesagt, das brauchen wir.

Jörg: Mhm.

Christoph: Und dann natürlich nächstes Jahr werden 5 % gespart werden, dann ist halt das erste so, ja, das kostet ja nur, dass man da 5 % wegspart.

Jörg: Mhm, mhm. Jetzt ist ja deine Besonderheit, du hast eine Menge Erfahrungen damit, Endkundenprodukte zu designen, zu definieren. Ich weiß gar nicht, wie man das jetzt am besten bezeichnet. Und es ist ja naheliegend zu denken, gut, die Erfahrung, die man dort hat bei einem Endkundenprodukt, die kann man ja eigentlich auch für interne Produkte anwenden. Aber wie funktioniert das? Also, was wären das für Erfahrungen, die man da anwenden kann?

Christoph: Ich finde das Wichtigste ist erstmal, besonders, also ich komme aus dem B2B Umfeld auch hauptsächlich. Ich habe jetzt kein Ad-based Massenkonsumentenprodukt jemals in meiner Karriere gemacht. Und da gibt es einfach sehr viele Parallelen, weil einerseits hat man einen Konsumenten, einen Nutzer, also wirklich jemanden, der jetzt bei einer Plattform übertragen, jemand, der das einbaut, jeden Tag benutzt, die API nutzt, die API ins Produkt bringt. Das sind aber oft ja nicht die Leute, die dann andere Interessen an das Produkt haben. Und das zu unterscheiden, also wirklich zwischen unterschiedlichen Stakeholdern zu unterscheiden und ich halt so zwischen den Konsumenten, wer benutzt. Da will ich gucken, wie kann ich denen helfen, wie kann ich deren Leben erleichtern, deren Arbeitsleben erleichtern. Und gleichzeitig aber auch gucken natürlich, kann ich zum Beispiel Compliance über ein großes Spektrum bringen? Kann ich sicherstellen, dass etwas legal ist? Anstatt, dass jedes Team das machen zu lassen und jedem Team zu sagen, ja, ihr seid halt dafür verantwortlich, dass wir jetzt hier die DSGVO überall einhalten und so. Kann ich das wirklich in eine Plattform packen? Und das ist die Denke, die würde ich sagen, aus Produkt kommt. Also wirklich in Risiken denken, wirklich auch zu unterscheiden zwischen was ist das Konsumententeil und was ist auch der unternehmerische Teil? Also wirklich, um wieder zurückzugehen mit so, ist es nur ein Kostenfaktor? Nee, wir wollen ja einen Return of Investment irgendwo haben, den wirklich zu formulieren und das auch sowohl in ganz einfacher monetären Argumenten zu verpacken, aber gleichzeitig auch halt legale, ethische und regulatorische Werte einfach mit zu berücksichtigen.

Jörg: Ich glaube, das Buch hatte ich sogar von dir empfohlen bekommen. Output Outcomes, ne?

Christoph: Outcomes over Output.

Jörg: Genau, andersrum. Ja, siehst du, so schlecht habe ich es gelesen. Nein. Da wären ja eine Menge Dinge, ich sag mal auch von aus einer Endkundensicht betrachtet, also was die Customer Journey etc. Sind das denn Techniken, die ich bei einem Plattformteam auch einsetzen könnte? Finde ich ja einen spannenden Gedanken.

Christoph: Definitiv. Was ich zum Beispiel super viel gemacht habe, ist mir anzugucken, wie andere Leute arbeiten, die eine Plattform oder ein Tool benutzen. Ich habe beispielsweise Survey Tools gebaut für Leute, die intern Surveys bauen, die dann ins Produkt einfließen. Da habe ich geguckt, wo überhaupt der Engpass bei denen ist. Ist das der Engpass im Survey Tool? Wir kamen dann darauf, dass es einen ganz anderen Engpass gibt, dass die sozusagen abgelenkt sind von ihrer eigenen Arbeit, weil sie noch 10.000 andere Sachen machen, die sich locker automatisieren ließen. Das war dann die Plattform. Wir haben gar nicht direkt an deren Workflow super stark gearbeitet, sondern haben einfach geguckt, wo die Engpässe sind, wo wir helfen können, sie viel effizienter arbeiten zu lassen und ihnen das Leben leichter zu machen. Daher gehe ich sehr viel in die Product Discovery, also wirklich zu verstehen, was die Konsumenten machen, dann auch zu verstehen, was die anderen Stakeholder machen, was die überhaupt für Bedürfnisse haben und das auch auseinander zu definieren. Statt zu sagen, na ja, schreibt mal eure Ideen ins Backlog und dann gucken wir mal, wann wir dazu kommen. Das ist ja ein bisschen der andere Weg, der Request Taker Weg, der irgendwie, wir sind halt hier interner Dienstleister und warten, bis uns irgendwer was sagt, sondern wirklich auch in dieses Proaktive zu kommen, zu verstehen, was meine Plattform ermöglicht und was der beste Weg ist, das umzusetzen.

Jörg: Also ein bisschen das, was man dann auch als Developer Experience heutzutage bezeichnet.

Christoph: Genau. Ja. Developer Experience ist auf jeden Fall Teil davon. Auch da, wir kennen ja die Metriken wie Dora und Space und so weiter, auf die auch zu gucken und zu gucken, wie man die aktiv beeinflusst zum Beispiel. Und praktisch Developer wirklich zu gucken, auch deren Arbeitsprozesse holistisch eben zu gucken, weil Developer Experience heißt ja nicht nur, ich habe jetzt eine API, die irgendwie besser funktioniert, sondern heißt ja auch, okay, da ist auch eine vernünftige Dokumentation dazu und man findet das Ding und es ist irgendwie vernünftig, weiß ich nicht, versioniert oder wird auch vernünftig ausgerollt und hat sogar internes Marketing vielleicht bei einer entsprechenden Größe und so weiter und so fort. Also es ist ja nicht nur, dass da jetzt besser jemand das nutzen kann, sondern es ist ja wirklich viel drumherum.

Jörg: Mhm, mhm. Ja, ist ein interessanter Aspekt, wenn du das gerade sagst, das ist vielleicht auch ein Grund, warum oftmals so externe Software-as-a-Service-Tools dann viel schneller eingesetzt werden, weil die sich eben auf solche Dinge konzentrieren, während interne Developer Tools, erlebe ich oft, als etwas stiefmütterlich behandelt, genau wegen diesem Kostenfaktor. Der ja, das ist ja da, du kannst es ja benutzen und wenn du wissen willst, wie man es benutzt, dann frag mich doch einfach. Aber das ist natürlich nicht die Experience, die ich bei einem externen Anbieter erwarten würde. Und das ist okay, ist spannend. Also das ist so ein bisschen der Maßstab, den ich dann auch an mich als Plattformteam ransetze. Interessant. Ein anderer interessanter Aspekt dabei, den ich aber empfinde oder das ist ein Konflikt, den ich gerne erlebt habe, ist, wie viel darf denn so ein Plattformteam auch, ich sag mal, den Stream Aligned Teams, wenn wir jetzt bei Team Topologies bleiben, vorschreiben? Also diese Frage von Alignment und Autonomie. Denn als Plattformteam, wenn ich sage, okay, ich biete dir jetzt eine Postgres-Datenbank an, dann setze ich damit ja einen Weg, quasi eine Regel, denn es gibt von mir eben keine MongoDB und wenn jetzt aber das Stream Aligned Team sagt, ich hätte gerne MongoDB eingesetzt, dann stehen sie im Regen. Ist das denn, also wie stehst du zu diesem Thema? Also ist das etwas, was Plattformteams beachten sollen, dass sie selbst auch Standards ausstrahlen oder sollten sie das gar nicht tun?

Christoph: Doch, ich denke schon. Ich verstehe das so, dass einerseits im Idealfall, und das ist wirklich jetzt auch ein bisschen idealisiert, Plattformen frei zu benutzen sein sollen. Also, dass ein Team, wenn es sagt, nee, wir wollen jetzt unsere eigene Datenbank, so ein bisschen so, why not? Und dann geht es aber genau um dieses why not, weil was oft dann nicht berücksichtigt wird, ist, dass dann das Team, das jetzt seine eigene Datenbank benutzt, das halt auch maintainen muss und gucken muss, dass es sicher ist und sonst was.

Jörg: Mhm.

Christoph: Und das ist ja genau der Vorteil einer Plattform, dass ich jetzt eine Plattform habe, die sagt, okay, wir haben hier skalierbare Datenspeicherung, du musst dich überhaupt nicht mehr um eine Datenbank kümmern und wir garantieren dir auch, dass es sicher ist und wir garantieren dir auch, dass du nicht auf den Deckel bekommst, wenn du einen Fehler machst, das ist unsere Verantwortung. Und das auch wirklich als Plattform dem Unternehmen anzubieten. Und dadurch natürlich auch Standards zu setzen. Das Ziel ist ja, eine Plattform zu entwickeln, die einen Vorteil bietet. Und natürlich geht es nicht immer. Wenn wir jetzt über Identity Management sprechen, was so eine klassische Plattform ist, natürlich kann nicht jedes Team ein eigenes Identity Management anbieten. Da gibt es natürlich Trade-offs und man zwingt natürlich auch bestimmte Teams, aber da kommt auch wieder das kunden- und konsumentenzentrierte Denken rein, wo ich sage, na ja, wenn ich eine Plattform anbiete, die wirklich meine Teams etwas erleichtert, warum sollen sie es denn nicht benutzen? Solange ich Teams habe, die um mich herum stehen und sagen, na ja, es macht keinen Spaß mit euch zu arbeiten und ihr seid irgendwie zu langsam und es funktioniert nicht, ist es schwer. Gleichzeitig muss aber natürlich auch eine Plattform eine Offenheit haben, um darauf zu bauen. Das ist ein Muster, was ich super spannend finde, was ich in wirklich guten Plattformteams sehe, ist, die stehlen. Die laufen herum, sehen, was andere Teams praktisch auf ihrer Plattform aufsetzen. Nehmen wir Identity Management, die haben Identity Management und dann kommt ein Team und sagt, ja, wir brauchen irgendwie die fünf zusätzlichen Faktoren an einer Identität und die bauen das dann selber dran. Und dann kommt das nächste Team und hat auch sowas.

Jörg: Mhm.

Christoph: Und dann kommt der Zeitpunkt, wo die Plattform sagt, okay, was können wir hier vereinheitlichen, was können wir euch anbieten? Also gar nicht in diese Lage zu kommen mit so, ah, okay, jetzt kommt der nächste und braucht jetzt noch das Feld und das Feld und das Feld, sondern zu gucken, was wird denn schon genutzt und was können wir klauen und in die Plattform integrieren?

Jörg: Ah ja, das kennen wir durchaus von größeren Produktanbietern. Ich glaube, Apple macht sowas auch gerne, zu beobachten, welche Produkte gut funktionieren auf ihrer Plattform und sie dann einfach selbst ins Betriebssystem zu integrieren. Also quasi mit genau diesem selben Mindset ranzugehen, ja, spannend.

Christoph: Genau, das ist die komplette AWS Strategie.

Jörg: Mhm, mhm.

Christoph: Gucken, was auf AWS gebaut wird und das dann als Produkt wieder auszurollen.

Jörg: Okay, das heißt also letztendlich bei Alignment und Autonomie eher zu sagen, wir bieten ein gutes Produkt und deswegen möchtest du das nutzen, ja? Also wirklich, als wäre man quasi auf einem freien Markt, wo sich die andere Seite stets entscheiden könnte, einfach einen anderen Anbieter zu nehmen. Versuchen, genau mit dem gleichen Mindset ranzugehen.

Christoph: Genau, und gleichzeitig steht natürlich bei vielen Plattformen auch zur Debatte, ob nicht eine Third-Party-Lösung auch eine Option ist. Ich habe gerade vorher Identity Management angesprochen. Für die wenigsten macht es Sinn, from scratch ein Identity Management zu bauen. Die nehmen etwas, bauen selber etwas darauf, dann bauen Streamline Teams etwas darauf, also wirklich die Wertschöpfungskette zu verstehen, was man eigentlich sinnvoll anbietet und was man auch wirklich integriert.

Jörg: Mhm, mhm. Ja, spannend. Ich stelle die Frage mal andersrum, was sollte so ein Plattformteam nicht tun?

Christoph: Viele Dinge bestimmt.

Jörg: Ja, weil es klang jetzt gerade so, boah, ganz viel, was wir da anbieten, aber was wollen wir denn nicht machen? Was wollen wir nicht sehen?

Christoph: Genau, was wir nicht sehen wollen, glaube ich, ist totale Insellösungen, die nur ein Team betreffen. Besonders dieses beliebte Muster, dass wir ein Streamline Team haben, das aber den ganzen Datenbankkram und so weiter nicht anfassen will. Also laufen sie zum Plattformteam und sagen, macht ihr das mal, das ist euer Job. Das wollen wir eigentlich nicht. Ein Plattformteam ist ja wirklich ein Skalierungsteam, also eine Methode, um zu vereinheitlichen und zu skalieren und nicht Speziallösungen zu bauen. Und was wir auch nicht sehen wollen, ist der Elfenbeinturm, den es immer noch manchmal gibt, wo die ganz schlauen Architekten sitzen, die den Plan gemacht haben, wie 2030 unsere Architektur aussieht und die bauen das so im stillen Kämmerchen vor sich hin. Das ist finde ich auch so ein Anti-Pattern, was es immer mal wieder gibt. Und das, ja, finde ich auch, funktioniert einfach nicht. Ich habe es einfach nie funktionieren sehen.

Jörg: Ja, das sind schon mal gute Hinweise. Ja, dann warte mal, ich gucke mal auf die Uhr, wir haben Februar oder Ende Februar 2026. Und das bedeutet, wir können eigentlich so einen Podcast nicht halten, ohne über das Thema KI zu sprechen und was das für Auswirkungen hat, auch auf Plattformteams. Ist sehr spannend, ne? Es wird gerade sehr, sehr viel, es ändert sich gerade viel in der Softwareentwicklung etc. durch die Dinge, die man da macht, aber was hat das für Auswirkungen auf Plattformteams? Muss ich mich darauf einstellen, was muss ich da tun?

Christoph: Ja, ich glaube auf jeden Fall in vielerlei Aspekten. Ich glaube von beiden Seiten, wir sehen ja sozusagen auf jeden Fall Streamline Teams, die viel, viel schneller werden und wahrscheinlich, solange ich im Modus bin, wo ich sage, okay, ich kriege Anforderungen von denen und die schreiben mir ein schönes Ticket im Backlog und so weiter, werde ich bestimmt nicht mehr nachkommen. Insbesondere, wenn dann die KI etwas ins Backlog schreibt, was dann vielleicht eine KI abarbeiten soll, kommen wir wahrscheinlich in Probleme. Besonders auch, nachdem natürlich diese Geschwindigkeit, mit der wir bauen können, immer mehr dazu führt oder immer mehr aufzeigt, dass wir den Engpass woanders hin verschoben haben.

Jörg: Mhm, mhm. Also, das klang so, als wolltest du was sagen. Na gut, dann stelle ich noch mal eine Frage rein oder packe eine, also ich erlebe gerade bei den Kunden häufiger, dass die ersten, die mit uns darüber reden, wie KI-orientierte Entwicklung funktioniert, also Agentic Software Engineering, was man aktuell dazu sagt, dass oft die ersten, die da zu uns kommen und fragen, wie können wir das machen, wie können wir das einführen, die Plattformteams sind. Das ist jetzt erstmal eine völlig neutrale Beobachtung. Kennst du das auch, was ist davon zu halten?

Christoph: Ja, ich kann mir gut vorstellen, dass der Anspruch an eine Plattform sehr schnell ist, nach dem Motto: „Oh, wir haben AI, wir brauchen viele Guardrails. Wir haben auf jeden Fall eine Regulatorik und ein Privacy-Thema und so weiter und so fort.“ Eine Plattform soll es ermöglichen, und ich glaube, das ist auch ein total spannender Weg. Das ist natürlich ein bisschen ein „slippery slope“, weil man eventuell versucht, Standards zu setzen, bevor man weiß, was man überhaupt braucht und was überhaupt funktioniert. Aber es ist auf jeden Fall ein Thema. Ich glaube, vor allem auch, dass wir eine neue Entwicklung sehen werden in Richtung „Vibe Coding“, kleines Tooling von überall her.

Jörg: Mhm.

Christoph: So Stichwort „Shadow IT“ ein bisschen.

Jörg: Mhm, mhm.

Christoph: Und da finde ich ganz spannend, wie die Plattformen dafür aussehen. Also, was kann ich den Mitarbeitern als Plattform geben, um darauf zu entwickeln? Wir sehen es teilweise, glaube ich, schon mit NNN-Installationen und solchen Sachen, dass Plattformen das intern zur Verfügung stellen. Aber das ist, glaube ich, noch sehr offen und ja, ist auf jeden Fall spannend. Ich frage mich gerade, ob du auf einen anderen Punkt hinauswolltest.

Jörg: Nee, nee, nee, das ähm, ich finde es, ich wollte einfach erstmal nur diese Beobachtung wiedergeben, die mir tatsächlich über den Weg läuft, dass Plattformteams die ersten sind, die scheinbar den Auftrag bekommen, nach dem Motto: „Wir möchten jetzt das ganze Thema KI-Entwicklung enablen.“ Deswegen ist das Plattformteam jetzt das erste, was diesen Auftrag bekommt. Das Schatten-IT-Thema ist natürlich ein spannendes. Ich habe gerade deswegen so ein bisschen geguckt, ich gehe das eben jedes Mal, wenn jemand „Vibe Coding“ sagt, dann sterbe ich innerlich ein bisschen. Aber das ist halt eigentlich genau das, was man, glaube ich, nicht machen sollte, aber es ist natürlich ein spannender Aspekt, den du ansprichst: Plattformteams, die andere Kunden zusätzlich bekommen, die einen anderen Hintergrund haben und trotzdem die Dienstleistung der Plattform benutzen. Ja.

Christoph: Zum Thema „Vibe Coding“ vielleicht noch: Einerseits, glaube ich, kann man es nicht verhindern. Es ist schon immer so, dass Leute Zeug benutzen, was halt so rumliegt. Siehe die kompliziertesten Excel-Skripte und keine Ahnung, was für zusammengebaute Workflows. Und ich denke, lieber die Leute, die da auch wirklich gute Sachen bauen, zu enablen und dann wieder vielleicht von denen zu klauen, wieder da Sachen zu vereinheitlichen, als Pattern zu nutzen, anstatt zu sagen: „Okay, ihr dürft nicht und ihr könnt nicht“, weil sie machen es ja dann doch, selbst wenn sie es auf dem Handy machen.

Jörg: Ja, okay, das stimmt. Ja, wir kommen tatsächlich jetzt schon wieder fast an den Punkt, wo ich sage: „Hey, wir haben unsere 30 Minuten schon erreicht.“ Spannende Diskussion. Ich nehme auf jeden Fall schon mal ein Stichwort von dir mit, nämlich einfach mal mehr klauen. Das fand ich auf jeden Fall schon eine sehr spannende Schlussfolgerung, also dieses Beobachten, was meine Kunden machen und dann stehlen und umsetzen. Finde ich spannend, habe ich bisher nur extern erlebt. Was sind denn noch Dinge, die man schlussfolgern könnte oder die man schlussfolgern sollte, wenn man so ein Produkt oder anders ein Plattformteam aus einer Produktsicht betrachtet?

Christoph: Ja, also ich glaube, es ist einfach total wichtig, dass man auch den Konsumenten definiert, auch die Stakeholder klar definiert und auch wirklich auf diese Business-Sprache kommt. Also wirklich aus dieser „Wir sind nur ein Cost Center“-Rolle rauskommt und wirklich formuliert, was man in Sprache, die auch Nicht-IT-Leute verstehen, formuliert, was man eigentlich für einen Mehrwert stiftet.

Jörg: Mhm.

Christoph: Und gleichzeitig auch wirklich, wenn wir gucken, dass durch AI, wie ich schon gesagt habe, das Bottleneck verschoben wird von Code schreiben hin zu Entscheidungen treffen, hin zu Erkennen, Orchestrieren und so weiter, wir kommen immer weiter in den Modus, dass ich sage: „Okay, ich kann ganz schnell Sachen bauen, aber in welche Richtung laufe ich eigentlich damit?“

Jörg: Mhm, mhm.

Christoph: Das wird, glaube ich, eine große Herausforderung und ich bin fest davon überzeugt, dass Produktdenken und nicht nur bei Produktmanagern, sondern bei Entwicklern, bei Designern und auch allen anderen Teammitgliedern sehr, sehr wertvoll ist, um mit diesen Herausforderungen umzugehen.

Jörg: Okay, also mehr von Produktmanagern, Product Ownern lernen.

Christoph: Genau, klauen.

Jörg: Klauen, mehr klauen.

Christoph: Mehr von Produktmanagern klauen.

Jörg: Sehr gut, wunderbar. Hat mir sehr viel Spaß gemacht, vielen Dank für das Gespräch und ich hoffe natürlich, liebe Zuhörer, ihr habt auch das ein oder andere mitnehmen können und ja, schreibt uns gerne, die Kontaktdaten werden wir in den Shownotes haben. Vielen Dank.

Christoph: Vielen Dank, dass ich dabei sein durfte.

Diese Zusammenfassung wurde automatisiert erstellt und nicht manuell überprüft. Es kann daher Fehler enthalten. Maßgeblich ist immer das im Mitschnitt gesprochene Wort.

Was ist ein Plattformteam und warum lohnt sich Produktdenken?

Plattformteams sind interne Technologieteams, die andere Teams im Unternehmen unterstützen, etwa durch APIs, Tools oder Infrastruktur. Statt sie nur als technische Dienstleister zu sehen, plädiert Christoph Steinlehner dafür, Plattformen konsequent als Produkte zu denken: mit klar definierten Nutzer:innen, Mehrwertversprechen und strategischem Zielbild.

Vom Cost Center zum Business Impact

Ein zentrales Problem vieler Plattformteams: Sie werden als Kostenfaktor wahrgenommen. Der Schlüssel liegt darin, ihren Beitrag messbar zu machen. Plattformen schaffen vor allem Skalierungseffekte – sie ermöglichen es mehreren Teams, schneller und effizienter zu arbeiten. Diese Effekte müssen in konkrete KPIs und Business-Nutzen übersetzt werden, statt vage Einsparversprechen zu formulieren.

Interne Nutzer verstehen: Product Discovery für Plattformen

Auch interne Plattformen brauchen Product Discovery. Statt Anforderungen einfach entgegenzunehmen („Request Taker“), sollten Plattformteams aktiv beobachten, wie ihre Nutzer:innen arbeiten, wo Engpässe liegen und wie sich Prozesse verbessern lassen. Oft liegt der größte Hebel nicht im Tool selbst, sondern im Arbeitskontext der Nutzer:innen.

Developer Experience als Wettbewerbsvorteil

Gute Plattformen orientieren sich an der Experience externer SaaS-Produkte. Dazu gehören nicht nur funktionierende APIs, sondern auch Dokumentation, Auffindbarkeit, Versionierung und interne Kommunikation. Plattformteams stehen dabei im Wettbewerb, wenn interne Lösungen nicht überzeugen, greifen Teams schnell zu externen Tools.

Standards setzen, aber attraktiv gestalten

Plattformteams bewegen sich im Spannungsfeld zwischen Autonomie und Alignment. Sie setzen Standards, etwa bei Datenbanken oder Identity Management, sollten diese aber so gestalten, dass Teams sie freiwillig nutzen wollen. Der beste Weg dahin: echten Mehrwert liefern, statt Vorgaben durchzudrücken.

Erfolgsprinzip: „Stehlen statt erfinden“

Ein starkes Muster erfolgreicher Plattformteams ist das gezielte „Stehlen“: Sie beobachten, welche Lösungen andere Teams auf ihrer Plattform bauen, und integrieren bewährte Ansätze in das zentrale Angebot. So entstehen standardisierte, wiederverwendbare Lösungen, ohne an den Bedürfnissen vorbei zu entwickeln.

Anti-Patterns: Insellösungen und Elfenbeinturm

Zwei typische Fehlentwicklungen: Plattformteams, die individuelle Speziallösungen für einzelne Teams bauen, und solche, die im Elfenbeinturm ohne echten Nutzerkontakt Architekturpläne entwickeln. Beides verhindert Skalierung und führt dazu, dass Plattformen ihren eigentlichen Zweck verfehlen.

KI verändert die Rolle von Plattformteams

Mit dem Einsatz von KI in der Softwareentwicklung verschieben sich Engpässe: Weg vom Coden hin zu Entscheidungen und Orchestrierung. Plattformteams stehen vor der Herausforderung, neue Guardrails zu definieren, ohne Innovation zu blockieren. Gleichzeitig entstehen neue Risiken wie Shadow IT durch „Vibe Coding“.

Fazit:

Plattformteams sind dann erfolgreich, wenn sie sich als Produktorganisation verstehen: mit klarem Fokus auf Nutzer:innen, messbarem Mehrwert und kontinuierlicher Weiterentwicklung. Gerade im Kontext von KI wird Produktdenken zur zentralen Fähigkeit, um Geschwindigkeit, Governance und Innovation in Balance zu halten.