Warum das Produktmanagement von Spotify für dein Unternehmen nicht funktioniert

Spotify hat eine Ingenieurskultur entwickelt, die viel Aufmerksamkeit auf sich gezogen hat: Das Spotify Model. Viele Entwicklungsteams, die gewachsen sind und ein Prozess implementieren wollten, versuchten, es nachzuahmen, aber nur wenige schafften es, sie zu implementieren. Heute nutzt Spotify diese scheinbar grossartige Struktur nicht mehr – oder versucht, sie nicht mehr zu nutzen. Da stellt sich die Frage: Warum?

Am Ende dieses Artikels kennst du die Elemente eines erfolgreichen Produktteams, die deinem Unternehmen zum Gedeihen verhelfen können.

Auch wenn Spotify keine Squad-Gruppen mehr verwendet, kann diese Methode anderen flexiblen Produktteams zugutekommen.

Ein kurzer Exkurs in das Spotify Squad Framework

Spotify wurde 2008 mit dem Konzept eines Scrum-Teams für seinen Entwicklungsansatz gestartet. Ihr radikales Wachstum hat jedoch gezeigt, dass die traditionelle Scrum-Methode nicht immer die flexibelste Option war.

Das Team beschloss, Scrum, seine Methoden und Terminologie auf Spotify zuzuschneiden. Sie implementierten das Spotify Squad Framework (Part 1, Part 2). Spotify Squads sind funktionsübergreifende, eigenständige Teams mit maximal acht Personen. Sie sind allein verantwortlich für alle erstellten Produkte. Das beinhaltet: Idee, Entwurf, Testen, Einsatz, Optimierung. Jede Squad-Einheit hat eine einzigartige Mission, kurzfristige Ziele und mehrere langfristige Ziele, die zur Gesamtmission des Unternehmens beitragen.

Im Fall von Spotify besteht die Mission des Unternehmens darin, das Potenzial menschlicher Kreativität freizusetzen. Engineer-Squads treffen lokale Entscheidungen, was bedeutet, dass sie Projekte vorantreiben oder eigenständig starten können, ohne auf die Zustimmung von oben angewiesen zu sein. Spotify baute auf Vertrauen basierende Teams auf, die sich auf kluge Leute verlassen, um kluge Entscheidungen zu treffen. Mit dem Ziel, eine autonome Belegschaft aufzubauen. Spotify stellt die Gemeinschaft gegenüber der Hierarchie und glaubt, dass eine Gemeinschaft, die stark genug ist, die richtigen Entscheidungen treffen könnte, ohne die Zustimmung hochgesinnter Führungskräfte zu benötigen. Spotify glaubt auch, dass sie durch den Aufbau einer in sich geschlossenen Community von Squads, Tribes, Chapters und Gilden ein Produktteam aufbauen kann, welche das Potenzial hat, „bessere Produkte zu machen“.

Was sind Spotify Squads, Tribes, Chapters und Gilden?

Spotify hat die Ingenieurskultur auf die nächste Stufe gehoben – und neue Namen vergeben. Es gibt ein paar Begriffe, die du verstehen musst, um die gesamte Struktur eines Produktteams, der agilen Softwareentwicklung und Produkt Roadmap zu verstehen. Spotify-Squads sind funktionsübergreifende, selbstgesteuerte Teams von bis zu acht Personen mit bereichsübergreifender Verantwortung für Ideenfindung, Design, Tests, Bereitstellung und Optimierung. Die Hauptidee hinter Spotify-Squads war es, einzelnen Teams zu ermöglichen, häufiger zu entwickeln und zu liefern. Neben den Spotify-Squads gab es auch Tribes (Gruppen von Squads), Chapters (Zuständigkeitsbereiche innerhalb der Abteilungen, innerhalb der Tribes) und Guilds (leichte Gemeinschaften von Menschen mit gemeinsamen Interessen zwischen den Abteilungen und Stämmen).

Squads

Ein Produkt-Ökosystem kann aus beliebig vielen Squad-Einheiten bestehen, solange sie durch eine gemeinsame Produktmission vereint sind. Spotify-Squads arbeiten zusammen, um Lösungen zu finden. Bestimmte Squad-Trupps besitzen bestimmte Prozesse oder Systeme – sie versuchen, einander die Möglichkeit zu geben, diese Systeme oder Prozesse zu nutzen, damit andere Spotify-Squads ihre Mission ausführen können. Spotify-Squads neigen dazu, sich auf Produktqualität und Lieferung zu konzentrieren.

Tribes

Tribes sind Squad-Gruppen. Tribes können eine beliebige Anzahl von Squad-Einheiten umfassen und gruppieren sich normalerweise für einen bestimmten Zweck. Das können Produktbereich, Standort, eine ganzheitliche Betrachtung des Problems und mehr sein.

Chapters

Chapters bilden die Kompetenzbereiche in allen Einheiten, innerhalb von Tribes. Beispielsweise könnten fünf Squads jeweils eine Person haben, die auf Anwendungsentwicklung spezialisiert ist. Diese fünf Personen bilden abteilungsübergreifend ein Chapter. Jedes Chapter hat einen Leiter, der als formeller Vorgesetzter fungiert. Diese Struktur ermöglicht es den Mitarbeitern, von einem Team zum anderen zu wechseln und an verschiedenen Initiativen zu arbeiten, ohne ihren Manager und Leiter zu verlieren.

Guilds

Guilds bilden eine Gemeinschaft von Menschen mit gleichen Interessen in Tribes und Squads. Guilds können mehrere Personen aus demselben Squad haben. Sie sind notwendig, um eine Kultur zu schaffen und Mitarbeiter über ihre Rollen hinaus einzubinden. Die Leute können kommen und gehen, wie sie wollen. Guilds können sich in Bereichen der beruflichen Entwicklung wie Python oder Google Analytics zusammenschliessen. Oder sie konzentrieren sich auf persönliche Interessen wie Yoga oder Fussball.

Darum scheitert der Spotify-Ansatz in deinem Unternehmen

Ein Grund dafür ist: Du bist nicht Spotify. Spotify ist ein schwedisches, schnell wachsendes, gut finanziertes Startup (inzwischen eine Börsenkotierte Firma) mit hunderten Entwicklern, welches ein spezifisches B2C Produkt entwickelt: Ein Audio Player auf allen möglichen Geräten. Ebenfalls die hohe Autonomie des Frameworks. Dies führt ohne einen verantwortungsvollen und kollaborativen Prozess jedoch dazu, dass viel Zeit verschwendet und Wissen nicht geteilt wird.

Du kannst jedoch die Erkenntnisse aus der Spotify Squads-Plattform nutzen, um einige deiner Elemente in der eigenen Organisation zu implementieren. Um eine ähnliche Methodik auf das eigene Team anzuwenden, denke daran, dass du den Führungsstil und die Struktur des Teams ändern musst, stelle also sicher, dass Dein gesamtes Team die neue Struktur unterstützt und gib eine bestimmte Anzahl von Empfehlungen ab. Für die Produktentwicklung, agile Softwareentwicklung und Produkt Roadmap sind die Spotify-Methoden teilweise nützlich. Die eigenständigen Produktgruppen von Spotify haben die reibungslose Veröffentlichung von Produkten sichergestellt. Sie neigen dazu, schneller Fehler zu machen als alle anderen und daraus zu lernen. Spotify hat auch die Architektur seines Produkts verändert, um Veröffentlichungen und das Produktmanagement unabhängiger zu machen. Dies bedeutete, dass bestimmte Squad-Gruppen für bestimmte Funktionen oder gewisse Bereiche der SaaS Produktmanagement verantwortlich waren und nicht alle Squads für die gesamte SaaS Anwendung zuständig waren. Die Einheiten des Produktmanagements wurden in drei Hauptbereiche unterteilt:

• Client-Function 
• Infrastruktur
• Client-Anwendung 

Unabhängige Releases bieten einen „begrenzten Burst-Radius“, was bedeutet, dass eine Produktbereitstellung, wenn sie fehlschlägt, auf ihren unmittelbaren Radius beschränkt ist und nicht zum Absturz des gesamten Produkts führt. Der Ansatz von Spotify Squads zur Produktentwicklung basierte auf Lean-Start-up-Prinzipien. Sie identifizieren ein Problem durch Recherche, formulieren eine Beschreibung, um die Lösung zusammenzufassen, und stellen Hypothesen (oder mehrere) über die Auswirkungen dieses Updates oder dieser neuen Produktfunktion auf. Wenn all dies erledigt ist, erstellen die Produktteams Prototypen für Benutzertests. Eine Möglichkeit, diese Technik in dein Team für Produktentwicklung und Produktmanagement zu integrieren, besteht darin, Doortests durchzuführen und relevantes kontextbezogenes Feedback von den Benutzern zu sammeln.

Wichtige Erkenntnisse aus dem Scheitern von Spotify-Squads für das Produktmanagement

Das Spotify Squads-Framework war im Laufe der Jahre Gegenstand von Kritik, von denen viele von ehemaligen Mitarbeitern stammten. Es wurde kritisiert, die falschen Probleme gelöst zu haben, zu autonom zu sein, wegen der Annahme menschlicher emotionaler Intelligenzkompetenzen und die Verantwortung für Ergebnisse zu verschieben. Die Abwesenheit von Engineering Managern störte die Kommunikation mit PM. Eine wichtige Lektion, die aus der Struktur von Spotify-Squads gelernt wurde, ist, dass eine gewisse Hierarchieebene erforderlich ist – Manager gibt es aus einem bestimmten Grund. Diese Struktur ermöglichte es Product Ownern, Design- und SaaS Engineering-Teams ohne Engineering-Manager zu leiten. Bei Meinungsverschiedenheiten innerhalb der Produktentwicklung musste der Produktmanager mit allen Ingenieuren des Teams verhandeln. Wenn die Ingenieure keinen Konsens erzielen konnten, musste der Produktmanager so viele Engineering Manager ansprechen, wie es Engineering-Spezialisten im Team gab. Natürlich hatten sie Leiter; diese Rollen hatten jedoch wenig oder keine Verantwortung für die Ergebnisse der Arbeit; stattdessen waren sie für das Karrierewachstum und die Entwicklung beruflicher Fähigkeiten verantwortlich. Dies führte dazu, dass Produktmanager mit einer Gruppe von Ingenieuren statt mit einem einzelnen technischen Supervisor oder DevOps-Ingenieur sprachen, was zu Zeitverschwendung, viel Hin und Her und vielleicht zu viel Autonomie führte.

Teamübergreifende Zusammenarbeit und Autonomie sind schwer zu kombinieren

Spotify strebt eine hohe Autonomie und Konsistenz beim Produktmanagement an. Führungskräfte präsentieren etwa Probleme, erklären, warum es sich um Probleme handelt, und bitten Teams, Lösungen zu finden, zu erstellen und freizugeben. Viele dieser Probleme erforderten jedoch eine Zusammenarbeit zwischen den Abteilungen. Dies war nicht immer möglich, da andere Squads mit dringend benötigten Prozessen oder Tools nicht über genügend Bandbreite verfügten, um zusammenzuarbeiten. Wenn ich etwas anders machen würde, würde ich sagen, dass wir uns nicht so sehr auf Autonomie konzentrieren sollten. Jedes Mal, wenn Sie ein neues Team haben, muss es das Rad neu erfinden, wie es funktionieren soll. Vielleicht, nur vielleicht, sollten wir „minimal realisierbare Agilität“ haben. Dies führte dazu, dass Produktteams mit agiler Softwareentwicklung und SaaS ihre eigenen Tools und Lösungen entwickelten. Trotz des aktuellen Code-Peer-Review-Prozesses wurde viel Zeit verschwendet und Wissen nicht geteilt. Alles funktionierte nicht so schnell, wie sie gehofft hatten.

Zusammenarbeit erfordert Geschick und Übung

Sicher, Spotify hat kluge Leute eingestellt; Produktmanager, Ingenieure und Datenmanager. Sie streben danach, ein vitales Unternehmen mit Wachstumsdenken, agilen Prinzipien und den richtigen Leuten zu sein. Kluge Menschen sind jedoch nicht unbedingt erfahrene Menschen. Die Struktur des Ingenieurteams von Spotify erforderte bestimmte Fähigkeiten, die Talent nicht immer mit sich bringt, und die Zusammenarbeit war eine davon. Den Leuten fehlte eine gemeinsame Sprache, um Prozessprobleme effektiv zu diskutieren, Bildung, um sie zu lösen, und Erfahrung, um die Leistung zu messen. Schliesslich, führen gut klingende Titel nicht immer zu den richtigen Entscheidungen und können zusätzliche Hindernisse schaffen. Wenn deine Titelstruktur nicht für deine Mitarbeiter geschrieben ist, kann es für die Leute schwierig sein, zu verstehen, was was ist. 

Rolle und Funktionen von Chief Product Officers (CPOs)

Während Unternehmen die wachsenden Anforderungen der digitalen Transformation und des produktgetriebenen Wachstums bewältigen, ist die Rolle des CPO – als Vermittler dieses Übergangs – wichtiger denn je. CPOs, die von digitalen B2B-Unternehmen wie SaaS kommen, konzentrieren sich beim Produktmanagement in der Regel auf das Produktwachstum. Sie haben bereits eine etablierte, starke Kultur und Produkte, die für die Digitalisierung entwickelt wurden. Chief Product Officers in traditionellen Branchen wie Manufacturing, Fertigung und Medien führen die digitale Transformation ihrer Unternehmen an. Für sie zählt nicht das Produkt, sondern eine intelligente Produkt Roadmap, agile Softwareentwicklung und der kulturelle Wandel. Und wenn es um die digitale Transformation geht, dreht sich alles um die Fähigkeit, ein Unternehmen mit einer sehr starken Vision zu transformieren.

Was macht einen CPO erfolgreich? Beim Produktmanagement steht die Customer Journey im Fokus. Das bedeutet, dass der Erfolg anhand des Benutzerengagements, der Kundenzufriedenheit und der Produktakzeptanz gemessen wird. Wenn es um Geschäftskennzahlen geht, denken CPOs an Umsatz, Time-to-Revenue und inkrementelle Verkäufe. Was einen erfolgreichen CPO jedoch auszeichnet, sind seine wirklichen Soft Skills. Und die erfolgreichsten CPOs sitzen am Top-Management-Tisch, sie haben eine sehr starke Vision und sie sind sehr gut darin, diese Vision zu kommunizieren. Sie wissen, was sie aufbauen müssen, und sie machen es richtig.

Je schneller das Wachstum, desto mehr Stress

Wenn ein Unternehmen schnell wächst, steht es unter Stress. Struktur kann die Situation verbessern, aber nur, wenn sie richtig auf Wachstum ausgelegt ist. Eine gute Struktur bildet die Grundlage, auf der deine Organisation wachsen kann. Eine schlechte Struktur kann alles noch schlimmer machen. Strukturelle Entscheidungen sind geschäftskritisch. Sie können ein Unternehmen aufbauen oder zerstören. Wenn der Erfolg deines Unternehmens von effektivem Wachstum abhängt, musst du es richtig machen. Definiere deine Organisationsstruktur, denn es gibt viele Möglichkeiten, die Produktentwicklung oder Produkt Roadmap zu organisieren. Es gibt zwei erwägenswerte Ansätze:

1. Das Triade-Modell. Jede Funktion (Engineering, Produkt und Design) hat ihre eigene Berichtsstruktur und Organisation. Sie arbeiten auf Augenhöhe zusammen.
2. Das CEO-Modell. Jede Organisation wird von einem General Manager geleitet, der für alle Funktionen innerhalb seiner Organisation verantwortlich ist. Dies wird auch als „Single Threaded Owner“-Modell bezeichnet.

Organisiere funktionsübergreifende Designs, implementiere und entwerfe Produkte

Es ist üblich, dass sich die agile Softwareentwicklung entlang funktionaler Linien organisiert. Zum Beispiel Front-End- und Back-End-Teams. Das mag natürlich erscheinen, denn so denken Ingenieure oft über ihre Arbeit. Und Ingenieure neigen dazu, ihre Identität, um ihre Rolle als Front-End-Ingenieure oder Back-End-Ingenieure herum aufzubauen. Sie erwarten also Frontend-Aufgaben und Backend-Aufgaben. Dieser Ansatz ist zwar möglich, hat aber viele Nachteile.

Diese sind:

• Erhöhte Abhängigkeit zwischen den Teams, was zu schlechter Leistung führt.
• Erhöhte Komplexität der Organisation (die mit zunehmendem Wachstum schlimmer wird)
• Erhöhter Kommunikationsbedarf

Jedes Team sollte in der Lage sein, einen Mehrwert für das Unternehmen zu schaffen, ohne andere Teams einzubeziehen. Daher solltest du Teams standardmässig funktionsübergreifend organisieren und nur funktional verwalten, wenn es ineffizient erscheint. In den meisten Fällen sollte man so tun, als ob das Design und das Produkt Teil desselben Teams sind. Füge jedem Team einen Designer und einen Produktmanager hinzu.

Eine der häufgisten Fehlerquellen in schnell wachsenden Organisationen sind ineffektive und fehlendes Ownership in den Führungsstrukturen. Ein starker Product Owner, der die Produkt Roadmap aktiv managed und alle notwendigen Anspruchsgruppen wie Sales, Entwickler und Design einbindet, kann viel erreichen. Tatsächlich würde ich sagen, dass dies eines der Probleme ist, auf die wir am häufigsten stossen.

In extremen Wachstumssituationen kann eine schlechte Anpassung zum Scheitern der Organisation führen. Wenn du die Unternehmensgrösse in sechs Monaten verdoppelst und es sechs Monate dauert, sich anzupassen, verlierst du an Boden. Deswegen investieren kluge Führungskräfte in ein effektives Onboarding der Mitarbeiter und leisten strukturelle Arbeit, um das Onboarding zu erleichtern. Ein Beispiel für Strukturarbeit, die der Anpassung hilft, ist die Definition von Rollen und einer klaren Produkt Roadmap. Wer ist für die technische Führung zuständig? Wer ist für das Projektmanagement im B2B Bereich zuständig? Das Identifizieren dieser Dinge ist wichtig, weil du nach diesen Fähigkeiten einstellst und jeder verstehen muss, wie sie in die schnell wachsende Organisation passen, die du aufbaust. Diese Art von Struktur ist absolut notwendig.

Wenn du Rollen definierst, empfehle ich Dir, diese dynamisch zu definieren und du musst kommunizieren, dass alles Geschriebene flexibel ist und sich im Laufe der Zeit ändern kann. Wenn diese schriftlichen Rollen unveränderlich wären, würde dies die organisatorische Flexibilität und den Wandel behindern. Dies ist für ein schnell wachsendes B2B Unternehmen problematisch.