Inspired E-Book

Marty Cagan

• Herausgeber: Wiley-VCH GmbH
• Kategorie: Fachliteratur
• Sprache: Deutsch

Seitenzahl: 381

Veröffentlichungsjahr: 2022

Beschreibung

Vollständig überarbeitete Neuauflage!

Wie definieren, designen und entwickeln die heute erfolgreichsten Technologie-Firmen - Amazon, Google, Facebook, Netflix, Tesla - Produkte, die buchstäblich von Milliarden Kunden weltweit geliebt werden? Überraschenderweise geschieht das dort vielleicht komplett anders als bei der großen Mehrheit der Technologie-Unternehmen.
In "Inspiriert" liefert der Vordenker im Bereich Technologie-Produktmanagement, Marty Cagan, einen Meisterkurs darüber, wie zum einen eine erfolgreiche und effektive Produkt-Organisation strukturiert und mit dem richtigen Personal versehen werden kann; und wie zum anderen technologische Produkte entdeckt und an Kunden geliefert werden können, die diese lieben.
Themen, die in den einzelnen Abschnitten behandelt werden, sind:
- Zusammenstellung der richtigen Leute und Fähigkeiten,
- Schaffen eines effektiven und dennoch "leichtgewichtigen" Prozesses,
- Skalierung der Produktorganisation und -gestaltung,
- Entwicklung einer starken Produktkultur.

Egal, ob die Leser in einem Start-up arbeiten und ein neues Produkt zur Marktreife entwickeln wollen, oder in einem wachsenden Unternehmen, dessen Organisation angepasst werden soll, oder aber ob sie in einer alteingesessenen Firma tätig sind, die versucht, ihre Fähigkeit wiederzugewinnen, dem Kunden ständig neuen Nutzen zu bieten - "Inspiriert" wird sie und ihre Organisation auf das nächste Level der Kundenbeziehung, Innovation und des Business-Erfolgs bringen.
Das Buch ist gefüllt mit zahlreichen persönlichen Geschichten des Autors und Profilen der aktuell erfolgreichsten Produktmanager und Technologie-Unternehmen, wie z. B. Adobe, Apple, BBC, Google, Microsoft und Netflix.

Leseprobe

Das englische Original erschien 2018 unter dem Titel Inspired. How to create tech producs customers love bei John Wiley & Sons, Inc., Hoboken, Newe Jersey

Copyright © 2018 by Wiley.

All rights reserved. This translation published under license with the original publisher John Wiley & Sons, Inc.

Alle 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

© 2022 Wiley-VCH GmbH, Boschstr. 12, 69469 Weinheim, Germany

Alle Rechte, insbesondere die der Übersetzung in andere Sprachen, vorbehalten. Kein Teil dieses Buches darf ohne schriftliche Genehmigung des Verlages in irgendeiner Form – durch Fotokopie, 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 Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über <http://dnb.d-nb.de> abrufbar.

Umschlaggestaltung: Susan Bauer, MannheimProjektmanagement und Lektorat: boos for books, Evelyn Boos-Körner, Schondorf am AmmerseeFachkorrektur und Lektorat der Neuauflage: Luitgard Köster

Print ISBN: 978-3-527-51105-1ePub ISBN: 978-3-527-83953-7

Dieses Buch ist meinem Vater Carl Cagan gewidmet. Im Jahr 1969 erhielt er den ersten PhD in Computerwissenschaften in den Vereinigten Staaten (zuvor waren die Computerwissenschaften Teil des Studiengangs Elektrotechnik gewesen) und er verfasste das erste Buch über Datenbanken (Data Management Systems, 1973, John Wiley & Sons).

Er war nicht nur ein wunderbarer Vater, sondern brachte mir auch bei, einen Computer zu programmieren, als ich neun war – Jahrzehnte bevor das in Mode kam –, und weckte in mir eine Liebe zur Technologie, als so viele der Technologien, auf die wir uns heute verlassen, gerade erst entwickelt wurden.

Inhaltsverzeichnis

Cover

Titelblatt

Impressum

Vorwort zur deutschen Ausgabe

Vorwort zur zweiten Auflage

Teil I: LEKTIONEN VON FÜHRENDEN TECHNOLOGIEUNTERNEHMEN

1 Hinter jedem großartigen Produkt

2 Technologiegetriebene Produkte und Dienstleistungen

3 Start-ups: Product/Market-Fit

4 Wachstumsunternehmen: Skalieren zum Erfolg

5 Reife Unternehmen: dauerhafte Produktinnovation

6 Die Grundursachen gescheiterter Produktvorhaben

7 Jenseits von Lean und Agile

8 Die Hauptkonzepte

Holistisches Produkt

Continuous Discovery und Delivery

Product Discovery

Prototyping

Product Delivery

Produkte und Product/Market-Fit

Product Vision

Teil II: DIE RICHTIGEN LEUTE

PRODUKTTEAMS

9 Die Grundsätze starker Produktteams

Ein Team aus Missionaren

Teamzusammensetzung

Teamkompetenzen und Zuständigkeit

Teamgröße

Die Hierarchiestruktur im Team

Teamzusammenarbeit

Teamstandort

Zuständigkeitsbereich des Teams

Langfristige Teambildung

Teamautonomie

Warum es funktioniert

10 Product Manager

Die wichtigsten Verantwortlichkeiten

Fundierte Kundenkenntnis

Fundierte Datenkenntnis

Fundierte Geschäftskenntnis

Fundierte Markt- und Branchenkenntnis

Klug, kreativ und beharrlich

Profile von Product Managern

11 Product Designer

Product Discovery

Holistisches User Experience Design

Prototyping

User Testing

Interaction und Visual Design

Das Fehlen von Product Design

12 Engineers

13 Product Marketing Manager

14 Die unterstützenden Positionen

User Researcher

Data Analyst

Test Automation Engineer

15 Profil: Jane Manning von Google

PEOPLE @ SCALE

16 Leadership

Leadership im Product Management

Leadership im Product Design

Technologie-Leadership

Leadership bei einer holistischen Betrachtungsweise

17 Head of Product

Kompetenzen

18 Head of Technology

Organisation

Führung

Delivery

Architektur

Discovery

Evangelism

19 Delivery Manager

20 Prinzipien der Strukturierung von Produktteams

21 Profil: Lea Hickman von Adobe

Teil III: DAS RICHTIGE PRODUKT

PRODUCT ROADMAPS

22 Die Schwierigkeiten mit Product Roadmaps

23 Die Alternative zu Roadmaps

PRODUCT VISION

24 Product Vision und Product Strategy

Product Vision

Product Strategy

25 Prinzipien der Product Vision

26 Prinzipien der Product Strategy

27 Produktprinzipien

PRODUCT OBJECTIVES

28 Die OKR-Technik

29 Objectives des Produktteams

PRODUCT @ SCALE

30 Product Objectives @ Scale

31 Product Evangelism

32 Profil: Alex Pressland von der BBC

Teil IV: DER RICHTIGE PROZESS

PRODUCT DISCOVERY

33 Prinzipien der Product Discovery

34 Überblick Discovery-Techniken

Framing-Techniken

Planning-Techniken

Ideation-Techniken

Prototyping-Techniken

Testing-Techniken

Feasibility Testing

Usability Testing

Value Testing

Business Viability Testing

Transformationstechniken

FRAMING-TECHNIKEN

35 Opportunity Assessment

Business Objective

Key Results

Customer Problem

Target Market

36 Customer Letter

37 Start-up Canvas

PLANNING-TECHNIKEN

38 Story Maps

39 Customer Discovery Program

Die Macht des Referenzkunden

Einen einzigen Target Market fokussieren

Potenzielle Referenzkunden anwerben

Die Beziehung

Plattform-/Schnittstellenprodukte

Customer Enablement Tools

Verbraucherprodukte

Zusammenfassung

40 Profil: Martina Lauchengco von Microsoft

IDEATION-TECHNIKEN

41 Customer Interviews

42 Concierge-Test

43 Die Stärke des Kundenfehlverhaltens

44 Hack Days

PROTOTYPING-TECHNIKEN

45 Prinzipien von Prototypen

46 Feasibility Prototyping

47 Nutzerprototypen

48 Live Data Prototyping

49 Hybrid Prototyping

TESTING-TECHNIKEN

50 Usability Testing

Anwender für Tests gewinnen

Den Test vorbereiten

Ihren Prototyp testen

Die Lernergebnisse zusammenfassen

51 Value Testing

Die Nachfrage testen

Qualitatives Value Testing

Quantitatives Value Testing

52 Demand Testing (Bedarfsermittlung)

53 Qualitatives Value Testing

Interview zuerst

Usability Test

Spezifische Value Tests

Iteration des Prototyps

54 Quantitatives Value Testing

A/B-Tests

Invite-only Testing

Customer Discovery Program

55 Feasibility Testing

56 Business Viability Testing

57 Profil: Kate Arnold von Netflix

TRANSFORMATIONSTECHNIKEN

58 Discovery Sprint

59 Pilotteams

60 Eine Organisation von Roadmaps entwöhnen

PROCESS @ SCALE

61 Der Umgang mit Stakeholdern

Die Definition von Stakeholdern

Die Verantwortlichkeiten des Product Manager

Erfolgsstrategien

62 Produkterkenntnisse kommunizieren

63 Profil: Camille Hearst von Apple

Teil V: DIE RICHTIGE KULTUR

64 Gute Produktteams, schlechte Produktteams

65 Die wichtigsten Gründe für Innovationsverlust

66 Die Hauptgründe für Geschwindigkeitsverlust

67 Eine starke Produktkultur etablieren

Danksagung

Über den Autor

Weitere Informationen

Stichwortverzeichnis

End User License Agreement

Illustrationsverzeichnis

Kapitel 6

Abbildung 6.1: Grundursachen gescheiterter Produktvorhaben

Kapitel 8

Abbildung 8.1: Continuous Discovery und Delivery

Orientierungspunkte

Cover

Titelblatt

Impressum

Inhaltsverzeichnis

Vorwort zur deutschen Ausgabe

Vorwort zur zweiten Auflage

Fangen Sie an zu lesen

Danksagung

Über den Autor

Weitere Informationen

Stichwortverzeichnis

End User License Agreement

Seitenliste

3

4

5

11

13

14

15

16

17

19

21

23

25

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

43

44

45

46

47

48

49

50

51

53

54

55

56

57

58

59

60

61

63

64

65

66

67

69

70

71

73

74

75

76

77

79

80

81

83

84

85

87

88

89

90

91

92

93

94

95

97

99

100

101

102

103

104

105

107

108

109

111

112

113

115

116

117

118

119

120

121

123

124

125

126

127

128

129

131

132

133

135

136

137

138

139

140

141

142

143

144

145

146

147

148

149

150

151

152

153

154

155

156

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

183

184

185

187

188

189

190

191

193

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

228

229

231

232

233

234

235

237

238

239

241

242

243

245

247

248

249

250

251

252

253

254

255

257

258

259

261

262

263

265

266

267

268

269

270

271

272

273

275

277

278

279

280

281

Vorwort zur deutschen Ausgabe

Schon in den 1980er Jahren fanden meine ersten Besuche in Deutschland statt. Damals arbeitete ich bei HP Labs und viele der besten Ingenieure des Unternehmens waren in Böblingen ansässig.

In den 1990er Jahren lernte ich als Führungskraft von Netscape Communications viele führende deutsche Technologieunternehmen kennen, die daran arbeiteten, mithilfe des Internets lang bestehende Probleme zu lösen und neue Möglichkeiten zu erschließen.

Für die, die mit den Anfängen des Internets in Deutschland vertraut sind, mag es interessant sein, dass ich bei eBay Senior Vice President Product & Design war. Wir hatten das deutsche Start-up Alando übernommen und so konnte ich viele persönlichen Beziehungen aufbauen, die zu meiner kontinuierlichen Zusammenarbeit mit deutschen Technologieunternehmen führten.

Als ich Anfang der 2000er Jahre die Silicon Valley Product Group gründete, lernte ichdrei eindrucksvolle Mitgründer von ImmobilienScout24 kennen. Ihr Unternehmen giltals frühe deutsche Erfolgsstory im Internet. Es folgte ein langer und intensiver Austausch, der zu unzähligen Besuchen im aufstrebenden Technologiezentrum Berlin und bei vielen deutschen Technologie-Start-ups führte – von München über Leipzig bis Hamburg.

Ich war immer von den deutschen Technologieführern und ihren Produktteams beeindruckt, daher hat es mich nicht im Geringsten überrascht, dass meine deutschen Freunde im weiteren Verlauf sowohl auf der deutschen als auch auf der internationalen Bühne Erfolge erzielten.

Zu Beginn der Internet-Ära waren die Hauptunterschiede in der Arbeitsweise der Unternehmen ihren Standorten geschuldet. Heute ist dies nicht mehr der Fall. Die besten Unternehmen und Teams der Welt sind in aller Herren Länder zu finden – New York, Seattle, Sao Paulo, London, Stockholm, Seoul, Tel Aviv, Bangalore, Melbourne, Shenzhen, Hamburg, um nur einige zu nennen.

Allerdings gibt es nach wie vor einen sehr großen Unterschied zwischen der Arbeitsweise der besten Unternehmen und der Arbeitsweise der meisten Unternehmen. In San Francisco und in Berlin gibt es großartige Teams, und dann gibt es noch den Rest.

In diesem Buch geht es darum, wie die besten Teams arbeiten. Am auffälligsten ist für mich, wie unterschiedlich diese Teams arbeiten. Ich hoffe, dass dieses Buch vielen deutschen Unternehmen helfen wird, wie die besten deutschen Unternehmen zu arbeiten, die zu den Besten der Welt gehören.

Marty Cagan

November 2019San Francisco, Kalifornien

Vorwort zur zweiten Auflage

Als ich zum ersten Mal erwog, eine Aktualisierung der ersten Auflage meines Buches Inspired herauszugeben, schätzte ich, dass ich ungefähr 10 bis 20 Prozent des Inhalts würde anpassen müssen – ich wollte einfach nicht so viel daran verändern.

Nachdem ich aber erst einmal angefangen hatte, wurde mir bald klar, dass diese zweite Auflage ein komplettes Umschreiben erforderte. Nicht weil ich bereute, was ich geschrieben hatte, sondern weil ich glaube, dass ich diese Themen jetzt viel besser erklären kann.

Ich hatte keine Ahnung, dass die erste Auflage so erfolgreich sein würde. Dank dem Buch habe ich Freundschaften in aller Welt geschlossen. Es wurde in zahlreiche Sprachen übersetzt und obwohl es inzwischen fast zehn Jahre alt ist, wachsen die Verkaufszahlen weiterhin, nur aufgrund von Mundpropaganda und Rezensionen.

Falls Sie also die erste Auflage gelesen haben, so danke ich Ihnen und hoffe, dass Ihnen die zweite sogar noch besser gefällt. Falls Inspired neu für Sie ist, hoffe ich, dass diese neue Auflage ihre Ziele noch besser erreicht.

Als ich die erste Ausgabe schrieb, war Agile noch nicht so fest in Produktionsunternehmen verankert und die Fachbegriffe Customer Development und Lean Start-up waren noch nicht sehr weit verbreitet. Heute benutzen die meisten Teams diese Techniken schon seit mehreren Jahren und interessieren sich mehr dafür, was es jenseits von Lean und Agile noch so gibt, und genau darauf werde ich mich hier konzentrieren.

Ich habe die Grundstruktur des Buches beibehalten, aber die Techniken, die ich beschreibe, haben sich in den letzten zehn Jahren deutlich verbessert.

Abgesehen davon, dass ich die Thematik anders erkläre, und neben den technischen Aktualisierungen ist die zweite maßgebliche Änderung des Buches, dass ich jetzt detailliert erläutere, was ich hier als Product @ Scale bezeichne.

In der ersten Auflage habe ich mich mehr auf Start-ups fokussiert. In dieser Auflage möchte ich jedoch den Blickwinkel auf die Herausforderungen erweitern, die sich Unternehmen in einem fortgeschrittenen Wachstumsstadium stellen, und auf die Frage, wie die Produktarbeit in großen Firmen gut gehandhabt werden kann.

Es steht außer Frage, dass Wachstum erhebliche Herausforderungen mit sich bringt, und in den letzten zehn Jahren habe ich einen Großteil meiner Zeit darauf verwendet, rasch größer werdende Unternehmen zu coachen. Manchmal nennen wir das Überlebenserfolg, vielleicht gibt Ihnen das eine Vorstellung davon, wie schwer es sein kann.

Ich habe von den Lesern der ersten Auflage viele wunderbare Rückmeldungen bekommen und dabei ein paar wichtige Dinge erfahren, die ich hier gerne ansprechen möchte.

Zunächst einmal besteht wirklich die Notwendigkeit, sich auf die spezielle Position des Product Managers zu konzentrieren. In der ersten Auflage habe ich viel über das Produktmanagement geschrieben, aber ich habe mich dabei eher in einem erweiterten Sinne an Produktteams zu wenden versucht. Heute gibt es viele exzellente Ressourcen für Product Designer und Produktentwickler, aber nur sehr wenige für Product Manager, die für technologiegetriebene Produkte zuständig sind. Ich habe daher beschlossen, mich in dieser Auflage auf die Tätigkeit des Technology Product Managers zu konzentrieren. Falls Sie Product Manager bei einem Technologieunternehmen sind oder diese Position anstreben, finden Sie hier hoffentlich Ihren Ratgeber für alle Fälle.

Zum anderen suchen viele nach einem Rezept für den Produkterfolg – einem Regelwerk oder System, um Produkte zu schaffen, die den Kunden begeistern. Ich verstehe zwar diesen Wunsch und könnte sicherlich erheblich mehr Exemplare verkaufen, würde ich dieses Buch so vermarkten, aber die unbequeme Wahrheit lautet, dass tolle Produkte einfach nicht auf diese Weise geschaffen werden. Es geht vielmehr darum, die richtige Produktkultur für den Erfolg zu erzeugen und das Zusammenspiel der Techniken für Product Discovery und Product Delivery zu verstehen, damit Sie das richtige Tool für Ihr spezielles Problem nutzen können. Und ja, das bedeutet, die Position des Product Managers ist alles andere als einfach, und um die Wahrheit zu sagen, nicht jeder hat das Zeug, in dieser Tätigkeit erfolgreich zu sein.

Dessen ungeachtet ist das Technical Product Management heute eine der begehrtesten Stellen in unserer Branche und die Hauptquelle – die Bewährungsprobe – für Start-up-CEOs. Wenn es Sie also in diese Richtung zieht und Sie bereit sind, sich die Mühe zu machen, dann tue ich nichts lieber, als Ihnen zum Erfolg zu verhelfen.

Teil I:LEKTIONEN VON FÜHRENDEN TECHNOLOGIEUNTERNEHMEN

Mitte der Achtzigerjahre war ich ein junger Softwareprogrammierer und arbeitete für Hewlett-Packard an einem sehr renommierten Produkt. Es war eine Zeit, in der künstliche Intelligenz (zum ersten Mal) in aller Munde war, und ich hatte das Glück, bei einer der zu diesem Zeitpunkt besten Technologiefirmen der Branche zu arbeiten, als Teil eines sehr starken Softwareentwicklungsteams (etliche Mitglieder dieses Teams wurden später bei Firmen in der gesamten Branche überaus erfolgreich).

Unsere Aufgabe war schwierig: Wir sollten eine KI-fähige Technologie für eine preiswerte Allzweck-Workstation schaffen, die bis dahin eine spezielle Hardware-Software-Kombination zum Preis von über 100.000 Dollar pro Nutzer erforderte – eine Summe, die nur für wenige erschwinglich war.

Weit über ein Jahr arbeiteten wir hart daran und opferten zahlreiche Nächte und Wochenenden. Bei der Gelegenheit fügten wir dem Portfolio von HP einige Patente hinzu. Wir entwickelten die Software, um die hohen Qualitätsstandards von HP zu erfüllen. Wir internationalisierten das Produkt und lokalisierten es für mehrere Sprachen. Wir bildeten das Verkaufsteam aus. Wir gaben der Presse eine Vorschau auf unsere Technologie und erhielten exzellente Beurteilungen. Wir waren bereit. Wir nahmen die Markteinführung vor. Wir feierten die Markteinführung.

Es gab nur ein Problem: Es verkaufte sich nicht.

Das Produkt war ein totaler Misserfolg am Markt. Es war zwar technisch beeindruckend und die Rezensenten fanden es wunderbar, aber es war nichts, was die Leute haben wollten oder brauchten.

Das Team war natürlich überaus frustriert von diesem Ergebnis. Doch bald fingen wir an, uns ein paar sehr wichtige Fragen zu stellen: Wer entscheidet, welche Produkte wir schaffen sollen? Wie wird das entschieden? Woher wissen die Entscheider, dass unsere Entwicklungen von Nutzen sein werden?

Unser junges Team lernte etwas sehr Bedeutsames – etwas, das viele Teams auf die harte Tour erfahren haben: Es spielt keine Rolle, wie gut Ihr Entwicklerteam ist, wenn es nicht an etwas Lohnenswertem arbeiten kann.

Als ich versuchte, den Gründen für unser Scheitern auf die Spur zu kommen, erfuhr ich, dass die Entscheidungen darüber, was entwickelt werden sollte, von einem Produktmanager getroffen wurden – jemandem, der hauptsächlich in der Marketingabteilung angesiedelt und für die Festlegung der von uns geschaffenen Produkte zuständig war. Aber ich erfuhr auch, dass Produktmanagement nicht gerade eine Stärke von HP war. Später fand ich heraus, dass die meisten Unternehmen darin nicht besonders gut waren und tatsächlich immer noch nicht sind.

Ich schwor mir, nie wieder so hart an einem Produkt zu arbeiten, wenn ich nicht sicher war, dass es sich dabei um etwas handelte, was Nutzer und Kunden wollten.

Während der folgenden dreißig Jahre hatte ich das große Glück, an einigen der erfolgreichsten Hightech-Produkte unserer Zeit arbeiten zu dürfen – zuerst bei HP während des Aufstiegs der Personal Computer, dann bei Netscape Communications während des Aufstiegs des Internets, wo ich als Vice President für Plattformen und Tools beschäftigt war, später bei eBay während des Aufstiegs des E-Commerce und der Online-Marktplätze, wo ich Senior Vice President für Produkte und Design war, und schließlich als Berater für Start-ups, von denen viele zu den heute erfolgreichsten Technologieunternehmen zählen.

Nicht alle entwickelten Produkte waren gleichermaßen erfolgreich, aber ich kann zum Glück behaupten, dass keine Misserfolge darunter waren, und viele werden von Millionen Menschen auf aller Welt geliebt und verwendet.

Ich fand heraus, dass ein gewaltiger Unterschied darin bestand, wie die besten Firmen Produkte herstellten und wie die meisten Firmen das taten.

Bald nachdem ich eBay verlassen hatte, erhielt ich Anrufe von Produktorganisationen, die ihren Produktionsprozess verbessern wollten. Als ich anfing, mit diesen Unternehmen zu arbeiten, fand ich heraus, dass ein gewaltiger Unterschied darin bestand, wie die besten Firmen Produkte herstellten und wie die meisten Firmen das taten.

Ich erkannte, dass die optimale Vorgehensweise sich stark von der gängigen Vorgehensweise unterschied.

Die meisten Unternehmen verwendeten immer noch alte und ineffiziente Formen der Product Discovery und Product Delivery. Ich fand auch heraus, dass es nur beklagenswert wenige Hilfestellungen gab, sowohl in der akademischen Welt, darunter die besten Business-School-Lehrgänge, als auch in Branchenorganisationen, die hoffnungslos in den gescheiterten Modellen der Vergangenheit festzuhängen schienen – genau wie das, mit dem ich bei HP gearbeitet hatte.

Ich hatte tolle Erlebnisse und besonders dankbar bin ich dafür, dass ich die Gelegenheit hatte, mit einigen Vordenkern der Branche zusammenzuarbeiten. Von ihnen stammen die besten Ideen in diesem Buch. Viele von ihnen erwähne ich in der Danksagung. Ich habe von ihnen allen gelernt und dafür bin ich jedem Einzelnen von ihnen dankbar.

Ich habe mich für diesen Berufsweg entschieden, weil ich an Produkten arbeiten wollte, die die Kunden lieben – Produkte, die inspirieren und einen echten Wert liefern. Natürlich wollen die meisten Führungskräfte im Product Management ebenfalls inspirierende und erfolgreiche Produkte schaffen. Aber die meisten Produkte sind nicht inspirierend und das Leben ist zu kurz für schlechte Produkte.

Meine Hoffnung beim Schreiben dieses Buches ist, dass es dazu beiträgt, die Best Practices der erfolgreichsten Produktunternehmen zu verbreiten, und dass dabei wirklich inspirierende Produkte herauskommen – Produkte, die Kunden lieben.

1Hinter jedem großartigen Produkt

Es ist meine feste Überzeugung und das zentrale Konzept dieses Buches, dass hinter jedem großartigen Produkt jemand steht – im Allgemeinen unermüdlich hinter den Kulissen arbeitend –, der das Produktteam dazu gebracht hat, Technologie und Design so miteinander zu kombinieren, dass echte Kundenprobleme auf eine Weise gelöst werden, die mit den geschäftlichen Bedürfnissen übereinstimmt.

Diese Menschen tragen für gewöhnlich den Titel Product Manager. Sie können auch Mitgründer oder CEO eines Start-ups sein oder eine andere Position im Team ausfüllen, haben jedoch die Dinge ins Rollen gebracht, weil sie die Notwendigkeit erkannt haben.

Außerdem unterscheidet sich diese Produktmanagementposition sehr stark von jenen des Designers, des Engineers und des Marketing oder Project Managers.

Das vorliegende Buch richtet sich an diese Menschen.

In modernen Technologieproduktteams hat der Product Manager einige sehr spezifische und äußerst anspruchsvolle Verantwortlichkeiten. Es ist eine enorm schwierige Position und jeder, der Ihnen etwas anderes erzählen will, tut Ihnen damit keinen Gefallen.

Es ist meine feste Überzeugung und das zentrale Konzept dieses Buches, dass hinter jedem großartigen Produkt jemand steht – im Allgemeinen unermüdlich hinter den Kulissen arbeitend –, der das Produktteam dazu gebracht hat, Technologie und Design so miteinander zu kombinieren, dass echte Kundenprobleme auf eine Weise gelöst werden, die mit den geschäftlichen Bedürfnissen übereinstimmt.

Die Position des Product Managers ist normalerweise eine absolute Vollzeitaufgabe. Ich persönlich kenne nicht viele, die in der Lage sind, alles dafür Notwendige in weniger als sechzig Stunden pro Woche zu schaffen.

Es ist prima, wenn Sie Designer oder Engineer sind und auch als Product Manager fungieren wollen – das hat ein paar echte Vorteile. Aber Sie werden schnell merken, dass Sie sich damit ein riesiges Arbeitspensum aufgehalst haben. Wenn Sie damit zurechtkommen, können die Ergebnisse durchaus beeindruckend sein.

Ein Produktteam besteht aus mindestens einem Product Manager und normalerweise zwischen zwei und zehn Engineers. Falls Sie ein anwenderorientiertes Produkt herstellen, sollten Sie auch wenigstens einen Product Designer in Ihrem Team haben.

In diesem Buch beleuchten wir auch die Situation, dass Sie auf Programmierer oder Designer an anderen Standorten oder von Agenturen oder Arbeitsvermittlungsfirmen zurückgreifen müssen. Doch ganz gleich, wie Sie Ihr Team zusammenstellen, diese Position und dieses Buch gehen davon aus, dass Sie ein Team damit beauftragt haben, mit Ihnen an der Gestaltung, Erstellung und Lieferung eines Produkts zu arbeiten.

2Technologiegetriebene Produkte und Dienstleistungen

Es gibt eine Vielzahl von Produkten, aber in diesem Buch konzentriere ich mich ausschließlich auf solche, die auf Technologie basieren. Manches von dem, was wir in diesem Buch behandeln, mag Ihnen auch von Nutzen sein, wenn Sie nichttechnologische Produkte herstellen, aber dafür übernehme ich keine Garantie. Ehrlich gesagt gibt es bereits eine große Auswahl leicht zugänglicher Quellen für nicht technologische Produkte, wie etwa die meisten Verbrauchsgüter, sowie für die Product Manager in diesem Bereich.

Mein Fokus liegt auf den besonderen Problemen und Herausforderungen der Herstellung von technologiegetriebenen Produkten, Dienstleistungen und Erfahrungen.

Ein paar gute Beispiele für den hier untersuchten Sweet-Spot sind Consumer-Service-Produkte wie E-Commerce-Seiten oder -Marktplätze (z.B. Netflix, Airbnb oder Etsy), soziale Netzwerke (z.B. Facebook, LinkedIn oder Twitter), Business Services (z.B. Salesforce.com, Workday oder Workiva), Endverbrauchergeräte (z.B. Apple, Sonos oder Tesla) und Apps (z.B. Uber, Audible oder Instagram).

Mein Fokus liegt auf den besonderen Problemen und Herausforderungen der Herstellung von technologiegetriebenen Produkten, Dienstleistungen und Erfahrungen.

Technologiegetriebene Produkte müssen nicht ausschließlich digital sein. Viele der besten Beispiele sind heutzutage Kombinationen von Online- und Offline-Erlebnissen – zum Beispiel die Suche nach einer Mitfahrgelegenheit oder einer Unterkunft für eine Nacht, die Beantragung eines Hypothekendarlehens oder der Versand einer Expresslieferung.

Ich bin davon überzeugt, dass die meisten Produkte sich heutzutage in technologiegetriebene Produkte verwandeln, und Unternehmen, die das nicht erkennen, verschwinden rasch vom Markt. Aber noch einmal, ich konzentriere mich hier auf technologiegetriebene Produkte und jene Unternehmen, die daran glauben, dass sie sich der Technologie offen zuwenden und sie im Interesse ihrer Kunden fortwährend innovieren müssen.

3Start-ups: Product/Market-Fit

In der Welt der Technologie gibt es im Allgemeinen drei Unternehmensstadien: Start-ups, Wachstums- und reife Unternehmen. Werfen wir einen kurzen Blick auf die Charakterisierung dieser drei Stadien und ihre jeweiligen Herausforderungen.

Ich definiere ein Start-up allgemein als ein neues Produktionsunternehmen, das den Product/Market-Fit noch erreichen muss. Product/Market-Fit ist ein überaus wichtiges Konzept, das ich im späteren Verlauf noch erläutern werde, aber sagen wir fürs Erste einmal, dass ein Start-up versucht, ein Produkt zu schaffen, mit dem sich ein rentables Geschäft machen lässt.

In einem Start-up wird die Position des Product Managers für gewöhnlich durch einen der Mitgründer besetzt. Typischerweise gibt es weniger als fünfundzwanzig Programmierer und die Bandbreite reicht von einem bis zu vielleicht vier oder fünf Produktteams.

Ein Start-up sollte schnellstmöglich den Product/Market-Fit erreichen und zwar ehe das Geld aufgebraucht ist. Es zählt kaum etwas anderes, bis Sie ein starkes Produkt anbieten können, das die Bedürfnisse eines Anfangsmarktes deckt, deshalb liegt der Fokus des jungen Unternehmens notwendigerweise auf dem Produkt.

Start-ups haben meistens ein begrenztes Startkapital, um herauszufinden, ob das Unternehmen das notwendige Produkt entdecken und bereitstellen kann. Je mehr das Kapital zur Neige geht, desto hektischer wird das Tempo und desto verzweifelter werden das Team und die Führung.

Auch wenn Geld und Zeit typischerweise knapp sind, so sind gute Start-ups optimal darauf ausgerichtet, schnell zu lernen und zu reagieren, und normalerweise werden sie kaum von Bürokratie gehemmt. Dennoch ist die hohe Versagensquote von Technologie-Start-ups kein Geheimnis. Die wenigen erfolgreichen sind im Allgemeinen jene, die sehr gut bei der Product Discovery abschneiden, und das ist das zentrale Thema dieses Buches.

Es zählt kaum etwas anderes, bis Sie ein starkes Produkt anbieten können, das die Bedürfnisse eines Anfangsmarktes deckt.

Die Arbeit in einem Start-up – das Rennen um den Product/Market-Fit – ist für gewöhnlich stressig, anstrengend und riskant. Aber es kann auch eine überaus positive Erfahrung sein, und wenn alles gut läuft, ist sie auch finanziell lohnenswert.

4Wachstumsunternehmen: Skalieren zum Erfolg

Diejenigen Start-ups, die genügend Kompetenz und Glück haben (im Allgemeinen braucht man beides), um den Product/Market-Fit zu erreichen, sind bereit, sich einer weiteren und gleichermaßen anspruchsvollen Herausforderung zu stellen: dem effektiven Wachstum.

Es sind viele maßgebliche Herausforderungen damit verbunden, ein Start-up zu einem großen, erfolgreichen Geschäft auszubauen. Auch wenn es sich dabei um eine extrem schwierige Aufgabe handelt, so ist es doch ein eher angenehmes Problem.

Wir müssen nicht nur deutlich mehr Leute einstellen, sondern auch herausfinden, wie wir unsere Anfangserfolge mit neuen, verwandten Produkten und Dienstleistungen wiederholen können. Gleichzeitig müssen wir das Kerngeschäft schnellstmöglich vergrößern.

In der Wachstumsphase haben wir für gewöhnlich zwischen fünfundzwanzig und mehreren Hundert Programmierern, es sind also viel mehr Leute da, die helfen können, allerdings zeigen sich auch überall Anzeichen von Organisationsstress.

Auch wenn es sich dabei um eine extrem schwierige Aufgabe handelt, so ist es doch ein eher angenehmes Problem.

Die Produktteams beschweren sich darüber, dass sie das große Ganze nicht verstehen – sie erkennen nicht, inwiefern ihre Arbeit zu den übergeordneten Zielen beiträgt, und sie ringen mit der Frage, was es bedeutet, ein kompetentes, autonomes Team zu sein.

Sales und Marketing klagen häufig, dass die Markteintrittsstrategien, die beim ersten Produkt funktioniert haben, für einige der neuen Produkte im Portfolio nicht so recht passen.

Die technische Infrastruktur, die geschaffen wurde, um die Anforderungen des Ursprungsproduktes zu erfüllen, platzt oft aus allen Nähten und man hört den Begriff »Technische Schulden« von jedem Programmierer, mit dem man sich unterhält.

Dieses Stadium ist auch schwierig für Führungskräfte, weil der Führungsstil und die Mechanismen, die funktioniert haben, als das Unternehmen noch ein junges Start-up war, oft nicht skalierbar sind. Die Führungskräfte sind gezwungen, ihre Positionen und in vielen Fällen auch ihre Verhaltensweisen zu verändern.

Doch die Motivation, diese Hindernisse zu überwinden, ist sehr groß. Oft strebt das Unternehmen den Börsengang an oder möchte vielleicht eine der Hauptgeschäftseinheiten eines bestehenden Unternehmens werden. Auch die Chance darauf, einen maßgeblichen und positiven Einfluss auf die Welt zu haben, kann sehr motivierend sein.

5Reife Unternehmen: dauerhafte Produktinnovation

Denjenigen Unternehmen, die erfolgreich wachsen und ein dauerhaft tragfähiges Geschäftsmodell schaffen wollen, stehen ein paar der schwierigsten Herausforderungen noch bevor.

Starke Technologieunternehmen wissen, dass sie fortwährende Produktinnovation gewährleisten müssen. Das bedeutet, ständig neuen Wert für ihre Kunden und ihr Geschäft zu schöpfen. Nicht nur bestehende Produkte aufzubessern und zu optimieren (was als Wertsteigerung bezeichnet wird), sondern vielmehr das volle Potenzial eines jeden Produktes zu entfalten.

Gleichwohl befinden sich viele große, reife Unternehmen bereits in einer langsamen Todesspirale. Alles dreht sich nur noch um die Ausschöpfung des Wertes und der Marke, die vor vielen Jahren oder gar Jahrzehnten geschaffen wurden. Der Unternehmenstod tritt selten über Nacht ein und ein großes Unternehmen kann viele Jahre lang dahintreiben. Aber machen wir uns nichts vor, mit der Organisation geht es bergab und das Ende ist gewiss.

Starke Technologieunternehmen wissen, dass sie fortwährende Produktinnovation gewährleisten müssen.

Das ist natürlich keine Absicht, aber wenn Unternehmen erst einmal diese Größe erreicht haben – und oft an der Börse notiert sind –, gibt es eine Vielzahl an Stakeholdern in jedem Geschäftsbereich, die alles tun, um zu bewahren, was das Unternehmen geschaffen hat.

Leider bedeutet dies oft, neue Initiativen oder Wagnisse abzuschmettern, die das Geschäft wiederbeleben könnten (aber das Kerngeschäft potenziell gefährden), oder aber neuen Ideen so viele Steine in den Weg zu legen, dass nur wenige bereit oder in der Lage sind, das Unternehmen in eine neue Richtung zu lenken.

Die Symptome sind kaum zu übersehen: sinkende Moral, fehlende Innovationen und eine erheblich längere Zeitspanne, bis neue Produkte in die Hände der Verbraucher gelangen.

Als das Unternehmen noch jung war, hatte es vermutlich eine klare und überzeugende Vision. Wenn es jedoch das Reifestadium erreicht, hat es diese ursprüngliche Vision weitgehend erreicht und jetzt ist man sich nicht ganz darüber im Klaren, was als Nächstes kommen soll. Die Produktteams klagen über fehlende Visionen, fehlende Vollmachten und die Tatsache, dass es ewig dauert, bis Entscheidungen getroffen werden, und die Produktarbeit entwickelt sich immer mehr zu einem unüberschaubaren Wust verschiedenster Meinungen und Ideen.

Auch die Führung ist wahrscheinlich frustriert über den Innovationsmangel der Produktteams. Nur zu oft sucht sie ihr Heil in Neueinstellungen oder in der Schaffung separater »Innovationszentren«, um in geschützter Umgebung neue Geschäftsideen auszubrüten. Doch das führt nur selten zu den so verzweifelt herbeigesehnten Innovationen.

Große, reife Unternehmen wie Adobe, Amazon, Apple, Facebook, Google und Netflix haben es dennoch geschafft, diesem Schicksal zu entgehen. Die Organisationsleitung fragt sich, warum sie es nicht genauso machen kann. Tatsache ist, sie könnte es genauso machen. Aber dazu müsste sie ein paar ziemlich große Veränderungen durchführen und darum geht es in diesem Buch.

6Die Grundursachen gescheiterter Produktvorhaben

Beginnen wir damit, die Ursachen für das Scheitern so vieler Produktvorhaben zu ergründen.

In den meisten Unternehmen, und zwar überall auf der Welt und egal welcher Größe, erkenne ich dieselben grundlegenden Arbeitsweisen und ich kann nicht umhin zu bemerken, dass diese nicht annähernd mit denen der besten Unternehmen vergleichbar sind.

Kleine Warnung vorab: Die folgende Darstellung kann ein bisschen deprimierend sein, besonders wenn Sie sich darin nur allzu gut wiederfinden. Also falls das der Fall sein sollte, möchte ich Sie bitten, einfach mit mir gemeinsam dranzubleiben.

Abbildung 6.1 beschreibt den Prozess, den die meisten Firmen nach wie vor nutzen, um Produkte zu schaffen. Ich möchte dieses Vorgehen noch nicht bewerten, sondern den Prozess zunächst einfach beschreiben:

Wie Sie sehen, fängt alles mit Ideen an. In den meisten Unternehmen kommen sie von innerhalb (durch die Geschäftsführung oder wichtige Stakeholder oder Firmeneigentümer) oder von außen (durch aktuelle oder potenzielle Kunden). Wo auch immer sie ihren Ursprung haben, es gibt stets eine ganze Reihe von Dingen, die verschiedene Bereiche des Unternehmens von uns erfordern.

Abbildung 6.1: Grundursachen gescheiterter Produktvorhaben

Die meisten Unternehmen möchten diese Ideen nach Prioritäten sortiert in einer Roadmap darstellen, und zwar aus zwei wesentlichen Gründen. Zum einen wollen sie, dass wir als Erstes an den wichtigsten Dingen arbeiten, und zum anderen wollen sie vorhersagen können, wann was fertig ist.

Dafür gibt es gewöhnlich irgendeine Form vierteljährlicher oder jährlicher Planungssitzungen, bei denen die Führungskräfte die Ideen begutachten und über eine Product Roadmap verhandeln. Aber um Prioritäten setzen zu können, brauchen sie zunächst für jeden Punkt irgendeine Art von Business Case.

Manche Firmen erstellen formelle Business Cases, andere eher informelle, aber in jedem Fall müssen über jede Idee zwei Dinge bekannt sein: (1) Wie viel Geld oder Wert bringt sie? Und: (2) Wie viel Geld oder Zeit kostet sie? Diese Informationen werden dann für die Erstellung der Roadmap genutzt, normalerweise für das nächste Quartal, aber manchmal auch bis zu einem Jahr im Voraus.

Durch diese Roadmap hat die Produkt- und Technologieorganisation nun ihren Marschbefehl und bearbeitet die Aufgaben nach Priorität.

Hat eine Idee es ganz nach oben auf die Liste geschafft, besteht die erste Aufgabe des Product Managers darin, mit den Stakeholdern zu sprechen, um die Idee auszugestalten und eine Reihe von »Anforderungen« zu formulieren.

Diese Anforderungen können User Stories oder irgendeine Form funktioneller Spezifikationen sein. Ihr Zweck ist es, den Designern und Programmierern zu verdeutlichen, was genau geschaffen werden muss.

Sind die Anforderungen zusammengetragen, wird das User-Experience-Designteam (vorausgesetzt, das Unternehmen verfügt über ein solches) mit dem Interaction Design, dem Visual Design und bei physischen Geräten mit dem Industrial Design beauftragt.

Schließlich werden die Anforderungen und die Design-Spezifikationen den Engineers vorgelegt. An dieser Stelle tritt für gewöhnlich Agile auf den Plan.

Die Programmierer werden die Arbeit typischerweise auf eine Reihe von Iterationen herunterbrechen – im Scrum-Prozess werden sie als »Sprints« bezeichnet. Es braucht also vielleicht ein bis drei Sprints, um die Idee auszugestalten.

Zu diesen Sprints gehört hoffentlich auch das QA Testing. Wenn nicht, wird das QA-Team dies nachholen und einige Tests vornehmen, um sicherzustellen, dass die neue Idee wie angekündigt funktioniert und nicht für weitere Probleme sorgt (die als Regressionen bekannt sind).

Sobald die QA grünes Licht gegeben hat, kann die neue Idee endlich bei echten Kunden zum Einsatz kommen.

Die Mehrheit der Unternehmen, ob groß oder klein, denen ich erstmals begegne, arbeiten im Wesentlichen genauso und tun das schon seit vielen Jahren. Doch diese Unternehmen klagen auch fortwährend über den Innovationsmangel und die sehr lange Dauer des Weges der Idee zum Kunden.

Ihnen ist vielleicht aufgefallen, dass ich zwar Agile erwähnt habe und dass so ziemlich jeder heute Agile für sich beansprucht, doch was ich gerade beschrieben habe, ist weitgehend ein Wasserfallprozess. Um den Programmierern Gerechtigkeit widerfahren zu lassen, muss gesagt sein, dass sie im Rahmen des größeren Wasserfall-Kontextes im Allgemeinen so viel Agile wie möglich anwenden.

Die meisten Teams werden vermutlich so arbeiten. Aber warum sollte das der Grund für so viele Probleme sein? Ziehen wir jetzt einmal die Verbindungslinien, damit wir genau erkennen können, warum diese weit verbreitete Arbeitsmethode für die meisten gescheiterten Produktvorhaben verantwortlich ist.

In der folgenden Liste führe ich auf, was ich für die zehn größten Probleme bei dieser Vorgehensweise halte. Denken Sie daran, dass jedes dieser zehn Probleme eine sehr ernste Angelegenheit ist, die allein schon ein ganzes Team ins Schleudern bringen kann. Viele Unternehmen haben jedoch mehr als eins oder sogar alle diese Probleme.

Zwar beansprucht so ziemlich jeder heute Agile für sich, doch was ich gerade beschrieben habe, ist weitgehend ein Wasserfallprozess.

Beginnen wir ganz oben – bei der Quelle der Ideen. Dieses Modell führt zu verkaufsgesteuerten Besonderheiten und zu stakeholdergesteuerten Produkten. Es gibt zu diesem zentralen Thema noch sehr viel mehr zu sagen, aber fürs Erste nur so viel: Das ist nicht die Quelle unserer besten Produktideen. Eine weitere Folge dieser Vorgehensweise ist die mangelnde Beteiligung der Teammitglieder. In diesem Modell haben sie nichts weiter zu tun, als zu implementieren – sie sind nichts als Söldner.

Als Nächstes wollen wir über den fatalen Irrtum bei diesen Business Cases sprechen. Um das klarzustellen, ich persönlich bin ein großer Befürworter von Business Cases, zumindest für Ideen, die eine größere Investition brauchen. Aber die Art und Weise, wie die meisten Unternehmen sie in diesem Stadium erstellen, um eine nach Prioritäten geordnete Roadmap zu erhalten, ist wirklich lächerlich, und zwar aus folgendem Grund. Erinnern Sie sich an die beiden wichtigsten Vorüberlegungen für jeden Business Case? Wie viel Geld Sie verdienen werden und wie viel es kosten wird? Also, die nackte, schonungslose Wahrheit lautet: In dieser Phase haben wir von beidem nicht die leiseste Ahnung. Genau genommen

können

wir das gar nicht wissen.

Wir können nicht wissen, wie viel Geld wir verdienen, weil das komplett davon abhängt, als wie gut die Lösung sich erweist. Wenn das Team gute Arbeit leistet, könnte die Sache äußerst erfolgreich sein und wahrhaftig den Kurs des Unternehmens ändern. Die Wahrheit ist jedoch, dass viele Produktideen am Ende überhaupt nichts einbringen. Und das ist keine effekthascherische Übertreibung. Wirklich überhaupt nichts (das wissen wir aus A/B-Tests).

Auf alle Fälle lautet eine der wichtigsten Lektionen beim Produktmarketing, zu wissen, was wir nicht wissen können, und wir können zu diesem Zeitpunkt einfach nicht wissen, wie viel Geld wir verdienen werden.

Ebenso wenig Ahnung haben wir davon, wie hoch die Erstellungskosten sein werden. Ohne die eigentliche Lösung zu kennen, ist das für die Technik extrem schwer vorauszusagen. Die meisten erfahrenen Programmierer dürften es ablehnen, in diesem Stadium eine Schätzung vorzunehmen, aber manche werden zu einem T-Shirt-Größen-Kompromiss gedrängt – uns einfach zu sagen, ob es »S, M, L oder XL ausfällt«.

Aber Unternehmen wollen diese nach Prioritäten geordneten Roadmaps unbedingt haben, und um einen zu erstellen, brauchen sie irgendein System zur Bewertung der Ideen. Also spielen die Leute das Business-Case-Spiel.

Ein sogar noch größeres Problem ist, zu sagen, was als Nächstes kommt, und an dieser Stelle sind die Unternehmen wirklich begeistert von ihren Product Roadmaps. Im Laufe der Jahre habe ich zahllose Roadmaps gesehen und die meisten davon sind im Wesentlichen Listen von Funktionen und Projekten. Das Marketing braucht diese Funktion für eine Werbekampagne. Der Verkauf braucht jene Funktion für einen neuen Kunden. Jemand möchte eine PayPal-Verknüpfung. Sie wissen schon, worauf ich hinauswill.

Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen schlicht nicht funktionieren wird.

Aber jetzt kommt das Problem – vielleicht das größte von allen. Es ist das, was ich als die beiden unbequemen Wahrheiten über Produkte bezeichne.

Die erste Wahrheit ist, dass mindestens die Hälfte unserer Ideen schlicht nicht funktionieren wird. Es gibt viele Gründe, warum eine Idee nicht umsetzbar ist. Der häufigste ist, dass die Kunden diese Idee einfach nicht so fantastisch finden wie wir. Also entscheiden sie sich, das Produkt nicht zu verwenden. Manchmal probieren sie es zwar aus, aber dann erweist es sich als so kompliziert, dass sich der Aufwand einfach nicht lohnt und die Kunden keinen zweiten Versuch unternehmen. Manchmal besteht das Problem darin, dass die Nutzer das Produkt zwar toll fänden, aber es stellt sich heraus, dass die Herstellung viel mehr erfordert, als wir gedacht haben, weshalb wir einfach nicht die notwendige Zeit und das Geld aufbringen können, um es anzubieten.

Ich kann Ihnen garantieren, dass mindestens die Hälfte der Ideen in Ihrer Roadmap nicht das von Ihnen erhoffte Resultat bringen wird. (Übrigens, wirklich gute Teams schätzen, dass mindestens drei Viertel der Ideen nicht so laufen wie erhofft.)

Als wäre das noch nicht schlimm genug, lautet die zweite unbequeme Wahrheit, dass selbst für die Ideen, die Potenzial beweisen, typischerweise etliche Iterationen notwendig sind, bis die Realisierung dieser Idee zu einem Punkt gelangt, an dem sie den notwendigen Geschäftswert erbringt. Wir nennen das Time to Money.

Eines der wichtigsten Dinge, die ich über das Product Management gelernt habe, ist, dass diese unbequemen Wahrheiten sich einfach nicht umgehen lassen, egal wie clever Sie auch sein mögen. Und ich hatte das Glück, mit vielen wirklich außergewöhnlichen Produktteams zusammenzuarbeiten. Der tatsächliche Unterschied liegt darin, wie man mit diesen Wahrheiten umgeht.

Lassen Sie uns als Nächstes die Rolle des Product Managements in diesem Modell betrachten. Eigentlich sollten wir es gar nicht als Product Management bezeichnen– es ist genau genommen eine Form des Project Managements. In diesem Modell geht es mehr darum, Anforderungen zusammenzutragen und sie für die Programmierer zu dokumentieren. Lassen Sie mich an dieser Stelle nur sagen, dass dies um 180 Grad von der Realität des modernen Tech Product Managements abweicht.

Ganz Ähnliches gilt für die Rolle des Designs. Die Sache ist schon viel zu weit vorangeschritten, um dem Design zu seinem tatsächlichen Wert zu verhelfen, und was hier geschieht, sind in erster Linie »kosmetische Maßnahmen«. Der Schaden ist bereits angerichtet und wir versuchen jetzt bloß, eine Schicht Farbe darüberzupinseln. Die UX-Designer wissen, dass das nicht gut ist, aber sie geben sich Mühe, es so nett und stimmig wie möglich aussehen zu lassen.

Die vielleicht größte verpasste Chance in diesem Modell ist die Tatsache, dass die technische Seite viel zu spät ins Spiel gebracht wird. Wir sagen, wenn Sie Ihre Programmierer nur zum Coden einsetzen, nutzen Sie nur ungefähr die Hälfte ihres Wertes. Das kleine Geheimnis der Produkterstellung lautet, dass Programmierer typischerweise die beste Innovationsquelle sind; trotzdem werden sie bei diesem Prozess nicht mal zur Party eingeladen.

Nicht nur das Engineering wird viel zu spät eingebracht, sondern auch die Prinzipien und wichtigsten Vorzüge von Agile treten viel zu spät auf den Plan. Teams, die Agile auf diese Weise nutzen, schöpfen vielleicht 20 Prozent des tatsächlichen Wertes und Potenzials der Agile-Methoden aus. Was man hier wirklich sieht, sind Agile-Methoden bei der Delivery, aber der Rest der Organisation und des Kontextes ist alles andere als agil.

Dieser gesamte Prozess ist sehr projektlastig. Das Unternehmen finanziert Projekte, stellt Personal für Projekte ab, drückt Projekte durch und führt schließlich Projekte aus. Leider sind Projekte aber Output und beim Produkt geht es in erster Linie um Resultate. Dieser Prozess führt vorhersehbar zu verwaisten Projekten. Irgendetwas wird am Ende schon dabei herauskommen, aber es erfüllt die Erwartungen nicht. Also worum ging es bei der ganzen Sache eigentlich? Auf jeden Fall ist das ein ernst zu nehmendes Problem und hat nichts damit zu tun, wie wir Produkte erstellen sollten.

Der größte Schwachpunkt des guten alten Wasserfallprozesses war schon immer und bleibt auch weiterhin, dass das gesamte Risiko am Ende liegt, und das bedeutet, dass die Kundenvalidierung viel zu spät erfolgt.

Das Grundprinzip von Lean-Methoden ist die Reduzierung von Überflüssigem und eine der entscheidendsten Formen des Überflüssigen ist es, eine Funktion oder ein Produkt zu gestalten, zu schaffen, zu testen und einzuführen, nur um festzustellen, dass es nicht das ist, was benötigt wird. Die Ironie an der Sache ist, dass viele Teams glauben, sie würden Lean-Prinzipien anwenden; stattdessen folgen sie aber nur den grundlegenden Prozessen, die ich gerade beschrieben habe. Dann erkläre ich ihnen, dass sie Ideen auf eine der teuersten und langsamsten Arten ausprobieren, die uns bekannt ist.

Und während wir mit diesem Prozess beschäftigt sind und Zeit und Geld vergeuden, zeigt sich am Ende für gewöhnlich der größte Verlust von allen, nämlich in Form der Opportunitätskosten dessen, was die Organisation stattdessen hätte tun können und sollen. Wir können uns diese Zeit und dieses Geld nicht zurückholen.

Kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür zurückbekommen. Ich habe Sie gewarnt, dass das Ganze ein bisschen deprimierend werden könnte. Aber Sie sollten genau verstehen, warum Ihr Unternehmen seine Arbeitsweise ändern muss, vorausgesetzt natürlich, dass es tatsächlich auf diese Weise arbeitet.

Kein Wunder, dass so viele Unternehmen so viel Zeit und Geld verschwenden und so wenig dafür zurückbekommen.

Die gute Nachricht ist: Ich verspreche Ihnen, dass die besten Teams überhaupt nicht so vorgehen, wie ich es gerade geschildert habe.

7Jenseits von Lean und Agile

Die Menschen suchen immer nach einem Königsweg für die Produktentwicklung und ihnen steht eine bereitwillige Industrie gegenüber, die ihnen mit Büchern, Coaching, Training und Consulting unter die Arme greifen will. Aber es gibt keinen Königsweg und das finden die Leute unweigerlich irgendwann heraus. Dann erfolgt die Gegenreaktion. Während ich dies schreibe, ist es gerade modern, sowohl Lean als auch Agile zu kritisieren.

Ich bezweifle nicht, dass viele Menschen und Teams bis zu einem gewissen Grad enttäuscht sind von den Ergebnissen, die sie mit der Anwendung von Lean sowie Agile erzielt haben. Und ich verstehe die Gründe dafür. Gleichwohl bin ich davon überzeugt, dass die Werte und Prinzipien von Lean und Agile dauerhaft gültig sind. Nicht so sehr die speziellen Ausprägungen dieser Methoden, die viele Teams heutzutage anwenden, sondern die dahinterstehenden Kernprinzipien. Ich bin der Meinung, dass sie beide einen bedeutsamen Fortschritt repräsentieren, und würde an diesen beiden Fronten keinerlei Rückschritte machen wollen.

Aber wie gesagt, auch Lean und Agile sind nicht der Königsweg, und wie bei jedem Tool muss man auch bei ihrer Nutzung klug vorgehen. Ich begegne zahllosen Teams, die für sich beanspruchen, den Lean-Prinzipien zu folgen; doch dann arbeiten sie monatelang an etwas, das sie als MVP bezeichnen, und sie haben wirklich keine Ahnung, was sie da haben und ob es sich verkaufen wird, bis sie eine Menge Zeit und Geld hineingesteckt haben – was kaum im Sinne der Lean-Prinzipien sein dürfte. Oder sie schießen weit übers Ziel hinaus und glauben, sie müssten alles testen und validieren, sodass sie sich total verzetteln.

Und wie ich gerade erläutert habe, wird Agile in den meisten Produktunternehmen auf eine Art angewendet, die rein gar keinen erkennbaren Bezug zu Agile-Methoden aufweist.