Robert Stephenson, Produktmanager bei Spotify, über den Weg zu einer zielgerichteten Auswertung von Daten

Robert Stephenson von Spotify auf dem Digitale Leute Summit 2021.

Spotify ist ein Unternehmen, welches in den letzten Jahren stark expandiert ist. Gleichzeitig ist es ein Paradebeispiel für dezentrale, agile Entwicklung in den sogenannten Squads. So entstand das Problem, dass zwar die zur Verfügung stehenden Daten immer mehr explodierten, nicht aber die Erkenntnisse, die daraus gewonnen werden konnten. Aktuell gibt es auf Spotify 10 Millionen Tracking Events/Sekunde bei 380 Millionen aktiven Nutzern pro Monat. Als Senior Product Manager beschäftigt sich Robert Stephenson seit 2016 mit dieser Problematik. Auf dem Digitale Leute Summit 2021 beschreibt er den Weg und die Vision hin zu einer guten Datennutzung.

→ Hier findest du die komplette Aufzeichnung seines Talks

• In diesem Text lernt ihr
• Wie Spotify die Datenanalyse organisiert
• Welche Probleme damit mit dem Unternehmenswachstum entstanden
• Welche Rolle dabei Standardisierung spielt
• Wieso plattformgetriebene Probleme oft Tech-Probleme sind

Die Grundlagen des Plattformproduktmanagements

„Ein Plattformprodukt ist eine Lösung, welche ein Unternehmen oder Teile davon horizontal unterstützt“, so Robert Stephenson am Beginn seines Vortrags. „Es kommt hier häufig zu einer Entscheidung zwischen selbst entwickeln und einkaufen.“ Bei einer Inhouse-Entwicklung gibt es dann die Notwendigkeit eines Produktmanagers und eines Teams. „Sehr häufig sind hier die Fragestellungen sehr technisch“, so Robert. Er selbst ist eben für eine Plattform zuständig, die sich bei Spotify mit der Datensammlung beschäftigt. Daraus ergeben sich verschiedene Problemstellungen.

Spotifys Organisationsmodell

Mittlerweile sei Spotify ein sehr komplexes Produkt mit einem sehr komplexen Business Modell, „woraus sich eine große Breite an Daten ergeben“. Das hat sich geändert. Aber gleich geblieben ist bis heute die Art der Organisation: Spotify stellt mit seinem Squad-Modell ein weltweit beachtetes Organisationsmodell für agiles Arbeiten in größeren Unternehmenszusammenhänge dar.

Squads beruhen im Prinzip auf einer ähnlichen Organisationsphilosophie wie SCRUM-Teams oder andere agile Teams. Sie sind klein, selbstorganisiert – und agieren auch hochautonom. „Sie sind die ausführenden Einheiten bei Spotify“, so Robert. Squads bestehen aus einem Projektmanager, einem agilen Coach und zwischen fünf und sieben Entwicklern.

Spotify ergänzt dies um die Idee der Tribes, Chapters und Gildes, die versuchen, diese autonom agierenden Teams in die komplexeren Zielzusammenhänge des Unternehmens einzubinden, und horizontale Verbindungen zwischen den Teammitgliedern zu erzeugen. In zahlreichen Artikeln und wissenschaftlichen Abhandlungen wurde dieses Organisationsmodell von Spotify untersucht.

Die Problematik besteht nun darin, für die autonom arbeitenden Teams dennoch Standards zu entwickeln.

Datensammlung am Beginn bei Spotify

Am Anfang der Unternehmensgeschichte wollte man bei Spotify natürlich auch wissen, wie viele Nutzer auf der Plattform sind und wie engagiert sie waren. Dazu wurden sehr sorgfältig die Playback-Daten analysiert, um zu wissen, was sich die Nutzer angehört haben.

Schon damals spielte die Autonomie der Squads eine große Rolle, denn diese sollten eigenständig ihre Datenanalyseziele verwirklichen. „Und das ist auch gute Praxis in der Entwicklung, dass man Untersuchungskapazitäten in seine Features implementiert“, so Robert. Man will verstehen, wie die Nutzung aussieht und was man optimieren muss. „Diese Squads sollten eben Werte fürs Unternehmen schaffen, ohne sich mit der komplizierten Datenentwicklung oder der Datenverteilung auseinandersetzen zu müssen.“

In dieser frühen Phase verursachten die Nutzer einen Logevent am Access Point. Diese Daten wurden dann automatisiert abgerufen und automatisiert ausgewertet, um daraus dann Aussagen zum Beispiel über Aktivitäten der Nutzer zu generieren. „In dieser Phase war die Datenauswertung nicht eine Plattform, sondern mehr eine Lösung, die funktioniert.“ Denn der Job war es einfach, Daten von Punkt A nach B zu transportieren.

Erst mit dem weiteren Wachstum wurde die Datenauswertung zu einer Plattformlösung. „Denn wir waren völlig ahnungslos, welche Daten wir sammelten“, so Robert. „Zudem änderten sich die technischen Anforderungen.“ Nun musste mit dem starken Wachstum von Spotify umgegangen werden: 2016 erreichte Spotify die ersten 100 Millionen Nutzer. Das zweite technische Problem war, den Code in eine Cloud zu transferieren. „Wir hatten also das Ziel, das Wachstum zu bewältigen und den Code in die Cloud zu transferieren“, so Robert.

Probleme, die sich mit dem Unternehmenswachstum ergaben

„Aber wir hatten noch ein anderes Problem.“ Denn es konnten keine weiteren Maschinen mehr in den Serverraum gestellt werden, „wir hatten zu diesem Zeitpunkt ohnehin schon Europas größten Hadoop-Cluster“, so Robert. „So war klar, dass er irgendwann mit Daten überflutet sein würde.“ Und das nicht etwa in der fernen Zukunft, sondern innerhalb der nächsten 60 Tage. Intern wurde dieser Tag „Doomsday“ genannt.

Aber es gab nicht nur ein Problem mit der schieren Masse der Daten, sondern auch mit deren Qualität, „denn wichtige Einsichten erwuchsen daraus nicht“, so Robert. Um herauszufinden, woran das lag, führte Roberts Team Nutzerrecherchen durch. Bei Spotify gibt es zwei Nutzersegmente:

• Produzenten
• Konsumenten

Spotify als System verknüpft deren Bedürfnisse miteinander. „Autonome Squads bedienen diese unterschiedlichen Nutzersegmente“, so Robert. „In der Vergangenheit wurden diese beiden Segmente gemeinsam betrachtet, aber das hat sich geändert.“ Heute gibt es immer mehr Teams, die die Daten aus ganz unterschiedlichen Gründen nutzen.

„Also entschieden wir, nicht mehr nur der Transport Layer für Daten zu sein“, so Robert. „Sondern wir interessierten uns nun auch dafür, was die Menschen konkret an Daten senden.“

Und das Ergebnis war: Die Daten hatten eine sehr freie Form. „Das war für uns sehr überraschend, denn eigentlich haben wir ganz klar definierte Events.“ Man habe nie eine Plattform ohne Schema betrieben. „Aber dennoch konnten die Entwickler mit JSON völlig eigenständige Dateninterpretationen starten.“ Man fokussierte sich dann auf zwei wichtige und sehr zentrale Events:

• UI Impression: Die wird zum Beispiel erzeugt, wenn ein Albumcover angeklickt wird.
• UI Interaction: Wenn mit dem Album interagiert wird, wird eine Interaction ausgelöst.

„Das hört sich in der Theorie gut an“, so Robert. Aber es gibt einen hohen Freiheitsgrad, wie Teams diese Events nutzen können. Robert nennt dafür Beispiele: Ein Event wird ausgelöst, weil jemand auf etwas geklickt hat. Aber das kann dann in der Interpretation zum Beispiel ein „Hit“, „Click“ oder „Touch“ sein. Sprich: Diese hohe Freiheit führt zu einer großen Granularität/Kleinteiligkeit der Daten. So kann man bei Spotify zum Beispiel auch Dinge „liken“. Manchmal sei dies ein Herz gewesen, manchmal aber auch die Aufnahme in eine Kollektion.

„Das brachte uns zu unserem guten Freund ‚Autonomie‘ zurück“, so Robert. „Das soll nicht heißen, dass Autonomie für uns nicht funktioniert. Es funktioniert nämlich wirklich gut, wenn es darum geht, zusätzliche Unternehmenswerte zu schaffen.“ Das Problem sei aber, dass eine Fragestellungen rund um die Daten oft nicht eindeutig zu beantworten ist, denn die Antwort hängt davon ab, welches Squad darin involviert ist. „Die Konsequenz ist eine massive Fragmentierung der verwendeten Technologie“, so Robert.

Die Aufgabe der Plattform sei es deshalb, Standardisierungen voranzubringen. Die Folge von immer stärkerer Standardisierung sei aber eine Reduzierung der Freiheit. Deshalb muss man auch die Pros und Contras abwägen. Die Pros und Contras einer starken Autonomie:

• Es gibt keine Möglichkeit der Weiterverwendung, man kann nicht von den Lösungen anderer Teams profitieren,
• aber man kann sehr stark spezialisierte Lösungen finden, die sehr gut zum Use Case passen.
• Man hat keine Abhängigkeiten und kann deshalb schneller entwickeln.

Auch für eine starke Standardisierung gibt es Vor- und Nachteile:

• Man hat keine Fragmentierung,
• aber man schafft einen Flaschenhals, weil das verantwortliche Team schnell überfordert ist.
• Außerdem werden einige Use Cases aus dem Standard ausgeschlossen.

Es sei deshalb sehr schwierig, herauszufinden, wann der Zeitpunkt für eine Standardisierung gekommen sei, so Robert. „Aber in unserem Fall hatten wir eine wirtschaftliche Anforderung.“ Denn es sei nahezu unmöglich gewesen, die den UI Impression oder UI Interaction zugrundeliegenden Bedürfnisse zu verstehen.

Robert rät dazu, dass ein echte Unternehmensanforderung die Grundlage für eine Standardisierung sein sollte, denn diese ist sehr teuer. Das Entwickler genervt seien, sei nicht die notwendige Grundlage. „Der Aufwand ist es nicht wert, wenn nicht ein echtes Businessproblem besteht“, so Robert.

Die Schritte zur Standardisierung

Aus seiner Erfahrung führt Robert aus, was die notwendigen Schritte sind, um die Standardisierung voranzutreiben:

• Du musst die Autorität erhalten, das Problem wirklich zu lösen. Denn man dürfe nicht in die Situation kommen, dass die eigene Lösung nur eine weitere neben vielen weiterhin existierenden ist, „so dass anstelle der bisherigen 10 Lösungen nun 11 existieren“, so Robert. „Deshalb haben wir in unserem Fall ein neues Team gebildet.“
• Im nächsten Schritt muss nun eine Meinung über die konkrete Umsetzung gebildet werden. „Es gibt hier keine klar falsche oder richtige Entscheidung“, warnt Robert. „Denn wenn das so wäre, wäre es zu keiner Fragmentierung gekommen.“ Wenn allerdings der Problemraum technisch sei, dann sollten auch die Lösungen dafür technische Best-Practises sein. „Lade genau deshalb zur Diskussion ein und ermutige zu viel Konversation zwischen den verschiedenen technischen und inhaltlichen Experten“, so Robert. Im Falle der Datenanalyse beinhaltet das Diskussionen über Schemen und Datenmodelle sowie über Identifier, die dafür benötigt werden.
• Es gibt dann im nächsten Schritt viele Möglichkeiten, die Ideen in die Plattform zu integrieren, so Robert. Bei Spotify hat man sich für ein Framework entschieden, welches das Datenmodell abbildet.
• Als letzter Schritt findet eine Migration der bestehenden Codes zu den neuen Standards statt. „Was ich hier hervorheben will“, so Robert: „Das kann eine unglaublich, unglaublich kostspielige Operation werden.“ Bei Spotify mussten 100 Teams dorthin migrieren. „Wenn nämlich das Kosten-Nutzen-Verhältnis der Standardisierung analysiert wird, darf man nicht die Migrationskosten unterschätzen.“

Rückmeldungen zu den standardisierten Daten

„Tatsächlich empfanden später dann viele Nutzer die Standardisierung als fürchterlich“, blickt Robert zurück. „Wir haben nämlich einen Vorgeschmack darauf gegeben, was möglich ist, wenn man die Sessions versteht.“

Jetzt wollten die Teams mehr haben und waren mit ihrer bisherigen Lösung nicht mehr zufrieden. „Unser Team wurde dadurch leider zu einem Flaschenhals“, so Robert. Es war schwierig, die vielen Rückmeldungen zu verarbeiten und schnell Verbesserungen durchzuführen.

Als zweites Problem stellte sich heraus, dass andere Daten – die Playback-Daten – nun sehr viel wichtiger für das Unternehmen wurden und auch hier Innovation nur langsam vorangeht. Und als drittes Problem ergab sich, dass die Datenmasse weiter explodierte, aber die daraus zu gewinnenden Einsichten nicht im gleichen Maße anstiegen. „Wir haben die Spotify Sessiondaten verbessert“, so Robert, „aber das ist nur ein Bereich von Daten.“

Worin die generellen, strukturellen Probleme liegen

Eine Strategie zur Umsetzung einer besseren Datenstruktur beinhalte drei Dinge, sagt Robert. „Zunächst muss man den Kontext besser verstehen.“ Und daraus ergibt sich eine Diagnose der zugrundeliegenden Probleme. Als Zweites sollte es eine Auswahl an Leitprinzipien geben, um eine Entscheidung zu treffen. Daraus ergeben sich dann Aktionen, mit sowohl unmittelbaren als auch iterativen Auswirkungen. „Aber sie sollten auch in diesem Sinne strategisch sein, dass sie für zukünftige Probleme in dem Problemraum sensibilisieren“, so Robert.

Spezifisch für Plattformen sei, dass hier für technische Probleme auch Leitlinien erstellt werden, die technische Best-Practise-Lösungen bieten. „Denn die Produktstrategie ist hier Tech-Strategie“, so Robert. Er leitet daraus, basierend auf dem Buch „Data Mesh“ von Zhamak Dehghani, drei Grundprobleme ab, wenn man Daten in einem wachsenden Unternehmen analysieren möchte:

• Zentralisierungs-/Monolithisches Problem: „Spotify war nie ein zentralisiertes Unternehmen“, so Robert. „Aber als die Teams keine Werte mehr aus den Daten generieren konnten, haben sie aufgehört, dies als einen wichtigen Bestandteil der Mission zu sehen.“ Man habe so zwar kein Zentralisierungsproblem, aber „ein autonom-monolithisches Problem“ gehabt, so Robert. „Weil die Datenkonsumenten am anderen Ende keinen Produzenten hatten.“
• „Gekoppelte Pipelinezerlegung“: „Das ist ein Problem, welches ich bei unseren sehr wichtigen Playback-Daten sehe“, so Robert. Man habe den Problemraum aufgebrochen, aber die Verantwortlichkeit dafür unterschiedlichen Businesseinheiten zugewiesen. So führe ein Ansteigen dieser architektonischen Zersetzung auf der einen Achse einer Matrix zu einer langsameren Umsetzung auf der anderen Achse. „Wenn also nicht feststeht, was die Prioritäten sind und wie Veränderungen herbeigeführt werden sollen, führt das zu einer langsameren Auslieferung.“
• Silos mit hyper-spezialisierten Eigentümern: „Wir haben nicht-verbundene Teams, frustrierte Kunden“, so Robert, die gerne ihre Anforderungen umgesetzt bekommen wollen. Und zusätzlich ein überstrapaziertes Plattformteam.

Im Endeffekt, so die Aussage von Zhamak Dehghani, existiert eine IT-Architektur und eine Organisationsstruktur, die nicht wachsen und die nicht den versprochenen Wert einer datengetriebenen Organisation verwirklichen können.

Buchtipp: Zhamak Dehghani: „Data Mesh: Delivering Data-Driven Value at Scale“

Was die Lösung für die strukturellen Plattformprobleme darstellen könnte

Robert beschreibt vier Paradigmen anhand von Zhamaks Buch, übertragen auf die Situation bei Spotify, um diese Problemstellungen zu lösen:

1. „Daten“, so interpretiert Robert die Ratschläge von Zhamak, müssen als kritisches Interface innerhalb der verschiedenen Businessbereiche verstanden werden. Denn die Daten müssen auf einer verteilten IT-Architektur übereinstimmen.
2. Als zweites Paradigma formulierte Zhamak, dass die Daten wie ein Produkt behandelt werden müssen. „Und auch das Interface selbst sollte als Produkt verstanden werden“, so Robert. „Das bedeutet eben auch, dass das Team gut mit Personal ausgestattet sein sollte.“ Eben mit einem Produktmanager und auch einer Produktstrategie. „Wenn wir diese einzelnen Komponenten alle innerhalb des gleichen Bereichs behandeln können, dann steht es nicht in Konkurrenz zur Organisationsstruktur“, denkt Robert.
3. Das Zusammenspiel von Daten mit einer Self-Service-Plattform ist das dritte Paradigma. „Das ist für uns kein Problem“, so Robert. Es bestehe eine Self-Service-Plattform. „Vielleicht haben wir es zu gut gemacht“, so Robert. „Wodurch die Datenexplosion entstanden ist.“

„Voraussichtlich werden wir, obwohl wir ganz viele Schritte in die richtige Richtung gehen, niemals den Punkt erreichen, dass wir denken, wir haben es geschafft“, so Robert. „Das ist das, was ich an dieser Aufgabe auch so interessant finde.“

Aber ein Produkt zu entwickeln, sei eine Lösung für ein Problem zu entwickeln, welches man tatsächlich habe. „Aber eben die Probleme von gestern.“ Robert findet deshalb, dass Projektmanager besser Problemmanager genannt werden sollten, „denn wir versuchen die richtigen Probleme zur richtigen Zeit zu lösen“.

In diesem Sinne sei eine Produktstrategie nicht, immer mehr Wert für ein Produkt zu generieren, sondern immer weiter in den Problemraum vorzudringen.

Auf dem Digitale Leute Summit 2021 in Köln beschrieb Robert Stephensen den Weg, den Spotify beschreitet, um mehr Erkenntnisse und am Ende bessere Ergebnisse für den Konsumenten aus den vorhandenen Daten zu generieren.

Über Robert Stephenson: Robert ist Senior Product Manager bei Spotifiy. Nach seiner Ausbildung an der University of Waterloo in Kanada, bei der er sich auf Distributionssysteme und deren Optimierung spezialisierte, und einer Station bei LinkedIn, fing er 2016 bei Spotify an. Dort arbeitet er an Methoden der Datensammlung.

Autor: Jörg Stroisch