Die Frage, nach welchen Kriterien eine Produktorganisation „geschnitten“ wird, ist komplex. Ich habe die meisten Ansätze in der Praxis schon erlebt und bin mittlerweile ein Anhänger der sogenannten Customer Journey Teams. In diesem Artikel erkläre ich warum und vor allem, wie man dorthin kommen kann.

Customer Journey Teams – um was geht’s?

In meinem Beitrag 4 Wege zu einem erfolgreichen Product Leadership habe ich schon die Organisationsentwicklung als einer der wichtigen Fähigkeiten eines Product Leaders beschrieben. Die Herausforderung von „Org Design“ ist komplex. Sie darf nicht nur die Funktion Produktmanagement betrachten, sondern auch die Auswirkungen auf andere Bereiche.

Von Organisationsformen wird viel erwartet, wie zum Beispiel:

• die größtmögliche Autonomie der Teams
• die beste Struktur für Karrierepfade
• eine lange Beständigkeit bei gleichzeitig hoher Flexibilität
• eine klare „Ownership“ von technischen Artefakten

Alles wunderbar. Das hört sich vernünftig an, oder? Nein, tut es nicht. Es fehlt der wichtigste Teil, nämlich der Kunde für den wir das alles machen. Das Produktmanagement hat die Aufgabe, Kunden- und Nutzerprobleme zu erkennen und diese funktionsübergreifend zu lösen. Eine Organisation hat die Aufgabe, die bestmöglichen Rahmenbedingungen dafür zu schaffen.

Ob sie darüber hinaus meine Kollegen:innen oder mir selbst nur wenige, viele oder sogar optimale Karrierechancen bietet, interessiert mich nicht. Organisationen werden nicht um Personen herum „gestrickt“. Die Personen haben sich an die für die Anforderungen von Markt und Kunden beste Organisationsform anzupassen.

Customer Journey Teams oder nicht – 5 Prinzipien

Bevor ich zu meinem Praxisbeispiel komme, möchte ich die für mich fünf wichtigsten Prinzipien bei der Wahl der passenden Organisationsform vorstellen:

1. Die Organisation folgt dem Business: Die Produktorganisation hat sich mit allem was sie tut an den Business-Zielen auszurichten. Das betrifft sowohl die Inhalte der Roadmap und Strategie als auch die Organisationsform. Die Aufgabe des Product- und des Tech-Leaders ist es, dies zu jedem Zeitpunkt für den entsprechenden Geschäftsbereich zu gewährleisten.
2. Es braucht einen langfristigen Fokus: Ein Team funktioniert am besten wenn folgende Voraussetzungen gegeben sind: a) Es gibt einen klaren Auftrag beziehungsweise eine klar definierte Mission; b) Das Team-Setup bleibt über einen längeren Zeitpunkt hinweg stabil; c) Das Team arbeitet an wenigen Themen mit hoher Priorität und vermeidet größere Kontextwechsel.
3. Es braucht ein Set klar abgestimmter KPIs: Abgeleitet aus der Mission und den Business-Zielen definiert jedes Team oder jeder Bereich ein Set von KPIs (Key Performance Indicators), an denen der Erfolg der tagtäglichen Arbeit gemessen wird. Dafür bietet es sich an, einen sogenannten „KPI Tree“ zu erstellen, der die Interdependenzen und die Kaskadierung der KPIs verdeutlicht. Einen guten Ansatz dafür bietet das North Star Metric Framework von Sean Ellis.
4. Die höchstmögliche Autonomie muss geschaffen werden: Teams sind am schnellsten, wenn sie so wenig externe Abhängigkeiten wie möglich haben, um ihre Aufgaben zu erledigen. Eine hohe Autonomie schafft man durch eine hohe Abdeckung an Fertigkeiten (Skills). Hierbei geht es nicht nur um die Funktionen Produkt, Tech und UX, sondern je nach Größe und Art eines Themen-Bereichs auch um Business Development, Sales, Marketing oder Customer Service.
5. Eine Funktions- und Team-übergreifende Kollaboration muss ermöglicht werden: Die Punkte 1-4 sind schlüssig, beinhalten aber die Gefahr einer Silo-Bildung. Falsch verstandene Autonomie kann im schlimmsten Fall zu Zielkonflikten führen, was den gesamtheitlichen Blick auf die Kundenbedürfnisse gefährdet. Hier sind wiederum die Führungskräfte gefragt, um die Rahmenbedingungen, wie zum Beispiel gemeinsame Ziele, Zeremonien und Formate, zu schaffen.

Fallbeispiel – dem Kunden sind APIs egal

Die Ausgangslage

In einem konkreten Fall war die Produkt-Organisation „historisch“ entlang der technischen Komponenten geschnitten. Beispielsweise war ein Team für die Administrations-Oberfläche der professionellen Verkäufer zuständig, ein anderes Team für die technischen Schnittstellen (APIs) und die Anbindung externer Tools. Auf den ersten Blick klingt das logisch, da es eine klare Zuordnung der Artefakte ermöglicht.

Auf der anderen Seite wurden wir regelmäßig mit folgenden Herausforderungen konfrontiert:

• Koordinationsaufwand: Die Teams mussten ständig ihre Planung abgleichen, um Anwendungsfälle (Use Cases) der Nutzer in beiden Artefakten termingerecht auszurollen.
• Fehlende Mission: Die Teams konnten für sich keine Mission beziehungsweise längerfristigen Auftrag definieren. Einer der Gründe war die fehlende Verantwortung für in sich geschlossene Anwendungsfälle aus Nutzer- und Kundensicht.
• Fehlende KPIs: Durch die fehlende Verantwortung für klar definierte Use Cases war es nahezu unmöglich Produkt-KPIs festzulegen und diese in Bezug zu den Business-Zielen zu setzen.
• Häufige Kontextwechsel: Da die Themengebiete für die Teams nicht klar aus Nutzer- und/oder Businessperspektive umrissen waren, wurden Projekte häufig beliebig beziehungsweise nach Auslastung zugeordnet.

Die Idee

Uns war klar, dass wir einen anderen Weg finden mussten, um die Teams aufzuteilen. Da sich das Produkt-Portfolio vergrößerte, war der Schritt nötig, um in Zukunft einfacher skalieren zu können und nicht bei jedem neuen „Projekt“ entscheiden zu müssen, welches Team am besten geeignet ist.

Die Schritte hin zu Customer Journey Teams

Mach‘ erstmal Business-Strategie

Wir hatten schon früh das Konzept der Customer Journey beziehungsweise der Jobs to Be Done in der Produktorganisation eingeführt, um Kundenempathie aufzubauen und neue Ideen zu generieren. Wie schon oben beschrieben muss am Anfang einer Neuausrichtung immer eine Business-Vision und -Strategie stehen. Davon leiten sich dann sowohl die Aktivitäten und Pläne als auch die Organisationsform der einzelnen Funktionen ab.

Die Business-Strategie wurde unter der Führung des verantwortlichen Business Developers funktionsübergreifend und in mehreren Workshops entwickelt. Einer der Kernelemente war die Definition der strategischen Felder, auf die sich der Bereich in den kommenden fünf Jahren konzentrieren sollte. Da die Customer Journey zunehmend zum Dreh- und Angelpunkt wurde, definierten wir die Felder entlang der darin identifizierten Kundenprozesse. Damit gewährleisteten wir die Konsistenz bei den Entscheidungen und Aktivitäten innerhalb der Geschäftseinheit.

Ran an die Teams

Im Produktteam waren wir uns einig, dass sich eine neue Org-Struktur konsequenterweise an den strategischen Geschäftsfeldern und damit an der Customer Journey ausrichten sollte. Die Entscheidung basierte auf der Annahme, dass zum einen der Business-Kontext klarer sein würde und zum anderen die Teams einfacher eine (End-to-End) Verantwortung für die Anwendungsfälle der Kunden übernehmen könnten.

Bei der Vorstellung der Idee in der Runde der Tech- und Teamleads machte sich dann schnell Ernüchterung breit. Der Vorschlag wirkte oktroyiert und die Diskussion drehte sich am Ende um Verantwortlichkeiten für die technischen Artefakte, die eine solche Änderung mit sich bringt.

Einen Schritt zurück

Die Idee an sich war nicht das Problem. Alle waren sich einig, dass sich unsere Organisation in Zukunft anders aufstellen musste. Unser Versäumnis war es, den Tech-Teams nicht die Möglichkeit zu geben, eigene Alternativen zu entwickeln und sich mit den Auswirkungen auf die technischen Verantwortlichkeiten zu beschäftigen. In Abstimmung mit der IT-Leitung haben wir das nachgeholt und in mehreren Sessions einen Plan entwickelt, wie und in welchen Schritten wir funktionsübergreifend vorgehen.

Durch Investitionen in zusätzliche Mitarbeiter wurde die Transformation zusätzlich beschleunigt, da die Teams sich durch die größere Personalstärke sowieso neu aufteilen mussten. Man konnte dabei sehr gut den klassischen „J-Curve“-Effekt beziehungsweise die Teambuilding-Phasen nach Tuckman (Forming, Storming, Norming, Performing) beobachten. Am Ende wurden Schritt für Schritt die ursprünglichen Herausforderungen aufgelöst und damit die Prinzipien der Organisationsentwicklung wesentlich besser bedient.

Die Grenzen von Customer Journey Teams

Jedes Organisationsmodell hat seine Stärken und Schwächen. Insbesondere folgende Fragestellungen müsst Ihr vor einer Änderung beantworten:

• Was ist mit nativen Plattformen? Ha! Über das Thema „native Setup“ kann man vortrefflich streiten. Die Antwort ist wie so oft: kommt drauf an. Zum einen auf den Reifegrad des nativen App-Angebots und zum anderen auf die Deckungsgleichheit der Anwendungsfälle im Vergleich zum Web. Ist der Entwicklungsstand der Apps noch nicht sehr weit, dann macht es Sinn, ein kleines Team zu entkoppeln, um eine hohe Umsetzungsgeschwindigkeit zu erreichen. Gleiches gilt, wenn die Apps kein 100% Abbild der Web-Anwendung sind, sondern wenn gezielt spezifische Use Cases nativ umgesetzt werden. Entscheidet man sich für eine Entkopplung, dann muss auf der anderen Seite eine gute Abstimmung zwischen den Teams erfolgen – insbesondere, was das Plattform-übergreifendes Tracking und die UX-Design Patterns betrifft.
• Was wenn der Fokus sich ändert? Wie schon oben beschrieben, ist Beständigkeit einer der Voraussetzungen für performante Teams. Die Vision und Strategie hilft dabei, das zu gewährleisten. Es gibt jedoch immer wieder externe und interne Faktoren und Ereignisse, die einen Fokus-Wechsel verlangen. Die Teams müssen dann in Lage und auch bereit sein, sich schnell anzupassen. Dabei spielen Erfahrung und ein breit ausgelegtes Skill Set in allen Funktionen eine Rolle, um die neuen oder geänderten Ziele mit möglichst wenig Reibungsverlusten zu bedienen.
• Wie vermeiden wir Silos? Was für ein schöner Begriff! Und: Im agilen Sinne sind Silos sogar etwas Positives. Sie gewährleisten Autonomie und Geschwindigkeit. Auf der anderen Seite bergen Silos die Gefahr, den holistischen Blick auf die Kunden und die Platform zu verlieren. Ich sehe hier drei Ansätze, um dies zu vermeiden: a) Einführung von agilen Gilden oder sogenannten Communities of Practice für die wichtigsten Funktionen; b) Definition einer North Star Metric für den Geschäftsbereich, um ein gemeinsames Ziel zu verfolgen; c) Entwicklung einer Business- und Produktstrategie, die den kollektiven Blick auf die Customer Journey und die zugrunde liegenden Bedürfnisse der Nutzer schärft.

Fazit

Ob es am Ende ein Journey-, „Funnel“- oder sogar ein Zielgruppen-Ansatz ist, den Ihr mit Eurer Produktorganisation verfolgt, hängt von einer Vielzahl von Faktoren ab. Wichtig ist nur, dass Ihr bei allen Änderungen der Team-Strukturen unbedingt versucht, aus der Perspektive des Nutzers beziehungsweise des Kunden zu denken.

Zum Zweiten solltet Ihr von Anfang an die Teams in die neue Gedankenwelt einbeziehen, selbst wenn Ihr dadurch zusätzliche „Schleifen“ drehen müsst. Nur mit der Einbindung aller Funktionen bekommt Ihr die dringend notwenige Unterstützung für die Veränderungsprozesse.

Weiterführende Links

• https://www.mckinsey.com/industries/financial-services/our-insights/ings-agile-transformation#
• https://www.user-experience-blog.de/2017/03/bessere-ux-durch-organisation-user-journeys/
• https://dandypeople.com/blog/the-customer-journey-product-organization/
• https://www.infoq.com/articles/magic-customer-journeys/

Literaturtipp

Klickt, kauft und macht uns reich – der Literaturtipp zum Thema agile Frameworks am Beispiel von Spotify:

Bild 1: Patagonien (Argentinien) von Martin Heckmann