28,99 €
Mehr erfahren.
- Herausgeber: Wiley-VCH
- Kategorie: Fachliteratur
- Sprache: Deutsch
Wie Sie Ihr Unternehmen transformieren und so innovativ werden, wie die weltweit führenden Technologieunternehmen!
In INSPIRED enthüllte der Produktvordenker Marty Cagan die besten Praktiken und Techniken der besten Produktteams führender Technologieunternehmen. In EMPOWERED wurden die besten Methoden vorgestellt, die die besten Produktmanager einsetzen, um ihren Teams das Umfeld zu bieten, das sie brauchen, um bei der Produktentwicklung erfolgreich zu sein.
TRANSFORMED baut nun eine Brücke zwischen dem Status quo, der Art und Weise, wie die meisten Unternehmen aktuell arbeiten und dem Ziel, das sie erreichen wollen: ein herausragendes Produkt-Modell. Die Führungskräfte dieser Unternehmen wissen, dass sie sich transformieren müssen, um in einer Ära sich schnell verändernder Technologien wettbewerbsfähig zu sein und zu bleiben, aber die meisten von ihnen haben noch nie auf diese Weise gearbeitet. TRANSFORMED hat drei große Ziele:
- Erstens vermittelt Ihnen das Buch ein tiefes Verständnis des Product Operating Model (Produktbetriebsmodells) und was es bedeutet, so zu arbeiten.
- Zweitens wird das Buch Sie mit detaillierten Fallstudien erfolgreicher Transformationen davon überzeugen, dass es zwar schwierig, aber durchaus möglich ist, Ihr Unternehmen auf das Produktbetriebsmodell umzustellen.
- Drittens wird das Buch Sie mit wirklich beeindruckenden Fallstudien von Produktinnovationen inspirieren, die zeigen, wozu auch Sie in der Lage sind, wenn Sie sich erfolgreich umstellen.
TRANSFORMED richtet sich an diejenigen, die den Wandel vorantreiben, einschließlich der Führungskräfte - angefangen beim CEO - sowie der leitenden Angestellten und Stakeholder, die mit den Produktteams zusammenarbeiten müssen, den Produktleitern, den Mitgliedern der Produktteams und all jenen, die diese Produktteams entweder unterstützen oder von ihnen abhängig sind.
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 458
Veröffentlichungsjahr: 2024
Ähnliche
1. Auflage 2025Alle Bücher von WILEY-VCH werden sorgfältig erarbeitet. Dennoch übernehmen Autoren, Herausgeber und Verlag in keinem Fall, einschließlich des vorliegenden Werkes, für die Richtigkeit von Angaben, Hinweisen und Ratschlägen sowie für eventuelle Druckfehler irgendeine Haftung
© 2025 Wiley-VCH GmbH, Boschstraße 12, 69469 Weinheim, GermanyAlle Rechte, insbesondere die der Übersetzung in andere Sprachen, vorbehalten. Kein Teil dieses Buches darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form – durch Photokopie, Mikroverfilmung oder irgendein anderes Verfahren – reproduziert oder in eine von Maschinen, insbesondere von Datenverarbeitungsmaschinen, verwendbare Sprache übertragen oder übersetzt werden. Die Wiedergabe von Warenbezeichnungen, Handelsnamen oder sonstigen Kennzeichen in diesem Buch berechtigt nicht zu der Annahme, dass diese von jedermann frei benutzt werden dürfen. Vielmehr kann es sich auch dann um eingetragene Warenzeichen oder sonstige gesetzlich geschützte Kennzeichen handeln, wenn sie nicht eigens als solche markiert sind.
Bibliografische Information der Deutschen NationalbibliothekDie Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.
Das englische Original erschien 2024 unter dem Titel Transformed. Moving to the Product Operating Model bei John Wiley & Sons, Inc., Hoboken, New Jersey
Copyright © 2024 by John Wiley & Sons, Inc.
All rights reserved. This translation published under license with the original publisher John Wiley & Sons, Inc.
Hedcut illustrations © Alison Boddy
Print ISBN: 978-3-527-51191-4ePub ISBN: 978-3-527-84815-7
Umschlaggestaltung: Torge Stoffers (in Anlehnung an das Orignalcover der US-Asugabe)
Dieses Buch ist Bruce Williams (1950–2016) gewidmet. Bruce war derjenige, der mir den Mut und das Selbstvertrauen gegeben hat, meine Komfortzone als Product Leader für andere Unternehmen zu verlassen und mich stattdessen mit der Silicon Valley Product Group (SVPG) selbstständig zu machen.
Bruce war nicht nur ein außergewöhnlicher Mensch, der wirklich das Leben zahlloser anderer verbessert hat, sondern auch der beste Freund, den man sich wünschen kann. Von Bruce habe ich alles bekommen, von Büroraum bis hin zu fachkundigem Rat in puncto Design, Vertrieb, Marketing, Veröffentlichungen, Finanzen und vielen anderen Dingen.
Ohne Bruce wäre ich wahrscheinlich Product Leader geblieben und hätte nie die Chance bekommen, Bücher zu schreiben oder die zuvor unvorstellbare Lebensqualität zu genießen, die ich als Teil der SVPG erlebe. Ich danke Bruce dafür, dass er mich ermuntert hat, die beste Karriereentscheidung meines Lebens zu treffen.
Ich wünsche jedem Menschen das Glück, dass es in seinem oder ihrem Leben einen Bruce Williams geben möge.
Inhaltsverzeichnis
Cover
Titelblatt
Impressum
Widmung
Inhaltsverzeichnis
Teil I: EINLEITUNG
1 Für wen ist dieses Buch gedacht?
2 Was ist ein Product-Operating-Modell?
3 Warum transformieren?
4 Eine typische Transformation
Notiz
5 Die Rolle des oder der CEO
6 Ihr Wegweiser durch
TRANSFORMED
Notiz
Teil II: DEFINIERE TRANSFORMATION
Anmerkungen
7 Ändern, wie Sie entwickeln
Anmerkungen
8 Ändern, wie Sie Probleme lösen
9 Ändern, wie Sie entscheiden, welche Probleme zu lösen sind
Notiz
Teil III: PRODUCT-MODELL-KOMPETENZEN
Notiz
10 Product Manager
Notiz
11 Product Designer
12 Technische Leiter
Anmerkungen
13 Product Leader
Notiz
14 Innovations-Story: Almosafer
Teil IV: PRODUCT-MODELL-KONZEPTE
15 Product Teams
Prinzip:
Zu eigenverantwortlicher Problemlösung ermächtigt (empowered)
Prinzip:
Ergebnisse gehen über Output
Prinzip:
Ein Gefühl der Eigenverantwortlichkeit
Prinzip:
Zusammenarbeit
Notiz
16 Product-Strategie
Prinzip:
Fokussieren
Prinzip:
Erkenntnisse als Motor
Prinzip:
Transparenz
Prinzip:
Die Einsätze verteilen
17 Product Discovery
Prinzip:
Verschwendung minimieren
Prinzip:
Product-Risiken einschätzen
Prinzip:
Mit schnellem Experimentieren anfreunden
Prinzip:
Ideen verantwortungsbewusst testen
18 Product-Auslieferung
Prinzip:
Kleine, häufige, unverbundene Releases
Prinzip:
Instrumentierung
Prinzip:
Überwachung
Prinzip:
Infrastruktur für die Bereitstellung
Anmerkungen
19 Product-Kultur
Prinzip:
Prinzipien gehen über Prozesse
Prinzip:
Vertrauen geht über Kontrolle
Prinzip:
Innovation geht über Berechenbarkeit
Prinzip:
Lernen geht über mögliche Misserfolge
20 Innovations-Story: CarMax
Teil V: TRANSFORMATIONS-STORY: TRAINLINE
Teil VI: DAS PRODUCT-MODELL IN AKTION
21 Partnerschaft mit den Kunden
Notiz
22 Partnerschaft mit dem Vertrieb
23 Partnerschaft mit dem Product Marketing
24 Partnerschaft mit der Finanzabteilung
25 Partnerschaft mit den Stakeholdern (betroffenen Beteiligten) im Unternehmen
26 Partnerschaft mit dem Management
27 Innovations-Story: Gympass
Teil VII: TRANSFORMATIONS-STORY: DATASITE
Teil VIII: TRANSFORMATIONS-TECHNIKEN
28 Transformations-Ergebnisse
29 Transformations-Bewertung
Notiz
30 Transformations-Taktiken: Kompetenzen
31 Transformations-Taktiken: Konzepte
32 Transformations-Taktiken: Umsetzung
33 Transformations-Überzeugungsarbeit
34 Transformations-Hilfe
Product Coach: Gabrielle Bufrem
Product Coach: Hope Gurion
Product Coach: Margaret Hollendoner
Product Coach: Stacey Langer
Product Coach: Dr. Marily Nika
Product Coach: Phyl Terry
Product Coach: Petra Wille
35 Innovations-Story: Datasite
Teil IX: TRANSFORMATIONS-STORY: ADOBE
Teil X: EINWÄNDEN BEGEGNEN
36 Einwände von Kunden
37 Einwände aus dem Vertrieb
38 Einwände von CEO und Vorstand
39 Einwände aus den Geschäftsbereichen
40 Einwände aus der Kundenbetreuung (Customer Success)
41 Einwände aus dem Marketing
42 Einwände aus der Finanzabteilung
43 Einwände aus der Personalabteilung
44 Einwände der IT-Leitung (der/des CIO)
45 Einwände des Projektmanagementbüros (PMO)
46 Einwände aus dem Product-Bereich selbst
Notiz
47 Innovations-Story: Kaiser Permanente
Teil XI: FAZIT
48 Die zehn Schlüsselelemente einer erfolgreichen Transformation
49 Innovations-Story: Trainline
Teil XII: ANHANG
Mehr erfahren
Danksagungen
Die Autoren
Stimmen zu TRANSFORMED
End User License Agreement
Orientierungspunkte
Cover
Titelblatt
Impressum
Widmung
Inhaltsverzeichnis
Fangen Sie an zu lesen
Mehr erfahren
Danksagungen
Die Autoren
Stimmen zu TRANSFORMED
End User License Agreement
Pages
3
4
5
11
13
14
15
16
17
19
20
21
22
23
24
25
26
27
28
29
31
32
33
34
35
36
37
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
97
98
99
100
101
102
103
104
105
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
129
130
131
132
133
134
135
137
138
139
140
141
142
143
145
146
147
149
150
151
152
153
154
155
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
229
230
231
233
234
235
236
237
238
239
240
241
242
243
244
245
247
248
249
250
251
252
253
254
255
256
257
259
260
261
263
264
265
267
268
269
270
271
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
293
294
295
296
297
298
299
300
301
302
303
305
307
309
311
312
313
314
315
316
Teil IEINLEITUNG
Dieses Buch verfolgt drei große Ziele:
Erstens möchten wir Ihnen genau erklären, was das Product-Operating-Modell ist und was es heißt, auf diese Art und Weise zu arbeiten.
Zweitens möchten wir Sie überzeugen – vor allem durch detaillierte Fallstudien von erfolgreichen Transformationen –, dass eine solche Transformation zwar durchaus schwierig sein wird, es für Sie aber dennoch ohne Weiteres möglich ist, Ihr Unternehmen gemäß dem Product-Modell zu transformieren.
Drittens wollen wir Sie inspirieren – vor allem durch einige wirklich beeindruckende Fallstudien von Product-Innovationen –, wozu auch Ihr Unternehmen in der Lage sein wird, wenn Sie es erst einmal erfolgreich transformiert haben.
Zu Beginn wollen wir Ihnen erläutern, warum wir das Buch TRANSFORMED geschrieben haben und in welcher Beziehung es zu den beiden vorausgehenden Büchern INSPIRED und EMPOWERED steht.
Als Nächstes möchten wir Ihnen dann die Hauptgründe und -motive dafür aufzeigen, warum Unternehmen den durchaus beträchtlichen Zeit- und Arbeitsaufwand auf sich nehmen, der für eine solche Transformation erforderlich ist.
Anschließend kommen wir zur Sache und schildern Ihnen zunächst einmal den ganz typischen Fall eines Transformations-Versuchs, der vorhersagbar zu enttäuschenden Ergebnissen geführt hat.
Wie sich dadurch zeigt, ist es also ganz wichtig, dass wir Ihnen ein realistisches Verständnis davon vermitteln, was für eine erfolgreiche Transformation wirklich erforderlich ist. Mancher wird Ihnen weismachen wollen, die Sache wäre ganz einfach – wenn Sie nämlich zur Unterstützung seine Dienste in Anspruch nehmen. Die Realität sieht allerdings ganz anders aus.
Genauso wichtig ist aber auch, dass wir Sie überzeugen: Sie können Erfolg haben! Und darüber hinaus wollen wir Ihnen auch ein Verständnis davon vermitteln, was Sie als Unternehmen alles werden erreichen können, wenn Sie Ihre »neuen Muskeln« erst einmal aufgebaut haben.
Zum Schluss wollen wir auch noch das Dilemma ansprechen, dass Sie womöglich erkennen, dass Sie etwas ändern müssen, aber womöglich keine Führungskräfte haben, die schon einmal auf diese Art und Weise gearbeitet haben.
1Für wen ist dieses Buch gedacht?
TRANSFORMED ist für alle geschrieben, die dazu beitragen wollen, dass ihr Unternehmen zum Product-Operating-Modell übergeht.
Dazu gehören:
Mitglieder von Product Teams, die zum Product-Operating-Modell übergehen wollen;
Product Leader, die ihr Unternehmen durch diese Veränderungen hindurchführen wollen;
leitende Manager des Unternehmens, insbesondere CEOs oder Geschäftsführer und Finanzchefs oder -chefinnen, die erfahren wollen, was beim Übergang zum Product-Modell alles zu beachten ist, ob das Ganze etwas für ihr Unternehmen ist und wie sie die Sache gegebenenfalls unterstützen können;
sonstige Manager, Beteiligte und Mitarbeiter, die vom Product-Modell betroffen sind und wissen möchten, wie sie sich konstruktiv einbringen können;
Product Coaches, die Unternehmen bei der erfolgreichen Transformation hin zum Product-Modell helfen möchten.
Eine sehr häufige Frage lautet: »Wir sind gar kein Tech-Unternehmen – ist das Product-Modell dann überhaupt etwas für uns?«
Hier liegt ein sehr verbreitetes Missverständnis vor: Wenn unsere Branche von einem »Tech-Unternehmen« spricht, dann bezieht sich das nicht darauf, was dieses Unternehmen verkauft, sondern darauf, wie dieses Unternehmen sein Geschäft betreibt.
Tesla verkauft Autos. Netflix verkauft Unterhaltung. Google verkauft Werbung. Airbnb verkauft Ferienunterkünfte. Amazon hat anfangs Bücher verkauft und verkauft heute nahezu alles.
Das Besondere ist also nicht, was diese Unternehmen verkaufen. Das Besondere ist, wie diese Unternehmen konzipieren und entwickeln, was sie verkaufen, und wie sie ihr Geschäft betreiben.
Das Product-Operating-Modell eignet sich für alle Unternehmen, die finden, dass sie ihr Geschäft mit Technologie betreiben sollten. Und das umfasst heute eine sehr große Bandbreite von Unternehmen in praktisch allen Branchen.
In welcher Beziehung steht dieses Buch nun zu INSPIRED und EMPOWERED?
INSPIRED haben wir geschrieben, um Ihnen die optimalen Vorgehensweisen und Techniken von Top-Product-Teams zu vermitteln, die nach dem Product-Modell arbeiten.
EMPOWERED haben wir anschließend geschrieben, um die optimalen Vorgehensweisen und Techniken von Top-Product-Leadern zu vermitteln, die ihren Product Teams das benötigte Umfeld verschaffen, in dem sie nach dem Product-Modell gut arbeiten können.
Aber die bei Weitem häufigste Frage, die wir gestellt bekommen, lautet: »Unser Unternehmen arbeitet so vollkommen anders, als Sie es beschreiben. Ist es für ein Unternehmen wie unseres denn überhaupt möglich, zum Product-Modell überzugehen, und wie würden wir eine solche Veränderung bewerkstelligen?«
Die Beantwortung genau dieser Frage ist das Ziel dieses Buches.
Seit 20 Jahren helfen wir von der SVPG Unternehmen bei solchen Veränderungen. Aus dieser Erfahrung wissen wir, dass es einige Unternehmen gibt – vor allem jüngere Unternehmen, die erst in der Internet-Ära gegründet wurden –, die bereits gemäß dem neuen Modell Tech-betriebener Product-Unternehmen entstanden sind. Für diese Unternehmen ist eine solche Arbeitsweise völlig natürlich.
Der großen Mehrheit der Unternehmen auf der Welt dagegen ist die Arbeitsweise, die wir hier beschreiben, völlig fremd.
Ein CEO verglich die Erfahrung einer solchen Transformation einmal damit, »vom Rechtsverkehr zum Linksverkehr überzugehen – und das schrittweise«.
Diese Unternehmen wissen zwar, dass sie sich transformieren müssen, um in einer Ära sich rasch verändernder unterstützender Technologie konkurrenzfähig zu bleiben, haben aber auch die Erfahrung gemacht, dass die erforderlichen Veränderungen erheblich sind und alles andere als einfach.
Wenn Sie INSPIRED und EMPOWERED gelesen haben, werden Sie die Bestandteile des Product-Modells wiedererkennen. Diese Bücher vermitteln jedoch nicht, wie Sie die erforderlichen Veränderungen Ihrer Arbeitsweise vornehmen können.
Wenn Sie unsere anderen Bücher nicht gelesen haben, kann Ihnen dieses Buch das notwendige Verständnis vom Konzept des Product-Modells vermitteln und Ihnen die benötigten Grundlagen liefern.
2Was ist ein Product-Operating-Modell?
Leider ist die Tech-Branche nicht gerade gut darin, für standardisierte Begriffe zu sorgen. Oft haben wir verschiedene Bezeichnungen für ein und dasselbe Konzept, mitunter haben wir umgekehrt auch ganz unterschiedliche Definitionen für ein und denselben Ausdruck.
Wir möchten hier ungern eine neue Nomenklatur einführen, aber wir müssen uns natürlich auch immer darüber im Klaren sein, was wir eigentlich meinen, wenn wir in diesem Buch über wichtige Konzepte sprechen.
Das grundlegendste Konzept, das wir hier verwenden und über das Klarheit herrschen muss, ist ganz allgemein das Product-Operating-Modell.
Diesen Ausdruck haben wir nicht selbst erfunden, sondern wir sind ihm in verschiedenen starken Product-Unternehmen begegnet. Etliche benutzen auch die Kurzform Product-Modell. (Auf Deutsch ließe sich der Ausdruck Product Operating vielleicht am besten als umfassende Produkt-Betreuung oder Produkt-Bearbeitung wiedergeben.)
Das Product-Operating-Modell ist kein Prozess und auch keine bestimmte Arbeitsweise. Es ist ein konzeptionelles Modell, das auf einer Reihe von Grundprinzipien beruht, die starke Product-Unternehmen für richtig halten. Zu diesen Prinzipien gehören zum Beispiel die Notwendigkeit des Experimentierens oder der Vorrang von Innovation vor Berechenbarkeit.
Wir verwenden den Ausdruck in diesem Buch, wenn wir uns auf die Vorgehensweise beziehen wollen, die nach unserer Beobachtung die besten Product-Unternehmen konsequent verwenden.
Im Wesentlichen geht es beim Product-Operating-Modell darum, konsequent Tech-betriebene Lösungen hervorzubringen, die einerseits den Kunden gefallen, andererseits auch dem Unternehmen etwas bringen.
Aus finanzieller Perspektive geht es darum, aus den Tech-Investitionen des Unternehmens das Meiste herauszuholen.
Wichtig ist hier zu betonen, dass es nicht die eine richtige Methode gibt, Products (Produkte) zu entwickeln. Mehr zu diesem sehr wichtigen Punkt später. Hier soll zunächst der Hinweis genügen, dass es viele gute Methoden gibt – allerdings auch noch mehr schlechte.
Hier ist auch eine gute Stelle, um auf etwas hinzuweisen, was wir in jedem unserer Bücher betonen: Nichts, was Sie in diesem Buch lesen, ist unsere eigene Erfindung. Wir schreiben lediglich darüber, was wir in den besten Product-Unternehmen beobachtet haben. Dabei beschreiben wir natürlich nicht alles, sondern nur das, was wir für die wichtigsten Themen und die Grundprinzipien halten. Wir übernehmen also sozusagen die Rolle von Kuratoren und Predigern.
Im Zusammenhang mit dem Product-Operating-Modell ist mitunter auch die Rede von Product-led Company (Product-geleitetes Unternehmen) oder Product-centric Company (Product-zentriertes Unternehmen). Diese Ausdrücke mögen wir deshalb nicht besonders, weil sie ein wenig so klingen, als übernähme die Product-Abteilung hier das Kommando.
Ähnlich verhält es sich mit dem Ausdruck Customer-driven Company (kundengesteuertes Unternehmen), der für das Product-Operating-Modell zwar zutrifft, aber durch seinen inflationären Gebrauch nahezu inhaltsleer geworden ist.
Schwieriger verhält es sich mit der Benennung des Modells, das für Ihr Unternehmen bisher gilt.
Meist wird hier die Überlegung herangezogen: Wer sitzt wirklich am Steuer?
In vielen Unternehmen hören Sie ständig, »der Geschäftsbetrieb« äußere Bitten an die IT; hier wird etwas betrieben, was als IT-Modell bezeichnet werden könnte (»die IT ist dazu da, den Geschäftsbetrieb zu unterstützen«).
Ein naher Verwandter des IT-Modells ist das Projekt-Modell, bei dem der Finanzabteilung eine besonders große Rolle zufällt, weil Finanz- und Personalausstattung typischerweise projektbezogen erfolgen.
Wenn betroffene Beteiligte im Unternehmen den Kurs bestimmen, ist oft vom Feature-Team-Modell die Rede (denn jede Gruppe von betroffenen Beteiligten achtet beim Kurs auf die ihnen selbst wichtigen Features).
Hält der Vertrieb das Steuer in der Hand, ist oft vom Sales-driven Product (vertriebsbestimmtes Product) die Rede, und gibt das Marketing den Kurs vor, vom Marketing-driven Product (marketingbestimmtes Product).
In diesem Buch werden wir, wenn wir uns auf die vorherige Situation beziehen, einfach immer vom bisherigen Modell sprechen, und die durch Transformation angestrebte neue Situation nennen wir das Product-Operating-Modell oder kurz Product-Modell.
In Teil II dieses Buchs, Definiere Transformation, finden Sie eine detaillierte Definition dessen, was es bedeutet, nach dem Product-Operating-Modell zu arbeiten.
Außerdem gibt es in diesem Buch noch weitere wichtige Product-Ausdrücke und -Konzepte; diese werden wir jeweils definieren, wenn wir ihnen begegnen.
Was ist ein Product?
Diese Frage wird häufig gestellt, und sie ist nur scheinbar einfach, denn diese Frage ist vielschichtig, und es gibt unterschiedliche Gründe, die Frage zu stellen.
Mitunter wird die Frage gestellt, weil die Fragesteller Zweifel haben, ob die Dinge, an denen sie arbeiten, überhaupt etwas Kundenorientiertes sind, etwa so, wie es eine E-Commerce-App oder ein Konsumartikel ist. Sie arbeiten also vielleicht an einem internen Tool, das von Mitarbeitern des Unternehmens genutzt wird, um sich um die zahlende Kundschaft zu kümmern. Oder vielleicht arbeiten sie an einem Plattform-Dienst, der genutzt wird, um andere Arten von Products herzustellen. Oder an einer Art Backoffice-System, das kritische Daten zur Verfügung stellt. Oder die Person konstruiert eher ein Gerät und nicht nur reine Software. Für diese Leistungen gibt es die verschiedensten Ausdrücke, aber Sie dürfen sicher sein: Bei allen handelt es sich um Products, für die das Product-Modell hilfreich ist.
Mitunter wird die Frage auch gestellt, weil den Fragestellern unklar ist, ob sie an einem vollständigen Product arbeiten oder nur am kleinen Teil eines größeren Ganzen. Das spricht ein wichtiges Thema an, das wir als Team-Topologie bezeichnen. Für unsere Zwecke wird jedenfalls auch so etwas als Product betrachtet, selbst wenn es nur der kleine Teil eines größeren Ganzen ist.
Und mitunter wird die Frage eben auch von Personen gestellt, die nicht wirklich etwas entwickeln. Es gibt sehr viele Arten von Produkten, bei denen es sich nicht um Tech-betriebene Produkte handelt, die von Entwicklern entwickelt werden. Vielleicht managen diese Fragesteller die Beziehung zu den Verkäufern einer dritten Partei und fragen sich, ob auch für sie das Product-Modell anwendbar ist. In diesem Fall lautet die Antwort allerdings nein. Beim Product-Modell geht es allein um die besonderen Herausforderungen von Personen, die Tech-betriebene Produkte und Dienstleistungen entwickeln.
3Warum transformieren?
Da Sie sich entschlossen haben, dieses Buch zu lesen, besteht eine gewisse Wahrscheinlichkeit, dass Sie bereits einige Gründe dafür sehen, eine Transformation in Angriff zu nehmen.
Aber da es hier um so viel geht und wirklich beträchtlicher Einsatz erforderlich ist, wäre eine ganz klare Formulierung Ihrer Ziele durchaus hilfreich.
Ganz allgemein haben wir festgestellt, dass Unternehmen meist durch einen oder mehrere der drei folgenden Umstände zur Transformation motiviert werden:
Konkurrenzdruck
Es gibt nur sehr wenige Branchen, die nicht bereits durch neue Konkurrenten herausgefordert worden wären, die bessere Lösungen für ihre Kunden anbieten.
Während wir dies schreiben, wird die Wettbewerbslandschaft zum Beispiel für viele Branchen gerade durch die neue disruptive Technik der generativen KI umgestaltet. Und wie es in solchen Fällen immer ist, nutzen manche Unternehmen diese neue Technik nun, um seit Langem bestehende Probleme ihrer Kunden auf eine Weise zu lösen, die erst durch diese Technik ermöglicht wird, während andere Unternehmen zurückbleiben.
Ein solcher Prozess der disruptiven Innovation hat schon in Branchen stattgefunden, die so unterschiedlich sind wie Finanzdienstleistungen, Gesundheitswesen, Einzelhandel, Automobiltechnik, Logistik, Werbung und sogar Weltraumforschung.
In manchen Branchen gibt es höhere Umbaukosten, stabilere Hürden durch staatliche Regelungen oder auch stärkeren staatlichen Schutz, wodurch eine Disruption länger dauern kann, aber kaum eine Branche kann sich wirklich sicher fühlen.
Etablierte Unternehmen bekommen den Eindruck, dass sie im Kampf um ihre Kundschaft mit Waffen und Strategien vorgehen, die einst funktioniert haben, aber jetzt mit den Mitteln und Fähigkeiten ihrer neuen Widersacher nicht mehr mithalten können.
Gewinnaussichten
Andere Unternehmen werden durch den finanziellen Lohn motiviert, der Unternehmen zufällt, die ihre Fähigkeit unter Beweis gestellt haben, stetige Innovationen zugunsten ihrer Kunden vorzunehmen.
Sie sehen die Bewertung dieser neuen Generation von Unternehmen und den Lohn, der Unternehmen nach einer erfolgreichen Transformation zufällt, und die Aussicht auf diesen Lohn motiviert Investoren, Manager, Product Leader und Mitarbeiter, den neuen Weg zu beschreiten.
Frustrierte Führungskräfte
Manche Unternehmen setzen auf das Product-Modell, weil sie frustriert sind, nachdem sie viel Geld in technologische Anstrengungen gesteckt haben, ohne dass es viel gebracht hätte.
Die ständigen Kostenüberschreitungen, die enttäuschenden Ergebnisse, der Zeitaufwand für jeden Vorgang, Kunden, die ihre Geduld verlieren, die endlosen Vorwürfe und Ausreden.
Womöglich haben die Führungskräfte gelesen, dass andere Unternehmen viel weniger Geld ausgeben, aber deutlich bessere Ergebnisse erzielen, und fragen sich nun, ob deren Methoden nicht auch für sie selbst taugen würden.
Manchmal tragen auch noch weitere Faktoren dazu bei, dass ein Unternehmen an einen Punkt gelangt, an dem seine Führungskräfte die Überzeugung gewinnen, dass sie nun den großen Sprung einer Transformation wagen müssten:
Vielleicht ist zu beobachten, dass die fähigsten Technologie-Experten das Unternehmen verlassen, weil sie frustriert von seiner Arbeitsweise sind.
Vielleicht hat das Unternehmen die Führungskraft eines starken Product-Unternehmens angeworben, die nun bei den Mitarbeitern für die neue Arbeitsweise wirbt.
Vielleicht haben sich die Kundenerwartungen verändert, und selbst wenn die Kunden noch loyal bleiben, werden doch die Klagen über das Angebot und das Tempo von Fortschritten lauter.
Was auch immer die Motivation im Einzelnen ist: Grundsätzlich entscheiden sich Unternehmen für eine Transformation, weil sie erfolgreich neue Chancen wahrnehmen möchten, die sich bieten, und weil sie ernsten Gefahren effektiv begegnen wollen, die sonst drohen.
4Eine typische Transformation
Die meisten Unternehmen, für deren Transformation wir uns engagiert haben, hatten zuvor schon mindestens einen Transformations-Versuch unternommen, bis sie erkannten, dass sie eine große Menge Zeit und Geld umsonst aufgewendet hatten.
Die folgende Geschichte ist ganz typisch. Wir haben zwar die Namen weggelassen, aber die Umstände sind völlig real. Schauen Sie doch einmal, wie viel Ihnen an dieser Story wohl bekannt vorkommt.
Das Unternehmen hatte seit seiner Gründung im Jahr 2000 den Finanztransaktionsmarkt dominiert. Es war stets ganz stark kundenorientiert gewesen und rühmte sich, immer genau das liefern zu können, was die Kundschaft wollte. Das hatte schließlich zu einer langen Liste von »Spezialangeboten« geführt, mit denen die festgestellten Bedürfnisse verschiedener individueller Kunden bedient werden sollten.
Zu Beginn führte die Konzentration auf das Ziel, alles zu tun, um mit den Kunden zu einem Abschluss zu kommen, zu echten geschäftlichen Erfolgen. Intern wie extern wurde es zum Markenzeichen des Unternehmens, dass die Kundenbedürfnisse schnell bedient wurden.
Bis das eines Tages nicht mehr der Fall war.
Denn trotz steigender Mitarbeiterzahl und einer Kultur langer Arbeitszeiten wurde die Zeit für die Bereitstellung neuer Features spürbar immer länger. Gleichzeitig gab es auf dem Markt etliche Neueinsteiger. Alle hatten dort schnell Fuß gefasst. Im Ergebnis begannen die Umsätze zu sinken, und der Marktanteil ging zurück.
Als Reaktion verfolgte das Unternehmen eine aggressive Akquisitions-Strategie und bemühte sich, schnell zusätzliche Lösungen zu erwerben und zu integrieren. Aber statt eine neue Ära der Profitabilität einzuleiten, erwiesen sich diese Zukäufe dann als problematisch und generierten keineswegs das erhoffte Einkommen.
Neustart
Der Vorstand reagierte, indem er Veränderungen direkt an der Unternehmensspitze vornahm.
Die neue CEO hatte eine beeindruckende geschäftliche Erfolgsbilanz vorzuweisen. Nachdem sie in einem weltweit tätigen Beratungsunternehmen schnell aufgestiegen und zum jüngsten Senior Partner des Unternehmens geworden war, hatte sie in zahlreichen Finanzunternehmen verschiedene Funktionen auf oberster Führungsebene bekleidet.1
Sie war jetzt zum ersten Mal CEO, und ihr war klar, dass ihre Karriere von ihren Ergebnissen bestimmt werden würde. Scheitern kam nicht infrage, und sie hatte auch ihre Hausaufgaben gemacht. Das Unternehmen hatte immer noch einen starken Marktanteil, der Markenname war anerkannt, und das Unternehmen arbeitete profitabel. Aber sie wusste, dass Veränderungen erforderlich waren – das hatte sie gegenüber dem Vorstand propagiert. Ihre Ernennung erfolgte mit dem Auftrag, die Marke wieder stark zu machen.
Das Drehbuch war gut einstudiert, sie hatte es in ihren Jahren als Management Consultant schon etliche Male in den unterschiedlichsten Sektoren durchgespielt. Sie begab sich sofort daran, die Probleme zu diagnostizieren.
Das Unternehmen war zu einer weit ausgedehnten Organisation geworden, mit Geschäftsstellen auf der ganzen Welt, von den USA über Indien bis Europa. Die daraus resultierenden kulturellen Unterschiede waren tiefgreifend.
Nach Jahren der Expansion durch Zukäufe handelte es sich im Grunde jetzt um eine Ansammlung mehrerer Unternehmen, mit fehlender Integration, schwerem technischen Rückstand und frustrierten Kunden.
Ihre alten Beziehungen ermöglichten es der CEO, rasch die Dienste einiger Beratungsunternehmen in Anspruch zu nehmen, die dabei halfen, schnell etliche wichtige überkommene Praktiken zu diagnostizieren.
Es waren tiefgreifende Veränderungen erforderlich. Dazu gehörten eine neue, zentralisierte Organisationsstruktur, das Insourcing von Engineering, eine zielgenauere geschäftliche Mission und die Schaffung einer neuen Product-Einheit, die Product Manager und Product Designer umfassen sollte. Zur Leitung der Transformationsanstrengungen wurde eine neue Chief Digital Officer (CDO) engagiert.
Reibungen und Widerstände
Zahlreiche Herausforderungen wurden gleichzeitig angegangen; nicht zuletzt und keinesfalls die unbedeutendste davon das Insourcing von Engineering. Die Aufgabe, bei knappem Marktangebot ein Team von 600 Entwicklern einzustellen, bedeutete, hohe Gehälter zu bieten; nach zwölf Monaten war das Budget überschritten, und trotzdem war die erforderliche Zahl von Neueinstellungen noch immer nicht erreicht. Aus Kostengründen entschied sich das Unternehmen nun dafür, anstelle der Einstellung qualifizierter Product Manager einfach ein Team von Business-Analysten umzubenennen. Die Überlegung dahinter war, dass das Product-System komplex sei und vertiefte Fachbereichskenntnisse erfordere.
Die Veränderungen erwiesen sich als disruptiver und kostspieliger, als das Unternehmen ursprünglich vorhergesehen hatte. Der Vertrieb, der lange als allein verantwortlich für den Erfolg bei der Kundschaft galt, war nicht glücklich über die Veränderungen und beklagte sich direkt bei der CEO. Obwohl die neue CDO positiv von der Einstellung neuer Engineering-Kompetenz und der Schaffung vielfältiger Product Teams berichtete, ging es nur langsam voran, und die Kosten stiegen immer weiter.
Wenn die Manager sie nicht hören konnten, stöhnten die neu hinzugekommenen Entwickler ungläubig über das Ausmaß des technischen Rückstands. Jedes der hinzugekauften Unternehmen arbeitete weiter nach seinem überkommenen technischen System. Es hatte keine ernsthaften Versuche gegeben, die Lösungen zu integrieren. Viele der ursprünglichen Mitarbeiter waren gegangen. Die Übriggebliebenen konnten die Systeme oft gerade mal am Laufen halten. Die Entwickler sahen keine Alternative zur sofortigen Einrichtung einer neuen Plattform.
Privat hatte die Führungsebene zwar Verständnis für die neuen Entwickler, aber wenig Lust, nun auch noch eine weitere so gewaltige Anstrengung zu unternehmen, wie es die Einrichtung einer neuen Plattform war. Man ermunterte die Entwickler, zwar umzugestalten, wo sie nur konnten, aber auch Möglichkeiten zu finden, wie man mit dem Entwicklungsplan schneller vorankommen könnte.
Nach zwei Jahren Transformation liefen die Dinge langsamer als je zuvor. Die CEO kam zu dem Schluss, dass das Hauptproblem beim Engineering liege und dort Hilfe gebraucht werde, um berechenbare und verlässliche Ergebnisse zu erreichen.
Fokus auf Berechenbarkeit
Die CIO (Chief Information Officer) empfahl den Wechsel hin zu einem neuen, formaleren und strukturierteren Vorgehen beim Erbringen der Entwicklerleistungen, und die Teams wurden für diese neue Vorgehensweise geschult in der Hoffnung, dass damit die Berechenbarkeit erhöht würde, wenn auch um den Preis, dass die Freigabe neuer Versionen nun länger dauern und weniger häufig erfolgen würde.
Aber angesichts der nun noch geringeren Zahl neuer Releases war jetzt auch ein neues Schlachtfeld eröffnet, auf dem es darum ging, welche Geschäftseinheit ausreichend Features hineinzwängen konnte, um den Druck – und die Kosten – durch unzufriedene Kunden mit Upgrades aufzufangen. Auch die laufenden Prozesskosten erhöhten sich beträchtlich.
Da nun alle Augen auf jede einzelne langwierige Freigabe neuer Versionen gerichtet waren, wurde ein Team von Programmmanagern eingestellt, die eine neue Kontrollebene bilden und den Auslieferungsprozess überwachen sollten.
Da die Kosten dadurch immer weiter stiegen, erfolgte das Release neuer Versionen immer seltener. Währenddessen gedieh die Konkurrenz prächtig. Die ursprünglichen Erfolgserwartungen des Vorstands waren inzwischen so gut wie vergessen.
Zudem hatte eine nennenswerte Zahl der gerade erst neu eingestellten Entwickler inzwischen wieder gekündigt; als Grund hatten sie Führungsversagen angeführt. Es wurde auch immer schwieriger, die Kunden zu halten, da viele von ihnen durch den offensichtlichen Mangel an Fortschritten frustriert waren.
Da sie nach ihrem Gefühl ohnehin nichts mehr zu verlieren hatten, entschlossen sich einige Product und Engineering Leader, sich direkt an die CEO zu wenden.
Sie machten geltend, die vorhandene Technologie mache es dem Unternehmen unmöglich, die Bedürfnisse der Kunden zu erfüllen, und die Bürokratie sei inzwischen so überwältigend, dass sie sich nicht mehr in der Lage sähen, irgendwo voranzukommen.
Keine der jetzt möglichen Optionen war gut. Das Technologie-Missmanagement der Vergangenheit hatte das Unternehmen eingeholt.
Die CEO fragte sich, was das Unternehmen von den Dutzenden Millionen Dollar an Transformationskosten gehabt hatte. Nach den Mühen und Ausgaben von vier Jahren und angesichts der versammelten Frustration ihrer Führungskollegen wurde die CEO informiert, dass sie nicht mehr das Vertrauen des Vorstands habe.
Die Transformation des Unternehmens war, zunächst nach und nach, dann mit aller Macht, gescheitert.
Notiz
1
Unser Bestreben ist seit Langem, die Wahrnehmung zu erweitern, wer starke Führungskraft ist. Daher verwenden wir in diesem Buch häufig das Pronomen
sie
. Wir möchten jedoch ausdrücklich betonen, dass sich dieses Buch an
jeden
Menschen richtet,
gleich welcher
Gender-Identität. Unsere Einstellung lautet: Wenn sie gute Menschen sind, denen an der gekonnten Fertigung eines Products liegt, dann hoffen wir, sie zu Freunden zu haben.
5Die Rolle des oder der CEO
Die wahrscheinlich wichtigste Lektion, die wir im Verlauf der 20 Jahre gelernt haben, in denen wir mittlerweile Unternehmen dabei helfen, sich zu transformieren und zum Product-Modell überzugehen, lautet, dass der oder die CEO eine absolut entscheidende Rolle spielt, wenn die Transformation gelingen soll.
Verstehen Sie das bitte nicht falsch. Eine CEO braucht selbst keine Erfahrung mit dem Product-Modell zu haben. Und sie muss auch nicht selbst viel Zeit auf die Transformation an sich verwenden.
Aber trotzdem ist der oder die CEO entscheidend.
Nun wird jede/r CEO natürlich sagen, dass sie/er die Transformation unterstütze.
Die meisten erkennen allerdings jedoch erst viel später im Verlauf, was das alles wirklich bedeutet.
Denn das Problem besteht darin, dass die Auswirkungen der Transformation aufs Unternehmen bei Weitem die Grenzen ihrer bisherigen Technologie-Abteilung überschreiten.
Denn die Transformation hat Auswirkungen auf Vertrieb, Marketing, Finanzen, Personalabteilung, Rechtsabteilung, Geschäftsförderung, Compliance und Produktion.
In diesem Buch werden wir genau diskutieren, wie und warum die Transformation sich auf alle diese Bereiche auswirkt. Die Sache ist nur, dass nicht alle wichtigen Führungskräfte und Beteiligten begeistert sein werden, zu der neuen Arbeitsweise überzugehen.
Die meisten werden zwar durchaus motiviert sein, ein Verfahren zumindest einmal auszuprobieren, das schließlich das Potenzial hat, für bessere Ergebnisse zu sorgen. Und viele dieser Leute werden auch erkennen, dass es sich im Lebenslauf zunehmend gut ausnimmt, wenn man gelernt hat, effektiv mit dem Product-Modell zu arbeiten.
Wichtig ist übrigens auch, zu erkennen, dass selbst die begeistertsten Beteiligten oder Manager Fragen oder ganz berechtigte Einwände haben werden, auf die sie Antworten erwarten.
Aber einige werden auch passiven Widerstand leisten, und einige wenige wahrscheinlich sogar aktiven Widerstand. Entweder weil sie ihre bisherigen Verantwortlichkeiten sichern wollen. Oder halt einfach wegen des uralten Phänomens, dass man von zwei Übeln doch lieber dasjenige wählt, das man schon kennt.
Diese problematischen Beteiligten werden letztlich alle auf die CEO zukommen und die Frage stellen, ob das denn wirklich alles wichtig und nötig sei.
Wie der legendäre Coach Bill Campbell gern sagte: »Dem Unternehmen ist wichtig, was der Führungskraft wichtig ist.«
Viel zu oft delegiert die CEO die Zuständigkeit für die Transformation an eine CIO, eine Leiterin Digitales oder eine Transformations-Leiterin. Aber diese Personen können zwar die Entscheidungen und Handlungen innerhalb ihres Bereichs beeinflussen, doch wenn die Beteiligten ihr nicht unterstehen (was selten der Fall ist), dann tritt das Problem trotzdem auf.
Als CEO könnten Sie hier zum ersten Mal die Erfahrung machen, dass eine Transformation etwas ist, das weit über den Bereich IT hinausgeht. Sollte das der Fall sein, ist es ganz wichtig, dass Sie diese neue Situation gründlich durchdenken.
Tatsächlich konzentrieren die meisten Unternehmen ihre Transformationsbemühungen zu Beginn auf die erforderlichen Veränderungen an Product, Design und Engineering. Und das ist auch richtig so, denn solange diese Fertigkeiten nicht etabliert sind, kann man mit dem Rest noch nicht anfangen.
Denn es müssen neue Kompetenzen entwickelt werden, es müssen neue Fertigkeiten und neue Prinzipien in Ihr Unternehmen eingebracht werden, und vor allem muss eine Veränderung der Unternehmenskultur erfolgen.
Aber allzu oft erkennt das Unternehmen erst, nachdem diese Veränderungen erfolgt sind, dass eine erfolgreiche Nutzung der neuen Fähigkeiten Auswirkungen aufs gesamte Unternehmen haben wird. Und wenn die CEO und die übrigen Top-Führungskräfte diese Veränderungen nicht aktiv unterstützen, kommen die Transformations-Bemühungen ins Stocken.
Um es ganz klar zu sagen: Die CEO ist als die wichtigste Predigerin für das Product-Modell zu betrachten.
Wenn Ihre CEO dazu nicht willens oder in der Lage ist, können Sie sich eine Menge Zeit, Geld und Mühe sparen, indem Sie erst einmal Ihre Bereitschaft zu diesen Veränderungen neu einschätzen.
Das Gute ist aber, dass Unternehmen, die erfolgreich nach dem Product-Modell arbeiten, die Situation für alle verbessern, nicht nur für die Product- und Engineering-Abteilung.
Die Mitarbeiter empfinden dann mehr Stolz auf die Produkte ihres Unternehmens. Die Marketing-Abteilung hat mehr zu promoten und zu positionieren. Der Vertrieb kann mehr verkaufen. Alle sehen die finanziellen Auswirkungen. Moral und Länge der Betriebszugehörigkeit der Mitarbeiter steigen.
All das soll heißen, dass es viele gute Gründe gibt, die eine aktive Hilfe und Unterstützung durch die CEO rechtfertigen.
6Ihr Wegweiser durch TRANSFORMED
Wir hoffen, dass Sie inzwischen eine gewisse Ahnung davon entwickelt haben, was wir wohl meinen könnten, wenn wir sagen, dass eine Transformation ein schwieriges Vorhaben ist.
Dieses Buch soll Sie darauf vorbereiten, was da alles auf Sie zukommt.
Was Sie in diesem Buch nicht finden werden, sind allerdings Rezepte oder Drehbücher für eine Transformation. Auch wenn viele Menschen Ihnen so etwas werden verkaufen wollen – wir haben leider noch nie gesehen, dass eine solche einfache, für alle Fälle passende Einheitslösung auch tatsächlich funktioniert hätte.
Ins Buch eingestreut sind Transformations-Storys – Fallstudien von erfolgreichen Transformationen – sowie Innovations-Storys – Fallstudien von innovativen Lösungen, die von zuvor transformierten Unternehmen entwickelt wurden.
Die Transformations-Storys sollen Ihnen die Zuversicht vermitteln, dass bei aller Schwierigkeit Erfolg absolut möglich ist. Diese Geschichten werden Ihnen jeweils von der Person berichtet, die bei diesen Unternehmen die Product-Einheit geleitet hat.
Und die Innovations-Storys sollen Ihnen den Mund wässrig machen für all das, was Sie erreichen können, wenn Sie die Transformation erst einmal geschafft haben.
Abgesehen von den Fallstudien ist das Buch in folgende Teile gegliedert:
Wir beginnen im gleich anschließenden Teil II, Definiere Transformation, mit einer umfassenden Definition dessen, was mit einer Transformation hin zum Product-Operating-Modell tatsächlich gemeint ist.
Die nächsten beiden Teile stoßen dann zum Kern der neuen Kenntnisse und Fähigkeiten vor, die Sie entwickeln müssen, wenn Sie zum Product-Modell übergehen wollen.
Wir beginnen in Teil III mit der Diskussion der neuen Product-Modell-Kompetenzen, die Sie entwickeln müssen, wenn Sie eine Transformation durchführen wollen. Wenn Sie der Meinung sind, Sie hätten diese Kompetenzen in Ihrem Unternehmen bereits, werden Sie damit fast sicher falsch liegen und auf ein Scheitern Ihrer Transformation zusteuern. Lassen Sie sich auch nicht täuschen, wenn Leute sich solche Titel einfach zugelegt haben.
Im Teil IV präsentieren wir dann die Product-Modell-Konzepte – und die Product-Modell-Prinzipien, auf denen sie beruhen –, die für das Product-Modell grundlegend sind. Die meisten Unternehmen erkennen sehr schnell, dass sie diese Fertigkeiten nicht haben, und das ist auch schon der erste Schritt, um sie zu erlernen.
Die neuen Product-Modell-Kompetenzen und die Product-Modell-Konzepte sind die Grundlagen, auf denen die Transformation ruht.
In Teil VI, Das Product-Modell in Aktion, besprechen wir, wie die Product-Abteilung konstruktiv und effektiv mit Kunden, Vertrieb, Product Marketing, Finanzabteilung, Interessengruppen und leitenden Managern partnerschaftlich zusammenarbeitet.
Als Nächstes besprechen wir in Teil VIII die Transformations-Techniken, die hilfreich sind, um Ihr Unternehmen durch eine Veränderung dieser Größenordnung hindurch zu navigieren. Veränderungen sind immer schwierig, aber es gibt einige wichtige Techniken und Taktiken, die eine Transformation erleichtern. Wir beginnen mit einer Einschätzung des Unternehmens, anschließend beschreiben wir eine Reihe von Taktiken. Wir betonen hier auch, wie wichtig ständige Überzeugungsarbeit zugunsten der Transformation ist.
Sie haben vielleicht schon gemerkt, dass hier eine Art Zwickmühle vorliegt. Denn wie soll denn ein Unternehmen, das noch nie auf eine neue Art und Weise gearbeitet hat und womöglich auch keine Führungskräfte besitzt, die schon auf diese Art und Weise gearbeitet haben, diese neue Arbeitsweise lernen?
Bücher und Kurse können hier durchaus weiterhelfen (sofern die Autoren und Kursleiter wissen, wovon sie reden), reichen aber selten aus. Deshalb untersuchen wir hier ganz gründlich die Frage, wie Sie zu dem neuen Modell übergehen können, wenn Ihre Führungskräfte noch nie auf diese Art und Weise gearbeitet haben.
Als Nächstes besprechen wir in Teil X, Einwänden begegnen, die verschiedenen Bedenken, die gemeinhin bei den wichtigsten Beteiligten entstehen – Kunden und Branche, Vertrieb, Kundenbetreuung, Marketing, Finanzabteilung, Personalabteilung, CIO, PMO, CEO und Vorstand – und auch die Einwände, die aus der Product-Einheit selbst kommen.
Es handelt sich grundsätzlich um legitime Einwände und Bedenken, denn sie werden normalerweise in bester Absicht erhoben, weil die Menschen ein Problem sehen und einfach noch nicht wissen, wie mit diesem Problem umgegangen werden soll. Wir sehen uns alle diese Einwände im Einzelnen an und besprechen dann, wie sie sich überwinden lassen.
Im Teil XI, dem Fazit, versuchen wir Zusammenhänge herzustellen und die entscheidenden Punkte zusammenzufassen, die wir in diesem Buch besprochen haben, einschließlich der Themen, die alle Transformations-Fallstudien verbinden, und einschließlich der Schlüssel zum Erfolg.
Eine gut gemeinte Ermahnung an Product Leader
Es ist schwer, eine Transformation mit Erfolg durchzuführen, und oft müssen schwierige Themen angeschnitten werden, von denen die Beteiligten lieber nichts hören wollen.
In diesem Sinne wollen wir hier an alle Product Leader eine gut gemeinte Ermahnung richten.1
Es steht außer Frage, dass die Top-Führungskräfte des Unternehmens eine Hauptrolle bei der Unterstützung der Transformationsbemühungen eines Unternehmens zu spielen haben.
Viele Product Leader sind jedoch überrascht, dass auf sie hier mindestens genauso viel Arbeit zukommt.
Es ist wirklich verblüffend, wie viele Product Leader glauben, wenn erst einmal die Top-Führungskräfte ihr Verhalten geändert hätten, wäre alles gut. Das heißt, sie konzentrieren ihre Energie darauf, andere zu ändern statt sich selbst.
Sie beklagen sich, sie hätten schwache Product Manager.
Sie beklagen sich, sie würden nicht zu eigenverantwortlichem Handeln ermächtigt.
Sie beklagen sich, ihre Entwickler seien nicht engagiert genug.
Sie beklagen sich, die betroffenen Beteiligten im Unternehmen vertrauten ihnen nicht.
Sie beklagen sich, weil CEOs detaillierte Product-Fahrpläne verlangen.
Dabei scheinen sie aber nicht zu erkennen, dass alle diese Probleme zum großen Teil die Folge ihres eigenen Handelns (bzw. Nichthandelns) sind.
Wenn Product Leader nicht bereit sind, die Verantwortung dafür zu übernehmen, dass das Qualifikationsniveau der eigenen Product-Leute gesteigert wird oder dass Fehler bei der Personaleinstellung korrigiert werden, dann sind die Product Teams eben mit Leuten besetzt, denen die erforderliche Kompetenz fehlt.
Und wenn das der Fall ist, wer kann sich dann wundern, wenn die Teams nicht zu eigenverantwortlichem Handeln ermächtigt werden?
Wer kann sich dann wundern, wenn die Entwickler wie bezahlte Söldner auftreten?
Wer kann sich dann wundern, wenn die Beteiligten den Product Managern nicht vertrauen?
Wer kann sich dann wundern, wenn die CEO den Menschen nicht vertraut, die für derart schwache Product-Leute verantwortlich sind?
Allgemein gesagt gibt es also zwei wichtige Dinge, die Sie als Product Leader im Kopf behalten müssen, wenn Sie sich an eine Transformation begeben: Erstens wird das Maß an Eigenverantwortung, das Ihnen eingeräumt wird, genau Ihrer Glaubwürdigkeit entsprechen; und zweitens gehört es zu Ihrem Job als Product Leader, auch Herzen und Köpfe zu gewinnen.
Es trifft zwar zu, dass sich bei den Top-Führungskräften eine Menge ändern muss, wenn sie zum Product-Modell übergehen, aber bei Product Leadern und Product Teams sind noch stärkere Veränderungen erforderlich.
Wir wollen hier ganz klar machen, dass Änderungen zwar auf allen Seiten erforderlich sind, dass es zu Erfolg aber erst kommt, wenn zuerst die Product-Einheit ihren Einsatz erhöht.
Notiz
1
Um für Klarheit bei unseren Bezeichnungen zu sorgen: Bei Product Managern, Product Designern, Tech Leads und allen anderen Entwicklern, Datenwissenschaftlern und Nutzerforschern handelt es sich jeweils um
Einzelpersonen,
die ihre Beiträge leisten. Der Ausdruck »Product Leader« bezieht sich auf die
Vorgesetzten
von Product Management, Product Design und Engineering. Der Ausdruck »leitende Manager« bezieht sich auf die
Top-Führungskräfte
des Unternehmens – CEO, CFO, COO, CMO, CRO usw.
Teil IIDEFINIERE TRANSFORMATION
Es gibt sehr, sehr viele ungeeignete Lösungsansätze (sogenannte Anti-Patterns), wenn es um Transformationen geht.
Viele von uns haben schon das Scheitern von Transformationen erlebt, aber nur wenige haben wirklich erfolgreiche Transformationen gesehen. Und das macht die Lehren, die aus erfolgreichen Transformationen gezogen werden können, so außerordentlich wertvoll.
Eine Frage, die wir recht häufig hören, lautet: »Was kann unser Unternehmen denn nach einer Transaktion, was wir vorher nicht konnten?«
Da wir in der Product-Welt sehr viel von Ergebnissen und Resultaten reden, halten wir das für die genau richtige Frage.
Und daher betont dieses Buch auch, welche Fähigkeiten und Ergebnisse Unternehmen erreichen können, die sich transformiert haben, und betrachtet dabei insbesondere ihre Fähigkeit, auf Bedrohungen zu reagieren und neue Chancen zu ergreifen.
Aber auch wenn wir davon ausgehen, dass die Führungskräfte eines Unternehmens wirklich überzeugt sind, dass sie eine Transformation brauchen: Was heißt das denn genau?
Viele von Ihnen haben sicher schon einmal Aussagen gehört wie: »Mag sein, dass eine Transformation hin zu mehr Agility notwendig ist, aber das ist auf keinen Fall ausreichend.«
Oder: »Das Herzstück einer Transformation ist der Übergang von Feature Teams zu eigenverantwortlich arbeitenden Product Teams.«
Oder: »Ziel ist die Transformation hin zu einem Product-gesteuerten Unternehmen.«
Alle diese Aussagen geben jeweils einen speziellen Aspekt von Transformationen wieder, aber keine liefert ein gutes, ganzheitliches Bild davon, was mit Transformation wirklich gemeint ist.
Wir wählen in diesem Buch daher ein anderes Vorgehen.
Statt Etiketten aufzukleben (wie »Agility«, »eigenverantwortlich arbeitendes Team« oder »Product-gesteuertes Unternehmen«), halten wir es für sinnvoller, darauf zu schauen, was tatsächlich anders wird.
Wir betrachten es in diesem Buch als Kennzeichen des Product-Modells, dass Sie in drei verschiedenen Dimensionen etwas ändern:
Ändern, wie Sie entwickeln,
Ändern, wie Sie Probleme lösen,
Ändern, wie Sie entscheiden, welche Probleme zu lösen sind.
Ändern, wie Sie entwickeln
Obwohl Agility nun schon so lange ein Thema ist, halten viel zu viele Unternehmen immer noch an monatlichen oder vierteljährlichen Software-Freigaben (Releases) fest oder sogar (schlimmer noch) an Großveröffentlichungen auf einen Schlag (Big Bang Releases).
Das Aufkommen sogenannter Fake Agility1 verleitet diese Unternehmen zu dem Irrglauben, sie arbeiteten bereits so, wie es nötig wäre, obwohl sie die Art und Weise, wie sie entwickeln, in keiner nennenswerten Hinsicht verbessert haben.
Was unser Unternehmen und unsere Kunden wirklich von uns brauchen, ist aber ein verlässlicher Service, auf den sie vertrauen können.
Und das bedeutet häufige, kleine Releases. Das bedeutet, die Technik so zu instrumentieren, dass Sie wissen, ob sie funktioniert und wie sie genutzt wird. Das bedeutet, dass Sie Ihre Technik so überwachen, dass Sie eventuelle Probleme hoffentlich schon vor Ihren Kunden entdecken. Und es bedeutet, beweisen zu können, dass neue Features auch den nötigen Wert liefern, bevor Sie diese auf breiter Front einsetzen.
Und wenn Sie schon keine kontinuierlichen Auslieferungen vornehmen, dann muss der Zeitabstand zwischen echten Releases2 aber allermindestens unter zwei Wochen liegen.
Ändern, wie Sie Probleme lösen
Wenn davon die Rede ist, dass ein Unternehmen von Feature Teams zu eigenverantwortlich arbeitenden (empowered) Product Teams übergeht, heißt das im Wesentlichen, dass die Art und Weise geändert werden soll, wie Probleme gelöst werden.
Statt dass betroffene Beteiligte im Unternehmen Lösungen vorgeben, die sie für prioritär halten (Features bzw. Merkmale und Projekte), und diese dann in Form eines Fahrplans oder einer Roadmap einem Feature Team übertragen, werden einem Product Team nun Probleme überantwortet, die zu lösen sind, und das Product Team wird ermächtigt (empowered), eine Lösung zu finden, die werthaltig, brauchbar, machbar und tragfähig ist.
Worum es geht, ist, dass die Entscheidung über die optimale Lösung hier denjenigen überantwortet wird, die am nächsten dran sind an der Technik, welche die Lösungen ermöglicht, und den Kunden, die mit dieser Technik interagieren.
In der Praxis heißt das: Es muss zum einen dafür gesorgt werden, dass die Fähigkeit entwickelt wird, Product-Ideen schnell zu testen, um eine Lösung zu entdecken, die es wert ist, entwickelt zu werden (man spricht hier von Product-Erkundung oder Product Discovery), zum anderen dafür, dass Ihre Entwickler und Product Designer echte Product Manager haben (die sich mit Kunden, Daten, Geschäft und Branche auskennen), damit das Product Team die für einen Erfolg benötigten funktionsübergreifenden Fertigkeiten bekommt.
Es ist wichtig, ausdrücklich darauf hinzuweisen, dass eine solche Veränderung ein neues Verhältnis zu den betroffenen Beteiligten im Unternehmen mit sich bringt – ein Verhältnis, in dem das Product Team statt einer dienenden eine kooperative Rolle bekommt und in dem das Product Team eine Lösung entdecken muss, die einerseits den Kunden gefällt, andererseits aber auch fürs Geschäft funktioniert.
Ändern, wie Sie entscheiden, welche Probleme zu lösen sind
Die Entwicklung von Kompetenz bei der Entdeckung geeigneter Products, mit der Ihre Teams konsequent und schnell schwierige Probleme so lösen können, dass es Ihren Kunden gefällt und dabei auch für Ihr Geschäft funktioniert, ist nach jeder Definition ein großer Schritt nach vorn. Damit wird allerdings noch nicht die Frage angesprochen: »Wie sind Sie denn zu der Entscheidung gelangt, dass dies das wichtigste zu lösende Problem ist?«
In den bisherigen Modellen trafen für gewöhnlich die betroffenen Beteiligten im Unternehmen die Entscheidung, welche Probleme zu lösen sind. Im Product-Modell ist die Aufgabe Product Leadership eine entscheidend wichtige neue Kompetenz.
Jedes Unternehmen sieht sich zahlreichen Bedrohungen, aber auch vielen Chancen gegenüber. Die Entscheidung, welche Bedrohungen Sie ernst nehmen und welche Chancen Sie ergreifen, kann den Unterschied zwischen Erfolg und Scheitern ausmachen.
Ein starkes Product-Unternehmen hat eine überzeugende Product-Vision und eine auf Erkenntnissen basierende Product-Strategie, mit denen es die entscheidenden Probleme erkennt, die gelöst werden müssen, damit die geschäftlichen Ziele bedient werden.
***
Hier noch ein paar wichtige Hinweise:
Erstens: Alle drei Dimensionen – Ändern, wie Sie entwickeln, wie Sie Probleme lösen, wie Sie entscheiden, welche Probleme zu lösen sind – erfordern starke Product Leader (Führungskräfte von Product Management, Product Design und Engineering), und wir hoffen, Sie bekommen allmählich ein Gefühl dafür, warum Product Leadership so schwierig ist. Die Mitglieder der Product Teams benötigen Coaching und strategischen Kontext.
Zweitens: Auf einer höheren Ebene können Sie die drei genannten Dimensionen als drei aufeinander folgende Schritte betrachten, und so ließe sich die Transformation eines Unternehmens auch in der Tat angehen. Aber in der Realität stellt jede der drei Dimensionen ein breites Spektrum dar, und Sie können und sollten Fortschritte in den drei verschiedenen Dimensionen parallel erreichen. Viel mehr dazu in Teil VIII, Transformations-Techniken.
***
Um alles noch einmal zusammenzufassen:
Ändern, wie Sie entwickeln und bereitstellen, heißt überzugehen von großen, vierteljährlichen Software-Veröffentlichungen hin zu einer Abfolge kleiner, stetiger, häufiger Releases. Diese Veränderung ist der Lösungsschlüssel, mit dem sich der Zeitraum stetig optimieren lässt, der bis zu einer Markteinführung vergeht (Time to Market).
Ändern, wie Sie Probleme lösen, heißt überzugehen von Fahrplänen bzw. Roadmaps, die von den betroffenen Beteiligten im Unternehmen vorgegeben werden – und von den entsprechenden Feature Teams – hin zu eigenverantwortlich arbeitenden (empowered) Product Teams, denen die Probleme zur Lösung vorgelegt werden und die dann durch die Erkundung geeigneter Verfahren (Product Discovery) zu Lösungen gelangen, die werthaltig, brauchbar, machbar und tragfähig sind. Bei diesen Lösungen sind sowohl die Kunden als auch das eigene Geschäft im Blick zu behalten. Diese Veränderung ist der Lösungsschlüssel, mit dem sich der Zeitraum stetig optimieren lässt, der vergeht, bis Geld verdient wird (Time to Money).
Ändern, wie Sie entscheiden, welche Probleme zu lösen sind, das ist normalerweise die tiefgreifendste Veränderung von allen, da hier darüber bestimmt wird, welche Chancen Sie wahrnehmen wollen und wie Sie aus Ihren Investitionen das Meiste herausholen, wozu auch Product-Vision und Product-Strategie gehören. Diese Veränderung ist der Lösungsschlüssel, mit dem sich der Ertrag Ihrer Technology-Investitionen maximieren lässt.
Wir hoffen, dieser gedankliche Rahmen kann Ihnen zu einem ganzheitlicheren Nachdenken über die Transformation verhelfen, die Ihr Unternehmen möglicherweise braucht, und auch über die Station, die Sie auf dieser Reise wohl bereits erreicht haben.
In den folgenden drei Kapiteln werden wir in jede der drei Dimensionen tiefer einsteigen und erklären, warum diese Änderungen für starke Product-Unternehmen so wichtig sind.
Auch wenn diese Konzepte ein wenig technisch klingen mögen: Um die Bedeutung – und den Wert – für Ihr Geschäft und Ihre Kunden zu verstehen, ist kein tieferes technisches Verständnis erforderlich.
Anmerkungen
1
Das krasseste Beispiel für »Fake Agility« ist das Verfahren SAFe; aber auch Teams, die auf Scrum in seiner einfachsten Form setzen und dennoch nur monatlich oder vierteljährlich Releases vornehmen, lassen sich die wahren Vorteile von Agility entgehen.
2
Was
echte Releases
bedeutet, unterscheidet sich je nach Product, aber für unsere Zwecke heißt es, dass ein Zustand erreicht ist, in dem man die neuen Features mit Erfolg den Kunden an die Hand geben kann.
7Ändern, wie Sie entwickeln
Bei Ihren Investitionen in Technologie geht es immer darum, Werte für Ihre Kunden und Kundinnen und für Ihr Unternehmen zu schaffen.
Zu dieser Wertschöpfung tragen etliche wichtige Aspekte bei, aber am Ende des Tages hängt es in erster Linie vom Können Ihrer Entwickler ab, wie Ihr Product entwickelt wird.
Für viele Tech-betriebene Unternehmen stellen die Entwickler den größten Kostenfaktor dar.
In den meisten bisherigen Modellen werden Tech-Bemühungen typischerweise als Projekte geführt.
Projekte werden finanziert, mit Personal ausgestattet, geplant, ausgeführt und abgeliefert. Mit der Ablieferung endet das Projekt, und die Leute wenden sich anderen Arbeiten zu.
Machen Sie sich aber klar, dass alles, was wir entwickeln, zu zwei Arten von Ergebnissen führt: dem, was wir herstellen, und dem, was wir dabei lernen. Im Projekt-Modell nun geht das Meiste von dem, was wir gelernt haben, am Ende wieder verloren.
Falls und wenn wir also erneut auf diesem Gebiet arbeiten wollen, wenden wir Zeit und Geld auf, um ein weiteres Mal zu lernen, wofür wir schon einmal bezahlt haben. Wahrscheinlicher ist es sogar, dass wir es erst einmal nicht lernen, sondern kostspielige Fehler machen.
Außerdem behandeln Teams, die in dem Code auch leben müssen, den sie entwickeln, diesen anders als Teams, die wissen, dass sie ihn am Ende des Projekts wieder verlassen werden. Das ist auch der Grund, warum im Projekt-Modell technische Rückstände derart grassieren.
Es ist der gleiche Unterschied, wie wenn Sie ein Haus renovieren, um es zu verkaufen oder um darin zu wohnen. Im ersteren Falle ist es schneller und billiger, die Tapeten einfach zu überstreichen, denn wenn die Farbe später abblättert, was kümmert Sie das dann noch?
Es ist kein Zufall, dass dies auch dem Vorgehen entspricht, wie Outsourcing betrieben wird. Wir sagen oft: Wenn das die Art und Weise ist, wie Sie arbeiten wollen, dann können Sie auch gleich ein Consulting-Unternehmen wie Accenture beauftragen, denn in solchen Arbeiten sind die besser, als Sie es je sein werden.
Für das Product-Modell ist diese Arbeitsweise jedoch viel zu zeit- und geldaufwendig, und, was noch wichtiger ist, sie liefert auch fast nie die Innovationen, die Ihre Kunden und Ihr Unternehmen brauchen.
Das ist also der Grund, warum Sie für eine Transformation als Erstes die Art und Weise ändern müssen, wie Sie entwickeln. Und das heißt, Sie müssen den Fokus statt auf Projekte jetzt auf Products richten.
Denn im Product-Modell werden die Products als fortlaufende Bemühungen gemanagt – bei denen jede Woche Verbesserungen zu sehen sind (in starken Product-Unternehmen sogar mehrmals täglich), und das normalerweise über mehrere Jahre.
Sie können die Arbeit dieser Teams dahingehend ändern, dass sie, statt neue Features hinzuzufügen, nun zusätzliche Einnahmen generieren oder die Betriebskosten reduzieren oder sonst etwas tun, was das Unternehmen braucht. Aber im Allgemeinen investiert das Team so lange immer weiter in sein Product, bis das Unternehmen beschließt, nicht noch mehr zu investieren und nur die laufenden Einnahmen zu halten oder aber das Product ganz auslaufen zu lassen.
In diesem Modell einer kontinuierlichen Entwicklung brauchen Sie Instrumente für kleine, häufige, zuverlässige Software-Releases.
Starke Product-Unternehmen haben es schon vor vielen Jahren gelernt: Auch wenn es der Intuition zuwiderlaufen mag, zeigen die Daten ganz klar, dass je mehr Sie entwickeln und je mehr Änderungen Sie ausliefern, desto besser ist es für Sie selbst – und besonders auch für Ihre Kunden –, Software häufiger zu veröffentlichen als seltener.1
Wenn Ihnen ein verlässlicher Service für Ihre Kunden wirklich wichtig ist, dann ist es viel einfacher, dafür zu sorgen, dass eine kleine Anzahl von Veränderungen anständig funktioniert und nicht zu unbeabsichtigten Problemen führt, als eine große Zahl von Veränderungen zusammenzufassen und alle auf einmal auszuliefern (was in der Branche auch als Big Bang Release bezeichnet wird).
Nur um diesen Punkt ganz klar zu machen: Wenn Ihre Product Teams nicht zumindest einmal alle zwei Wochen Änderungen freigeben, können Sie für Ihre Kunden nicht so sorgen, wie es erforderlich wäre.2
Darüber hinaus müssen Sie bei allem, was Sie bereitstellen, für eine Instrumentierung der neuen Features sorgen, die sicherstellt, dass Sie wissen, ob das Product anständig funktioniert, und dass Sie erkennen, wie Ihre Kunden das Product tatsächlich nutzen. Sie müssen Ihr Product außerdem kontinuierlich überwachen, damit Sie mögliche Probleme erkennen, und das hoffentlich, bevor es Ihre Kunden tun. Bei vielen bedeutsamen Veränderungen müssen Sie zudem belegen können, dass das neue Feature auch den nötigen Wert liefert, bevor Sie dieses auf breiter Front zum Einsatz bringen (standardmäßig erfolgt das durch einen A/B-Test).
Womöglich meinen Sie jetzt, dass dies alles für Ihre Art von Product nicht gelte, oder Sie möchten geltend machen, dass Ihre Kunden Sie zu weniger häufigen, nicht zu mehr Releases drängen. Im 18. Kapitel, »Product-Auslieferung«, werden wir Ihnen die Gründe auseinandersetzen, warum das sowohl für Sie als auch für Ihre Kunden wichtig ist, werden Ihnen die Prinzipien darlegen, die zu dieser Arbeitsweise führen, und die Mechanismen schildern, die dafür verwendet werden.
