Digitales Produktmanagement: Methoden – Instrumente – Praxisbeispiele [1. Aufl.] 9783658306281, 9783658306298

Citation preview

Sascha Hoffmann Hrsg.

Digitales Produktmanagement Methoden – Instrumente – Praxisbeispiele

Digitales Produktmanagement

Sascha Hoffmann (Hrsg.)

Digitales Produktmanagement Methoden – Instrumente – Praxisbeispiele

Hrsg. Sascha Hoffmann Professur für Online-Management Hochschule Fresenius Hamburg, Deutschland

ISBN 978-3-658-30628-1 ISBN 978-3-658-30629-8  (eBook) https://doi.org/10.1007/978-3-658-30629-8 Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar. © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Jede Verwertung, die nicht ausdrücklich vom Urheberrechtsgesetz zugelassen ist, bedarf der vorherigen Zustimmung des Verlags. Das gilt insbesondere für Vervielfältigungen, Bearbeitungen, Übersetzungen, Mikroverfilmungen und die Einspeicherung und Verarbeitung in elektronischen Systemen. Die Wiedergabe von allgemein beschreibenden Bezeichnungen, Marken, Unternehmensnamen etc. in diesem Werk bedeutet nicht, dass diese frei durch jedermann benutzt werden dürfen. Die Berechtigung zur Benutzung unterliegt, auch ohne gesonderten Hinweis hierzu, den Regeln des Markenrechts. Die Rechte des jeweiligen Zeicheninhabers sind zu beachten. Der Verlag, die Autoren und die Herausgeber gehen davon aus, dass die Angaben und Informationen in diesem Werk zum Zeitpunkt der Veröffentlichung vollständig und korrekt sind. Weder der Verlag, noch die Autoren oder die Herausgeber übernehmen, ausdrücklich oder implizit, Gewähr für den Inhalt des Werkes, etwaige Fehler oder Äußerungen. Der Verlag bleibt im Hinblick auf geografische Zuordnungen und Gebietsbezeichnungen in veröffentlichten Karten und Institutionsadressen neutral. Planung/Lektorat: Imke Sander Springer Gabler ist ein Imprint der eingetragenen Gesellschaft Springer Fachmedien Wiesbaden GmbH und ist ein Teil von Springer Nature. Die Anschrift der Gesellschaft ist: Abraham-Lincoln-Str. 46, 65189 Wiesbaden, Germany

Geleitwort

Digitale Produkte gibt es schon lange. Aber erst seit Beginn ihrer intensiven Kommerzialisierung in den 2000er Jahren breiten sie sich immer schneller aus und verankern sich tief in unserem Leben. Ohne digitale Produkte funktioniert mittlerweile wenig: E-Mails, Online-Shopping, Messenger, Navigation, Streaming von Musik und Filmen, bargeldloses Bezahlen, Reisebuchungen, Car-Sharing oder Online-Banking sind prominente Beispiele. Und selbst wer bewusst auf Smartphone oder Laptop und damit auf Teilhabe am digitalen Leben verzichtet, ist indirekt auf digitale Produkte angewiesen, denn bei genauer Betrachtung stehen auch hinter nahezu jeder physischen Ware digitale Prozesse, ohne die Herstellung, Vertrieb und Logistik kaum noch denkbar wären. Zusammen mit der massiven Verbreitung digitaler Produkte ist über die letzten Jahrzehnte ein völlig neues Berufsfeld entstanden: das digitale Produktmanagement. Während digitale Produkte anfänglich stark IT-getrieben entwickelt wurden, ist im Laufe der Zeit und im Spannungsfeld von neuen technologischen Möglichkeiten und sich schnell wandelnden Märkten und Geschäftsmodellen ein komplexes Berufsbild entstanden. Dieses ist durch eine eigene Kultur, Sprache und Arbeitsweise gekennzeichnet und befindet sich nach wie vor in einem steten Wandel. Obwohl wir alle die Ergebnisse der Arbeit von digitalen Produktmanagern täglich nutzen, ist für Außenstehende schwer nachzuvollziehen, wie ein digitales Produkt entsteht und was ein digitaler Produktmanager genau macht. Außerdem stößt man selbst mit jahrelanger praktischer Erfahrung als digitaler Produktmanager immer wieder auf neue Fragestellungen und ungelöste Probleme. Grund genug also für dieses Buch, in dem erfahrene Produktmanager jeweils einen Teilaspekt des digitalen Produktmanagements tiefer ausleuchten. Da es nicht das digitale Produktmanagement gibt, sondern Methoden, Ansätze und Fragestellungen immer ein Ergebnis der eigenen Einstellung, der jeweiligen Organisation und der externen Rahmenbedingungen sind, haben die Autoren diverse Hintergründe und in den unterschiedlichsten digitalen Branchen gearbeitet. Auf diese Weise vermittelt das Buch einen breiten Überblick. Je nach persönlichem Hintergrund wird man beim Lesen unterschiedliche Dinge mitnehmen. Interessierte Nutzer digitaler Produkte bekommen ein besseres Verständnis V

VI

Geleitwort

für die komplexe und vielschichtige Arbeit, die notwendig ist, um eine erste Idee in ein fertiges Produkt zu verwandeln. Angehende digitale Produktmanager können sich schnell einen umfassenden Überblick über unterschiedliche Methoden und Ansätze verschaffen oder auch einzelne Punkte gezielt nachschlagen. Und erfahrenen Produktmanagern bietet das Buch viele hilfreiche Anregungen sowie praktische Tipps für die tägliche Arbeit. Dr. Christian Becker Produktmanagement- & Discovery-Coach sowie u. a. Gründer der leanproductable GmbH

Vorwort

Die Digitalisierung verändert die Welt, in der wir leben, gravierend. Das Internet, Smartphones und seit ein paar Jahren das Internet of Things, also die Erweiterung von physischen Gütern mit digitalen Zusatzfunktionalitäten, schaffen immer neue digitale Produkte und Services für uns. Mit Apple, Alphabet (Google), Microsoft, Amazon und Facebook stammen inzwischen die fünf wertvollsten Unternehmen alle aus der Digitalbranche. Und neben den großen Tech-Giganten aus dem Silicon Valley drängen weltweit unzählige weitere Digitalunternehmen und Start-ups mit innovativen Geschäftsmodellen auf den Markt. Dadurch sind auch traditionelle Unternehmen gezwungen, sich digital zu transformieren, um künftig noch eine Rolle zu spielen. Die Entwicklung digitaler Produkte, wie Websites, Apps bzw. allgemein Software, ist damit zu einer Kernfunktion in Unternehmen geworden. Gleichzeitig hat sich in den letzten Jahren die Art, wie die Entwicklung digitaler Produkte betrieben wird, stark gewandelt. So findet kein Abarbeiten eines einmal aufgestellten Anforderungskatalogs und Projektplans mehr statt. Stattdessen hat sich eine agile Vorgehensweise etabliert, um eine marktgerechte, d.h. nutzerzentrierte Produktentwicklung sicherzustellen. Die agile Entwicklung digitaler Produkte verändert aber nicht nur die Arbeitsweise der Programmierer. Sie impliziert auch eine neue Art des Produktmanagements. Das aktive Managen von Produkten ist an sich nichts Neues: Bereits seit Jahrzehnten ist es fester Bestandteil in der betriebswirtschaftlichen Literatur, z. B. in Form der Produktpolitik im Marketing. Und auch der Beruf des Produktmanagers existiert schon lange. Im digitalen Kontext unterscheidet sich das Aufgabenspektrum von Produktmanagern jedoch z. T. deutlich von ihrer primär kaufmännisch geprägten, „klassischen“ Ausgestaltung. So reicht ihr Verantwortungsbereich von der initialen Identifikation von Neuproduktideen und der Validierung ihres nutzer- sowie unternehmensseitigen Potentials, über die Spezifikation der Anforderungen und die Steuerung ihrer Umsetzung bis hin zu einer nachhaltig erfolgreichen Weiterentwicklung der digitalen Produkte. Im Produktmanagement geht es also neben der wirtschaftlichen Optimierung vor allem auch um die technologische Umsetzbarkeit von digitalen Produkten, die aus Nutzersicht wirklich gewünscht sind – und für die eine Zahlungsbereitschaft existiert.

VII

VIII

Vorwort

Ein Produktmanager ist damit ganzheitlich für die inhaltliche Ausgestaltung und Weiterentwicklung „seines“ Produktes verantwortlich. Besonders deutlich wird dies im agilen Scrum-Framework, in dem die Rolle als „Product Owner“ explizit vorgesehen ist – eine Bezeichnung, die z. T. auch in Unternehmen verwendet wird, die ihre digitale Produktentwicklung mit anderen agilen Methoden organisieren. Produktmanager haben eine sehr verantwortungsvolle und vielseitige Position im Unternehmen, für die sie über ein breites Methodenwissen und ein ausgeprägtes zwischenmenschliches Fingerspitzengefühl verfügen müssen. Produktmanager werden am Markt gesucht. Aufgrund einer weitgehend fehlenden institutionalisierten Ausbildung und den gleichzeitig sehr vielfältigen Anforderungen übersteigt die Nachfrage das vorhandene Angebot an qualifizierten Produktmanagern um ein Vielfaches. Unternehmen versuchen, diese Bedarfslücke u. a. dadurch zu schließen, dass sie kommunikative Softwareentwickler bzw. IT-affine Betriebswirte aus ihren Reihen zu Produktmanagern weiterbilden. Hier setzt das Buch an, indem es beschreibt, wie digitales Produktmanagement erfolgreich eingesetzt wird. Dazu wird im ersten Beitrag zunächst eine grundlegende Einordnung des digitalen Produktmanagements gegeben, und es werden die zentralen agilen Produktmanagementkonzepte sowie ausgesuchte Methoden und Tools vorgestellt. Dadurch erhalten Einsteiger einen praxisnahen Überblick, was sie in der Welt der digitalen Produktentwicklung erwartet. In den anschließenden Beiträgen geben ausgewiesene Experten auch fortgeschrittenen Lesern durch Best-Practise-Beispiele und konkrete Handlungsempfehlungen wertvolle Anregungen, um sich in dem sehr umfangreichen und vielseitigen Feld des digitalen Produktmanagements weiterzuentwickeln. In dem Beitrag von Inken Petersen geht es dazu zunächst um die Art, wie eine nutzerzentrierte Produktvision im Team entwickelt werden kann und anschließend auch wirklich im Unternehmensalltag präsent ist. Der Beitrag von Alexander Hipp und Philip Steen erläutert, wie wichtig eine intensive Product Discovery ist, um die wirklich relevanten Nutzerprobleme zu verstehen und darauf basierend Erfolg versprechende Lösungsideen zu entwickeln. Bevor die Lösungsideen direkt auf die Product Roadmap kommen, sollte ihre Tragfähigkeit jedoch zunächst noch validiert werden. Welche Aspekte dabei zu beachten sind und welche Tools sich sinnvoll einsetzen lassen, beschreibt Anna Wicher in ihrem Beitrag. Produktmanagement bedeutet immer auch Schnittstellenmanagement mit vielen unterschiedlichen Stakeholdern in einem Unternehmen. Dies ist nicht immer frei von Zielkonflikten und persönlichen Befindlichkeiten. Gerade deshalb ist eine gute, vertrauensvolle Abstimmung ein wesentlicher Erfolgsfaktor. Wie dieses sog. Alignment gut funktionieren kann, zeigt Arne Kittler in seinem Beitrag auf. Auch bei Sonja Mewes geht es um Alignment und die Priorisierung von Produktideen, indem sie beschreibt, wie sich mithilfe des populären Objektives- & Key-ResultsAnsatzes Product Roadmaps mit den übergeordneten Unternehmenszielen wirkungsvoll verbinden lassen.

Vorwort

IX

Tim Adler berichtet in seinem Beitrag zur Product Delivery, welche kleinen und großen Herausforderungen sich bei der eigentlichen Produktentwicklung im Alltag ergeben, und gibt konkrete Tipps, die den Alltag eines Produktmanagers erleichtern. Daran anschließend zeigt Tim Herbig, wie es einem Produktmanager durch Lateral Leadership möglich ist, Produktteams zu führen und seine Produktthemen gegenüber anderen Stakeholdern im Unternehmen durchzubringen, ohne eine formale Führungsposition inne zu haben. Wird das digitale Produktmanagement in einem Unternehmen nach dem ­Scrum-Konzept umgesetzt, so gibt es neben dem Product Owner auch noch einen Scrum Master, der das Produktteam unmittelbar unterstützen und steuern soll. Jan Köster beschreibt, wie eine gute und vertrauensvolle Zusammenarbeit zwischen Scrum Master und Product Owner gelingen kann, von der das gesamte Produktteam enorm profitiert. Inken Petersen erläutert im Anschluss in ihrem zweiten Buchbeitrag, wie wichtig eine gute User Experience, also ein positives Nutzungserlebnis, für den Erfolg digitaler Produkte ist, und sie gibt praktische Hinweise, wie das Zusammenspiel zwischen Produktmanagern und den UX-Experten gelingt. Auch bei Jan Martens geht es um eine bereichsübergreifende Zusammenarbeit, indem er für zahlreiche Fallstricke sensibilisiert, die zu Missverständnissen in der Zusammenarbeit zwischen Produktmanagern und Data Analytics-Experten in Unternehmen führen können. Markus Andrezak erläutert in seinem Beitrag, wie allgegenwärtig – und schwierig – die Forderung nach immer mehr Wachstum für Produktmanager ist, die ja nicht nur für die Neuentwicklung, sondern auch für die erfolgreiche Weiterentwicklung „ihrer“ Produkte verantwortlich sind. Patrick Roelofs gibt schließlich einige Hinweise, wie aus einem guten ein herausragender Produktmanager werden kann, indem er den Blick von reinen Methoden- und Toolkenntnissen auf eine ganzheitliche Sicht weitet. Das Buch endet mit einer Case Study zur Hanseatic Bank, in der Matthias Blaß aufzeigt, wie sich aus dem Produktmanagement heraus die gesamte Organisation des Unternehmens agil transformiert, um für die Herausforderungen der Zukunft möglichst gut aufgestellt zu sein. Das Buch wäre ohne tatkräftige Unterstützung nicht gelungen. Mein besonderer Dank gilt zunächst natürlich meinen Co-Autoren, ohne deren großes Engagement neben ihren eigentlichen Berufen das Buch nie entstanden wäre. Darüber hinaus danke ich Marisa Kühn und Kira Röhle, die in mühevoller Kleinarbeit die zahlreichen Grafiken erstellt bzw. überarbeitet haben. Zudem bedanke ich mich sehr bei Imke Sander vom Springer-Gabler-Verlag für die unkomplizierte Zusammenarbeit und das sorgfältige ­ Lektorat. Und schließlich geht ein großes Dankeschön an meine Familie, die mir während der vielen Abende und Wochenenden, die es brauchte, um das Buch von der ersten Idee bis zum letzten Schliff zu einem guten Ende zu bringen, den Rücken freigehalten hat.

X

Vorwort

Im Namen aller Autorinnen und Autoren wünsche ich Ihnen viel Freude beim Lesen der Beiträge sowie Erfolg beim Übertragen der Erkenntnisse auf die eigene Arbeits- und Erfahrungswelt. Dabei bitte ich Sie, liebe Leserinnen und Leser, um Verständnis, dass feminine und maskuline Formen im Buch nicht beide erwähnt werden, sondern bei Verwendung der einen Form die andere immer mit gemeint ist. Ergänzende Hinweise zum Buch und spannende Neuigkeiten zum digitalen Produktmanagement finden Sie unter www.digitales-produktmanagement.de. Hamburg, im Juni 2020

Sascha Hoffmann

Inhaltsverzeichnis

1

Einführung in das digitale Produktmanagement. . . . . . . . . . . . . . . . . . . . . . 1 Sascha Hoffmann 1.1 Produktmanagement vs. Projektmanagement. . . . . . . . . . . . . . . . . . . . . 1 1.2 Digitales Produktmanagement mit Scrum. . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Digitales Produktmanagement mit Kanban. . . . . . . . . . . . . . . . . . . . . . . 18 1.4 Weitere agile Methoden im digitalen Produktmanagement. . . . . . . . . . . 23 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2

Nutzerzentrierte Produktvisionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Inken Petersen 2.1 Was ist eine Produktvision?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 2.2 Warum man eine Produktvision braucht. . . . . . . . . . . . . . . . . . . . . . . . . 31 2.3 Woran man eine gute Produktvision erkennt. . . . . . . . . . . . . . . . . . . . . . 32 2.4 Tools zur Erstellung einer guten Produktvision. . . . . . . . . . . . . . . . . . . . 33 2.4.1 Das Vision Statement. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4.2 Das Product Vision Board. . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.4.3 Das Product Vision Template. . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.4.4 Der Visiontype. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 2.5 Der Visions-Workshop. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.5.1 Die richtige Vorbereitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 2.5.2 Der Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 2.5.3 Nach dem Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 2.6 Woran man erkennt, dass die Produktvision funktioniert . . . . . . . . . . . . 39 2.7 Ein kurzer Ausblick zum Schluss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3

Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Alexander Hipp und Philip Steen 3.1 Ziele von Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

XI

XII

Inhaltsverzeichnis

3.2

Grundprinzipien einer Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . 46 3.2.1 Outcome-Orientierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 3.2.2 Nutzerzentrierung und Problemfokussierung . . . . . . . . . . . . . 47 3.2.3 Iteratives und experimentelles Vorgehen. . . . . . . . . . . . . . . . . 47 3.2.4 Interdisziplinarität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3 Ausprägungen einer Product Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.1 Projektbezogene Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.3.2 Kontinuierliche Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.4 Frameworks zur Strukturierung einer Product Discovery. . . . . . . . . . . . 51 3.4.1 Design Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4.2 Product Kata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.4.3 Opportunity Solution Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 3.5 Product Discovery Toolbox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.6 Praktische Hinweise zur Anwendung einer Product Discovery im Unternehmen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.6.1 Folgen einer Fokussierung auf die Product Delivery. . . . . . . . 58 3.6.2 Potentielle Stolpersteine bei der Einführung von Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 3.6.2.1 Fremdbestimmung von Produktteams. . . . . . . . . . 59 3.6.2.2 Output statt Outcome . . . . . . . . . . . . . . . . . . . . . . 60 3.6.2.3 Kein regelmäßiger Austausch mit dem User. . . . . 60 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4

Validierung von Produktideen am Markt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Anna Wicher 4.1 Warum Validierung?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 4.1.1 Worum wird es hier gehen?. . . . . . . . . . . . . . . . . . . . . . . . . . . 65 4.1.2 Wie lange dauert so eine Validierung normalerweise? . . . . . . 65 4.1.3 Was für ein Team brauche ich zur Validierung?. . . . . . . . . . . . 66 4.2 Research – Womit fangen wir an?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 4.2.1 Hypothesen – Was nehmen wir bisher an? . . . . . . . . . . . . . . . 67 4.2.2 Marktanalyse und Zielgruppendefinition – Worauf beziehen sich unsere ersten Annahmen?. . . . . . . . . . . . . . . . . 69 4.2.3 Qualitativer Research – Was sagt die Zielgruppe?. . . . . . . . . . 69 4.2.4 Quantitative Validierung – Wie viele gibt es davon?. . . . . . . . 71 4.2.5 MVP-Definition und Ressourcenbedarf – Was brauchen wir zum Testen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.2.6 Design vs. Technik – Worauf liegt der Fokus bei der MVP-Erstellung?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 4.3 Prototyping – Was bauen wir jetzt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.3.1 Testplan & Feature-Definition – Was wollen wir wissen und was brauchen wir dafür?. . . . . . . . . . . . . . . . . . . . . . . . . . 76

Inhaltsverzeichnis

XIII

4.3.2 4.3.3

UX und UI – Wie soll das MVP aussehen?. . . . . . . . . . . . . . . 79 Entwicklung – Wie und mit welcher Technologie wird das MVP umgesetzt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.3.4 Team – Wer baut das? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 4.3.5 Zeitabschätzung – Wie lange brauchen wir dafür? . . . . . . . . . 82 4.4 Testing – Wie kommen wir an die Zahlen?. . . . . . . . . . . . . . . . . . . . . . . 83 4.4.1 Launch- & Marketing-Plan – Wer testet das MVP? . . . . . . . . 83 4.4.2 Pivot – Alles noch mal neu?. . . . . . . . . . . . . . . . . . . . . . . . . . . 84 4.4.3 KPIs & Businessplan – Verdienen wir jetzt damit Geld? . . . . 85 4.5 Und wie geht’s jetzt weiter?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 5 Alignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Arne Kittler 5.1 Warum ist Alignment wichtig im Kontext moderner Produktentwicklung?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 5.1.1 Alignment schafft Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . 88 5.1.2 Alignment hilft Ressourcenverschwendung zu vermeiden. . . 88 5.1.3 Alignment hilft Entscheidungen herbeizuführen. . . . . . . . . . . 89 5.2 Mit wem sollte man sich als Produktmanager aktiv abstimmen?. . . . . . 90 5.3 In welchen Kontexten ist Alignment besonders wichtig? . . . . . . . . . . . . 90 5.4 Wann sollte eine systematische Abstimmung am sinnvollsten erfolgen? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5 Welche Vorgehensweisen helfen bei der Abstimmung?. . . . . . . . . . . . . . 91 5.5.1 Die richtigen Gesprächspartner in der richtigen Reihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 5.5.2 Sinnvolle Konstellationen und Methoden für eine aktive Abstimmung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 5.6 Wichtige zu klärende Fragen im Rahmen der Abstimmung . . . . . . . . . . 93 5.6.1 Ausgangslage aus Nutzerperspektive. . . . . . . . . . . . . . . . . . . . 93 5.6.2 Zielbild aus Nutzerperspektive . . . . . . . . . . . . . . . . . . . . . . . . 93 5.6.3 Hypothesen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.6.4 Input – und Rollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5.6.5 Output – und Grenzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.6.6 Outcome – und Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.7 Konflikte identifizieren und zur Klärung bringen . . . . . . . . . . . . . . . . . . 96 5.8 Abstimmung in der Praxis: Auftragserklärung bei XING. . . . . . . . . . . . 97 5.8.1 Ursprung und Entwicklung der Auftragsklärung. . . . . . . . . . . 98 5.8.2 Wesentliche Artefakte und übliche Praktiken . . . . . . . . . . . . . 98 5.8.3 Einführung, Anwendung und Missverständnisse. . . . . . . . . . . 100 5.9 Grenzen sinnvoller Abstimmung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

XIV

Inhaltsverzeichnis

6

Wirkungsorientiertes Produktmanagement mit OKR. . . . . . . . . . . . . . . . . 103 Sonja Mewes 6.1 Herausforderungen für Produktorganisationen. . . . . . . . . . . . . . . . . . . . 103 6.2 Einführung in Objectives & Key Results. . . . . . . . . . . . . . . . . . . . . . . . . 105 6.2.1 Objectives. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106 6.2.2 Key Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.2.3 Der OKR-Zyklus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108 6.2.4 Die OKR-Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.2.5 Der OKR-Check-in . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.2.6 Die OKR-Reflektion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.3 Vorteile von OKR für Produktteams. . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.4 OKR im Produktmanagement-Alltag . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.5 OKR-Fallbeispiel Analytico. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 6.5.1 Erstes OKR-Quartal bei Analytico. . . . . . . . . . . . . . . . . . . . . . 115 6.5.2 Zweites OKR-Quartal bei Analytico. . . . . . . . . . . . . . . . . . . . 116 6.5.3 Drittes OKR-Quartal bei Analytico. . . . . . . . . . . . . . . . . . . . . 117 6.5.4 Viertes OKR-Quartal bei Analytico. . . . . . . . . . . . . . . . . . . . . 118 6.6 Résumé: Wirksamkeit benötigt aktives Handeln. . . . . . . . . . . . . . . . . . . 119 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

7

Product Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Tim Adler 7.1 Los geht’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 7.2 Was man braucht, bevor es losgeht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.2.1 MVP vs. MLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.2.2 Features dokumentieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 7.2.3 Erstmal „hübsch“ machen – Design vorbereiten. . . . . . . . . . . 124 7.3 Vorher wissen, was es kosten wird. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.3.1 Klassisches Projektmanagement FTW . . . . . . . . . . . . . . . . . . 127 7.3.2 Eine Idee von Teamgröße. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 7.3.3 Zeit- und damit Kostenabschätzung. . . . . . . . . . . . . . . . . . . . . 128 7.3.4 Was tun, wenn es zu teuer oder zu langsam ist? . . . . . . . . . . . 130 7.4 Werkzeugkasten einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 7.4.1 Noch mehr Vorbereitung, ernsthaft? . . . . . . . . . . . . . . . . . . . . 131 7.4.2 Einen Namen wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.4.3 Backlog vorbereiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.4.4 Sprint-Board einrichten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135 7.5 Marathon laufen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 7.5.1 Sprintlänge wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

Inhaltsverzeichnis

XV

7.5.2

7.6

Meetings, Meetings, Meetings… sind der Sprint . . . . . . . . . . 137 7.5.2.1 Sprintplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 7.5.2.2 Daily(-Standup). . . . . . . . . . . . . . . . . . . . . . . . . . . 140 7.5.2.3 Sprint-Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . 142 7.5.2.4 Retrospektive. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.5.3 Sind wir noch im Plan…? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.5.4 …und falls nicht, wie kommen wir wieder rein?. . . . . . . . . . . 144 Kleine Helferlein im Alltag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 7.6.1 Entwickler schreien „Refactoring!“. . . . . . . . . . . . . . . . . . . . . 145 7.6.2 Kundensupport schreit „Bugs!“. . . . . . . . . . . . . . . . . . . . . . . . 146

8

Lateral Leadership im Produktmanagement. . . . . . . . . . . . . . . . . . . . . . . . . 147 Tim Herbig 8.1 Das Missverständnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 8.2 Das emotionale Vakuum agiler Prozesse. . . . . . . . . . . . . . . . . . . . . . . . . 148 8.3 Autonomie durch Alignment herstellen. . . . . . . . . . . . . . . . . . . . . . . . . . 149 8.4 Das Mission Briefing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 8.5 Empathie als Schlüsselelement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 8.6 Abschließende Gedanken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

9

Product Owner und Scrum Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Jan Köster 9.1 Mehr als ein Rollenbild aus einem Framework. . . . . . . . . . . . . . . . . . . . 157 9.2 Wie eine gute Zusammenarbeit gelingen kann . . . . . . . . . . . . . . . . . . . . 158 9.2.1 Start with Why. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 9.2.2 Gemeinsame Visionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 9.2.3 Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 9.2.4 Agile Prinzipien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 9.2.5 Wann hören wir auf? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 9.2.6 Warum machst Du das so?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.2.7 Seid Partner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.2.8 Gemeinsame Rituale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 9.2.9 Euer PDCA-Zyklus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 9.2.10 Führen über Warum und Transparenz . . . . . . . . . . . . . . . . . . . 166 9.2.11 Führen über Haltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166 9.2.12 Gemeinsam geteilte Führung. . . . . . . . . . . . . . . . . . . . . . . . . . 167 9.3 Was folgt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

XVI

Inhaltsverzeichnis

10 User Experience verstehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Inken Petersen 10.1 Die Bedeutung eines positiven Nutzererlebnisses. . . . . . . . . . . . . . . . . . 171 10.2 Der iterative UX-Designprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 10.3 Die Kerndisziplinen im User Experience-Bereich. . . . . . . . . . . . . . . . . . 174 10.3.1 Der UX-Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 10.3.2 Der Visual Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 10.3.3 Der User Researcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 10.4 Die verschiedenen Arten von UX-Teams. . . . . . . . . . . . . . . . . . . . . . . . . 176 10.4.1 Das klassische UX-Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 10.4.2 Das „UX-Team of one“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 10.4.3 Das hybride „UX- & Visual-Design-Team“ mit separater User-Research-Dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 10.5 Die beste Organisationsform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 10.6 Die richtige Menge an UX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 10.7 Die Zukunft von UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 11 Data Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Jan Martens 11.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 11.2 Rollen und Organisationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 11.3 Die Fallstricke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 11.3.1 Die Feel-Good-Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 11.3.2 Die Rechtfertigungsanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . 185 11.3.3 Die Symptom-Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 11.3.4 Einfache Fragen, komplexe Antworten. . . . . . . . . . . . . . . . . . 186 11.3.5 Selbstüberschätzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 11.3.6 Selbstverliebtheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 11.3.7 Einfach falsch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 11.3.8 „Nicht signifikant“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189 11.3.9 Zu anspruchsvoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190 11.3.10 Fehlende Distanz – Sunk costs . . . . . . . . . . . . . . . . . . . . . . . . 191 11.3.11 Zu wenig Daten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 11.4 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 12 Growth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Markus Andrezak 12.1 Alle wollen Wachstum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193

Inhaltsverzeichnis

XVII

12.2 Wie lange dauert Wachstum?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 12.2.1 Henry Ford und das Model T. . . . . . . . . . . . . . . . . . . . . . . . . . 197 12.2.2 Das iPhone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 12.2.3 Digitale „Wachstumswunder“. . . . . . . . . . . . . . . . . . . . . . . . . 199 12.3 Wachstumssprünge in zwei Phasen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201 12.4 Modelle zum Wachstum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 12.4.1 Der Hockey-Stick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 12.4.2 Das 3-Horizonte-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 12.4.2.1 Horizont 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 12.4.2.2 Horizont 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208 12.4.2.3 Horizont 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 12.4.2.4 Das Zusammenspiel der Horizonte. . . . . . . . . . . . 209 12.5 Was müssen wir beherrschen, um Wachstum zu erreichen?. . . . . . . . . . 210 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 13 Produktmanagement ganzheitlich verstanden. . . . . . . . . . . . . . . . . . . . . . . . 213 Patrick Roelofs 13.1 Die Aufgaben des Produktmanagers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 213 13.1.1 Ergebnisdimension 1: Zufriedenheit der Nutzer mit dem Produkt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 13.1.2 Ergebnisdimension 2: Kommerzieller Erfolg des Produktes. . . 215 13.2 Der Produktmanager als proaktiver Beziehungsmanager . . . . . . . . . . . . 216 13.3 Der Produktmanager als herausragender Kommunikator. . . . . . . . . . . . 217 13.4 Der Produktmanager als „Entscheidungsmacher“. . . . . . . . . . . . . . . . . . 219 13.4.1 Klar formulierte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 13.4.2 Maximale Transparenz („Connecting the dots“). . . . . . . . . . . 220 13.4.3 Notwendige und sinnvolle Eskalationen. . . . . . . . . . . . . . . . . 221 13.5 Der Produktmanager als Antworten-Lieferant. . . . . . . . . . . . . . . . . . . . . 222 13.6 Der Produktmanager ist (klarer) Gedanken-Formulierer. . . . . . . . . . . . . 223 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 14 Die agile Transformation der Hanseatic Bank. . . . . . . . . . . . . . . . . . . . . . . . 227 Matthias Blaß 14.1 Über die Hanseatic Bank. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 14.2 Am Anfang steht die Erkenntnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 14.3 Ein wichtiger Impuls von oben . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230 14.4 Systeme, Prozesse und Kulturwandel . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 14.4.1 Mit dem Solution Lab beginnt das Abenteuer. . . . . . . . . . . . . 232 14.4.2 Die Zukunftswerkstatt begleitet den Wandel. . . . . . . . . . . . . . 234 14.4.3 Ein Open Banking Framework als technologische Basis . . . . 235 14.4.4 Mehr Eigenverantwortung – Die LernBank entsteht. . . . . . . . 236 14.4.5 Techniken & Tools für bessere Zusammenarbeit. . . . . . . . . . . 237

XVIII

Inhaltsverzeichnis

14.5 Ein Change über alle Bereiche. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 14.5.1 Acceleration Hub. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 14.5.2 People & Organisation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 14.5.3 Personal Loan & Deposit Business. . . . . . . . . . . . . . . . . . . . . 242 14.5.4 Payment & Financing Business. . . . . . . . . . . . . . . . . . . . . . . . 242 14.5.5 IT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 14.6 Zwischenfazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245

Herausgeber- und Autorenverzeichnis

Über den Herausgeber Sascha Hoffmann ist Professor für Betriebswirtschaftslehre und Online-Management an der Hochschule Fresenius in Hamburg. Er lehrt dort Fächer wie Digital Media, E-Commerce, Online-Marketing bzw. digitales Produktmanagement. Zuvor war er u. a. für XING und blau Mobilfunk in leitender Funktion im Business Development und Produktmanagement tätig. Mehr unter www.hoffmann-sascha.de. Kontakt: [email protected]

Autorenverzeichnis Tim Adler  Greenhouse Innovation Lab, Hamburg, Deutschland Markus Andrezak  überproduct GmbH, Potsdam, Deutschland Matthias Blaß  Hanseatic Bank GmbH & Co KG, Hamburg, Deutschland Tim Herbig  Erfurt, Deutschland Alexander Hipp  Neobank N26, Barcelona, Spanien Sascha Hoffmann  Hochschule Fresenius, Hamburg, Deutschland Arne Kittler  New Work SE (XING), Hamburg, Deutschland Jan Köster  G+J Digital Media, Hamburg, Deutschland Jan Martens  Lotto24 AG, Hamburg, Deutschland Sonja Mewes  Beautiful Future, Erfurt, Deutschland Inken Petersen  Hamburg, Deutschland

XIX

XX

Herausgeber- und Autorenverzeichnis

Patrick Roelofs  Lotto24 AG, Hamburg, Deutschland Philip Steen  IDALABS GmbH & Co. KG, Kiel, Deutschland Anna Wicher  G+J Innovation GmbH, Hamburg, Deutschland

1

Einführung in das digitale Produktmanagement Einordnung und Grundkonzepte Sascha Hoffmann

Zusammenfassung

Der einführende Beitrag geht zunächst auf die grundlegenden Unterschiede zwischen der klassischen, projektbasierten und der agilen Entwicklung digitaler Produkte ein und stellt dabei die Vorteile einer agilen Vorgehensweise dar. Im Anschluss daran wird Scrum, als die in der Praxis dominierende agile Entwicklungsmethode, im Detail erläutert. Mit Kanban wird danach eine andere, ebenfalls sehr populäre Methode beschrieben, bevor zum Schluss im Überblick auf weitere genutzte Mischformen sowie Weiterentwicklungen agiler Methoden zur digitalen Produktentwicklung eingegangen wird.

1.1 Produktmanagement vs. Projektmanagement Die Entwicklung digitaler Produkte (Apps, Websites bzw. allgemein Softwarelösungen) erfolgte lange Zeit vorwiegend in klassischer Projektform, indem der Entwicklungsprozess in einzelne, nacheinander zu durchlaufende Phasen eingeteilt wurde. Diese Vorgehensweise wird als Wasserfall-Methode bezeichnet (Abb. 1.1). Bei der Wasserfall-Methode findet zu Beginn des Entwicklungsprojekts eine genaue Festlegung der zu entwickelnden Produkteigenschaften statt. Dazu werden in einer Analysephase im Detail die Anforderungen der Stakeholder an das neue Produkt zusammengetragen. Ist diese Phase abgeschlossen, werden in der Planungs- bzw. Konzeptionsphase

S. Hoffmann (*)  Hochschule Fresenius, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_1

1

2

S. Hoffmann

Anforderungsanalyse Konzeptentwicklung Development Test & Review Release Zeit

Abb. 1.1   Schematischer Ablauf einer wasserfallartigen Produktentwicklung. (Quelle: Eigene Darstellung)

die Spezifikationen für das zu entwickelnde digitale Produkt abgeleitet und in einem ausführlich beschriebenen Anforderungskatalog schriftlich fixiert. Dieser dient in der Folge als Pflichtenheft für das Entwicklerteam. Im Anschluss daran startet erst die eigentliche Programmierung in der Development-Phase, die bei größeren Projekten durchaus mehrere Monate oder gar Jahre dauern kann, da sie oft noch einmal in Unterphasen (Entwurf, Implementierung etc.) unterteilt ist. Ist die Entwicklung vollständig abgeschlossen, folgt vor der Markteinführung i. d. R. noch eine Test- bzw. ReviewPhase, bei der überprüft wird, ob das Produkt fehlerfrei und dem Lastenheft der Auftraggeber entsprechend umgesetzt wurde. Ist dies der Fall, wird das Produkt im letzten Projektschritt dem Auftraggeber übergeben (englisch: deployed) bzw. live genommen (englisch: released) (Laudon et al. 2016). Ein Entwicklungsprojekt im klassischen Sinne ist bereits dann erfolgreich abgeschlossen, wenn sämtliche Anforderungen innerhalb des vorgegebenen Zeit- und Budgetrahmens umgesetzt wurden, also der geforderte Output geliefert wurde. Im digitalen Produktmanagement ist der Erfolg dagegen erst dann gegeben, wenn das Produkt von den Nutzern auch wirklich angenommen wird und zu einer positiven Verhaltensänderung führt (Outcome). Im Produktmanagement geht es daher sehr stark darum, das Risiko zu minimieren, ein Produkt am Markt vorbei zu entwickeln. Dabei wird sich bewusst eingestanden, dass niemand allein auf der Basis einer vermeintlich guten Produktidee vorhersagen kann, dass ein Produkt später erfolgreich sein wird. Dies gilt umso mehr in der heutigen dynamischen und komplexen Zeit (Neuberger 2018).

1  Einführung in das digitale Produktmanagement

u

3

Zur Beschreibung der sich schnell ändernden Umwelt- und Marktverhältnisse wird oft von einer VUCA-Welt gesprochen wird. Dieses Akronym steht für Volatility (Volatilität bzw. Flüchtigkeit), Uncertainty (Unsicherheit bzw. Ungewissheit), Complexity (Komplexität) und Ambiguity (Mehrdeutigkeit) und beschreibt die schwierigen Rahmenbedingungen unter denen Menschen bzw. Organisationen Entscheidungen treffen müssen (Mack et al. 2015).

Die vermeintliche Planungssicherheit des klassischen Projektmanagements entpuppt sich also vielfach als Scheinsicherheit. Selbst die detailliertesten Spezifikationen am Anfang eines Projektes können nur ungenau und lückenhaft sein. Markveränderungen, technische Neuerungen, Gesetzesänderungen usw. führen entlang des Entwicklungsprozesses regelmäßig dazu, dass sich die Anforderungen an das zu entwickelnde Produkt ändern. Im klassischen Projektmanagement wird dies jedoch erst am Ende bemerkt, wenn das neue Produkt vom Markt nicht angenommen wird bzw. durch beispielsweise zwischenzeitlich geänderte Vorgaben erst gar nicht live gehen kann. Dies bedeutet im Extremfall, dass das Entwicklungsprojekt wieder von vorne beginnen muss, indem man mit einer erneuten Analyse der veränderten Anforderungen startet. Im Produktmanagement wird dagegen akzeptiert, dass zu Beginn der Softwareentwicklung noch nicht alle Parameter bekannt sind und während der Entwicklung neue Anforderungen hinzukommen können sowie ursprünglich angenommene sich verändern oder auch wegfallen können. Nach dem Cynefin-Framework von David Snowden (2000) handelt es sich also um eine komplexe Problemsituation, bei der Ursache-Wirkungs-Zusammenhänge zu Beginn noch nicht klar sind (vgl. zum ­Cynefin-Framework im Kontext des digitalen Produktmanagements ausführlich Kap. 9 von Jan Köster). Im Gegensatz zum klassischen Projektmanagement hat sich daher im digitalen Produktmanagement eine andere Art der Produktentwicklung durchgesetzt: sie findet inkrementell bzw. agil statt. Das bedeutet, dass entlang des gesamten Entwicklungsverlaufs das Produkt schrittweise entwickelt wird und regelmäßig das Feedback der Stakeholder, insbesondere der späteren Nutzer, eingeholt wird, um zu validieren, dass die verfolgte Lösung auch wirklich noch den aktuellen Anforderungen und Bedürfnissen des Marktes entspricht. Das Ergebnis jeder Feedbackschleife beeinflusst dabei unmittelbar die weitere Produktentwicklung (Abb. 1.2). Ganz neu ist diese Art der agilen Produktentwicklung jedoch nicht. So wurde bereits in den 90er Jahren des vergangenen Jahrtausends das sog. Extreme Programming als eine der ersten agilen Methoden durch Kent Beck entwickelt (Beck 2000). Im Jahr 2001 wurde methodenübergreifend das Manifest für Agile Softwareentwicklung (www. agilemanifesto.org) verfasst, das als konzeptioneller Rahmen gilt. Darin wurden vier grundlegende Werte sowie daraus abgeleitet zwölf Prinzipien aufgestellt, wie digitale Produkte entwickelt werden sollten.

4

S. Hoffmann

Vision

Zeit

Abb. 1.2   Schematischer Ablauf einer agilen Produktentwicklung. (Quelle: Eigene Darstellung)

u

Die vier grundlegenden Werte des agilen Manifests lauten: 

1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge. 2. Funktionierende Software ist wichtiger als eine umfassende Dokumentation. 3. Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen mit ihm. 4. Die Reaktion auf Veränderungen ist wichtiger als das strikte Befolgen eines Plans. (Beck et al. 2001) Oberstes Ziel ist es, ein funktionierendes Produkt bereitzustellen, das am Markt auch wirklich angenommen wird. Um dies zu erreichen ist u. a. eine enge, vertrauensvolle Zusammenarbeit mit dem Kunden notwendig und die aufrichtige Bereitschaft, jederzeit offen für Anforderungsänderungen im Entwicklungsprozess zu sein. Dies bedeutet natürlich nicht, dass bei einer agilen Entwicklung ohne Plan bzw. Strukturen vorgegangen wird. Sie sind jedoch nicht Selbstzweck, sondern kommen nur zum Einsatz, sofern sie dazu beitragen, die Produktentwicklung zu verbessern. u

„The Agile movement is not anti-methodology […]. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.“ (Beck et al. 2001, o. S.)

1  Einführung in das digitale Produktmanagement

5

Während klassische Projekte meist mit temporären, projektspezifisch zusammengesetzten Teams umgesetzt werden, wird im digitalen Produktmanagement mit langfristig zuständigen Teams (Dedicated Teams) gearbeitet, die jeweils für ein bestimmtes Produkt bzw. einen Produktbereich verantwortlich sind (Neuberger 2018). Um diesen Produktteams auch wirklich eine „Ownership“ für ihr Produkt bzw. das zu lösende Nutzerproblem zu geben und um sie zu motivieren, sollen sich die Mitglieder selbst organisieren dürfen, in einem inspirierenden Umfeld arbeiten können und über persönliche Gespräche sicherstellen, dass innerhalb des Teams eine größtmögliche Transparenz bezüglich der Projektziele, des jeweiligen Status quos und der jeweils aktuellen Anforderungen besteht. Zudem soll das Team in regelmäßigen Abständen seine Prozesse und sein Verhalten reflektieren, um so seine Zusammenarbeit kontinuierlich zu verbessern und eine technische Exzellenz sicherzustellen (Epping 2011; Beck et al. 2001). Für die konkrete Umsetzung einer agilen Produktentwicklung wurden unterschiedliche Methoden entwickelt, die jedoch alle auf den agilen Prinzipien von kurzen Planungszyklen, einer iterativen Entwicklung, regelmäßigen Tests und institutionalisiertem Feedback basieren.

1.2 Digitales Produktmanagement mit Scrum Scrum wurde von Jeff Sutherland und Ken Schwaber, die beide auch zu den Erstunterzeichnern des Agilen Manifests gehören, Anfang der 1990er Jahren entwickelt und 1995 erstmalig auf der OOPSLA-Konferenz in Austin (Texas) präsentiert. Ursprünglich wurde Scrum für die Entwicklung von komplexen digitalen Produkten konzipiert. Die Anwendung von Scrum ist heutzutage aber nicht mehr nur auf die digitale Produktentwicklung beschränkt, sondern wird zunehmend auch in vielen anderen Bereichen von Unternehmen eingesetzt (Schwaber und Sutherland 2017). u

„Scrum ist weder ein Prozess, noch eine Technik oder [eine] vollständige Methode. Vielmehr ist es ein Rahmenwerk, innerhalb dessen verschiedene Prozesse und Techniken zum Einsatz gebracht werden können. Scrum macht die relative Wirksamkeit Ihres Produktmanagements und Ihrer Arbeitstechniken sichtbar, damit Sie fortlaufend das Produkt, das Team und die Arbeitsbedingungen verbessern können.“ (Schwaber und Sutherland 2017, S. 3.)

Kerngedanke von Scrum ist, dass die Produktentwicklung von selbst organisiert agierenden Teams in einem iterativen, inkrementellen Prozess erfolgt. Auf diese Weise sollen die Prognosesicherheit für einen späteren Markterfolg optimiert und die Risiken in der Produktentwicklung kontrolliert werden. Innerhalb eines Scrum-Teams gibt es

6

S. Hoffmann

als explizit angelegte Rollen den Product Owner, den Scrum Master sowie das idealerweise zwischen drei und neun Personen umfassende, interdisziplinäre Entwicklerteam (Schwaber und Sutherland 2017). Der Product Owner ist für den marktseitigen Erfolg „seines“ (!) Produkts verantwortlich. Er legt die Eigenschaften des Produkts fest, spezifiziert diese und sorgt dafür, dass die Entwickler das Produkt bestmöglich umsetzen. Er ist dabei nicht nur für die Neuproduktentwicklung zuständig, sondern hat vielmehr die Aufgabe, das Produkt entlang des gesamten Lebenszyklus erfolgreich zu managen. Er hat damit eine ganzheitliche Sicht aus den Blickwinkeln Wirtschaft, Technologie und vor allem Markt- bzw. Nutzbedürfnisse auf sein digitales Produkt, s. Abb. 1.3. Um in dieser Schnittstellenposition erfolgreich zu sein, tauscht sich der Product Owner regelmäßig mit den anderen Stakeholdern des Produktes aus, um deren Wünsche und Bedürfnisse zu verstehen (Neuberger 2014). Für seine anspruchsvolle Aufgabe erhält der Product Owner Unterstützung von einem Scrum Master, der als „Servant Leader“ das gesamte Scrum-Team dabei unterstützt, seine Zusammenarbeit zu optimieren und außerhalb des Teams hilft zu verstehen, wie das Scrum-Team arbeitet, um es vor störenden Einflüssen zu schützen. Konkret organisiert und moderiert der Scrum Master den Großteil der Scrum-Meetings, coacht das Team, um in der Interaktion besser zu werden und sorgt dafür, dass Hindernisse, welche die Entwickler vom Programmieren abhalten, möglichst beseitigt werden (Petersen 2017; Jungwirth 2016); siehe dazu auch Kap. 9 von Jan Köster. Um ein Produkt zielgerichtet zu entwickeln, sollte der Product Owner eine Vision für das Produkt aufstellen. In der Produktvision wird der Mehrwert des künftigen Produkts im Kern beschrieben, indem sie die zentralen Produkteigenschaften grob skizziert und ein mit der Entwicklung des Produktes verfolgtes, motivierendes Ziel formuliert (zur Produktvision s. ausführlich Kap. 2 von Inken Petersen). Eine Möglichkeit, die

Markt/Nutzer (User Experience)

Technologie

Business

Abb. 1.3   Das Aufgabenspektrum eines Produktmanagers. (Quelle: In Anlehnung an Eriksson 2011)

1  Einführung in das digitale Produktmanagement

7

Produktvision zu visualisieren, stellt ein Product Vision Board dar, auf dem die Zielgruppe, deren Bedürfnisse sowie das Produkt und seine Wirtschaftlichkeit auf einen Blick skizziert sind (Abb. 1.4). Auf dem Product Vision Board wird zunächst die grundlegende Idee in einem prägnanten Satz als Vision Statement formuliert. Zudem wird die Zielgruppe, die mit dem Produkt angesprochen werden soll, spezifiziert, und es werden ihre Wünsche und Bedürfnisse skizziert, die mit dem Produkt adressiert werden sollen. Im Bereich „Produkt“ geht es dann darum, die drei bis fünf wichtigsten Eigenschaften des zu entwickelnden Produkts aufzuschreiben, mit denen die Bedürfnisse der Zielgruppe – besser als mit anderen ggf. bereits am Markt existierenden Lösungen – befriedigt werden sollen. Im letzten Abschnitt wird schließlich das Erlösmodell für das Unternehmen aufgeführt (Pichler 2014). Damit das Produkt im Unternehmen die benötigten Ressourcen und positive Aufmerksamkeit bekommt, ist es von enormer Bedeutung, dass die Produktvision vom gesamten Unternehmen mitgetragen wird. Um dies zu erreichen, sollte der Product Owner die Produktvision möglichst in enger Abstimmung mit dem Entwicklerteam und den übrigen Stakeholdern entwickeln. Das Product Vision Board ist dabei ein gutes Vehikel, das der Product Owner nutzen kann, um die Produktvision zu visualisieren und damit ins Unternehmen zu transportieren. In einer agilen, nutzerzentrierten Produktentwicklung stellen sowohl die Produktvision als Ganzes wie auch die einzelnen Elemente zunächst nur Hypothesen dar. Es muss daher überprüft werden, ob es auch wirklich echte Nutzer in einer ausreichend großen Zahl gibt, die das skizzierte Produkt haben möchten, damit für das Unternehmen ein wirtschaftlicher Erfolg erwartbar ist. Von den Hypothesen sollten dabei zunächst die grundlegenden unbekannten Aspekte der Produktvision validiert werden, um möglichst rasch die Unsicherheiten bei der Produktentwicklung abzubauen. Diese können sich u. a.

Vision Target Group

Needs

Product

Business Goals

Abb. 1.4   Product Vision Board. (Quelle: In Anlehnung an Pichler 2014)

8

S. Hoffmann

auf die Zielgruppenbedürfnisse, die wirtschaftlichen Annahmen aber auch die technische Umsetzbarkeit beziehen (Cagan 2016). Insbesondere bei größeren, grundlegenden Produktneuentwicklungen wird dazu vor der eigentlichen Produktentwicklung eine eigene Discovery-Phase vorgeschaltet (zur Product Discovery s. ausführlich Kap. 3 von Alexander Hipp und Philip Steen). In der Praxis besteht für den Product Owner hierbei oft die Herausforderung, dem Management zu verdeutlichen, dass die Discovery-Phase ergebnisoffen ist. Das bedeutet, dass sich bei der Discovery durchaus auch herausstellen kann, dass die Produktidee in den Augen der Zielgruppe doch nicht so brillant ist wie gedacht, oder die Marktchancen kleiner sind als ursprünglich angenommen. Auch kann sich in der Discovery-Phase ergeben, dass sich für das identifizierte Nutzerproblem keine technische Lösung finden lässt, die in einem wirtschaftlichen Verhältnis für das Unternehmen steht (Cagan 2007). Während es für Pharmazieunternehmen Normalität ist, dass der Großteil der Arzneiinnovationen sich während der Discovery-Phase doch als nicht marktfähig herausstellt, ist diese Denkweise in der Digitalbranche deutlich seltener anzutreffen. Dort wird oftmals statt einer echten, ergebnisoffenen Product Discovery leider nur eine Konkretisierung der ursprünglichen Produktidee vorgenommen – ein Umstand, bei dem sich zu Recht fragen lässt, wie ehrlich Agilität in den Unternehmen gelebt wird und der sich durchaus im weiteren Verlauf der Produktentwicklung bzw. spätestens beim Product-Launch rächen kann (Gibbert 2013). In der Discovery-Phase stehen dem Product Owner zahlreiche Methoden und Tools zur Verfügung, die je nach Fragestellung genutzt und ggf. angepasst werden. Idealerweise hilft bei der Auswahl und Anwendung der richtigen Tools ein User ­Experience-Experte (vgl. zur Rolle von UX-Teams in der digitalen Produktentwicklung ausführlich Kap. 10 von Inken Petersen). u User Experience (UX) meint das Nutzungserlebnis einer (digitalen) Anwendung durch einen Nutzer, d. h. seine Erfahrungen vor, während und nach der Interaktion. Die Usability (Nutzerfreundlichkeit), also insbesondere die grafische Bedienbarkeit einer Anwendung (User Interface, UI), ist dabei nur ein Teil der UX. Zur UX gehören auch die Zusammenhänge und Prozesse zwischen Produkt, Unternehmen, Kundenkommunikation etc. Um eine gute User Experience zu gewährleisten, analysieren UX-Experten zuvor intensiv die Nutzerbedürfnisse, wofür ihnen eine ganze Reihe an Methoden zur Verfügung steht (Vgl. zu User Experience und den UX-Methoden ausführlich Jacobsen und Meyer 2019 sowie Ulrich et al. 2016). Populär ist es, sich dabei z. B. am Design Thinking-Prozess zu orientieren. Beim Design Thinking (Kelley 2001) geht es zunächst darum, den Problemraum zu verstehen, d. h. herauszufinden, ob das vermutete bislang nicht bzw. nur unzureichend adressierte Kundenbedürfnis wirklich besteht. Hierfür ist es wichtig, dass der Product Owner und idealerweise auch weitere Mitglieder des Scrum-Teams mit Menschen aus der Zielgruppe in den Austausch kommen. Idealerweise besteht die Möglichkeit, die Menschen

1  Einführung in das digitale Produktmanagement

9

in ihrer normalen Lebenswirklichkeit zu beobachten, um so ihre Routinen und bisherigen Lösungswege zu verstehen. Ergänzend dazu helfen qualitative Nutzerinterviews, um die hinter den Handlungen liegenden Gründe und Motive zu verstehen. Übergeordnetes Ziel ist es, ein tieferes Verständnis und möglichst sogar echte Empathie für die Zielgruppe aufzubauen (Grots und Pratschke 2009). Um das Wissen aus der User-Analyse für das gesamte Scrum-Team zugänglich zu machen und so ein einheitliches Verständnis aufzubauen, ist es wichtig, die Erkenntnisse zu dokumentieren, was oft in Form von Visualisierungen geschieht. Eine beliebte Methode ist dabei die Anfertigung von Personas. Darauf aufbauend kann man den erhobenen Handlungsablauf z. B. als Customer Journey Map bzw. Customer Empathy Map bei der aktuellen Problemlösung visualisieren (vgl. dazu ausführlich Jacobsen und Meyer 2019). u Personas sind repräsentative, realitätsnah beschriebene Prototypen der Zielgruppe. Die in Form von Steckbriefen inkl. Namen und Foto visualisierten Personas geben der Zielgruppe ein Gesicht und helfen dem Team im weiteren Verlauf, die Zielgruppe, für die es das Produkt entwickelt, „greifbar“ zu machen (Cooper 1999). Ein weiterer weit verbreiteter Ansatz, um die qualitativen Ergebnisse zu synthetisieren, ist, für die Personas ein Value Propositon Canvas (Osterwalder et al. 2014) auszufüllen, um deren Wünsche und Bedürfnisse sowie den erhofften Mehrwert und die befürchteten Sorgen zusammenzutragen (s. Abb. 1.5). Erst nachdem der Problemraum von allen Teammitgliedern wirklich erfasst wurde, geht es im Design Thinking-Prozess daran, Lösungsansätze zu erarbeiten (die sich auf der linken Seite der Value Proposition Canvas systematisiert erfassen lassen). Dabei werden im ersten Schritt viele unterschiedliche Ideen entwickelt, um einen möglichst breiten Lösungsraum aufzuspannen. Zur Inspiration können hierfür alle möglichen Kreativitätstechniken, wie etwa das klassische Brainstorming, zum Einsatz kommen. Im Anschluss daran werden im Team die erfolgversprechendsten Ideen ausgewählt und in Form von Prototypen „erfahrbar“ gemacht, um sie bei der Zielgruppe

Gain Creators

Gains Customer Job(s)

Products & Services

Pain Relievers

Pains

Abb. 1.5   Value Proposition Canvas. (Quelle: In Anlehnung an Osterwalder et al. 2014)

10

S. Hoffmann

zu validieren (vgl. zur Validierung ausführlich Kap. 4 von Anna Wicher). Prototypen sollen schnell umzusetzen und günstig zu entwickeln sein und können unterschiedlich detailliert ausgearbeitet sein: von einfachen Zeichnungen (Scribbles), mit Lego-Steinen gebaute Szenarien bis hin zu Wireframes, Mockups bzw. interaktiven Click-Dummies (Grots und Pratschke 2009). u Wireframes sind gegenüber ersten einfachen und oft per Hand erstellten Scribbles (englisch für Gekritzel) Layouts, die schon deutlich detaillierter und mit realistischen Proportionen zueinander versehen sind. Farben, Schriftarten und Effekte fehlen dagegen noch. Bei Mockups sind diese Designelemente zusätzlich berücksichtigt, sodass sie bereits wie ein fertiges Produkt anmuten. Click-Dummies als letzte Detaillierungsstufe sind sogar schon interaktiv, wobei sie sich in der Regel auf wenige Detailseiten beschränken und noch nicht den vollen Produktumfang simulieren (Jacobsen und Meyer 2019; Gläser 2014). Die erstellten Prototypen werden in Usability-Tests vom (Ziel-)Nutzer bewertet. Dabei sollen sie nicht nur helfen, die Lösungsideen zu validieren, sondern vor allem als Ideengeber dienen, um zu verstehen, warum etwas (nicht) funktioniert. Dafür kommen vor allem qualitative Erhebungsmethoden, wie der Thinking-Aloud-Ansatz sowie Eyebzw. Mousetracking-Verfahren, zum Einsatz, um detaillierte Einschätzungen von den Nutzern zu erhalten. Beim Thinking-Aloud-Ansatz sind die Testnutzer angehalten, ihre Gedanken laut auszusprechen, während sie den Prototypen nutzen. Dadurch soll nachvollzogen werden, welche Aspekte vom Nutzer ggf. nicht bzw. falsch verstanden werden und wo er Stärken bzw. Schwächen in der vorgestellten Lösung sieht. Beim Eyetracking werden den Probanden am Bildschirm die digitalen Prototypen in Form von Mockups bzw. Click-Dummies gezeigt und es wird aufgezeichnet, wohin ein Nutzer blickt und wie er sich auf den Testseiten verhält. Ein sehr ähnliches Verfahren ist das Mousetracking, bei dem die Bewegungen des Cursors oder auch Touch-Gesten erfasst werden, wodurch ein onlinebasiertes Testen möglich ist (Jacobsen und Meyer 2019). Abhängig vom Nutzerfeedback werden die Prototypen weiterentwickelt, variiert oder aber auch verworfen bis ein potenziell marktfähiges Produkt gefunden wurde. Dieses Vorgehen entspricht dem Build-Measure-Learn-Zyklus des validierten Lernens aus dem Lean Startup-Konzept von Steve Blank und Eric Ries (Ries 2011), das in der digitalen Produktentwicklung und im Startup-Umfeld ein festes Grundprinzip darstellt. Wenn die Discovery-Phase erfolgreich verlief und sich ein konkreter Produktansatz als Erfolg versprechend erwiesen hat, muss der Product Owner das zu entwickelnde Produkt auf die Product Roadmap bringen. Die Product Roadmap ist ein Planungswerkzeug für einen mittelfristigen Zeitraum von 12 bis 18 Monaten. Sie enthält die wesentlichen zu erstellenden Produkt-Features bzw. -versionen. Streng genommen ist die Product Roadmap kein Bestandteil von Scrum, gleichwohl ist sie sehr hilfreich in der Kommunikation mit den Stakeholdern. Insbesondere, um mit dem Top-Management die Unternehmensziele und die Produktziele abzugleichen und gleichzeitig die für die

1  Einführung in das digitale Produktmanagement

11

Produktentwicklung notwendigen Investitionsentscheidungen und damit verbundenen Ressourcenallokationen abzustimmen (Pichler 2014). Um alle Stakeholder inkl. Scrum-Team wirklich „abzuholen“, sollte der Product Owner die Product Roadmap im Dialog erstellen und abstimmen. Nur so erhält er das für eine erfolgreiche Umsetzung notwendige individuelle Commitment1 und ein echtes organisationales Alignment. Alignment meint, dass ein Team bzw. eine Organisation ein gemeinsames Bewusstsein für die Relevanz eines Themas hat und ein einheitliches Bild vom geplanten Umsetzungsergebnis besitzt (Drath et al. 2008). Nur, wenn das tatsächlich gegeben ist, können Product Owner und Scrum-Team das Produkt eigenständig umsetzen. Um diese „Autonomy through alignment“ herzustellen, wurde beispielsweise bei XING das Canvas der Auftragsklärung (www.auftragsklaerung.com) entwickelt und in der Product-Community verbreitet (s. hierzu ausführlich Kap. 5 von Arne Kittler). u

„[A]utonomy is not something you claim – it’s something you can only earn through successful alignment with stakeholders, peers and within your team. We believe that good alignment should be a collaborative effort during which • the tricky questions about an upcoming initiative are discussed early • the underlying thinking of an initiative is sharpened for clarity of intent • the results are made transparent to get everyone ‘on the same page’“. (New Work SE o. J.)

Die eigentliche Entwicklung des digitalen Produkts findet in der Delivery-Phase statt (vgl. hierzu ausführlich Kap. 7 von Tim Adler). Ziel der agilen Produktentwicklung ist es dabei, möglichst frühzeitig und regelmäßig funktionierende Software auf dem Markt zu veröffentlichen (englisch: to release). Dafür wird in Scrum ein Produkt inkrementell, d. h. in mehreren, aufeinander aufbauenden Versionen entwickelt, um so frühzeitig das Marktfeedback zu einer veröffentlichten Version als Input für die Entwicklung der nächsten Versionen einfließen zu lassen. Die erste Version des Produkts wird nach Ries (2011) als Minimum Viable Product (MVP) bezeichnet und soll sich auf die notwendigsten Produktmerkmale (englisch: Features) beschränken (Krasadakis 2019; Gibbert 2014).2

1Um

ein Produkt tatsächlich zu realisieren, muss jeder Einzelne dazu bereit sein und sich verpflichtet fühlen (englisch: to commit), seinen jeweiligen Beitrag zur Zielerreichung zu leisten (Drath et al. 2008; Conner 2012). 2Die Idee, ein digitales Produkt möglichst rasch zu veröffentlichen, um Marktfeedback einzusammeln und darauf basierend das Produkt inkrementell weiterzuentwickeln, ist nicht neu, sondern wurde bereits 1988 von Gilb postuliert.

12

S. Hoffmann

u „Your minimum viable product is comprised of the least amount of

functionality necessary to solve a problem sufficiently such that your customer will engage with your product and even pay for it, if that’s your revenue model.“ (Cooper und Vlaskovits 2013, S. 173.) Für eine reibungslose Product Discovery besteht eine der Hauptaufgaben für den Product Owner in Scrum darin, das sog. Product Backlog zu pflegen. Darin enthalten sind alle Aufgaben, die vom Entwicklerteam abgearbeitet werden müssen, um das Produkt weiterzuentwickeln. Das Product Backlog entspricht damit vom Grundsatz dem Lastenheft aus der traditionellen Produktentwicklung, weist allerdings in der Handhabung signifikante Unterschiede auf: Im Unterschied zum Lastenheft stellt das Product Backlog ein „lebendes“ Objekt dar, das vom Product Owner während der gesamten ­Delivery-Phase laufend angepasst wird. Neue Anforderungen werden als zusätzliche Einträge ins Product Backlog aufgenommen und bestehende Einträge werden, u. a. aufgrund von Nutzerfeedback, Rückmeldungen vom Entwicklerteam usw., angepasst, neu priorisiert oder auch gelöscht (Pichler 2014). Wie die einzelnen Einträge im Product Backlog aussehen sollen, ist im ­Scrum-Framework nicht spezifiziert. In der Praxis werden hierfür meist User Stories genutzt. Eine User Story besteht aus drei Teilen: einer prägnanten Bezeichnung, einer kurzen Beschreibung der Anforderung sowie einem bzw. mehreren Akzeptanzkriterien. Die Beschreibung ist nicht technisch, sondern aus Nutzersicht formuliert und soll dem Entwicklerteam klarmachen, was mit der Umsetzung der User Story erreicht werden soll. Akzeptanzkriterien erläutern relevante Details für die Umsetzung und stellen Anforderungen dar, die bei der Softwareentwicklung erfüllt werden müssen, damit die User Story erfolgreich umgesetzt worden ist. Der Grundaufbau einer User Story lautet: „Als [Anwender] möchte ich [Aktion], um [Ziel].“ (Cohn 2004). Für eine gute User Story gilt, dass sie den INVEST-Kriterien entspricht. INVEST ist ein Akronym und steht für: Independent (die User Story ist möglichst nicht von anderen User Stories abhängig), Negotiable (bis zur vollständigen Entwicklung können noch Anpassungen an ihr vorgenommen werden), Valuable (die User Story besitzt einen Wert für den User), Estimable (der Entwicklungsaufwand ist schätzbar), Small (die User Story ist innerhalb eines Sprints umsetzbar) und Testable (die Erfüllung der Akzeptanzkriterien ist objektiv überprüfbar) (Epping 2011; Wake 2003). Beispiel für eine User Story:

• Bezeichnung: CSV-Export • Beschreibung: „Als Banking-App-Nutzer möchte ich die Transaktionsdaten als CSV-Datei herunterladen können, um damit z. B. in Excel Auswertungen zu erstellen.“

1  Einführung in das digitale Produktmanagement

13

• Akzeptanzkriterien: – Der Nutzer kann die Daten für jedes Konto herunterladen. – Es sind alle Werte in der CSV-Datei enthalten. – Der Nutzer kann sich die Daten für unterschiedliche Berichtszeiträume ausgeben lassen. (Herwarth von Bittenfeld 2010). ◄ Die Reihenfolge der Einträge im Product Backlog entspricht ihrer Priorität. Die wichtigsten Einträge stehen oben, sind am detailliertesten beschrieben und werden zuerst vom Entwicklerteam implementiert. Weniger wichtige Einträge sind dagegen oftmals noch gar nicht ausformuliert, sondern stehen als „Platzhalter“ am Ende des Product Backlog. Die Entwicklung der User Stories findet wiederum im Dialog zwischen Product Owner und den übrigen Stakeholdern statt. Dabei sollten nach Jeffries (2001) für eine User Story die drei Cs beachtet werden: Card, Conversation, Confirmation. Mit „Card“ ist gemeint, dass die User Story nur die Essenz des Kundenwunsches sowie die wichtigsten Punkte, die mit dem Entwicklerteam vereinbart wurden, enthalten soll, damit sie auf einer Papierkarte Platz finden kann (gleichwohl pflegt der Product Owner sein Product Backlog meist in Softwareprogrammen, wie z. B. Jira oder Trello von Atlassian). „Conversation“ bedeutet, dass jede User Story mindestens einmal, meist jedoch mehrfach mit dem Kunden und dem Team besprochen worden sein muss, bevor sie als hoch priorisierter Eintrag ins Product Backlog kommt. „Confirmation“ meint schließlich, dass für die spätere Abnahme der implementierten User Story Akzeptanzkriterien benannt werden, deren Einhaltung der Product Owner später überprüfen kann (Herwarth von Bittenfeld 2011). Die Priorisierung der User Stories stellt regelmäßig eine große Herausforderung für den Product Owner dar. Zentrale Kriterien sind der Business Value, ggf. vorhandene inhaltliche Abhängigkeiten, die Auslieferbarkeit sowie das Ausmaß an Unsicherheit einer User Story. Grundsätzlich sollten User Stories, die hoch priorisiert und damit zeitnah umgesetzt werden, einen hohen Business Value aufweisen (großer Nutzen für die Anwender, hoher wirtschaftlicher Erfolg für das Unternehmen). Je größer die Unsicherheit bei einer User Story ist, desto riskanter ist die erfolgreiche Entwicklung des Produkts. Risikobehaftete Einträge im Product Backlog sollten daher hoch priorisiert und frühzeitig angegangen werden, um schnell die Unsicherheit aus der Entwicklung zu nehmen (Fail-fast-Prinzip). Damit einher geht, dass Software möglichst früh und regelmäßig ausgeliefert werden sollte, um ein Marktfeedback zu erhalten und auf diese Weise ebenfalls das Risiko aus der Produktentwicklung zu nehmen. Schließlich sind bei der Priorisierung inhaltliche Abhängigkeiten zwischen User Stories von Bedeutung. Größere Themenbereiche (englisch: Themes) werden dabei in mehrere User Stories aufgespalten, wobei User Stories, auf die andere Einträge aufbauen, natürlich bei der Umsetzung vorgezogen werden müssen (Pichler 2014).

14

S. Hoffmann

Aktualisierung des Product Backlog

Daily Scrums

Product Backlog

Sprint Planning

Sprint (2-4 Wochen) Sprint Backlog

Sprint Review

Retrospecve Produktinkrement

Abb. 1.6   Der Scrum-Prozess. (Quelle: Eigene Darstellung)

Die eigentliche Produktentwicklung findet in sog. Sprints statt. Sprints sind feste Intervalle, die je nach Unternehmen zwischen einer und vier Wochen dauern.3 Sie sind Herzstück der agilen Produktentwicklung nach Scrum. Ziel ist es, innerhalb eines Sprints ein neues/weitergehendes funktionsfähiges Zwischenprodukt zu entwickeln. Dieses auch als Inkrement bezeichnete Zwischenprodukt umfasst alle Einträge aus dem Product Backlog, die während eines Sprints vollständig fertiggestellt worden sind (Schwaber und Sutherland 2017). Sprints folgen einem festen Ablauf mit mehreren Zeremonien (Meetings) sowie Artefakten (Dokumente), wie Abb. 1.6 zeigt. Vor jedem Sprint findet ein Sprint ­Planning-Meeting statt, bei dem festgelegt wird, welche Einträge aus dem Product Backlog im kommenden Sprint umgesetzt werden sollen. In dem Sprint PlanningMeeting, das vom Scrum Master moderiert wird, präsentiert und erläutert der Product Owner dem Entwicklerteam die User Stories aus dem Product Backlog, die von ihm am höchsten priorisiert wurden. Voraussetzung ist, dass die Stories wirklich von allen als „bearbeitbar“ angesehen werden (Definition of Ready). Eine Story ist „ready“, wenn alle Informationen vorliegen, die zur Entwicklung notwendig sind, und die Story so gut gefasst ist, dass sie in einem Sprint umsetzbar ist.4 Sollte eine User Story für ein Entwicklerteam mit zu vielen Unsicherheiten verbunden sein, um sie direkt entwickeln zu können, erstellt der Product Owner für die Exploration der Umsetzung einen eigenen Eintrag im Product Backlog und priorisiert ihn entsprechend.

3Ursprünglich

waren Sprints auf 30 Tage ausgelegt. Mittlerweile entwickeln die meisten Unternehmen jedoch in ein- bzw. zweiwöchigen Sprints. 4Wenn eine User Story nicht in einem einzelnen Sprint umsetzbar ist, handelt es sich um ein sog. Epic, das vom Product Owner in einzelne, miteinander verbundene Stories heruntergebrochen werden muss (Compounded Stories) (Rehkopf o. J.).

1  Einführung in das digitale Produktmanagement

15

Im Anschluss an die Vorstellung der User Stories bespricht das Entwicklerteam untereinander, wie die einzelnen Stories umzusetzen sind und welche entwicklungsseitigen Aufgaben (Tasks) zur Umsetzung erforderlich sind. Product Owner und Entwicklerteam einigen sich zudem darauf, anhand welcher Kriterien nach dem Sprint entschieden wird, ob die Umsetzung einer User Story erfolgreich abgeschlossen ist (Definition of Done). Nicht-funktionale Anforderungen an das zu entwickelnde Produkt, wie beispielsweise Performance-Vorgaben, werden als Nebenbedingungen (englisch: Contraints) formuliert. Allgemein gilt für die Definition of Done, dass für die User Stories am Sprint-Ende eine funktionierende und damit „veröffentlichungsfähige“ Software vorliegen muss, die getestet und dokumentiert ist. Was im Einzelfall unter „funktionierender Software“ zu verstehen ist, muss vom Product Owner jeweils spezifiziert werden und mit klar überprüfbaren Kriterien versehen werden, um bei der späteren Abnahme keine Qualitätskompromisse eingehen zu müssen, die sich auf die Performance des Produkts negativ auswirken (Schwaber und Sutherland 2017; Pichler 2014). Im nächsten Schritt findet eine Aufwandsschätzung (englisch: Sizing) der einzelnen User Stories durch das Entwicklerteam statt. Der Aufwand wird dabei in Story Points geschätzt, die relative Schätzwerte in Form einer nicht-linearen Zahlenfolge darstellen, z. B. 0, 1, 2, 3, 5, 8, 13, 20, 40.5 Führt ein Entwicklerteam erstmalig eine Aufwandsschätzung durch, einigt sich das Team zu Beginn auf eine mittelgroße Referenz-Story und gibt ihr beispielsweise den Story Point-Wert 3. Alle weiteren Stories werden nun in der Folge in Relation zu der Referenzstory bewertet. Eine verbreitete Methode zur Ermittlung der Story Points ist das Planning Poker. Jeder Softwareentwickler erhält dabei einen Kartenstapel, auf dessen Karten die möglichen Story Point-Werte vermerkt sind. Der Product Owner nimmt nicht an der Schätzung teil. Soll nun für eine User Story der Umsetzungsaufwand ermittelt werden, schätzt jeder Entwickler zunächst für sich den Aufwand und zieht eine entsprechende Pokerkarte. Haben alle ihre individuelle Schätzung vorgenommen, fordert der Scrum Master das Team auf, die Karten aufzudecken. Weichen die Schätzungen voneinander ab, werden die Entwickler mit den unterschiedlichsten Werten gebeten, ihre Einschätzung zu erläutern. Anschließend wird eine neue Runde Planning Poker gespielt, bis ein Konsens im Entwicklerteam gefunden wurde (Pichler 2014). Hat das Entwicklerteam alle hoch priorisierten Einträge im Product Backlog geschätzt, legt es gemeinsam mit dem Product Owner das jeweilige Sprint-Ziel fest und verpflichtet sich selber (englisch: to commit), wie viele Einträge es im kommenden Sprint umsetzen wird. Aus der mit den jeweiligen Story Points gewichteten Anzahl der

5Grundlage

der Story Point-Schätzung ist die sog. Fibonnacci-Zahlenfolge, bei der sich die jeweils folgende Zahl durch Addition ihrer beiden vorherigen Zahlen ergibt. Sie wurde von Cohn (2005) leicht modifiziert und für die Aufwandsschätzung in der digitalen Produktentwicklung eingeführt. Bei einer alternativen, ungenaueren Aufwandsschätzung werden für die einzelnen User Stories T-Shirt-Größen (Skala XS, S, M, L, XL, XXL) bestimmt (Wiegand 2015).

16

S. Hoffmann

zugesagten User Stories lässt sich dann die prognostizierte Geschwindigkeit (englisch: Velocity) des Scrum-Teams für den nächsten Sprint ermitteln, deren Vorhersagekraft in aller Regel nach ein paar Sprints hoch ist (Domin 2019; Schwaber und Sutherland 2017). u

Der Product Owner gibt über die Priorisierung des Product Backlogs vor, in welcher Reihenfolge die Einträge umgesetzt werden. Das Entwicklerteam legt mit der Aufwandschätzung fest, wie viele Einträge in einem Sprint tatsächlich realisiert werden.

Die vom Entwicklerteam für den nächsten Sprint zugesagten Einträge werden runtergebrochen auf ihre abgeleiteten Tasks in das Sprint Backlog als Tickets übernommen und der eigentliche Sprint kann beginnen. Das Sprint Backlog besteht aus drei Spalten, s. Abb. 1.7. Zu Beginn des Sprints stehen alle abzuarbeitenden Tickets in der ersten Spalte „To Do“. Wenn die Entwickler beginnen, einen Task zu bearbeiten, verschieben sie das entsprechende Ticket in die zweite Spalte „Doing“ (auch als „(Work) In Progress“ bezeichnet). Ist ein Task vollständig bearbeitet, wird das Ticket in die letzte Spalte „Done“ verschoben. Ziel ist, dass am Ende des Sprints sämtliche Tasks vom Sprint Backlog abgeschlossen sind und somit die Tickets in der Spalte „Done“ stehen. Für die Erstellung und Pflege des Sprint Backlogs stehen diverse Apps, wie Jira, Trello oder Github Projects, zur Verfügung. Es ist jedoch üblich, dass es zusätzlich – z. T. sogar ausschließlich – auch ein physisches Sprint Backlog-Board gibt, das im Arbeitsbereich des Scrum-Teams (englisch: Team Space) aushängt und an dem die einzelnen Tickets auf Post-its geschrieben in den jeweiligen Spalten hängen. Das Sprint Backlog-Board dient so der Transparenz über den Sprint-Fortschritt und fördert die teaminterne Kommunikation. Ergänzend wird häufig noch ein Burn-Down(-Up-)-Chart

Product Backlog 1. Eintrag 2. Eintrag

Sprint Backlog To Do

Doing

Done

1. Eintrag

3. Eintrag 4. Eintrag 5. Eintrag

2. Eintrag 3. Eintrag

... n. Eintrag

4. Eintrag

Abb. 1.7   Zusammenhang zwischen Product Backlog und Sprint Backlog. (Quelle: Eigene Darstellung)

1  Einführung in das digitale Produktmanagement

17

gepflegt, auf dem die im Zeitablauf des Sprints jeweils bereits umgesetzten Story Points visualisiert werden. Als selbstorganisiertes Team treffen sich die Entwickler täglich immer zur gleichen Uhrzeit zum Daily Scrum vor dem Sprint Backlog-Board, um sich gegenseitig ein Update über die erledigten und anstehenden Tickets sowie ggf. aufgetretene Hindernisse (englisch: Impediments) zu geben. Das Daily Scrum wird als Stand up-Meeting vom Scrum Master moderiert, folgt einer festgelegten Struktur und sollte maximal 15 min dauern. Im Daily Scrum geht es einzig darum, dass das Entwicklerteam einen einheitlichen Informationsstand über den Sprint-Verlauf hat; inhaltliche Diskussionen sind im Daily Scrum nicht vorgesehen. Das Daily Scrum ist ein entwicklerinternes Meeting, an dem der Product Owner oder gar andere Personen nur auf explizite Einladung teilnehmen (Schwaber und Sutherland 2017). u

Die Entwickler geben im täglichen Daily Scrum ihr Update standardisiert, indem sie folgende drei Fragen beantworten: 1. Was habe ich gestern getan, das dem Entwicklungsteam hilft, das ­Sprint-Ziel zu erreichen? 2. Was werde ich heute tun, um dem Entwicklungsteam beim Erreichen des Sprint-Ziels zu helfen? 3. Sehe ich ein Hindernis, das mich bzw. das Team daran hindert, das ­Sprint-Ziel zu erreichen?

(Schwaber und Sutherland 2017). Während des Sprints werden keine Änderungen vorgenommen, die das jeweilige Sprint-Ziel gefährden. Die Entwickler sollen sich voll auf die Umsetzung der im Sprint Planning-Meeting vereinbarten Product Backlog-Einträge fokussieren können. Der Scrum Master kümmert sich um mögliche Impediments und entlastet somit das Entwicklungsteam. Am Ende eines Sprints sollen sämtliche Tasks der vorgenommenen Einträge umgesetzt sowie erfolgreich in einer Testumgebung auf mögliche Programmierfehler überprüft worden sein und damit als potentiell auslieferfähiges Produktinkrement (englisch: potentially releasable product increment) vorliegen. Sollte das vereinbarte Sprint-Ziel aufgrund von veränderten Markt- bzw. technologischen Rahmenbedingungen oder einem übergeordneten Wechsel des Unternehmensziels obsolet sein, kann (nur!) der Product Owner im absoluten Ausnahmefall den laufenden Sprint abbrechen (Schwaber und Sutherland 2017). Jeder Sprint endet mit einem Sprint Review-Meeting. Darin präsentiert das Entwicklerteam dem Product Owner sowie allen weiteren anwesenden Stakeholdern die aus seiner Sicht fertiggestellten Sprint-Ergebnisse. Dies geschieht nicht mit Hilfe von PowerPoint-Folien oder Click Dummies o. ä., sondern das Ergebnis soll real am funktionierenden System vorgeführt werden. Das Produktinkrement ist zu dem Zeitpunkt

18

S. Hoffmann

aber natürlich noch nicht allgemein veröffentlicht, sondern läuft auf einer Testumgebung (Sandbox). Mit dem Sprint Review ist in Scrum ein in kurzen Zeitabständen regelmäßig stattfindendes Format verankert, in dem alle Stakeholder die Möglichkeit haben, sich über den jeweiligen Produktentwicklungsstatus zu informieren und dem ­ Scrum-Team Feedback zu geben. Ziel des Sprint Reviews ist es, zu verstehen, ob sich das Scrum-Team auf dem richtigen Entwicklungsweg befindet bzw. frühzeitig ggf. not­ wendige Anpassungen für das Produkt zu identifizieren, was als Trial-and-Error-Vorgehen Kern der agilen Arbeitsweise ist. Aufgabe des Product Owners im Sprint Review ist es zu überprüfen, ob die User Stories im abgelaufenen Sprint vom Entwicklerteam gemäß der vereinbarten Definition of Done-Kriterien umgesetzt wurden und ob das anvisierte Sprint-Ziel erreicht wurde. Sollte dies nicht der Fall sein, sind die User Stories abzulehnen und wandern als nicht erfolgreich umgesetzte Einträge wieder in das Product Backlog. Sofern das Produktinkrement vom Product Owner abgenommen wurde und keine sonstigen Einwände bestehen, wird es im Anschluss an die Sprint Review zur Veröffentlichung im Markt bereitgestellt (Deployment). Schließlich findet ein Abgleich zwischen der geplanten Sprint Velocity und der tatsächlich erreichten statt. Anders als der Name „Sprint“ vermuten lässt, ist es dabei jedoch nicht das Ziel, immer schneller in der Entwicklung zu werden, sondern es geht vor allem um eine langfristige Konstanz und Planbarkeit. Mit dem Sprint Review-Meeting endet der aktuelle Sprint und es startet unmittelbar der nächste (Pichler 2014). Nach dem Sprint-Ende wird eine Retrospektive durchgeführt. Dort reflektiert das Entwicklungsteam den letzten Sprint und schaut, welche prozessualen bzw. zwischenmenschlichen Aspekte in der Zusammenarbeit gut waren und welche verbessert werden können. Der Scrum Master lädt zur Retroperspektive ein und ist in dem Meeting ein gleichberechtigtes Mitglied, da er einen wesentlichen Anteil am organisationalen Ablauf des Sprints hatte. Am Ende der Retroperspektive vereinbaren Scrum Master und Entwicklerteam konkrete Verbesserungen für eine effektivere und zufriedenstellendere Arbeitsweise, deren Umsetzung im nächsten Sprint in der folgenden Retrospektive in Form einer Selbstüberprüfung kontrolliert wird (Schwaber und Sutherland 2017).

1.3 Digitales Produktmanagement mit Kanban Neben Scrum existieren einige weitere Methoden in der Praxis, wie digitale Produkte agil entwickelt werden. Im deutschsprachigen Raum ist insbesondere Kanban sehr populär, dessen Anwendung in der digitalen Produktentwicklung auf Anderson (2010) zurückgeht (Petereit 2017; Leopold und Kaltenecker 2013). Kanban wurde ursprünglich von Taiichi Ohno, einem Mitarbeiter bei Toyota in den 50er und 60er Jahren des vergangenen Jahrtausends mit dem Ziel entwickelt, einen

1  Einführung in das digitale Produktmanagement

19

gleichmäßigen „Fluss“ (englisch: Flow) in der Autoproduktion herzustellen und die vorhandenen Lagerbestände an Einzelteilen zu reduzieren. Vor dem Hintergrund der Kaizen-Philosophie6, was frei übersetzt „Veränderung zum Besseren“ bedeutet, entstand mit Kanban und einigen weiteren Methoden das Toyota Production System, aus dem in den 1980er Jahren das Lean Manufacturing hervorging (Dickmann 2007). Mit Kanban wurde bei Toyota das Problem gelöst, dass bei der Produktion eines Autos an einigen Stationen zu viele Produktionsteile herumlagen, während an anderen Stellen keine vorhanden waren und so die Herstellung einer Ausstattungsvariante zu viel Zeit in Anspruch nahm bzw. die Arbeit ggf. sogar vollständig zum Erliegen kam. Die Lösung bestand darin, jedes (Zwischen-)Lager mit einer Signalkarte (japanisch: Kanban) zu versehen, mit der ein Mitarbeiter zum Hauptlager geht, wenn das Zwischenlager auf eine zuvor festgelegte Anzahl an Teilen gesunken ist.7 Der Nachschub wird also vom jeweiligen Verbrauchsort „angefordert“, was als Pull-Prinzip kennzeichnend für Kanban ist (Dickmann 2007). In der digitalen Produktentwicklung weisen Kanban und Scrum viele Ähnlichkeiten auf. Ein wesentlicher Unterschied besteht darin, dass es in Kanban keine Sprints gibt. Die Entwicklung ist vielmehr ein kontinuierlicher „Fluss“. Zudem fokussiert sich Kanban konzeptionell auf die Organisation innerhalb des IT-Entwicklerteams, weshalb darin zunächst kein Product Owner vorgesehen ist. Gleichwohl wird in der praktischen Anwendung von Kanban heutzutage meist ein Product Owner, in Kanban auch als Service Request Manager bezeichnet, eingesetzt. Unterstützt wird das Entwicklerteam zudem häufig von einem Service Delivery Manager. Dieser entspricht dem Scrum Master, indem er u. a. die Zusammenarbeit des Teams fördern, Meetings organisieren sowie den Entwicklungsprozess dokumentieren und visualisieren soll. Anders als in Scrum müssen die beiden Rollen nach Anderson jedoch nicht zwingend neu eingeführt werden, sondern die Aufgaben können auch von bereits bestehenden Personen ausgeübt werden (Anderson 2016a). Auch in Kanban steht das selbstorganisierte, sich kontinuierlich verbessernde Miteinander im Vordergrund. Dafür werden organisationale Regeln im Team vereinbart. Hierzu zählt insbesondere die Regel, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen (Work in Progress, WiP). Es werden Höchstmengen definiert, die nicht überschritten werden dürfen, um sich auf die einzelnen Aufgaben ausreichend fokussieren zu können („Stop starting and start finishing!“ Roock 2012). Ist die maximale Anzahl an Aufgaben erreicht, an denen das Entwicklerteam gerade arbeitet, darf erst dann mit einer neuen Aufgabe begonnen werden, wenn eine andere fertiggestellt worden ist. Die Entwickler holen sich folglich ihre jeweils neuen Aufgaben, sobald sie Kapazitäten

6Das

Kaizen-Prinzip wird im Deutschen auch als „kontinuierlicher Verbesserungsprozess (KVP)“ beschrieben, vgl. hierzu ausführlich Fleig (2019). 7Auch heute noch kommt Kanban, wenngleich inzwischen mit RFID-Codes und BarcodeScannern, in vielen Produktionsprozessen zum Einsatz, vgl. hierzu ausführlich Dickmann (2007).

20

S. Hoffmann

frei haben. Dies ist die Umsetzung des oben ausgeführten Pull-Prinzips aus dem Produktionsprozess physischer Güter (Epping 2011). Organisiert werden die Aufgaben an einem Kanban Board. Dies kann entweder ein physisches Board sein, auf dem die Aufgaben mit Post-its geschrieben und verschoben werden, oder es kommen Softwareprogramme, wie Trello, Jira bzw. K ­ anban-spezifische Programme, wie Leankit oder Kanbanize, in Unternehmen zum Einsatz. Im elektronischen Fall wird das Board dann in Meetings gerne per Beamer für alle sichtbar gemacht. Wichtig ist in jedem Fall, dass die Teamaufgaben und der Bearbeitungsprozess visualisiert und somit für alle Stakeholder transparent sind (Millweber 2013). Analog zu Scrum wird das Kanban Board im einfachsten Fall in drei Spalten unterteilt: „To Do“, „(Work) In Progress“ und „Delivered“ bzw. „Done“. Häufig werden jedoch fünf Spalten verwendet, indem die WiP-Spalte weiter unterteilt wird in „Design“, „Development“ sowie „Testing“. Die Aufgaben in der Spalte „To Do“ werden in der Regel mit Prioritäten versehen, sodass ein Softwareentwickler nicht völlig frei entscheiden kann, welche Aufgabe er als nächstes aus der Spalte „To Do“ bearbeiten möchte. Die Priorisierung der einzelnen Aufgaben erfolgt u. a. über die Beschreibung des Servicetyps und ihrer jeweiligen Serviceklasse. Durch die Angabe des Servicetyps wird spezifiziert, um was für eine Art von Aufgabe es sich handelt. u

Bei den Servicetypes wird meist in „(New) Feature“ (neue Produkteigen­schaft), „Bug“ (Fehler) und „Change“ (Anpassung) unterschieden. ­Feature-Aufgaben werden wie bei Scrum in der Regel in Form von User Stories aufgeschrieben.

Die einzelnen Servicetypen können auf dem Kanban Board in separaten Zeilen (sog. Swimlanes) visualisiert werden. Dabei kann bei Bedarf für jede einzelne Swimlane eine WiP-Obergrenze vereinbart werden (Leopold und Kaltenecker 2013). Serviceklassen beschreiben, wie zeitnah etwas bearbeitet werden muss bzw. welche Kosten sich aus einer verzögerten Auslieferung ergeben würden (Cost of Delay). Üblicherweise wird dabei unterschieden in „Dringende Bearbeitung“, „Fester Liefertermin“, „Standard“ sowie „Unbestimmte Kosten“. Aufgaben, die als „dringend zu bearbeiten“ gekennzeichnet sind, sollten unmittelbar in Angriff genommen werden, weil sie anderenfalls zu hohen Kosten führen. Dies sollte jedoch die absolute Ausnahme sein, in der sogar das WiP-Limit überschritten werden darf, da bereits begonnene Arbeiten u. U. ruhen. Aufgaben, die zu einem festen Termin fertig sein müssen, rechtfertigen dagegen keine Überschreitung des WiP-Limits. Um dies sicherzustellen, wird der Aufwand dieser Aufgabenklasse geschätzt. Im Vergleich zu Scrum wird die Schätzung jedoch meist gröber durchgeführt, etwa indem T-Shirt-Größen (S, M, L, XL, XXL) als Bewertungsmaßstab herangezogen werden. Ist der Aufwand geklärt, kann die Bearbeitung rechtzeitig genug beginnen, um den benötigten Auslieferungstermin zu gewährleisten. Der Großteil der Aufgaben sollte als „Standard“ klassifiziert sein.

1  Einführung in das digitale Produktmanagement

21

Hier gilt als Bearbeitungsregel meist das FiFo-Prinzip (First in, First out). Aufgaben, bei denen die Kosten unbestimmt sind, stellen eine Art „Merkposten“ im Backlog dar. Es handelt sich dabei um Aufgaben, die irgendwann einmal erledigt werden müssen, z B. das Upgrade einer Software vorzunehmen. Sie werden nur bearbeitet, sofern keine Aufgabe mit einer höheren Serviceklasse gezogen werden muss bzw. wenn sie „akut“ werden und dadurch eine der anderen Serviceklassifizierungen erhalten. Neben den Servicetypen und Serviceklassen spielen bei der Priorisierung natürlich auch inhaltliche Abhängigkeiten der einzelnen Aufgaben eine wichtige Rolle. Aufgaben, von deren Bearbeitung andere Aufgaben abhängen, müssen natürlich bevorzugt umgesetzt werden (Leopold und Kaltenecker 2013). Um für mehr Transparenz gegenüber seinen Stakeholdern zu sorgen, kommuniziert das Entwicklerteam in Kanban vielfach grundsätzliche Service Level Agreements, d. h. erwartbare Durchlaufzeiten eines Aufgabentickets, die auf den bisherigen Erfahrungswerten beruhen. u

Service Level Agreements können für die einzelnen Servicetypen und Serviceklassen und deren jeweilige Aufwandsgrößen spezifiziert sein, z. B.: • Tickets der Serviceklasse „Standard“ mit der T-Shirt-Größe M werden zu 80 % innerhalb von 2 Wochen erledigt. • Tickets vom Servicetyp „Bug“ mit der Größe S werden zu 90 % innerhalb von 5 Werktagen erledigt. (Leopold und Kaltenecker 2013).

Tritt bei der Bearbeitung einer Aufgabe ein Problem auf, das nicht unmittelbar gelöst werden kann, erhält das Ticket einen „Blocker“-Vermerk am Kanban Board und ruht. Damit zählt die Aufgabe auch nicht zu der aktuellen Anzahl der in Bearbeitung befindlichen Aufgaben. Findet sich in der Folge eine Lösung für das Problem, wandert das Ticket zurück in die Spalte „To Do“ und kann erneut von einem Entwickler gezogen werden (Millweber 2018). Aufgrund des Pull-Prinzips ist in Kanban zudem die Definition of Done von zentraler Wichtigkeit. So muss grundlegend definiert sein, wann ein Design fertig ist, wann der Programmiercode final ist und wann ein Test abgeschlossen ist. Beispielhafte Definition of Done:

• Der Softwarecode ist fertig, mit Kommentaren versehen und lauffähig. • Der Code wurde von einem anderen Teammitglied überprüft. • Der Code enthält keine bekannten Fehler mehr. (Millweber 2018). ◄

22

S. Hoffmann

Die Definition of Done sollte für jede einzelne Spalte inkl. möglicher Unterspalten im Kanban Board definiert sein, damit klar ist, wann eine Aufgabe von einer Spalte in die nächste gezogen werden darf. Hierzu kann es sinnvoll sein, jede einzelne Spalte noch einmal zu zweiteilen in „In Progress“ und „Done“, um Missverständnisse zu vermeiden, ob eine Aufgabe bereits fertig ist, um in die nächste Spalte gezogen zu werden. In „Done“ werden dann stets alle Aufgaben von „In Progress“ verschoben, welche die Definition of Done erfüllt haben. Neue Aufgaben können von einem Entwickler „gezogen“ (Pull) werden, wenn sie sich in der Done-Spalte befinden, s. Abb. 1.8. Damit in Kanban der Arbeitsfluss optimal verläuft, bedarf es einer engen Abstimmung. Idealerweise erfolgt diese permanent, z. B. im Daily Standup-Meeting, das in Kanban ebenfalls vorgesehen ist, bzw. ad hoc im Bedarfsfall. Darüber hinaus haben sich als regelmäßige Meetingformate insbesondere das Replenishment-Meeting, das Release-Meeting sowie Teamretroperspektiven bewährt (Leopold und Kaltenecker 2013). Das Replenishment-Meeting („Nachschubmeeting“) findet meist alle ein bis zwei Wochen statt. Darin besprechen das Entwicklerteam und die Stakeholder, welche Aufgaben als nächstes zur Bearbeitung anstehen. Wichtig ist, dass dabei jedem klar ist, auf welcher inhaltlichen Basis die Priorisierung vorgenommen wird (Transparenz). Entwickelt ein Team Produkte für mehrere Stakeholder, kann der Abstimmungsprozess im Replenishment-Meeting durchaus komplex sein. Daher sollte es zeitlich begrenzt und vor allem gut moderiert werden (Singh 2017). Im Release-Meeting werden wie im Review-Meeting bei Scrum die fertiggestellten Aufgaben den Stakeholdern präsentiert. Anders als bei Scrum ist hierfür jedoch kein festes Intervall vorgesehen, wobei eine gewisse Regelmäßigkeit auf die Stakeholder vertrauensfördernd wirkt. Die Teamretrospektive schließlich hat wie in Scrum die Funktion, dass das Entwicklerteam die bisherige Zusammenarbeit regelmäßig Revue passieren lässt und nach Ansätzen für eine Verbesserung sucht.

Work in Progress

To Do Design In Progress

Done

Development In Progress

Done

Delivered Testing In Progress

Done

Abb. 1.8   Kanban Board mit Unterteilung „In Progress“ und „Done“. (Quelle: Eigene Darstellung)

1  Einführung in das digitale Produktmanagement

23

Diese regelmäßige, schrittweise Verbesserung des Kaizen-Prinzips ist Wesenszug von Kanban. Im Gegensatz zu Scrum muss bei einer Einführung von Kanban also nicht direkt das gesamte bestehende System der bisherigen digitalen Produktentwicklung umgekrempelt werden, sondern Veränderungen lassen sich evolutionär umsetzen. Kanban ist gerade darauf ausgelegt, auf jeder bestehenden Methode der digitalen Produktentwicklung aufzusetzen. Dies führt häufig dazu, dass es weniger Widerstände innerhalb des Entwicklerteams bzw. bei den Stakeholdern gegenüber Kanban gibt. So ist es in Kanban auch nicht notwendig, bestehende Jobprofile zu verändern bzw. abzuschaffen, sondern das Team kann entlang des Weges selber entscheiden, welche Veränderungen und ggf. neuen Rollen für sich am hilfreichsten sind (Anderson 2010, 2016a; Leopold und Kaltenecker 2013).

1.4 Weitere agile Methoden im digitalen Produktmanagement Scrum als dominierende agile Entwicklungsmethode im digitalen Produktmanagement weist wie beschrieben einen sehr festen und umfassenden Rahmen an Rollen und organisationalen Regeln auf. Unternehmen, die sich entschließen, Scrum einzuführen, stehen daher oft vor der Herausforderung, ihre bisherige Produktentwicklung sehr stark umzustellen. Hieran scheitern nicht wenige Organisationen. Noch viel häufiger hört man in der Praxis jedoch den Satz: „Wir arbeiten mit Scrum, aber…“. Eine im Jahr 2017 durchgeführte Studie der Scrum Alliance unter mehr als 2000 Mitgliedern ergab, dass in 78 % der Unternehmen Scrum in Kombination mit anderen Methoden eingesetzt wurde. Und selbst zentrale Meetings, wie das ­Sprint-Planning-Meeting bzw. das Daily Scrum wurden nur in 86 % bzw. 87 % der Unternehmen, die Scrum einsetzen, konsequent durchgeführt (Scrum Alliance 2018). Die unterschiedlichen Ab- und Aufweichungen von Scrum wurden von Ken Schwaber einmal zusammenfassend als „Scrum-But“ bezeichnet, wobei er und sein Mitbegründer Jeff Sutherland inzwischen auch von „Scrum-And“ sprechen, um das Grundgerüst von Scrum sinnvoll an die jeweiligen organisationalen Gegebenheiten optimal anzupassen (Schwaber 2012). Viele Unternehmen, für die eine strikte Anwendung von Scrum nicht sinnvoll erscheint, orientieren sich dabei in Richtung Kanban (Anderson 2016b; Ammons 2015). Für die digitale Produktentwicklung bedeutet dies, dass in den Unternehmen die unterschiedlichsten Formen und Mischungen von Scrum- und Kanban-Implementierungen gelebt werden. Das ursprünglich als Beschreibung für diese Mischform(en) erdachte Wort Scrumban (Scrum-ban, Ladas 2008) hat sich inzwischen zu einem eigenständigen Framework für die agile digitale Produktentwicklung entwickelt. Scrumban kommt aber auch und gerade bei der Implementierung einer agilen Arbeitsweise auf der Basis von Scrum außerhalb der Produktentwicklung zum Einsatz (Reddy 2015).

24

u

S. Hoffmann

„Scrumban is not about using just a few elements of both Scrum and Kanban to create a software development process. Rather, it emphasizes applying kanban systems within a Scrum context, and layering the Kanban Method alongside Scrum as a vehicle for evolutionary change.“ (Reddy 2015)

Von Scrum übernommen wurde in Scrumban, dass sich das Team weitgehend selbst organisiert und die Entwicklung in kurzen Iterationen erfolgt. Eine feste Vorgabe, wie groß das Team sein muss bzw. welche Rollen in dem Team existieren müssen, gibt es jedoch nicht. Die Visualisierung der Aufgaben steht auch bei Scrumban im Mittelpunkt und erfolgt analog zu Scrum und Kanban über ein in Spalten eingeteiltes Board. Die maximale Menge an gleichzeitig in der aktiven Bearbeitung befindlichen Aufgaben wird wie in Kanban begrenzt (WiP-Limit). Die Umsetzungsplanung neuer Aufgaben erfolgt in Scrumban bedarfsbezogen, sobald die Anzahl an Aufgaben in der „To Do“-Spalte eine gewisse Grenze unterschreitet (On demand planning). Dabei werden für die einzelnen Aufgaben Prioritäten vergeben. Daran orientieren sich die Entwickler, wenn sie sich die jeweils nächste Aufgabe zur Bearbeitung aus der „To Do“-Spalte „ziehen“ (Pull-Prinzip aus Kanban). Kurz vor dem jeweiligen Iterationsende kommt es in Scrumban zu einem Feature Freeze. Das bedeutet, dass ab dem Zeitpunkt keine weiteren Aufgaben mehr begonnen werden, sondern nur noch die aktuell vorhandenen fertiggestellt werden. Ist absehbar, dass sogar nicht mehr alle bereits begonnenen Aufgaben bis zum Iterationsende fertiggestellt werden können, kann der Product Owner/Projektleiter entscheiden, sich nur noch auf die höher priorisierten Aufgaben zu fokussieren und die Entwicklung der anderen zu stoppen (Triage). Mit Ausnahme eines Daily Standup finden Meetings in Scrumban schließlich ebenfalls anlassbezogen anstatt wie in Scrum routinemäßig statt. So sind auch Review- und Retroperspektive-Meetings nicht zwingend vorgesehen in Scrumban (Reddy 2015; Ladas 2009). Scrum, aber auch Kanban und andere agile Methoden stoßen an Grenzen, wenn sie in großen Unternehmen bzw. Projekten mit einer Vielzahl an aufeinander abzustimmenden Organisationseinheiten eingesetzt werden sollen. Um hier nun nicht doch wieder auf traditionelle Projektmanagementmethoden zurückgreifen zu müssen, werden die agilen Methoden von unterschiedlichen Personen und Organisationen weiterentwickelt, um sie „skalierungsfähig“ zu machen. Für Scrum wurden hierfür beispielsweise von Ken Schwaber (2015) das Framework Nexus entwickelt sowie von Craig Larman und Bas Vodde (2017) Large-Scale Scrum (LeSS). Darin geht es vor allem darum, wie die Zusammenarbeit von mehreren Scrum-Teams koordiniert werden kann, um in jedem Sprint ein abgestimmtes Produkt-Inkrement ausliefern zu können. Ein grundlegendes Meetingformat, um diese Koordination umzusetzen, ist dabei ein teamübergreifendes Daily Scrum, das auch als Scrum of Scrums bezeichnet wird (Sutherland 2001). Neben den hier skizierten Weiterentwicklungen und Mischformen von Scrum und Kanban gibt es noch zahllose weitere agile Frameworks bzw. Methoden, wie Extreme Programming (XP), Rational Unified Process (RUP), Agile Unified Process (AUP), Behavior-driven Development (BDD), Design-driven Development (DDD),

1  Einführung in das digitale Produktmanagement

25

­ eature-driven Development (FDD) etc., die in der digitalen Produktentwicklung einF gesetzt werden. Sie unterscheiden sich oft nur marginal voneinander und stellen vielfach auch Eigenentwicklungen von (Beratungs-)Firmen dar, die primär einem vertrieblichen Motiv entspringen. Hier einen umfassenden Überblick zu geben, erscheint aussichtslos und wäre auch wenig zielführend. Die nachfolgenden Beiträge liefern jedoch neben vielen Detailhinweisen und Tooltipps vor allem auch ein gutes Gefühl dafür, wie das digitale Produktmanagement im Unternehmensalltag umgesetzt wird.

Literatur Ammons, G. 2015. Ditching Scrum for Kanban – The best decision we’ve made as a team. https:// medium.com/cto-school/ditching-scrum-for-kanban-the-best-decision-we-ve-made-as-a-teamcd1167014a6f#.s5v843snj. Anderson, D.J. 2010. Kanban. Successful evolutionary change for your technology business. Washington: Blue Hole Press. Anderson, D.J. 2016a. Emerging roles in Kanban. https://djaa.com/emerging-roles-in-kanban. Anderson, D.J. 2016b. Are Scrum & Scaled Agile damaging morale at your firm? https://djaa.com/ are-scrum-scaled-agile-damaging-morale-at-your-firm. Beck, K. 2000. Extreme Programming explained. Embrace change. Boston: Addison. Beck, K., M. Beedle, A. van Bennekum, A. Cockburn, W. Cunningham, M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R.C. Martin, S. Mellor, K. Schwaber, J. Sutherland, und D. Thomas 2001. Manifesto for agile software development. www. agilemanifesto.org. Cagan, M. 2007. Product Discovery. https://svpg.com/product-discovery. Cagan, M. 2016. Planning Product Discovery. https://svpg.com/planning-product-discovery. Cooper, A. 1999. The inmates are running the asylum. Why high-tech product drive us crazy and how to restore the sanity. Indianapolis: Macmillan. Cooper, B., und P. Vlaskovits. 2013. The lean entrepreneur. Hoboken: Wiley. Cohn, M. 2004. User stories applied: For agile software development. Boston: Addison. Cohn, M. 2005. Agile estimation and planning. Stoughton: Prentice Hall. Connor, D. 2012. Understanding, commitment, and alignment. www.connerpartners.com/ frameworks-and-processes/understanding-commitment-and-alignment. Dickmann, P. (Hrsg.). 2007. Schlanker Materialfluss mit Lean Production, Kanban und Innovationen. Heidelberg: Springer. Domin, A. 2019. Scrum: Was versteht man unter dem Velocity-Faktor? https://t3n.de/news/scrumvelocity-faktor-1138393. Drath, W.H., C.D. McClaudey, C.J. Palus, und E.V. Velsor. 2008. Direction, alignment, commitment: Toward a more integrative ontology of leadership. The Leadership Quarterly 19 (6): 635–653. Epping, T. 2011. Kanban für die Softwareentwicklung. Heidelberg: Springer. Eriksson, M. 2011. What, exactly, is a product manager? www.mindtheproduct.com/what-exactlyis-a-product-manager. Fleig, J. 2019. Kaizen als Prinzip und was es bedeutet. www.business-wissen.de/hb/kaizen-alsprinzip-und-was-es-bedeutet. Gibbert, R. 2013. Product Discovery – Aber bitte richtig. www.produktbezogen.de/productdiscovery-aber-bitte-richtig.

26

S. Hoffmann

Gibbert, R. 2014. Das MVP – Problemlösung mit minimalem Feature-Umfang. www.produktbezogen.de/das-mvp-problemloesung-mit-minimalem-feature-umfang. Gilb, T. 1988. Principles of software engineering management. Harlow: Addison. Gläser, T. 2014. Prototyping UX: Mit Wireframes und Prototypes zum optimalen Interface. https:// t3n.de/magazin/wireframes-prototypes-optimalen-interface-prototyping-ux-233367. Grots, A., und M. Pratschke. 2009. Design Thinking. Kreativität als Methode. Marketing Review St. Gallen 26 (2): 18–23. Herwarth von Bittenfeld, P. 2010. User Stories: Anforderungen aus Nutzersicht dokumentieren. https://blog.seibert-media.net/blog/2010/11/29/user-stories-anforderungen-aus-nutzersichtdokumentieren. Herwarth von Bittenfeld, P. 2011. Die drei Cs einer User Story: Card, Conversation, Confirmation. https://blog.seibert-media.net/blog/2011/03/09/user-story-scrum-card-conversationconfirmation. Jacobsen, J., und L. Meyer 2019. Praxishandbuch Usability und UX, 2. Aufl. Bonn: Rheinwerk Computing. Jeffries, R. 2001. Essential XP: Card, conversation, confirmation. https://ronjeffries.com/xprog/ articles/expcardconversationconfirmation. Jungwirth, K. 2016. Scrum: So finden Sie einen exzellenten Scrum Master. www.inloox.de/unternehmen/blog/artikel/scrum-so-finden-sie-einen-exzellenten-scrum-master. Krasadakis G. 2019. The Minimum Viable Product explained. What an MVP really is and how you can benefit from it. https://medium.com/agileactors/the-minimum-viable-product-explained8f1187ca7cec. Kelley, T. 2001. The art of innovation. Lessons in creativity from IDEO, America’s leading design firm. New York: Doubleday. Ladas, C. 2008. Scrum-ban. https://leansoftwareengineering.com/ksse/scrum-ban. Ladas, C. 2009. Scrumban and other essays on Kanban Systems for Lean Software Development. Seattle: Modus Cooperandi Press. Larman, C., und B. Vodde. 2017. Large-Scale Scrum: More with LeSS. Boston: Addison. Laudon, K.C., J.P. Laudin und D. Schoder 2016. Wirtschaftsinformatik, 3. Aufl. Hallbergmoos: Pearson. Leopold, K., und S. Kaltenecker. 2013. Kanban in der IT. Eine Kultur der kontinuierlichen Verbesserung schaffen, 2. Aufl. München: Hanser. Mack, O., A. Khare, A. Krämer und T. Burgartz Hrsg. 2015. Managing in a VUCA World. Wiesbaden: Springer. Millweber, F. 2018. Kanban für Anfänger. Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung. Hannover. Neuberger, D. 2014. Die Aufgabe des Produktmanagers. www.produktbezogen.de/die-aufgabeeines-produktmanagers. Neuberger, D. 2018. Produkt vs. Projekt. www.produktbezogen.de/podcast-01-produkt-vs-projekt. New Work SE o.  J. Auftragsklärung. A framework for collaborative alignment. https:// auftragsklaerung.com. Osterwalder, A., Y. Pigneur, G. Bernarda, A. Smith und T. Papadakos 2014. Value Proposition Design: How to create products and services customers want. Hoboken: Wiley. Petereit, D. 2017. Kanban versus Scrum – Was sind die Unterschiede? https://t3n.de/news/kanbanscrum-unterschiede-834533. Petersen, M. 2017. Was macht eigentlich ein Scrum-Master? https://t3n.de/news/scrum-masteraufgaben-ausbildung-gehalt-800972. Pichler, R. 2014. Agiles Produktmanagement mit Scrum. Erfolgreich als Product Owner arbeiten, 2. Aufl. Heidelberg: dpunkt.

1  Einführung in das digitale Produktmanagement

27

Reddy, A. 2015. The Scrumban [R]Evolution: Getting the most out of Agile, Scrum, and Lean Kanban. New York: Addison. Rehkopf, M. o. J. Epics, stories, themes, and initiatives. www.atlassian.com/agile/projectmanagement/epics-stories-themes. Ries, E. 2011. The Lean Startup: how today's entrepreneuers use ccontinuous innovation to create radically successful businesses. New York: Crown Business. Roock, A. 2012. Stop starting, start finishing! Seattle: Lean-Kanban University. Schwaber, K. 2012. Scrum But replaced by Scrum And. https://kenschwaber.wordpress. com/2012/04/05/scrum-but-replaced-by-scrum-and. Schwaber, K. 2015. What is Scaling Scrum? https://kenschwaber.wordpress.com/2015/06/03/whatis-scaling-scrum. Schwaber, K. und J. Sutherland 2017. Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf. Scrum Alliance Hrsg. 2018. 2017–18 State of Scrum Report. https://info.scrumalliance.org/Stateof-Scrum-2017-18.html. Singh, M. 2017. 7 Factors for running an effective Kanban replenishment meeting. www.digite. com/blog/kanban-replenishment-meeting. Snowden, D.J. 2000. The social ecology of knowledge management. Cynefin: A sense of time and place. In Knowledge Horizons: The Present and the Promise of Knowledge Management, Hrsg. C. Despres und D. Chauvel., 237–265. Oxford: Routledge. Sutherland, J. 2001. Agile can scale: Inventing and reinventing SCRUM in five companies. IT Journal 14 (12): 5–11. Ulrich, B., S. Wagner, A. Schütt, C. Grünewald, und H. Obendorf. 2016. Experiments handbook. An overview of how and when to validate hypotheses. And with whom. For a better working product lifecycle. Norderstedt: BoD–Books on Demand. Wake, B. 2003. INVEST in good stories, and SMART tasks. https://xp123.com/articles/invest-ingood-stories-and-smart-tasks. Wiegand, S. 2015. Story-Points. https://agilmanagen.de/story-points.

Der Autor Sascha Hoffmann  ist Professor für Betriebswirtschaftslehre und Online-Management an der Hochschule Fresenius in Hamburg. Er lehrt dort Fächer wie Digital Media, E-Commerce, OnlineMarketing bzw. digitales Produktmanagement. Zuvor war er u. a. für XING und blau Mobilfunk in leitender Funktion im Business Development und Produktmanagement tätig. Mehr unter www.

hoffmann-sascha.de. Kontakt: [email protected]

2

Nutzerzentrierte Produktvisionen Im Team entwickeln und erfolgreich einsetzen Inken Petersen

Zusammenfassung

Eine gute Produktvision kann den Erfolg oder Misserfolg eines Produktes maßgeblich beeinflussen. Sie stellt den Kundennutzen in den Mittelpunkt und bietet ein langfristiges und inspirierendes Leitbild. Oft werden Produktvisionen aber nicht gemeinsam gelebt, sind zu generisch oder es geht nur um Geschäftszahlen. Dann bleibt der erhoffte Effekt aus. In diesem Artikel seht Ihr, wofür Ihr eine Vision braucht, wie Ihr sie am besten einbindet, welche Tools Ihr nutzen könnt und wie Ihr u. a. mit einem Team-Workshop zu einer wirklich gemeinsamen und kundenzentrierten Vision kommt.

2.1 Was ist eine Produktvision? Erfolgreiche Produkte können nur mit einer entsprechend langfristigen Vision im Blick entwickelt werden. Ohne eine tragfähige Vision fehlt oft der Antrieb und die Produktentwicklung kommt nicht in Schwung. Aber was genau ist eine Produktvision? u Produktvision: Eine Produktvision ist ein inspirierendes und langfristiges Leitbild für ein Produkt. Mit der Vision wird ein klares Zielbild für das Produkt formuliert. Die Richtung, in die sich das Produkt entwickeln soll, wird in dieser meist kompakten Formulierung deutlich gemacht. Dabei geht es nicht nur um wirtschaftliche Ziele. Eine gute Vision beschreibt, warum es das Produkt gibt und welchen Mehrwert es seinen Nutzern und der Welt bieten kann. I. Petersen (*)  Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_2

29

30

I. Petersen

Eine wichtige Frage bei der Produktvision ist der Zeithorizont, d. h. wie weit die Vision in die Zukunft schauen sollte. Dieser Zeithorizont ist je nach Industrie, Produktlebenszyklus und Produktart unterschiedlich. Bei digitalen Produkten wird die Produktvision in der Regel für einen Zeitraum von 2 bis 5 Jahren definiert. Bei Hardware kann eine Vision auch einen Zeitraum von 5 bis 10 Jahren umfassen, da Hardware-Produkte in der Regel einen längeren Produktlebenszyklus haben. Die Produktvision ist jedoch meist nur der Anfang. Für eine erfolgreiche Produktentwicklung muss die Vision mit Zielen und einer Strategie ergänzt werden. So entsteht ein tragfähiges Fundament, das hilft, die richtigen Entscheidungen zu treffen und schnell voran zu kommen. Das sogenannte VMOST-Modell bietet hier ein gutes Framework, das man gut zur Einbindung von Vision, Mission, Zielen, Strategie und Aktionen in den Alltag nutzen kann (Sondhi 1999). Zudem macht es den Auftrag der Vision deutlich. Das ­VMOST-Modell besteht aus 3 verschiedenen Ebenen: (1) Vision und Mission Die Vision beschreibt das langfristige Zielbild und wohin sich das Produkt in Zukunft entwickeln soll. Die Mission beschreibt den Produktzweck und warum es das Produkt geben sollte. Vision und Mission werden oft gemeinsam verwendet und die Vision wird von der Mission abgeleitet. Der Mehrwert für den Nutzer spielt hier natürlich eine wichtige Rolle, da er in der Regel der Grund für die Existenz des Produktes ist. Beispiel

Googles Mission ist z. B. „to organize the world’s information and make it universally accessible and useful.“ Die Vision von Google ist „to provide access to the world’s information in one click“. ◄ (2) Ziele („Objectives“) Auf Basis der Vision und Mission können die Ziele für die nächsten Quartale definiert werden. Hier rücken die wirtschaftlichen Aspekte meist in den Fokus. In einer typischen Produktorganisation mit mehreren Produktteams werden die Vision, die Mission und die Ziele oft übergreifend formuliert. Auf den unteren Ebenen kann dann jedes Produktteam selbst eine Strategie und die passenden Maßnahmen zur Zielerreichung definieren. Beispiel

Ein Beispiel für ein Ziel für einen Online-Shop könnte z. B. das „Erreichen von 50.000 neuen Käufern“ sein. ◄ (3) Strategie und Maßnahmen („Strategy“ & „Tactics“) Auf dieser Ebene werden die Ziele in Plänen und Maßnahmen konkretisiert. Der Produktmanager überlegt sich hier unter Einbeziehung des Produktteams, wie die Ziele

2  Nutzerzentrierte Produktvisionen

31

für das nächste Quartal erreicht werden können. Dieser Schritt ist sehr wichtig, da hier die Verknüpfung der übergreifenden Vision und der Strategie mit der Arbeit in den Teams stattfindet. Dieser Schritt wird bei der Entwicklung von Visionen jedoch oft verpasst, weshalb in der Folge die Vision nie wirklich zum Einsatz kommt. Beispiel

Ein Beispiel für eine konkrete Strategie könnte z. B. das Adressieren eines neuen Kundensegmentes sein. Die abgeleiteten Maßnahmen sind dann spezielle Funktionen, die das Produkt braucht, um für dieses neue Kundensegment attraktiv zu sein. ◄ Es bietet sich an, regelmäßige Termine zur Abstimmung der Ziele, der Strategie und der Maßnahmen einzuplanen. Der übergreifend Produktverantwortliche (also z. B. der „Head of Product“) sollte diese Sessions mit dem Team zur Rückführung der Ziele auf die übergreifende Vision und Mission nutzen und es so aktiv einbinden.

2.2 Warum man eine Produktvision braucht Erfolgreiche Produktentwicklung ist immer das Ergebnis einer erfolgreichen Teamarbeit, da verschiedene fachliche Kompetenzen gut zusammenwirken müssen. Eine gemeinsame Vision ist dabei elementar für ein Team, um gut und effizient zusammenarbeiten zu können (Google o. J.). Das klappt aber nur, wenn die Vision gut eingebunden wird. Eine sinnvolle Verzahnung der verschiedenen organisatorischen Ebenen im Unternehmen ist hier wichtig: eine im Top-Management erdachte Vision ohne Einbindung der Produktteams wird meiner Erfahrung nach meist nicht angenommen und nicht genutzt. Für eine gute Teamarbeit ist jedoch eine gemeinsam getragene und gelebte Vision sehr wichtig. Die folgenden vier Argumente für den Einsatz einer Produktvision in der Produktentwicklung sollten dabei jeden Zweifler überzeugen, zumal der Aufwand zur Erstellung einer Produktvision im Verhältnis zu ihrem Nutzen überschaubar ist. (1) Klare Richtung Um gut und effizient arbeiten zu können, braucht ein Produktteam ein gemeinsames Ziel. Eine gute Vision ist eine gemeinsame Vision, die dem Team eine klare Richtung vorgibt. Anhand der Vision kann das Team zudem immer abgleichen, ob es auf dem richtigen Weg ist. (2) Schnellere Entscheidungen In der Produktentwicklung müssen ständig Entscheidungen getroffen werden. Eine klare Vision hilft bei der Entscheidungsfindung und auch bei der Priorisierung von Ideen für die Umsetzung. Und sie ermöglicht es, dabei ein gutes Gefühl zu haben.

32

I. Petersen

(3) Höhere Motivation Ohne eine gemeinsame Vision fehlt dem Team oft der Antrieb sich anzustrengen, da es keinen übergeordneten Grund dafür gibt. Eine gute Vision für ein sinnvolles Produkt ist daher eine super Motivation für Produktteams. (4) Bessere Kommunikation Für eine gute Teamarbeit ist eine funktionierende Kommunikation extrem wichtig. Eine gemeinsame Vision kann hier einen wichtigen Beitrag leisten, da gemeinsame Ziele auch die Kommunikation untereinander verbessern. Zusammengefasst ist eine gemeinsame Produktvision also nicht nur für Strategie und Planung wichtig, sondern ist auch elementar für ein gut funktionierendes Team.

2.3 Woran man eine gute Produktvision erkennt Eine gute Produktvision erkennt man zuallererst daran, dass die Vision im Unternehmen und in den einzelnen Teams bekannt ist und genutzt wird. Um das zu erreichen, sind die sogenannten SHIELD-Kriterien als Leitlinie hilfreich (Gibbert 2013). Diese Kriterien sind gerade bei der initialen Erstellung einer Vision wichtig. (1) S für „Simple“ Die Produktvision muss einfach zu verstehen sein. Eine klare und präzise Formulierung in einer im Unternehmen gängigen Sprache ist unbedingt wichtig. (2) H für „Huge“ Die Produktvision sollte ein großes und anspruchsvolles Ziel formulieren. Ambitionierte und gute Ziele sind eine wichtige Motivation. (3) I für „Important“ Das Ziel bzw. die Vision sollten wichtig sein, also ein echtes Bedürfnis ansprechen. Das ist meist das Bedürfnis der Zielgruppe, also z. B. ein Problem, das mit dem Produkt für sie gelöst wird. (4) E für „Engaging“ Die Vision sollte inspirierend sein und alle Beteiligten einnehmen und mitreißen. Das ist bei kurzen und kompakten Texten nicht immer einfach. Hier kommt es sehr stark auf eine gute interne Vermarktung und Kommunikation der Vision an. (5) L für „Long Term“ Eine Vision sollte langfristig ausgerichtet und nicht nur kurzfristig gedacht sein.

2  Nutzerzentrierte Produktvisionen

33

(6) D für „Distributed“ Die Vision sollte allen Beteiligten bekannt und damit gemeinsam geteilt sein.

2.4 Tools zur Erstellung einer guten Produktvision Für die Erstellung von Produktvisionen gibt es vier bekannte Tools: das Vision Statement, das Vision Board, das Vision Template und den Visiontype. Jedes dieser Tools hat nach meiner Erfahrung Vor- und Nachteile, die ich im Folgenden kurz vorstellen werde.

2.4.1 Das Vision Statement Das Vision Statement ist sicher das bekannteste und am häufigsten eingesetzte Tool für Produktvisionen. Es wird meist eher zur Formulierung von Unternehmensvisionen genutzt, eignet sich aber auch hervorragend für Produktvisionen. Das Vision Statement ist ein sehr knackiges und kompaktes Format, was sicherlich zu seiner Beliebtheit beigetragen hat. Man kann die Vision hier wirklich auf den Punkt bringen. Diese Kompaktheit ist eine der wesentlichen Vorteile dieses Tools. Man kann sich das Vision Statement gut merken und man ist durch das kompakte Format quasi gezwungen, sich kurz zu fassen. Beispiel

Ein gelungenes Vision Statement ist das von Wikipedia: „Imagine a world in which every single human being can freely share in the sum of all knowledge.“ (Wikimedia Foundation o. J.). ◄ Ein wesentlicher Nachteil des Vision Statements ist das offene Format, das wenig Struktur vorgibt. Es kann schnell passieren, dass ein Vision Statement sehr beliebig, zu lang oder zu kompliziert wird. Da helfen die SHIELD-Kriterien weiter. Wenn man mit dem offenen Format jedoch gut zurechtkommt, ist es meiner Meinung ein optimales Tool.

2.4.2 Das Product Vision Board Das Product Vision Board von Roman Pichler (Pichler 2011) ist ein gut strukturiertes Tool im Canvas-Format zur Erstellung von Produktvisionen, siehe Abb. 2.1. Es eignet sich vor allem gut bei der Entwicklung von neuen Produkten, bei der Erschließung neuer Marktsegmente und bei größeren Änderungen an bestehenden Produkten. Das Board ist recht einfach zu nutzen und bietet einen praktischen Überblick über Produktvision und auch die Produktstrategie. Es besteht aus fünf Bereichen:

34

I. Petersen

Vision Target Group

Needs

Product

Business Goals

Abb. 2.1   Product Vision Board. (Quelle: In Anlehnung an Pichler 2011)

• • • •

Vision: Was ist das übergeordnete Ziel? Warum sollte es dieses Produkt geben? Zielgruppe: Wer ist die Zielgruppe und was kann das Produkt für sie tun? Bedürfnisse: Was braucht die Zielgruppe und welche zu lösenden Probleme hat sie? Produkt: Was sind die wichtigsten Eigenschaften und Features von dem Produkt? Was sind die 3 bis 5 wichtigsten Features, die das Produkt als USP (Unique Selling Proposition) braucht? • Business-Ziele: Wie kann das Produkt zum wirtschaftlichen Erfolg beitragen und was soll damit erreicht werden? Das Product Vision Board ist ein Format aus der agilen Produktentwicklung und seine Befüllung folgt daher einem schlanken und iterativen Ansatz. Auf dem Board kann man den wesentlichen Kern des Produktes gut fokussieren. Da man anfangs nicht wissen kann, ob man mit seinen Annahmen richtig liegt, sollte das Board im Verlauf der Produktentwicklung immer wieder überprüft und ggf. überarbeitet werden. Ein wesentlicher Vorteil des Boards ist meiner Meinung nach das strukturierte und übersichtliche Canvas-Format, das die Kernfragen bei der Produktentwicklung umfasst. Auch der Ansatz als iteratives Tool, das überprüft und geändert werden darf und soll, passt zu den Herausforderungen der heutigen Produktentwicklung: Märkte und Nutzer sind komplex und ändern sich schnell, da sollten Produktvisionen auch Raum zur Änderung einfordern. Ein Nachteil ist meiner Erfahrung nach, dass das Board als solches wenig inspirierend ist und sich nur mäßig zur Kommunikation der Produktvision eignet. Wenn man das Product Vision Board aber z. B. mit einem Vision Statement oder einem Visiontype kombiniert, kann das sehr gut funktionieren.

2  Nutzerzentrierte Produktvisionen

35

2.4.3 Das Product Vision Template Das Product Vision Template von Geoffrey Moore bietet einen sehr kompakten und schlanken Weg, um eine Vision in einem Satz zu formulieren (Moore 2014), s. Abb. 2.2. Das Template ist auch als Elevator Pitch bekannt, da man die Vision des Produktes einem potentiellen Investor innerhalb einer Fahrstuhlfahrt rüberbringen können sollte. In der Start-up-Szene ist das Product Vision Template sicher das bekannteste Tool für Produktvisionen. Mit diesem Template kann man den wesentlichen Mehrwert des Produktes sehr gut auf den Punkt bringen. Das Satzformat ist strukturiert und gibt detaillierte Vorgaben, was man eintragen soll. Zudem hilft das Satzformat sehr dabei, sich kurz zu fassen. Da die einzelnen Satzteile aber wie eine Aufzählung von Fakten rüberkommen, ist das Product Vision Template wenig inspirierend. Es ist eben ein Template, das sich gut für den Verkauf eines Produktes an potentielle Partner und Investoren eignet und weniger zur Inspiration und Motivation des Teams.

2.4.4 Der Visiontype Ein Visiontype ist eine visuelle Darstellung der Produktvision mithilfe eines Prototypen. Mit dem Visiontype kann die gewünschte Zukunft des Produktes verständlich und gut dargestellt werden. Der Visiontype ist hierzulande ein noch recht unbekanntes Tool. Geprägt wurde der Begriff von dem Produktmanagement-Experten Marty Cagan (2008).

Product Vision Template For

(target customer)

the

(product name)

that

(benefits, unique selling points).

Unlike

(compeor product),

our Product

who is a

(customer need to be solved) (product category)

(main difference).

Abb. 2.2   Product Vision Template. (Quelle: In Anlehnung an Moore 2014)

36

I. Petersen

Ein Visiontype kann verschiedene Formate haben: vom Video bis hin zu einem interaktiven Click Dummy. Meist wird der Visiontype aus der Perspektive des Nutzers dargestellt, im Video wird also z. B. gezeigt, wie der Nutzer mit dem zukünftigen Produkt interagiert. Wichtig ist beim Visiontype, dass er eine zukünftige aber dennoch realistisch denkbare Version des Produktes darstellen sollte. Das macht den Unterschied zur Designfiktion aus, die sich als Tool bewusst mit dem Erfinden einer neuen fiktiven Zukunft befasst (Roselló 2017). Beide Tools kommen aus dem UX- bzw. Designbereich. Der wesentliche Vorteil des Visiontypes ist das sehr inspirierende Format, das Teams wirklich mitreißen und begeistern kann. Mit keinem anderem Tool kann man Produktvisionen so greifbar und verständlich rüberbringen. Ein Nachteil des Visiontypes ist, dass oft viel in den Visiontype eingebaut wird und dadurch im Vergleich z. B. zum Product Vision Statement die knackige Kompaktheit fehlt. Zudem ufert das Erstellen von Produktvisionen mit Visiontypes leicht aus. Daher sollte man lieber z. B. mit einem Product Vision Board starten und den Visiontype im zweiten Schritt erstellen.

2.5 Der Visions-Workshop Für den Erfolg einer Produktvision ist es wichtig, dass es eine gemeinschaftliche Vision ist. Eine im Elfenbeinturm erstellte Produktvision wird es vor allem im agilen Umfeld schwer haben. Ich bin ein großer Fan von kollaborativen Visions-Workshops, in denen man gemeinsam in die Zukunft blickt und eine sinnvolle Produktausrichtung erarbeitet. Die Erstellung einer guten Vision ist nicht trivial und deswegen ist es wichtig, verschiedene Meinungen und Perspektiven einzubeziehen. Deswegen sollte am Workshop jeder teilnehmen, der einen Beitrag zur Produktvision leisten kann.

2.5.1 Die richtige Vorbereitung Für einen erfolgreichen Workshop ist eine gute Vorbereitung sehr wichtig. Ansonsten läuft man Gefahr, sich während des Workshops in endlosen Diskussionen zum Ablauf zu verlieren. Für die Vorbereitung des Visions-Workshops sollte man daher nach meiner Erfahrung mindestens zwei bis drei Wochen Vorlaufzeit einplanen. Damit der Workshop ein Erfolg wird, müssen vorab die richtigen Grundlagen geschaffen werden. (1) Den Kontext verstehen Im ersten Schritt sollten alle verfügbaren Infos, wie z. B. Marktdaten, Studien über Nutzerbedürfnisse, Daten zur Nutzung vom derzeitigen Produkt, Trendstudien etc. gesammelt werden. Das ist wichtig, um sich einen ersten Überblick zu verschaffen. Natürlich handelt es sich hier größtenteils um eine Rückwärtsbetrachtung, aber für einen Blick in die Zukunft ist dieser wichtig.

2  Nutzerzentrierte Produktvisionen

37

(2) Den Kunden, seine Probleme und Bedürfnisse verstehen Gute Produktvisionen sind immer nutzerzentriert und stellen den Mehrwert für den späteren Anwender oder die Gesellschaft in den Fokus. Dafür ist es wichtig, den Nutzer und seine Probleme besser zu verstehen. Zudem inspiriert nichts so sehr, wie in die Lebenswelt des Nutzers einzutauchen. Als Tool eignet sich hier z. B. das J­ obs-to-be-done-Framework. Grundgedanke des Jobs-to-be-Done-Framework ist, dass Nutzer ein Produkt brauchen oder kaufen, wann immer sie eine Aufgabe zu lösen haben (Christensen et al. 2016). Mit diesem Verständnis über die Kernaufgaben von Nutzern kann man sehr gut in die Erstellung der Produktvision einsteigen. Die Jobs-to-be-done-Analyse sollte unbedingt mit einer statistisch relevanten Anzahl von Nutzern im Interview-Format durchgeführt werden. (3) Den Workshop planen Dann geht es an die Planung des Workshops. Damit der Workshop gut läuft, ist vor allem die Auswahl des Tools zur Erarbeitung der Produktvision wichtig. Alle vier hier vorgestellten Tools eignen sich grundsätzlich gut für einen Visions-Workshop. Für das Product Vision Board, das Vision Template und das Vision Statement kann man super mit großen Plakaten arbeiten, die man als Arbeitsfläche für die Teilnehmer an die Wand hängt. Das sollte natürlich alles vorbereitet werden. Zudem ist die Auswahl eines passenden Raums wichtig. Der Raum sollte idealerweise ein kreatives und inspirierendes Umfeld bieten. Man kann sich eine große Produktvision schließlich schlecht in einem engen und schlecht beleuchteten Konferenzraum ausdenken.

2.5.2 Der Workshop Jetzt geht es an das Formulieren der Vision! An dem Workshop sollten alle teilnehmen, die gerne visionär denken, Ideen haben bzw. eine besondere fachliche Expertise mitbringen. Damit der Workshop gut läuft und eine gute Produktvision erarbeitet werden kann, sind meiner Erfahrung nach vier Punkte zu beachten: (1) Einen guten Workshop-Moderator haben Bei einem Visions-Workshop treffen viele verschiedene Meinungen und Ideen über die mögliche zukünftige Ausrichtung aufeinander. Damit am Ende alle mit einer gemeinsamen Ausrichtung aus dem Workshop gehen, ist es unbedingt wichtig einen Workshop-Moderator einzusetzen. Der Moderator sollte mit kreativen Teamprozessen in der Produktentwicklung Erfahrung haben. (2) An den Wänden sichtbar arbeiten Bei kreativen und kollaborativen Team-Workshops geht es viel darum, sich die Arbeitsergebnisse gegenseitig zu präsentieren und zu diskutieren. Nur mit dieser Auseinandersetzung kann am Ende ein gemeinsames Ergebnis erzielt werden. Dafür wird wie aus

38

I. Petersen

dem Design Thinking bereits bekannt mit großen Arbeitswänden gearbeitet, an denen die Ergebnisse für alle sichtbar aufgehängt und gemeinsam verfeinert werden, bis alle mit der Produktvision in der ersten Version zufrieden sind. (3) An die nutzerzentrierte Ausgangsbasis denken Man sollte in den Workshop immer mit einem Blick auf den Nutzer und seine Bedürfnisse starten. Dazu können z. B. die Ergebnisse der Jobs-to-be-done-Analyse und die hoffentlich bereits vorliegenden Personas kurz vorgestellt werden. Wichtig ist dabei, den Einstieg so zu gestalten, dass die Teilnehmer Empathie zum Nutzer aufbauen können. Ohne Empathie ist es schwer, wirklich aus der Nutzerperspektive heraus in die Zukunft zu denken und kreativ zu werden (Hall 2019). Perfekt ist es, wenn vor dem Visions-Workshop bereits alle gemeinsam an den Nutzerinterviews für die Jobs-to-be-done-Analyse teilgenommen haben. Alternativ kann man Videos von den ­ Nutzerinterviews zu Beginn des Workshops zeigen. (4) Die technische und die Business-Perspektive nicht vergessen Eine gute Produktvision hat den Nutzer im Fokus, vergisst aber auch nicht die wirtschaftliche und die technische Perspektive. Nur aus der Kombination dieser drei Perspektiven entstehen wirklich nachhaltig erfolgreiche Produkte, was im ­Venn-Diagramm aus dem Design Thinking auch optisch gut dargestellt wird (Brown 2019), s. Abb. 2.3. Im Workshop sollten daher auch die finanziellen Aspekte und die technologischen Möglichkeiten nicht verloren gehen. Natürlich kann sich bei einem Ausblick in die nächsten 2 bis 5 Jahre eine Menge ändern – aber da es sich bei der Produktvision um keine Designfiktion handelt, sollte man immer im Bereich des Wahrscheinlichen bleiben. Der Dreiklang der Perspektiven hilft dabei.

Mensch

Welche Probleme werden mit dem Produkt gelöst? Welche Bedürfnisse werden mit dem Produkt befriedigt?

Technologie

Was ist in den nächsten Jahren wahrscheinlich technisch umsetzbar und auch möglich?

Wirtscha

Was ist markähig und bietet auch einen nachhal
g finanziellen Nutzen?

Abb. 2.3   Venn-Diagramm einer guten Produktvision. (Quelle: In Anlehnung an Brown 2019)

2  Nutzerzentrierte Produktvisionen

39

2.5.3 Nach dem Workshop Nach dem Workshop ist die Vision meist nicht fertig. Die Ergebnisse der Teamarbeit aus dem Workshop müssen in der Regel feingeschliffen und konkretisiert werden. Dafür reicht die Zeit im Workshop nicht aus und es ist auch gut, mit etwas Abstand noch einmal auf die Ergebnisse zu schauen. Die Kommunikation und das erste Einbinden der Vision in den Alltag dürfen nach dem Workshop nicht vergessen werden. Nur wenn man an die folgenden 3 Punkte denkt, kann die Vision erfolgreich genutzt werden. (1) Die Konkretisierung der Vision Die Konkretisierung bzw. die Schärfung der Vision ist unbedingt wichtig. Vor allem zu generische Aussagen wie z. B. „besseres Produkt“ oder „bestes Produkt“ sollten kritisch hinterfragt werden. Wurde ein Visiontype erarbeitet, muss er gestaltet und produziert werden. Bei dem Vision Statement, dem Vision Template und dem Vision Board reicht hingegen meist eine textliche Überarbeitung. (2) Die Kommunikation der Vision Jetzt geht es darum, das finale Ergebnis mit allen anderen zu teilen. Es schadet nicht, hieraus ein kleines Event zu machen. Schließlich geht es um die zukünftige Ausrichtung, die gut in einem inspirierenden Rahmen präsentiert werden kann. Neben der initialen Vorstellung der Vision sollte die Vision z. B. an die Wände im Büro gehängt oder auf der Firmen-Website eingebunden werden. So bleibt die Vision präsent und kann gut wirken. (3) Das Nachhalten und Nutzen der Vision Dieser Schritt ist mit der komplizierteste. Das Einbauen der Vision in die tägliche Arbeit erfordert Disziplin. Hier sind die Produktverantwortlichen gefragt, die die Vision z. B. in regelmäßigen Strategie-Sessions und in den OKR-Prozessen einbinden sollten. Denn die Vision bleibt nur präsent und wird genutzt, wenn man sie kontinuierlich in die Prozesse der Produktentwicklung einbindet. Auch ein regelmäßiges Nachfragen, welchen Bezug neue Produktideen zur Vision haben, ist dafür eine gute Möglichkeit.

2.6 Woran man erkennt, dass die Produktvision funktioniert Aber woran erkennt man nach dem Workshop und wenn man alle Punkte beachtet hat, ob die Produktvision gut funktioniert? Hier gibt es zum Abschluss dieses Artikels noch ein paar Tipps. Gut funktionierende Produktvisionen sind zum einen natürlich an erfolgreichen Produkten zu erkennen, die Nutzer und Mitarbeiter begeistern. Denn nur mit einer starken Vision können Produktunternehmen wirklich nachhaltig erfolgreich sein. Globale Produktunternehmen wie z. B. Google oder Facebook sind alle mit einer guten Produktvision gestartet und haben ihre starke Vision genutzt, um starke Produkte und Marken

40

I. Petersen

aufzubauen. An den folgenden vier Punkten kann man erkennen, ob die Produktvision wirklich funktioniert: (1) Die Teams sprühen vor Motivation und Energie Unternehmen und Teams mit einer funktionierenden Vision zeichnen sich durch eine starke Motivation und Energie aus, die allgemein spürbar ist. Eine gemeinsame Ausrichtung und das Arbeiten an relevanten Problemen sind für viele eine wichtige Antriebskraft und oft wichtiger als finanzielle Aspekte. (2) Die Teams beziehen sich selbst auf die Vision Nicht nur die Manager erwähnen die Vision in Präsentationen und Meetings, sondern jeder aus dem Team bezieht sich auf die Vision. Die Vision ist damit zum wichtigen Referenzpunkt für die Produktentwicklung geworden und wird alltäglich in Entscheidungen und die Ideenfindung mit einbezogen. (3) Die Vision ist ein Fixpunkt im ansonsten dynamischem Umfeld Eine Vision wird selten geändert, außer sie ist wirklich ganz verkehrt gewesen. So wird sie zu einem festen Bezugspunkt für die Teams, der hilft, sich an ihr zu orientieren und zum Hinterfragen des aktuellen Tuns anregt. Die Strategie und die Maßnahmen zur Erreichung der Vision sind immer in Bewegung und werden regelmäßig mit der Vision abgeglichen und angepasst. (4) Der Nutzer spielt eine große Rolle Gute Visionen thematisieren immer den Mehrwert, den sie auf der Welt schaffen wollen. Daher stellen sie den Nutzer bzw. die Gesellschaft meist in den Fokus, da rein finanzielle Ziele niemals einen solchen Effekt haben können. Dieser Nutzerfokus aus der Vision ist dann auch in den Teams spürbar. Die Teams hinterfragen wie von selbst stets den Effekt ihrer Arbeit auf den Nutzer und damit langfristig auch auf die Vision.

2.7 Ein kurzer Ausblick zum Schluss In Zukunft wird das Thema Produktvision in der Produktentwicklung sicher noch mehr Relevanz bekommen. Die derzeitigen ökonomischen Entwicklungen in Richtung Nachhaltigkeit und sanfteres Wachstum machen das Arbeiten mit einer Produktvision noch wichtiger. Denn die Produktvision fördert wie kein anderes Tool in der Produktentwicklung eine langfristige Ausrichtung und den Fokus auf die Generierung von wirklichem Mehrwert. Beides sind Themen, die mittlerweile nicht nur für die Mitarbeiter, sondern auch für die späteren Kunden beim Kauf eines Produktes wichtiger sind.

2  Nutzerzentrierte Produktvisionen

41

Literatur Brown, T. 2019. Change by design, revised and updated. New York: Harper Business. Cagan, M. 2008. Inspired: How to create products customers love. San Francisco: Wiley. Christensen, C.M., H.R. Hall, K. Dillon, und D.S. Duncan. 2016. Competing against luck: The story of innovation and customer choice. New York: Harper Business. Gibbert, R. 2013. Produktvision oder die Sehnsucht nach dem weiten, endlosen Meer. www. produktbezogen.de/produktvision-oder-die-sehnsucht-nach-dem-weiten-endlosen-meer. Google o. J. Learn about Google’s manager research. https://rework.withgoogle.com/guides/ managers-identify-what-makes-a-great-manager/steps/learn-about-googles-manager-research. Hall, C. 2019. The power of empathy in product development. https://phys.org/news/2019-05power-empathy-product.html. Moore, G. 2014. Crossing the Chasm, 3. Aufl. New York: Harper Business. Pichler, R. 2011. The product vision board. www.romanpichler.com/blog/the-product-vision-board. Roselló, E. 2017. https://lab.cccb.org/en/design-fiction-prototyping-desirable-futures. Sondhi, R. K. 1999. Total Strategy. Nottingham: Airworthy Publications International. Wikimedia Foundation o. J. About. https://wikimediafoundation.org/about/vision.

Die Autorin Inken Petersen hatte im Laufe ihrer Karriere schon viele unterschiedliche Rollen innerhalb und außerhalb von UX-Teams als UX-Designerin, Information Architect, UX-Lead und Product Owner. Ihre Leidenschaft sind Produkte und Services mit herausragender User Experience. Dafür coacht sie als freiberufliche UX-Beraterin ihre Kunden zu UX-Strategie, UX-Management, Product Discovery und Continuous Product Discovery. Für neue Produkte und größere Relaunches erstellt sie Designvisionen mit ­Visions-Prototypen und baut neue und effiziente Designsysteme auf. Sie ist Mitgründerin des Product- & UX-Community-Blogs produktbezogen.de. Kontakt: [email protected]

3

Product Discovery Probleme verstehen und Erfolg versprechende Lösungen entwickeln Alexander Hipp und Philip Steen

Zusammenfassung

In dem Beitrag wird beschrieben, wie wichtig eine Product Discovery ist, um im digitalen Produktmanagement an den richtigen Produktlösungen zu arbeiten, die den Kunden einen echten Mehrwert generieren. Dazu werden zunächst die grundlegenden Ziele und Prinzipien, wie Outcome-Orientierung, Nutzerzentrierung und das iterative Vorgehen in einem interdisziplinären Team, einer Product Discovery erläutert. Im Anschluss daran werden die Unterschiede zwischen einer projektbasierten und einer kontinuierlichen Discovery dargestellt, bevor einzelne Discovery-Frameworks und -Tools vorgestellt werden. Der Beitrag endet mit einigen praktischen Hinweisen zur Umsetzung einer Product Discovery.

3.1 Ziele von Product Discovery „Product discovery is a process to define a product that is valuable, useful, and feasible.“ – Marty Cagan, Silicon Valley Product Group

A. Hipp (*)  Neobank N26, Barcelona, Spanien E-Mail: [email protected] P. Steen  IDALABS GmbH & Co. KG, Kiel, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_3

43

44

A. Hipp und P. Steen

Product Discovery Decide what to build, and then build it.

Product Delivery Abb. 3.1   Zusammenhang zwischen Product Discovery und Product Delivery. (Quelle: In Anlehnung an Torres 2016a)

Product Discovery beinhaltet alle Aktivitäten eines Produktteams, die mit der Entscheidung zusammenhängen, welche Produkte, Ideen und Features umgesetzt werden sollen. Product Delivery ist der Weg, wie diese Ideen tatsächlich umgesetzt werden, um Nutzen für den Kunden zu generieren (Torres 2017). Während es bei der Delivery darum geht, Ideen richtig umzusetzen, geht es bei der Discovery, wie in Abb. 3.1 veranschaulicht, also darum, die richtigen Ideen umzusetzen. Um zu entscheiden, welche Ideen als nächstes bei einem Produkt umgesetzt werden sollen, gibt es verschiedene Methoden. Im agilen Umfeld hat sich in den letzten Jahren die Bewertung und Priorisierung von Ideen anhand eines Backlogs etabliert. Hierbei werden alle Ideen und Anforderungen in einer Liste gesammelt. Diese Liste wird dann vom Produktmanager, oftmals gemeinsam mit weiteren Stakeholdern, in eine priorisierte Reihenfolge gebracht und in dieser Reihenfolge umgesetzt. Dieses Vorgehen setzt jedoch voraus, dass alle Anforderungen klar sind und man genug Wissen über die Anforderungen der Kunden hat. Einige kritische Risiken bei der Produktentwicklung werden bei diesem Ansatz jedoch meist nicht bzw. erst nach erfolgreicher Auslieferung adressiert (vgl. Cagan 2018): • Nutzen (Value Risk): Wird der Kunde das Produkt nutzen und ist er bereit, dafür zu bezahlen? • Nutzbarkeit (Usability Risk): Versteht der Kunde die Bedienung? • Umsetzbarkeit (Feasibility Risk): Ist eine Umsetzung technisch möglich? • Wirtschaftliche Tragfähigkeit (Business Viability Risk): Ist das Produkt rentabel? Ohne den Einsatz von Product Discovery würde man erst nach Fertigstellung und Vermarktung eines Produkts bzw. des Produktinkrements feststellen, wie die Kunden damit interagieren und ob es am Markt tatsächlich angenommen wird. Dies ist der teuerste Weg, den Wert einer Idee herauszufinden. Im Gegensatz zum traditionellen Requirements-Engineering, bei dem Anforderungen (ausschließlich) von Auftraggebern eingeholt und priorisiert werden, fokussiert sich Discovery auf die Nutzerbedürfnisse und die Maximierung des Kundenwertes. Dabei geht es nicht um eine detaillierte Prüfung der technischen Umsetzbarkeit, sondern darum,

3  Product Discovery

45

ein tiefes Verständnis für die Kunden zu gewinnen. Ohne die Bedürfnisse der Nutzer zu erforschen und Annahmen über die Zielgruppe vor der Umsetzung zu validieren, gehen Produktteams das Risiko ein, Produkte und Features zu entwickeln, die letztendlich nicht vom Kunden genutzt werden. Dies erst nachträglich in weiteren Iterationen zu korrigieren, würde viel Zeit und Geld kosten und wertvolle (Entwicklungs-)Ressourcen binden. Diese Risiken können durch den regelmäßigen Einsatz einer Product Discovery reduziert werden. Statt Produktinkremente erst nach der Fertigstellung mit Kunden zu testen, sollen in der Product Discovery bereits die grundlegenden Annahmen hinter einem Produkt oder Feature mit Kunden validiert werden. Dazu wird in der Discovery geprüft, ob ein tatsächliches Kundenproblem gelöst wird, die Lösung vom Kunden bedienbar und technisch umsetzbar ist. Somit werden Ideen frühzeitig im Prozess durch echtes Kundenfeedback verbessert, der Markt bereits analysiert und die Business Opportunity validiert. Das hilft dabei, bereits vor der Produktentwicklung die Ideen mit dem höchsten Potenzial zu identifizieren. Somit können die Unsicherheit im Produktentwicklungsprozess und die Dauer des Feedback-Zyklus reduziert werden. In der Regel gibt es in einem Produktteam immer mehr Ideen als Umsetzungskapazität. Bei genauerer Betrachtung stellt man jedoch meist fest, dass nicht alle Ideen so vielversprechend sind, wie sie zu Beginn erscheinen. Menschen im Allgemeinen und Produktmanager im Speziellen sind gut darin, Lösungen zu finden und ein identifiziertes Problem direkt zu überwinden. Bei der Problemlösung gehen Menschen jedoch oft vom eigenen Erfahrungsschatz bzw. den persönlichen Bedürfnissen und Werten aus. Dieses Muster funktioniert gut, um Probleme des alltäglichen Lebens zu lösen. Beim Erstellen digitaler Produkte geht es allerdings in den meisten Fällen nicht darum, persönliche Probleme, sondern die Probleme von Nutzern zu lösen, welche in der Regel andere Persönlichkeiten, Lebensumstände und Fähigkeiten haben. Bevor eine Lösung in Form eines Produktes oder Features entwickelt werden kann, sollten daher das eigentliche Kundenproblem und – viel wichtiger noch – die Personen, für die das Problem gelöst werden soll, ausreichend erforscht und verstanden werden. Dazu ist es speziell am Anfang einer Product Discovery essentiell, das persönliche Gespräch mit Personen aus der Zielgruppe zu suchen, um hierdurch eine Bindung zu diesen aufzubauen. Hier liegt eine der großen Chancen von Product Discovery: frühzeitig die wichtigsten Nutzerprobleme zu identifizieren und zu erkennen, ob eine Umsetzung zum aktuellen Zeitpunkt sinnvoll ist. Dies bedeutet zwar, dass ein zusätzlicher Aufwand vor der eigentlichen Umsetzung entsteht; dadurch lässt sich aber wertvolle Zeit in der Delivery-Phase einsparen und Irrwege können vermieden werden. In der Product Delivery, geht es dann letztendlich darum, die Discovery-Ergebnisse sinnvoll im Produkt zu integrieren. Das Verhältnis von Discovery zu Delivery fällt in den meisten Unternehmen häufig zugunsten der Delivery-Phase aus. Dies liegt zum einen daran, dass das Verhältnis von Entwicklern zu User Researchern, Designern und Produktmanagern ungleich verteilt ist. Zum anderen verfallen viele Teams, nachdem sie durch eine erfolgreiche Discovery zu einer potentiellen Lösung gelangt sind, recht schnell in einen „Delivery-Modus“.

Product Discovery

A. Hipp und P. Steen

Discovery Backlog

Product Delivery

46

Delivery Backlog

Discovery

Validierte Ideen

Working Soware Sprint

Abb. 3.2   Prozess im Dual Track Agile. (Quelle: Eigene Darstellung)

Produktteams sollten daher regelmäßig folgende Fragen kritisch beantworten:

• Lösen wir immer noch das aktuell wichtigste Kundenproblem und schaffen gleichzeitig den höchsten Gegenwert für unser Unternehmen? • Haben wir das zu lösende Problem komplett verstanden? • Was haben wir in der letzten Woche Neues gelernt, und könnte diese neue Erkenntnis einen Richtungswechsel herbeiführen? ◄ Um Ideen vor der Umsetzung zu validieren, kann das zuvor angesprochene Backlog in zwei separate Bereiche aufgeteilt werden. Ausgehend von der Produktstrategie und der Roadmap kommen alle Ideen zuerst in ein Discovery Backlog (häufig auch Ideen-Backlog genannt). Die Ideen aus diesem Backlog werden dann durch eine ­ Discovery validiert und deren Priorität wird ermittelt. Als Ergebnis der Discovery-Phase ergibt sich dann ein validiertes Delivery Backlog, in dem nur User Stories enthalten sind, für welche die kritischen Risiken in Bezug auf Usability, Feasibility und Viability bereits bewertet wurden. Diese Trennung zwischen Delivery und Discovery wird oftmals als Dual Track Agile bezeichnet und ist in Abb. 3.2 dargestellt.

3.2 Grundprinzipien einer Product Discovery Die konkrete Ausgestaltung während einer Discovery hängt von verschiedenen Faktoren ab. Je nach Unternehmen, Produkt, Teamzusammensetzung und aktueller Fragestellung stehen Produktteams unterschiedliche Methoden und Vorgehensweisen zur Verfügung. Trotzdem gibt es bei der Durchführung einer Product Discovery einige grundlegende Philosophien bzw. Prinzipien, die für jede Discovery gelten und im Folgenden kurz dargestellt werden.

3  Product Discovery

47

3.2.1 Outcome-Orientierung Während es in der Delivery-Phase darum geht, bereits validierte Ideen möglichst effizient umzusetzen, ist das Ziel von Product Discovery herauszufinden, welche Ideen einen wirklichen Kundennutzen haben. Es geht nicht darum, möglichst viele Funktionen umzusetzen, sondern genau die Ideen herauszufinden, die einen tatsächlichen Mehrwert für den Kunden haben und daher wert sind, umgesetzt zu werden. Dabei ist es wichtig, sich auf den Outcome statt auf den Output zu fokussieren. Während Output die produzierten Ergebnisse, also die fertigen Produktfeatures bezeichnet, beschreibt Outcome die Änderungen im Kundenverhalten, die durch die umgesetzten Features erreicht werden.

3.2.2 Nutzerzentrierung und Problemfokussierung Bei der Product Discovery steht immer der Nutzer im Fokus. Statt eine interne, produktfokussierte oder vertriebsgesteuerte Perspektive einzunehmen und Lösungen aus Unternehmenssicht zu definieren, steht der Kunde im Mittelpunkt. Der Ausgangspunkt für eine Product Discovery kann eine Produktidee, eine Veränderung am Markt oder ein identifiziertes Kundenproblem sein. Unabhängig vom Ausgangspunkt der Discovery geht es im ersten Schritt darum, das Kundenproblem möglichst weitreichend zu verstehen. Statt Lösungen zu generieren und eine konkrete Umsetzung für eine Idee zu spezifizieren, geht es in der Discovery also vielmehr zunächst darum, eine Idee durch das detaillierte Verstehen des Problems grundlegend zu validieren. Hierzu sollten Kunden direkt in die Discovery mit eingebunden werden, da so deren Bedürfnisse, Probleme, Wünsche, Anliegen, Ziele und Motivationen hinterfragt und identifiziert werden können. Erst wenn ein tiefes Verständnis des Problems und der damit verbundenen Gründe und Verhaltensweisen gewonnen wurde, können sinnvolle Lösungsansätze erarbeitet werden. Statt sich also (zu) früh auf einen Lösungsweg festzulegen, sollte das Problem gemeinsam im Team aus verschiedenen Blickwinkeln komplett durchdrungen werden. Dies führt zu einem umfassenderen Verständnis, vielfältigen Lösungsideen und somit letztendlich zu besseren Produkten, die stärker genutzt werden.

3.2.3 Iteratives und experimentelles Vorgehen Eine grundlegende Annahme bei der Durchführung von Product Discovery ist, dass viele initiale Ideen falsch sind und Produkte oder Features nicht funktionieren werden. Die schwierige Aufgabe liegt darin herauszufinden, welche der Ideen nicht funktionieren und welche getroffenen Annahmen sich als falsch erweisen.

48

A. Hipp und P. Steen

Kunden einfach danach zu fragen, reicht in der Regel nicht aus, da diese meist zwar gut ihre Probleme beschreiben können, jedoch nur selten eine (gute) Lösung für das Problem kennen. Um herauszufinden, was wirklich funktioniert, ist es daher oft besser, Kunden eine Produktidee ausprobieren zu lassen und dabei ihr Verhalten und ihre Reaktionen zu beobachten. Häufig gibt es mehrere alternative Wege, ein Kundenproblem zu lösen. Um also herauszufinden, wie gut oder schlecht eine Idee ist, müssen die potentiellen Lösungen iterativ getestet werden. Je nach Art des Produktes kann dies durch unterschiedliche Methoden geschehen. Statt fertige Features auszuliefern, können beispielsweise Prototypen genutzt und „am Kunden“ validiert werden. Auf der Basis des Nutzerfeedbacks wird dann entschieden, welche Ideen weiterverfolgt werden und welche Ideen verworfen werden sollten. Durch dieses Vorgehen können Ideen mit vergleichsweise geringem Aufwand validiert und nur die vielversprechendsten Ideen tatsächlich umgesetzt werden. Ergebnisoffenheit

Bei einer Product Discovery geht es nicht darum herauszufinden, wie man ein Feature am besten umsetzt, sondern vielmehr darum, herauszufinden, was überhaupt umgesetzt werden sollte. Aus diesem Grund muss der Prozess einer Discovery ergebnisoffen sein. Folgende Ergebnisse können bei einer Product Discovery herauskommen: • Mehr Discovery: Das Ergebnis einer Discovery kann sein, dass noch nicht genügend Informationen gesammelt werden konnten. In diesem Fall bedarf es weiterer Iterationen, um einzelne Problembereiche tiefgründiger zu verstehen, die wichtigsten Kundenprobleme zu identifizieren und passende Lösungsansätze zu entwickeln. • Idee verwerfen: Ein anderes Ergebnis kann sein, dass eine Idee nicht weiterverfolgt werden sollte. Gründe hierfür können u. a. sein, dass doch kein echtes Kundenproblem gelöst wird oder sich mit vertretbarem Aufwand keine nutzbare bzw. technisch umsetzbare Lösung für das Kundenproblem finden lässt. • Idee umsetzen: Wird ein relevantes Kundenproblem identifiziert und eine passende Lösung gefunden, die tragfähig, nutzbar und umsetzbar ist, sollte sie in der Delivery-Phase umgesetzt werden. • Pivotieren: Findet man in der Discovery heraus, dass die ursprüngliche Idee nicht umgesetzt werden kann oder das Kundenproblem in Wahrheit ein anderes ist, sollte die Richtung bzw. der Fokus geändert werden. Hierbei wird also die ursprüngliche Idee verworfen, um stattdessen eine andere, vielversprechendere Idee zu verfolgen. ◄

3  Product Discovery

49

3.2.4 Interdisziplinarität Während die Zusammensetzung eines Produktteams in der Product Discovery meist fix ist, unterscheidet sich die Zusammensetzung der Personen, die an einer Discovery beteiligt sind, von Discovery zu Discovery häufig. Die Zusammensetzung hängt u. a. vom Thema, der nutzbaren Zeit und den verfügbaren Personen ab. Auf den ersten Blick mag es sinnvoll erscheinen, das Entwicklerteam nur in der Product Delivery einzusetzen, um die Umsetzungsgeschwindigkeit zu maximieren und dadurch schneller Kundenmehrwert zu generieren. In den letzten Jahren hat sich jedoch der Gedanke durchgesetzt, neben dem Produktmanager und einem ­User-Experience-Designer auch die Softwareentwickler an der Product Discovery teilhaben zu lassen. Der Grund ist, dass die Technologie ein zentraler Treiber der Funktionalität eines Produktes ist und heutige Softwareprodukte nicht ohne ein tiefes technisches Verständnis entstehen können. Je nach Thema und Unternehmensstruktur können auch zusätzliche Stakeholder z. B. aus dem Marketing, Vertrieb, Kundensupport, Recht oder der Finanzabteilung sinnvolle Teilnehmer einer Product Discovery sein, um echte cross-funktionale Kollaboration zu ermöglichen. Der Vorteil hierbei ist, dass Probleme und potentielle Lösungen aus unterschiedlichen Perspektiven beleuchtet werden können, Fachwissen aus verschiedenen Bereichen mit einbezogen werden kann und alle Teilnehmer die zu lösenden Probleme direkt vom Nutzer erfahren und mit ihrem eigenen Fachwissen Lösungsansätze generieren können.

3.3 Ausprägungen einer Product Discovery Während die Ziele und Grundprinzipien einer Product Discovery unabhängig vom Produkt, Produktteam und Unternehmen sind, können die konkrete Ausgestaltung einer Product Discovery sowie das Zusammenspiel mit der Product Delivery unterschiedlich ausfallen. In diesem Kapitel wird der Unterschied zwischen einer kontinuierlichen und einer projektbezogenen Discovery aufgezeigt und es wird erläutert, in welchen Fällen welche Variante bevorzugt eingesetzt werden sollte.

3.3.1 Projektbezogene Discovery Eine projektbezogene Discovery beschreibt einen projektartigen, begrenzten Zeitraum vor der Umsetzung eines neuen Produktes oder einer neuen Idee, in der zunächst das Kundenproblem tiefer verstanden und eine Lösung definiert werden sollen. Besonders in einer Produktentwicklung, die wasserfallartig organisiert ist, ist eine Discovery-Phase

50

A. Hipp und P. Steen

praktisch immer projektartig organisiert. Oftmals wird eine projektbezogene Discovery von Agenturen oder externen Auftragnehmern ausgeführt wird. Viele Methoden der projektbezogenen Discovery, wie z. B. der Design Sprint (siehe Abschn. 3.4.1) funktionieren nach einem ähnlichen Prinzip und finden größtenteils isoliert und außerhalb von Product Delivery statt. Ein Produktteam für einen gewissen Zeitraum in einen kompletten Discovery-Modus zu versetzen, um intensive Nutzerinterviews und Usability Tests durchzuführen, kann vor allem in folgenden Situationen sinnvoll sein: • zum Start eines zeitlich begrenzten Projektes (z. B. Agenturarbeit); • um tiefergehende Klarheit zu einem bestimmten Problemfeld zu bekommen; • wenn viele Stakeholder eingebunden werden müssen, die entweder unterschiedliche Wissensstände haben oder räumlich voneinander getrennt sind; • bei der Durchführung von Hackathons.1 Da hierzu der eigentliche Arbeitsrhythmus des Produktteams unterbrochen werden muss und oftmals sogar externe Räumlichkeiten genutzt werden, um den gesamten Fokus auf Discovery zu lenken, lässt sich diese Art von Discovery nur schwer in den regulären agilen Entwicklungsprozess einbinden. Ein weiteres Problem der projektbezogenen Discovery ist, dass Nutzerfeedback i. d. R. nur zu bereits fertigen Lösungen in Form von Produkten bzw. Prototypen eingeholt werden kann. Hierdurch wird hauptsächlich getestet, ob die entwickelte Lösung für den Kunden nutzbar ist, statt die Nutzer bereits zum Start in die Lösungsfindung zu integrieren, um von Anfang an sicherzustellen, dass das richtige Problem gelöst bzw. das richtige Produkt gebaut wird. In allen Szenarien, die sich auf die kontinuierliche Verbesserung eines Produkts konzentrieren, sollten daher neue Produktideen durch den Einsatz einer kontinuierlichen Discovery validiert werden.

3.3.2 Kontinuierliche Discovery Eine der größten Veränderungen, um Software zeitgemäß zu entwickeln, besteht darin, von einer projektbasierten auf eine kontinuierliche Discovery umzustellen (Torres 2016a). Bei der kontinuierlichen Product Discovery steht im Vordergrund, dass ein Produktteam gemeinsam mit Usern eine Problemdefinition und anschließend eine Lösung

1Ein

Hackathon ist eine Veranstaltung bei der als Event organisiert Soft- und Hardware entwickelt wird. Ziel eines Hackathon ist es, innerhalb der Dauer der Veranstaltung gemeinsam nützliche, kreative oder unterhaltsame Produkte herzustellen bzw. Lösungen für gegebene Probleme zu finden.

3  Product Discovery

51 Prototype & Test

Release to Everyone

Opportunies & Soluons

Discovery Customer Feedback

Expand Audience

Launch to Testgroups

Delivery Choose the best Opon

Build

Abb. 3.3   Schematischer Ablauf einer kontinuierlichen Discovery. (Quelle: In Anlehnung an Boduch und Wylie 2019)

erarbeitet. Der wichtigste Faktor hierbei liegt in der Frequenz, in der das Produktteam auf Nutzerfeedback zurückgreift. Ziel dieser regelmäßigen Interaktion ist, die Reaktionen von Nutzern zu geplanten Features oder bestehenden Produkten iterativ herauszufinden und die gewonnenen Erkenntnisse direkt in die Produktentwicklung einfließen zu lassen. Bei einer kontinuierlichen Discovery wird der Kundenkontakt ein fester Bestandteil des Wochenablaufs eines Produktteams, analog zur Sprintplanung bzw. zu Retrospektiven in der Product Delivery. Ein exemplarischer Ablauf einer kontinuierlichen Discovery ist in Abb. 3.3 dargestellt.

3.4 Frameworks zur Strukturierung einer Product Discovery Um neben den Zielen, Prinzipien und Ausprägungen auch konkrete Vorgehensmodelle darzustellen, werden im folgenden Kapitel drei Frameworks für eine Product Discovery vorgestellt. Zuerst wird der Design Sprint für projektbezogene Discovery beschrieben und anschließend werden die Product Kata sowie der Opportunity Solution Tree für eine kontinuierliche Product Discovery dargestellt.

3.4.1 Design Sprint Gerade für Teams, die sich neu mit dem Thema Product Discovery beschäftigen, kann die Vielzahl an möglichen Methoden den Einstieg in die Discovery erschweren. Google Ventures hat dafür mit dem sogenannten Design Sprint ein projektbezogenes Framework in Form einer festen Reihenfolge von Methoden entwickelt, welches es ermöglicht, komplexe Probleme innerhalb einer Woche möglichst vollständig zu verstehen, Lösungen zu erarbeiten und diese mit Kunden zu testen (Knapp et al. 2016).

52

A. Hipp und P. Steen

Ein Design Sprint ist für eine Arbeitswoche konzipiert und gibt für jeden Tag konkrete Ziele, Methoden und Checklisten vor. Es werden Vorschläge zur benötigten Teamgröße, Zusammensetzung des Teams und zur zeitlichen Einteilung der Aufgaben gemacht. Der Ablauf eines Design Sprints ist wie folgt: Montag Der erste Tag des Sprints wird zur Zieldefinition genutzt. Hier wird festgelegt, um welche Nutzer es gehen soll und welcher Abschnitt der User Experience näher betrachtet werden soll. Fragen, die in dem Sprint beantwortet werden sollen, werden festgehalten und grafisch dargestellt. Um eine möglichst detaillierte Zieldefinition zu erhalten, werden Experteninterviews durchgeführt. Dienstag Am zweiten Tag werden erste Lösungsideen entwickelt. Zuerst werden dazu bereits existierende Ideen recherchiert und vorgestellt. Anschließend werden vom gesamten Team neue/alternative Lösungsideen erarbeitet und in Form von skizzenhaften Zeichnungen visualisiert. Mittwoch Idealerweise hat das Team zu Beginn von Tag drei bereits einen Stapel an potentiellen Lösungsansätzen. Da nicht alle Ideen getestet werden können, geht es am Mittwochvormittag darum, jeden Ansatz zu bewerten und die Ideen herauszufiltern, die am besten auf das am Montag definierte Ziel einzahlen. Diese Ideen werden dann am Nachmittag in einen Ablaufplan überführt, welcher die einzelnen Schritte der Lösung detaillierter darstellt und gleichzeitig die Grundlage zur Erstellung eines Prototypen bildet. Donnerstag Am vierten Tag wird der Ablaufplan des vorherigen Tages in einen Prototyp überführt. Dieser soll dazu dienen, die wichtigsten Fragen in Bezug auf die am ersten Tag festgelegte Zielstellung in Nutzerinterviews zu beantworten. Der Prototyp sollte für den Kunden möglichst realistisch aussehen und einen ausreichenden Detailgrad aufweisen, um ein valides Kundenfeedback zu ermöglichen. Freitag Am letzten Tag des Design Sprint wird der erstellte Prototyp mit realen Nutzern getestet. Hier hat sich oft herausgestellt, dass fünf Interviews ausreichen, um eine Lösungsidee zu validieren (Nielsen und Landauer 1993): Die Testpersonen werden von einem Interviewer durch den Prototypen geführt, während der Rest des Teams über einen Videochat in einem separaten Raum zuschaut und sich Notizen macht. Am Ende des Tages wird dann gemeinsam ausgewertet, welche Ideen weiterverfolgt werden und welche Anpassungen ggf. notwendig sind.

3  Product Discovery

53

3.4.2 Product Kata Die Product Kata basiert auf der Toyota Kata, einem Framework zur kontinuierlichen Verbesserung. Wie bei einer Kata aus dem Bereich der Kampfkunst wird hierbei ein Prozess immer wieder ausgeführt, um die Technik optimal zu erlernen. Ziel der Toyota Kata ist es, eine Verbesserung im Unternehmen durch Fokussierung auf schnelles Lernen zu erreichen. Die Toyota Kata beschreibt ein Vorgehensmodell, wie Probleme analysiert und mithilfe von kleinen Experimenten gelöst werden können (Blum 2016; Rother 2009). Melissa Perri (2015) hat die Prinzipien der Toyota Katas auf die Entwicklung von Softwareprodukten übertragen und mit der Product Kata ein Framework beschrieben, welches kurze, nutzerzentrierte Iterationen nutzt, um Lösungen für bestehende Kundenprobleme zu entdecken. Die Product Kata hilft Produktteams, durch eine ständige Wiederholung des Discovery-Prozesses, nicht direkt in Lösungen zu denken, sondern zunächst ein ausreichendes Verständnis für die User sowie deren Umfeld und Probleme zu erhalten, um sich anschließend in kleinen Schritten in Richtung einer geeigneten Problemlösung zu bewegen. Die Abb. 3.4 zeigt, wie eine Iteration des Frameworks exemplarisch abläuft. Im ersten Schritt der Product Kata werden die aktuelle Situation im Unternehmen, die Unternehmensvision sowie das Unternehmensziel ergründet. Basierend darauf wird ein Produktziel in Form einer Produkt-KPI oder eines gewünschten Sollzustands definiert. Ein beispielhafter Sollzustand könnte sein, die Anzahl der Supportanrufe durch einen Self-Service-Bereich im Produkt auf Null zu reduzieren. Strategy Creaon & Development

Execuon

1

2

3

4

Understand the Direcon

Analyze the Current State

Set the next Goal

Choose Step of Product Process

Company Vision & Strategic Intent

Current State of Intents

Product Iniave

Problem Exploraon

Current State of Iniave/Product

Opon Goal

Product Iniave

Soluon Exploraon

Abb. 3.4   Die Product Kata. (Quelle: In Anlehnung an Perri 2018)

Soluon Opmizaon

54

A. Hipp und P. Steen

Im zweiten Schritt wird der Status Quo in Bezug auf das gesetzte Ziel analysiert. Dazu werden das aktuelle Kundenverhalten analysiert sowie die größten Probleme und Hindernisse zur Erreichung des gesetzten Ziels erarbeitet. Statt nun direkt eine oder mehrere Lösungen umzusetzen, geht es in der Product Kata darum, zunächst offene Fragen in Bezug auf das Kundenverhalten zu klären. Die Grundidee ist, dass jede offene Frage ein Hindernis zur Erreichung des Zielzustandes ist. Für das Beispiel des Kundenservice sollten z. B. die Anrufe pro Tag und die Gründe für die Anrufe näher betrachtet werden. In der dritten Phase der Product Kata wird dann ein erstes Teilziel definiert, welches dazu beitragen soll, das Gesamtziel zu erreichen. Dieses wird anhand folgender Fragen erarbeitet: • Was funktioniert bislang gut? • Was ist schlecht? • Was muss verbessert werden, um das Ziel zu erreichen? Ein beispielhaftes Teilziel könnte sein, die Anrufe pro Tag um 10 % zu reduzieren. Sollten keine aktuellen Daten vorhanden sein, könnte auch die Datenbeschaffung zum besseren Verständnis der Situation ein erstes Teilziel sein. Im vierten Schritt werden dann einzelne Experimente zur Erreichung des Teilziels definiert und durchgeführt. Bei den Experimenten geht es darum, das erwartete Kundenverhalten mit dem tatsächlichen Kundenverhalten abzugleichen. Stellt man etwa in dem Beispiel im zweiten Schritt fest, dass Kunden oft mit einer bestimmen Fragestellung anrufen, könnte als Experiment ein Newsletter mit Inhalten zur Beantwortung genau dieser Frage gesendet werden. Anschließend wird gemessen, ob und wie sich das Anrufverhalten nach dem Newsletter ändert. Die Ergebnisse aus den Experimenten, stellen dann den Ausgangszustand für die nächste Iteration der Product Kata dar. Dieser Prozess wird so oft wiederholt, bis das initial im ersten Schritt definierte Ziel erreicht wurde.

3.4.3 Opportunity Solution Tree Der Opportunity Solution Tree ist eine Methode für eine kontinuierliche Product Discovery, um einen Plan zur Erreichung eines Zielzustandes visuell darzustellen. Die Methode dient dazu, implizite Annahmen explizit darzustellen, und hilft Produktteams, sich von einer reinen Lösungs- bzw. Umsetzungsfokussierung zu lösen. Ein Opportunity Solution Tree besteht aus den folgenden vier Bereichen:

3  Product Discovery

• • • •

55

ein gewünschtes Outcome, Opportunities, wie dieses Outcome erreicht werden kann, konkrete Umsetzungsideen zu den jeweiligen Opportunities sowie Experimente, um die Ideen selbst bzw. deren Annahmen zu validieren.

Um einen Opportunity Solution Tree zu erstellen, wird zuerst ein gewünschtes Outcome klar definiert. Dies kann in Form eines Anstiegs oder eines Rückgangs einer Zielmetrik ausgedrückt werden. Das Objective einer OKR-Definition ist hierfür beispielsweise ein geeignetes Format.2 Im Falle einer Social-Media-Plattform, könnte ein gewünschtes Outcome zum Beispiel sein, das Engagement der Nutzer zu erhöhen. Anschließend werden alle Opportunities, die auf das gewünschte Outcome einzahlen, festgehalten. Opportunities können Kundenbedürfnisse bzw. ungelösten Kundenprobleme und -wünsche sein. Falls hierzu keine Erkenntnisse vorliegen, können zunächst Annahmen getroffen werden, die später durch User Research validiert werden. Im Beispiel der Social-Media-Plattform könnte eine Opportunity sein, vorhandene Inhalte auf der Plattform stärker zu nutzen. Eine weitere Opportunity könnte sein, Nutzer anzuregen, mehr neue Inhalte zu erstellen. Im dritten Schritt werden zu jeder Opportunity Lösungsansätze bzw. Umsetzungsideen festgehalten. Dabei werden nur die Ideen berücksichtigt, die auch einer Opportunity zugeordnet werden können. Kann eine Idee keiner Opportunity zugeordnet werden, wird sie nicht weiterverfolgt. Beispielhafte Ideen für die Opportunity, vorhandene Inhalte auf der Social-Media-Plattform stärker zu nutzen, könnten Features wie ein Like-Button, ein personalisierter Newsfeed oder Benachrichtigungen für Nutzer sein. Im letzten Schritt werden zu jeder Idee Experimente definiert. Bei den Experimenten soll nicht die Idee selbst in Form eines Produktinkrements getestet werden, sondern die zentralen Annahmen hinter einer Lösungsidee. Beispielhafte Methoden für diese Experimente können sein: ein Concierge-Test, Wizard-of-OZ-Tests, Smoke Screens oder FakeDoor-Tests.3

2Objectives

& Key Results (kurz: OKR) ist ein Vorgehensmodell, um Ziele und deren Outcomes zu definieren und nachzuhalten. Zum OKR-Konzept s. Kap. 6 „Wirkungsorientiertes Produktmanagement mit OKR“ von Sonja Mewes. 3Zu den einzelnen Methoden s. ausführlich Jacobsen und Meyer (2019).

56

A. Hipp und P. Steen

Desired Outcome

Soluon

Soluon

Opportunity

Opportunity

Opportunity

Soluon

Soluon

Soluon

Soluon

Experiment

Experiment

Experiment

Experiment

Soluon

Experiment

Abb. 3.5   Opportunity Solution Tree. (Quelle: In Anlehnung an Torres 2016b)

Verbindet man Outcomes, Opportunities, Ideen und Experimente, ergibt sich der Opportunity Solution Tree (Abb. 3.5), welcher der Methode seinen Namen gegeben hat: Da bei einem Opportunity Solution Tree nicht direkt in Lösungen gedacht wird, sondern Opportunities und Lösungen gleichzeitig betrachtet werden, ist er gut geeignet, eine kontinuierliche Discovery zu strukturieren. Weiterhin eignet sich die Methode gut dazu, die Discovery nachträglich in einen bereits etablierten Delivery-Prozess zu integrieren, da hiermit jedem Backlog Discovery-Ergebnisse zugeordnet werden können. Durch das Verlinken der Ideen im Backlog mit qualitativen und quantitativen Daten wird das gewünschte Outcome hinter den Ideen deutlich.

3.5 Product Discovery Toolbox Neben den im vorherigen Kapitel vorgestellten Frameworks zur projektbezogenen und kontinuierlichen Discovery gibt es eine Vielzahl einzelner Discovery-Methoden, um mehr über User, eine Produktidee, den Wettbewerb oder das eigene Unternehmen herauszufinden. Gemeinsames Ziel dieser Methoden ist es, unterschiedliche Risiken, wie die wirtschaftliche Tragfähigkeit, Nutzbarkeit, den Nutzen bzw. die Umsetzbarkeit einer Produktidee zu reduzieren. Aufgrund der großen Anzahl verfügbarer Methoden kann die Auswahl gerade für Einsteiger beim Thema Product Discovery schwierig sein.

3  Product Discovery

57

Die Auswahl einer konkreten Methode sollte stets mit einer klaren Problembeschreibung starten. Dabei sollten das Thema und die Zielstellung, was in einer Discovery herausgefunden werden soll, festgehalten werden. Mögliche Themenbereiche einer Product Discovery sind: • Nutzer: Fragen über Nutzer, z. B. zu Verhalten, Problemen und Bedürfnissen • Produkt: Fragen zum eigenen Produkt, z. B. zur Nutzbarkeit • Wettbewerb: Fragen aus externer Unternehmenssicht, z. B. Positionierung gegenüber dem Wettbewerb • Organisation: Fragen aus unternehmensinterner Sicht, z. B. Stärken und Schwächen Basierend auf dem Themenbereich stehen verschiedene Methoden zur Verfügung. Eine nach den Bereichen gegliederte Übersicht sinnvoller Methoden ist in Abb. 3.6 dargestellt. Detaillierte Informationen zu den Methoden und ihren konkreten Anwendungen können bei Erika Hall (2013), Bella Martin und Bruce Hanington (2012) bzw. auf der Internetseite www.designkit.org/methods von Ideo.org (2020) gefunden werden.

Interviews Contextual Inquiry

Interviews User

Usability Tesng

Literature Review

A/B Tesng

Quesons about

Organizaon

Product

Usability Tesng

SWOTAnalysis

Brand Audit

Compeon

Compeve Analysis Heurisc Analysis

Abb. 3.6   Methodenübersicht Product Discovery. (Quelle: In Anlehnung an Hall 2013)

58

A. Hipp und P. Steen

3.6 Praktische Hinweise zur Anwendung einer Product Discovery im Unternehmen Da Produktteams immer die Herausforderung haben, gleichzeitig sowohl in der Discovery als auch in der Delivery Ergebnisse erzielen zu müssen, werden im ersten Abschnitt die Entwicklungen in den beiden Bereichen und die Verbreitung von Product Discovery in Unternehmen kritisch betrachtet. Abschließend wird beschrieben, welche Herausforderungen sich bei der Einführung einer kontinuierlichen Product Discovery ergeben und wie diese adressiert werden können.

3.6.1 Folgen einer Fokussierung auf die Product Delivery Bei der Professionalisierung der Product Delivery wurden in den letzten Jahren erhebliche Fortschritte erzielt. Auch bei der Product Discovery gab es solche Entwicklungen, die jedoch bisher in vielen Produktteams noch kein fester Bestandteil der täglichen Arbeit geworden sind. Während z. B. das Daily Standup bei der Product Delivery bei praktisch allen Produktteams Einzug gehalten hat, sind Methoden aus dem Design Thinking oder die regelmäßige Durchführung von Nutzerinterviews noch nicht flächendeckend angenommen. Obwohl die Vorteile einer nutzerzentrierten Discovery, die auf einer konsequenten Validierung der eigenen Annahmen mit dem Interviewen von richtigen Nutzern beruhen, vielen Unternehmen bekannt sind und im Grundsatz auch eine breite Zustimmung finden, gibt es immer noch viele Unternehmen, die keine explizite Product Discovery durchführen. Dafür gibt es mehrere Gründe: Zum einen sind die Rekrutierung von Nutzern und die Durchführung von Interviews kostenintensiv und zeitaufwändig. Zum anderen werden die Erkenntnisse aus Nutzerinterviews oftmals nicht gut genug im Unternehmen kommuniziert, sondern verbleiben isoliert in einzelnen Abteilungen oder Teams, was die Akzeptanz der Nutzerinterviews schmälert. Darüber hinaus denken viele Teams, ihre Nutzer und deren Bedürfnisse ausreichend zu kennen und gehen deshalb davon aus, dass sie ihr Verhalten auf Produktveränderungen vorhersagen können. Die Annahme, Nutzerbedürfnisse bereits zu kennen, manifestiert sich häufig auch stark in der Art, wie eine Product Discovery durchgeführt wird: Produktteams, die davon ausgehen, eh zu wissen, was der Kunde braucht, neigen stark dazu, eine längere Zeit am Stück zu „discovern“, um dann mit dem Ergebnis ihr Product Backlog für mehrere Wochen „Delivery“ zu füllen. Das hat zur Folge, dass Teams sich zu Beginn eines Quartals, meist in Form einer detaillierten Roadmap, dazu verpflichten, bestimmte Features, die man in der Discovery definiert hat, zu entwickeln und bis zu einem bestimmten Zeitpunkt fertigzustellen.

3  Product Discovery

59

Das Erstellen einer detaillierten Roadmap beruht jedoch auf der falschen Annahme, dass Features ganz genau nach Plan fertiggestellt werden können und direkt ein spezielles Kundenproblem zu 100 % lösen. (Zu) Viele Teams beschreiben Product Discovery als linearen Prozess. Die Realität zeigt jedoch, dass eine gute Discovery alles andere als linear ist. Marty Cagan (2012) beschreibt, den Prozess passenderweise als „messy“. Man muss also in der Lage sein, auf neue Erkenntnisse aus analytischen Daten, Nutzer-Interviews oder Veränderungen am Markt reagieren zu können. Daher ist es für die meisten Teams sinnvoller, kontinuierlich neue Produktverbesserungen zu identifizieren, zu validieren und zu beschreiben.

3.6.2 Potentielle Stolpersteine bei der Einführung von Product Discovery Neben den bereits beschriebenen Herausforderungen bei der Product Discovery, ergeben sich bei der Einführung einer kontinuierlichen Product Discovery häufig zusätzliche Herausforderungen für Produktteams.

3.6.2.1 Fremdbestimmung von Produktteams Ein typischer Konflikt bei der Entwicklung digitaler Produkte liegt im Grad der Selbstbestimmung des Produktteams. Um eine kontinuierliche Discovery erfolgreich im Produktentwicklungsprozess zu integrieren, sollten Produktteams befähigt sein, eigenverantwortlich Entscheidungen zu treffen. Statt eine Product Roadmap mit vordefinierten Features abarbeiten zu müssen, sollte das Team von Anfang bis Ende für die Validierung von Produktfeatures und den Weg zur Erreichung der Ziele verantwortlich sein. Diese Verantwortlichkeit kann jedoch nur funktionieren, wenn das Produktteam als echtes cross-funktionales Team zusammengesetzt wurde. Hierzu benötigt das Produktteam den Zugriff auf Experten aus verschiedenen Unternehmensbereichen (z. B. Recht, Kundensupport, Vertrieb, Marketing, Finanzen), um selbstständig Probleme zu identifizieren und passende Lösungen zu finden. Hierbei tun sich viele Unternehmen schwer. In der betrieblichen Realität können viele Produktteams nicht wirklich selbstverantwortlich handeln und haben es besonders im Bereich der Business-Bewertung von Produkten noch immer schwer, selbstständig Entscheidungen zu treffen (Cagan 2019). Sobald die wirtschaftlichen Entscheidungen eines Produktes aber bei einem Stakeholder außerhalb des Produktteams liegen, der die Roadmap bestimmt, kann das Team keine eigenständigen Entscheidungen treffen, was als nächstes umgesetzt werden sollte. Dadurch kann eine Product Discovery nicht richtig gelebt werden. Eine Lösung, den Selbstbestimmungsgrad von Produktteams zu erhöhen, kann darin liegen, frühzeitig transparente Absprachen mit Stakeholdern über Entscheidungsräume zu treffen. Auf diese Weise ist allen Beteiligten klar, welche Entscheidungen eigenständig im Team getroffen werden können und ab wann Stakeholder mit einbezogen werden müssen.

60

A. Hipp und P. Steen

3.6.2.2 Output statt Outcome Während bei der Product Delivery irgendwann Features ausgeliefert werden und somit die Arbeitsergebnisse sichtbar werden, ist eine Product Discovery als Prozess mit unklaren Ergebnissen und ggf. sogar einer unbestimmten Dauer für Führungskräfte oft schwer greifbar. Ein befürchteter Autoritätsverlust hindert sie daher vielfach daran, den Teams die nötige Autonomie zu geben. So treffen traditionelle Führungsmethoden eines autoritären Managements auf moderne Arbeitsmethoden mit selbstorganisierten Teams. Um Kontrolle über den Prozess auszuüben und ihn scheinbar vorhersagbar zu machen, wird eine Product Discovery dann beispielsweise mit einem festen Zeitraum versehen. Dies nimmt Produktmanagern den notwendigen Handlungsspielraum und lenkt den Fokus des Produktteams ausschließlich auf die Product Delivery. In dem Fall kann eine praktikable Lösung darin liegen, gemeinsam mit der Führungsebene klare Quartalsziele zu setzen, die in Form von Kennzahlen und Metriken und nicht in Form konkreter Features formuliert sind. Dies lässt Produktteams den notwendigen Handlungsspielraum, die richtigen Features umzusetzen, und führt so hoffentlich zu erfolgreicheren Produkten. 3.6.2.3 Kein regelmäßiger Austausch mit dem User Da der Rekrutierungsprozess für Nutzerinterviews oft aufwendig und teuer ist und auch die Vorbereitungen auf ein Interview meist einen recht hohen Zeitaufwand bedeuten, verlieren viele Unternehmen und Teams nach einiger Zeit den Drang, regelmäßig mit der Zielgruppe in Kontakt zu treten. Dies kann jedoch durch automatisierte bzw. sog. Ad-Hoc-Rekrutierungen erheblich vereinfach werden. Statt aufwändige persönliche Nutzerinterviews zu führen, können so Nutzer beispielsweise direkt bei der Nutzung eines Produktes über ­Smartphone-Benachrichtigungen (Push Notifications), Online-Fragebögen oder auch einen Chat befragt werden. Bei B2BProdukten können darüber hinaus auch der Vertrieb oder Kundensupport genutzt werden, Nutzer mit einem bestimmten Nutzungsverhalten für ein persönliches Interview zu rekrutieren. Wichtig ist auf jeden Fall, regelmäßig mit echten Nutzern im Austausch zu sein, damit eine Product Discovery zu wirkungsvollen Produkten führt.

Literatur Boduch, E., und J. Wylie 2019. Continous discovery in product-led companies. www.slideshare. net/jfalk415/continuous-discovery-in-productled-companies. Blum, C. 2016. Die Toyota KATA – Kampfsport oder echtes Erfolgsrezept? www.managementcircle.de/blog/die-toyota-kata-kampfsport-oder-echtes-erfolgsrezept. Cagan, M. 2012. Dual-Track Agile. https://svpg.com/dual-track-agile. Cagan, M. 2018. Inspired – How to create tech products customers love, 2. Aufl. New Jersey: Wiley. Cagan, M. 2019. Product vs. feature teams. https://svpg.com/product-vs-feature-teams. Hall, E. 2013. Just enough research. New York: A Book Apart.

3  Product Discovery

61

Ideo.org. Hrsg. 2020. The field guide to human-centered design. www.designkit.org. Jacobsen, J., und L. Meyer. 2019. Praxisbuch Usability und UX, 2. Aufl. Bonn: Rheinwerk. Knapp, J., J. Zeratsky, und B. Kowitz. 2016. Sprint – Solve big problems and test new ideas in just five days. New York: Simon & Schuster. Martin, B., und B. Hanington 2012. Universal methods of design. Essex County: Rockport Publishers. Nielsen, J., und T. Landauer 1993. A Mathematical model of the finding of usability problems. Proceedings of ACM Interchi’93 Conference, Amsterdam. Perri, M. 2015. The product Kata. https://melissaperri.com/blog/2015/07/22/the-product-kata. Perri, M. 2018. Escaping the build trap: How effective product management creates real value. Sebastopol: O’Reilly Media. Rother, M. 2009. Toyota Kata: Managing people for improvement, adaptiveness and superior results. New York: McGraw-Hill. Torres, T. 2016a. The rise of modern product discovery. www.producttalk.org/2016/03/risemodern-product-discovery. Torres, T. 2016b. Why this opportunity solution tree is changing the way product teams work. www.producttalk.org/2016/08/opportunity-solution-tree. Torres, T. 2017. The evolution of modern product discovery. www.producttalk.org/2017/02/ evolution-product-discovery.

Die Autoren Alexander Hipp  arbeitet aktuell als Senior Product Manager bei der Neobank N26 in Barcelona, Spanien. Dort arbeitet er zusammen mit seinem Team an den ­Subscription-Produkten und der Kartenbereitstellung der Bank. Zuvor war er Teil des Teams der XING GmbH und hat dort mit dem Mobile-App-Team und dem Data Engineering zusammengearbeitet. Vor seiner „Product Management“-Laufbahn hat er einen Master in Kommunikation- und Medienmanagement in Karlsruhe und London absolviert, und in Boston und auf Hawai’i gearbeitet. Er ist Mitbegründer der Product Management Buchempfehlungsplattform „PM Library“ und aktiver Organisator der Product Tank Meetups in Hamburg und Barcelona. Kontakt: [email protected] Philip Steen  ist Geschäftsführer der Firma IDALABS GmbH & Co. KG, die Softwareprodukte zur Digitalisierung der Unternehmensprozesse von kleinen und mittelständischen Handwerksunternehmen entwickelt. Zuvor war er als Produktmanager zunächst festangestellt und anschließend freiberuflich unter anderem für die Fielmann AG, AIDA Cruises und Costa Cruises in Asien tätig. Hierbei hat er den Aufbau neuer Produktteams vorangetrieben und war für mobile Apps sowie Webanwendungen im E-Commerce verantwortlich. Sein Masterstudium im Bereich Wirtschaftsinformatik/IT-Management hat er an der Nordakademie in Hamburg absolviert. Kontakt: [email protected]

4

Validierung von Produktideen am Markt Erfahrungen, Inspirationen und woher man weiß, ob damit Geld zu verdienen ist Anna Wicher

Zusammenfassung

In diesem Kapitel wird beschrieben, wie Validierungsprozesse aussehen können und welche Tools dafür sinnvoll einsetzbar sind. Die Autorin teilt dabei hilfreiche Erfahrungen aus der Praxis und führt von den ersten Rahmenbedingungen der Validierung hin zu der Bedeutung der Recherchearbeit und zeigt auf, wie relevant eine solche Vorarbeit in der Praxis tatsächlich für ein Projekt ist. Weiterhin werden das Prototyping mit den zu klärenden Elementen, wie Zieldefinition, UX und UI und die Frage nach der adäquaten Technologie, eingeführt und anschließend das Testing beleuchtet. Abschließend wird aufgezeigt, wie erfolgreiche Projektideen weitergeführt werden können.

4.1 Warum Validierung? „Eines Morgens stand ich unter der Dusche und hatte eine großartige Produktidee. Mir fehlte danach nur noch ein bisschen Geld, um diese Idee umzusetzen und damit unfassbar viel Geld zu verdienen.“ So ähnlich fängt die Entwicklung eines neuen Produkts oft an. Ob als StartupGründerin, die dann auf der Suche nach einem Investor ist, oder als Ideengeber in einem größeren Konzern, der die Idee vor dem Management pitcht, ein Investment für die Umsetzung bekommt und mit der Umsetzung beginnt. Der theoretische Prozess der

A. Wicher (*)  G+J Innovation GmbH, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_4

63

64

A. Wicher

Entwicklung einer neuen Idee ist ja im Grunde auch denkbar einfach: Jemand hat eine Idee, es wird Geld investiert und ein neues, großartiges Produkt kommt auf den Markt. Was aber vergisst man dabei oft – vor allem bei Corporate Startup-Projekten? All das, was bei einer nutzerzentrierten Entwicklung von der Idee bis zum marktreifen, investitionswürdigen Produkt unterwegs passieren sollte: Der Blick auf den Markt und die Beantwortung von ein paar sehr wichtigen Fragen: Welches Problem von echten Nutzern da draußen löst die Idee denn eigentlich? Und ist die Idee die richtige Lösung für dieses Problem? Wie viele Menschen haben dieses Problem? Wie lösen sie das Problem bisher? Und besonders wichtig: Sind sie bereit, für die neue Lösung ihres Problems Geld auszugeben? Setzt man die ursprüngliche Idee für ein neues Produkt unter Ausschluss der Außenwelt im stillen Kämmerlein um – ohne unterwegs zu überprüfen (aka zu validieren), ob man ein echtes User-Problem löst –, dann überspringt man die oft vielfältigen Verbesserungen bzw. Richtungsänderungen (Pivots), die in den meisten Fällen nötig sind, um aus einer Idee tatsächlich das Produkt zu machen, welches am Markt die nötige Zahlungsbereitschaft auslöst, um darauf ein funktionierendes Geschäft aufzubauen. In Wahrheit ist der Prozess der Entwicklung einer neuen Idee eben viel chaotischer. Im Laufe der Entwicklung und Validierung am Markt lernt man viel über Markt und Zielgruppe, womit sich die Idee und das daraus entstehende Geschäftsmodell meist mehrmals verändern. Bei Ideen, die in einem Konzernumfeld entstehen, hängen solche Veränderungen der ursprünglichen Idee in vielen Fällen an langen Entscheidungsprozessen. Für die Umsetzung der ersten Idee wurde oft schon viel Geld ausgegeben. Aufgrund begrenzter Innovationsbudgets können zudem vielfach nur wenige Ideen gleichzeitig getestet werden und auf denjenigen, die ein Investment ergattern konnten, liegt großer Druck. Daher und aufgrund der hohen Anfangskosten fällt eine Veränderung der ersten Idee, oder gar die Entscheidung, ein Projekt als gescheitert zu deklarieren und zu beenden, sehr schwer oder wird erst (zu) spät getroffen. Wie lässt sich das lösen? Die Investitionsentscheidung für ein neues Produkt muss von der Validierung getrennt werden, indem die Validierung mit einem kleinen Budget vorangestellt wird. Erst mit validen Marktzahlen und einem Businessplan, der den Blick auf den Markt und die Beantwortung von ein paar wichtigen Fragen enthält, wird dann die eigentliche Investitionsentscheidung getroffen. Das funktioniert auch, indem eine Kultur gefördert wird, die ein Innovationsprojekt als erfolgreich ansieht, wenn es erfolgreich getestet wurde und man darauf aufbauend eine datenbasierte Entscheidung treffen kann, ob die Idee eine Investition wert ist oder nicht. Das setzt natürlich Zeit, Ressourcen und Know-how für eine solche Vorab-Validierung voraus – sie zu investieren spart aber meiner Erfahrung nach zum einen Innovationsgelder, zum anderen können Teams über ein derart testgetriebenes Arbeiten extrem viel über Märkte, Nutzer und Mechanismen lernen, die auch über den Erfolg von anderen Produkten entscheiden und so langfristig und nachhaltig bessere Produkte voranbringen.

4  Validierung von Produktideen am Markt

65

4.1.1 Worum wird es hier gehen? Wie so ein Validierungsprozess aussehen kann und welche Tools und Arbeitsweisen dabei hilfreich sein können, beschreibe ich in diesem Kapitel – vieles stammt aus den Themenbereichen agile Entwicklung, Design Thinking und Lean Startup. Was ich beschreibe ist jedoch keinesfalls reine Lehre oder der einzig richtige Weg, sondern basiert auf den Erfahrungen, die ich im Laufe der Arbeit an vielen unterschiedlichen Projekten gemacht habe. Mein Fokus liegt dabei vor allem auf dem Was zu tun ist und Warum, weniger detailliert auf dem Wie. In jeder Phase gibt es Tools, die sich empfehlen und die hilfreich sein können. Es kommt dabei nicht nur auf das richtige Tool an, sondern vor allem auf die richtige Auswahl. Es hilft wenig, ein Problem mit 10 Tools zu bewerfen; wichtiger ist zu erkennen, welches Tool in welcher Situation wirklich helfen kann, um eine Produktidee voranzubringen. Daher kann dieser Beitrag keine Anleitung für jedes Validierungsprojekt sein, sondern maximal Inspirationen liefern, in welche Richtung man mit dem eigenen Projekt gehen könnte. Jetzt aber zur Sache: Im Grunde lässt sich die Validierung von neuen Produktideen in drei Phasen unterteilen, um die es im Folgenden gehen wird: a) Research b) Prototyping (MVP-Entwicklung) c) Testing & Auswertung Besonders am Ende der ersten Phase gilt es, nochmal einen Schritt zurück zu machen und zu bewerten, ob eine Fortführung des Projektes in der geplanten Form sinnvoll ist oder ob jetzt schon absehbar ist, dass der Businesserfolg der Idee sehr unwahrscheinlich ist. Die zweite und dritte Phase sind eher künstlich getrennt, da sie ineinander übergehen und voneinander abhängen; die eine wird oder sollte ohne die andere nicht stattfinden.

4.1.2 Wie lange dauert so eine Validierung normalerweise? Wenn wir ehrlich sind, ist das ein bisschen Glaskugellesen, da die Antwort davon abhängt, wie das MVP (Minimum Viable Product, mehr dazu im nächsten Abschnitt) am Ende aussieht. Meint man es ernst damit, die Validierung von der Umsetzung und Investitionsentscheidung zu trennen, sollte das Validierungsprojekt jedoch nicht länger als 3–5 Monate dauern, siehe Abb. 4.1 Alles darüber hinaus bedarf meist schon größerer Investitionen, sodass es kaum noch als Vorab-Validierung zu bezeichnen ist, sondern eher als Inkubation einer Startup-Idee. Auch das kann seine Berechtigung haben, sollte aber immer eine aktive Entscheidung sein. Es lohnt sich einmal zu hinterfragen, ob eine erste Validierung nicht doch schneller und damit auch günstiger möglich ist.

66

A. Wicher Projektwoche

Projektphase

1

4

8

12

16

20

Research MVP-Entwicklung Tesng und Auswertung

Abb. 4.1   Projektphasen eines Validierungsprojektes. (Quelle: Eigene Darstellung)

Ein großer Zeitfaktor bei Validierungen innerhalb eines Konzerns sind meist Abstimmungen mit anderen Bereichen im Konzern. Meiner Erfahrung nach ist es daher für die erste Validierung oft hilfreich, einen möglichst unabhängigen, von wenig anderen Bereichen beeinflussten Weg zu gehen.

4.1.3 Was für ein Team brauche ich zur Validierung? Die benötigte Expertise bzw. die benötigten Fähigkeiten unterscheiden sich stark in den drei Phasen, die das Projekt durchläuft. Wenn die benötigten Fähigkeiten nicht vorhanden sind, sollte der Project Lead dafür sorgen, dass er diese Expertise rechtzeitig einplant und an Bord holt: Meistens benötigt man, vor allem in der ersten Phase, nur einen Project Lead und jemanden, der ihr/ihm entlang des Projekts immer wieder die „richtigen Fragen“ stellt, d. h. einen Sparrings-Partner, der hilft, Gedanken zu überprüfen und Ideen zu jonglieren. Alles weitere ergibt sich aus dem Projekt und vor allem aus dem zu testenden MVP. Der Project Lead ist in meiner Betrachtung im Kern auch der oder die ProduktmanagerIn; ihre oder seine Aufgaben sind im hier erläuterten Vorgehen einer Marktvalidierung an vielen Stellen Projektmanagementaufgaben; daher spreche ich vom Project Lead. Im Grunde sind aber alle Aufgaben des Project Lead bestens mit einem oder einer ProduktmanagerIn besetzt, vor allem, wenn es um die Validierung einer Innovationsidee aus einem bestehenden Produktteam heraus geht. In der ersten Phase sind vor allem Vorerfahrungen aus dem Bereich User-Research bzw. Design Thinking hilfreich. Im zweiten Schritt, wenn es darum geht, das MVP umzusetzen, hängt die benötigte Expertise von der Art und Form des MVPs ab. Wird etwa mit einem technischen MVP getestet – was hier im Fokus stehen soll, da es vor allem für Produktmanager wohl der interessanteste Case ist – benötigt man in der Regel ein kleines Produktteam: Produktexpertise des Project Leads, einen Designer der sich um die UI und UX1, also das Aussehen und die Funktionsweise des Produktes, kümmert und

1UI

steht für User Interface und meint meist das Design, UX steht für User Experience und meint die Funktionsweise, also das, was der Nutzer „erlebt“.

4  Validierung von Produktideen am Markt

67

Entwickler, die das Ganze umsetzen. Je nach Art des Produktes ist ggf. noch eine zusätzliche ­Content-Expertise vonnöten. In der Testphase schließlich sind Marketingexpertise, Know-how zur Datenauswertung und schließlich BWL-Kenntnisse, um einen guten Businessplan aufzustellen, besonders wichtig.

4.2 Research – Womit fangen wir an? Mit einer Produktidee im Kopf hat man meist schon ganz viel Wissen, das einen zu dieser Idee geführt hat. Der wichtigste und oft schwerste Schritt, um eine neue Produktidee wirklich zu validieren, ist der, die Produktidee zurückzustellen und für den Research (die „Marktforschung“) die dahinterliegenden Nutzerbedürfnisse herauszuarbeiten – um deren tatsächliche Existenz zu überprüfen. Der Research dient dazu, das echte Problem hinter einer Produktidee zu finden, zu verstehen, wie relevant dieses Problem wirklich ist und wie bzw. ob es am Markt bereits von anderen bestehenden Produkten oder Workarounds gelöst wird. Wenn wir das gemacht und mit Usern gesprochen haben, bei denen dieses Problem auftritt, und am Ende des Tages feststellen, dass unsere ursprüngliche Produktidee vielleicht wirklich eine gute Lösung für ein tatsächlich am Markt existierendes Problem ist, können wir sie wieder hervorholen und ausarbeiten. Haben wir die Idee jedoch die ganze Zeit im Kopf, wird sie unsere Research-Ergebnisse verfälschen, da wir nicht wirklich versuchen, ein Problem zu finden oder zu verstehen, sondern lediglich bemüht sind, Beweise dafür zu finden, dass unsere Produktidee gut ist und jemandem gefällt. Der wichtigste Schritt eines Validierungsprojektes ist nicht die Umsetzung des Prototypen, sondern der vorbereitende Research, der mit dem Testplan als Grundlage für die MVP-Definition dient, sowie der Blick auf die Zahlen am Ende, die für die Kalkulation des Businessplans relevant sind.

4.2.1 Hypothesen – Was nehmen wir bisher an? Um zunächst einen Überblick zu bekommen über die Annahmen, die für den Erfolg des Produktes wichtig sind und darüber, was wir bereits wissen, stellen wir Hypothesen auf. Die Aufstellung von bisherigen Annahmen und eventuellem Wissen in Form von Hypothesen zu machen, die es zu beweisen bzw. zu widerlegen gilt, hilft, um alle Informationen, die wir eventuell schon mitbringen, noch einmal zu hinterfragen. Wo bringen wir bereits validiertes Wissen mit und wo treffen wir lediglich eine Annahme? Worauf basieren unsere Annahmen? Müssen wir sie überprüfen oder reicht die bereits vorhandene Datengrundlage aus? Und schließlich: Sind die Annahmen überhaupt wichtig für den Erfolg der Idee? Im Folgenden wird das anhand eines konkreten Beispiels einmal illustriert.

68

A. Wicher Beispiel

Wir sind mit einem Print-Magazin zum Thema „Achtsamkeit“ am Markt erfolgreich. Die Idee entsteht, dass man doch eigentlich auch schauen könnte, was sich Digitales zum Thema Achtsamkeit machen lässt. Was wissen wir aus dem bestehenden Print-Geschäft bereits und was können wir nur annehmen? Hier ist ein Ausschnitt, wie erste Hypothesen zu diesem Thema aussehen könnten, die den User-Research strukturieren und leiten: • Für das Thema Achtsamkeit gibt es eine Zielgruppe, die Interesse an der Nutzung eines digitalen Produktes zum Thema Achtsamkeit hat. • Der Markt ist groß genug, um darin erfolgreich zu sein: Laut einer Studie beträgt das Meditations- und Achtsamkeitsgeschäftsfeld fast 1 Mrd. Dollar. • Es gibt noch Lücken im bestehenden Markt; Probleme der Zielgruppe sind noch nicht erschöpfend gelöst. • Wir haben mit unserem Wissen und unseren vorhandenen Ressourcen im Bereich Achtsamkeit einen Vorteil gegenüber anderen Playern am Markt. ◄ Zu jeder Hypothese, die Grundlage für den Erfolg des Geschäftsmodells ist, gilt es zu definieren, was der überprüfbare Key Performance Indicator (KPI) ist; also die Zahl, mit der man die Richtigkeit der Hypothese messen kann. Außerdem muss festgehalten werden, wie der Test aussehen soll (Testcase), mit dem man den KPI messen kann – sofern das zu Beginn der Research-Phase schon möglich ist. Und schließlich muss man sich darauf verständigen, welchen Wert der KPI (mindestens/höchstens) haben darf, damit man den Test als Erfolg einstuft (Breaking Point). Hypothesen, die wir in dieser Phase aufstellen, können sich im Laufe der Research-Phase stark verändern; es können neue hinzukommen und bisherige hin­ fällig werden. Es ist sogar sehr wahrscheinlich, dass wir die Arbeit an den Hypothesen nach der Research-Phase noch einmal ganz neu vornehmen müssen. Wir erstellen dann neue ­Testing-Hypothesen für das MVP, das wir bis dahin definiert haben und umsetzen möchten, da wir ggf. bis dahin so viel Neues gelernt haben, dass unsere ursprünglichen Hypothesen nicht mehr ausreichen oder nicht mehr hilfreich sind. Dennoch ist es sinnvoll und wichtig, die Arbeit an KPIs, Testcases und Breaking Points – soweit es geht – einmal zu Beginn zu machen. Es hilft dabei, sich immer wieder selber zu hinterfragen: Was habe ich zu Beginn gedacht, was Erfolg bedeutet, und wovon bin ich ausgegangen? Man biegt sich die Realität und den Erfolg ansonsten anhand späterer Ergebnisse allzu leicht zurecht. Beispielsweise reichen dann Ergebnisse zum Erfolg, bei denen man vielleicht zu Beginn des Projektes gesagt hätte: Wenn wir diesen Wert nicht erreichen, kann das nicht funktionieren. Das mag legitim sein, da man eventuell neue Erkenntnisse gewonnen hat, die das Geschäftsmodell verändern; diese Erkenntnisse werden aber durch den Check der ursprünglichen Hypothesen dann noch einmal reflektiert, was normalerweise zu besseren Entscheidungen führt.

4  Validierung von Produktideen am Markt

69

Ziel der Aufstellung von Hypothesen ist es demnach, das vorhandene Wissen zu überprüfen und zu strukturieren, Annahmen von Fakten zu trennen und anhand der Hypothesen einen ersten Scope (Umfang/Rahmen) für das Projekt zu umreißen.

4.2.2 Marktanalyse und Zielgruppendefinition – Worauf beziehen sich unsere ersten Annahmen? Um eine erste grundsätzliche Potentialanalyse für den Markt und das Themenfeld zu machen, ist es wichtig, sich den relevanten Markt genauer anzuschauen. Man bekommt so schnell ein besseres Gefühl für den Kontext einer Idee. Die Markrecherche sollte im Ergebnis folgende Fragen beantworten: • Welche Player gibt es bereits am Markt; wie sieht der potentielle Wettbewerb aus? • Wie sehen derzeitige Lösungen dieser Player am Markt aus? • Welche Zielgruppen werden von ihnen angesprochen? • Wie groß sind diese Zielgruppen ersten Abschätzungen zufolge? • Wie können diese Zielgruppen erreicht werden? • Welche Probleme dieser Zielgruppen werden bereits mit bestehenden Produkten gelöst und welche nicht? • Wie groß ist die Zahlungsbereitschaft bei den Zielgruppen für Lösungen zu diesen Problemen? Die Beantwortung dieser ersten Research-Fragen ist oft über einen einfachen Desk-Research innerhalb weniger Tage oder 1–2 Wochen möglich. Stellt man hier ­ bereits fest, dass der Markt zu klein ist, alle vorhandenen Probleme bereits zur vollsten Zufriedenheit der Zielgruppe gelöst werden, keine Zahlungsbereitschaft besteht oder die Zielgruppe gar nicht erreichbar ist, sollte man die Ausrichtung des Validierungsprojekts überdenken oder es nach der Research-Phase beenden. Ziel ist es, am Ende dieses ersten Research-Teils eine Einschätzung über das Marktpotential machen zu können und zu wissen, mit wem man im nächsten Research-Teil sprechen möchte, wo man die Zielgruppe finden und wie man sie erreichen kann.

4.2.3 Qualitativer Research – Was sagt die Zielgruppe? Es fällt schwer, das eigene Vorwissen und die Annahmen zu einem Thema in den Hintergrund zu stellen, vor allem wenn man selbst Teil der Zielgruppe sein könnte. Qualitativer Research ist der beste Weg, um näher an die echte Zielgruppe heranzukommen, die wirklich dahinterliegenden Probleme kennenzulernen und bei der Entwicklung neuer Produktideen userzentriert zu arbeiten. Am ergiebigsten sind meiner Erfahrung nach

70

A. Wicher

1:1 Interviews mit einer Länge von 30 bis 60 min und einem offenen Leitfaden zur User Journey2. Das wichtigste Tool hierbei ist die Erstellung eines offenen Leitfadens, der im Interview entlang der zu klärenden Hypothesen eine Orientierung bietet, und es vor allem ermöglicht, die Interviews schlussendlich vergleichend auszuwerten. Aus den Interviews lassen sich wertvolle Erkenntnisse (Customer Insights) erarbeiten, indem die Ergebnisse jedes einzelnen Interviews ausgewertet und aufs Wesentliche heruntergebrochen werden. Über die Interviews zeigen sich meist musterhaft wiederkehrende Aussagen, die helfen, das untersuchte Problem bzw. die bislang genutzten Lösungen besser zu verstehen. Die Informationen werden dabei oft nur implizit von den Interviewten erwähnt. Das heißt, eine gewisse Vorerfahrung in der Interviewführung und -auswertung sollte im Team vorhanden sein. Was wir im Detail von der Zielgruppe wissen möchten, sollte sich aus den zuvor aufgestellten Hypothesen, wie auch den Ergebnissen der Marktrecherche ergeben. Im Kern sind immer wieder folgende Bereiche für die Abfrage in den Interviews zentral bzw. sollten bereits als Annahmen in den Hypothesen auftauchen: • Einstellungen, Erfahrungen und Bedürfnisse rund um das Projekt-Thema • Verhalten entlang der bestehenden User Journey rund um den Problembereich Versucht man also etwa in dem Beispiel der Achtsamkeitsanwendung, die User Journey einer Person zu verstehen, die sich ihre Momente der Achtsamkeit über Yogastunden nach der Arbeit verschafft, könnten in ihren Erzählungen zu ihrem Alltag Hinweise versteckt sein, was ihr dabei vielleicht noch fehlt oder welches Problem für sie noch nicht gelöst ist. Das Ergebnis einer übergreifenden Auswertung der einzelnen User-Interviews ist oft die Erstellung von Personas. Damit ist gemeint, die Nutzer nach ihren Merkmalen in Gruppen aufzuteilen und den bzw. die „typischen“ Nutzer zu beschreiben. Solche Personas können dabei helfen, die Ausgestaltung des MVPs auf seine Zielgruppe zu verbessern und die Zielgruppe für das Produktteam greifbarer zu machen. Auf der Suche nach einer Daumenregel, mit wie vielen Usern man sprechen sollte, habe ich die Erfahrung gemacht, dass pro Personengruppe mit größtenteils übereinstimmenden Merkmalen (Teilzielgruppe, die sich als Persona darstellen lässt) meist sieben Personen ausreichend sind, um die wichtigsten Erkenntnisse herauszuarbeiten. Mehr Interviews bringen oft nur Wiederholungen von Inhalten, die bereits bekannt sind. Oft lassen sich jedoch erst während der ersten Interviews Teilzielgruppen genauer

2Bei

der User Journey geht es darum, den bisherigen Problem-/Lösungsweg eines Nutzers nachzuvollziehen. Dabei ist es wichtig, die einzelnen Schritte im Detail zu verstehen, um daraus Hinweise für eine sinnvolle Produktlösung abzuleiten.

4  Validierung von Produktideen am Markt

71

definieren – dementsprechend flexibel sollte man sein, die Anzahl an Interviews eventuell zu ergänzen. Es kann sein, dass zu Beginn des qualitativen Researchs aus den Ergebnissen der ersten Marktrecherchen schon Ideen entwickelt werden können, in welche Richtung eine Produktidee gehen könnte. Möchte man schon zum Ende der User-Interviews diese ersten Ideen mit den Nutzern besprechen, kann es hilfreich sein, sie in einem kurzen Design Sprint zu Papier-Prototypen oder ähnlich schnell erzeugbaren Minimum Viable Products (MVPs) auszuarbeiten – so lassen sich auch in dieser frühen Phase schon schnell und einfach erste Erkenntnisse zu eigentlichen Ideen gewinnen. Weitere hilfreiche Tools in dieser Phase der Auswertung neben der „Persona-­ Entwicklung“, und der „User Journey“ sind auch z. B. das Erstellen eines „Problemstatements“ oder das Herausarbeiten von „Jobs to be done“ sowie der „Pains und Gains“ (beispielsweise über die Vorlagen aus dem Value Proposition Canvas). Alle Tools dienen dazu, die Zielgruppe besser zu verstehen und ihre Bedürfnisse und zu lösenden Probleme für die Entwicklung des MVPs greifbar zu machen. Beschreibungen dieser Tools und wie sie anzuwenden sind, finden sich beispielsweise in den Strategyzer-Büchern „Value Proposition Design“ (Osterwalder et al. 2015), „Business Model Generation“ (Osterwalder und Pigneur 2010) und „Testing Business Ideas“ (Bland und Osterwalder 2020).

4.2.4 Quantitative Validierung – Wie viele gibt es davon? Mit den aus den qualitativen Interviews entwickelten Personas in der Hand gilt es nun herauszufinden, wie groß die Zielgruppe am Markt ist. Wir wollen dabei zum einen wissen, ob die über die Interviews entwickelten Personas in dieser Form am Markt überhaupt existieren und zum anderen, wie groß diese Zielgruppe ist. Das quantitative Validieren der qualitativen Ergebnisse hilft, gewonnene Insights bis zu einem bestimmen Grad verallgemeinern zu können und vor allem ein Gefühl dafür zu bekommen, wie viel wirtschaftliches Potential die Zielgruppe wirklich mitbringt. Beim Aufsetzen einer quantitativen Umfrage sind verschiedene Aspekte besonders wichtig zu beachten: Kann ich meine Umfrage über ein für die gesuchte Zielgruppe repräsentatives Marktforschungspanel ausspielen? Kann ich in der mir zur Verfügung stehenden Zeit eine Stichprobengröße erreichen, die ausreicht, um repräsentativ für die Zielgruppe zu sein? Kann ich die Fragen, die ich habe, so kurzfassen, dass die Umfrage nicht durch eine zu hohe Abbruchquote bei den Teilnehmern verzerrt wird? Kann ich meine Personas trennscharf genug voneinander betrachten? Sollte ich die Umfrage selbst ausspielen, oder einen Panel-Anbieter bzw. Dienstleister für quantitativen Research nutzen: Bekomme ich alle notwendigen Informationen, um Rückschlüsse auf den Gesamtmarkt vornehmen zu können (Etwa: Wie viele Nutzer konnten durch eventuelle Filterfragen zu Beginn – um eben nur die gesuchte Zielgruppe anzusprechen – nicht an der Umfrage teilnehmen?)?

72

A. Wicher

Mit diesen Fragen sollte man sich intensiv beschäftigen, um zu verhindern, dass die quantitative Analyse nicht nur eine weitere schöne Statistik hervorbringt, von der man nicht genau weiß, was sie einem wirklich bringt, sondern einen echten Mehrwert bietet und valide Erkenntnisse produziert. Außerdem lohnt sich nach dem qualitativen Research auch immer die Frage zu stellen, ob einen eine Quantifizierung der Ergebnisse wirklich weiterbringt, bzw. ob die Ergebnisse den weiteren Weg des Projektes verändern können. Für manche Projekte ist eine Quantifizierung auch nicht nötig, bzw. nicht hilfreich.

4.2.5 MVP-Definition und Ressourcenbedarf – Was brauchen wir zum Testen? Bisher gab es noch keinen expliziten Part, der beschreibt, wie aus dem Research tatsächlich eine neue Produktidee wird. Das hängt ein bisschen damit zusammen, dass es nicht wirklich einen festgelegten Zeitpunkt gibt, an dem das am sinnvollsten passiert. Aus jedem Teil der Research-Phase können sich Ideen für Produkte ergeben, die eventuell entdeckte Probleme lösen. Vielleicht gab es ja beispielsweise direkt zu Beginn des Projektes schon eine Idee, die wir erst einmal zurückgestellt haben, und wir haben im Zuge der Interviews festgestellt haben, dass diese Idee tatsächlich existierende Probleme löst und eventuell genau für diese Problemlösung eine Zahlungsbereitschaft besteht. Im Grunde geht es immer darum, so viel Aufwand in die kundenzentrierte Ideenausgestaltung zu stecken, dass man am Ende „beweisen“ kann, dass eine Idee, die man hatte oder die vielleicht neu entstanden ist, nicht nur in den eigenen Augen nach einer guten Idee aussieht, sondern der Markt bzw. echte User die Idee ebenfalls spannend finden und es Hinweise für eine Zahlungsbereitschaft gibt. Das angestrebte Ergebnis der Research-Phase ist es, eine klare Vorstellung davon zu erhalten, wie das spätere Produkt aussehen könnte, was es für einen USP (Unique Selling Proposition, also das Alleinstellungsmerkmal) hat sowie ob und warum Menschen dafür Geld ausgeben würden. Die Frage nach dem Geschäftsmodell (Business Case) lässt sich beispielsweise sehr gut über das Business Modell Canvas (zu finden im Buch „Business Model Generation“ von Osterwalder und Pigneur (2010) – online gibt es aber auch zahlreiche Vorlagen) abbilden, da man hier auch schnell sieht, welches die relevanten Einflussfaktoren für ein funktionierendes Geschäftsmodell sind, siehe Abb. 4.2. Dieses Wissen wiederum ist für den nächsten Schritt enorm wichtig: Wir definieren so detailliert wie möglich, welche KPI wir benötigen, um den Erfolg der Produktidee zu messen. Haben wir das getan, können wir feststellen, was das MVP zur Produktidee mindestens enthalten muss, damit wir auch genau diese KPI messen können. Im Detail heißt das, dass wir bei der Entwicklung der Produktidee sicherlich viele Eigenschaften im Kopf haben, die es zu einem tollen Produkt machen. Das MVP kommt aber meist mit einem viel kleineren Umfang an Eigenschaften (Feature-Set) aus, weil

4  Validierung von Produktideen am Markt

Key Partners

Key Key Acvies Acvies

Key Resources

Cost Structure

73

Value Proposion

Customer Customer Relaonships Relaonships

Customer Customer Segments Segments

Channels

Revenue Streams

Abb. 4.2   Business Model Canvas. (Quelle: In Anlehnung an Osterwalder und Pigneur 2010)

sich damit schon die relevanten Fragen beantworten lassen, die in der Validierung gestellt werden, um am Ende einen Business Case zu berechnen. Bei der Ausgestaltung des MVP muss immer abgewogen werden, was wirklich essentiell wichtig ist, um sinnvoll testen zu können und wie viel Aufwand dahintersteckt. Die Devise sollte immer sein, wirklich nur den minimal notwendigen Funktionsumfang zu bauen. Man sollte sich also nicht dazu verleiten lassen, das „perfekte Produkt“ zu bauen, wenn sich die Grundfrage vielleicht auch nur mit fünf Features ermitteln ließe. Bei der Entscheidung, wie viel Zeit und Geld man in die Erstellung des MVPs investiert, gilt es am Ende des Tages immer mehrere Aspekte abzuwägen: • Der strategische Aspekt: Auf welchem Weg kann man am nachhaltigsten auch in der Zukunft Innovationsprojekte finanzieren? (Bzw. anders gefragt: Wie wird mir das Scheitern eines Projektes am ehesten verziehen und darf ich die nächste Idee testen?) • Der operative Aspekt: Wie wird ein MVP in der Entwicklung bei Erfolg des Projektes am besten zum finalen „echten“ Produkt? Im Grunde stecken hinter beiden Aspekten die gleiche Frage und das gleiche Dilemma. Wenn ich das MVP als echtes MVP aufsetze (günstig und schnell umgesetzt in der Entwicklung, aber vermutlich mit vielen technischen Schulden, d. h. nicht skalierbar oder nachhaltig aufgesetzt in der Technik) werde ich die Tests für kleines Geld machen können und viele Projekte mit einem geringen Innovationsbudget umsetzen können. Für alle Projekte, die Erfolg haben, heißt das aber in den meisten Fällen, dass die technische

74

A. Wicher

Umsetzung zur Weiterführung des Produktes neu gemacht werden muss – was dann im Nachgang Zeit und Geld kostet. Ist es also besser Projekte günstig und schnell aufzusetzen und das eine, was erfolgreich ist, nach der Testphase neu zu bauen? Oder bräuchte der Neubau potentiell so lange, dass ich eine Marktchance verpasst habe, die für den Erfolg des Produktes entscheidend ist? Sich diese Fragen zu stellen und zu versuchen, sie bestmöglich mit allen Involvierten zu beantworten, führt vielfach zu besseren Entscheidungen. Auf jeden Fall führt es zu informierteren Entscheidungen. Hat man festgelegt, wie viel Zeit und Geld für das MVP investiert werden soll und kann, lässt sich das Feature-Set daraus und aus den ­Research-Ergebnissen ableiten und die MVP-Definition steht. Aus der MVP-Definition ergibt sich schließlich, welches Team für die nächste Phase benötigt wird: Geht es etwa um eine Landingpage, die das Produkt nur erklärt, reichen vermutlich ein Designer und ein Entwickler. Wollen wir im MVP aber bereits ein weitgehend fertiges Produkt verkaufen, brauchen wir sicherlich noch weitere Ressourcen: Geht es in dem Achtsamkeitsbeispiel inhaltlich etwa um audiogeführte Meditationen, die angeboten werden sollen, brauchen wir für den Content mindestens einen Achtsamkeitsund Meditationsexperten, einen charismatischen Sprecher und einen Audio-Konzepter. Alle benötigten Ressourcen rasch zur Verfügung zu haben, ist hier oft entscheidend und im Aufwand nicht zu unterschätzen.

4.2.6 Design vs. Technik – Worauf liegt der Fokus bei der ­­MVPErstellung? Nach meiner Erfahrung ist Product Design in Innovationsprojekten oft wichtiger als ein „sauberes“, nachhaltiges Engineering (Programmierung der Software). Für die Berechnung des Business Models brauche ich natürlich am Ende eine gute Vorstellung, was ein skalierbares Setup mit einer guten technischen Aufsetzung kostet. Das lässt sich jedoch meist auch ganz gut auf der Basis eines technisch weniger detaillierten MVP abschätzen. Die Optik, bzw. Funktionalität, die die Testpersonen sehen, muss jedoch gut sein, da Testergebnisse sonst keine Aussagen über das Produkt erlauben, für welches das MVP gebaut wurde. Man kann sich nach meiner Erfahrung immer gut an dem Spruch „vorne hui hinten pfui“ orientieren. So lassen sich gute Testergebnisse erzielen, ohne dass der technische Aufwand den Rahmen sprengt. Außerdem konzentriert man sich in der Testphase so wirklich darauf, nur das zu bauen, was man für den Test braucht und verbringt weniger Zeit damit, zu überlegen, wie man das Tech-Setup nachhaltig aufbaut und auf Skalierung vorbereitet. Das sind zwar immens wichtige Schritte, für ein MVP aber oft noch überflüssig. Hinzu kommt, dass man in der Testphase viel darüber lernt, was in der Produktentwicklung für dieses Produkt funktioniert und was nicht. Im Ergebnis wird das Produkt, das man mit all diesem Wissen neu baut, deutlich besser aufgesetzt sein, als man es beim ersten Mal – ohne das neue Wissen – getan hätte.

4  Validierung von Produktideen am Markt

75

4.3 Prototyping – Was bauen wir jetzt? Wir haben inzwischen eine gute Vorstellung davon, was das Produkt ausmacht, das wir testen wollen. Außerdem haben wir definiert, wie das MVP dafür aussehen soll, welches wir jetzt umsetzen wollen. Prototyping kann sehr unterschiedliche Formen und Ausmaße haben. Von simplen Low-Fidelity Prototypen (z. B. Papier-Prototypen, Wireframes, simple Landingpages), die wir eventuell in der Research-Phase schon angewendet haben, bis hin zu detailliert ausgearbeiteten Varianten, wie etwa Clickdummy Mockups oder MVPs, in denen nur ein aufwendiger technischer Part simuliert wird, bis hin zu programmierten Produkten mit Frontend und Backend. Beispiele für Low-Fidelity Prototypen

Papier-Protoyp: Papier-Prototypen werden gezeichnete Varianten (Skizzen) des Produkts bezeichnet. Diese werden von Hand auf Papier angefertigt. Ziel dieser einfachen Technik ist es, erste Ideen und Produkt-Überlegungen schnell und einfach am Nutzer zu spiegeln. Im Testing am Nutzer braucht es einen „Facilitator“, das heißt jemanden der die interaktiven Elemente simuliert (etwa umblättern auf ein neues Blatt Papier, wo ein „Klick“ erfolgt oder das Sprechen von Ansagen). Wireframe: Wireframes sind eine Art Blueprint für ein Produkt und zeigen, meist in schwarz weiß und ohne Design, den Aufbau eines Produktes. Das Ziel von Wireframes ist es meist, Funktionsweisen und UX zu zeigen. Wireframes eignen sich selten, um sie an unerfahrenen Nutzern zu testen, da sie oft nicht „schön“ aussehen und sich die meisten Nutzer an der (fehlenden) Gestaltung aufhalten, anstatt die Funktionalität zu bewerten. Einfache Landingpage: Einfache Landingpages oder Vorbestell-Seiten, sind einzelne Websites, die es ermöglichen, Vorabaussagen über ein Produkt zu treffen, was es so noch nicht gibt. Im Gegensatz zu den ersten beiden Low-Fidelity Prototypen, kann man hier recht einfach nicht nur qualitative, sondern auch quantitative Tests machen. In der Regel zeigen die Landingpages eine Vorschau für ein Produkt und ermöglichen es zu Interagieren, um Interesse und Zahlungsbereitschaft zu testen, etwa indem eine E ­ -Mail-Adresse eingetragen werden kann, wenn man zum Start des Produktes Informiert werden möchte, eine Vorbestellung durchgeführt werden kann oder auch einen ­Fake-Kauf-Prozess gestartet werden kann. ◄

76

A. Wicher Beispiele für High-Fidelity Prototypen:

Klickdummy Mockup: Ein Mockup ist das fertig designte Produkt, das aber eben nur aus Designs besteht, die noch nicht technisch umgesetzt sind. Im Gegensatz zum Wireframe sieht das Produkt jetzt „schön“ aus. Mithilfe von Tools wie z. B. proto.io können solche Mockups zu Klickdummies zusammengestellt werden, sodass es visuell und von den Interaktionsmöglichkeiten (Klicks) nicht vom eigentlichen Produkt zu unterscheiden ist. Es handelt sich um eine Nachbildung des fertigen Produktes. Es können Funktionen, Inhalte und Design mit Nutzern getestet werden, noch bevor technischer Aufwand in der Frontend-Entwicklung entstanden ist. MVP mit simulierter Technik: Solche MVPs werden auch als Wizard of Oz MVPs bezeichnet. Im Gegensatz zum Mockup und Klickdummy ist hier das Frontend meist schon programmiert, nicht aber die Funktionalität im Backend. Logiken und Abläufe, die später technisch automatisiert ablaufen, werden hier manuell nachgestellt. MVP mit programmierter Technik: Programmierte Prototypen sind dem fertigen Produkt, das getestet werden soll am ähnlichsten. Sie beinhalten die im Testplan definierten Kern-Features, die für die Validierung des Produktes benötigt werden und sind sowohl was UX und UI betrifft, als auch was Funktionalität, Backend und Tracking betrifft, programmiert. ◄ Wie weit wir gehen müssen, das heißt mit welcher Art des Prototyps getestet werden kann, hängt vom Testplan ab. Das Ergebnis dieser Phase ist ein am Markt testbarer Prototyp, mit dem alle Fragen beantwortet werden können, die für die Berechnung des Businessplans beantwortet sein müssen.

4.3.1 Testplan & Feature-Definition – Was wollen wir wissen und was brauchen wir dafür? Zwar haben wir inzwischen eine gute Vorstellung von dem Produkt, das wir testen wollen. Für die Feature-Definition vom MVP ist jedoch primär entscheidend, welche KPI wir am Ende benötigen, um einen Business Case zu rechnen und um beurteilen zu können, ob das Produkt, für das wir ein MVP bauen, Erfolg verspricht. Das heißt, bevor wir mit dem Prototyping wirklich loslegen, sollten wir einen Testplan aufstellen. Erst daraus ergibt sich unser Feature-Set. Hier steht nicht im Fokus, was aus User-Sicht oder gar unserer Sicht cool für das Produkt wäre – sondern was für die Tests benötigt wird. Mir hilft dabei immer, explizit zu unterscheiden zwischen dem Produkt, das wir testen möchten und dem MVP, das wir für den Test verwenden.

4  Validierung von Produktideen am Markt

77

Was beinhaltet ein Testplan? Im Grunde haben wir uns das schon im Groben angeschaut, als es darum ging, Hypothesen zu formulieren. Diese Hypothesen gilt es jetzt wieder hervorzuholen und für die entstandene Produktidee zu schärfen. Um einen besseren Überblick zu behalten, bietet es sich dabei oft an, die Hypothesen in Bereiche entlang der User Journey, die in optimaler Weise zu unserem Produkt führt, aufzuteilen. Um das einmal an einem Beispiel zu erklären: Wir haben eine digitale Produktidee, die wir an Konsumenten verkaufen möchten. Wir wollen Paid Content verkaufen und bieten ihn als Abomodell an (wie zum Beispiel Netflix oder Spotify). Mit einem solchen Geschäftsmodell werden insbesondere folgende Fragen für das Testing wichtig: a) Kundenakquise & Target Group: Wie kommen welche User zu uns und was kostet uns das? b) Positionierung & Branding: In welchem Kontext funktioniert das Produkt für die User und wird es genutzt? c) Content, USP & Wert: Für welche Inhalte und in welcher Form sind die Nutzer zahlungsbereit? d) Monetarisierung & Payment: Wie bezahlen die Nutzer? Was ist ihnen dabei wichtig? Wie sieht das Geschäftsmodell aus und wie teuer kann das Produkt sein? e) Aktivität, Retention & Customer Development: Bleiben die Nutzer längere Zeit dabei? Was sind die Gründe dafür und was müssen wir dafür tun? Zu jedem Bereich haben wir entweder aus der Research-Phase schon Hypothesen gebildet oder entwickeln sie jetzt auf der Grundlage des User Researchs und mit Blick auf die Produktidee. Oft ist es hilfreich, zu jeder Hypothese die User-Statements und die daraus generierten Insights, auf denen die Hypothesen basieren, aufzuschreiben, um sich den User Research nochmal vor Augen zu führen. Zu jeder Hypothese gilt es dann im nächsten Schritt drei Dinge festzulegen: 1. KPIs: Welche KPIs müssen wir messen, um diese Hypothese bestätigen oder widerlegen zu können? 2. Testszenario: Wie sieht das Testszenario aus, mit dem wir an diese Zahlen kommen? 3. Breaking Point: Welche Werte müssen die KPIs mindestens annehmen, damit wir den Test als Erfolg werten und die Hypothese als bestätigt/widerlegt ansehen können bzw. sich unser Business Case rechnet? 4. Im folgenden Beispiel ist erklärt, wie eine Hypothese in zwei Bereichen (ich habe hier beispielhaft Bereich A und D gewählt) aussehen könnte, wenn Netflix die zu testende Produktidee wäre.3 In der Regel hat man dabei anders als im Beispiel nicht nur eine Hypothese pro Bereich, sondern eine Vielzahl. 3Disclaimer:

Die Zahlen in dem hier beschriebenen Beispiel basieren auf keinerlei Recherche oder Businessplan-Berechnungen (wie es in einem Projekt sein sollte, das gerade aus der ResearchPhase kommt), sondern wurden zur Veranschaulichung willkürlich ausgewählt.

78

A. Wicher Kundenakquise & Target Group – Wie kommen welche User zu uns und was kostet uns das?

Hypothese 1: User lassen sich eher beim Lesen von E-Mails ablenken und in audiovisuelle Geschichten hineinziehen als beim Vorbeigehen an einer Litfaßsäule. 1. KPIs: Klickraten (berechnet aus Views und Klicks), Cost per Click (CPC), ­Watch-Time 2. Testszenario: Display-Anzeigen bei diversen E-Mail-Anbietern schalten. Plakatwerbung auf Litfaßsäulen jeweils mit Rabatt-Code zum Tracken buchen sowie eine Kamera bei der Litfaßsäule installieren, um die View-Zahl auszuwerten. 3. Breaking Point: Genereller Erfolg der Maßnahmen: Klickraten von View zu Nutzung ab 15 % sei ein Erfolg. CPC max. 3 €, Watch Time > 5 min. Unterschiede zwischen den beiden Maßnahmen sind mit Signifikanztest auszuwerten. Welche benötigten Features für das MVP ergeben sich daraus? Verschiedene Anzeigenformate für Display und Plakatwerbung, Landingpage mit ein paar Inhalten, die per Rabatt-Code freigeschaltet werden können, Tracking von Traffic-Kosten, Views, Klicks und Userverhalten auf der Landingpage. Monetarisierung & Payment – Wie bezahlen die Nutzer? Was ist ihnen dabei wichtig? Wie sieht das Geschäftsmodell aus und wie teuer kann das Produkt sein? Hypothese 2: Die Kauf-Conversion ist besser, wenn verschiedene Zahlungsmethoden zur Auswahl stehen. 1. KPI: Kauf-Conversion (berechnet aus Traffic auf der Landingpage und Anzahl an Kaufabschlüssen). 2. Testszenario: Checkout-Page mit verschiedenen Zahlungsmöglichkeiten im ­A/B-Test im Vergleich zu einer Checkout-Page, die nur die gängigste und für den User einfachste oder für uns günstigste Zahlungsmethode beinhaltet. Eventuell ist ein Vorab-Test mithilfe der Checkout-Page, die verschiedene Optionen bereitstellt, nötig, um herauszufinden, welche Zahlungsmethode von den Nutzern bevorzugt ausgewählt wird. 3. Breaking Point: Genereller Erfolg wird bei einer Kauf-Conversion von mehr als 3 % gesehen. Unterschiede des A/B-Tests sind mit Signifikanztest auszuwerten. Welche benötigten Features für das MVP ergeben sich daraus? Checkout-Strecke auf der Landingpage mit einer Auswahl diverser Zahlungsmöglichkeiten (ggf. ist es ausreichend, die Zahlungsmöglichkeit zu simulieren, also keine echten Zahlungsanbieter anzubinden), A/B-Testing-Möglichkeiten sowie Tracking von allen für die Berechnung der Kauf-Conversion benötigten Werte. ◄

4  Validierung von Produktideen am Markt

79

Oft gilt es nach der Erstellung des idealen Testplanes und einer daraus resultierenden Feature-Liste noch einmal eine Reihenfolge der zu testenden Szenarien festzulegen und vor allem den Impact von Misserfolg einzelner Szenarien zu definieren. Um kosteneffizient zu arbeiten, kann es sich beispielsweise lohnen – sollte das möglich sein – erst einen Bereich zu testen und nicht alle definierten Features auf einmal umzusetzen. Stellt man beispielsweise fest, dass man keinen funktionierenden Weg findet, Nutzer auf das Produkt aufmerksam zu machen, sollte man zunächst eine erfolgsversprechende Lösung für die Traffic-Akquise finden, bevor man Features baut, mit denen die Kauf-Conversion überprüft werden kann. In jedem Fall gilt, dass das wichtigste Feature in jedem MVP das entsprechende KPI-Tracking ist. Kein Feature für den User bringt irgendetwas, wenn sich die im ­ Zusammenhang stehenden KPIs nicht tracken lassen. Daher ist es wichtig und sinnvoll, Tracking aller benötigten KPIs immer als Feature des MVPs aufzuführen und von Beginn an ins Backlog für die technische Umsetzung aufzunehmen. Sonst wird es vergessen, in der Kosten- und Zeitschätzung nicht berücksichtigt und fällt einem auf die Füße, kurz bevor man mit den Tests beginnen möchte.

4.3.2 UX und UI – Wie soll das MVP aussehen? Mit der fertigen Feature-Liste in der Hand sollten wir uns als nächstes überlegen, wie die UX und UI des MVPs aussehen wird. Das ist die Grundlage, um genauer sagen zu können, was und wie lange wir für die Entwicklung des MVP brauchen. Das heißt, wir brauchen ein Design. Der Project Lead sollte hier eng mit dem Designer zusammenarbeiten und alle bisherigen Insights zur Verfügung stellen. Das heißt, das Briefing für den oder die Designerin sollte zum einen enthalten, was die Produktidee ist und wie diese entstanden ist. Das bedeutet, dass alles, was bisher im Research gelernt wurde, verständlich aufbereitet und geteilt werden muss. Zum anderen muss ganz deutlich werden, was im Gegensatz zum Endprodukt für das MVP geplant ist und warum. Das heißt, dass der Testplan und die daraus entstandene Feature-Liste mit dem Designer oder der Designerin durchgegangen werden sollte, sodass er oder sie ebenso im Bilde ist, wie das Produktmanagement selbst: Wo soll das Projekt hinführen und was ist das Ziel der Validierung? Es empfiehlt sich, die Entwicklung von UX und UI wirklich explizit von der schlussendlichen Programmierung zu trennen, da man mit ersten Clickdummys auf der Basis der Designs (zum Beispiel mithilfe von Tools wie proto.io) schon ins Testing gehen kann, ohne dass man Entwicklungskosten hat. Beispiel

Das lässt sich an einem Beispiel verdeutlichen: Innovationsprojekte können auch in Form von Research & Development-Projekten umgesetzt werden. Im Unterschied zu einem Produktinnovationsprojekt heißt das, dass es eigentlich kein Nutzerproblem gibt,

80

A. Wicher

zu dem wir Ideen haben, wie wir es lösen können. Vielmehr gibt es eine neue Technologie, die uns vielversprechend erscheint und die wir gerne ausprobieren und auf ihr Potential als Basis für neue Geschäftsmodelle testen möchten. Konkretes Beispiel: Die Chatbot-Technologie ist gerade auf dem Markt aufgetaucht und ein Publisher stellt sich die Frage, ob das ein Kanal ist, der für digitalen Content relevant werden könnte. Bei solchen Projekten mit neuen Technologien lohnt es sich besonders, für die ersten Tests auf unvollständige Zwischenlösungen zu setzen, die vielleicht sogar nur simulieren, was die neue Technologie an spannenden Features mit sich bringt. Im genannten Beispiel sah das Testszenario wie folgt aus: Für einen Use-Case, der im ersten Test validiert werden soll, wird ein erster Entwurf für das Conversational Design (Design, in dem ein Sprachverlauf zwischen Nutzer und Produkt entworfen wird anstatt visueller Komponenten) und die UX gemacht. Im Anschluss klemmen sich Teammitglieder eine Woche hinter Rechner und Chat und simulieren mithilfe eines Entscheidungsbaums auf Basis des Conversational Designs sowie vorgefertigten Antworten den Chatbot. Damit der „Bot“ schnell genug antworten kann, ist es in der Testphase notwendig, dass immer ein Teammitglied ohne Verzögerung antworten kann; Toilettengänge werden also abwechselnd gemacht. So ließen sich mit einem geringen technischen Aufwand innerhalb von einer Woche unzählige Insights generieren, die die darauffolgende technische Umsetzung des Chatbots massiv beeinflusst haben. Anhand des User-Verhaltens ließ sich schnell das Conversational Design iterieren und verbessern. Es wurde deutlich, dass einige Features dabei gar nicht benötigt wurden. Andere wiederum fehlten, die einen großen Einfluss auf die Aktivitätsrate der User hatten. Zusätzlich konnten erste Ideen generiert werden, wie sich mit dem Chatbot Geld verdienen lässt. Diese Ideen konnten dann im nachfolgenden, technisch umgesetzten Prototyp getestet werden. ◄

4.3.3 Entwicklung – Wie und mit welcher Technologie wird das MVP umgesetzt? UX- und UI-Anforderungen, Überlegungen zum Tracking aber auch verfügbare ­Entwickler-Ressourcen sollten Basis für die Auswahl der Technologie sein, mit der der Prototyp umgesetzt wird. Auf das Wie der technischen Umsetzung und Delivery des Produktes werde ich hier nicht im Detail eingehen, da es in diesem Buch dazu andere Beiträge gibt (zum Beispiel Kap. 7 von Tim Adler). Im Kern unterscheidet sich die Delivery eines MVPs nicht von der Delivery jedes anderen Produktes. Möglicherweise fällt der Umfang (Scope) eines MVPs etwas kleiner aus und es sollte zusätzlich weniger Fokus auf Skalierungsvorplanung gesetzt werden, um den Aufwand und damit die Kosten gering zu halten. Außerdem bestimmt, wie oben ausführlich erläutert, nicht der reine User- oder Business-Need das Feature-Set, sondern primär der Testplan, und welche KPIs mit welchen Features getestet werden können.

4  Validierung von Produktideen am Markt

81

4.3.4 Team – Wer baut das? Gilt es, ein Innovationsprojekt mit einem Team umzusetzen, das ansonsten an Produkten arbeitet, die bereits live sind, ist das eine andere Herausforderung als den Großteil des Teams quasi auf der grünen Wiese zusammenzustellen, und es sich in dem Umfang nur für die Entwicklung dieses Prototyps zusammenfindet. Beides hat seine Vor- und Nachteile und bringt andere Herausforderungen mit sich. In dem Setting, in dem ich viele Innovationsprojekte begleitet habe, gab es bezüglich der technischen Umsetzung nur ein sehr kleines festes Team. Für uns hat es sich bewährt, auf jeden Fall die UX und UI fest im Team zu haben, da sie eigentlich in jedem Projekt benötigt werden und oft sehr kurzfristig neue Aufgaben in diesem Bereich entstehen, die schnell umgesetzt werden wollen. Zumal UX und UI einen so elementaren Einfluss auf Nutzerverhalten, Conversion Rates und damit die Chance auf Erfolg des Produktes haben, dass hierauf immer ein starker Fokus liegen sollte. Je nach Umfang und technischen Anforderungen ist dann der Rest des Teams zusammenzustellen. Zieht man Teammitglieder dazu, die fest im Unternehmen angestellt sind und neben dem Innovationsprojekt im Zweifel noch andere Aufgaben haben, ist es enorm wichtig, dafür zu kämpfen, dass sie in dem Zeitraum, in dem das MVP umgesetzt werden soll, für das Projekt voll zur Verfügung stehen und von ihren eigentlichen Aufgaben vollständig abgezogen werden. Andernfalls kommt man schnell in Situationen, in denen Prioritäten nicht klar sind und man schlingert aus dem Zeitplan. In vielen Fällen bietet es sich daher an, Lücken im Team über Freelancer auszugleichen. Erstens ist man hier flexibler in der Technologiewahl und hat die Freiheit, mit dem Tech-Setup zu arbeiten, das für den angestrebten Prototyp am geeignetsten erscheint. Zweitens lassen sich so Ressourcen für einen sehr begrenzten Zeitraum aufbauen und die Zusammenstellung eines festen Teams, welches Fixkosten produziert, kann zu einem späteren Zeitpunkt erfolgen, zu dem die Idee bereits validiert ist. Auch hier gilt es natürlich abzuwägen: Möchte man nach erfolgreichem Abschluss des Validierungsprojektes das MVP zum finalen Produkt weiterentwickeln, geht das am besten mit demselben Team, mit dem das MVP umgesetzt wurde. Steht das Team dann jedoch nicht mehr in der Form zur Verfügung oder ist es durch die Freelancer-Gehälter für einen langfristigen Betrieb des Produktes zu teuer, ist es elementar, ein Team zu haben, das mit dem Tech-Setup ebenso umgehen kann wie das Validierungsteam. Am besten überlegt man sich das nicht erst, wenn das Validierungsprojekt abgeschlossen ist, denn dann ist es im Zweifel zu spät. Man sollte die Fortführung schon früh antizipieren und dafür planen. Ich gebe zu, dass ich mir damit ein bisschen selber widerspreche: Einerseits sollte die Projektorganisation schlank gehalten werden, sodass das Testing nicht zu teuer wird, und andererseits soll vorgeplant werden, damit auch eine Fortführung effizient gelingen kann. Ich glaube, es gibt hier keine perfekte Lösung – wichtig ist nur, sich darüber Gedanken

82

A. Wicher

zu machen und eine Idee zu haben, wie es funktionieren könnte, sodass man von der Fragestellung am Ende nicht überrascht wird.

4.3.5 Zeitabschätzung – Wie lange brauchen wir dafür? Mit einer Zeitabschätzung entsteht in der Regel auch gleich eine Kostenabschätzung. Es liegt auf der Hand, dass Dauer und Kosten völlig von dem definierten und gewünschten Feature-Set abhängen. Einfach gerechnet: Anzahl der Arbeitstage, die voraussichtlich pro Teammitglied benötigt werden, mal Tagessätze eines Teammitglieds mal Anzahl Teammitglieder. Als kleine Daumenregel lässt sich sagen: Wenn die Entwicklung länger als 3–4 Wochen dauern wird, ist das kein MVP mehr. Wenn noch gar nicht vorher getestet wurde, sollte man nach einem alternativen „Low-Fidelity-Prototyp“ suchen, mit dem man die aufgestellten Hypothesen schneller und günstiger ersten Tests unterziehen kann. Bei High-Fidelity-Prototypen kann das dann u. U. anders sein und die Entwicklung auch mal zwei Monate dauern. Zu dem Zeitpunkt sollte man aber schon einige Insights gesammelt haben, die für den Erfolg der Idee sprechen. Dann lohnt es sich eher, etwas mehr Aufwand in die Nachhaltigkeit, das heißt in die Weiterverwendbarkeit nach der Validierung, des Prototypen zu stecken. Einen solchen Prototypen zu bauen, sollte daher bereits eine sehr bewusste und informierte Entscheidung sein. Beispiel

Gehen wir einmal davon aus, dass sich im ersten Research und mit LowFidelity-Protoypen folgende Insights generieren ließen: • Für digitalen Audio-Content besteht eine Zahlungsbereitschaft, wenn der User das Gefühl hat, diese Meditationen nach dem Kauf zu besitzen, um sie immer wieder nutzen zu können. • Ein Abo-Modell für digitalen Audio-Content erscheint als Geschäftsmodell am erfolgversprechendsten. • Digitaler Content, der nicht als Download bereitgestellt wird, ist am besten über eine App zu verkaufen; da ein Nutzer bei Apps, die er auf sein Gerät herunterlädt, eher ein Eigentumsgefühl entwickelt als bei Content im Web mit Login und ­User-Bereich. • Die größere Zahlungsbereitschaft für digitalen Content und andere In-App-Käufe weisen IOS-Nutzer auf. ◄ Aus den Erkenntnissen des Beispiels folgt relativ klar, dass es sinnvoll ist, zunächst eine App für den IOS-Appstore von Apple zu entwickeln. Da Apple jedoch keine ­Beta-Versionen mit unfertigen Inhalten im Appstore zulässt, ist man hier gezwungen,

4  Validierung von Produktideen am Markt

83

einen Prototypen zu entwickeln, der schon sehr nah an das tatsächliche Produkt herankommt. Das in drei bis vier Wochen umzusetzen ist dann eher unrealistisch und man muss mehr Entwicklungszeit und damit auch ein höheres Budget für den Prototypen einplanen.

4.4 Testing – Wie kommen wir an die Zahlen? Natürlich sind viele Schritte der vorigen Phasen auch schon Teil des Testings. Wenn ich einen Papierprototypen im qualitativen Interview zeige, ist das Testing. Wenn ich in einem quantitativen Fragebogen am Ende eine Produktidee vorstelle und Usern anbiete, ihre E-Mail-Adresse einzutragen, wenn sie zum Launch des Produktes informiert werden möchten, ist das auch Testing. Wenn ich ein Design-Mockup mache, mit einem Clickdummy durch die Straßen laufe und ihn Menschen in die Hand drücke, um zu erfahren wie sie damit umgehen, ist das ebenfalls Testing. In jedem Schritt, der mich bis zu dem Punkt gebracht hat, bei dem ich einen Testplan und ein marktreifes MVP in den Händen halte, sollte getestet worden sein. In diesem Kapitel geht es daher im Besonderen um das Testen von digitalen, programmierten Prototypen, die zur Validierung an den Markt gebracht werden wie ein neues, „fertiges“ Produkt.

4.4.1 Launch- & Marketing-Plan – Wer testet das MVP? Im Research wurde sich damit beschäftigt, wer die Zielgruppe für das MVP ist, und herausgefunden, wie diese Zielgruppe für Gespräche zu erreichen ist. Dieses Wissen wird jetzt wieder benötigt, um den Prototypen an den Markt zu bringen und Traffic in einer Menge zu produzieren, die die nötigen Testzahlen liefern kann. Zu diesem Zeitpunkt ist es dann meist auch spannend und sinnvoll, hierbei nicht ausschließlich auf die Zielgruppe zu gehen, sondern breiter anzusetzen, um so die Möglichkeit zu haben, die Hypothese, welche Zielgruppe sich für dieses Produkt interessiert, am Markt zu überprüfen. Im Kern eignen sich für die Traffic-Akquise auf eine Website bzw. in eine App zunächst alle bekannten Online-Marketing-Methoden bzw. das Ausliefern des MVPs über eigene vorhandene digitale Kanäle, also z. B. ein Hinweis auf der eigenen Website. Dadurch lassen sich die benötigten KPIs tracken, die im Testplan stehen. Bei der Erstellung des Launch- und Marketing-Plans ist es für das Testing wichtig, sich die gewählten Kanäle vorab anzuschauen, eine Prognose zu treffen, wie viel Traffic darüber erwartet wird und zu berechnen, ob das ausreichen kann, um signifikante Ergebnisse zu erzielen. So weiß man vorab, wie viel Budget voraussichtlich benötigt wird und wie viel Zeit man brauchen wird, um genügend Besucher- bzw. Conversionzahlen zu generieren. Sollten die Schätzungen nicht passen, kann man ggf. den Testplan justieren, um sicherzustellen, dass sich im Zeit- und Budgetrahmen aussagekräftige Testergebnisse zeigen werden.

84

A. Wicher

4.4.2 Pivot – Alles noch mal neu? Die ersten zwei Wochen Testing sind abgeschlossen, die Ergebnisse liegen vor und wir stellen fest, dass es alles ganz anders gekommen ist als wir dachten. Was dann? Projekt wegwerfen und neu machen? Anpassen und noch einmal versuchen? Gelerntes verarbeiten und das Projekt beenden? Alles valide Optionen zwischen denen je nach Ergebnis abgewogen werden muss. Wenn nach der ersten Testrunde die Ergebnisse nicht dem entsprechen, was wir in den Hypothesen angenommen haben, ist das meistens der Punkt, an dem ein Projekt länger dauert als geplant. Denn die Planung von Research, Prototyping und Testing beinhaltet nach meiner Erfahrung eigentlich nie einen Plan für einen größeren Pivot (ein Umschwenken in der Idee, im Geschäftsmodell, in der Zielgruppe oder Ähnliches). Passieren tut das allerdings in acht von zehn Fällen. Man sollte also doch versuchen, damit zu kalkulieren – zumindest aber Stakeholder zu Beginn des Projektes darauf aufmerksam machen, dass das passieren könnte und was es für die Zeit und damit das Budget eines Projektes bedeuten könnte. Tritt dann der Fall in der Projektrealität ein, ist es das Wichtigste, keine uninformierten bzw. von einer Ideen- oder Produktliebe getriebenen Entscheidungen zu treffen, sondern auf die Zahlen zu schauen und zu identifizieren, in welche Richtung es sinnvoll weitergehen kann. Lassen sich in den Ergebnissen Indizien finden, die dafür sprechen, dass eine Anpassung des Produktes Erfolg versprechend ist, fängt man im Grunde wieder beim Testplan an. Der Testplan wird angepasst, eventuell neu benötigte Features werden definiert, das Team dafür wird an den Start gebracht, um das Ganze umzusetzen, und Testphase zwei wird gestartet. Ein anderer Fall, der in der Testphase häufig vorkommt, ist, dass wir mit dem getesteten Produkt doch nicht das beabsichtige Problem lösen, aber unterwegs ein anderes Problem finden, das sich lohnt zu lösen. Im Ergebnis kann damit eine neue Idee entstehen, die dann in eine Research-Phase übergehen könnte. Erzielt man allerdings Ergebnisse, die klarmachen, dass das Problem zum Beispiel nicht gravierend genug ist, als dass eine Lösung bei der Zielgruppe eine Zahlungsbereitschaft hervorruft oder man im Testing externe Faktoren entdeckt, die die Zahlen so verändern, dass das Geschäftsmodell sich nicht rentieren wird, sollte man auch keine Scheu haben, das Projekt zu beenden. Wichtig ist in dem Fall aber, das Gelernte mit den Stakeholdern und anderen Interessenten offen zu teilen, um für die Zukunft daraus zu lernen. Wenn man zwei von zehn Projekten zum Erfolg führt, ist das aus meiner Erfahrung eine gute Quote, zumal in der Startup-Szene allgemein davon ausgegangen wird, dass neun von zehn Startups scheitern.

4  Validierung von Produktideen am Markt

85

4.4.3 KPIs & Businessplan – Verdienen wir jetzt damit Geld? Und jetzt kramen wir das Wissen aus unserer letzten Statistik-Vorlesung heraus bzw. holen uns jemanden dazu, der sich mit Datenauswertung, -synthese und -interpretation auskennt. Im Grunde besteht die letzte Aufgabe nämlich darin, alle gesammelten Daten in den Testplan einzutragen, Ergebnisse daraus zu berechnen, um zu überprüfen, welche Hypothesen bestätigt oder widerlegt wurden. So zeigt sich, an welchen Stellen wir die Breaking-Points erreicht haben und falls nicht, zu überlegen, woran das gelegen hat. Gab es etwa zu Beginn des Projektes Annahmen, die sich nicht bestätigt haben? Hier wird auch noch einmal deutlich, warum man so viel Wert auf einen guten Testplan und eine Ableitung der MVP-Features aus dem Testplan und den benötigten KPIs legen sollte: Wenn ich erst an dieser Stelle im Projekt feststelle, dass mir eine Zahl für eine Berechnung fehlt, weil ich sie nicht getrackt habe, kann das Projekt im schlimmsten Fall zu keinem richtigen Ergebnis kommen. Wie kann man dem vorbeugen? Ich führe gerne die Berechnung, die ich eigentlich erst am Ende des Projektes machen werde, schon einmal zu Beginn durch, wenn ich meinen Testplan erstelle. Auf welcher Grundlage? Mit den Zahlen, die ich in der Breaking-Point-Liste habe. Das sind ja meine Annahmen, wie ein guter Wert aussehen sollte. Und wenn ich meinen Businessplan mit diesen Zahlen aufsetze, zeigt er hoffentlich, dass mit diesem Projekt Geld zu verdienen ist. Das hat auch den Vorteil, dass ich meine Breaking-Point-Annahmen nicht nur auf Marktwerte aus der Recherche stütze, sondern auch auf meine eigenen Business-Needs. Möglicherweise ist „da draußen“ eine Kaufrate von zwei Prozent etwas, was als gut oder als Durchschnitt bewertet wird, für meinen Business Case reicht es jedoch nicht aus, denn ich brauche eigentlich mindestens drei Prozent, damit die Rechnung aufgeht. Sich das schon zu Beginn klarzumachen, hat auch den Vorteil, dass man sehr schnell ein Gefühl dafür bekommt, an welchen Stellschrauben das Projekt deutlich besser performen muss als andere am Markt und an welchen man mehr Spielraum hat.

4.5 Und wie geht’s jetzt weiter? Wir haben das jetzt alles auf der grünen Wiese getestet: Es lief super, der Businessplan steht und zeigt Gewinne ab dem ersten Jahr. Und jetzt? Besonders im Corporate-Umfeld sollte man diese Frage auf keinen Fall jetzt erst stellen. Corporate Innovation hat oft damit zu kämpfen, dass neue Ideen bezüglich der Agilität und Anpassbarkeit von „echten“ Startup-Teams nicht mithalten können, da es am Ende doch an einem Konzern hängt, der Entscheidungsprozesse mit sich bringt, die das schnelle und userzentrierte Reagieren auf den Markt erschweren. Ein Innovationsprojekt, das auf der grünen Wiese entstanden ist und erfolgreich war, kann dann in der Fortführung an genau solchen Gründen doch noch scheitern, wenn diese nicht vorher bedacht wurden.

86

A. Wicher

Teil des Ergebnisses und der Empfehlung für solche Projekte sollte daher immer auch eine Einschätzung sein, mit was für einem Setup das Projekt langfristig Erfolg haben kann. Liegt der Erfolg beispielsweise darin, dass das Projekt in einem bestehenden Bereich des Konzerns bestimmte Ressourcen oder Expertise mitnutzen kann und damit einen großen Marktvorteil hat, sollte dieser Bereich nicht erst mit Projektabschluss davon erfahren. Idealerweise sollten solche Ergebnisse schon vor Projektbeginn antizipiert und der entsprechende Bereich in das Projekt involviert werden, um eine „Ownership“ (Zugehörigkeitsgefühl bzw. Zuständigkeit) zu entwickeln und schon vor Projektbeginn ein Commitment (Zusage) von dem Bereich zu erhalten, das Projekt bei Erfolg auch weiterzuführen. Die Herausforderung ist dabei aber, trotz einer bereits eingeholten Zusage noch die nötige Flexibilität und Ergebnisoffenheit bei dem ja erst noch zu evaluierenden Produkt zu wahren. Das Projektteam sollte daher bis zum Ende die Möglichkeit haben, eine eigene Empfehlung für die Weiterführung zu geben, die für das Projekt am erfolgversprechendsten erscheint.

Literatur Bland, D., und A. Osterwalder. 2020. Testing business ideas: A field guide for rapid experimentation. New Jersey: Wiley. Osterwalder, A., und Y. Pigneur. 2010. Business model generation: A handbook for visionaries, game changers, and challengers. New Jersey: Wiley. Osterwalder, A., Y. Pigneur, G. Bernarda, A. Smith, und T. Papadakos. 2015. Value proposition design. How to create products and services customers want. New Jersey: Wiley.

Die Autorin Anna Wicher ist Head of Product in einem Hamburger Corporate Startup, das ursprünglich als Projekt im Greenhouse Innovation Lab, der Ideenschmiede vom Verlag Gruner + Jahr und der Mediengruppe RTL, gestartet ist. Im Rahmen dieses Projektes ist sie seit Anfang 2019 als Produktmanagerin tätig und hat vorher zwei Jahre als Project Lead im Greenhouse Innovation Lab Innovationsprojekte am Markt validiert. Dieser Beitrag möchte die Erfahrungen dokumentieren, die sie bei der Leitung diverser Innovationsprojekte und weiteren, die sie begleitet hat, sammeln konnte. Er soll Inspirationen liefern, wie sich neue Ideen schnell und effizient am Markt validieren lassen. Kontakt: [email protected]

5

Alignment Warum gute Abstimmung so wichtig ist – und wie sie gelingt Arne Kittler

Zusammenfassung

Gut abgestimmt zu sein ist wichtig für Produktmanager – dies gilt unabhängig von der Unternehmensgröße oder der Branche, in der man arbeitet. Eine gute Abstimmung, oder neudeutsch „Alignment“, ist eine notwendige Voraussetzung dafr, dass Produktmanager Vertrauen gewinnen können. Und Vertrauen ist wiederum die Grundlage für viele Erfolgsfaktoren modernen Produktmanagements, wie etwa eine möglichst autonom iterierende Arbeitsweise als Produktteam oder auch eine effiziente Entscheidungsfindung. Der folgende Beitrag beschreibt näher, warum und in welchen Situationen eine gute Abstimmung wichtig ist und wie man sie herbeiführt.

5.1 Warum ist Alignment wichtig im Kontext moderner Produktentwicklung? Wenn wir in diesem Beitrag von Abstimmung sprechen, so meint dies, dass man als Produktmanager mit relevanten Personen in seinem Umfeld Klarheit darüber hergestellt hat, was man warum vorhat und wie das zu dem passt, was die anderen Beteiligten vorhaben. Es bedeutet nicht, dass alle Akteure zwangsläufig den Plänen der anderen zustimmen, sondern es geht erst einmal um eine größtmögliche Klarheit – gegebenenfalls auch im Dissens. Diese Klarheit ist eine notwendige Grundlage für Vertrauen. Zudem hilft sie, das Risiko unnötiger Arbeit („waste“) zu reduzieren und Entscheidungen herbeizuführen. A. Kittler (*)  New Work SE (XING), Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_5

87

88

A. Kittler

5.1.1 Alignment schafft Vertrauen Im Gegensatz zu traditionellen „Command & Control“-Führungsstilen, bei denen hierarchisch sehr konkrete Vorgaben zum Vorgehen gemacht und deren Einhaltung überprüft werden, operieren moderne Produktorganisationen mit einem wesentlich offeneren Führungsstil. Aber auch bei diesem Führungsstil wird von Produktteams erwartet, dass sie ihre Arbeit an übergreifenden Unternehmenszielen, längerfristigen Visionen, Strategien usw. ausrichten. Hinsichtlich der Frage, WAS sie dafür konkret tun und vor allem, WIE sie dies tun, genießen Produktteams aber idealerweise ein hohes Maß an Entscheidungsraum und Autonomie. Nur mit diesen Freiräumen sind Produktteams wirklich befähigt, iterativ und mit agilen Arbeitsweisen die besten Lösungen für die Nutzer und das Unternehmen zu entwickeln (Cagan 2018). Den Rückhalt, um weitgehend selbstständig als Team in der Produktentwicklung agieren zu können, kann man als Team in der Praxis aber nicht einfach für sich reklamieren, sondern man wird den nötigen Rückhalt nur dann bekommen, wenn alle relevanten Akteure im Umfeld des jeweiligen Teams hinreichend Vertrauen in das Team und sein Vorgehen haben. Fehlt dieses Vertrauen, werden übergeordnete Entscheider meist konkreter Einfluss auf die Arbeitsweise des Teams nehmen, als es diesem Recht ist, und die Zusammenarbeit mit anderen Akteuren wird zumindest deutlich abstimmungsintensiver ausfallen oder kommt im Extremfall gar nicht zustande. Indem Produktmanager sich frühzeitig mit ihrem Umfeld abstimmen, können sie einen wesentlichen Beitrag dafür leisten, Vertrauen in die eigene Arbeit und die Arbeit des eigenen Teams aufzubauen.

5.1.2 Alignment hilft Ressourcenverschwendung zu vermeiden Fehlt es an sinnvoller Abstimmung, kann es leicht zu Situationen wie den folgenden kommen: • Nach erfolgtem Launch eines Produkts herrscht Uneinigkeit darüber, ob die erzielten Ergebnisse als Erfolg zu werten sind oder nicht. Wichtige Entscheider stellen infrage, ob sich der eingesetzte Aufwand in Anbetracht des Ergebnisses gelohnt hat. • Kurz vor Fertigstellung eines wichtigen Produktlaunches stellen die betroffenen Teams fest, dass sie zwar alle intensiv auf den Launch hingearbeitet haben, aufgrund mangelnder Abstimmung ihre Teilergebnisse aber nicht sinnvoll zusammenpassen und nur mit einem erheblichen Zusatzaufwand integriert werden können. Die beiden Beispiele illustrieren, dass die Arbeit von Teams entweder nicht wie geplant zum Gesamtergebnis beiträgt oder zumindest nicht honoriert wird. Beides führt dazu,

5 Alignment

89

Abb. 5.1   Misalignment. (Quelle: Kniberg 2016)

dass weniger Kapazität als theoretisch vorhanden für eine bestmögliche Produktlösung im Interesse der Nutzer aufgewandt werden kann. Ein anschauliches Beispiel für die Kosten mangelnder Abstimmung liefert der langjährige Spotify-Coach Henrik Kniberg (2016) in seiner Zeichnung (Abb. 5.1).

5.1.3 Alignment hilft Entscheidungen herbeizuführen Wie eingangs erwähnt, geht es bei Abstimmungen von Produktmanagern nicht zwangsläufig darum, umfassend Konsens herzustellen. Aufgrund unterschiedlicher Perspektiven oder im Extremfall sogar aufgrund von Zielkonflikten lässt es sich häufig auch gar nicht vermeiden, dass Produktmanager eine andere Sicht auf ein Produktentwicklungsvorhaben haben als ihr Gegenüber. Dies kann in größeren Organisationen beispielsweise in der Zusammenarbeit zwischen Produktmanagern der Fall sein, die für einzelne Teilprodukte das Maximum herausholen wollen, und Plattform-Produktmanagern, die eher eine holistische Perspektive als lokale Optima im Blick haben. Diese Konflikte nicht nur auszuhalten, sondern sie entweder selbstständig beizulegen bzw. zeitnah per geregelter Eskalation (vgl. Abschn. 3.7) zu einer Entscheidung zu führen, ist eine zentrale Verantwortung von Produktmanagern. Werden Meinungsverschiedenheiten nicht zu einer erfolgreichen Klärung gebracht, wirkt sich dies negativ auf das gegenseitige Vertrauen in der Zusammenarbeit aus. Häufig führen ungeklärte bzw. verschleppte Entscheidungen zudem dazu, dass die Produktentwicklung blockiert oder zumindest negativ beeinträchtigt wird.

90

A. Kittler

Aus den genannten Gründen ist es so wichtig, dass Produktmanager mit ihrem Umfeld über eine sinnvolle Abstimmung Klarheit herstellen.

5.2 Mit wem sollte man sich als Produktmanager aktiv abstimmen? Als Produktmanager ist eine Abstimmung in drei Dimensionen wichtig: vertikal, lateral und mit dem eigenen Team. Am offensichtlichsten ist die Bedeutung einer erfolgreichen vertikalen Abstimmung mit den Vorgesetzten und anderen übergeordneten Entscheidungsträgern: Es ist im Interesse von Produktmanagern, dass Vorgesetzte verstehen, warum man in welcher Weise agiert und was man vorhat, damit diese der Produktmanagerin und ihrem Team das nötige Vertrauen gewähren, selbstständig zu entscheiden, wie sie vorgehen. Dabei ist es möglich, dass man im Rahmen der Abstimmung feststellt, dass Vorgesetzte eine ganz andere Vorstellung haben und man deshalb das eigene Vorgehen noch einmal hinterfragen muss. Das mag kurzfristig ungelegen kommen, typischerweise ist es aber sinnvoller und effizienter, unterschiedliche Vorstellungen frühestmöglich herauszufinden und nicht „heimlich“ und unabgestimmt loszulegen und damit zu riskieren, dass die agierenden Teams wegen späterer Änderungen vergeblich arbeiten. Insbesondere in größeren Organisationen mit mehreren Produktteams oder starken Teams in anderen Funktionsbereichen, wie Sales oder Marketing, ist eine gute laterale Abstimmung besonders wichtig. Lateral meint dabei, sich auf gleicher „hierarchischer Ebene“ auszutauschen und abzustimmen. Denn nur auf diesem Wege kann man frühzeitig sicherstellen, dass eine übergreifende Zusammenarbeit am Ende auch wirklich zusammenpasst oder man stellt schnell fest, wenn es Interessenskonflikte gibt, die nur über eine Eskalation auf hierarchisch höherer Ebene aufgelöst werden können. Und schließlich ist es ebenso wichtig, dass Produktmanager auch mit ihrem eigenen Team gut darüber abgestimmt sind, warum sie eine Produktentwicklung verfolgen und was sie grob vorhaben. Nur wenn die Teammitglieder diesen Kontext verstehen, können sie aus ihrer jeweiligen fachlichen Perspektive sinnvoll zu einer bestmöglichen Lösung beitragen. Und auch motivatorisch ist es wichtig, dass alle Teammitglieder verstehen, wie ihre Arbeit zum Unternehmenserfolg beiträgt. Klarheit hierüber herzustellen ist mit systematischer Abstimmung wesentlich besser möglich als rein informell.

5.3 In welchen Kontexten ist Alignment besonders wichtig? Eine gründliche und systematische Abstimmung bedeutet für alle Beteiligten zunächst einmal einen Zusatzaufwand. Der Aufwand einer frühzeitigen Abstimmung lohnt sich aber im Allgemeinen, weil er hilft, spätere Ineffizienzen, Missverständnisse oder zu einem späten Zeitpunkt nicht mehr lösbare Probleme zu vermeiden.

5 Alignment

91

Wichtige Indikationen für Produktmanager, sich um eine aktive Abstimmung zu bemühen, sind u. a. die folgenden Situationen: • Eine geplante Initiative ist für viele, insbesondere heterogene Entscheider im Unternehmen von hoher Relevanz. • Eine geplante Initiative erfordert die Zusammenarbeit mit anderen Teams oder flankierenden Spezialisten wie Analysten, Data Science oder Marketing. • Eine geplante Initiative stellt einen signifikanten Entwicklungsaufwand für das eigene Team und ggf. auch weitere betroffene Teams und Spezialisten dar. Wann immer Produktmanager sich in einer Situation befinden, in der mindestens eines dieser Kriterien gilt, ist es ratsam, den Kontext aktiv über eine systematische Abstimmung der geplanten Initiative besser zu klären.

5.4 Wann sollte eine systematische Abstimmung am sinnvollsten erfolgen? Grundsätzlich sollte eine Abstimmung so früh wie möglich in einer Initiative erfolgen, um das Risiko späterer Richtungswechsel und damit eines ineffizienten Mitteleinsatzes möglichst gering zu halten. Erfahrungsgemäß besteht eine Herausforderung darin, dass man es insbesondere bei Neuentwicklungen zu einem frühen Zeitpunkt noch mit einem hohen Maß an Unsicherheit über den Kontext der Produktinitiative zu tun hat und sich möglicherweise auch der eigenen Haltung zum weiteren Vorgehen noch nicht ganz klar ist. Der Umstand, dass man weiß, wie viel man eigentlich noch nicht weiß, sollte Produktmanager aber nicht davon abhalten, frühzeitig eine gemeinsame Klärung zu suchen und auf diesem Wege auch für sich selbst mehr Klarheit zu erlangen.

5.5 Welche Vorgehensweisen helfen bei der Abstimmung? Wie genau man als Produktmanager am sinnvollsten zu einer erfolgreichen Abstimmung kommt, hängt oft von spezifischen Kontextfaktoren, wie der Unternehmenskultur und dem Stellenwert, der dem Produktmanagement dabei eingeräumt wird, ab. Grundsätzlich hilft es aber, folgende Aspekte zu berücksichtigen:

5.5.1 Die richtigen Gesprächspartner in der richtigen Reihenfolge Wie unter Abschn. 5.2 beschrieben ist es hilfreich, sich mit einer Vielzahl an Personen(gruppen) abzustimmen. Allerdings kann man natürlich nicht mit allen

92

A. Kittler

gleichzeitig sprechen. Deshalb macht es Sinn, sich initial – und auch im weiteren Verlauf eines Abstimmungsprozesses immer wieder – bewusst zu machen, wen man sinnvollerweise einbeziehen sollte und in welchen Konstellationen und Reihenfolgen man das am besten tut. Im Sinne einer vertrauensvollen Zusammenarbeit mit anderen Teams kann es beispielsweise helfen, zunächst lateral in die Abstimmung zu gehen und erst danach – und ggf. auch gemeinsam – hierarchisch übergeordnete Stakeholder bzw. Entscheider einzubeziehen. Wenn man allerdings widersprüchliche Signale aus der Richtung mehrerer Entscheider wahrnimmt, ist es am wichtigsten, zunächst diese Unklarheit aufzulösen, bevor man in operativere Abstimmungen geht. Und falls man als Produktmanager nicht ausreichend Klarheit über Details des zur Abstimmung stehenden Produkts hat, ist es grundsätzlich hilfreich, zunächst mit dem eigenen Team in die Abstimmung zu gehen und dadurch eine fundiertere Grundlage für alle weiteren Abstimmungen außerhalb des Teams zu legen. Da Produktmanager in Abstimmungen häufig als „Außenminister“ ihres Teams agieren ist es wichtig, inhaltlich hinreichend Bescheid zu wissen und auch die Haltung des Teams zu kennen, damit das Team sich adäquat vertreten fühlt.

5.5.2 Sinnvolle Konstellationen und Methoden für eine aktive Abstimmung Egal mit wem und in welcher Reihenfolge man spricht, ist es hilfreich, die jeweiligen Gruppenkonstellationen bewusst zu wählen. Einerseits werden Produktmanager kaum Zeit haben, sich mit allen relevanten Personen separat abzustimmen (zumal dies im Interesse eines gegenseitigen Verständnisses der jeweiligen Perspektiven oftmals auch nicht sinnvoll wäre). Andererseits kann eine zu große bzw. zu heterogene Gruppe Gespräche auch erschweren, etwa weil zu viele Personen nicht aktiv teilnehmen oder weil die „Flughöhe“ der besprochenen Themen nicht passt. Je nach Methode und Zusammensetzung bietet meist eine Gruppe von 2 bis 6 Teilnehmern eine gute Möglichkeit, mit mehreren Teilnehmern gleichzeitig eine gemeinsame Sicht zu erlangen und dabei das Energielevel hochzuhalten. Eine aktive Teilnahme aller Anwesenden an einer Abstimmung ist wichtig, weil nur aktive Teilnehmer ihren Standpunkt offenlegen. Und nur, wenn sie dies tun, kommt die Abstimmung voran. Anders gesagt: Ein Meeting, zu dem man zu viele Teilnehmer einlädt und während dessen viele dann nicht bei der Sache sind, ist schlecht investierte Zeit für alle Beteiligten. Neben der Gruppengröße hilft es auch, bei Abstimmungsmeetings bewusst Formate zu wählen, die zu einer aktiven Partizipation einladen, beispielsweise indem alle Teilnehmer aufgefordert sind, ihre Perspektive über selbst geschriebene Post-Its einzubringen. Dies ist einer der Gründe, warum canvasbasierte Abstimmungsframeworks (siehe Abschn. 5.8) sich gut als Hilfsmittel für die Abstimmung eignen. Neben der

5 Alignment

93

aktiven Einbeziehung aller Teilnehmer hat die Nutzung eines Canvas zwei weitere große Vorteile: • Die Teilnehmer werden angeregt, ihre Gedanken zur diskutierten Produktinitiative zu externalisieren und somit auch für andere transparent und „handhabbar“ zu machen; • Es hilft, die Abstimmung zu strukturieren und damit z. B. auch dafür zu sorgen, dass schwierige bzw. kritische Fragestellungen nicht vergessen oder vermieden werden.

5.6 Wichtige zu klärende Fragen im Rahmen der Abstimmung Der schlimmste Feind einer wirksamen Abstimmung ist ein vermeintlicher Konsens, bei dem die kritischen Themen ausgespart werden. Dies ist so, weil man den eigentlichen Klärungsbedarf letztendlich nur auf einen späteren Zeitpunkt verschiebt, zu dem die Konsequenzen typischerweise schwerwiegender sind. Um dies zu vermeiden hilft es, einige konfliktträchtige Fragen auf jeden Fall im Rahmen der Abstimmung explizit zu adressieren, um entweder einen Konsens zu erzielen oder einen Eskalationsbedarf zu identifizieren. Die folgenden Fragestellungen orientieren sich an den wichtigsten Aspekten des bei XING seit 2016 praktizierten Abstimmungsframework der „Auftragsklärung“ (im Detail s. Abschn. 5.8), sie können allerdings auch unabhängig davon als Orientierung auf dem Weg zu einem wirksamen Alignment dienen.

5.6.1 Ausgangslage aus Nutzerperspektive Um sich sinnvoll austauschen zu können, ist es wichtig, dass alle Teilnehmer wichtige Informationen über die Ausgangslage haben: • Wie ist die aktuelle Nutzerwahrnehmung des relevanten Sachverhalts – und wie viele Nutzer sind davon betroffen? • Welche weiteren relevanten Informationen aus qualitativer und quantitativer ­User-Forschung sollten alle Beteiligten kennen? • Welche wesentlichen User-Forschungsvorhaben sind bereits geplant und was soll dabei genau untersucht werden?

5.6.2 Zielbild aus Nutzerperspektive Es wird wenig überraschen, dass es hilfreich ist, im Rahmen der frühzeitigen Abstimmung einer Produktinitiative ein gemeinsames Verständnis zum angestrebten Zielzustand zu erreichen. Um dabei eine unternehmenszentrierte Sicht zu vermeiden, ist

94

A. Kittler

es hilfreich, das Zielbild nicht aus der Innenperspektive oder in Form von umgesetzten Features zu beschreiben, sondern bewusst die Nutzerperspektive in den Vordergrund zu stellen: Wie wird sich das Ergebnis der geplanten Initiative für die davon betroffenen Nutzer anfühlen, wenn wir fertig sind? Für diese Außenperspektive der Zukunft kann man sich beispielsweise an dem vielfach mit Amazon in Verbindung gebrachten „Working backwards“-Format orientieren, mit dem man versucht, im Voraus anhand einer fiktiven Presseerklärung zu beschreiben, worin der emotionale und funktionale Mehrwert einer Initiative für die Zielnutzer bestehen wird (Bariso 2019).

5.6.3 Hypothesen Präferenzen in Bezug auf zukünftige Vorgehensweisen und Prioritäten speisen sich typischerweise nicht nur aus Fakten, sondern auch zu einem erheblichen Teil aus individuellen Annahmen zu zukünftigen Wirkzusammenhängen. Solange man die Annahmen der anderen Beteiligten bei ihrem Agieren nicht kennt, ist es schwierig, die anderen Verhaltensweisen zu verstehen und sinnvoll miteinander zu kollaborieren. In einem Alignment-Prozess ist es darum wertvoll, die persönlichen Annahmen der Beteiligten explizit zu machen und sich auf ein zentrales Set von Hypothesen zu einigen: Welche Annahmen müssen sich als richtig erweisen, damit die Initiative die erhoffte Wirkung bei den Nutzern entfaltet? Ein gemeinsames Verständnis zentraler Hypothesen kann zudem im Anschluss auch die Priorisierung wichtiger Produktexperimente erleichtern, mit denen man idealerweise besonders erfolgskritische Hypothesen überprüft.

5.6.4 Input – und Rollen Sinnvollerweise thematisiert man bei einer Abstimmung auch frühzeitig die jeweiligen Vorstellungen davon, welche Inputs – im Sinne von Mitteleinsatz oder Arbeitskapazität – man für die Initiative einzusetzen gedenkt. Gerade bei der Abstimmung mit übergeordneten Entscheidern dient dies einer frühzeitigen Entscheidung, ob die beabsichtigte Investition in einem gesunden Verhältnis zum erwarteten Ergebnis steht. Eine gute Einheit, um erwartete Entwicklungsaufwände zu beziffern, können beispielsweise Personenmonate sein. Ein weiterer wichtiger Aspekt im Rahmen der Klärung ist das Explizitmachen der jeweiligen Rollen der einzelnen Beteiligten bei dem gemeinsamen Vorhaben. Dies hilft u. a. bei der Frage, mit wem man sich sinnvollerweise abstimmen sollte. Als Daumenregel kann gelten, dass man alle beteiligten Abteilungen, von denen man einen signifikanten Beitrag erwartet, genau hierzu in die Klärung einbezieht.

5 Alignment

95

5.6.5 Output – und Grenzen Auch wenn man zu einem frühen Zeitpunkt idealerweise noch offen für die bestmöglichen Ergebnisse einer Discovery-Phase sein sollte, werden alle Betroffenen bereits eine gewisse Vorstellung davon haben, welche greifbaren Ergebnisse – im Sinne konkreter Artefakte vor internen oder externen Nutzern – im Rahmen der Initiative herauskommen werden: Geht man also beispielsweise davon aus, dass eine neue native App entwickelt wird? Oder geht es um die Erweiterung eines Services innerhalb eines bestehenden ­Web-Angebots? Die Herausforderung bei einer Abstimmung liegt darin, hierbei noch hinreichend ergebnisoffen zu sein, gleichzeitig aber die eigenen Erwartungen trotzdem mit anderen zu teilen, damit man frühzeitig feststellt, ob man grundsätzlich dieselben Vorstellungen hat. Wie auch beim Outcome macht es Sinn, beim Output explizite Grenzen abzustecken: In diesem Fall geht es aber eher darum zu benennen, was explizit nicht im Rahmen der Initiative, also Out of Scope, liegt. Gerade bei längerfristigen Initiativen mit heterogenen Beteiligten ist es wichtig zu klären, worum man sich ausdrücklich nicht kümmert, oder worum man sich zumindest in einer ersten Phase noch nicht kümmert. Auf diesem Wege kann man die Gefahr von Missverständnissen und späteren Enttäuschungen verringern.

5.6.6 Outcome – und Grenzen Klarheit darüber, was eine Initiative verändern soll, ist zentral, um Einigkeit darüber zu erzielen, wann man die Initiative als Erfolg wertet. Dies ist eine der zentralen Fragen der Abstimmung. Dabei geht es nicht um das sichtbare Ergebnis (Output), sondern um die Veränderung beim Nutzer und/oder beim Unternehmen (Outcome).1 Dabei ist es wichtig, möglichst präzise zu benennen, welche Metriken man bewegen will und wie groß die Veränderung bis zu welchem Zeitpunkt idealerweise sein sollte. Im besten Fall identifiziert man Metriken, die möglichst direkt von der geplanten Initiative beeinflusst werden können. Statt der generellen Entwicklung der wöchentlichen aktiven Nutzer (auf die in den meisten Unternehmen viele Maßnahmen parallel hinarbeiten) könnte man beispielsweise eher die Wiederkehrrate eines bestimmten Usersegments als Erfolgskriterium heranziehen. Gerade wenn die Abstimmung zu einem frühen Zeitpunkt stattfindet, kann es mitunter jedoch schwierig sein, konkrete Zielwerte zuverlässig vorherzusagen. Im Sinne gegenseitiger Erwartungsklärung macht es aber Sinn, selbst dann Zielwerte bei der Abstimmung zu benennen, selbst wenn diese lediglich dem eigenen Bauchgefühl ent-

1Zum

Unterschied zwischen Outcome und Output s. ausführlich Gothelf und Seiden (2017).

96

A. Kittler

springen. Denn damit kann man einen fruchtbaren Dialog darüber anstoßen, bei welchen Zielwerten unterschiedliche Abstimmungspartner zufrieden mit dem Ergebnis der Initiative wären. Wenn man bei dieser Gelegenheit beispielsweise feststellt, dass wichtige Stakeholder die Initiative nur bei einer Verzehnfachung der Zielmetrik lohnenswert finden, man selbst aber nur eine Verdopplung für möglich hält, ist es wichtig, dies frühzeitig zu bemerken und explizit zu machen. Neben dem Zielwert ist es auch wichtig zu konkretisieren, bis wann man glaubt, diesen erreichen zu können und idealerweise auch, wie sich die Zielmetrik zwischenzeitlich entwickeln sollte. Hiermit schafft man die Grundlage dafür, im Prozess frühzeitig feststellen zu können, ob man noch im Plan ist. Neben den geplanten Zielmetriken ist es wichtig, auch explizit zu machen, ob es unbeabsichtigte Nebeneffekte gibt, die unbedingt vermieden werden müssen. So könnte es beispielsweise sein, dass eine Verbesserung des Anmeldeprozesses für bestehende Nutzer nicht zulasten der Registrierungsquote neuer Nutzer gehen darf. Oder dass bei der Integration weiterer Werbeflächen die Klickrate der eigentlichen Inhalte nur bis zu einem bestimmten Schwellwert beeinträchtigt werden darf.

5.7 Konflikte identifizieren und zur Klärung bringen Wie eingangs erwähnt, geht es bei Klärung nicht zwangsläufig darum, sich mit allen Beteiligten sofort einig zu werden. Im Gegenteil liegt der Wert einer frühzeitigen Abstimmung besonders bei komplexeren Produktentwicklungsvorhaben oft darin, rechtzeitig zu einem Zeitpunkt, an dem man noch Handlungsoptionen hat, etwaige Konflikte zu identifizieren und dadurch adressieren zu können. Entsprechend ist es im Rahmen der Klärung auch nicht die Aufgabe von Produktmanagern, es allen Recht zu machen, sondern frühzeitig Konflikte zu identifizieren und sie zu einer Klärung zu bringen. Dabei können folgende Regeln helfen, die an das bei XING eingesetzte „Clarification Manifesto“ (Kittler 2018) angelehnt sind: Einigkeit darüber erzielen, dass man sich nicht einigen kann Wenn man bei Abstimmungen feststellt, dass Konflikte nicht nur auf Missverständnissen beruhen, ist es die Verantwortung der beteiligten Produktmanager, den Konflikt zügig und explizit als solchen zu benennen und sich mit dem Gegenüber darauf zu einigen, dass man sich gerade nicht einig ist und ohne weitere Klärung der Rahmenbedingungen vermutlich auch nicht einigen wird („Agree to disagree“). Gemeinsam eskalieren Der Begriff Eskalation ist bei vielen negativ belegt, obwohl er ja eigentlich nur besagt, dass man Dinge, die man auf seiner eigenen Ebene nicht klären kann, eine Hierarchie-

5 Alignment

97

ebene höher trägt, um dort Unterstützung bei der Klärung zu erfragen. Also im Grund ein ganz normaler, wertneutraler Vorgang. Die negative Assoziation rührt vermutlich vor allem daher, dass Eskalationen häufig einseitig und hinter dem Rücken einzelner Beteiligter erfolgen, wodurch die hierarchisch übergeordnete Intervention für die Betroffenen unvorbereitet kommt und von ihnen allein deshalb schwer angenommen werden kann. Wesentlich weniger negativ ist dagegen eine Eskalation, die gemeinsam von denjenigen, die sich uneins sind, angestoßen wird. Zwei Produktmanager, die sich einig sind, dass sie sich nicht einig werden, können also gemeinsam an ihre jeweiligen Produktführungskräfte eskalieren. Klärungsbedarf klar benennen Bei einer gemeinsamen und damit transparenten Eskalation ist es wiederum hilfreich, wenn die Eskalierenden möglichst klar benennen können, in welcher Hinsicht sie Hilfe bei der Klärung benötigen („Be clear about what’s unclear“). Statt also den Führungskräften den vollständigen Verlauf des Klärungsprozesses darzulegen, wird es i. d. R. hilfreicher sein, sehr explizit zu machen, welche Rahmenbedingungen oder Grundsatzentscheidungen die Produktmanager brauchen, um die Klärung anschließend idealerweise alleine weitertreiben zu können. Verantwortung da belassen wo sie hingehört Im zuvor beschriebenen Sinne sollten die einbezogenen Führungskräfte wiederum auch nur die erforderliche Klärungshilfe leisten. Die Produktmanager sollten anschließend aber (wieder) die Verantwortung für die weitere Klärung übernehmen. Falls die hinzugezogenen Führungskräfte die angefragte Klärungshilfe als grundsätzliche Delegation missverstehen und zum Micromanagen übergehen, kann es erforderlich sein, sich als Produktmanager den Auftrag aktiv zurückzuholen.

5.8 Abstimmung in der Praxis: Auftragserklärung bei XING Viele der beschriebenen Überlegungen zur Abstimmung von Produktmanagern fußen auf den Erfahrungen des Autors als Produktführungskraft bei XING. Dort wurde Alignment vor einigen Jahren von der internen Produkt-Fachgemeinschaft als eine der wesentlichen Herausforderungen identifiziert und daraufhin mit der Auftragsklärung eine Methode intern etabliert, die inzwischen auch weltweit innerhalb des ­Produktmanagement-Diskurses referenziert wird, so beispielsweise von Martin Eriksson, dem Gründer von Mind The Product und Co-Autor des Buches Product Leadership (Banfield et al. 2017). Der folgende Exkurs zur Auftragsklärung ist als Anregung zu verstehen, nicht mit dem Anspruch, dass Auftragsklärung à la XING für jeden Kontext die beste Methode zur Abstimmung bietet.

98

A. Kittler

5.8.1 Ursprung und Entwicklung der Auftragsklärung Nachdem die Produktorganisation bei XING zwischen 2010 und 2015 signifikant auf über 30 Produktmanagerinnen und Produktmanager gewachsen war, wurde eine Fachgemeinschaft („Community of Practice“) etabliert, um einen systematischen Austausch und eine gemeinschaftliche Ausrichtung zu verfolgen. Denn obwohl bei XING mit Methoden agiler Software-Entwicklung und somit auch dem Ideal möglichst autonom agierender Teams operiert wird, gab und gibt es aufgrund der engen Verzahnung einzelner Produkte zahlreiche gegenseitige Abhängigkeiten und Synergiepotenziale. Im Rahmen einer ersten Bestandsaufnahme wurde identifiziert, dass die bereichsübergreifende Abstimmung eines der Themen war, das viele der Produktmitarbeiter als besonders herausfordernd empfanden. Als gemeinsame Methode wurde mit der „Auftragsklärung“ ein in allen Produktabteilungen der Firma einheitliches Abstimmungsformat etabliert. Nach ersten Versuchen mit ausformulierten, längeren Textdokumenten wurde das Format im Rahmen von Überarbeitungen zu einem deutlich partizipativeren Canvas entwickelt, der dann sowohl innerhalb als auch außerhalb von XING kommunikativ ausgerollt wurde. Als Beispiel hierfür sei auf die Präsentation von Marc Kadish beim ProductTank London verwiesen (Kadish 2016). Nach mehreren Jahren in der Anwendung wurde das Format 2019 überarbeitet, um die Nutzerperspektive expliziter einzubeziehen und durch Umstrukturierungen und Hilfetexte eine bessere Hilfestellung in der Anwendung zu bieten (New Work SE 2019). Die aktuelle Version zeigt Abb. 5.2, die auch unter www.auftragsklaerung.com abrufbar ist.

5.8.2 Wesentliche Artefakte und übliche Praktiken Im Kern der Auftragsklärung steht der Canvas, da dieser sich besonders gut als Hilfsmittel bei Abstimmungsbesprechungen eignet und dabei hilft, Abstimmungsteilnehmer zum Externalisieren ihrer jeweiligen Positionen zu bewegen. Wichtig in der Anwendung ist allerdings, dass der Canvas und alle anderen Artefakte letzten Endes nur Mittel zum eigentlichen Zweck der Auftragsklärung darstellen, nämlich einer frühzeitigen, kollaborativen Abstimmung. Typischerweise wird die Auftragsklärung bei XING von den für eine Initiative verantwortlichen Produktmanagern initiiert und mithilfe des Canvas in mehreren Iterationen detailliert. Der resultierende Canvas hängt häufig als Referenz im Büro der betroffenen Teams. Aufgrund der zunehmend auch standortübergreifenden Arbeitsweise bei XING-Standorten wird aktuell auch mit Remotetauglichen Formaten der Auftrags­ klärung, z. B. unter Einsatz der Software Miro, experimentiert.

5 Alignment

Abb. 5.2   Auftragsklärung. (Quelle: New Work SE 2019)

99

100

A. Kittler

5.8.3 Einführung, Anwendung und Missverständnisse Nach einer initialen Pilotphase gab es bei XING mehrere Wellen von Trainingsphasen, in denen alle Produktmanager in der Anwendung der Auftragsklärung geschult wurden. Diese Schulungen halfen bei der Etablierung des Frameworks und trugen dazu bei, dass sich die Auftragsklärung als Format fest in der Produktarbeit bei XING etablierte und zunehmend als Referenz in der Zusammenarbeit nachgefragt wurde („Ich bin neu in dem Thema. Kannst Du mir bitte einmal die Auftragsklärung zeigen?“). Und auch außerhalb der Produktabteilungen fand die Auftragsklärung zunehmend Anwendung, wurde dort in Ermangelung von systematischen Schulungen und Begleitungen aber mitunter anders als intendiert angewandt. Im Ergebnis wurden beispielsweise lang ausformulierte Schriftdokumente in der Struktur der Auftragsklärung erstellt, um für interne Initiativen zu werben. Diese Formate verfehlen aber den eigentlichen Zweck der Auftragsklärung, nämlich als Hilfsmittel bei einem Dialog zu fungieren und damit dazu beizutragen, dass kritische Fragestellungen frühzeitig adressiert werden. Aktuell wird daher bei XING erwogen, Schulungen zur Auftragsklärung auch jenseits der Produktorganisation auszuweiten.

5.9 Grenzen sinnvoller Abstimmung Wie wichtig eine gute und frühzeitige Abstimmung ist, wurde bereits dargelegt. Wichtig ist allerdings auch im Blick zu haben, dass innerhalb einer Organisation kein „Abstimmungs-Fetisch“ entsteht, der der hier formulierten eigentlichen Intention entgegenwirkt. Dies wäre beispielsweise der Fall, wenn zu viele operative Details frühzeitig fixiert werden und dadurch ein sinnvoller Freiraum für Iteration fehlt. Oder wenn Produktmanager so viel Zeit in Abstimmungen verbringen, dass keine Zeit mehr für die kollaborative Arbeit an guten Nutzerlösungen bleibt. Daher ist es sinnvoll, Klärung nicht zum Selbstzweck werden zu lassen, sondern den Klärungsbedarf jeder Initiative zur jeweiligen Situation mit hinreichendem Abstand zu hinterfragen und sich ggf. auch bewusst gegen eine Abstimmung zu entscheiden.

Literatur Banfield, R., M. Eriksson, und N. Walkingshaw. 2017. Product leadership, Sebastopol: O‘Reilly. Bariso, J. 2019. Amazon has a secret weapon known as “Working Backwards” – and it will transform the way you work. https://www.inc.com/justin-bariso/amazon-uses-a-secret-process-forlaunching-new-ideas-and-it-can-transform-way-you-work.html. Cagan, M. 2018. Empowered product teams. https://svpg.com/empowered-product-teams.

5 Alignment

101

Gothelf, J., und J. Seiden. 2017. You need to manage digital projects for outcomes not outputs. https://hbr.org/2017/02/you-need-to-manage-digital-projects-for-outcomes-not-outputs. Kadish, M. 2016. Collaborative alignment – the ‚Auftragsklärung‘ framework. https://www. mindtheproduct.com/alignment-framework-managing-stakeholder-communications. Kittler, A. 2018. Clarity in collaboration. https://youtu.be/T5Ta6TJtQKs. Kniberg, H. 2016. Misalignment. https://blog.crisp.se/2016/05/30/henrikkniberg/misalignment. New Work SE. 2019. Auftragsklärung. https://auftragsklaerung.com.

Der Autor Arne Kittler arbeitet seit seinem Studium der Medien-Planung, -Entwicklung und -Beratung (Universität Siegen, Abschluss als Diplom-Medienwirt) in Schnittstellenberufen der digitalen Medien. Seit mehr als 8 Jahren ist er als Produktführungskraft bei XING/New Work tätig und war dabei eine der treibenden Kräfte bei der Einführung des Abstimmungsframeworks Auftragsklärung. Neben seiner Arbeit bei XING ist er C ­ o-Veranstalter und -Kurator von MTP Engage Hamburg, der aktuell größten Konferenz für Produktmanager in Deutschland. Er twittert unter @ arnekittler. Kontakt: [email protected]

6

Wirkungsorientiertes Produktmanagement mit OKR Erfolgreiche Produkte bauen durch Fokus, Kommunikation und gemeinsames Lernen Sonja Mewes

Zusammenfassung

Wirkungsvolles Arbeiten ist ein erstrebenswerter Zustand für Organisationen und Menschen. Alle vorhandenen Ressourcen und alle Zusammenarbeit von Menschen sind dann auf das Lebendigwerden eines Sinnzweckes ausgerichtet. Die damit verbundene hohe Motivation, der klare Beitrag zur Wertschöpfung und mehr ermöglichen erfolgreiche, wirksame Organisationen. Objectives & Key Results (OKR) ist eine Methode, die ein solches wirkungsorientiertes Arbeiten durch transparente, fokussierte und partizipativ erstellte sowie nachverfolgte Ziele organisationsweit unterstützen kann. In diesem Kapitel werden die Hintergründe zur Methode, die Auswirkungen auf die Arbeit im Produktmanagement und auch der Lernprozess bei der Benutzung von OKR beleuchtet.

6.1 Herausforderungen für Produktorganisationen Produktverantwortliche in Organisationen kennen sehr wahrscheinlich den einen oder anderen Moment aus ihrem Alltag in der Zusammenarbeit mit Kollegen, Führungskräften oder Kunden:

S. Mewes (*)  Beautiful Future, Erfurt, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_6

103

104

S. Mewes

Beispiel 1

Ein aktuelles Produkt wird von den Vertriebskollegen bei Kunden präsentiert. Im Verkaufsprozess haben die meisten Kunden detaillierte Fragen und vor allem auch Anforderungen, wie das Produkt außerdem noch zu ihren ganz individuellen Bedürfnissen passen sollte. Um den Vertragsabschluss zu sichern, verspricht nun der Vertriebskollege dem potentiellen Kunden, dass zwei seiner Anforderungen mit Sicherheit im nächsten Jahr noch in das Produkt eingebaut werden können. Die Firma feiert den unterzeichneten Vertrag, die Produktverantwortliche jedoch ist nicht erfreut, weil sie eine unfreiwillige Zusatzaufgabe erhält, die nicht auf die Kern-Produktvision einzahlt. ◄ oder Beispiel 2

Das Führungsteam der Organisation bereitet die Planung für das kommende Jahr vor. Budgets werden erstellt, Themen- und Ressourcenplanungen in den Fokus genommen. Alle Produktverantwortlichen werden nach ihrem Beitrag für diese Planungen gefragt und sollen einen Plan erarbeiten, welche Schwerpunkte in ihrem Produktbereich bearbeitet werden und wie viele Ressourcen dafür nötig seien. In den Produktteams wird jedoch im Alltag mit Scrum als Vorgehensmodell gearbeitet, bei dem eine agile, iterative Bearbeitung in zweiwöchigen Sprint-Zyklen vorgesehen ist. Mehrwert dieses agilen Modells ist die jederzeit mögliche Änderung der Pläne, je nachdem ob Kundenbedürfnisse oder technische Möglichkeiten schnelle, neue Anpassungen erfordern. Ist die sogenannte Produkt-Roadmap, also die Themenplanung für das Produkt, aber bereits ein Jahr im Voraus geplant, kann die Arbeit mit Scrum nur noch auf kleine Dinge reagieren und ihre eigentlichen agilen Potentiale können nicht genutzt werden. ◄ oder Beispiel 3

Die Bereichsleiterin kommt von einer internationalen Konferenz zurück, bei der sie von vielen Mitbewerbern von deren Umsetzung eigener Nachrichten-Produkte erfahren hat. Voller Begeisterung verkündet sie im nächsten Meeting: „Wir bauen auch eine Nachrichten-App“ und verteilt Aufgaben für eine erste Discovery-Phase, in der weitere Details dieses neuen Produktes ausgearbeitet werden sollen. Über den konkreten Kundenmehrwert in Relation zu vorhandenen Produkten oder, ob eine solche App überhaupt die richtige Lösung für das aktuelle Problem ist, eine neue Zielgruppe anzusprechen, kann nicht mehr diskutiert werden. Die Entscheidung

6  Wirkungsorientiertes Produktmanagement mit OKR

105

wurde innerhalb der bestehenden Machtstruktur getroffen. Ungünstigerweise entsteht so ein Zusatzprojekt, ohne dafür bestehende Themen zu de-priorisieren. Der Stapel an Themen im Produktteam wächst und damit gleichzeitig auch das Risiko für Unzufriedenheit, Defokussierung und Misserfolge. ◄ Diese und ähnliche Vorkommnisse beschreiben typische Probleme in Organisationen, die auch das Produktmanagement als Teil von Organisationen betreffen: Statt konkrete Lösungen von Kundenproblemen im Kleinen, beziehungsweise die Erfüllung von Sinnzweck oder Vision der Organisation im Großen als Grundlage von Entscheidungen heranzuziehen, stehen vielmehr individuelle Vorstellungen Einzelner oder das Generieren von Ergebnissen in Form von Umsatz oder Features im Vordergrund. Da Letzteres mit dem Funktionieren einer Maschine vergleichbar ist, wird im Produktumfeld in solchen Kontexten auch von Teams als #FeatureFactory gesprochen. Wirksamkeit für Organisationen, Teams und einzelne Personen bezieht sich dagegen auf Ersteres: durch Aktivitäten, zum Beispiel im Produktmanagement, entsteht tatsächlich ein erwünschter Mehrwert für Nutzer.

6.2 Einführung in Objectives & Key Results Eine Möglichkeit, Wirksamkeit in der gesamten Organisation zu verankern, bietet die Methode Objectives & Key Results (kurz: OKR). Sie ermöglicht es im Kern, für alle Mitarbeiter transparente und gemeinsam abgestimmte Ziele zu formulieren, deren Fortschritt regelmäßig zu überprüfen. Aufsetzend auf bestehenden Methoden bzw. Prozessen zur Steuerung mit Zielen wie Management by Objectives (MBO), Key Performance Indicators (KPI), SMART Goals oder der Balanced Scorecard kann sie als eine Evolution der Ziel-Systeme betrachtet werden, die sowohl Ziel-Definition als auch den Prozess der Ziel-Erreichung umfasst. Die Methode, die heute häufig mit Google in Verbindung gebracht wird, wurde ursprünglich von Andy Grove von Intel erdacht. Intel musste sich in den 1970er Jahren der notwendigen Herausforderung stellen, das gesamte Unternehmen innerhalb kürzester Zeit auf eine neue Branche auszurichten. Die Notwendigkeit einer klaren Ausrichtung und schnellen Anpassungsmöglichkeiten veranlasste Grove, alle Aktivitäten auf einen vierteljährlichen „Nordstern“ (Objective) auszurichten, konkretisiert durch eine Reihe messbarer Schlüsselergebnisse (Key Results). Sie zeigen an, ob das Unternehmen auf dem richtigen Weg ist, das Objective tatsächlich zu erreichen. Er hatte mit diesem Vorgehen Erfolg und Intel wurde vom Speicher- zum Mikroprozessoranbieter. 1999 stellte der frühere Intel-Mitarbeiter John Doerr diese Vorgehensweise dem jungen Google-Management-Team vor. Seitdem arbeitet Google mit OKR. Durch wechselnde Mitarbeiter hat sich das Konzept über das Silicon Valley, die Tech-Branche und darüber hinaus verbreitet. Mehr über die Geschichte und ihre Verbreitung im Silicon Valley und in der Welt bei Doerr (2018). Seit einigen Jahren kommt es auch verstärkt in

106

S. Mewes

deutschen Unternehmen zum Einsatz, zum Moment der Artikelerfassung beispielsweise in einzelnen Organisationsbereichen von Daimler, Bosch, Flixbus, HolidayCheck oder auch vielen Start-ups. OKR bilden eine Brücke zwischen der langfristigen Vision und Strategie einer Organisation und den kurzfristigen Aufgaben. Sie beschreiben auf inspirierende Art und Weise die nächste Etappe zur Erreichung der Vision als eine Art „Mini-Strategie“ und machen die Ziele so greifbar und nutzbar als Priorisierungsinstrument im beruflichen Alltag. Um das Objective verständlich zu machen, wird es immer durch mehrere messbare Ergebniskriterien, den sogenannte Key Results, konkretisiert. Sie beschreiben den bewusst ambitioniert erwünschten Endzustand aus verschiedenen Perspektiven, in der Annahme, dass hoch gesteckte Ziele die Chance auf neue Denkweisen und neue, innovative Lösungsräume eröffnen. Im Folgenden wird im Artikel die Abkürzung „OKR“ als Referenz auf die Methode selbst und die Formulierung „OKR-Set“ oder „OKR-Sets“ für eines oder mehrere konkret definierte Objectives mit den dazugehörigen Key Results verwendet.

6.2.1 Objectives Objectives haben die Funktion eines „Nordsterns“, der jederzeit Orientierung gibt, sind jedoch für einen kürzeren Zeitraum als eine langfristige Unternehmensvision ausgelegt, s. Abb. 6.1. Sie beschreiben vielmehr allein den nächsten Schritt hin zur Erreichung der Vision. Typischerweise zeichnen sie sich durch die folgenden Attribute aus: 1. qualitativ, ambitioniert und inspirierend, 2. bringt alle einen Schritt näher zur Strategie/Vision/Purpose, 3. zeitgebunden, 4. möglichst unabhängig erreichbar.

Purpose Mission Vision Strategie

OBJECTIVE Inspirierende Beschreibung der nächsten Etappe auf dem Weg zum Erreichen der Vision KEY RESULTS • Messkriterien • 2-5 pro Objecve • Verschiedene Perspekven • Relaver Wert, absoluter Wert, Meilenstein oder binäres Ja/Nein

Abb. 6.1   Objectives & Key Results. (Quelle: Eigene Darstellung)

Aufgaben management

6  Wirkungsorientiertes Produktmanagement mit OKR

107

Ob die festgelegten Ziele tatsächlich ambitioniert, inspirierend und passend für den Zeitraum sind, kann nur von der jeweiligen Organisation beurteilt werden, weil sie das Ergebnis einer gemeinsamen Diskussion widerspiegeln. Ein exemplarisches Objective einer Organisation könnte lauten: 

„Wir wollen das neue Kundensegment Mittelstand erobern.“

Dieses Objective allein ließe noch immer einen zu großen Interpretationsspielraum offen, wer oder was mit „Mittelstand“ und „erobern“ eigentlich genau gemeint ist und wann das Objective wirklich erfolgreich erfüllt ist. Es besteht die Gefahr, dass unterschiedliche Personen und Teams der Organisation dieses unterschiedlich auslegen und im Extremfall zur Realisierung vielleicht sogar in entgegengesetzte Richtungen arbeiten.

6.2.2 Key Results Key Results beschreiben den gewünschten Endzustand eines Objective mit konkreten Kriterien und machen es so messbar. Durch sie wissen alle während des Weges und auch am Ende ganz genau, ob sie den Zustand erreicht haben oder nicht. Mit zwei bis fünf Key Results wird das Objective aus verschiedenen Perspektiven spezifiziert und greifbar. Analog zur Betrachtung eines Gegenstandes wie einer Tasse von allen Seiten – dem Boden, der Öffnung, der Seite mit Griff, den restlichen Seiten – beschreiben Key Results das Objective aus verschiedenen Blickwinkeln. Statt allein auf Umsatzzahlen für die Steuerung zu setzen, fließen so vielmehr auch andere Perspektiven wie Qualität, Prozess, Nutzerwachstum etc., in die Beschreibung des erwünschten Zustandes ein. Einfache Fragen, um Key Results zu definieren, sind etwa: „Woran merke ich, wenn ich mein Objective erreicht habe?“ oder „Welche Zahlen, mit denen ich Kundenbedürfnisse messen kann, würden sich dadurch ändern?“. Key Results können dabei absolute bzw. relative Zahlen oder auch Meilensteine sein. Auch binäre Ja/Nein-Beschreibungen sind möglich, sollten keine passenden Kennzahlen vorhanden sein. Je mehr Zahlen benutzt werden, desto klarer und einfacher ist der Fortschritt im Laufe der Umsetzung auch messbar. Das genannte Objective „Wir wollen das neue Kundensegment Mittelstand erobern“ könnte beispielsweise durch diese Key Results aus verschiedenen Perspektiven beschrieben werden: Beispiel

Objective „Wir wollen das neue Kundensegment Mittelstand erobern“ • Key Result 1: 100.000 Leads von Online-Marketers sind im Akquise-Funnel • Key Result 2: 50.000 € Umsatz werden aus dem neuen Segment gewonnen

108

S. Mewes

• Key Result 3: Steigerung der Kundenzufriedenheit von 50 % auf 80 % in Zielgruppe • Key Result 4: 4 neue Produkte für Zielgruppe gehen live. ◄ Key Results, die bewusst nur Messkriterien für Veränderungen beinhalten und keine konkreten Features oder Lösungen als Meilensteine vorgeben, verschaffen Produktteams die Freiheit, eigenständig die effektivsten Lösungen zu entdecken, um dann Kriterien wie Umsatz und Zufriedenheit zu steigern.

6.2.3 Der OKR-Zyklus Wie genau läuft ein OKR-Zyklus eigentlich ab? Grundsätzlich gilt für OKR wie für viele andere Methoden auch, dass alle Eckpunkte, von der Zyklusdauer bis hin zur Art und Weise der Zusammenarbeit, passend zum Umfeld der Organisation gestaltet werden können. In vielen Organisationen erstreckt sich ein OKR-Zyklus über die Dauer eines Quartals. Bei anderen Grundrhythmen in einer Organisation oder auch einem sich besonders schnell verändernden Umfeld für Start-ups kann der OKR-Zyklus aber zum Beispiel auch vier oder eben nur zwei Monate andauern. Der OKR-Zyklus besteht analog zu einem Lern-Kreislauf oder auch zum Lean Management, einem Konzept der kontinuierlichen Verbesserung, aus drei Hauptelementen: der OKR-Set-Definition zu Beginn, einem regelmäßigen (z. B. wöchentlichen) OKR-Check-in zur Fortschrittsmessung und am Ende einer OKR-Reflektion der Erreichung selbst und auch der Zusammenarbeit währenddessen (Abb. 6.2).

Purpose Mission Vision

OKRDefinion

Strategie

Alignment

OKRReflekon

OKRCheck-ins Aufgaben management

Abb. 6.2   Beispielhafter OKR-Zyklus. (Quelle: Eigene Darstellung)

6  Wirkungsorientiertes Produktmanagement mit OKR

109

6.2.4 Die OKR-Definition Beim ersten Experimentieren mit OKR im gesamten Unternehmen wird normalerweise der Definitionsprozess auf der obersten Ebene gestartet. Das Managementteam definiert zum Beispiel zuerst die OKR-Sets des Unternehmens. Nachdem sie den nächsten Ebenen vorgestellt wurden, beginnen die Abteilungen, ihre eigenen OKR-Sets in Bezug auf diese zu erstellen. Dabei fragen sie sich: „Was ist unser Beitrag zu den Unternehmens-OKR-Sets?“. Das Gleiche passiert für einzelne Teams und möglicherweise sogar einzelne Personen in einem Team. Ein typisches Format für die Definition sind drei- bis vierstündige OKR-Workshops. In diesen kann eine kreative, integrative Arbeit im Team selbst ermöglicht werden (für eine vertiefende Beschreibung dieses Entstehungsprozesses siehe Mewes (2018)). Nachdem die OKR-Sets als Entwurfsversion definiert wurden, findet ein weiterer sogenannter Alignment-Prozess statt. Dabei sind Rückmeldungen und Anpassungen zwischen verschiedenen Teams (horizontal) oder verschiedenen vertikalen Ebenen (z. B. Unternehmen – Abteilung – Team) möglich. Dieser Feedback-Prozess ist notwendig, da die einzelnen Teams nicht gleichzeitig alle Abhängigkeiten und Ideen anderer Teams berücksichtigen können, während die eigenen OKR-Sets entworfen werden. Am Ende des Prozesses wurde sichergestellt, dass das gesamte Unternehmen an einem Strang zieht und fokussiert an denselben Themen arbeitet. Dies erfordert einen hohen Kommunikationsaufwand zu Beginn des OKR-Zyklus, stellt danach aber sicher, dass alle Organisationseinheiten ihre Ressourcen sinnhaft für dieselben Themen einsetzen, statt vielleicht ein halbes Jahr in unterschiedliche Richtungen zu arbeiten.

6.2.5 Der OKR-Check-in Der OKR-Check-in ist die Basis der Steuerungsfähigkeit für Teams und Management im laufenden Zyklus. Das regelmäßige Reflektieren des Status Quo ermöglicht es bereits wöchentlich die konkreten Aufgaben oder Projekte anzupassen, sollte sich der erwünschte Fortschritt bei den OKR-Sets nicht wie gedacht einstellen. Dafür ist es wichtig, dass die Key Results bestmöglich kontinuierlich messbar sind, z. B. durch mehrere Umfragen oder Messmöglichkeiten innerhalb eines Quartals. Zu einem effizienten OKR-Check-in gehören drei Bestandteile, wie beispielhaft in Abb. 6.3 dargestellt: 1. Der Blick zurück: Was haben unsere Aktivitäten bis jetzt für die Zielerreichung gebracht? 2. Der Blick nach vorn: Wie sicher sind wir, dass wir unser Ziel zu 100 % erreichen? 3. Konkrete Planung: Was sind die Prioritäten in dieser Woche, um den nächsten, größtmöglichen Schritt in Richtung Zielerreichung zu machen?

110

S. Mewes

OBJECTIVE 04 Wir wollen das neue Kundensegment Online-Marketers erobern Status KR1: 100.000 Leads im Funnel KR2: 50.000€ Umsatz KR3: Zufriedenheit von 50 auf 80% KR4: 4 neue Produkte für ZG

Zuversicht

20%

50%

40%

100%

100%

100%

25%

75%

Prioaufgaben letzte Woche

Prioaufgaben nächste Woche

•

Meetup-Event, Inhalte, Freebies vorbereiten

•

•

Produktentwicklung Ideenphase –> Ergebnisse

4 offene Verträge abschließen

Abb. 6.3   Beispielhafter OKR-Check-in. (Quelle: Eigene Darstellung)

Entsprechen alle Zwischenstände dem gewünschten Kurs, ist ein OKR-Check-in schnell durchgeführt. Gibt es hingegen Meinungsverschiedenheiten oder unterschiedliche Informationsstände im Team bietet dieses Format einen Gesprächsanlass, diese aufzuklären. Dabei erkannte Hindernisse, die Teams abhalten ihre Key Results zu erreichen, können im Anschluss von der entsprechenden Führungskraft oder Rolle kanalisiert oder bearbeitet werden.

6.2.6 Die OKR-Reflektion Der Fokus des OKR-Check-ins liegt auf dem Bewerten des Fortschrittes und Identifizieren möglicher nächster Aufgaben, mit denen die aktuellen OKR-Sets noch besser erreicht werden können. Am Ende des OKR-Zyklus lohnt es sich außerdem zusätzlich Zeit zu investieren, um den endgültigen Status gemeinsam zu reflektieren und alle zwischenzeitlich aufgekommenen Themen einmal aus der Vogelperspektive zu betrachten. Hilfreiche Fragen dabei sind: „Wurden die gewünschten Ergebnisse erreicht?“ „Wenn ja, waren sie vielleicht zu niedrig gesteckt“, „Wenn nein, waren sie zu ambitioniert?“ „Welche Hindernisse aus dem Markt oder der internen Organisation haben uns bei der Erreichung abgehalten?“ „Was lernen wir daraus für unsere nächsten Schritte?“ Diese ­OKR-Reflektion hilft, Muster und Abläufe zu identifizieren, die im Laufe der Zeit auftauchen, s. Abb. 6.3. Außerdem unterstützt sie dabei, Perspektiven und Erkenntnisse aus den einzelnen Teams für die gesamte Organisation zusammenzubringen.

6.3 Vorteile von OKR für Produktteams Durch das beschriebene Vorgehen kann die OKR-Methode für Produktteams oder Produktorganisationen zum Beispiel ermöglichen:

6  Wirkungsorientiertes Produktmanagement mit OKR

111

1. dauerhaft mehr Klarheit und Fokus auf die wirklich wichtigen Initiativen zu legen, 2. ein besseres Alignment zwischen Teammitgliedern und Teams der gesamten Organisation zu erreichen, auch über die Produktorganisation hinaus und 3. mehr Autonomie bei der Erarbeitung von Lösungen zu erlangen. Die Beispiele zu Beginn dieses Kapitels hätten sich mit Hilfe von OKR dann vielleicht so angehört: Im Fall der Sales- und Produkt-Kollegen: Gemeinsamer Fokus und Alignment in der Organisation

Alle Teams, inklusive Vertriebs- und Produktteam, haben sich durch OKR auf gemeinsame Objectives geeinigt. Dadurch denkt der Vertriebsmitarbeiter bereits im Verkaufsprozess darüber nach, ob das Produkt für den Kunden um neue Feature erweitert werden kann und ob diese Features zu den aktuellen OKR-Sets passen. Kann das Produkt nur mit zusätzlichen Features verkauft werden, die diesem entgegenstehen, entsteht durch die ursprünglich mit OKR für alle gültigen Prioritäten zumindest ein Gesprächsanlass, für eine nun neue Situation gemeinsam mit der Produktverantwortlichen eine mögliche neue Lösung zu finden. ◄ Im Fall der Jahresplanung: Mehr Autonomie für die Teams durch geringere Vorausplanung

Durch den agilen Rhythmus wird bei OKR in kurzen Zyklen (wie ein Quartal) betrachtet, ob die gesamte Organisation noch auf dem Weg ist, ihre Vision zu erreichen. Es gibt außer strategischen Schwerpunktfeldern keine detaillierte Jahresvorplanung mehr. In Gesprächen mit längerfristigem Horizont, zum Beispiel mit Kunden, wird in diesem Fall nur noch ein Produktausblick gegeben, der intern quartalsweise durch das Formulieren der OKR-Sets verifiziert und geschärft wird. Dieses Vorgehen ist allen Mitarbeitern der Organisation klar und wird von ihnen unterstützt. ◄ Im Fall der App-Idee: Mehr Autonomie für die Teams beim Entscheiden über Features und Produkte

Einigt sich die gesamte Organisation mithilfe der OKR-Methode auf gemeinsame Prioritäten, gelten diese auch für die Bereichsleitung. Durch transparente O ­ KR-Sets ist einfacher Klarheit herzustellen, welches Thema darauf einzahlen kann und welches nicht. Sollte beispielsweise die Bereichsleiterin eine App-Idee euphorisch verfolgen wollen, bieten die definierten OKR-Sets eine sachliche Gesprächsgrundlage dazu, ob die Idee einen Beitrag leisten kann. ◄

112

S. Mewes

6.4 OKR im Produktmanagement-Alltag Purpose (Sinnzweck), Vision, Strategie und OKR-Sets beschreiben von einer langfristigen bis mittelfristigen Perspektive, WARUM eine Organisation besteht und wie sie agiert. Im anschließenden Aufgaben-Management wird dann konkretisiert, WAS genau für das Erreichen dieser langfristigen und mittelfristigen Ziele an Aktivitäten geplant und umgesetzt wird. Agiles Produktmanagement mit den Bestandteilen Produktplanung, Product Discovery und Product Delivery lässt sich zu großen Teilen dieser ­WAS-Kategorie zuordnen. OKR-Sets, die in den Alltag von Produktteams integriert sind, machen jederzeit sichtbar WARUM die Teams an Themen arbeiten und eignen sich als Priorisierungsinstrument für alle Entscheidungen, WAS genau im Einzelnen umgesetzt wird. Verbindung von OKR und der Produktplanung Für die langfristige Planung im Produktmanagement geben Unternehmensstrategie (zum Beispiel „Innovationsführer sein“) und die spezifischere Produktstrategie (zum Beispiel „internationale Lernplattform“) Orientierung. Modelle wie das Product Field (siehe Frahm et al. 2015) sind Orte, an denen entsprechende Aspekte festgehalten werden und nächste Schritte für das Erreichen dieser strategischen Ziele identifiziert werden. Typischerweise denken Produktteams für die Umsetzungsideen und Wünsche dabei bereits sowohl an die nächsten Monate als auch an eine noch fernere Zukunft wie das kommende Jahr oder später. Diese Ideen werden dann in einer sogenannten Roadmap gesammelt und in Formaten wie Themes (zum Beispiel „Plattform auch für B2C“) oder auch Epics (noch konkrete Sub-Themen) beschrieben. Stehen zu Beginn eines neuen OKR-Zyklus die aktuellen Unternehmens-OKR-Sets fest, ist es meist notwendig, die vorhandene Sammlung dieser Themes und Epics aus der Roadmap neu zu priorisieren. Produktverantwortliche können sich dabei fragen: „Welche der bekannten Ideen kann wirklich einen Beitrag zu den aktuellen Objectives leisten?“ Themes und Epics die keinen Beitrag erwarten lassen, sollten de-priorisiert werden. Gegebenenfalls entsteht sogar die Notwendigkeit, völlig neue Themes zu erstellen, sollten keine passenden Ideen vorhanden sein. Da auf Teamebene meist nur wenige Themen parallel in einem Quartal umgesetzt werden, können die ausgewählten oder neu erdachten Themes gleichzeitig die Quelle eines oder mehrerer Team-Objectives werden. OKR-Set-Definition für Produktteams und die Roadmap-Aktualisierung gehen somit Hand in Hand. Verbindung von OKR und Product Discovery Bevor ein Produktteam mit der Umsetzung einer konkreten Lösungsidee (zum Beispiel „neue API für Plattformpartner“) starten kann, ist es oftmals empfehlenswert, mittels einer Product Discovery eine weitere Vor-Validierung zu erarbeiten, statt gleich hohe

6  Wirkungsorientiertes Produktmanagement mit OKR

113

Produktionskosten zu generieren. Durch Recherche und Experimente wird in dieser Zeit überprüft, ob die Nutzerprobleme richtig verstanden wurden und eine Lösungsidee sowohl diese Probleme löst, als auch wirtschaftlich und technisch umsetzbar ist. Am Ende einer Discovery wird nochmals entschieden, ob diese Problemstellung ausreichend lohnenswert ist, sie anzugehen und auch, ob die Lösungsideen die dafür am besten geeigneten Möglichkeiten darstellen. Zwei Faktoren zeigen an, dass eine Product Discovery empfehlenswert ist umzusetzen: a) Hohe Unsicherheit über den klaren Nutzer-Problemraum b) Hohe strategische Bedeutung des Themas für die Organisation Ob b) ein Thema eine hohe strategische Bedeutung hat geht sowohl aus der langfristigen Strategie als auch aus den aktuellen Unternehmens-Objectives für das nächste Quartal hervor. OKR-Sets unterstützt an dieser Stelle die Entscheidung, ob eine Discovery überhaupt umzusetzen ist, da sie anzeigen, was für alle als nächstes wichtig ist. In der Durchführung einer Discovery dienen OKR-Sets als Rahmen und Orientierung für die zu erreichenden Ziele. Sie können beispielsweise in die spezifische Auftragsklärung einfließen oder später als Bewertungskriterien der Discovery Ergebnisse herangezogen werden. Ein Ergebnis der Product Discovery sind spezifische Informationen und Messkriterien über Verhaltensveränderungen, die bei Nutzern generell und durch die Lösungsideen zu erwarten sind. Dieses Wissen kann im aktuellen oder folgenden Quartal mit den Key Results verbunden werden. Verbindung von OKR und Product Delivery Werden Themen wie eine neue API umgesetzt (Product Delivery Phase) sind die aktuellen OKR-Sets ebenfalls eine Entscheidungshilfe in vielen Situationen. In der Planungsphase eines Sprints kann durch sie jede User Story oder Aufgabe auf ihr Potential hin überprüft werden, Key Results positiv zu beeinflussen. Das Produktteam kann sich dafür zum Beispiel im Aufgaben-Management-System (z. B. Jira) eine zusätzliche Spalte mit der Bezeichnung „OKR-Sets“ erstellen. Bei der Befüllung der nachstehenden „ToDo“-Spalte mit User Stories kann nun immer das OKR-Set, also das WARUM, mitgedacht werden. Im besten Fall werden nur User Stories oder Aufgaben aufgenommen, die auch eine Wirkung erwarten lassen. In der Praxis gibt es natürlich immer Themen, die keine Wirkung auf das OKR haben werden (Fehleinschätzung), oder die trotz allem erledigt werden müssen. Dies trifft oft auf wichtige und nicht planbare Fehlerbehebungsarbeiten zu oder auch auf Themen, die bei der OKR-Set-Erstellung zu Beginn des Zyklus noch nicht bekannt waren. In diesen Fällen ist OKR wieder primär als „Gesprächsanlass-Instrument“ für Team und Stakeholder zu verstehen, nicht aber als absolute Pflichterfüllung. Gemeinsam kann

114

S. Mewes

besprochen werden, ob eine Ausnahme von großem Nutzen wäre und eine Aufgabe trotzdem erfüllt werden soll oder nicht. Am Ende eines Sprints kann evaluiert werden, ob die erarbeiteten Ergebnisse messbar auf die vereinbarten Key Results eingezahlt haben. Meetingformate wie Sprint Reviews und OKR-Check-ins können daher gut zusammen in einem Meeting erfolgen. Ist die Wirkung nicht innerhalb eines Sprints einschätzbar, da ein Ergebnis erst noch im L ­ ive-Betrieb seine Wirkung in den Folgewochen beweisen muss, können folgende Tipps verfolgt werden: • User Stories bzw. Tasks in noch kleinere, schneller messbare Einheiten „schneiden“ • Ergebnisse vorheriger Sprints erneut in späteren OKR-Check-ins mit betrachten

6.5 OKR-Fallbeispiel Analytico OKR ist keine Methode, die einmal funktioniert und dann immer genau so auszuführen ist. Durch die Eigenschaft eines regelmäßigen Kreislaufes können Organisationen und Produktbereiche Zyklus für Zyklus, beziehungsweise Schritt für Schritt erkennen, was eine erfolgreiche Zielerreichung fördert oder behindert. Diese Beobachtungen können dann wiederum für jeden neuen Zyklus berücksichtigt werden und die Art und Weise des OKRSystems (Summe aller Prozesse rund um die Erstellung und Nutzung von OKR) angepasst werden. Diesen Prozess wollen wir uns am Beispiel von Analytico genauer anschauen. Analytico ist ein Software-as-a-Service-Unternehmen, das von drei Gründern aus der Taufe gehoben wurde und mittlerweile auf 70 Personen angewachsen ist. Analytico hat im Wesentlichen drei Produkte auf dem Markt: ein Analytics-Tool, ein Personalisierungs-Tool und ein AB-Testing-Tool, mit denen beispielsweise Online Shops ihre Software verbessern können. Es ist in die funktionalen Bereiche Marketing, Sales, Customer Care und Produkt/Entwicklung gegliedert. Die Unternehmensvision ist es, das „Lernen in Organisationen durch datengetriebenes Entscheiden zu unterstützen“. Das Gründungsteam, das noch aktiv im Unternehmen arbeitet, machte sich vor der Einführung der OKR-Methode regelmäßig Gedanken wie „Haben wir eigentlich wirklich den richtigen Fokus?“, „Sollten wir wirklich genau diese drei Produkte entwickeln, oder vielleicht doch lieber nur eins und uns dafür richtig drauf fokussieren?“ oder „Wie können wir eigentlich die Zusammenarbeit auch zwischen unseren Funktionen und unseren Teams noch verbessern, damit die Arbeit noch erfolgreicher sein kann?“ Mit diesen Fragen stießen die Gründer auf OKR als eine Ziele-Methode, die Antworten auf ihre Fragen versprach, und sie entschieden sich dazu, diese ab sofort einzusetzen. Sie informierten sich im Internet über OKR und beschlossen, es ähnlich dem Google-Vorbild umzusetzen.

6  Wirkungsorientiertes Produktmanagement mit OKR

115

In einem gemeinsamen Wochenend-Offsite definierten die Gründer ein OKR-Set für das gesamte Unternehmen (siehe Beispiel), das auch allen Bereichen und Teams Orientierung geben sollte. Beispiel

• Objective: Wachstum im nächsten Quartal stabilisieren. • Key Result 1: 100 neue Kunden gewinnen (für Teams: Marketing, Vertrieb). • Key Result 2: Landingpage für Agenturkunden bauen (für Teams: Marketing, Vertrieb). • Key Result 3: Drei neue Feature A, B, C launchen (für Teams: Produkt, Entwicklung). ◄ Weil Analytico zu diesem Zeitpunkt sowieso mehrere neue Arbeitsmethoden im Unternehmen einführte und die Gründer die Teams nicht noch stärker belasten wollten, starteten sie ohne eine weitere Einbeziehung der Teams bei der Definition. Sie stellten das OKR-Set in einem firmenweiten Meeting vor und Quartal eins begann.

6.5.1 Erstes OKR-Quartal bei Analytico Wie ging es den Mitarbeitern mit den vorgegebenen OKR-Sets? Sie hatten nun absolute Klarheit über das Quartalsziel. Diese waren bisher nicht wirklich transparent, denn die Gründer besprachen die Ziele vorwiegend untereinander und kommunizierten diese nicht strukturiert und vollständig an alle Teams. Mit dieser neuen Klarheit kamen gleichzeitig aber auch erste kritische Gedanken zum neuen Vorgehen auf. Die Mitarbeiter fragten sich: „Warum eigentlich genau hundert Kunden?“, „Wie kommt die Zahl zustande?“, „Warum genau drei Features?“, „Warum genau diese?“, „Und warum wurde nicht nach unserem Input gefragt?“. Die fehlende Mitsprache bei den zu erreichenden Zahlen und Themen erzeugte Unmut bei den Mitarbeitern. Die Vorgabe der OKR-Sets reduzierte die Motivation, daran mitzuarbeiten. Zudem war das wertvolle Expertenwissen aus den Teams nicht mit einbezogen worden. Zum Ende des Quartals tauschten sich Gründer und Mitarbeiter über das Gelernte aus. Sie reflektierten darüber, ob das OKR-Set genug Fokus und Orientierung gab. Dabei kamen sie zu dem Ergebnis, dass dies nicht der Fall war, da beispielsweise das Objective „Wachstum stabilisieren“ viel zu generisch formuliert war. Den Gründern wurde bewusst, dass sie bei der Erstellung der OKR-Sets direkt zu viele konkrete Aufgaben in den Key Results formuliert hatten, statt sich auf die Auswahl der wichtigsten Messkriterien zu fokussieren. Das Vorplanen der Aufgaben für ein ganzes Quartal passte überhaupt nicht zum üblichen agilen Arbeitsrhythmus. Gleichzeitig richtete es sich zu sehr auf das Ergebnis aus, ohne weiter zu berücksichtigen, was genau damit eigentlich erreicht werden sollte.

116

S. Mewes

Die Gründer erhielten ferner das Feedback, dass die Mitarbeiter mehr in den Prozess integriert sein wollen, um sich so sinnhaft ins Unternehmen einzubringen.

6.5.2 Zweites OKR-Quartal bei Analytico Im zweiten Quartal passte das Gründungsteam den OKR-Prozess gründlich an. Sie beschäftigten sich nochmals mit Objectives und ihrer Messbarkeit, um von reinen „Umsatzwachstum-ist-unser-Ziel“-Formulierungen Abstand zu bekommen und mehr Inspiration zu bieten. Dazu überprüften die Gründer mit einer strategischen Analyse, welcher der nächste wichtige Bereich/Aspekt war, der mit Hilfe von OKR-Sets konkret verbessert werden sollte. Sie dachten inzwischen weniger in festen Features und Aufgaben für die Key Results, sondern mehr in der Wirkung, die sie erzielen wollten. Darüber hinaus wurden nun Vorschläge für die Bereichs- und Team-OKR-Sets von den Mitarbeitern erstellt, um mit den Inhalten besser verbunden zu sein. Sie durften ebenfalls Feedback zu den Unternehmens-OKR-Sets geben, um so auch auf Unternehmensebene ihr Wissen einzubringen und blinde Flecken zu vermeiden. Es wurde die Rolle von OKR-Experten neu eingeführt, um das Gründungsteam zu entlasten und die Nutzung von OKR in den Bereichen eng zu begleiten und noch mehr Wirkung zu erzielen. Eines von insgesamt 6 OKR-Sets aus dem Produktbereich:

• Objective: Mehr Upgrades aus der kostenlosen Probephase in die Bezahlphase. • Key Result 1: Jeder Probenutzer verwendet 5 kostenpflichtige Funktionen. • Key Result 2: 30 Probenutzer werden in einen kostenpflichtigen Tarif umgewandelt. • Key Result 3: Die aktuelle Conversion-Rate (von Probenutzer in Bezahlnutzer) wird in allen Team-Review-Meetings besprochen. ◄ Die Mitarbeiter waren im zweiten Quartal recht beschäftigt mit dem Voranbringen ihrer oftmals bis zu 6 OKR-Sets pro Team. Das führte dazu, dass sie zwar viele Aufgaben begannen, aber nicht fertig stellten. Da keine Aufgaben mehr in den OKR standen, sondern hauptsächlich Messkriterien die den Zielzustand beschrieben, entstanden neue Fragen wie: „Jetzt wissen wir, was ihr für euer Produkt erreichen wollt, aber was konkret macht ihr eigentlich?“, „In welcher Reihenfolge werden wir uns die Design-Ressourcen aufteilen?“ und „Welche Abhängigkeiten bleiben zu unserem zweiten Produkt bestehen?“. Es entwickelte sich ein großer Bedarf, mehr Klarheit und Abstimmung bei der Feature- und Ressourcenplanung herzustellen, der die Freude an der Nutzung von OKR trübte. Temporär wurde sich mit einem Eintagesworkshop zur Synchronisierung aller hinter den OKR-Sets liegenden Aufgaben und Ressourcenplanungen beholfen.

6  Wirkungsorientiertes Produktmanagement mit OKR

117

Am Quartalsende stellten alle in der Reflektionsphase fest, dass es ihnen noch immer sehr schwerfiel, wirkungsorientiertere OKR-Sets zu definieren. Dafür wurden drei Gründe identifiziert: 1. Grundsätzlich wurde bei Analytico im Alltag wenig mit Kennzahlen gearbeitet, aus denen man sich hätte für Key Results bedienen können. 2. Eine bereits für das gesamte Jahr vorgeplante Roadmap mit konkreten Features gab Ergebnisse vor und erschwerte so das Denken in Wirkung. 3. Die aktuelle Strategie gab wenig Anhaltspunkte und Orientierung für ein Denken in Wirkung und Kundenmehrwert, da sie fast einzig auf monetäre Zusammenhänge ausgerichtet war. Die Gründer erkannten, dass auch über den OKR-Prozess hinaus Änderungen bei Strategie- und Roadmap-Erstellung und Impulse für kennzahlenorientierteres Arbeiten notwendig waren, um in Zukunft noch einfacher und hochwertiger wirkungsvolle ­OKR-Sets zu erarbeiten.

6.5.3 Drittes OKR-Quartal bei Analytico Auch im dritten Quartal wurde der OKR-Prozess daher wieder justiert. Dieses Mal passten als neue Verantwortliche die OKR-Experten in Rücksprache mit den Gründern den Prozess an. Sie entschlossen sich beispielsweise für alle Ebenen (Unternehmen – Bereiche – Teams) die Anzahl der OKR-Sets auf maximal drei zu begrenzen. Um die Abstimmungsintensität bei der Synchronisierung zu reduzieren, die in der funktionalen Struktur entstanden war, erstellten sie nun direkt cross-funktionale OKR-Sets für die Produkte „Analytics-Tool“, „Personalisierungs-Tool“ und ­„AB-Testing-Tool“. Auf diese Weise saßen alle an den jeweiligen Produkten beteiligten Personen aus Marketing/Sales, Product, Design und Entwicklung direkt an einem Tisch und konnten gemeinsam im Sinne des Kundenmehrwertes nächste Schritte planen. Für das Analytics-Tool testete die cross-funktionale Gruppe auch die Umstellung von einer fest vorgeplanten Roadmap auf eine sogenannte Themebased-Roadmap, in der nur Themen der ganz aktuellen Zeit konkreter geplant werden und spätere Themen nur sehr grob. Mit diesem Vorgehen hatten sie mehr Freiraum bei den OKR-Sets tatsächlich in Wirkung zu denken und die Art der Umsetzung durch spezielle Aufgaben und Features noch für die Arbeit in den Sprints offen zu lassen. Für mehr Hintergrundinformationen zu Themebased-Roadmaps siehe Lombardo (2018). Des Weiteren erstellten die OKR-Experten für alle Teams Ideen, wie sie in ihrem Alltag noch bessere Verbindungen zwischen OKR-Sets und den Scrum-Prozessen in den Produktteams und den Kanban-Prozessen im Marketing herstellen konnten, um noch effizienter zu arbeiten. Zum Beispiel wurden die OKR-Sets in alle Scrum-Meetings und

118

S. Mewes

Tools der Aufgabenplanung eingebunden. Überall dort, wo Entscheidungen getroffen wurden („Was mache ich als nächstes?“, „Worauf verwenden wir unsere Zeit?“), waren die Ziele der Organisation so für die Mitarbeiter einfacher sichtbar. Bei jeder Aufgabe hatten sie die OKR-Sets im Blick um sich zu fragen: „Hat diese Aufgabe die Priorität?“, „Ist es das Beste, was mir einfällt, um den definierten Zielen einen Schritt näherzukommen?“ und prüften nach dem Erledigen, ob das Getane wirklich etwas gebracht hatte. Dieses Vorgehen brachte dem gesamten Unternehmen und vielen Mitarbeitern enorme Klarheit und ein Gefühl der Wirksamkeit stellte sich ein. Der Einzelne trug zur Erreichung der Team-Objectives bei. Und die Team-Objectives wiederum zur Erreichung der Objectives der gesamten Organisation. Jeder Mitarbeiter gewann Transparenz, wie er mit seinem Beitrag ein konkretes Ziel unterstützte und etwas bewirkte. Beispiel für ein cross-funktionales OKR-Set für das „Analytics-Tool“ im dritten Quartal:

• Objective: Bestandskunden stärken und Kundenbindung verbessern. • Key Result 1: 50 bis 90 % Vertragsverlängerungsquote. • Key Result 2: Jedes ausgelieferte neue Feature wird von jedem Kunden mindestens einmal verwendet und damit tatsächlich genutzt. • Key Result 3: Aus allen Kunden-Feedbacks die Bewertung exzellent" erhalten. ◄ 

Wie hat die Integration der OKR-Sets praktisch für den Arbeitsalltag bei Analytico ausgesehen? Beispielsweise gab es in jedem Scrum-Ticket ein Pflichtfeld, das abfragte, auf welches OKR-Set das Ticket einzahlt. Wurde ein Ticket benötigt, das auf keines der OKR-Sets einzahlte, konnte die Option „kein OKR-Set“ ausgewählt werden.

6.5.4 Viertes OKR-Quartal bei Analytico Wie ging es Analytico nun nach einem knappen Jahr grundsätzlich? Die OKR-Methode hatte eine deutliche Veränderung bei Analytico angestoßen und sich als Lern-Reise herausgestellt. Dem Unternehmen wurde dank OKR zum ersten Mal so richtig bewusst, wie es um die Zusammenarbeit und den Grad der Zielerreichung bestellt war. Gleichzeitig ermöglichte OKR, die Arbeitsweise hin zu mehr Wirkungsorientierung auf allen Ebenen Schritt für Schritt anzupassen. OKR hat sich für Analytico als ein Instrument für mehr Inspiration, mehr Klarheit, mehr Orientierung, mehr Gesprächsanlässe und mehr Lernen im Unternehmen erwiesen. Die Teams nutzten jetzt OKR als Steuerungsinstrument, um jederzeit selbstverantwortlich Entscheidungen zu treffen oder Aufgaben zu justieren. Manchen Führungskräften fiel es dabei noch schwer, nun nicht mehr wegweisend in die Zielplanung der Teams einzugreifen. Auch die Gründer stellten sich die Frage, wie sie ihre Rolle als Management nun in Zukunft ausgestalten sollten.

6  Wirkungsorientiertes Produktmanagement mit OKR

119

Die bedeutsamste Lernerfahrung war aber die Feststellung, dass Analytico seinen eigenen Weg bei der Nutzung von OKR finden musste. Deshalb war es eine gute Idee, den OKR-Prozess entlang des Weges anders zu gestalten als Google ihn lebt. Analytico hatte verstanden, dass sie eine individuelle Organisation sind, mit ihren eigenen, spezifischen Problemen, und sie deshalb ihren eigenen Weg finden mussten, der sich auch künftig regelmäßig anpassen wird.

6.6 Résumé: Wirksamkeit benötigt aktives Handeln Kommt als Résumé durch OKR automatisch viel mehr Wirksamkeit in Unternehmen und Produktteams? Diese Frage kann nicht pauschal beantwortet werden, denn es kommt schlussendlich drauf an, wie genau OKR gelebt werden und ob aus der Reflektion der Zyklen tatsächlich etwas gelernt und verändert wird. Durch Transparenz, Fokussierung, Fortschrittsbetrachtung und Mitgestaltungsmöglichkeiten schafft OKR für einzelne Mitarbeiter oder für das Team deutlich mehr Wirksamkeit (Abb. 6.4). Sie verstehen durch die OKR-Sets sehr gut, was ihr Beitrag zum großen Ganzen der Organisation ist. Das vermittelt ihnen eine enorme, spürbare Wirksamkeit. In den Arbeitsalltag integriert, ist die Wirksamkeit von OKR sogar noch stärker. Ziele selbst können mit OKR sowohl ergebnisorientiert (Fokus eher auf konkrete Resultate wie „Lern-App ist live“) als auch wirkungsorientiert (Fokus eher auf Verhaltensänderungen wie „mehr Nutzern unterwegs Lernen ermöglichen“, die entweder mit einer App oder ganz anderen Formaten erreicht werden kann) formuliert werden. Zweiterer ist erstrebenswerter, wenn Wirkung in Form von echtem Beitrag zu einer

WIRKUNGSORIENTIERTE ZIELE

Werte/ Normen/ Kultur

Struktur/ Prozesse

Arbeitsweisen/ Tools

Abb. 6.4   Wirkungsebenen von OKR. (Quelle: Eigene Darstellung)

Purpose Mission Vision Strategie

OKR (Ziele)

Aufgabenmanagement

Rollen/ Verantwortung Fähigkeiten/ Weiterentwicklung

Anreize/ Vergütung

120

S. Mewes

gewünschten Verhaltensänderung bei Nutzern verstanden wird. Eine erstellte App kann zwar auch ein Resultat sein, dass auf dem Weg hin zu einer Wirkung nötig ist. Hat man aber nur das Erstellen von Apps per se im Blick und nicht, ob sie auch wirklich den gewünschten Mehrwert für Nutzer bringen, ist es kaum möglich, ein Gefühl von Wirksamkeit herzustellen. Daher hängt es am Ende davon ab, welche Art von OKR-Sets in Unternehmen formuliert wird. Nur die zweite unterstützt ganzheitlich Wirksamkeit. Außerdem sind Ziele (egal ob mit OKR oder anderen Methoden formuliert und verfolgt) immer nur ein Teil der gesamten Organisationsgestaltung, in der viele weitere Elemente eine Rolle spielen: Kultur, Werte, funktionale oder cross-funktionale Strukturen, kennzahlenorientierte Arbeitsweisen, Art der Strategie- und R ­ oadmap-Planung und vieles mehr (siehe verschiedene Kreise der Organisationsgestaltung in Abb. 6.4). Bei all diesen Aspekten sind Grundsteine für die Wirksamkeit einer (Produkt)Organisation zu legen. Was OKR allerdings jederzeit leisten kann, ist, die genannten Punkte in der Organisation als Ganzes sichtbar zu machen so wie es auch Analytico in seiner OKR Nutzung erlebte. So unterstützt die Methode daher Wirkung sowohl durch die Art und Weise der Ziele-Formulierung in Form von OKR-Sets, als auch in ihrer Eigenschaft als Reflektions- und Entwicklungsinstrument.

Literatur Doerr, J. 2018. Measure what matters: How Google, Bono, and the Gates Foundation rock the world with OKRs. München: Penguin. Frahm, K. P., M. Schieben, und W. Wopperer-Beholz. 2015. The product field – Build better products. https://productfield.com. Lombardo, C. T. 2018. Roadmaps are dead! Long live roadmaps. https://www.mindtheproduct. com/roadmaps-are-dead-long-live-roadmaps-by-c-todd-lombardo. Mewes, S. 2018. OKR Workshop – 6 Schritte für mehr Wirkung. https://okr.beautifulfuture.de/okrworkshop-6-schritte.

Die Autorin Sonja Mewes ist Beraterin und Trainerin für Organisations- und Strategieentwicklung, die Bedürfnisse und Erfordernisse von Menschen in den Mittelpunkt stellt und mit den Möglichkeiten neuer Technologien verbindet. Sie hat selbst über zehn Jahre Managementerfahrung in der Digitalbranche bei Konzernen in Transformation (z. B. Gruner+Jahr) wie auch Tech-Start-ups in der Wachstumsphase (z. B. Spryker Systems) gesammelt. Heute begleitet Sonja mit verschiedensten „New Work“ zuzuordnenden Ansätzen Kunden bei der Analyse, Implementierung und Weiterentwicklung ihrer individuellen Organisationssysteme, Strategien und Arbeitsweisen, z. B. im KMU-, Agentur- oder Softwarebereich. Kontakt: [email protected]

7

Product Delivery Richtig gute Produkte effizient entwickeln Tim Adler

Zusammenfassung

Von der Produktidee oder dem neuen digitalen Geschäftsmodell bis zum erfolgreichen Launch muss man als Produktmanager die tatsächliche Produktentwicklung oder „Product Delivery“ managen. Die agilen Projektmanagementmethoden wie SCRUM sind dafür weithin gut etabliert. Allerdings lassen sie auch einige wichtige Fragen unbeantwortet: Wie viel kostet das neue Produkt und wie lange wird die Entwicklung dauern? Wann ist man überhaupt bereit, eine Produktentwicklung zu starten? Warum gehen meine Programmierer immer so pünktlich? Dieser Artikel gibt darauf Antworten und empfiehlt klar, wie sich Produktentwicklung pragmatisch organisieren lässt.

7.1 Los geht’s Ideen für ein neues Produkt sind ein gefährliches Ding: Manchmal scheinen sie so eingängig und einleuchtend, dass man gar nicht versteht, warum die Umsetzung überhaupt ein Problem sein sollte. Deswegen passiert es auch nicht selten, dass die Umsetzung einer Produktidee als „ein teurer Einkauf“ gedacht wird: Man bezahlt eine größere Menge Geld und bekommt am Ende eine neue Fitness-App, eine Webseite für Haustierbedarf oder eine neue Kryptowährung. Die geniale Einfachheit vieler Apps und das große Angebot von digitalen Produkten verstärken den Eindruck, dass der Weg vom fertigen Konzept zum fertigen Produkt nicht so weit sein kann. T. Adler (*)  Greenhouse Innovation Lab, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_7

121

122

T. Adler

Mit „Umsetzung“ ist der Abschnitt einer Produktentwicklung gemeint, in dem das Produkt wirklich entsteht. Ganz einfach zu erkennen ist das übrigens meistens daran, dass irgendwo von jemandem ein Programm-Code produziert wird – regelmäßig, jeden Tag und manchmal unter Ausschluss von Tageslicht. Wenn man schon ein wenig Erfahrung mit der Umsetzung von Produkten hat, dann kann es sein, dass einen die Wahrnehmung von Produktentwicklung als „Einkauf“ irritiert. Man hat dann vielleicht schon eher das Gefühl, dass es sich auch bei kleineren Projekten eher um eine Expedition in etwas ungewisse Gegenden handelt. Manchmal ist auch die Analogie eines Hausbaus passend, denn die Statik eines Hauses soll ja auch dann noch halten, wenn der Dachgiebel aufgesetzt wird. Das alles sind Gründe, warum merkwürdige Situationen in der Umsetzung von Produkten immer wieder auftauchen: Von der Aufwandsschätzung, für deren Grundlage es kaum mehr als einen gesprochenen Satz gibt, bis hin zu so engen Rahmenbedingungen, dass es nur noch ein „Das-muss-aber-so“ gibt, wohin man auch blickt: „Das muss bis Ende des Monats fertig werden.“, „Das muss unbedingt die Apple ­Health-Anbindung und Push-Notifications zum Launch haben.“ und „Ach ja, das darf auf keinen Fall mehr als 10.000 € kosten“. Die im Folgenden beschriebenen Tools werden Ihnen helfen, mit solchen Situationen umzugehen. Mit diesen Tools kann man genauso die Entwicklung eines Marktplatzes für Designer-Mode im Wettlauf mit einem Konkurrenten organisieren, als auch analysieren, ob nach der Rückkehr aus zwei Monaten Elternzeit das Launchdatum einer App in drei bis vier Wochen realistisch ist oder nicht. Die Arbeitsweisen und Tools, die ich hier beschreibe, orientieren sich stark am bekannten Prozess-Framework SCRUM für agile Projekte. Allerdings wird es hier weder eine detaillierte Beschreibung aller in SCRUM enthaltenen Tools und Meetings geben, noch wird die beschriebene Arbeitsweise dem „SCRUM-Dogmatiker“ gefallen – da bin ich mir ziemlich sicher.1 Vielmehr möchte ich Produktmanagern, die das erste Mal vor der Herausforderung stehen, ein Produkt umzusetzen, einen Fahrplan an die Hand geben, mit dem sich gut beginnen lässt. Aber auch Lesern, die schon das eine oder andere Projekt mit SCRUM umgesetzt haben und sich danach vielleicht fragen, wieso man mit SCRUM die Antworten auf manche wichtigen Fragen nur schwer direkt am Anfang eines Projekts geben kann: „Was wird das mal kosten?“ oder „Wie lange dauert das noch?“. Mein Ziel ist es hier, meine Interpretation der agilen Methoden zu beschreiben: So wie ich sie in vielen erfolgreichen Projekten zusammen mit dem Team etabliert und in abgebrochenen Projekten schmerzlich vermisst habe. Ich versuche, damit die Lücken zu füllen, die SCRUM im täglichen „Business“ unbeantwortet lässt und möchte meine Einschätzung teilen, welche Bestandteile der agilen Methoden unverzichtbar sind und wie bestimmte Tools in der Praxis mit kleinen Anpassungen erst so richtig nützlich werden.

1Für

eine detaillierte Darstellung von SCRUM s. Kap. 1 in diesem Buch (Sascha Hoffmann).

7  Product Delivery

123

7.2 Was man braucht, bevor es losgeht 7.2.1 MVP vs. MLP Ausnahmsweise gehen wir an dieser Stelle einmal davon aus, dass schon vorab klar ist, welches Produkt gebaut werden soll. Die Aufs und Abs des User Research und des Prototypings liegen längst hinter uns. Es wurde getestet, verifiziert und auch eine Marke wurde bereits für das neue Produkt entwickelt. Hoffentlich wurden auch schon ein paar Features gestrichen und der Umfang zusammengedampft und so ein Produkt definiert, welches ein erstes rundes Bild für den User ergibt. Ich nenne es an dieser Stelle gerne MVP („Minimum Viable Product“). Da dieser Begriff aber auch gerne für Prototypen während des User Research verwendet wird, können wir auch gerne MLP verwenden („Minimal Launchable Product“). Außerdem transportiert das auch ein bisschen die schöne Nachricht, dass es, wenn es mit Zeit und Geld eng wird, häufig selbst mit weniger Features als im MVP definiert noch ein Produkt gibt, das man launchen kann, ohne sich zu blamieren. Es existiert also eine sehr konkrete Vorstellung davon, was Ihr neues Produkt können soll, auch wenn es noch nicht umfassend für die Umsetzung dokumentiert ist.

7.2.2 Features dokumentieren Als allererstes schreibt man am besten ein ziemlich langweiliges Textdokument über sein neues Produkt. „Oha, ein Lastenheft?“ könnten Sie jetzt fragen und bestimmt wird ein mitlesender agiler Evangelist die Hände über dem Kopf zusammenschlagen. Aber glauben Sie mir: Wenn man so ein Dokument eher als Gliederung oder Mindmap schreibt, dann wird es für alle noch folgenden Schritte sehr nützlich sein. Vor allem aber als Briefing für das Design und die drängenden Fragen nach dem „Wie lange dauert das eigentlich?“ und „Was wird es kosten?“. Optimal für den hier angestrebten Detailgrad sind „Outlining-Tools“, wie OmniOutliner oder Dynalist. Diese Tools sind dafür gemacht, eine Art Mindmap zu den Gedanken zu einem Thema (in diesem Fall Ihr neues Produkt) zu erstellen. Sie benutzen dazu allerdings eine Darstellungsform, die bereits wie ein Dokument aussieht und nicht die übliche Netzform einer Mindmap hat. Versuchen Sie, darin das neue Produkt grob, aber mit möglichst vielen Aspekten zu beschreiben. Denken Sie auch schon drüber nach, welche Dinge im „Frontend“ (also direkt für den User benutzbar) und welche im „Backend“ (z. B. Schnittstellen zu anderen System) geschehen müssen. Spätestens bei der Frage nach notwendigen ­Infrastruktur-Themen (Projekt aufsetzen, Server konfigurieren) sollten Sie über die Liste auch noch einmal einen Entwickler ihres Vertrauens gucken lassen.

124

T. Adler

Abb. 7.1   Produktbeschreibung am Anfang einer Product Delivery. (Quelle: Eigene Darstellung)

Wenn wir hier wirklich ein MLP entwickeln und nicht den nächsten ­SAP-Konkurrenten, dann würde ich sagen, dass dieses Dokument nicht länger als fünf bis acht Seiten sein darf. Sonst haben Sie sich in dieser Phase zu sehr in Details verstrickt, siehe Abb. 7.1.

7.2.3 Erstmal „hübsch“ machen – Design vorbereiten Genau mit diesem Dokument sollten Sie jetzt einen Designer briefen und mit dem ­UI/ UX-Design beginnen – auch wenn die agile Methodik es normalerweise für möglich hält, dies auch im Projektverlauf noch zu entwickeln. Ich glaube es ist gut, eine Farbwelt, Typographie und die groben Navigationsmöglichkeiten eines neuen Produkts vorab

7  Product Delivery

125

entwickelt zu haben. Auf jeden Fall ist es am effizientesten, hier noch mit einem kleinen Team (vielleicht sogar nur Sie als Produktmanager und ein Designer) schnell durch Iterationen des Designs zu gehen und auch schon ein „Go!“ von Ihren Stakeholdern einzusammeln. Insbesondere, wenn es nur ein enges Budget (in Zeit oder Kosten) gibt, macht ein solches Vorgehen Sinn, weil es später unnötige Verzögerungen in der Umsetzung verhindert. Vor allem aber vermeidet es auch die Umsetzung von Features in suboptimaler Form, die so nie gedacht waren, und damit doppelte Arbeit. Ein Design sollte folgende Aspekte des späteren Produkts auf jeden Fall enthalten: • Klick-Flow (s. Abb. 7.2), • Zustände der Screens für „Laden“, „Normal“ und „Fehler“, • Typographie-Klassen. Um den Zugriff für Programmierer später zu erleichtern, ist es gut, wenn man darauf achtet, dass das Design in einem Tool umgesetzt wird, das es erlaubt, Screenshots auch über Klickpfade zu verbinden („Sketch“ und „Adobe XD“ sind gute Beispiele). Am Schluss sollte man das Ganze auch online verfügbar machen (z. B. in Zeplin). Das hat den Vorteil, dass man schnell aus E-Mails und Tickets heraus auf einzelne Screens verlinken kann und es nur eine „führende Quelle“ für das Design gibt. Sonst kann niemand mehr die vielen Dateien auseinanderhalten, die in unterschiedlichen Formen von sich behaupten „_Final_v2_finally“ zu sein.

Abb. 7.2   User Interface-Design mit Klick-Flow. (Quelle: Eigene Darstellung)

126

T. Adler

Abb. 7.3   Beispiel für Typographie-Klassen. (Quelle: Eigene Darstellung)

Für einen weiteren echten Effizienzboost in der Umsetzung, lassen Sie im Design die Typo und Farben standardisieren. Das bedeutet, dass alle Schriften (Größe, Schriftschnitt) insofern vereinheitlicht werden, dass „Klassen“ von Schriften gebildet werden. Warum? Man sollte es vermeiden, sowohl ein paar Worte in 17 px, als auch eine Überschrift in 18 px zu haben. Vielmehr sollte man sich im Design bemühen, schon jetzt die Vereinheitlichung durchzuführen, die in der Programmierung ohnehin später passieren muss. Damit unterstützt man im Design bereits das Bestreben, „saubere“ Programm-Codes zu schreiben und Wiederholungen oder unnötige Details zu vermeiden. Jede nicht als Klasse gedachte Typographie (auch nur 1 px größerer Text) muss sonst von den Programmierern individuell abgebildet werden, siehe Abb. 7.3. Vergessen Sie auch nicht, die Basiszustände eines jeden Screens zu durchdenken: • „Laden“: das ist immer, wenn der Screen noch nicht alle Daten hat und der User noch ein bisschen warten soll. • „Fehler“: glaubt man nicht, kommt aber öfter vor, als Sie hoffen: Irgendwas ist schiefgegangen und das muss man dem User sagen. • „Normal“: das, was Sie eigentlich auf dem Screen tun wollen.

7  Product Delivery

127

Alle diese Zustände wird ein Entwickler später ohnehin abbilden müssen. Deswegen ist es besser, wenn sie im Design vorgedacht werden, anstatt sie dem Zufall zu überlassen. Und schließlich hilft Ihnen als Produktmanager ein gut vorbereiteter Klick-Flow, also der geplante Ablauf beim „Durchklicken“ durch einen User, auch sehr dabei, noch einmal alle Teile des umzusetzenden Produkts zu sehen und sich das Ausmaß der bevorstehenden Aufgabe vor Augen zu führen.

7.3 Vorher wissen, was es kosten wird 7.3.1 Klassisches Projektmanagement FTW Es ist Zeit, mit einem Werkzeug zu arbeiten mit dem schon der Ötzi seinen Lehmofen geplant hat: dem Gantt-Chart. Dieses Präzision vorgaukelnde, Ressourcen zu 50 % verplanende und chronisch nicht mehr der Realität entsprechende Biest ist für eines unglaublich gut: Zeitabschätzungen. SCRUM bietet uns nur einen guten Weg, vorab zu Zeit- und Kostenabschätzungen zu kommen: Schätzungen im Team auf der Basis von großen (und deswegen auch „episch“ genannten) Featureblöcken. Üblicherweise probiert man sich in Schätzgroßen, die T-Shirt-Größen entsprechen (S, M, L, XL). Da zu diesem Zeitpunkt in der Produktumsetzung allerdings kaum Erfahrungswerte hinter den Schätzungen stehen, hat diese Methode den großen Nachteil, dass sie sich nur schwer in Zeit und Geld übersetzen lässt. Meistens wollen die Stakeholder aber vorab wissen, was die Produktentwicklung kosten wird. Deswegen greifen wir also zum Äußersten: Wir planen einen „Wasserfall“. Ein Wasserfall-Projektplan ist ein alternativer Name für Gantt-Charts, die in ihrem Wesen sehr weit von „agil“ entfernt sind (neben „Projektausschüssen“ und „Lastenheft“ natürlich). Trotzdem werden wir es nun verwenden, um unsere Sprints zu planen, und kommen so überraschenderweise zu einer relativ guten Abschätzung von Zeit und Kosten unseres Umsetzungsprojekts.

7.3.2 Eine Idee von Teamgröße Eine Größe, die sich häufig vergleichsweise leicht bestimmen lässt, ist die Besetzung des Produktteams, welches einem für die Umsetzung zur Verfügung stehen soll. Selbst wenn sich die Teamgröße noch ändert, dann lässt sich das zumindest mit einiger Sicherheit voraussehen. Die Idee bei der „Wasserfall-Planung“ ist jetzt eine ganz einfache: Man versucht anhand der Teamgröße abzuschätzen, wie viele Themen man pro Sprint schaffen kann.

128

T. Adler

Als Sprintlänge nehmen wir an dieser Stelle zwei Wochen an (mehr dazu im nächsten Abschnitt). Ein paar einfache Faustregeln für die Schätzung: • Ein Designer kann häufig ein bis zwei Entwickler relativ gut in ihrer Arbeit unterstützen. • Ein Entwickler kann sich pro Sprint mit ein bis zwei unterschiedlichen Themen beschäftigen. • Entwickelt man ein Produkt mit klarer Frontend-/Backend-Unterscheidung (z. B. eine App mit Anbindung eines Backends über eine API), dann braucht man häufig für die ein bis zwei unterschiedlichen Themen pro Sprint einen Frontend-Entwickler und einen Backend-Entwickler. • In einem Team von bis zu drei Personen können Sie die Quality Assurance (QA)/das Testing neuer Features als Produktmanager noch selbst übernehmen. Bei größeren Teams sollten Sie dies einem dezidiert für QA zuständigen separaten Teammitglied überlassen, sonst werden Sie nicht schnell genug Feedback an das Team geben können. Das sind sehr konkrete und zugegeben recht pauschale Faustregeln und es gibt gute Gründe, warum diese in einzelnen Projekten auch nicht hundertprozentig passen könnten. Allerdings haben Sie sich in meinen Projekten häufig als gute Basis für eine Zeit- und Kostenabschätzung herausgestellt.

7.3.3 Zeit- und damit Kostenabschätzung Die groben Faustregeln nutzen wir jetzt und legen die Themen aus unserer Feature-Dokumentation auf einen Zeitstrahl. Beginnen Sie die Planung mit einem „Setup-Sprint“. Es gibt immer haufenweise vorzubereiten – insbesondere, wenn ­ es einen deutlichen Unterschied zwischen Frontend und Backend gibt (z. B. das Repository für Quellcode und seine Anbindung an einen Build-Server/CI, Accounts in ­Third-Party-Tools wie Google/Amazon u. v. m.). Danach legen Sie ein bis zwei Themen pro Sprint aus der Feature-Dokumentation fest, die bearbeitet werden sollen. Im besten Falle arbeiten Sie sich von außen nach innen (d. h. von dem Teil aus, wo Ihr Produkt an Bestehendes anknüpft oder z. B. mit dem Login beginnt) hin zu den spezielleren Features, die bereits auf andere neuen Teilen des neuen Produkts aufbauen. Diese Betrachtung ergibt eine gute Reihenfolge für die Sprints (siehe Abb. 7.4). Wenn Sie mehr als vier bis fünf Sprints geplant haben: Planen Sie auch einen „Post-Launch-Sprint“ mit ein. Auch wenn man jetzt noch nicht genau weiß, was da wohl passieren könnte, gibt es bei der Komplexität des Produkts ganz sicher Fehler zu beheben.

7  Product Delivery

129

App

Registrierung

Bibliothek

Facebook Login

Tracking

Downloads Betriebssystem

Startscreen

Abb. 7.4   Schema zur Feature-Priorität. (Quelle: Eigene Darstellung)

Am Ende sollten Sie also eine schöne Liste von Sprints haben, die aufeinander aufbauen, jeweils zwei Wochen lang sind und damit bereits eine erste Zeitabschätzung für Ihr Produkts ergeben (siehe Abb. 7.5). Da Sie ja bereits auch eine Teambesetzung angenommen haben, können Sie die Zeitschätzung nun relativ einfach in Projektkosten umrechnen. u Projektkosten  = Anzahl Mitarbeiter im Team * durchschn. Tagessatz * Anzahl

Tage pro Sprint * Anzahl Sprints.

Sprint 1

Sprint 2

Sprint 3

Sprint 4

Projekt-Setup Login Registrierung Bibliothek Facebook-Login Tracking

Abb. 7.5   Wasserfall-Planung für Sprints. (Quelle: Eigene Darstellung)

130

T. Adler

Ein wichtiger Tipp für die Kostenabschätzung: Kommunizieren Sie immer ganz klar, dass hier für Sprints gezahlt wird und man nicht das Produkt „kaufen“ kann. Ein „Produktpreis“ kommuniziert die falsche Sicherheit, dass es ganz klar ist, wie aufwändig das Produkt sein wird. Das haben wir zwar abgeschätzt – aber dennoch werden sich Verschiebungen in Themen und Teambesetzung ergeben, die auch einen Sprint mehr oder weniger bedeuten können.

7.3.4 Was tun, wenn es zu teuer oder zu langsam ist? An dieser Stelle gibt es jetzt den unwahrscheinlichen, aber möglichen Fall, dass alles, was Sie bislang als Schätzung vorliegen haben, total ins Budget passt und Sie noch Geld und Zeit für einen Mittagssnack übrig haben. Wahrscheinlicher ist, dass dem nicht so ist und Sie den einen oder anderen Kleinwagen vom Zielbudget entfernt sind. Es gibt dann leider nur zwei Möglichkeiten: Entweder Sie vergrößern das Team mit mehr Entwicklern und schaffen dadurch mehr Themen pro Sprint. Oder Sie lassen Dinge sein. Das Team zu vergrößern ist natürlich nur eine Option, wenn Sie zwar keine Zeit, aber noch Geld übrig haben. Unendlich groß werden kann ein Team allerdings nicht, denn irgendwann stehen sich die Teammitglieder gegenseitig auf den Füßen: • Durch die größere Anzahl an Teammitgliedern kann plötzlich eine größere Notwendigkeit bestehen, sich über die interne Funktionsweise des Produkts auszutauschen, da jeder daran entwickelt und sie gleichzeitig auch nutzen muss. • Frontend-Entwickler warten auf Fortschritte im Backend und können ihre Arbeit nicht abschließen. • Manche Probleme sind schlicht nicht auf mehrere Köpfe verteilbar, z. B. das Erstellen einer Datenbankstruktur oder das Projektsetup. Bei einem Produktteam in der Umsetzung würde ich maximal sechs Personen in der Hochphase empfehlen. Allerdings wird das Potenzial, zu parallelisieren, am Anfang des Projektes schwieriger zu finden sein als mittendrin. Mehr Teams sind natürlich immer möglich, allerdings sollten sie dann auch an klar abgrenzbaren (Teil-)Produkten arbeiten können. Das näherliegende Szenario ist, dass Sie sowohl am Zeit-, als auch am Budget-Ende angekommen sind. Dann bleibt leider nur eines: Wenn es schneller oder günstiger sein soll, muss man Einbußen hinnehmen. Das heißt: Das Produkt wird zum Launch weniger können, als bisher geplant. Hier bleibt nichts Anderes übrig, als sich auf die Suche nach einem Feature-Set zu begeben, welches die dringendsten Anforderungen bereits erfüllt, aber günstiger ist. Ein Beispiel gefällig?

7  Product Delivery

131

Beispiel

In einem App-Relaunch-Projekt, welches eine reine iOS-App durch eine ­Multiplattform-Version (Android und iOS) austauschen sollte, war es dringend nötig, schneller auf allen Plattformen zu sein, als es ein vollständiges Feature-Set erlaubt hätte. Wir haben damals entschieden, die Android-Version in einer minimalen BetaVersion zu launchen und die „alte“ iOS-Version so aufzurüsten, dass sie mit den dafür nötigen Änderungen im Backend klar kam. Die neue iOS-Version haben wir erst später veröffentlicht. Das reduzierte die Komplexität und war auch ein kontrollierbareres Launch-Szenario. ◄ Lassen Sie sich an diesem Punkt nicht davon abbringen, nochmal radikal über die Notwendigkeit von Features nachzudenken. Ein üblicher Trugschluss ist, dass man mit Druck auf die Arbeitszeit der Mitarbeiter schneller und günstiger zum Ergebnis kommen könnte. Das unterliegt der falschen Annahme, dass Zeit und Kosten miteinander nichts zu tun haben. Klar wird dies, wenn man nicht an Festangestellte, sondern an freie Mitarbeiter denkt: Da wird nämlich jede Überstunde extra bezahlt und das Projekt wird vielleicht schneller, aber nicht günstiger. Ein viel wichtigerer Grund gegen die „Druck-Methode“ ist allerdings, dass sich der nötige Druck kaum über einen Zeitraum von mehreren Monaten aufrechterhalten lässt. Das wäre aber häufig nötig, um konstant schneller zu sein. Außerdem ist Druck bei der nötigen Arbeitsweise während der Entwicklung völlig kontraproduktiv: Dort sind Konzentration und die Freiheit, alternative Lösungsansätze auszuprobieren, essentiell. Diese Konzentration lässt sich häufig nur einen regulären Arbeitstag lang aufrechterhalten – danach braucht es eine Pause. Erfahrenen Entwicklern ist das bewusst und das äußert sich häufig in einem stringenten Umgang mit der eigenen Arbeitszeit. Aber man sollte sich generell bewusst sein: Es heißt zwar „Sprint“, aber die Arbeitsweise in der Produktumsetzung entspricht in Summe eher einem „Marathon“ mit einem sehr formalisierten, wiederkehrenden Ablauf.

7.4 Werkzeugkasten einrichten 7.4.1 Noch mehr Vorbereitung, ernsthaft? Sie werden ungeduldig, oder? So langsam könnte es losgehen, oder? Es nervt schon ein wenig, dass ich jetzt den vierten Abschnitt anfange und noch nicht ein Feature ist implementiert, richtig? Dafür verspreche ich Ihnen etwas: Das, was jetzt kommt, ist essentiell für eine effiziente Umsetzung. Wenn Sie es nicht vorbereiten, dann wird es während der Umsetzung „einfach so“ passieren und Sie hatten keine Chance, es zu beeinflussen.

132

T. Adler

Deswegen: Es lohnt sich. Und: Es sind wirklich die letzten Vorbereitungen, die es noch zu erledigen gilt, bevor endlich etwas entwickelt wird.

7.4.2 Einen Namen wählen Das neue Produkt muss einen Namen tragen. Einen richtig guten Namen. Einen, der vom Marketing, Management und vom Kunden gleichermaßen geliebt wird. Allerdings braucht so ein Name häufig Zeit, bis man ihn hat. Manchmal muss man auch lange Runden drehen, bevor er final ist – oder er ändert sich kurz vor Schluss noch einmal. Sie brauchen trotzdem direkt zu Anfang einen internen Namen und zwar einen, der für immer bleibt. Der Kunde und das Management werden ihn niemals zu sehen kriegen. Das Marketing vermutlich schon – sofern es mal Tickets schreiben wird. Dieser Name wird für alles verwendet: vom Repository für den Quellcode, bis zur Konfiguration von Accounts bei Drittanbietern (Sie wollen doch nicht etwa das Zahlungssystem selber coden oder doch?), die für das Produkt benötigt werden. Wählen Sie deswegen einen einfachen Namen und denken Sie nicht zu lange drüber nach. Geben Sie vor allem nicht der Versuchung nach, einen vermeintlich witzigen Namen zu wählen. Aber nehmen Sie auch nicht die Namensidee, die gerade für das Produkt im Raum ist – wenn Sie noch nicht sicher ist, dass sie bleibt. Beispiel

Wenn es eine App für Immobilien wird, dann nennen Sie lieber alles „immobilien_ app“, als „immotep“ (nach dem ägyptischen Pharao). Der Name ist dann der richtige, wenn auch in drei Jahren noch ein neu an Board gekommener Entwickler die „immobilien_app“ einfach von der „hausbesitzer_app“ unterscheiden kann. ◄ Der finale Produktname kann dann immer noch „kurz vor Launch“ eingefügt werden, sodass der User den „internen“ Namen niemals sehen wird.

7.4.3 Backlog vorbereiten Die zwei wichtigsten Werkzeuge, die man als Produktmanager bei der Umsetzung hat, sind das Setzen von „Priorität“ und die möglichst detaillierte Beschreibung von Anforderungen. Das bedeutet nicht unbedingt, dass man viel Prosa aufwenden muss, um etwas zu beschreiben; vielmehr ist das Durchdenken möglichst vieler Szenarien und Spezialfälle für eine Anforderung vorab ein Schlüsselfaktor für eine effiziente Umsetzung. Die Priorität wiederum bestimmt die Reihenfolge der Abarbeitung von Anforderungen.

7  Product Delivery

133

Sie fragen sich jetzt eventuell, was das mit dem Backlog zu tun hat? Nun, um Priorität transparent und konsistent zu definieren, braucht man das Backlog bzw. später das Sprint-Board als Werkzeug. Das Backlog enthält dabei alles, woran aktuell nicht gearbeitet wird. Sie müssen Anforderungen voneinander abgrenzen und priorisieren. Das bedeutet unter anderem auch, dass ein grundlegendes Gesetz bei der Umsetzung gelten sollte: „No Ticket, no Work.“ Insbesondere Änderungen von Anforderungen, die mitten im Prozess auftauchen, geraten in Vergessenheit, wenn sie nicht dokumentiert werden. Anforderungen, die nicht gegenüber anderen priorisiert sind, verursachen Irritationen bei der Auswahl des nächsten To-dos während der Umsetzung. Welches Werkzeug Sie für die Zusammenstellung des Backlogs nutzen, ist vergleichsweise egal. Rechnen Sie allerdings – wie immer – mit der Bequemlichkeit der User Ihres Backlogs und wählen Sie deswegen ein Tool, welches möglichst nah am eigentlichen Code ist. Ich habe bislang gute Erfahrungen mit Trello gemacht und würde seit neuestem alternativ auch Github Projects empfehlen, welches mit seiner Spaltendarstellung und direkten Integration in den Issue Tracker von Github einfach unschlagbar eng verzahnt ist. Wenn Sie mögen – und es schon da ist – nutzen Sie meinetwegen auch Jira. Allerdings finde ich dessen Komplexität meistens viel zu hoch für den Zweck, den es erfüllen soll. Wenn Sie dafür aber die schwierige Diskussion „Dafür haben wir doch schon was“ mit Ihrem Admin nicht führen müssen, dann nutzen Sie es. Für das Backlog müssen Sie jetzt Ihre Feature-Gliederung in Tickets übertragen. SCRUM empfiehlt hier auf ein User Story-Format zu setzen, bei dem Sie Ihre Anforderungen in der Form beschreiben: „Als (Benutzertyp) möchte ich (Funktionsbeschreibung), um (Zweck) zu erreichen.“ Zusätzlich sollten Sie für eine User Story Akzeptanzkriterien mit angeben, ohne deren Umsetzung ein Ticket nicht als abgeschlossen gilt. Das ist auf jeden Fall ein gutes Format und Sie können sich gerne daran halten. Allerdings passieren in der Umsetzung ganz häufig Abwandlungen davon und die klassische User Story passt nicht zu Anforderungen wie „Bugfixing“ oder rein technischen Anforderungen. Wenn man die nämlich als User Story formuliert, dann passieren so Absurditäten wie: „Als registrierter Benutzer möchte ich, dass das Ändern meiner E-Mail-Adresse richtig funktioniert“ oder „Als Entwickler möchte ich, dass wir uns an Coding-Guidelines halten“. Deswegen möchte ich lieber auf die Punkte hinweisen, die Sie in jedem Fall nicht vergessen sollten: Beschreiben Sie in Ihren Tickets/User Stories immer den „Use Case“ bzw. das Wunschszenario, das umgesetzt werden soll, und denken Sie dabei in den Akzeptanzkriterien insbesondere die Spezialfälle durch. Notieren Sie die Akzeptanzkriterien als Checkliste, die man möglichst im Laufe der Entwicklung abhaken kann. Was häufig passiert ist, dass in den Tickets bereits die technologische Implementierung oder der Lösungsweg beschrieben werden. Darauf sollten Sie aber in keinem Fall Ihre Zeit investieren, auch wenn Sie zurecht stolz auf Ihr technologisches Verständnis sind. Denn diese Art der Ticketbeschreibung bricht sofort zusammen, wenn

134

T. Adler

auf dem Weg der Umsetzung nochmal Ausnahmefälle entdeckt werden, die einen völlig anderen Lösungsansatz notwendig machen. Dann ist Ihr Ticket plötzlich nichts mehr wert. Das passiert leider häufiger als man denkt und dann wird bis zur Umsetzung der Anforderung das Ticket häufig nur noch als „Erinnerung“ verwendet und beschreibt leider nichts mehr im Detail. Erinnern Sie sich: Detaillierte Anforderungen sind eines der Hauptwerkzeuge bei der Umsetzung. Deswegen klingt das nun Folgende auch etwas albern. Aber glauben Sie mir, das passiert viel schneller, als Sie denken, wenn Sie Zeitnot haben: Vermeiden Sie es in jedem Fall, die Wörter „alle“ oder „jede“ in ihren Tickets/Stories zu verwenden. Sie lassen damit offensichtliche Lücken in der Feature-Definition entstehen oder verursachen Nachfragen von ihren Entwicklern. Im schlechtesten Fall wird an dieser Stelle einfach „gemacht, was man denkt“ und dann kommt natürlich auch nur in den seltensten Fällen genau das raus, was Sie möchten. Beschreiben Sie vielmehr (wenn auch nur in Stichworten) die Szenarien oder Zustände, die Sie dabei „alle“ im Kopf haben. Es ist sicherlich nicht ganz einfach, einen guten „Granularitätsgrad“ für das Schreiben Ihrer Stories zu wählen. Denn letztendlich müssen Sie sich ja entscheiden, wie Sie Ihre Feature-Gliederung in Tickets überführen. Grundsätzlich würde ich empfehlen, erstmal aus jedem Punkt einer Gliederung ein Ticket zu machen, bei dem es sich nicht um eine Überschrift oder ganz klar eine Detailbeschreibung handelt. Häufig passt es, wenn man einfach die vorletzte Ebene nutzt. Es kommt allerdings hier auch nicht ganz so sehr darauf an, es bereits zu Anfang „richtig zu machen“, denn der folgende SCRUM-Prozess wird schon dafür sorgen, dass die Tickets auf den „richtigen“ Detailgrad runtergebrochen werden. Zusammen mit dem Team werden Sie sich sowieso noch einmal jedes Ticket ansehen, bewerten und nötigenfalls aufteilen. Versuchen Sie also eher, einen breiten thematischen Bereich mit den Tickets und vor allem Tickets für fast die ganze Laufzeit des Projektes vorzubereiten. Nicht, um wirklich schon jedes einzelne Ticket zu haben, sondern eher, um ständig eine Sichtbarkeit darüber zu haben „was noch alles zu tun ist“. Als Strukturierung des Backlogs sollten Sie sich auf wenige Arten von Kategorien beschränken: • „Kommende Sprints“: Tickets, die Sie bereits für einen nächsten Sprint ausgewählt haben. Normalerweise bietet sich an zu wissen, was in den nächsten zwei Sprints stattfinden wird. • „Geschäftszweck“: Strukturieren Sie alle weiteren Tickets nach dem Zweck, dem sie dienen. Also z. B. „Marketing-Optimierung“ für Tracking-Features oder „Effizienterer Kundensupport“ für Backend-Verbesserungen. • „Bugs“: Es wird immer welche geben. • „Produktbereiche“: Wie „User-Profil“, „Registrierung“ oder „Bibliothek“.

7  Product Delivery

135

Next Sprint

Ready for Sprint

Bugs

Markeng

User Story

User Story

User Story

User Story

User Story

User Story

User Story

User Story

...

User Story

Abb. 7.6   Struktur eines Product Backlog nach Geschäftszweck. (Quelle: Eigene Darstellung)

Beim letzten Punkt würde ich die (Unter-)Kategorisierung allerdings nur so lange nutzen, wie die Grundfunktionalität Ihres neuen Produkts noch nicht komplett hergestellt ist bzw. bis Sie ein größeres neues Feature umsetzen. Sobald die grundsätzliche Funktionalität steht, können Sie sich mit der Strukturierung des Backlogs nach „Geschäftszweck“ selber einfacher dazu disziplinieren, immer den unmittelbaren Nutzen im Auge zu behalten. Außerdem liegt das Argument für die Umsetzung einzelner Features für Ihre Stakeholder dann sofort auf der Hand. Ein gutes und nützlich strukturiertes Product Backlog könnte demnach ungefähr so aussehen wie in Abb. 7.6 dargestellt.

7.4.4 Sprint-Board einrichten Ihr wichtigstes Arbeitswerkzeug in der täglichen Arbeit der Produktumsetzung besteht aus dem Sprint-Board, welches wir uns als nächstes ansehen. In diesem Board steht alles drin, woran wirklich aktuell gearbeitet wird. D. h. Sie bestücken zusammen mit dem Team in einem Planungsmeeting dieses Board und innerhalb des Sprints wird (hoffentlich) alles abgearbeitet und es kommt (hoffentlich) nichts dazu. Das Sprint-Board hat am besten die folgenden Spalten, auf die Sie regelmäßig zusammen mit dem Team einen Blick werfen können: • „To-dos“: In dieser Spalte stehen zu Beginn des Sprints alle Tickets. Hier können die Mitglieder des Teams im Laufe des Sprints „neue“ Arbeit finden. Wenn Sie Sorge haben, dass in diesem Sprint ggf. nicht alles Geplante auch geschafft wird: Vergeben Sie auch hier eine Priorität. • „Doing“: Beginnt jemand an einem Ticket zu arbeiten wandert das Ticket in diese Spalte. Achten Sie darauf, dass es hier im Laufe des Sprints keine Karteileichen gibt.

136

•

•

•

•

T. Adler

Es passiert häufiger mal, dass sich pro Person hier zu viele Themen ansammeln und in Wirklichkeit gar nicht an allem gearbeitet wird, was in dieser Spalte steht. „Code Review“: Nach dem Abschluss eines Tickets sollte es auf jeden Fall einen Zwischenschritt für einen Code-Qualitätscheck geben, den Ihre Entwickler gegenseitig durchführen. Diese Spalte sollten Sie nur dann auslassen, wenn es tatsächlich nur einen Entwickler überhaupt oder nur einen Backendler und Frontendler gibt – also Personen, die sich gegenseitig kaum Feedback zum Code geben können. „QA“ (Quality Assurance): Wenn der Code-Review abgeschlossen ist, wechselt ein Ticket in die QA-Spalte. Wenn ein Ticket in die QA-Spalte wechselt, sollte es die Verantwortung der Entwickler sein, dass die Umsetzung des Tickets auch tatsächlich getestet werden kann, d. h. dass es entweder auf einem Testsystem verfügbar ist oder Sie eine Version ihres Produkts auf einem Testgerät installieren und ausprobieren können „Ready for Deploy“: War das Testen erfolgreich, wechseln Tickets in diese Spalte. Sie signalisiert, dass die Änderung oder das Feature auf das Live-System gehen kann. Dies wiederum sollte Verantwortung der Entwickler sein. Sollte Ihr neues Feature ggf. noch in einen Review, z. B. bei einem AppStore, gehen müssen, dann ist diese Spalte auch ein guter Ort, das Ticket abwarten zu lassen. „Done“/„Live“: Hier stehen alle Tickets, die wirklich final abgeschlossen sind.

Da Sie dieses Board in der täglichen Arbeiten immer wieder mit dem Team anschauen werden, macht es Sinn, dass es entweder sehr übersichtlich und einfach per Beamer oder TV groß und für alle sichtbar gezeigt werden kann oder aber direkt physisch irgendwo steht. Ich persönlich konnte bisher keine wirklichen Vorteile von physischen gegenüber virtuellen Boards feststellen, sofern man sich zum Daily tatsächlich „in real life“ trifft. Die virtuelle Variante des Boards hat den Vorteil, dass auf den Tickets „unendlich“ viel Platz ist und sich z. B. Designs und Konzepte einfach verlinken lassen. Deswegen empfehle ich Ihnen eher ein virtuelles Board.

7.5 Marathon laufen 7.5.1 Sprintlänge wählen Am Anfang der Umsetzung und des Aufsetzens der zugehörigen Meetings legen Sie die Sprintlänge final fest. In den vorangegangenen Teilen waren wir bereits von einem Sprint mit einer Länge von zwei Wochen ausgegangen und ich würde ihnen raten, das auch einfach so beizubehalten. Es kann ab und zu Sinn machen, einen Sprint auch länger als zwei Wochen laufen zu lassen. Diese Gründe finden sich aber eher in besonderen Rahmenbedingungen, wie Urlauben, Ausfällen von Teammitgliedern oder der Weihnachtszeit. Aber als Ziel behalten Sie die zwei Wochen im Blick, denn häufig stellt sich bei längeren

7  Product Delivery

137

Zeiträumen irgendwann „Unordnung“ oder zu viel „On Top-Kram“ im Sprint-Board ein und dann ergibt es Sinn, mal einen Schlusspunkt zu finden. Besonders skeptisch sollten Sie gegenüber kürzeren Sprints sein. Ich habe schon mehrfach Produktteams erlebt, in denen es einwöchige Sprints gab. Meiner Erfahrung nach treten sie dann auf, wenn Stakeholder entweder kurzfristige Ergebnisse erwarten oder man dem Team gegenüber skeptisch ist und es enger kontrollieren will. Ich habe allerdings noch nie erlebt, dass es dadurch schneller, besser oder transparenter wurde. Was ich dagegen schon positiv erlebt habe, ist, dass mitten im Sprint gelauncht wurde. Ich würde also dringend empfehlen, der Versuchung aus Druck zu kürzeren Sprint zu wechseln nicht nachzugeben und eher zusätzliche „Launch-Tage“ einzuführen. Im Kern geht es bei dieser Definition der Sprintlänge auch darum, dass man einen Takt bzw. die „Pace“ findet, in der ein ausgewogener Mix aus Overhead/Planungszeit und Arbeitszeit vorhanden ist. Am Ende müssen sich die einzelnen Sprints ja zu einem Marathon zusammenfügen, der ein gewisses Ziel in einer bestimmten Zeit erreicht.

7.5.2 Meetings, Meetings, Meetings… sind der Sprint Eine ganz besonders wichtige Arbeit in der Produktumsetzung liegt in der Durchführung von „guten“ Meetings mit einem klaren Zweck und (häufig kurzen) Follow-ups, die sich aus diesen Meetings ergeben. Die Häufigkeit und der Zweck der Meetings definieren sich über ihre Stelle im Sprint. Alle im nun Folgenden beschriebenen Meetings sind ziemlich genau das, was sich ein SCRUM-Handbuch darunter vorstellt. Deswegen spreche ich den Zweck der Meetings hier nur in aller Kürze an und versuche mich eher darauf zu konzentrieren, auf was man in der Praxis achten muss, um die Meetings wirklich effizient und nützlich zu halten. Grundsätzlich sortieren sich die Meetings, wie in der Abb. 7.7 dargestellt, wie folgt ein: Zu Beginn eines Sprints steht eine Sprintplanung, in der die To-dos des nächsten Sprints zusammengestellt werden. Jeden Tag eines Sprints werden „Dailies“ durchgeführt und zum Abschluss gibt es einen „Review“ mit allen Stakeholdern.

Sprint Anfang

Planning

Ende

Daily

Daily

Daily

Daily

Abb. 7.7   Meetings im Laufe eines Sprints. (Quelle: Eigene Darstellung)

Daily

Review

138

T. Adler

7.5.2.1 Sprintplanung Zu Beginn eines Sprints setzt sich das gesamte Team zusammen, um eine Auswahl von Tickets/User-Stories zusammenzustellen, die im nächsten Sprint umgesetzt werden sollen. Setzen Sie für diese Sprintplanung ein 1,5 bis 2 h dauerndes Meeting an. Normalweise sind Versuche, es in einer Stunde hinzukriegen, zum Scheitern verurteilt – zumindest dann, wenn man ausreichend Zeit für Diskussionen lässt. Teil dieses Meetings ist auch die Schätzung der ausgewählten Tickets. Legen Sie die Sprintplanung möglichst auf einen Tag, der weder der Anfang, noch das Ende der Woche ist. Damit tappen Sie nicht regelmäßig in ein Wochenanfangs- oder -endtief des Teams. Mittwoch ist in der Regel ein guter Tag für einen Sprintstart. Im Kern ist es Ihre Verantwortung, für dieses Meeting so vorbereitet zu sein, dass Sie dem Team eine Auswahl von priorisierten Tickets vorstellen können, die Sie im nächsten Sprint gerne umgesetzt haben möchten. Sollten sich während Ihrer Vorstellung der Tickets Fragen ergeben, insbesondere zum angedachten Umfang der Tickets, dann klären Sie diese. Es kann dabei durchaus passieren, dass sich die Meinung ergibt, dass ein Ticket aufgespalten oder mit anderen Tickets zusammengeführt werden muss. Meiner Erfahrung nach ist es gut, dies direkt in der Sprintplanung zu machen – auch wenn Ihnen dann ab und zu hoch bezahlte Menschen bei der Textverarbeitung zusehen. Dadurch ist aber die Bedeutung des Tickets allen immer klar und es wird später in der Entwicklung nicht versehentlich das Falsche umgesetzt – das wäre dann nämlich erst richtig teuer. 7.5.2.1.1 Schätzung Wenn sich in der Runde des Teams ausreichende Klarheit über das ergeben hat, was das Ticket beschreibt, gehen Sie über zur Schätzung. Die Schätzung soll dem Ticket eine Größenordnung verleihen, aber stellt keine hochexakte Voraussage dar, für die jemand die Hand ins Feuer legen muss. Trotzdem werden Sie die Summe der Schätzungen sowohl für eine Beurteilung, ob der Sprint zu „voll“ ist oder evtl. sogar „noch Platz“ hat, als auch für die Erfassung der tatsächlichen Leistung (Summe der fertig umgesetzten Stories) heranziehen können. Um gar nicht erst den Eindruck einer exakten Schätzung beim Team entstehen zu lassen, verwenden wir gerne die Frage nach der Komplexität als Schätzgröße für ein Ticket. Deswegen gibt es auch keine Zeit als mögliche Schätzgrößen, sondern eine Auswahl von Zahlen (1, 3, 5 und 8). An dieser Stelle sollten Sie immer eine Schätzgröße wählen, die sich einfach zusammenrechnen lässt. Das geht z. B. nicht gut mit ­T-Shirt-Größen s. o. Sie werden später noch sehen, warum. Wichtig ist tatsächlich, dass Sie die Auswahlmöglichkeiten für die Schätzgrößenordnungen beschränken, da sich sonst leicht endlose Diskussionen ergeben, ob das jetzt „eher eine 1 oder eine 2 ist“. Die Schätzung ist übrigens am einfachsten mit SCRUM-Poker-Karten zu erreichen. Das bedeutet, dass Sie ein Kartenset mit den möglichen Schätzgrößenordnungen ans Team verteilen und jedes Teammitglied seine Größenordnung als Schätzung hochhält.

7  Product Delivery

139

Wenn sich krasse Unterschiede ergeben, sollten Sie noch einmal mit dem Team über das Verständnis des Tickets diskutieren. u

Sie wissen mit diesen Zahlen gar nichts anzufangen? Was sollen die überhaupt bedeuten und welche nehmen Sie am besten? Trösten Sie sich, das geht Vielen im Team so, die mit diesen Zahlen schätzen sollen. Deswegen bietet es sich an, zu Beginn eine Referenzstory auszuwählen, die jeder im Team gut versteht und eine Vorstellung der Arbeit hat, die da drinsteckt. Dieser Story geben Sie dann einfach eine erste Zahl, die Sie für passend halten. Wir bemühen uns immer, etwas aus dem Mittelfeld zu nehmen und nicht direkt mit einer 8 zu starten. Sobald mehrere Personen im Team mit den Zahlen arbeiten können, werden neue Teammitglieder schnell eine Vorstellung bekommen, was die Zahlen bedeuten.

Sie können aber auch gerne mit „Zeit“ schätzen, darunter kann sich jeder etwas vorstellen. Allerdings sollten Sie auch hier die Auswahlmöglichkeiten beschränken und z. B. nur 30 min, 2 h, 4 h, 1 T und 3 T anbieten. Das heißt: Wenn etwas voraussichtlich länger als 2 h dauert, dauert es automatisch 4 h. Dieses Konzept zu verstehen, fällt später dann auch nicht ganz leicht – ähnlich, wie bei den Zahlen. Das Schätzen mit Zeit als Messgröße hat noch ein paar weitere Merkwürdigkeiten: • Wenn Sie und Ihr Team bei der Einschätzung von Tickets falsch liegen (und das werden Sie), dann wird es Ihnen komisch vorkommen, wenn Sie ein mit 2 h geschätztes Ticket erst nach 3 T abschließen können. Dem Impuls, die Schätzung nachträglich zu ändern, sollten Sie dann aber in jedem Fall widerstehen. Sie wollen am Ende nämlich lernen, besser zu schätzen, was das inkludiert, dass man falsch liegt. So kommen Sie mit diesen Zahlen zu einer besseren Einschätzung, wie viel in einem Sprint zu schaffen ist – inklusive Ihres eigenen Fehlers beim Schätzen. • Eine Summe aus Komplexitätsgrad-Schätzungen können Sie sehr einfach Ihren Stakeholdern zeigen, ohne großartige Rechtfertigungen auszulösen. Z. B. „Wir haben in den letzten 3 Sprints Tickets in der Größenordnung von 65 Punkten geschafft“. Wenn Sie dies mit Zeitschätzungen tun, z. B. „Wir haben in den letzten 3 Sprints Tickets in der Größenordnung von 7 T 6 h 30 min geschafft“, dann werden Sie in irritierte Gesichter blicken und als nächstes die Frage kassieren, was denn in der ganzen „Freizeit“ passiert ist. 7.5.2.1.2 Nicht abgeschlossene Tickets Es wird nur einen Sprint geben, den Sie mit einem leeren Sprint-Board beginnen – und zwar den ersten. Danach werden sich praktisch immer Tickets auf dem Board finden, die es noch nicht bis in den komplett abgeschlossenen Zustand geschafft haben. Wir verfahren mit diesen Tickets nach einem recht simplen Prinzip:

140

T. Adler

Ist das Ticket so gut wie fertig und wurde sogar schon getestet, dann kann man sich darauf einigen, dass es schon zu den abgeschlossenen zählt. • Gibt es noch QA zu tun, so wandert es in den QA-Status und bekommt die Schätzung, die üblicherweise für die Arbeit in QA benötigt wird. • Muss noch weitere Implementierungsarbeit geleistet werden, so wird eine „Restschätzung“ vorgenommen. D. h. der Ticket-Verantwortliche beschreibt, was noch zu tun ist und dann schätzt das Team die restliche Größenordnung des Tickets. Im letzten Fall kommt es nicht selten vor, dass das Ticket gleichbleibt oder sogar größer wird. Genauso könnten Sie sich aber wundern, wenn das Ticket jetzt kleiner wird, denn plötzlich sind aus dem Sprint ja Punkte verschwunden, die später nirgends erfasst werden. Außerdem wurde ja an dem Ticket bereits gearbeitet aber diese Arbeit findet so nirgends seine Anerkennung. Allerdings ist das Absicht: Wir wollen ja bewusst nur die Tickets erfassen, die tatsächlich geschafft wurden. Am Ende des Sprints helfen halb fertige Tickets niemandem und deswegen werden sie dann auch so behandelt. 7.5.2.1.3 Sprintgröße und Velocity Zwei wichtige Beurteilungs- und Planungsgrößen für Ihre Sprints sind die Größe eines Sprints und die Velocity. Beide stellen denselben Wert dar, nämlich die Summe aller Schätzgrößen (Story Points) in einem Sprint – einmal zu Anfang des Sprints (=Sprintgröße) und am Ende mit Fokus auf allen geschafften Tickets (=Velocity). Beide Werte sollten Sie sich für einen Sprint in einer Liste (ja, das darf ruhig auch Excel sein) notieren und kontinuierlich fortschreiben. Sie bekommen so nach und nach ein Gefühl für die Geschwindigkeit des Teams – also für das, was man pro Sprint schaffen kann. Im direkten Abgleich mit der Sprintgröße haben Sie so einen Indikator, wie viel wohl pro Sprint zu schaffen ist, s. Abb. 7.8. Es ist übrigens gut, wenn Sie zusätzlich zu diesen beiden Werten noch einen dritten Wert erfassen, nämlich die Menge der „On-top-Tickets“. Gemeint sind damit alle Tickets, von denen weder Sie noch das Team zum Zeitpunkt der Sprintplanung wussten und die aus dringender Notwendigkeit im Laufe des Sprints dazugekommen sind. Diese haben zwar keine Schätzung, dürfen aber durchaus als Leistung des Teams erfasst und gewürdigt werden. Wir geben diesen Tickets deswegen anstatt einer Schätzung die Größenordnung „on top“ mit. Übrigens: Sollte ein On-top-Ticket am Ende des Sprints nicht abgeschlossen sein, sollten Sie ihm ganz ordnungsgemäß eine Schätzung verpassen.

7.5.2.2 Daily(-Standup) Dieses kurze tägliche Meeting sollte jeden Tag zur gleichen Zeit stattfinden und nicht länger als 15 min dauern. Jedes Teammitglied, das gerade am Projekt arbeitet, ist aufgefordert, hier ein kurzes Statusupdate darüber zu geben, was sie bzw. er am letzten Tag

7  Product Delivery

141

Story Points

Tatsächlich realisierte Points („Velocity“) Geplante Points („Sprintgröße“)

1

2

3

4

5 Sprints

Abb. 7.8   Sprintgröße- vs. Velocity-Graph. (Quelle: Eigene Darstellung)

gemacht hat und ob es Probleme gibt. Ziel ist es, möglichst schnell Situationen zu lösen, in denen jemand auf etwas wartet oder ein schwerwiegenderes Problem vorliegt, über dessen Lösung es gemeinsam zu entscheiden gilt. Für das Daily öffnen wir üblicherweise nur das Sprint-Board für alle sichtbar und sprechen reihum über die Tickets, an denen gearbeitet wird. Da es immer zur gleichen Zeit stattfindet, ist es üblicherweise auch für Remote-Mitarbeiter einfach zu „besuchen“. Wichtig dabei ist lediglich, dass das verwendete Video-Conferencing-Tool das Übertragen des Bildschirms unterstützt. Der Hauptbildschirm mit dem Sprint-Board und die Video-Conferencing-Software sollten auf Ihrem Rechner laufen, damit Sie ggf. nötige Änderungen an Tickets direkt selbst vornehmen können und diese direkt für alle sichtbar sind. Häufigstes Problem bei Dailies ist, dass sich an einem Implementierungsproblem „festgequatscht“ wird. Das passiert schnell, wenn man tief in Details einsteigt und dabei Lösungen für Probleme diskutiert. Es braucht jemanden in der Runde, der so eine Situation schnell bemerkt und darauf hinweist, dass Lösungsdiskussionen außerhalb des Dailies passieren sollten. Das langweilt weniger Menschen, die nichts mit dem Problem zu tun haben und ist ohnehin effizienter und günstiger. Da das Daily ein Gefahrenort ist, in dem es vergessen werden könnte: Lassen Sie mich den Spruch „No ticket, no work“ noch einmal in Erinnerung rufen: Schnell werden im Daily Dinge gesagt, die man entweder „auch nochmal machen müsste“ oder die ein Detail für ein Ticket sind, welches bisher noch nicht aufgefallen ist. Notieren Sie diese Dinge entweder sofort in ein Ticket (egal ob im Backlog oder auf einem existierenden Ticket), wenn sie wichtig erscheinen, oder lassen Sie das geschehen, was ohnehin das Schicksal jeder nicht notierten Sache im Sprint ist: Vergessen Sie sie sofort wieder.

142

T. Adler

Notieren Sie alles, was Ihnen auch nur ansatzweise als Ticket wichtig erscheint. Und: Versuchen Sie sich an diese Regel zu erinnern, wenn das erste Mal etwas Wichtiges nicht implementiert wurde, obwohl „das doch schon mal gesagt worden ist“.

7.5.2.3 Sprint-Review Zum Abschluss eines jeden Sprints sollte es einen „Sprint-Review“ geben. Dieses Meeting hat insbesondere den Zweck, die Stakeholder und auch den Kundensupport abzuholen und ihnen zu zeigen, was in den letzten zwei Wochen erreicht worden ist. Setzen Sie dafür zum Ende des Sprints dieses ca. 45 min-Meeting an. Auch hier gilt: Nicht am Anfang oder am Ende der Woche. Dienstage sind gut. Die Funktion, Stakeholder über den aktuellen Entwicklungsstand zu informieren, ist nicht zu unterschätzen. Das sollten Sie vor allem dann im Kopf behalten, wenn Sie selbst in Dailies und Plannings täglich erfahren, wie der Fortschritt ist und welche Herausforderungen gemeistert wurden. Die Personen, die man in das Sprint-Review-Meeting einlädt, wissen dagegen normalerweise gar nicht, was die letzten zwei Wochen passiert ist. Meistens haben die Stakeholder auch anderes zu tun, als sich 45 min lang in einen Review zu setzen, aber gerade deswegen sollte man darauf bestehen, dass sie kommen. Es wird sich sonst sicherlich nach spätestens zwei bis drei Sprints das Gefühl bei den Stakeholdern einstellen, dass es kaum vorwärts geht. Oder schlimmer noch: Dass an den Themen, die wirklich wichtig sind (aus Sicht der Stakeholder), nicht gearbeitet wird. Solche Trugschlüsse wieder aus der Welt zu schaffen, ist sehr viel mehr Arbeit, als alle zwei Wochen die Anwesenheit für diese Meetings einzufordern. Und speziell der Kundensupport gewöhnt sich schnell daran, immer wieder das Gleiche zu erklären und bekommt sonst gar nicht mit, wenn ein langwieriges Problem ggf. endlich gelöst ist. Für das Team an sich hat ein Review wieder den schönen Effekt, dass es ein Ziel gibt, auf das hingearbeitet werden kann. Es stellt auch immer ein Kommunikationstool dar, in dem die eigene Arbeit, die ja häufig technisch komplex ist, so einfach und sichtbar für den Kunden dargestellt werden muss, dass sie in einer Demo verständlich wird. Führen Sie einen Review auch in dem Fall durch, dass es wenig zu zeigen gibt. Selbst das hilft, die aufgefallenen Probleme nochmal zu beleuchten und zu erklären, warum Dinge länger dauern. Der Ablauf eines Reviews ist eigentlich denkbar simpel. Sie stellen die Frage „Was haben wir im letzten Sprint geschafft?“ und lassen dann das Team die Ergebnisse der Tickets präsentieren, an denen sie gearbeitet haben. Das muss nicht Ticket-für-Ticket passieren, sondern kann auch für große Themenkomplexe „im Ganzen“ erfolgen. Es sollte allerdings unbedingt das echte Produkt gezeigt und demonstriert werden. Keine PowerPoint-Folien – bzw., nur in seltenen Ausnahmefällen, wenn sich z. B. ein bestimmtes Szenario/Feature schwer in Echtzeit demonstrieren lässt. Besser ist es jedoch immer, wenn sich das Team Zeit nimmt, ein Feature „demonstrierbar“ zu machen.

7  Product Delivery

143

Seien Sie darauf gefasst, dass im Review Kommentare, Anmerkungen und neue Anforderungen aufkommen, die Sie notieren und im Nachgang schärfen und priorisieren müssen. Zum Abschluss des Meetings ist es gut, wenn Sie kurz Ihre Pläne für den nächsten Sprint als „Das werden wir tun“ darlegen. Und am Tag danach sollte es darauf basierend dann die nächste Sprintplanung geben.

7.5.2.4 Retrospektive Ich hatte kurz überlegt, ob ich die „Retrospektive“ einfach ketzerisch auslasse und gar nicht erwähne. Wie schon zu Beginn erwähnt: Ich glaube, so wie SCRUM möchte, dass man die Retrospektive einsetzt, kommt sie definitiv zu häufig und bringt deswegen nichts. Mehr noch: Ich habe zu oft erlebt, dass Teams sich in den Retrospektiven zu Jammerrunden versammeln oder sie ewig in die Länge ziehen. In Retrospektiven soll man eigentlich über den vergangenen Sprint reflektieren und überlegen, wie man Dinge besser machen könnte. Ich würde empfehlen, diese Retrospektiven lieber alle 3 Monate durchzuführen oder wenn man bemerkt, dass es wirklich Probleme im Team gibt. Dann können sie auch wirklich Probleme aufdecken und sich Chancen zur Verbesserung ergeben. Auf einem schnellen und effizienten Weg von der Discovery zum MVP-Launch sehe ich Retrospektiven nicht.

7.5.3 Sind wir noch im Plan…? Je nachdem, wie viele Sprints Sie sich vorgenommen haben, werden Sie sich früher oder später die Frage stellen, ob Sie „noch im Plan“ sind. Oder um es mit den Worten Ihrer Stakeholder zu sagen: „Schaffen wir das zum ?“ und fünf Minuten später „Ne, ehrlich wir müssen das schaffen zum !“ Um diese Frage zu beantworten, können Sie zwei Werkzeuge heranziehen, die Sie in der Vorbereitung bereits angelegt haben: Ihre Sprintgrobplanung aus Abschn. 7.3 und die ­Velocity-Messung aus Abschn.  7.5.2.1.3. Grundsätzlich würde ich Ihnen raten, sich zu keiner Aussage hinreißen zu lassen, solange noch nicht zwei bis drei Sprints ins Land gegangen sind. „Und was ist, wenn ich nur so viele überhaupt geplant habe?“ könnten Sie jetzt fragen. Dann muss man in dieser kurzen Zeit mit der entsprechenden Unsicherheit leben. Warum dieser Zeitraum? Um ein paar mehr Datenpunkte über die tatsächliche Geschwindigkeit des Teams zu gewinnen. Es kann genauso gut sein, dass man den Marathon mit einem Null-Punkte-Sprint beginnt, als auch noch mehr schafft, als man sich zu Beginn vorgenommen hat. Nichts von beidem sollte einen beunruhigen oder übermäßig freuen, denn nur, wenn die mittlere Geschwindigkeit über einen längeren Zeitraum gemessen wird, haben Sie die Chance, wirklich zu erkennen, wie schnell Sie sind. Ausreißer in der Velocity gibt es ständig und sind ganz häufig unvorhersehbar. Die einzige Konstante, die ich bisher erlebt habe, ist ein großer Geschwindigkeitsspike in

144

T. Adler

dem Sprint kurz vor Weihnachten. Bisher konnte ich noch keine Erklärung dafür finden. Vermutlich will man einfach noch einmal schnell alles wegschaffen, um dafür im neuen Jahr quasi keine Arbeit mehr zu haben. Nach dieser Zeit werden Sie einige Velocity-Messungen zur Verfügung haben. Außerdem werden Sie ein Gefühl dafür haben, ob die großen Themenblöcke in der Reihenfolge und Geschwindigkeit abgearbeitet werden können, wie Sie sie geplant hatten. Lassen Sie sich dabei nicht verunsichern, wenn Sie Themen von zukünftigen Sprints nach vorne holen und dafür ggf. Themen weiter nach hinten schieben. Nachdenklich sollte Sie nur stimmen, wenn Sie ausschließlich Dinge nach hinten schieben.

7.5.4 …und falls nicht, wie kommen wir wieder rein? Spätestens zwei Sprints vor Ihrem geplanten Launch-Datum sollten Sie das Gefühl haben, dass der Launch „erreichbar“ ist. D. h. Ihr Produkt hat eine Reife erreicht, bei der Sie das gute Gefühl haben, dass Sie es auf Ihre Kunden loslassen können. Dieses gute Gefühl sollten Sie unbedingt an andere Dinge knüpfen als an Aussagen Ihres Teams: Sie sollten Zwischenstände Ihres Produkts bereits ausprobiert und für gut befunden haben. Sollten zu diesem Zeitpunkt noch Bugs oder Teile der Funktionalität nicht existieren ist das so lange ok, wie Sie anhand der Velocity und Sprintgrobplanung erkennen können, dass Sie diese Themen noch schaffen, zu erledigen. u

Leider habe ich schon öfter Situationen erlebt, wo man sich auch zu diesem Zeitpunkt lediglich auf Aussagen von Entwicklern oder schlimmer noch „das Nicken“ von Entwicklern verlassen hat. Noch mal: Das alleine reicht hier leider nicht. Sie brauchen etwas zum Anfassen.

Haben Sie bereits vor diesem Zeitpunkt das Gefühl, dass Ihr Team mehr Geschwindigkeit vertragen könnte? Dann gibt es dafür ein einfaches aber teures Tool: mehr Mitarbeiter. Leider gibt es wenig Alternativen, sofern Ihre Tickets entsprechend gut vorbereitet sind. Ihr Team wird nicht plötzlich „ohne Grund“ schneller fertig werden mit Dingen, die in der Vergangenheit auch länger gedauert haben. Insbesondere aufseiten der Entwickler können Sie häufig – bis zu einem gewissen Grad – aufstocken, um schneller zu werden. Auch hier würde ich raten, sich zwei Sprints Zeit zu lassen, um zu ermessen, ob mehr Personal wirklich zu einem Geschwindigkeitsgewinn geführt hat. Im ersten Sprint kann zu viel Aufwand mit „Onboarding“ verbracht worden sein. Die einzige weitere Möglichkeit, die Sie haben, um schneller zu werden, ist lediglich das „Weglassen“. Versuchen Sie bitte nicht mit Ihrem Team zu verhandeln, ob man „noch mehr schaffen kann“: Letztlich ist es die Verantwortung des ganzen Teams, ein Gefühl für die mögliche Geschwindigkeit zu bekommen. Sie gehören dazu.

7  Product Delivery

145

Wenn es also nicht möglich ist, mehr Teammitglieder an Bord zu holen (üblicherweise ist bei sechs Entwicklern irgendwann Schluss), dann versuchen Sie, noch einmal über das Featureset zum Launch nachzudenken. Lassen Sie Dinge weg, die nicht wirklich essentiell sind. Denken Sie dabei auch immer dran: Es ist durchaus möglich und heute sogar üblich, dass man neue Produkte erstmal als „beta“ launcht und dann nachliefert.

7.6 Kleine Helferlein im Alltag Nachdem Sie auf diese Weise hoffentlich erfolgreich (und darunter fasse ich auch alle Abstriche, Mehrkosten und emotionalen Meetings, die Ihnen auf dem Weg begegnet sind) Ihr Produkt an den Kunden gebracht haben, möchte ich noch zwei Themen beleuchten, mit denen zwei Personengruppen während der Arbeit an Ihrem Produkt, auf Sie zukommen werden.

7.6.1 Entwickler schreien „Refactoring!“ Das Thema „Refactoring“ ist für Sie als Produktmanager nur schwer zu beurteilen, weil Sie eben nicht jeden Tag mit dem Code arbeiten und die dort vergrabenen Leichen sehen können. Das einzige, was Sie überhaupt wahrnehmen können, sind die Wünsche und Aussagen Ihres Teams, „wie schlimm der Code“ aussieht und „dass man das mal neu machen müsste“. Ich möchte Ihnen empfehlen, sowohl auf die Aussagen des Teams zu hören, als auch auf ein Phänomen zu achten, dass Sie selbst in Ihrem Produkt beobachten können: Treten bei der Umsetzung von neuen Features regelmäßig Probleme auf, die vorher niemand vermutet hätte? Zum Beispiel: Geht beim Einbau eines Facebook-Logins plötzlich die Möglichkeit, die E-Mail-Adresse zu ändern, kaputt? Damit meine ich nicht, dass man an diesem Punkt während des Sprints ggf. Anpassungen vornehmen musste, weil es sonst nicht mehr funktioniert hätte. Es geht zu diesem Zeitpunkt vielmehr darum zu sehen, ob das Team diesen Umstand bemerkt und behoben hat. Sollte das Phänomen der „Nebenwirkungen“ von neuen Features vermehrt auftreten und es auch das eine oder andere Mal in Ihr finales Produkt geschafft haben, dann spricht dies dafür, dass das Team nur noch schwer den Überblick über die Komplexität des Produkts behalten kann. Zu solchen Zeitpunkten lohnt es sich, verstärkt ins „Refactoring“ zu investieren und danach ein Auge darauf zu haben, ob sich dieses Phänomen reduziert. Genauso können diese Nebenwirkungen allerdings auch darauf hinweisen, dass Ihrem Produkt „automatisierte Tests“ fehlen. Ich hoffe, dass so mittlerweile nicht mehr entwickelt wird, aber vorkommen kann das immer wieder. Deswegen sollten Sie diese Frage noch einmal mit dem Team abgleichen, bevor Sie sich aufs „Refactoring“ stürzen.

146

T. Adler

Die Arbeit in „automatisierte Tests“ zu investieren, erleichtert nämlich auch die QA, weil Standardfälle dann künftig einfach „von alleine“ getestet werden.

7.6.2 Kundensupport schreit „Bugs!“ Wenn Ihr neues Produkt gelauncht wurde und in die Hände der Kunden gelangt ist, dann ist eines gewiss: Bugs (Fehler) gibt es immer. Egal ob kleine optische Unschönheiten oder schwierig zu reproduzierende Abstürze, die kein Entwickler zuverlässig nachstellen kann. Spätestens, wenn diese Probleme im Kundensupport auftauchen, wird die Frage kommen: Wie priorisieren Sie Bugs, die Ihnen in „freier Wildbahn“ begegnen? Jeder Bug wird immer sehr wichtig erscheinen, wenn er nur bei den richtigen Personen oder Stakeholdern auftaucht. Sie sollten deshalb versuchen, Bugs ähnlich einzuschätzen, wie Sie die Wirtschaftlichkeit von neuen Features für Ihr Produkt einschätzen. Allerdings versuchen Sie bei Bugs nicht, den möglichen Gewinn für Ihre KPI einzuschätzen, sondern die Menge der betroffenen User. Dies lässt sich über persönlichen Kontakt oder Beobachtung kaum gewährleisten. Sie brauchen einen Exception- und Stabilitätstracker, der dies automatisiert im Auge behält. Mögliche Tools hierfür sind z. B. Bugsnag, Rollbar oder Honeybadger. Diese Tools erfassen für Sie und Ihr Team alle auftretenden Abstürze und Fehler, die dem User begegnen. Sie können außerdem sogar absichtlich „Fehler“ bei diesen Tools erfassen, um z. B. Zahlungsabbrüche, die zwar regulär auftreten können, aber deren Häufigkeit Sie gerne kennen würden, zu erfassen. Die Tools fassen Fehler zu Fehlertypen zusammen und messen deren Häufigkeit und die Umstände, unter denen sie beim Kunden aufgetreten sind. Eine solche Aufschlüsselung hilft Ihnen, die tatsächliche Häufigkeit von Fehlern besser einzuschätzen. Priorisieren Sie die Fehler, die hier vermehrt auftreten. Behalten Sie allerdings im Kopf, dass diese Exception-Tracker nach einer Zeit des Live-Betriebs immer voll sind mit Meldungen. Einen absturz- oder fehlerfreien Betrieb gibt es einfach nicht und es ist weder erstrebenswert und insbesondere nicht effizient zu versuchen, jeden Fehler zu beheben. Der Autor Tim Adler  ist Managing Director in einem Innovation Lab in Hamburg. Zuvor arbeitete er als CTO in einem Company Builder. Dort baute er eine große Zahl von Startups erfolgreich mit auf. Als Projektleiter begleitete er außerdem größere Restrukturierungsmaßnahmen im Digitalbereich eines großen deutschen Verlages und brachte als Produktmanager die erste Ausgabe eines großen deutschen Nachrichtenmagazins aufs iPad. Er bildete sowohl Produktmanager aus, beriet TopManager und schrieb als Lead-Entwickler verschiedener Projekte viele hunderte Code-Zeilen. Dieser Beitrag versucht, die Erfahrungen aus den agilen Entwicklungsprojekten dieser Zeit zu dokumentieren und Empfehlungen zu geben, wie man am effizientesten zum Ergebnis kommt. Kontakt: [email protected]

8

Lateral Leadership im Produktmanagement Überzeugen und Führen ohne Titel Tim Herbig

Zusammenfassung

In diesem Artikel erhalten Produktmanager – aber auch alle anderen Personen mit lateraler Führungsverantwortung – Methoden an die Hand, die ihnen dabei helfen, ihre laterale Führungsrolle effektiv zu füllen. Um dies umzusetzen, beschäftigt sich der Autor zunächst mit bestehenden Irrtümern beim Verständnis lateraler Führung; er beschreibt, wie Autonomie erreicht werden kann und welche Rolle Alignment dabei einnimmt. Zudem werden das Mission Briefing nach Bungay eingeführt und es wird sich mit der zentralen Bedeutung von Empathie im eigenen Team auseinandergesetzt.

8.1 Das Missverständnis Als ich zum ersten Mal in meiner Karriere in einem Lateral-Leadership-Training saß und die Definition des Begriffs hörte, war ich glücklich. Endlich konnte ich meine tägliche Herausforderung als Produktmanager in einem agilen Team mit einem Namen greifen und beschreiben. Denn auch wenn eine Stellenbeschreibung als Produktmanager das Wort „Führung“ vielleicht nicht explizit enthält, so ist es doch eine implizite Erwartung an diese Rolle. Das Problem mit impliziten Erwartungen ist, dass sie einen oft erst spät im Berufsalltag einholen. Im Bewerbungsgespräch drehte sich noch alles um Roadmaps, Product Discovery und Scrum Sprints. Aber plötzlich wird man „nebenbei“ im Alltag mit einer Führungsverantwortung für Kollegen konfrontiert, auf die man nicht vorbereitet wurde. T. Herbig (*)  Erfurt, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_8

147

148

T. Herbig

In den meisten Firmen wird Führung über den Jobtitel oder die Stellenbeschreibung definiert. Kollegen mit einem „Head of“, „Director“ oder „Teamleiter“ im Titel dürfen anderen sagen, was sie zu machen haben… Soweit zumindest das traditionelle, allgemeine Verständnis. Aber in immer agiler werdenden Organisationsformen finden sich auch zunehmend Personen, denen formale Autorität weder über die Stellenbeschreibung, noch das Organigramm zugeschrieben ist. Um auch aus dieser Position heraus effektiv Kollegen davon überzeugen zu können, etwas Bestimmtes zu tun, ist ein klares Verständnis von lateraler Führung notwendig. In diesem Artikel bekommen Produktmanager – aber auch alle anderen Rollen mit lateraler Führungsverantwortung – Methoden an die Hand, die ihnen dabei helfen, ihre laterale Führungsrolle effektiv zu füllen.

8.2 Das emotionale Vakuum agiler Prozesse Als Generalist, der man als Produktmanager nun einmal ist, muss man häufig mit ziemlich smarten Fachexperten aus den Bereich Tech, User Experience (UX) oder Marketing zusammenarbeiten und diese von den eigenen Ideen überzeugen. Genau diese Art crossfunktionaler Zusammenarbeit in selbst organisierten Teams ist eine der stärksten Ursprungsideen hinter dem Begriff „Agilität“ (Gothelf 2015). Über die Jahre haben sich allerlei Frameworks und Prozesse auf dieser Grundidee entwickelt. Und mit Scrum, einem der prominentesten Frameworks, bekommt man auch allerhand Ideen für die genauere Gestaltung der Zusammenarbeit an die Hand. Aber vergessen wir nicht etwas, wenn wir Prozesse adaptieren, die uns dabei helfen sollen, selbst organisierte Teams zu bilden? Ich beobachte häufig Folgendes: Entlang des Weges wird die Notwendigkeit einer anderen Haltung zum gegenseitigen Umgang und der Führung untereinander vergessen. Wenn wir für einen Moment auf die zugrunde liegenden Prinzipien agiler Arbeitsweisen zurückschauen, erkennen wir: Agilität hat schon immer bei den Leuten im eigenen Team angefangen. Es ging nie um Velocity Charts, Story Points oder darum, den Sprint pünktlich zu starten. Daher sollten die Mitglieder eines agilen Teams immer die oberste Priorität für Produktmanager haben. Und dafür braucht man weder eine hierarchische Weisungsbefugnis per Stellenbeschreibung, noch die Erlaubnis der HR-Abteilung. Doch wie genau kann man wirksame Führung als Produktmanager ohne formale Autorität angehen? Sicherlich nicht mit dem strikteren Verfassen von Anforderungen, mehr Scrum-Meetings oder veralteten hierarchischen Verhaltensweisen wie Abmahnungen oder Anschreien. Der Schlüssel liegt in der Kombination von zwei Dingen: Zum einen durch die Herstellung des gleichen Verständnisses auf allen Ebenen über das Warum hinter einem

8  Lateral Leadership im Produktmanagement

Alignment

149

Empathie

Lateral Leadership

Abb. 8.1   Lateral Leadership. (Quelle: Eigene Darstellung)

Produkt. Und zum anderen durch gelebte Empathie für die Teammitglieder (vgl. Abb. 8.1).

8.3 Autonomie durch Alignment herstellen Weder das Einhalten von vorgegebenen Prozessen, noch vordefinierte Rollenverteilungen führen zu der Freiheit, die sich viele Teams für ihre Arbeit wünschen. Dabei geht es aber nicht nur um die Unabhängigkeit von den hierarchischen Ebenen im Unternehmen, sondern auch für jedes Teammitglied selbst. Selbst wenn alle gemeinsam an der Lösung des gleichen Problems arbeiten, so hat doch jedes Teammitglied einen einzigartigen Vorteil, der ihn oder sie für die Arbeit an einem Teilbereich prädestiniert. Leider haben wir jedoch oft den Drang in uns, Unsicherheit oder Unverständnis für die Arbeit von Kollegen mit mehr Kontrolle begegnen zu wollen. Das gilt sowohl für das Senior Management in Zusammenarbeit mit Teams im ganzen Unternehmen, als auch für Generalisten wie Produktmanager im Zusammenspiel mit Entwicklern oder Designern. Allerdings ist mehr Kontrolle und Einblick ins Detail das Letzte, was qualifizierte Kollegen von Produktmanagern brauchen, um ihren Job zu erledigen. Vielmehr geht es darum, auf einer übergeordneten Ebene und in einer gemeinsamen Sprache Klarheit über das Warum hinter einer bevorstehenden Aufgabe herzustellen. Sobald das erreicht ist, kann jeder seines Weges gehen und braucht sich durch das geschaffene Alignment keinen Kopf um die Details zu machen. Der Strategieberater Stephen Bungay nutzt dafür in seinem Buch „The Art of Action“ (Bungay 2010) eine Analogie aus dem Militär: Durch die verschiedenen Rollenverteilungen gehen dort auch nicht alle Soldaten ins Feld. Einige unterstützten von der Basis aus, während andere die Mission operativ ausüben. Damit im Falle von z. B. abbrechender Kommunikation trotzdem die Mission ein Erfolg wird, muss vor dem Start der Mission allen Beteiligten das verfolgte Ziel klar sein und es müssen ihnen die richtigen Entscheidungshilfen an die Hand gegeben werden.

150

T. Herbig

Selbst als ehemaliger Zivildienstleistender konnte ich mich schnell mit dem Konzept arrangieren und sehe Klarheit über die Rahmenbedingungen eines Projekts als eines der wichtigsten Tools für Führung ohne formale Autorität.

8.4 Das Mission Briefing Für das Herstellen von Alignment gibt es mittlerweile sehr viele Frameworks und Formate (siehe auch Kap. 5 „Alignment als Kernkompetenz für Produktmanager“ von Arne Kittler). Nach einigem Ausprobieren ist das – hier leicht angepasste – Mission Briefing nach Bungay (2010) immer noch mein Favorit. Es besteht aus 5 Abschnitten und wird idealerweise gemeinsam und iterativ im Team erarbeitet, um ein sog. Buy-In, also die Zustimmung für die Umsetzung, für den Inhalt zu erreichen: • The Context – Hier werden die aktuelle Marktsituation, die Entwicklungen des eigenen Produkts sowie das Problem beschrieben. Ziel ist es, den Anlass des Handelns klar zu machen. • Higher Intent – In diesem Abschnitt sollte sich die übergreifende Firmenstrategie und ihre Beziehung zum konkreten Vorhaben wiederfinden. Hilfreicher Input hierfür ist z. B. ein Zitat des CEO. • Our Intent – Nun geht es um das Vorhaben des Teams. Was soll auf einer Wirkungsebene für die Nutzer bzw. die Firma erreicht werden und wann wissen wir, dass wir Erfolg hatten? • Key Implied Tasks – Statt dem Verfassen einer Schritt-für-Schritt-Anleitung darüber, was zu tun ist, sollte das Team die nächsten Herausforderungen zusammenfassen. Was sind die größten Unbekannten? Wer muss mit eingebunden werden? • Boundaries – Für eine echte Freiheit gilt es schließlich, gemeinsam zu beschließen, was nicht im Rahmen der kommenden Arbeit passieren soll. Beispielsweise explizit ausgeschlossene Features oder Metriken, die sich nicht als „Nebeneffekt“ verschlechtern dürfen. u

Beim Erarbeiten des Mission Briefing ist vor allem die Zusammenarbeit im Team wichtig. Ihr solltet erst Klarheit über jeden einzelnen Abschnitt haben, bevor Ihr weiterarbeitet.

Das gemeinsame Erarbeiten könnte z. B. so aussehen (Abb. 8.2): • Zunächst widmet man sich gemeinsam dem Abschnitt „The Context“. Vielleicht existieren sogar schon Beispiele aus anderen Mission Briefings, die für alle sichtbar gemacht werden können. • In einer Timebox von 5 min schreibt jedes Teammitglied so viele passende Sticky Notes für den Abschnitt zusammen, wie möglich. • Der Input wird gegenseitig vorgestellt und Rückfragen werden geklärt.

8  Lateral Leadership im Produktmanagement

151

Abb. 8.2   Mission Briefing, Beispielprojekt Icarus. (Quelle: Herbig 2018)

• Anschließend werden ähnliche Inhalte zusammengefasst und Duplikate entfernt. • Sollten am Ende mehr als 4 Sticky Notes übrig sein, macht eine kurze Voting Session mittels Punkten Sinn. Hierbei bekommt jedes Teammitglied Punkte zum Voten für einen Inhalt. • Eine Orientierung für die Anzahl der zu vergebenden Punkte kann sein: Anzahl der zur Auswahl stehenden Elemente geteilt durch 2. • Anschließend werden die „Gewinner“ in eine stimmige Reihenfolge gebracht, sodass eine Story entsteht. • Danach widmet sich das Team dem nächsten Abschnitt. • Zum Abschluss sollte noch einmal durch das ganze Mission Briefing gegangen werden, um etwaige Unstimmigkeiten auszuräumen. Die größte Gefahr innerhalb eines Alignment-Prozesses ist die falsche Wahrnehmung, Alignment mit Zustimmung gleichzusetzen. Es geht nicht darum, jeden glücklich zu

152

T. Herbig

machen. Vielmehr geht es um die Bestätigung der Bereitschaft, einen gemeinsamen Weg auszuprobieren. u

Jeff Bezos (2017) fasste das Ziel eines Alignment-Prozesses in einem seiner berühmten Shareholder Letter exzellent zusammen: „Third, use the phrase „disagree and commit.“ This phrase will save a lot of time. If you have conviction on a particular direction even though there’s no consensus, it’s helpful to say, „Look, I know we disagree on this but will you gamble with me on it? Disagree and commit?“ By the time you’re at this point, no one can know the answer for sure, and you’ll probably get a quick yes. This isn’t one way. If you’re the boss, you should do this too.“

8.5 Empathie als Schlüsselelement Am Anfang des Artikels habe ich über die Bedeutung von zwischenmenschlichen Beziehungen in der agilen Zusammenarbeit gesprochen. Oft hat man nicht nur einmal im Quartal oder alle 2 Wochen während des Retro-Meetings Bedenken. Vielmehr trägt man jeden Tag Bedenken bzgl. der eigenen Arbeit und Umgebung mit sich herum. Sei es z. B. aufgrund fehlender zwischenmenschlicher Anerkennung oder dem Wunsch nach mehr organisatorischer Flexibilität. Und so geht es auch jedem Teammitglied, mit dem man jeden Tag zusammenarbeitet. Alle tragen Bedenken über prozessuale oder inhaltliche Aspekte der Zusammenarbeit mit sich herum und haben nur selten die Gelegenheit, diesen Bedenken Gehör zu verschaffen. Der Grund dafür ist, dass Empathie vor allem in der hierarchischen Führung erst langsam an Bedeutung gewinnt. Als laterale Führungskraft, die auf Augenhöhe mit einem Team zusammenarbeitet, hat man aber die Chance einen Unterschied zu machen. Durch das Anerkennen der individuellen Bedürfnisse der Teammitglieder verbessert man nicht nur die langfristige Beziehung zu den Kollegen, sondern man kann auch einen positiven Einfluss auf die gemeinsame Effektivität als selbst organisiertes Kollektiv feststellen. Empathische Beziehungen sollten allerdings nicht nur zwischen Produktmanagern und einzelnen Teammitgliedern entstehen, sondern im gesamten Team etabliert werden. Hierfür habe ich das Agile Peer Canvas entwickelt, das eine ganzheitliche Betrachtung von Kollegen über ihre Stellenbeschreibung hinaus ermöglicht (Abb. 8.3). Das Canvas besteht aus 7 Bereichen, die wie folgt zu verstehen sind: • Mission: Was ist die Essenz der Person in einem Satz zusammengefasst? • Dos: Welche expliziten Tätigkeiten fallen in den Verantwortungsbereich der Person? • Don’ts: Aus welchen Themen sollte sich die Person klar heraushalten?

8  Lateral Leadership im Produktmanagement

153

Abb. 8.3   Agile Peer Canvas. (Quelle: Herbig 2018)

• Hopes: Was sind die individuellen Erwartungen daran, etwas aus der eigenen Position im Unternehmen zu machen? • Fears: Was hält denjenigen oder diejenige täglich davon ab? • Drivers und Motivators: Welche inneren Motive treiben die Person tagtäglich an? • Informal Role: Welche Aufgaben innerhalb des Teams übernimmt die Person über ihre offizielle Stellenbeschreibung hinaus? Das Canvas lässt sich am effektivsten in einer gemeinsamen Session des Teams einsetzen. Jeder hat die Zeit, die einzelnen Felder für sich auszufüllen (Abb. 8.4), bevor man sie anschließend mit allen Teilnehmern im Raum teilt. Durch das Feedback der Kollegen kann man so wertvolles Feedback zur Fremdwahrnehmung sammeln und die Perspektive der anderen Teammitglieder in das eigene Handeln einfließen lassen. Erfahrungsgemäß wirkt das Agile Peer Canvas am besten, wenn sich ein Team gerade frisch verändert hat oder einen grundlegenden Change-Prozess durchläuft. Häufig muss man als Produktmanager den Stein ins Rollen bringen und sich als erstes mit dem eigenen ausgefüllten Canvas gegenüber den Kollegen öffnen. Doch diese Offenheit wird in den meisten Fällen mit tollem Feedback und einer nachhaltigen Stärkung des Zusammenhalts im Team belohnt. Für mehr Infos zum Hintergrund und der Anwendung des Agile Peer Canvas siehe Herbig (2018) bzw. https://herbig.co/lateral-leadershipbook/#agilepeercanvas.

154

T. Herbig

Abb. 8.4   Exemplarisch ausgefülltes Agile Peer Canvas. (Quelle: Herbig 2018)

8.6 Abschließende Gedanken Der wichtigste Schritt auf dem Weg zum effektiven Führen als Produktmanager liegt im Annehmen der eigenen Führungsrolle auch ohne formale Autorität. Je nachdem, in welchem Arbeitsumfeld man sich bewegt, sollte man unterschiedliche Schwerpunkte legen. In den meisten Konzernumfeldern stellen Abhängigkeiten und Hierarchien die größten Herausforderungen für Produktteams dar. Daher sollte hier der Fokus auf Klarheit über das Alignment liegen, damit ein Team selbstbestimmt agieren kann. In Start-ups erfolgt hingegen das inhaltliche Alignment aufgrund von kleineren Teamgrößen fast „automatisch“, weshalb hier zunächst an gegenseitiger Wertschätzung und Empathie gearbeitet werden sollte. Sowohl für die Arbeit an mehr inhaltlichem Alignment, als auch für ein gemeinsames Verständnis für die Herausforderungen des Einzelnen gilt, dass das Erarbeiten und Teilen im Team entscheidend ist. Wenn nur der Produktmanager die Zielsetzung mit dem Senior Management abstimmt oder alleine über die Bedürfnisse der Teammitglieder Bescheid weiß, kann kein Vertrauen in die Führungsrolle von den Kollegen erwartet werden. Der wichtigste Ratschlag für Produktmanager in lateralen Führungspositionen ist jedoch: Hinterfragt Euch selber dahin gehend, ob Ihr Euch auch selber folgen würdet – selbst ohne formale Hierarchien.

8  Lateral Leadership im Produktmanagement

155

Literatur Bezos, J. 2017. Letter to shareholders. www.sec.gov/Archives/edgar/data/1018724/00011931251712 0198/d373368dex991.htm. Bungay, S. 2010. The art of action: How leaders close the gaps between plans, actions and results. UK: Hachette. Gothelf, J. 2015. Agility through cross-functional collaboration. https://youtu.be/5aDaIsVKuIQ. Herbig, T. 2018. Lateral leadership: A practical guide for agile product managers. Brooklyn: Sense & Response Press.

Der Autor  Tim Herbig  ist Product-Management-Coach, Consultant, Autor und Keynote Speaker. Nach zahlreichen Product-Leadership-Rollen u. a. bei XING und Gruner + Jahr hilft er inzwischen Firmen und Einzelpersonen dabei, bessere Produkte zu bauen und Product Teams zu empowern. Er ist ebenfalls der Co-Host des Product Tank Hamburg-Meetups und Creator der Product Discovery Online Masterclass (mehr unter www.herbig.co). Kontakt: [email protected]

9

Product Owner und Scrum Master Zwei Rollen – ein erfolgreiches Team Jan Köster

Zusammenfassung

Scrum Master und Product Owner führen gemeinsam Expertenteams ohne hierarchisch vorgesetzt zu sein. Dieses Spannungsfeld führt im Alltag immer wieder zu Konflikten, kann die beiden aber auch zu einem echten Team werden lassen, wenn sie einige Tipps beherzigen, die in diesem Kapitel gegeben werden.

9.1 Mehr als ein Rollenbild aus einem Framework In einem Setup, in dem komplizierte Probleme, also Probleme die es so oder so ähnlich schon gab, gelöst werden sollen, kann eine Person, zum Beispiel ein Projektleiter, einen Plan mit einem konkreten Ziel aufstellen und sich dabei an „Best Practices“ orientieren. Die Durchführung des Plans kann dann hierarchisch angeordnet und von einem Team in den vorgegebenen Schritten gelöst werden. Im Gegensatz zum Arbeiten an komplizierten Problemen, bei denen die Führungskraft nicht nur über ein „Warum“ führt, sondern auch vorgibt, „was“ und „wie“ ein Problem gelöst wird, liegt in agilen Systemen die Lösungsfindung bei den Experten, die gemeinsam die Lösungen erarbeiten, da nur sie das nötige Wissen und die entsprechenden Fähigkeiten haben. Sie entwickeln das „Wie“ also aus sich heraus. In dem Fall können Führungskräfte nicht über ihr Fachwissen führen, sondern nur über das „Warum“ etwas getan werden muss. Sie setzen Rahmenbedingungen und geben je nach Reifegrad des Entwicklerteams z. T. auch vor, „Was“ getan werden muss. J. Köster (*)  G+J Digital Media, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_9

157

158

J. Köster

In den meisten agilen Setups wird das Team lateral von zwei Rollen geführt. In Scrum, als das am weitesten verbreitete System der agilen Produktentwicklung, sind dies der Product Owner und der Scrum Master.1 Der Product Owner (PO) ist dabei zuständig für die Wertschöpfung des Teams. Er trägt die Verantwortung dafür, dass mit den gegebenen Ressourcen und Mitteln das Team den maximalen Wert liefert. Der Scrum Master (SM) bzw. die „prozessuale Führung“, ist dafür verantwortlich, dass das Expertenteam, bestehend aus PO, Softwareentwicklern und Scrum Master, unter den bestmöglichen Bedingungen arbeiten kann, über ihr System reflektiert und dieses Stück für Stück verbessert. Dabei geht das eine nicht ohne das andere. Ein Team wird durch ein gemeinsames Ziel erst zum Team, das ihnen der PO vermittelt. Und die einzelnen Mitglieder werden erst zu einem wahren Team durch die Arbeit am System, bei der der Scrum Master durch Impulse, Feedback und Reflektion führt. u

Der Product Owner führt „im System“, indem er inhaltlich vorgibt, was mit welcher Priorität bearbeitet werden soll. Dies tut er unter anderem über die Priorisierungen im Product Backlog, mit denen beschrieben wird, was als nächstes von dem Expertenteam umgesetzt werden soll. Der Scrum Master dagegen führt das Team „am System“ zu einem Erkenntnisgewinn und besseren Systemverständnis, um das System selbst Schritt für Schritt zu verbessern. Dafür setzt er unterschiedliche Methoden ein. Die wichtigste ist dabei die Retrospektive, in der das Expertenteam auf den letzten Sprint blickt und identifiziert, wie es besser werden kann.

Aus diesem Setup können sich großen Konflikte zwischen Product Owner und Scrum Master ergeben, die die beiden Rollen miteinander haben: Zum einen führen sie gleichberechtigt ein Team aus dem Team heraus und zum anderen arbeiten sie zeitgleich an einem Produkt und an einem Team. Und das, ohne den Experten hierarchisch vorgesetzt zu sein.

9.2 Wie eine gute Zusammenarbeit gelingen kann Wie ein Team aus Scrum Master und Product Owner an diese Herausforderung herangeht, wie es Lösungen dafür erarbeitet, diese kontrolliert und dabei lernt, entscheidet darüber, ob das Team scheitert, durchschnittlich ist oder zum Duo wird, das jede Herausforderung meistert. 1Der

Vollständigkeit halber sei erwähnt, dass es durchaus agile Team-Setups gibt, in denen die beiden Rollen um eine weitere, zumeist technisch geprägte, ergänzt werden, z. B. Architekt, Systemverantwortlicher, Senior Entwickler oder Ähnliches. Dieses Konstrukt wird im Folgenden aber nicht genauer betrachtet.

9  Product Owner und Scrum Master

159

9.2.1 Start with Why Die Basis jedes Teams sind ein gemeinsames Zielbild und gegenseitiges Vertrauen. Genau das sind daher die ersten Dinge, an denen Ihr als PO-SM-Team arbeiten solltet. Stellt Euch dabei die Frage, warum Ihr in genau dieser Konstellation zusammenarbeitet und warum Ihr in diesem agilen Setup arbeiten wollt. Betrachtet gemeinsam das Cynefin-Framework (Snowden 2000) aus Abb. 9.1 und kontrolliert, ob Euer Projekt bzw. Eure Arbeitsweise tatsächlich im komplexen Bereich wiederzufinden ist, in dem ein agiles Arbeiten sinnvoll ist. Das Cynefin-Framework des walisischen Forschers und Berater für Wissensmanagement David J. Snowden (2000) teilt Systeme in 5 unterschiedliche Felder ein: einfach, kompliziert, komplex, chaotisch sowie verwirrt. Jedes Problem oder Projekt kann in eines dieser Felder einsortiert werden: • Einfache Probleme zeichnen sich durch ein klares Ursache-Wirkungsprinzip aus. Es sind Probleme, die ein Experte alleine lösen kann, häufig schon gelöst hat und für dessen Problemlösung nur einfache Hilfsmittel benötigt werden (z. B. eine Checkliste). • Komplizierte Probleme sind wie einfache Probleme durch ein klares Ursache-Wirkungsprinzip beschreibbar. Die Anzahl der Ursache-Wirkungs­ zusammenhänge ist aber vielfältig und die Lösungen müssen strukturiert werden. Um Lösungen zu erarbeiten, ist Expertenwissen nötig, aber es gibt Best Cases, an denen sich ein Experte orientieren kann. Außerdem gibt es für die Lösung des Problems ein klares Ziel. Der Experte, der den Plan zur Lösung des Problems erstellt, nutzt dafür verschiedene Hilfsmittel. Hier kommen klassische Projektmanagementmethoden ideal zur Anwendung. • Komplexe Probleme unterscheiden sich deutlich von komplizierten dadurch, dass es keinen klaren, vorher erkennbaren Ursache-Wirkungszusammenhang gibt. Wenn überhaupt, können solche Zusammenhänge erst im Nachhinein identifiziert werden. Um Lösungen zu erarbeiten, muss eine Gruppe von Experten experimentieren und Schritt für Schritt einen Weg zur Lösung finden und daraus lernen. Es gibt keinen

» CHAOTISCH «

» EINFACH «

» VERWIRRT «

» KOMPLEX «

» KOMPLIZIERT «

Abb. 9.1   Das Cynefin-Framework. (Quelle: Eigene Darstellung)

160

J. Köster

Best Case und keine Möglichkeit, eine genaue Lösung vorab zu skizieren. Diese Probleme können nur mit agilen Methoden gelöst werden. • Chaotische Probleme sind wie komplexe ohne klares Ursachen-Wirkungsprinzip. Aber hier können gleiche Inputs unterschiedliche Outputs generieren, sodass selbst eine nachträgliche Analyse des Lösungsweges kein in der Zukunft reproduzierbares Ergebnis liefert. • Verwirrte Probleme: Projekte, Systeme oder Prozesse schließlich, die nicht klar einem der oben genannten Felder zugeordnet werden, werden als „verwirrt“ bezeichnet. Oft kommt es hier zur Anwendung falscher Methoden, um Komplexität zu bewältigen – z. B wird versucht, ein komplexes Projekt mit klassischem Projektmanagement zu bewältigen. Zur Klärung darüber, ob Ihr Euch wirklich in einer komplexen Problemsituation befindet, können drei kurze Fragen helfen: • Könnt Ihr nur ein Zielbild bzw. eine Vision aber noch kein klares Ziel, bei dem das Produkt komplett ausdefiniert ist, beschreiben? • Gibt es keine Best Practises, deren Vorgehen Ihr kopieren könnt? • Seid Ihr Euch einig darüber, dass Ihr iterativ vorgehen und gemeinsam mit Euren Kunden an Produktinkrementen lernen müsst, wie Ihr den Zielraum erreichen könnt? Wenn Ihr die Fragen gemeinsam mit ja beantwortet, habt Ihr den ersten großen Schritt gemacht. Ihr habt das „Warum ein agiles Setup notwendig ist“ für Euch und Euer Team geklärt. u WHY-Plakat Erstellt ein Plakat für Euren Projektraum und beschreibt darauf in einem Satz: Warum arbeiten wir in unserem Projekt agil?

9.2.2 Gemeinsame Visionen Als nächstes erarbeitet Ihr als Product Owner und Scrum Master gemeinsam Visionen, die Euch und das Team leiten sollen. Die Produktvision, bei der der PO im Lead ist, definiert, worauf im System mit dem Team hingearbeitet wird, also der Zielraum des Produktes. Die Teamvision, deren Owner der Scrum Master ist, definiert, worauf am System hingearbeitet wird, also den Zielraum der Teamentwicklung. Der jeweils andere unterstützt die Entwicklung der Vision und dient dabei als Sparringspartner, der durch kritische Fragen zum Erkenntnisgewinn beiträgt. u

Produkt- und Teamvision Erarbeitet Euch Eure Vision und bittet dann Euren Partner, diese zu hinterfragen. Fangt beim „Warum“ an und beschreibt anschließend das Zielbild,

9  Product Owner und Scrum Master

161

also wohin sich das Team oder das Produkt entwickeln sollen. Um die Vision zu hinterfragen, sucht Euch besonders kritische Stakeholder oder Teammitglieder aus und nehmt ihre Rolle ein. Was würden sie fragen?

Komplexe Probleme und Herausforderungen können nur durch Experimente gelöst werden. Diese Experimente müssen immer wieder mutig und außerhalb der gewohnten Lösungswege gedacht werden und ein kontrolliertes Scheitern ist ebenso wahrscheinlich und dienlich wie ein erfolgreiches Experiment. Teams, die offen über ihre Fehler sprechen und daraus lernen, werden performanter und mutiger, wodurch sie die besseren Lösungen finden.

9.2.3 Vertrauen Nachdem Ihr Euch klar geworden seid, warum Ihr agil arbeitet und die fachlichen Zielräume definiert und abgestimmt sind, geht es darum, die Basis für eine gute Teamarbeit zu legen. Die Basis jeder guten Zusammenarbeit ist Vertrauen. Ein Vertrauen, das dafür steht, dass sich jedes Teammitglied in einem sicheren Umfeld befindet und in dem es eine offene Feedback- bzw. Fehlerkultur gibt. Vertrauen entwickelt sich aus gemeinsamen Erlebnissen und persönlichem Wissen über die anderen Teammitglieder. Es geht darum, sich gegenseitig menschlich kennenzulernen. Dabei sollte der Fokus nicht nur auf den Stärken liegen. Besonders die Offenbarung von Fehlern oder eigenen Schwächen schafft ein tief greifendes Vertrauen. Als Product Owner und Scrum Master solltet Ihr also gemeinsame Erlebnisse und Situationen meistern und an ihnen wachsen. Begebt Euch dabei aus der Komfortzone Eurer Arbeitsumgebung und lernt Euch auch persönlich kennen. Ein erster Schritt kann eine Erlebniskurve sein, eine gemeinsame Aktivität oder das Schaffen einer gemeinsamen Arbeitsumgebung. u

Die Erlebniskurve Zeichnet auf einem Stück Papier eine Skala auf der y-Achse von „besonders schön“ zu „besonders traurig“. Die x-Achse bildet Eure Lebensjahre. Zeichnet nun Eure Lebenslinie ein. Wann war es besonders schön und wann nicht? Beschriftet nun 7 Ereignisse, die Euch sehr geprägt haben und die Ihr miteinander teilen wollt. Nehmt Euch dafür Zeit und hinterfragt Euch selber – im Anschluss stellt Euch Eure Kurven gegenseitig vor.

u

Schreibt nicht In vielen, besonders größeren Organisationen wird jede Form der Kommunikation schriftlich festgehalten, um sich im Zweifelsfall später darauf beziehen und sich absichern zu können. Als Team von Scrum Master und Product Owner solltet Ihr Euch davon aber lösen. Vertraut Euch, sichert Euch nicht ab, sondern sprecht miteinander.

162

J. Köster

Dabei geht es nicht darum, sinnvolle Notizen nicht mehr mitzuschreiben oder keine Thesen und Ziele zu visualisieren. Es geht vielmehr darum, dass Ihr Euer ganz persönliches Fangnetz aus PowerPoint-Präsentationen, Meeting-Protokollen und Verantwortungs-Matrizen bewusst einreißt und ­ Euch darüber klar werdet, dass Ihr entweder als Team strahlt oder gemeinsam untergeht.

9.2.4 Agile Prinzipien Das Agile Manifest und seine Prinzipien definieren die Werte, die es benötigt, um im Komplexen zu arbeiten. Sie können Euch als Leitsätze dienen und Euch Orientierung bieten. Häufig werden die Leitsätze aber unterschiedlich inter- oder überinterpretiert, fast schon dogmatisch heruntergebetet. Dabei wird außer Acht gelassen, dass das Manifest inzwischen etwas in die Jahre gekommen ist. Nutzt es daher bewusst als Diskussionsgrundlage, um gemeinsame Werte zu definieren und lebt diese Eurem Team vor. Es geht primär um eine Haltung und weniger um strikte Regeln, die es zu befolgen gilt. u

Agile Prinzipien Druckt Euch die agilen Prinzipien aus und bringt sie – zunächst jeder für sich – vom wichtigsten Prinzip bis zum unwichtigsten in eine Reihenfolge. Danach stellt Euch Eure Ergebnisse wechselseitig vor und erklärt einander, wie Ihr zu dem jeweiligen Ergebnis gekommen seid. Dabei geht es nicht um einen Konsens, sondern eher um das Verständnis für den anderen.

9.2.5 Wann hören wir auf? Ein häufiges Konfliktfeld zwischen Product Owner und Scrum Master sind zeitintensive Rituale, bei denen es vor allem in der späteren Produktentwicklung so scheint, als wenn sie nicht mehr benötigt werden. Macht Euch daher jederzeit klar, dass agiles Arbeiten kein Selbstzweck ist. Es handelt sich um eine Arbeitsweise und nicht um eine Religion. Legt am Anfang Eurer Zusammenarbeit fest, woran Ihr merken werdet, dass Arbeitsweisen und die dazugehörigen Rituale ggf. überflüssig werden und Ihr sie nicht mehr benötigt. Das hilft dabei, dass Ihr auch im Verlauf der Zusammenarbeit ein Regel-Set habt, das Euch ermahnt, Eure Arbeitsweise zu hinterfragen. u

Wann hören wir auf? Klebt auf Euer Poster: „Warum wir agil arbeiten“ drei große Post-its, auf denen jeweils ein Indiz steht, an dem Ihr merken würdet, dass agiles Arbeiten keinen Sinn mehr macht und ihr genug Informationen habt, um ein klares Ziel vorzugeben und einen Plan mit allen nötigen Schritten auszuarbeiten. Wenn dem so ist, sind andere Methoden effizienter und passender.

9  Product Owner und Scrum Master

163

9.2.6 Warum machst Du das so? Versteht Euch als wahres Team und akzeptiert, dass Ihr von der Arbeit des Anderen keine Ahnung habt, auch wenn Ihr in einem anderen Kontext eventuell schon einmal eine ähnliche Aufgabe übernommen habt. So wie nur der Product Owner das Produkt und seine Stakeholder kennt, die Prioritäten festlegt und die Verantwortung für die Wertschöpfung trägt, so kennt auch nur der Scrum Master das Team, die Prioritäten für das Arbeiten am System und übernimmt die Verantwortung für eine gute Zusammenarbeit. Das heißt nicht, dass Ihr das Handeln des Anderen nicht kritisch hinterfragen oder Euch erklären lassen sollt, warum Euer Partner bestimmte Entscheidung trifft und Prioritäten festlegt. Ganz im Gegenteil: Euer Partner ist sogar dazu angehalten, Euch jederzeit kritisch zu hinterfragen und Euch auf Missstände hinzuweisen. Dies sollte allerdings immer in einer vertrauensvollen Umgebung auf Augenhöhe passieren, ohne dass es scheint, als wolltet Ihr Euch über den anderen in einer Gruppe erheben. u

Warum machst Du das so? Gebt Eurem Partner das Gefühl, dass Ihr ihn als Experten wertschätzt und fragt ihn mindestens einmal pro Woche, warum er bestimmte Dinge auf (s)eine Weise tut? Gebt ihm Raum, um Euch von seiner Expertise zu überzeugen und Euch sein Handeln zu erklären.

9.2.7 Seid Partner Ihr solltet als ein echtes Team arbeiten. Dabei hilft es, wenn Ihr Euch so versteht, dass Ihr im System als allererstes Euch beide als gemeinsames Team habt. Vielen hilft dabei der Vergleich mit Polizeipartnern aus amerikanischen Filmen: Sie halten sich gegenseitig den Rücken frei, stärken sich in schwierigen Situationen, scherzen übereinander und wissen, dass sie sich jederzeit auf den anderen verlassen können. u

Seid Partner: Good Cop – Bad Cop Sprecht Euch vor einem Termin kurz ab, was Ihr von ihm erwartet und wie Ihr das Geplante gemeinsam erreichen könnt. Häufig hilft es, wenn Ihr Gespräche zusammen vorbereitet und Euch auf Rollen einigt – das können z. B. die klassische Rollenaufteilung zwischen Good und Bad Cop oder der Team- und Kundenbeschützer sein.

9.2.8 Gemeinsame Rituale Um ein Team zu werden, helfen gemeinsame Rituale. Der tägliche Austausch ist vergleichbar mit dem Stand-Up Eures Entwicklerteams. Und die Rituale, in denen Ihr gemeinsam an Euch als PO-SM-Team arbeitet, sind vergleichbar mit den Scrum-Zyklen.

164

J. Köster

Tägliche Rituale sind begründet auf den agilen Prinzipien, dass Experten und Anforderer eng miteinander zusammenarbeiten sollen und es die effizienteste und effektivste Methode ist, Informationen im Gespräch von Angesicht zu Angesicht zu übermitteln. Schafft Euch dafür ein Ritual. Dabei ist es egal, ob es der Kaffee nach dem Team-Stand-Up ist, gemeinsame Mittagessen, ein Treffen in der Kaffeeküche oder ein fester Jour-fixe-Termin ist. Die Hauptsache ist, dass Ihr täglich mindestens ein gemeinsames Ritual habt. Dies bietet Euch die Möglichkeit, Probleme sofort anzusprechen und direkt auf diese zu reagieren. Damit lebt Ihr Eurem Team außerdem vor, wie wichtig eine direkte Kommunikation ist und wie eng Ihr zusammenarbeitet. u Spazierengehen Blockt Euch nach dem Stand-Up Eures Teams jeden Tag 15 min in Euren Kalendern. Seid erst für Euer Expertenteam ansprechbar und nutzt im Anschluss die verbleibenden Minuten, um gemeinsam ein Stück zu gehen. Dabei muss der Spaziergang nicht einmal außerhalb des Gebäudes sein. Schlendert über den Flur und sprecht kurz die wichtigsten Erkenntnisse des Stand-Up durch. u Feedback Nutzt die täglichen Regeltermine, um Euch ein ritualisiertes Feedback zu geben. Beschreibt dem anderen, wie Ihr ihn in einer Situation wahrgenommen habt, was das bei Euch ausgelöst hat und was Euer Impuls an ihn wäre. Beispiel: „Ich habe im Stand-Up wahrgenommen, dass Du Dein Handy in der Hand hattest. Das hat mir das Gefühl gegeben, dass Du den Termin nicht ernst nimmst und ich würde mir wünschen, dass Du die 15 Minuten voll konzentriert dabei bist, oder uns mitteilst, was Dich gerade ablenkt, damit wir Dein Handeln nachvollziehen können.“ Ein Feedbackritual macht Euch gemeinsam besser, übt strukturiertes Feedbackgeben und Ihr lebt Eurem Team die Bedeutung von Feedback vor. Außerdem stärkt es Eure gegenseitige Selbstverpflichtung und Euer Vertrauen zueinander, da der Andere Euch offen an seinen Gedanken teilhaben lässt.

9.2.9 Euer PDCA-Zyklus Nachdem das tägliche gemeinsame Ritual hoffentlich fester Bestandteil Eures Arbeitens geworden ist, überlegt Euch, wie für Euch ein übergeordneter PDCA-Zyklus aussehen könnte. Ein PDCA-Zyklus bzw. Deming-Kreis ist die Grundlage jedes agilen Arbeitens und beschreibt die wiederkehrende Reihenfolge aus Planung, Ausführung, Überprüfung und Handeln, s. Abb. 9.2. Der PDCA-Zyklus sorgt für eine kontinuierliche Verbesserung: Erst werden Thesen und Arbeitspakete geplant (Plan). Danach werden diese umgesetzt

9  Product Owner und Scrum Master

165

Plan

Do

Act

Check

Abb. 9.2   Der PDCA-Zyklus. (Quelle: In Anlehnung an Shewhart 1939)

und als Inkrement ausgeliefert (DO). Das Inkrement und die dahinterliegenden Thesen werden anschließend überprüft (CHECK) und aus dem Gelernten werden Ableitungen für den nächsten Zyklus vorgenommen (ACT). Wichtig ist in dem Zyklus u. a., dass die Checks schon bei der Planung berücksichtigt werden (Scholtes 1998). In der PO-SM-Konstellation haben die einzelnen Phasen des PDCA-Zyklus die folgende Bedeutung: • Plan: Überlegt Euch, für wen Ihr was in welcher Priorität macht. Versucht dabei, ein besonderes Augenmerk darauf zu legen, dass keiner Eurer drei großen Stakeholder zu kurz kommt: Ihr als PO-SM-Team, Euer Umsetzungsteam, mit dem Ihr am Produkt arbeitet, und auch nicht der Kunde, für den Ihr das Produkt entwickelt. • Do: Setzt die Maßnahmen um. Achtet dabei besonders darauf, dass Transparenz darüber herrscht, wer gerade an welchem To-do arbeitet und ob er dabei die Hilfe seines Partners braucht. • Check: Überprüft, ob Ihr mit den Maßnahmen Eure Ziele erreicht habt, gebt Euch Feedback und reflektiert, was Ihr aus dem vergangenen Zyklus und den Ergebnissen gelernt habt. Dabei solltet Ihr besonders darauf schauen, wie gut sich diese Maßnahmen mit dem Arbeiten am Produkt in Einklang bringen ließen. Blickt hier auch auf Eure Checkliste „Macht Agiles Arbeiten noch Sinn?“. Nehmt Euch dabei gegenseitig in die Verantwortung und seid Eure stärksten Kritiker, denn in genau dieser Phase gewinnt Ihr die Erkenntnisse, die Euch, Euer Entwicklerteam und Euer Produkt besser machen. • Act: Leitet aus dem Gelernten neue Maßnahmen ab und korrigiert ggf. Euren Zielraum bzw. Eure Teamvision. Euer PDCA-Zyklus sollte natürlich nicht so kurz sein, wie der Eures Teams, während sie an dem Produkt arbeiten. Er sollte aber auch nicht so lang sein, dass er sich eher nach einer Roadmap für die nächsten Monate anfühlt.

166

u

J. Köster

Die Länge Eures PDCA-Zyklus Bewährt hat sich ein PO-SM PDCA-Zyklus von 6 Wochen. Plant einen wöchentlichen Termin (Weekly) und setzt Euch konkrete Ziele, wie Ihr an der Teamund Produktvision arbeiten wollt. Richtet Euch eine Review ein und reflektiert danach, ob Ihr Euren Zielen deutlich nähergekommen seid.

9.2.10 Führen über Warum und Transparenz Scrum Master und Product Owner sind im agilen Arbeiten laterale Führungskräfte. Sie delegieren, moderieren und führen über Feedback. Sie geben Rahmenbedingungen vor und erklären die Bedeutung der Aufgaben des Teams, ordnen ein, „warum“ etwas getan werden muss und erklären die Bedeutung für die Gesamtorganisation. Dabei führen sie gemeinsam im Operativen auf Augenhöhe mit dem Team. Ihre Aufgabe ist es, Transparenz über die Arbeit nach innen und außen zu schaffen sowie eine Arbeitsumgebung zu gewährleisten, in der die Experten bestmöglich arbeiten können. In jedem Stand-Up sammeln sie die wichtigen Informationen und mit der Frage „Was behindert Euch“ Items, die sie schnellstmöglich gemeinsam lösen bzw. am nächsten Tag über den aktuellen Stand Rechenschaft ablegen. u

Warum? Warum? Warum? Fordert Euer Entwicklerteam auf, Euch zu fordern und macht sie zu Euren Kritikern, die jede Eurer Entscheidungen mit einem Warum hinterfragen. Denn nur, wenn Alle das gleiche Verständnis haben, werdet Ihr gemeinsam erfolgreich sein. Sobald jeder Experte weiß, wie er mit seinem Handeln das große Ganze zum Erfolg führen kann und die Prioritäten verinnerlicht hat, kann er sein ganzes Potential einbringen, im Sinne des Produktes handeln und mitdenken.

u

Zeigt, woran Ihr arbeitet Schreibt alle Hindernisse auf Post-its und bringt sie mit auf das Sprint Board Eures Teams. Falls Euer Umsetzungsteam ein digitales Board nutzt, macht es auch dort transparent. Lasst die Post-its vom Team priorisieren und ordnet sie den richtigen Spalten zu. Hängt sie im täglichen Stand-Up um, wenn Ihr etwas lösen konntet oder sagt deutlich, warum Ihr an einem Thema nicht weiterkommt. Damit zeigt Ihr Eurem Team, dass Ihr Eure Arbeit genau so transparent macht, wie Ihr es von ihnen erwartet.

9.2.11 Führen über Haltung Als Scrum Master und Product Owner führt Ihr über Haltung. Das bedeutet, dass Euch bewusst sein muss, dass jede Eurer Handlungen als Vorbild dient. Egal, ob Ihr zu spät zum Stand-Up kommt, vorschlagt, die Retro ausfallen zu lassen oder Eure Kaffeetasse

9  Product Owner und Scrum Master

167

auf dem Meetingtisch zurücklasst: Euer Handeln dient als Leitbild. Ihr zeigt, dass Euch das Stand-Up nicht wichtig ist, bzw. dass Eure Zeit wertvoller ist als die der anderen, wenn Ihr nicht pünktlich seid. Ihr setzt die Bedeutung der Retro herab und macht dem Team deutlich, dass Ihr von seinen Maßnahmen nichts haltet, wenn Ihr sie ausfallen lasst. Und Ihr zeigt jedem, dass Ihr vermeintlich etwas Besseres seid, wenn Ihr Eure Tasse stehen lasst und erwartet, dass jemand anderes diese für Euch wegräumt. Und auch, wenn Ihr das nicht so meint, kann es so gedeutet werden. u

Seid der größte Kritiker des anderen In unserem täglichen Handeln können wir nicht auf alles achten – Führen über Haltung ist schwer. Aber eben hier hat das Team aus Product Owner und Scrum Master einen entscheidenden Vorteil. Ihr könnt der größte Kritiker des anderen sein und ihn auf seine Haltung hinweisen oder aufzeigen, wie diese interpretiert werden könnte.

9.2.12 Gemeinsam geteilte Führung Ihr führt ein Team aus Experten, die in ihrem Gebiet sehr viel mehr wissen als Ihr. Und jeder Einzelne ist unerlässlich für den gemeinsamen Erfolg. Deswegen begegnet jedem mit Respekt und führt auf Augenhöhe. Aber nur Ihr könnt Euren Weg finden, wie Ihr Euer Team so fordert, dass es das bestmögliche Ergebnis für das gemeinsame Ziel liefert, ohne dass Ihr die Experten überfordert oder sie sich selbst überfordern. Besonders die geteilte Führung ist dabei eine Herausforderung. Ihr müsst als Einheit auftreten – auch wenn Ihr nicht immer der gleichen Meinung seid. Wenn dies der Fall ist, diskutiert niemals vor dem Team; tretet trotzdem gemeinsam auf und versucht, Euch nicht so zu widersprechen. Unterstützt den anderen in schwierigen Situationen und geht erstmal davon aus, dass er im Sinne des Teams und nach bestem Wissen und Gewissen handelt. Arbeitet dabei täglich mit Eurem Team zusammen. Seid ansprechbar, ständig präsent und nicht gehetzt. Nehmt an allen Teamritualen teil und lernt mit dem Team gemeinsam. Auch wenn in dem Scrum Guide steht, die Teilnahme an den Ritualen sei optional, hat die Praxis gezeigt, dass dies für ein produktives Team keine Option sein sollte. Macht Euch als Scrum Master und Product Owner klar, dass das Team, das Ihr führt, Erfolg hat, wenn das Projekt erfolgreich abgeschlossen ist. Sollte dies nicht so sein, dann trägt nicht das Team die Verantwortung für das Scheitern, sondern Ihr. Damit es erst gar nicht zu einer Trennung zwischen Team, Product Owner und Scrum Master kommt, sollte Euch eines die ganze Zeit klar sein: Um die gemeinsamen Visionen zu erreichen, braucht es jeden aus dem großen Team. Keiner von Euch wird alleine im Komplexen Erfolg haben. Und egal ob Product- oder Teamvision: die Lösung kann nur vom Expertenteam gemeinsam erarbeitet werden. Product Owner und Scrum Master dienen dabei als laterale Führungskräfte – sie führen also aus dem Team heraus.

168

J. Köster

u „Wir“ Damit Euch der Teamaspekt zu jeder Zeit klar ist, sagt nie „das Team muss“, sondern sprecht immer von „Wir“.

9.3 Was folgt? Welche Dinge soll man als Product Owner bzw. Scrum Master nun mitnehmen? Orientiert Euch vor allem an den drei Leitsätzen, die den Unterschied machen: 1. Seid ein PO-SM-Team 2. Seid Führungskräfte 3. Seid Teil des gesamten Teams Dann werdet Ihr gemeinsam Eure Produkt- und Teamvision verwirklichen, Euer Team performant führen und dabei begleiten, jede Herausforderung zu meistern. Den größten Fehler, den Ihr machen könnt, ist nicht miteinander, sondern gegeneinander zu arbeiten. Versteht die vorangegangenen Tipps als Anregung und nicht als strikte Lösung, denn die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbst organisierte Teams – und das seid in diesem Falle Ihr. Lernt zudem immer weiter. Versucht als Team immer besser zu werden und Euch weiterzuentwickeln. Experimentiert, macht Fehler, fallt hin, steht wieder auf und macht weiter. Just do it and fail fast – agiles Arbeiten lebt von kleinen Experimenten, Scheitern und Lernen. Als Team aus Product Owner und Scrum Master habt Ihr immer jemanden an der Seite, der Euch auf die Schulter klopft, wenn ein Experiment gelungen ist. Und viel wichtiger einen, der Euch aufhilft, wenn Ihr mit einem gescheitert seid. Verliert nicht Eure Visionen aus dem Blick und sorgt dafür, dass Ihr das beste Team seid, in dem Ihr jemals gearbeitet habt.

Literatur Scholtes, P.R. 1998. The leader’s handbook – Making things happen, getting things done. New York et al.: McGraw Hill Professional. Shewhart, W.A. 1939. Statistical method from the viewpoint of quality control. New York: Graduate School Department of Agriculture. Snowden, D. 2000. The social ecology of knowledge management. Cynefin: A sense of time and place. In Knowledge horizons: The present and the promise of knowledge management, Hrsg. C. Despres und D. Chauvel. Oxford: Butterworth-Heinemann.

9  Product Owner und Scrum Master

169

Der Autor  Jan Köster  begleitet bei Gruner und Jahr als agiler Coach Bereiche, Teams und Einzelpersonen im Sinne des Agilen Manifests, schult agile Methoden, bildet Scrum Master aus und begleitet die agile Community und HR. Sein Fokus des agilen Coachings liegt auf dem Erkenntnisgewinn der Coachees. Sie erkennen Hindernisse im System oder ihren Produkten, identifizieren Lösungsräume und entfalten so ihr Potential aus sich heraus. Kontakt: [email protected]

User Experience verstehen UX-Teams in der digitalen Produktentwicklung erfolgreich einsetzen

10

Inken Petersen

Zusammenfassung

Digitale Produkte und Services gehören zu unserem alltäglichen Leben. Mit zunehmender digitaler Kompetenz steigen das Bewusstsein und die Erwartungshaltung der Nutzer. Sie setzen sich – bereits vor dem Download oder der Registrierung – mit dem zu erwartenden Produktnutzen intensiv auseinander. Das Erlebnis der Nutzer bei der Produktnutzung, also die User Experience (kurz UX), hat einen immer größeren Einfluss auf die Entscheidung für oder gegen ein Produkt. Viele Unternehmen haben dies erkannt und investieren gezielt in eine gute User Experience ihrer Produkte. Sie engagieren UX-Teams und verschiedene UX-Spezialisten, die sich jeden Tag um das Erforschen und Gestalten des besten Nutzererlebnisses kümmern. Jedoch ist Produktverantwortlichen oft unklar, wie die einzelnen Disziplinen in einem UX-Team zusammenwirken und wie man ein UX-Team am besten in der Produktentwicklung einsetzen kann. In diesem Artikel wird daher ein Grundverständnis für die Bedeutung von UX, die einzelnen UX-Disziplinen und die beste Einbindung von ­UX-Teams aufgebaut.

10.1 Die Bedeutung eines positiven Nutzererlebnisses User Experience umfasst laut Don Norman „alle Aspekte der Interaktion des Nutzers mit dem Unternehmen, seinen Produkten und seinen Dienstleistungen“ (Norman und Nielsen 2016). Don Norman war der erste UX-Architekt bei Apple im Jahre

I. Petersen (*)  Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_10

171

172

I. Petersen

1993 – ein Unternehmen, das die Wichtigkeit von UX schon sehr früh erkannt hat. Ein positives Nutzungserlebnis beginnt nicht erst beim Kauf einer App oder nach der Registrierung, sondern schon beim ersten Kontakt mit der Marke über eine Empfehlung oder über einen Treffer in einer Suchmaschine. Dieser ganzheitliche Ansatz ist mittlerweile auch in der entsprechenden ISO-Norm 9241-210 als Standard definiert (International Organization for Standardization 2019). Im Vordergrund steht für den Nutzer dabei die Frage, inwiefern das Produkt einen wirklichen Nutzen bietet. Erst danach kommen Aspekte wie Einfachheit, Ästhetik oder Freude ins Spiel. Ein einfach zu bedienendes und schönes Produkt ohne Nutzen wird keine Kunden finden. Eine gute UX geht über das User Interface (UI), also die reine Oberflächengestaltung des Produktes, hinaus. Selbst ein perfektes User Interface hilft einem Nutzer nicht weiter, wenn er Funktionen oder Services braucht, die ihm das Produkt nicht bieten kann. Wenn der Nutzer ein Produkt per Expresslieferung benötigt, die Lieferzeit aber 2 Wochen beträgt, wird er den Online-Shop unzufrieden verlassen und woanders einkaufen. Wenn er gerne Videos mit seinen Freunden teilen möchte, aber nur Fotos teilen kann, wird er auch unzufrieden sein. Für eine herausragende UX muss man dem Nutzer dabei immer einen Schritt voraus sein. Es reicht also nicht aus, Checklisten von gewünschten Features aus Umfragen und Nutzertests abzuarbeiten. Es geht vielmehr darum, dass alle Funktionen im Unternehmen – wie Marketing, Sales, Engineering, Produktmanagement, UX Design etc. – zu Kundenverstehern werden und gemeinsam das perfekte Nutzererlebnis aktiv mitgestalten. Der UX-Designprozess bekommt als Vorgehensweise dadurch Relevanz über das UX-Team und die Produktentwicklung hinaus. Denn die Philosophie hinter dem Designprozess kann auch auf Projekte im Marketing und Sales übertragen werden.

10.2 Der iterative UX-Designprozess Der UX-Designprozess ist ein iterativer und schneller Prozess, der sich im Umfeld der agilen Produktentwicklung entwickelt hat und auf bekannten Designansätzen und -philosophien wie „Design Thinking“ und „User Centered Design“ aufbaut.1 Der Fokus im UX-Designprozess liegt auf der ganzheitlichen Produktgestaltung, die den gesamten Kundenlebenszyklus und alle Interaktionspunkte zwischen Kunden und dem Produkt bzw. dem Service beinhaltet. Zudem ist der UX-Designprozess (ähn-

1Mehr

zum Thema Design Thinking findet man im „Change by Design“ Buch dem ­ esign-Thinking-Vordenker Tim Brown (2009). Mehr über den „User Centered Design Prozess“ D findet man in Don Normans Buch „User-Centered System Design: New Perspectives on HumanComputer Interaction“ (Norman 1986).

10  User Experience verstehen

173

Ideenmenge

Verstehen

Den Nutzer und seine Bedürfnisse, Probleme und Wünsche verstehen

Prototyping

Ideen und Konzepte entwickeln und mit Prototypen umsetzen

Überprüfen

Ideen und Konzepte mit Nutzertests überprüfen

Verbessern

Ideen und Konzepte auf Basis der Testerkenntnisse verbessern

Abb. 10.1   Der iterative UX-Designprozess. (Quelle: Eigene Darstellung)

lich wie beim Design Thinking) durch schnelle und leicht umsetzbare Methoden charakterisiert, um in das Tempo der modernen agilen Produktentwicklung zu passen. Der iterative UX-Designprozess besteht, wie in Abb. 10.1 veranschaulicht, aus 4 Schritten, die aufeinander aufbauen und zyklisch wiederholt werden: Verstehen, Prototyping, Überprüfen und Verbessern. Im Laufe dieser Schritte werden eine Vielzahl von Ideen und Lösungsansätzen generiert und dann auf die besten Ideen reduziert. Die iterative und schnelle Vorgehensweise orientiert sich am Lean-Startup-Prinzip, das von Eric Ries geprägt wurde (Ries 2011). (1) Verstehen Im Zentrum des UX-Designprozesses stehen immer die Nutzer – die jetzigen und die zukünftigen. Zu Beginn jedes Projektes wird das Nutzerverhalten mit Beobachtungen oder Befragungen analysiert. Diese Erkenntnisse werden in Modellen, wie Personas oder Nutzerszenarien, verdichtet, die einen guten Überblick über die Zielgruppe und die Nutzungssituationen mit dem Produkt oder Service bieten. In dieser Phase sprießen die Ideen und Lösungsansätze, da die Auseinandersetzung mit dem Nutzer auf dieser Ebene sehr inspirierend ist. (2) Prototyping Im nächsten Schritt beginnt das Prototyping, also das Erstellen von Modellen für das neue Produkt, den neuen Service oder die neuen Features. Im UX-Design gibt es eine Vielzahl von Prototyping-Methoden wie Papier-Prototyping, Wireframes und Clickdummys, die helfen, die Ideen und das zukünftige Systemverhalten zu visualisieren. Die Prototypen bilden die Grundlage zur Kommunikation der neuen Ideen und zum Validieren der Ideen mit der Zielgruppe.

174

I. Petersen

(3) Überprüfen Die Ideen, Hypothesen und Designansätze in den Prototypen werden mit Hilfe von Nutzerfeedback überprüft und validiert. Kritische UX- bzw. Usability-Probleme können so vor einer technischen Umsetzung behoben werden und das Risiko der Entwicklung von Produkten, die keiner will und braucht, wird reduziert. Für das Überprüfen gibt es eine Vielzahl an Methoden – vom klassischen Test im User Lab bis hin zum A/B-Test mit einer programmierten Version des Prototypen. (4) Verbessern Die gewonnenen Testerkenntnisse werden – meist im Team – priorisiert und dann auf den Prototypen übertragen. Je nach Testergebnis werden die Ideen und Konzepte in diesem Schritt radikal verändert oder auch nur leicht optimiert. Der UX-Bereich nimmt als Spezialisten-Einheit hier eine besondere Rolle ein, da viele der Aufgaben im UX-Team – in enger Abstimmung mit Produktmanagement und Software Engineering – erledigt werden. UXler kennen sich aus mit UX-Methoden und Tools, um in kurzer Zeit viele Ideen zu generieren, schnelle Prototypen zu gestalten und zu überprüfen. Da man alle diese Aufgaben schlecht in einer Rolle unterbringen kann, haben sich in den letzten Jahren drei Kerndisziplinen im UX-Bereich entwickelt.

10.3 Die Kerndisziplinen im User Experience-Bereich Ein modernes User Experience-Team besteht in der Regel aus den drei Bereichen ­UX-Design, Visual Design und User Research. Alle beschäftigen sich damit, das Nutzererlebnis eines digitalen Produktes so angenehm, zufriedenstellend, motivierend, effizient und produktiv wie möglich zu gestalten. Sie überlegen z. B., ob eine Website-Navigation intuitiv verständlich ist oder die Smartphone-App einen visuell ansprechenden Eindruck hinterlässt. Sie setzen eine Vielzahl von verschiedenen Methoden und Tools ein, um das Nutzerverhalten vor, während und nach der Nutzung zu analysieren und auf dieser Grundlage das Produkt oder den Service zu gestalten. Jede Disziplin hat dabei ihren eigenen Fokus sowie eigene Methoden und Tools.

10.3.1 Der UX-Designer Der UX-Designer ist die wohl bekannteste Disziplin im UX-Team. Mittlerweile wird der UX-Designer auch oft als Product Designer bezeichnet. Der Fokus des UX-Designers liegt in der Konzeption von nützlichen sowie gut funktionierenden Produkten und weniger auf der Ästhetik.

10  User Experience verstehen

175

Die Aufgaben des UX-Designers sind insb.: • Verstehen, wie der Nutzer sich verhält, welche Probleme er hat und was er braucht; • Erstellen von Nutzermodellen, wie User Journeys und Personas, als Grundlage für die Produktgestaltung; • Gestalten von einfach zu bedienenden und gut funktionierenden Produktkonzepten mit Papier-Prototypen, Wireframes und interaktiven Prototypen; • Überprüfen der Produktkonzepte mittels Nutzerfeedback aus UX-Tests, ­Usability-Tests, Kundeninterviews, A/B-Tests etc. Einige Beispiele aus dem Werkzeugkoffer eines UX–Designers sind: Anwendungsszenarien, Funktionalität, Usability, Navigation, Informationsarchitektur, Personas, ScreenStruktur, User Journeys, Wireframes, Prototypen etc. Im Buch „101 Design Methoden“ von Vijay Kumar findet man eine gute Übersicht über gängige Designmethoden (Kumar 2012).

10.3.2 Der Visual Designer Der Visual Designer kümmert sich um die zeitgemäße Ästhetik eines Produktes und um dessen visuelle Konsistenz. Seine Designs haben den Anspruch, schön und gut bedienbar zu sein sowie zu den technischen Anforderungen zu passen. Er wird oft auch als User Interface-Designer (UI-Designer) bezeichnet. Die Aufgaben des Visual Designers sind insbesondere: • Verstehen, welcher visuelle Stil zur Marke und den Nutzern des Produktes passt; • Ausarbeiten der visuellen Benutzeroberfläche des Produktes; • Gestalten der visuellen Benutzeroberfläche passend zur Technologie, wie responsive Websites oder native Apps; • Sicherstellen, dass die Interface-Elemente konsistent eingesetzt werden Einige Beispiele aus dem Werkzeugkoffer eines Visual Designers sind: die visuelle Gestaltung von Interaktionselementen wie Buttons und Eingabefeldern, visuelle Gestaltung der Benutzeroberfläche mit Schriften, Farben und Icons passend zur Marke, Entwicklung von Animationen für z. B. Teaser, Erstellung von visuellen Styleguides, Erstellen von visuellen Designvorlagen in Sketch oder Photoshop als Grundlage für die technische Umsetzung etc.

10.3.3 Der User Researcher Der User Researcher ist der interne Experte für alle Fragen rund um Nutzertests. Er kennt eine Fülle an passenden Testmethoden und Test-Tools und führt die entsprechende UX-Forschungsmethode im Projekt durch. Er wird auch als UX-Researcher bezeichnet.

176

I. Petersen

Die Aufgaben des User Researchers sind insbesondere: • Definieren der zu überprüfenden Hypothesen für die Nutzertests; • Auswählen der für den jeweiligen Kontext am besten geeigneten Testmethoden und Test-Tools, wie Interviews, UX-Tests, Umfragen, Usability Tests, Remote Tests etc.; • Vorbereiten, Durchführen und Auswerten der Tests; • Zusammenführen der Erkenntnisse über mehrere Tests hinweg als Wissensbasis. Einige Beispiele aus dem Werkzeugkoffer eines User Researchers sind: Nutzerbeobachtung, Nutzerbefragungen, Usability Tests, Test-Software, Testleitfaden, FeedbackTools, Datenanalyse. Die Methoden des User Researcher sind im Buch von Tomer Sharon „Validating Product Ideas: Through Lean User Research“ gut beschrieben (Sharon 2016).

10.4 Die verschiedenen Arten von UX-Teams Im UX-Team fällt eine Vielzahl unterschiedlicher Aufgaben an. Viele dieser Aufgaben hängen voneinander ab bzw. bauen aufeinander auf. Das macht UX zum Teamsport und den Informationsfluss und den Austausch im Team sehr wichtig. Je nach Unternehmensgröße und Kompetenzen der Team-Mitglieder kann es dabei sinnvoll sein, bestimmte Disziplinen in einer Rolle zusammenzufassen. Jeder organisatorische Aufbau hat seine Vor- und Nachteile, die bei der Entscheidung für oder gegen eine Aufteilung beachtet werden sollten.

10.4.1 Das klassische UX-Team Im klassischen UX-Team gibt es eine klare Aufgabentrennung der einzelnen Disziplinen UX-Design, Visual Design und User Research. Vorteile der klassischen Lösung sind: • klare Verantwortlichkeiten; • Wissens- und Kompetenzaufbau auf hohem Niveau möglich; • Aufgabentrennung passt sehr gut zu den Anforderungen in der Produktentwicklung. Nachteile der klassischen Lösung sind: • Informationsaustausch ist nicht einfach; • die Organisation der Arbeit nimmt mehr Zeit in Anspruch, da mehr Disziplinen involviert sind; • die Spezialisierung kann den Tunnelblick fördern. Für die meisten Unternehmen ist der klassische Aufbau durch seine Klarheit die beste Lösung. Zudem ist das Finden von geeigneten Designern einfacher, da es z. B.

10  User Experience verstehen

177

nur sehr wenige Designer gibt, die sowohl den Bereich UX-Design als auch den ­Visual-Design-Bereich in sehr hoher Qualität abdecken können.

10.4.2 Das „UX-Team of one“ Beim „UX-Team of one“ übernimmt eine Person alle Aufgaben der drei verschiedenen UX-Disziplinen. Vorteile des „UX-Team of one“ sind: • ein sehr guter Überblick und guter Wissensstand über alle UX-Themen; • sehr flexible Einsatzmöglichkeit der UX Expertise. Nachteile des „UX-Team of one“ sind: • die verschiedenen Aufgaben und Projekte alleine abzudecken ist eine Herausforderung; • viele Aufgaben können nicht parallel erledigt werden und die UX des Produktes leidet darunter. Das „UX-Team of one“ kann in kleinen Startups oder Unternehmen, die mit einem professionellen UX-Bereich beginnen, eine pragmatische Anfangslösung sein.

10.4.3 Das hybride „UX- & Visual-Design-Team“ mit separater UserResearch-Dimension Bei dieser Lösung gibt es keine getrennten Design-Disziplinen. Der Designer übernimmt alle UX- und Visual-Design-Aufgaben. Durch separate User Researcher wird jedoch sichergestellt, dass das Überprüfen der Hypothesen und Konzepte nicht zu kurz kommt. Vorteile der hybriden Lösung sind: • Es ist keine Übergabe vom UX-Designer an den Visual Designer im Projektverlauf notwendig; • durch die separate Research-Disziplin bleibt trotzdem genug Zeit, Hypothesen und Konzepte umfassend zu überprüfen. Nachteile der hybriden Lösung sind: • Die verschiedenen Aufgaben von UX-Design und Visual Design abzudecken, ist nicht einfach, da viele Designer ihre Stärken meist nur in einer Disziplin haben. • Die hybride Lösung kann funktionieren, wenn die Designer im Team die Aufgaben aus UX-Design und Visual Design gut abdecken können oder sich als „Design Pairs“, d. h. einer engen Zusammenarbeit im 2er-Team, gegenseitig in ihren ­Spezial-Disziplinen unterstützen können.

178

I. Petersen

10.5 Die beste Organisationsform Neben der Zusammenstellung des UX-Teams müssen sich Produkt- und UXVerantwortliche auch mit der Frage der besten Einbettung in die agile Produktentwicklungsorganisation befassen. Derzeit zeigen sich in der Praxis dabei vor allem zwei gegensätzliche Ansätze: das verteilte UX-Team und das zentralisierte UX-Team. Das verteilte UX-Team Bei diesem Ansatz arbeitet das UX-Team dezentral und verteilt in sog. Cross Functional-Teams, also in funktionsübergreifenden agilen Produktteams. Die UX- und Visual Designer sitzen direkt bei einem Produktteam und sind hauptsächlich für dieses Team tätig. Die Vorteile dieser Lösung sind die sehr effiziente und gute Zusammenarbeit mit den Produktmanagern und Software-Entwicklern und eine größere Themennähe der Designer. Ein Nachteil ist der oft mangelnde übergreifende Austausch der UX- und Visual Designer untereinander. Fehlendes Feedback und der Blick über den Tellerrand führen bei den dezentralen UX-Teams langfristig häufig zu einer Unzufriedenheit bei den Designern, da die eigene Weiterentwicklung leidet. Das zentralisierte UX-Team Der gegenteilige Ansatz ist das zentralisierte UX-Team, das wie eine interne Designagentur arbeitet. Das UX-Team sitzt an einem Ort zusammen und bearbeitet Projekte aus unterschiedlichen Produktteams. Die Vorteile dieser Lösung sind der gute Austausch innerhalb des UX-Teams und die guten Möglichkeiten der eigenen Weiterentwicklung durch z. B. das Feedback der anderen Designer. Ein großer Nachteil ist die schwierigere Zusammenarbeit mit den agilen Produktteams, wodurch das die User Experience dann in Projekten oft einfach vernachlässigt wird. Deswegen eignet sich das zentralisierte ­UX-Team meist nur für Unternehmen, die bereits eine ausgeprägte UX-Kultur haben und bei denen die User Experience zum Arbeitsprozess einfach dazugehört. Die Organisationsform sollte also immer abhängig vom Gesamtkontext gewählt werden und kann sich über die Jahre auch ändern. Neben der Organisationsform stellt sich beim UX-Team auch immer die Frage nach der notwendigen Anzahl von Designern und Researchern. Dafür haben sich in den letzten Jahren Best Practices etabliert.

10.6 Die richtige Menge an UX Wer ein Produkt mit einer hervorragenden User Experience haben will, muss in UX investieren. Eine gleichwertige Einbindung von UX in die Arbeitsprozesse und Entscheidungen ist wichtig. Oft werden die UX-Disziplinen aber leider mit „schön machen“ der Oberfläche gleichgesetzt. Wenn dies passiert, berauben sich Unternehmen jedoch wichtiger Chancen und Potentiale in der Produktentwicklung.

179

Sowareentwicklung

10  User Experience verstehen

Gutes Verständnis der Funkonen

Unausgeglichenes Verhältnis der Funkonen

Abb. 10.2   Der dreibeinige Hocker in der Produktentwicklung. (Quelle: In Anlehnung an Schleifer 2018)

Beim Aufbau von Mitarbeitern im Produktmanagement und in der Software-­ Entwicklung sollte man deshalb dem Modell des Dreibeinigen Hockers folgen, siehe Abb. 10.2: Optimal ist ein gutes Gleichgewicht zwischen allen Funktionen. Ein zu kurzes Bein in einer der Funktionen führt zu einem wackeligen Hocker bzw. einem wackeligen Produkt. In Firmen wie AirBnB hat sich das Modell des Dreibeinigen Hockers bereits bewährt (Schleifer 2018). Die passende Ratio, also das Verhältnis von UX zu den anderen Funktionen, ist dabei für die einzelnen UX-Disziplinen unterschiedlich. Sowohl beim verteilten als auch beim zentralisierten UX-Team-Modell haben sich die folgenden Faustformeln bewährt: • UX-Design-Ratio: 0,5 bis 1 UX-Designer je Produktteam • Visual-Design-Ratio: 0,25 bis 0,5 Visual Designer je Produktteam • User-Researcher-Ratio: 0,25 User Researcher je Produktteam Die Verhältnisse orientieren sich an der Empfehlung von Marty Cagan, dem Gründer der Silicon Valley Product Group (Cagan 2007). Wichtig ist, dass das hybriden Designer-Modell, also UX-Designer und Visual Designer in einer Person, nicht bedeutet, dass man Designer einsparen kann. Zumindest nicht ohne Einbußen in Geschwindigkeit oder Qualität. Das Verhältnis bleibt dasselbe.

10.7 Die Zukunft von UX Technische Produkte werden immer komplexer und Themen wie Künstliche Intelligenz, Spracheingabe, Verknüpfungen von physischen Produkten mit digitalen Produkten (Beispiel: Tracking-Armbänder mit digitalen Apps) sowie immer mehr Endgeräte verändern

180

I. Petersen

die Anforderungen an die User Experience ständig. Zugleich wird der Faktor UX in dieser komplexen technischen Welt für die Nutzer immer wichtiger. Leider wird der Mehrwert von guten UX-Teams oft unterschätzt oder nicht verstanden. Und auch die UX- Community selbst zeigt zu wenig Präsenz nach draußen bzw. tut sich schwer damit, den eigenen Mehrwert gut zu verkaufen und deutlich zu machen. Ein Grund hierfür ist sicherlich, dass die Aufgaben der drei Kerndisziplinen in den letzten Jahren sehr in Bewegung waren. Mit den komplexeren Aufgaben wachsen die Anforderungen, und die Berufsbilder verändern sich. Und diese Veränderungen sind auch noch nicht abgeschlossen. Die Universitäten und möglichen Ausbildungswege kommen – vor allem in Deutschland – zu langsam hinterher. Gute UX-Mitarbeiter im digitalen Umfeld zu finden, ist daher eine große Herausforderung. Für alle UX-Designer, Visual Designer und User Researcher bedeutet dies kontinuierliche Weiterbildung und Hinterfragen der derzeitigen Arbeitsprozesse und Tools. Und sich Zeit für die Außendarstellung von und Aufklärung über UX zu nehmen. Für alle, die mit UX in ihren Projekten zu tun haben, bedeutet dies, sich mit den Grundlagen von guter UX auszukennen. Das gehört zum heutigen Basiswissen für alle, die in der digitalen Produktentwicklung tätig sind, einfach dazu. Dieser Artikel ist dabei hoffentlich ein Anstoß in die richtige Richtung.

Literatur Brown, T. 2009. Change by design – How Design Thinking transforms organizations and inspires innovation. New York: HarperCollins. Cagan, M. 2007. Roles and ratios. https://svpg.com/roles-and-ratios. International Organization for Standardization (ISO). 2019. Ergonomics of human-system interaction – Part 210: Human–centred design for interactive systems. Genua: International Organization for Standardization (ISO). Kumar, V. 2012. 101 Design methods: A structure approach for driving innovation in your organisation. Hoboken: Wiley. Norman, D. 1986. User centered system design: New perspectives on human–computer interaction. Boca Raton: CRC Press. Norman, D., und J. Nielsen. 2016. The definition of User Experience (UX). www.nngroup.com/ articles/definition-user-experience. Ries, E. 2011. The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business. Schleifer, A. 2018. Defining product design: A dispatch from Airbnb’s design chief. https:// firstround.com/review/defining-product-design-a-dispatch-from-airbnbs-design-chief. Sharon, T. 2016. Validating product ideas: Through lean user research. Brooklyn: Rosenfeld Media.

10  User Experience verstehen

181

Die Autorin  Inken Petersen hatte im Laufe ihrer Karriere schon viele unterschiedliche Rollen innerhalb und außerhalb von UX-Teams als UX-Designerin, Information  Architect, UX-Lead und Product Owner. Ihre Leidenschaft sind Produkte und Services mit herausragender User Experience. Dafür coacht sie als freiberufliche UX-Beraterin ihre Kunden zu UX-Strategie, UX-Management, Product Discovery und Continuous Product Discovery. Für neue Produkte und größere Relaunches erstellt sie Designvisionen mit Visions-Prototypen und baut neue und effiziente Designsysteme auf. Sie ist Mitgründerin des Product- & UX-Community-Blogs produktbezogen.de. Kontakt: [email protected]

Data Analytics Herausforderungen bei der Arbeit mit Daten

11

Jan Martens

Zusammenfassung

Mancher mag in diesem Kapitel erwarten, Lösungen zu finden für den richtigen KPI, die richtige Analysestrategie oder die richtige technische Datenplattform. Meiner Meinung nach stecken jedoch fast alle Herausforderungen in der Kommunikation zwischen Produktmanager und Analyst: Welches ist die richtige Frage und auf welchem Weg kommen wir zu einer Antwort, die Erfolg versprechend und businessrelevant ist und eine umsetzbare Handlung enthält? Erst wenn Sie sich und Ihre Organisation darauf einstellen, dieser kommunikativen Herausforderung mit den richtigen Einstellungen und der nötigen Portion Selbstkritik zu begegnen, werden Sie den erwarteten analytischen Mehrwert ernten können. Wie dies gelingen kann, wird Ihnen im vorliegenden Beitrag skizziert.

11.1 Einleitung Die Beziehung des Produktmanagers zu Daten und ihren „Aufbereitern“ ist komplex. Als ich für dieses Buch gefragt wurde, ein Kapitel darüber beizusteuern, hatte ich selber noch keine Idee, wie man am besten die Herausforderungen dieser Arbeitsbeziehung beschreiben könnte. Ursprünglich hatte ich den Wunsch, eine Art Leitfaden aufzuschreiben; eine Anleitung, nach Rezept zu arbeiten. Dies hat sich jedoch schnell als nicht sinnvoll herausgestellt: Weder befindet sich ein Produktmanager auf der grünen Wiese, auf der er komplett neu seine Datenlandschaft aufbauen kann, noch ähneln sich die J. Martens (*)  Lotto24 AG, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_11

183

184

J. Martens

Ausgangsbedingungen genug, als dass ein One-Size-Fits-All-Rezept effektive Lösungen schaffen könnte. Stattdessen habe ich mich dafür entschieden, eine Sammlung von Problembeschreibungen bereitzustellen, wegen derer man in der Praxis vielfach nicht so erfolgreich mit Daten arbeitet, wie man möchte und könnte. Dabei zeige ich – wo möglich – Wege auf, um das jeweilige Problem zu umgehen bzw. zu lösen. Es bleibt dabei Ihrer Analyse überlassen, welche der Herausforderungen auf Sie besonders zutreffen. Dabei halte ich es für denkbar und wahrscheinlich, dass viele latent sogar von mehreren Problemstellungen gleichzeitig betroffen sein könnten – nacheinander oder sogar gleichzeitig.

11.2 Rollen und Organisationen Analyst oder Scientist, was macht da eigentlich den Unterschied? Zu diesem Thema lässt sich reichlich Material im Internet finden. Allerdings ist das Bild nicht einheitlich und oftmals überlappen sich die Stellenbezeichnungen und -anforderungen auch mehr oder weniger stark. Der Data Analyst wird oftmals beschrieben als „vor Ort“ beim Produktteam arbeitend, mit häufigen direkten Kontakten zum Produktmanager (oder anderen Stakeholdern). Seine Aufgaben sind häufig kleinteiliger, eher deskriptiv, rückwärtsblickend. Er soll berichten und direkte Nachfragen beantworten. Der Data Scientist dagegen wird häufiger beschrieben als eine Person, welche zentral in einem Team Gleichgesinnter Aufgaben bearbeitet, die oftmals umfangreicher sind und einen Projektcharakter haben. Gängige Beispiele sind Modellierungen und Prognosen, die zukunftsgerichtet Entscheidungen von Kunden oder anderen Einflüssen vorhersagen sollen. Wenn ich auf den nachfolgenden Seiten vom Analysten spreche, meine ich damit immer die ganze Gruppe analytischer Rollen, egal ob Business Analyst, Data Scientist, BI-Analyst, BI-Manager oder verwandte Rollennamen. Auch sind meine Anmerkungen sowohl gemeint für Mitarbeiter in Zentralorganisation als auch direkt in Ihr Team eingegliederte.

11.3 Die Fallstricke Kommen wir zu meiner Top 12 der analytischen Herausforderungen, welche weder nach Schwere noch Häufigkeit des Auftretens sortiert sind. Zuerst konzentriere ich mich auf die Ursachen im Bereich des Stakeholders, danach folgen die Herausforderungen, die ihren Ausgangspunkt eher beim Analysten haben. Wenn Sie Ihre eigenen Probleme mit diesen Fallstricken abgleichen, bedenken Sie bitte, dass es oftmals keine eindeutige Zuordnung gibt und Sie zudem in Betracht ziehen sollten, von mehreren Fallstricken gleichzeitig betroffen zu sein.

11  Data Analytics

185

11.3.1 Die Feel-Good-Analyse Haben Sie schon mal Ihren Analysten gefragt, wie erfolgreich und wirkungsvoll eine Ihrer Entscheidungen war? Ganz bestimmt haben Sie! Es ist der Klassiker unter den hier behandelten Fallstricken und wir sind alle davon latent betroffen. Wer ist nicht auf der Suche nach Bestätigung, möchte seine Arbeit verifizieren, möchte auch für zukünftige Entscheidungen eine Bestätigung haben, dass die in der Vergangenheit getroffenen Entscheidungen richtig waren. Das Problem solcher Fragestellungen bleibt dabei: Welche Handlungsempfehlungen sollen aus ihnen erwachsen? Sehr oft gar keine. Das ganze Berichtswesen von Standardreportings über Dashboards bis hin zu Business-Balance-Scorecards und Quartalsberichten dient im Grunde ja der Überprüfung des Erfolgs der verantwortlich Handelnden. Verstehen Sie mich nicht falsch: Solche Instrumente werden gebraucht und haben ihren Zweck. Wollen Sie jedoch aus den Daten etwas für zukünftige Entscheidungen lernen, dann gucken Sie bitte nicht in Ihr Berichtswesen. Dort stehen die Antworten nicht drin. Vermeiden Sie daher, dass Ihr Analyst in deskriptive Analysen abtaucht und nachschaut, welche Effekte er eventuell finden kann, um Sie in der Großartigkeit Ihrer Entscheidungen zu bestätigen. Fragen Sie sich stattdessen, vor welchen Entscheidungen Sie zukünftig stehen werden und was Sie wissen müssen, bevor Sie Ihre Entscheidung treffen. Erarbeiten Sie sich mit Ihrem Team eine Liste von Hypothesen und priorisieren Sie die wichtigsten Hypothesen, damit Ihr Team die Beantwortung dieser Hypothesen in den Fokus stellt. Dabei ist das Erarbeiten der richtigen Hypothesen kein Selbstläufer, denn viele werden häufig aus der Sicht des Unternehmers und nicht aus der Sicht des Kunden formuliert.

11.3.2 Die Rechtfertigungsanalyse Eine Spielart bzw. Eskalation des vorgenannten Phänomens ist die Rechtfertigungsanalyse, bei der ein Druck für den Nachweis des Erfolgs auf dem Produktmanager lastet und er versucht, dem Analysten Lösungswege vorzuschreiben. Der Analyst beugt sich in der Praxis (zu) häufig dem Druck und liefert wie befohlen, bringt aber seine Lösungskompetenz nicht mehr ein. Als Resultat werden gerne Ergebnisse, mit Interpretationen von Trendlinien, wo eigentlich gar kein Effekt vorhanden ist, geschönt bzw. durch gut ausschauende ­Äpfel-Birnen-Vergleiche oder andere Instrumente aus der Rubrik „Traue keiner Statistik, die Du nicht selber gefälscht hast“ sogar gefakt. Gerade, wenn der Analyst in der Reportinglinie steht, fällt es ihm schwer, echten Widerspruch zu leisten und macht mangels Alternativen beim Aufhübschen der Ergebnisse mit. Hier ist es für den Produktmanager schwer, eigenhändig Lösungen zu schaffen, denn eigentlich ist das schon fast ein Organisationsverschulden. Versuchen

186

J. Martens

Sie in dem Fall aber, den auf Ihnen liegenden Druck nicht an Ihren Analysten durchzureichen, damit dieser Ihnen weiterhin so gut es geht reinen Wein einschenken kann.

11.3.3 Die Symptom-Analyse In jeder Firma gibt es ein Berichtswesen (siehe Abschn. 11.3.1 Feel-Good-Analyse). All diese Dashboards zeigen geschäftsrelevante Kenngrößen fast ausschließlich in Zeitreihen über unterschiedliche Zeiträume, gerne im Vergleich zu vergangenen Zeiträumen oder mit gesetzten Zielen. Unweigerlich kommt es zur Interpretation dieser Zeitreihen, und sowohl ungeübte aber auch geübte Augen kommen bei fallenden bzw. „nicht genügend steigenden“ Kenngrößen zu der Frage: „Haben wir ein Problem?“. Man kann ganze Analyse-Abteilungen mit solchen Fragen für Monate beschäftigen und Sie ahnen schon: Das könnte wenig effektiv sein. Warum ist das so? Entweder die Probleme sind extern oder hausgemacht. Viele externe Probleme oder Herausforderungen können aus dem internen Daten heraus schlecht analysiert werden, während interne Probleme eigentlich mit Werkzeugen der Qualitätskontrolle gefunden werden sollten, z.  B. Watchdogs, Softwaretests oder Meilensteine im Projektcontrolling. Symptomanalyse ist teuer, denn Fehler sollten nicht hinterher entdeckt, sondern vorher vermieden werden. Die Jagd nach dem nicht entdeckten Problem ist also in mehrerlei Hinsicht fragwürdig, aber wenn Sie es schon machen (müssen), dann erarbeiten Sie in einem Brainstorming zumindest alle relevanten Hypothesen für mögliche Ursachen und arbeiten die Hypothesen anschließend systematisch ab. Akzeptieren Sie dabei, dass auf etliche Hypothesen die Antwort lauten wird: „Im Rahmen der möglichen Messgenauigkeit ist kein Effekt zu sehen.“ Wenn alle Hypothesen hinterfragt wurden, schicken Sie Ihren Analysten nicht auf die Suche nach dem unbekannten Problem, das es vielleicht gar nicht gibt. Geben Sie sich mit den Antworten auf die Hypothesen zufrieden und konzentrieren Sie sich wieder vorwärtsgerichtet auf die anstehenden Entscheidungen der Zukunft.

11.3.4 Einfache Fragen, komplexe Antworten Die ersten drei Konfliktfelder handelten von Fragen, welche in meinen Augen aus den falschen Motiven des Produktmanagers gestellt wurden. Es gibt aber noch ein weiteres Konfliktfeld, welches aus der Rubrik „Produktmanager stellt Frage, Analyst antwortet“ stammt: Gerne erwarten Produktmanager Antworten auf ihre Fragen möglichst zeitnah und schnell, speziell, wenn in agilen Umgebungen Entscheidungen im laufenden Sprint getroffen werden müssen. Die Erwartungshaltung einfacher und sofort verfügbarer Antworten steht jedoch häufig im Widerspruch mit der Verfügbarkeit des Analysten oder

11  Data Analytics

187

seiner Einschätzung, wie lange die in seinen Augen komplexe Antwort benötigen würde. In diesem Spannungsfeld bleibt dem Analysten häufig nicht mehr, als gar keine, eine ungenügende oder eine zu späte Antwort zu liefern. Beispiel

Ein Produktteam arbeitet an einem Feature, von dem es sich einen Uplift verspricht. Der Analyst gibt zu bedenken, dass ohne einen A/B-Test und zusätzliche Datenfelder die Hypothese nicht beantwortet werden kann. Es ist aber zu spät dafür, denn das Feature ist ja schon in der Produktion. Besser wäre es, vor der eigentlichen Produktentwicklung die analytischen Fragen zu antizipieren und zu klären, welche Fragen es wert sind, getestet und beantwortet zu werden. ◄ Aus diesem Konflikt kommt man nur heraus, wenn einerseits Erwartungen und Lösungen vereinbart werden, die beide Seiten verstehen und ihnen zustimmen, und andererseits analytische Fragen weit genug im Voraus antizipiert werden, sodass benötigte Lösungen auch vorliegen, wenn Entscheidungen anstehen.

11.3.5 Selbstüberschätzung Haben Sie schon einmal voller Überzeugung etwas getan und dann hat es nicht funktioniert? Diese kognitive Verzerrung, im Englischen auch bekannt als Overconfidence Bias, trifft früher oder später jeden einmal. In geschäftlichen Umfeldern führen Entscheidungen aus Selbstüberschätzung oft zu Fehlleistungen und Risiken für das Unternehmen. In unserem Kontext ist der Produktmanager überzeugt von seinen Ideen, setzt sie um, aber das erwartete positive Ergebnis tritt nicht ein. Eine vielleicht bereits erfolgte Analyse – leider fehlerhaft ausgeführt – bestätigt den Produktmanager in seiner Idee. Aber spätestens in den Umsatz- oder Gewinnzahlen kann dann ein entsprechend gleichwertiges Resultat nicht wiedergefunden werden, was die Frage offen lässt, warum die Analyse zu einem viel positiveren Ergebnis kam. Der Fehler in der Analyse wurde nicht bemerkt, weil man zu überzeugt von der ursprünglichen Idee war und das Ergebnis nicht mehr kritisch hinterfragt hat. Im besseren Fall liefert bereits die Analyse das korrekte Ergebnis, dass die Erwartungen nicht erfüllt wurden und der Effekt viel kleiner ist, wahrscheinlich unter der Messgenauigkeit liegt, und damit nicht sichtbar ist. Selbstüberschätzung kann korrigiert werden: Ein praktisches Instrument ist die Reflexion von Erwartungen im Team, bevor das Feature umgesetzt wird. Jedes Teammitglied gibt dazu seine eigene Einschätzung zur Wirksamkeit ab, indem es seine Erwartung in der Steigerung des Ziel-KPI ausdrückt. Wenn man auf diese Weise alle wichtigen Entscheidungen eines Teams dokumentiert,

188

J. Martens

wird nach einiger Zeit die Selbstüberschätzung von Einzelnen bzw. des ganzen Teams deutlich und man kann sich an realistischeren Einschätzungen versuchen oder der Frage widmen, ob nicht andere Handlungen sinnvoller wären, wenn die Entscheidungen der Vergangenheit so wirkungsarm waren.

11.3.6 Selbstverliebtheit Nachdem ich mich jetzt reichlich auf Ihren potentiellen eigenen Fehlern ausgelassen habe, wird es Zeit, meine eigene Zunft auch nicht unverschont zu lassen: Analysten und Datenwissenschaftler haben schon tolle Werkzeuge, die man inhaltlich oft nicht wirklich versteht, oder? Wie auch? Sie sind komplex und es ist der Job des Analysten, diese zu verstehen und richtig zu nutzen. Es kommt regelmäßig vor, dass der Analyst das Werkzeug benutzt, das ihm am meisten Spaß macht, welches er schon immer mal ausprobieren wollte, das ihn persönlich am meisten weiterbildet bzw. mit dem er Erfahrungen sammeln möchte. Dabei wird nicht priorisiert nach Effektivität, sondern nach Vorliebe. So kommen statt einer einfachen Prognosemethode, wie einem simplen Entscheidungsbaum, schnell ein neuronales Netz oder andere innovative Methoden zum Einsatz. Der Mehrwert solch fortschrittlicher Werkzeuge ist von außen kaum herauszufinden. Deswegen ist es erforderlich, dass die Analyse-Abteilung selbstreflektiert ihre Werkzeugwahl begründen kann und Auskunft darüber gibt, wie viel besser eine komplexe Methode gegenüber einer Standardmethode ist. Das alles muss sich aber wirtschaftlich rechnen. u

Fordern Sie Ihren Analysten ruhig heraus und verlangen Sie, dass er Ihnen erklärt, warum er sich für die eine Lösung entschieden hat. Lassen Sie sich erklären, warum die komplexere Lösung die bessere ist und geben Sie sich nicht mit der Antwort zufrieden, es sei eine Blackbox und man müsse der Empfehlung des Modells blind vertrauen. Für Ihre nächsten Schritte müssen Sie sowieso nachvollziehen können, was die Blackbox kann und was nicht.

11.3.7 Einfach falsch In der Vergangenheit habe ich etliche Analysen zu sehen bekommen, in denen kleine aber folgenschwere Fehler steckten. Sie können an den unterschiedlichsten Stellen einer Analyse auftauchen: bei der Konzeption, der Datenerhebung und -bereinigung oder in der Ergebnisdarstellung bzw. in der -interpretation. Jede Entwicklungsabteilung testet ihren Softwarecode, und so sollte auch jede analytische Abteilung ihre Analysen auf Richtigkeit überprüfen. Dies ist jedoch leichter gesagt als getan, denn die Fehler äußern sich in verfälschten Ergebnissen, von denen ja per Definition keiner weiß, ob sie richtig oder falsch sind. Auf einmal ist ein A/B-Test mit einem überraschenden Ergebnis hochsignifikant und das Produkt wird entsprechend

11  Data Analytics

189

umgesetzt. Auch hier wundert man sich Monate später, warum man keine entsprechende Wirkung im Ergebnis des Unternehmens sieht. Fehlererkennung in der Analytik ist anspruchsvoll. Der einzige Weg ist die Übertragung wissenschaftlicher Werkzeuge auf den Betrieb im Unternehmen: Interne Revision analytischer Ergebnisse, 4- oder noch besser 6-Augen-Prinzip, Code-Review, Unabhängigkeit der Analyse, Redundanz und Wiederholbarkeit. All das kostet leider Geld und Zeit und wird deshalb gerne auch zur Kritik für eine Minderleistung bzw. Langsamkeit herangezogen. In der Praxis verwende ich folgende Instrumente, um diese Risiken zu minimieren: Je relevanter und überraschender ein Ergebnis ist, je mehr Zeit und Aufwand verwenden wir auf den internen Kontrollprozess. Wir haben schon SQL-Queries ein zweites Mal unabhängig geschrieben, um die Fehlerfreiheit zu verifizieren. Produktmanager versuchen oft Zwischenergebnisse abzugreifen, welche sich gerne verselbstständigen und die Runde machen, bevor das Ergebnis stimmig ist. Wenn dann das finale Ergebnis anders aussieht, ist die Verwunderung groß und manchmal schmerzhaft. Seien Sie also geduldig! Wenn Ihr Analyst sagt, „Das überprüfen wir noch“, dann hat das sehr wahrscheinlich einen guten Grund. Ich bin kein Fan von zentralistischen Datateams und möchte lieber die Analysten in den Produktteams sitzen und arbeiten sehen. Dennoch sollten sie dort, wenn irgendwie möglich, zumindest in Paaren arbeiten können, um Kontrollprozesse in der täglichen Arbeit, also in möglichst kurzen Iterationsschleifen, zu ermöglichen: Ein analysierter komplexer multivariater A/B-Test sollte nicht erst in die Fehlerüberprüfung, wenn alles formschön zusammengeschrieben ist, sondern frühzeitig und niederschwellig vom Sitznachbarn geprüft werden. Diese Herausforderung ist natürlich umso größer, je kleiner das Unternehmen und die Zahl der Analysten sind. Und was, wenn es nur einen Analysten gibt? Wie kontrolliert er sich dann selber? Auf diese Fragen habe ich noch keine befriedigende Antwort gefunden.

11.3.8 „Nicht signifikant“ „Nicht signifikant“ habe ich schon häufiger als einzige Antwort von Analysten gehört und das führte in erster Instanz zu Handlungsempfehlungen wie „kein Ergebnis“ oder „keine Empfehlung“. Das ist in meinen Augen zu kurz gegriffen. Ein einfacher Wechsel in die Perspektive des Produktmanagers macht dem Analysten gewöhnlich klar, dass ja in jedem Fall eine Entscheidung getroffen wird, und sei es nur die Entscheidung, alles so zu lassen, wie es ist. Den Produktmanager mit seiner Entscheidung alleine zu lassen und die Verantwortung von sich zu schieben, erscheint gelegentlich zwar verlockend, ist unternehmerisch aber keine Lösung. Deshalb sollte jede Handlungsempfehlung die möglichen Optionen im Kontext von Wert und Risiko betrachten. Auch ein nicht signifikantes Ergebnis führt immer zu einer Handlungsempfehlung, die die Produktbedingungen und die Relevanz der Entscheidung

190

J. Martens

berücksichtigt. Wenn das der Analyst nicht hinbekommt, macht er seinen Job nicht richtig. In der Konsequenz übernimmt die finale Interpretation der Ergebnisse wieder der Produktmanager, da die Handlungsempfehlungen für ihn nicht stringent sind. Es gibt aber auch das entgegengesetzte Problem: Der Analyst gibt völlig zu Recht das Feedback, dass eine Handlungsempfehlung nicht gegeben werden kann, da die Daten nur zufällig ein Signal vortäuschen. Machen Sie sich als Produktmanager daher also mit der Sprache der Statistik vertraut und fragen Sie nach, was mit „signifikant“ oder „nicht signifikant“ inhaltlich gemeint ist. Wie viel Zuverlässigkeit in den Empfehlungen des Analysten stecken, sollte immer Teil Ihrer Entscheidungsfindung sein. u

Was ist überhaupt signifikant und was ist relevant? Ein zehnprozentiger Umsatzanstieg ist sehr wahrscheinlich in vielen Geschäftsfeldern relevant. Sind es nur 0,1 % werden viele schon sagen, das sei nicht wichtig genug. Relevanz würde ich vereinfacht mit Wichtigkeit übersetzen. Trotzdem können die 10 % nur zufällig sein, also nicht signifikant, aber die 0,1 % signifikant, und damit eine zuverlässige Aussage.

11.3.9 Zu anspruchsvoll Das Aufgabenprofil eines Analysten ist sehr breit und reicht von der adressatengerechten Kommunikation mit analytisch Fachfremden und Projektmanagementfertigkeiten über ein tief gehendes Verständnis über das Produkt, mathematisch-statistischen Fertigkeiten bis hin zu Fachkenntnissen in unterschiedlichen Programmiersprachen. Dieses Profil ist anspruchsvoll und viele tun sich schwer damit, in allen Bereichen gute Ergebnisse zu erzielen. Selten (eigentlich nie) findet man Bewerber, die schon umfassend für dieses Profil ausgebildet sind. Trotz aller Ausbildungsbemühungen stelle ich noch immer fest, dass dieses Profil so anspruchsvoll ist, dass ich bei der Personalauswahl eine hohe Ablehnungsquote habe. Deswegen braucht es ein betriebsinternes Ausbildungskonzept, das jemand Fachkundiges betreuen muss. Diese Person existiert oftmals nicht, und so muss sich das analytische Team gegenseitig schulen oder man kauft ein entsprechendes Wissen ein. Trotzdem empfehle ich Ihnen, Ihre analytischen Kollegen in ihrer Qualität zu hinterfragen und zu optimieren. Als Produktmanager haben Sie hier eventuell nur wenige Einflussmöglichkeiten. Versuchen Sie aber dennoch, den verantwortlichen Einstellenden von der Breitbandigkeit des Jobprofils zu überzeugen und den Fokus nicht nur auf die technisch-mathematischen Fertigkeiten zu legen. Außerdem sollten Sie den Analysten anleiten als sei er Ihr Junior-Produktmanager. Er sollte Ihre Handlungsmuster und Motive nachvollziehen können. Eine weitere mögliche Quelle von Schwierigkeiten kann in dem Zusammenhang ein zu großer räumlicher und ein damit oft einhergehender mentaler Abstand zwischen dem Produktmanager und dem Analysten sein. Wenn sich die beiden zu selten im operativen

11  Data Analytics

191

Betrieb sehen oder treffen, werden die vom Analysten vorgeschlagenen Lösungen Gefahr laufen, nicht die wirklichen Probleme des Produktmanagers zu adressieren. Andersrum wird der Produktmanager nicht alle Rahmenbedingungen des Analysten nachvollziehen können. Besonders gefährdet sind zentral organisierte Data-Science-Teams, welche für sich räumlich platziert oftmals als businessfremd wahrgenommen werden. Sie erzeugen dann nicht den erhofften Mehrwert, wodurch sich der Produktmanager als Konsequenz seinen eigenen Analysten vor Ort einstellt. Das führt in der Praxis gerne zu der Trennung von Data Science und Data-Analytik, wobei der einzelne „Vor-Ort-Analyst“ von den Fragestellungen schnell überfordert sein kann, da ihm häufig die oben genannten Werkzeuge und Weiterbildungsmöglichkeiten fehlen. Fordern Sie von Ihrer Zentralabteilung daher in dem Fall, dass sich die Analysten in Ihrem Team regelmäßig blicken lassen, und zwar nicht nur für die Meetings sondern tage- oder wochenweise lokal eingebunden in Ihr Team.

11.3.10 Fehlende Distanz – Sunk costs Gerade in kleinen Teams und Startups gibt es oft keine echte Trennung zwischen Produktmanager und Analyst. Gerne kommt es auch zur Personalunion dieser Rollen. Dann bleibt vielfach wenig Raum für Abstand und Kritik, weil auch der Analyst erfolgsorientiert handelt und den gleichen potentiellen Herausforderungen erliegt und nicht kritisch genug gegenüber seiner eigenen Analysetätigkeit ist. Manchmal sind die Analysten auch direkt disziplinarisch dem Produktmanager unterstellt. Dies macht sie abhängig und eingenommen in ihrer Tätigkeit und schränkt sie ein, kritisch mit Herausforderungen umzugehen. Sollte Ihr Analyst Ihnen oder Ihrer Abteilung direkt weisungsgebunden sein, ziehen Sie daher in Erwägung, Ihrem Analysten ein Stück weit „Narrenfreiheit“ zu gewähren und seinen Ansichten einen gewissen „Minderheitenschutz“ einzuräumen. Ansonsten werden sich die Produktmanager nur selbst bestärken in ihren getroffenen Entscheidungen und zu spät Fehlentscheidungen revidieren.

11.3.11 Zu wenig Daten Mathematik und Analytik können nicht zaubern und es gibt einfach einen Bereich, in dem sich Relevanz und Signifikanz nicht begegnen: im Tal der zu kleinen Stichprobe. Gerade im Neukundengeschäft von Startups sind Daten teuer, denn jeder Kunde muss eingekauft werden. Wenn dann der Analyst für die Beantwortung einer Frage sagt, dafür bräuchte er X Kunden oder Y Klicks, dann wird die Beantwortung der Hypothesen zu einer Frage des Budgets. Im Lebenszyklus der Produktentwicklung sind viele analytische Werkzeuge also eher später anzuwenden, während viele grundlegende Entscheidungen eher früh im Produktleben anstehen. Dies erzeugt ein Spannungsfeld, welches sich nur bedingt auflösen lässt. „MVP“, „Fail fast“ oder wie die Konzepte heißen mögen: Alle sollen die fundamentalen

192

J. Martens

Produktentscheidungen zu einem frühen (und günstigen) Zeitpunkt ermöglichen. Es bleibt aber der Konflikt, dass man immer getrieben ist zwischen den beiden Polen von Schnelligkeit und Gründlichkeit im Produktlebenszyklus. Jedes Unternehmen mit einem genügend großen Reservoir an Bestandskunden darf sich da glücklich schätzen, vergleichsweise einfach Alternativen testen zu können. Daher ist hier eine grundsätzliche Herausforderung der Analytik enthalten. Signifikanz und Relevanz von analytischen Fragestellungen und Antworten stehen immer in einem Konflikt. Die Mikrokonversion einer Webseite lässt sich signifikant optimieren, ist aber eventuell nicht relevant für den Geschäftserfolg. Eine Testhypothese zur Erhöhung des Customer Lifetime Value erfolgreich zu validieren, wäre selbstverständlich hochrelevant, jedoch ist ein signifikantes Testdesign extrem anspruchsvoll herzustellen. Es bleibt Aufgabe des Analysten, zwischen diesen beiden Extremen zu vermitteln und einen Weg aufzuzeigen, der beide Seiten kombiniert.

11.4 Fazit Aus den zuvor beschriebenen Problemen und Herausforderungen folgen aus meiner Sicht die folgenden Empfehlungen für eine gute Zusammenarbeit zwischen Produktmanagern und Data Analysten: • Reden Sie immer wieder mit Ihrem Analysten. Optimieren Sie die Kommunikation mit ihm kontinuierlich. • Reden Sie zielgetrieben mit Ihrem Analysten. Erklären Sie ihm, was Ihr Problem ist, und nicht, was für eine Lösung Ihnen vorschwebt. • Hinterfragen Sie den Erfolg und die Effektivität der gelieferten Services. • Verstehen Sie Daten auch als Werkzeug zum Lernen, nicht nur zum Kontrollieren: Daten können Entscheidungen rechtfertigen oder bestätigen, aber erst die Beantwortung einer kontroversen Hypothese erschafft einen Mehrwert. Erlauben Sie unterschiedliche Meinungen – mehr noch: Fordern Sie unterschiedliche Meinungen ein. • Akzeptieren Sie die Grenzen der Analytik und der Data Science. Jede Frage benötigt ihre Datenquelle, um sie richtig beantworten zu können. Fordern Sie von Ihrem Analysten, diese Grenzen im Sinne der zu treffenden Entscheidungen klarzustellen. Gelingt es in einem Unternehmen, ein wechselseitiges echtes Verständnis zwischen Produktmanagern und Data-Analysten zu erzeugen, bedeutet dies für den Kundennutzen der Produkte und damit letztlich auch für das Unternehmen einen ungeheuer großen Mehrwert. Der Autor  Jan Martens arbeitet als Director Data Science und Analytics für die Lotto24 AG. Nach dem Studium der Physik hat er 13 Jahre in der Halbleiterindustrie gearbeitet. Seit 6 Jahren leitet er analytische Teams im E-Commerce. Kontakt: [email protected]

Growth Die Sache mit dem Wachstum

12

Markus Andrezak

Zusammenfassung

In der Wirtschaft reicht es nicht, einfach nur gute und wirtschaftlich erfolgreiche Produkte auf den Markt zu bringen. Allzu oft müssen die Wachstumszahlen auch noch kontinuierlich bzw. sogar exponentiell steigen, um die versprochenen Unternehmensziele zu erreichen. Der Beitrag zeigt, dass sich Wachstum aber nicht einfach „ansagen“ lässt, sondern das Ergebnis von harter, langwieriger Arbeit ist. Dabei benötigt ein Unternehmen neben dem Mut, unterschiedliche Arbeitsweisen innerhalb seiner Organisation zuzulassen, immer auch eine große Portion Glück.

12.1 Alle wollen Wachstum Growth! Wachstum! Alle wollen es, alle suchen es. Warum das so ist, wissen wir nicht ganz genau. Vielleicht ist es einfach dem Aktien- bzw. Venture Capital-Markt geschuldet, getrieben vom Wunsch der schnellen Vermögensvermehrung. Wachsen, größer werden, mehr Umsatz machen, mehr Angestellte – all das strebt fast jede Firma an. Und wenn eine Firma mit diesem Credo bricht, wie etwa Patagonia, dann kann sie damit gleich Werbung machen – und trotzdem weiter wachsen… Schon in den 70er und 80er Jahren des letzten Jahrhunderts war der vom Club of Rome beim MIT ausgeführte Bericht „Limits of Growth“ in aller Munde. Wer damals

M. Andrezak (*)  überproduct GmbH, Potsdam, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_12

193

194

M. Andrezak

zur Schule ging, dem war bewusst, dass Wachstum nicht unendlich funktionieren kann. Es war sogar schon klar, wie komplex lokales Geschäft und globales Wachstum miteinander zusammenhängen. Das Wissen ging auch in den Kanon der Betriebswirtschaftslehre und Volkswirtschaftslehre ein. Was wir aber entgegen dieses Wissens in der Wirtschaft beobachten, ist ein emotional getriebener fortbestehender Drang nach Wachstum. Wer möchte schon eine Firma oder ein Produkt managen, die nicht wachsen? Da im Kleinen alle weiter wachsen wollen, wächst auch global alles weiter. Und wenn es mit dem Wachstum einmal nicht klappt, weil Blasen platzen, dann muss man die Zinsen drücken und schon geht es doch noch mal ein Stückchen weiter. Platzt die Blase endgültig, werden die Banken gerettet, ein paar Konsumenten geopfert, ein Wachstumsprogramm aufgelegt und weiter geht’s… In der Rolle als Produktmanager ist es relativ wenig karrierefördernd, in jedem Gespräch mit Vorgesetzten bzw. Auftraggebern der Vernünftige zu sein und immer wieder auf Ressourcenschonung abzuheben, den Bericht des Club of Rome hervorzuziehen und auf „No Growth“ zu bestehen. Deswegen wird es im Rest des Beitrags nun darum gehen, wie man gezielt Wachstum erarbeiten kann. Man könnte meinen, im Digitalen sei alles anders: Unsere Güter sind nicht greifbar und der Gedanke, wir verbrauchten nicht so viele Ressourcen, ist verführerisch. Das fängt bei Programmiersprachen an, die vorhandene Rechnerressourcen wie perfektes Gas zu jeder Zeit ausfüllen – und sei es für eine Notizbuch-App. Das ökonomische Modell der Bewertung der meisten Produktmanager ist dementsprechend auch nicht, akribisch herauszufinden, welches Feature wie viel zum Umsatz beiträgt, sondern viel mehr: Wir haben 200 Entwickler, die sind und waren teuer – Hauptsache, sie haben immer gut zu tun. Gerade wie in den Anfangszeiten der Industrialisierung, nur eben mit Programmierern. In diesem Kapitel geht es vornehmlich um das Wachstum aus Neuem und nicht um das Wachstum, das aus der Pflege von Bestehendem resultiert. Denn zweiteres ist immer linear. Diese Art von Wachstum beherrschen wir in der Regel ganz gut. Der Schmerz entsteht aus unrealistischen Vorstellungen in Bezug auf Wachstum aus Neuem. Schwierig wird es, wenn der Chef oder die Organisation „Hockey-Stick-Growth“ bzw. ­„Triple-Digit-Growth“ oder ähnlich Populäres „in Auftrag“ geben. u

„The purpose of business is to create and keep a customer“ – (Peter Drucker 1973).

Wachstum entsteht aus der ersten im Satz beschriebenen Aufgabe. Der zweite Teilsatz sorgt dafür, dass wir nicht untergehen. Ein Problem im Wachstum ist, dass Firmen ab einer gewissen Größe fast nur noch Mechanismen kennen, die dabei helfen, Kunden nicht zu verlieren. Kunden zu gewinnen geht aber ganz anders. Es fühlt sich unsicherer an. Und man weiß nicht so genau, ob es klappt. Die Kultur vom Kunden-Halten und vom Bewahren hilft aber nicht viel beim Kunden-Gewinnen.

12 Growth

u

195

„Satisfying a large group of users is a by-product of satisfying one user. Satisfying nobody is a by-product of trying to satisfy a large group of users“ (Alan Cooper 2019).

Dieser Satz beschreibt die Dialektik, die Wachstum so schwer für uns macht: Wir wollen möglichst schnell für viele Kunden attraktiv sein. Wir müssen aber den Umweg gehen, erst einmal sehr wenige Kunden sehr gut und gründlich zu bedienen. Das Rezept, das wir benötigen, um viele zu bedienen, liegt in der Abstraktion und Vereinfachung. Gute Produkte für die Massen sind immer ein Kompromiss. Ein guter Kompromiss, der vielen irgendwie gefällt. Die dafür notwendige Abstraktion und Vereinfachung, das Rezept, können wir aber nur „zu Fuß“ entdecken und lernen, durch wiederholtes Bedienen von Wenigen. Oder kürzer und einfacher: „There is no overnight success.“ – Es gibt keine Abkürzung. Auch Karinas Chef will Wachstum

Karina ist eine Produktmanagerin, wie wir alle. Karina kommt schockiert aus einem One-on-One-Meeting mit ihrem Chef zurück zu ihren Kollegen. Sie ist Teil eines Scrum-Teams. Wie es sich gehört, ist man co-located und teilt fast alles miteinander. Man versteht sich gut. Man arbeitet gut zusammen. Die Kollegen riechen Lunte und nach einer Karenzzeit, die Karina dringend zur Erholung benötigt hat, kommt die Frage, die kommen muss: „Was war denn?“ Karinas E-Mail funktioniert noch. Gekündigt wurde ihr also nicht. „Martin [ihr Chef] hat in seinem Excel-Sheet eine tolle Opportunity gefunden.“ Ein Business Analyst (Big Data, klar!) hat ihm geflüstert, dass im Funnel des Produktteils, den Karina betreut, nicht alles läuft, wie es die Benchmarks anderer Produkte versprechen. Da müsste doch was zu machen sein… Der Rest ging ganz schnell: 23 % Wachstum in ihrem Bereich müssten ja wohl zu machen sein in den nächsten beiden Quartalen..! ◄ Der eine oder andere wird sicher schon einmal die Forderung nach Hockey-StickGrowth, „Wachstum über dem Markt“ oder ähnliches gehört haben. Karina soll immerhin „nur“ zur Benchmark hin optimieren. Flugs ist das Ziel als Objective eines OKRs definiert.1 Nun darf Karina die Neuigkeiten ihrem Team überbringen. Für das Team ist das alles ein kleiner Schlag ins Gesicht: Man geht gerade wegen eines ähnlichen Meetings vor ein paar Monaten ganz anderen Zielen nach. Vor allem hat man ganz andere, qualitative Hinweise, was die Kunden gerade von einer höheren

1Zum

ausführlichen OKR-Konzept s. Kap. 6 von Sonja Mewes.

196

M. Andrezak

Zufriedenheit abhält. Das Team macht sich trotz allem Frust daran, die fehlenden Key Results für das Objective hinzubasteln. Dabei gibt es mehrere Probleme: • Das Team weiß noch gar nicht, was Kunden von der Conversion abhält, es fehlt qualitatives Wissen. • Das Team weiß gar nicht genau, was mit Wachstum gemeint ist. Und: Darf man dafür Marge opfern? • Dem Team ist der direkte Zusammenhang zwischen ihrem Produktteil und Wachstum nicht klar. • Sind 6 Monate ernst gemeint oder nur eine Größenordnung, ein gedachter Ansporn? Selbst wenn das nächste One-on-One schon vor der Tür steht: Die Verunsicherung ist groß und die Hoffnung auf wirkliche Klärung vage. Die Uhr aber tickt. Natürlich habe ich mir Karina ausgedacht. Ich kenne aber viele Karinas in sehr ähnlichen Situationen. Vielleicht noch kurz zwei Begebenheiten aus meinem eigenen Produktleben: Ich habe einmal in einer Firma gearbeitet, die mit ca. 17 % pro Jahr gewachsen ist. Im Jahr 2008 machten wir ca. 120 Mio. EUR Umsatz. Das Motto war dann plötzlich „210 in 2010“. Dazu hatten wir noch ca. 18 Monate Zeit. Ein einfaches Rückrechnen machte klar, dass wir das Wachstum ab dem Tag der „Verkündung“ mehr als verdoppeln müssten, um ein Ansteigen des Umsatzes um mehr als 50 % hinzubekommen… Jeder normale Mensch hätte wissen müssen, dass ab diesem Tag in der Firma kein Stein mehr auf dem anderen hätte bleiben dürfen, um diese Ziele zu erreichen. Wahrscheinlich war das auch jedem klar. Aber: Mehr Veränderung war wohl nicht zu ertragen. Also arbeitete man eigentlich weiter wie bisher, nur unter einem anderen Motto, ein bisschen anders organisiert, ein bisschen „agiler“ und hoffte. Fragen nach der Ernsthaftigkeit der Zahlen wurden stets mit „doch so meinen wir das“ beantwortet, ebenso Fragen nach dem Zeithorizont. Sträflich vermisst wurde Hilfe, die über ein Ausgeben des Mottos hinausging. Der Zynismus behielt recht: Das Ziel wurde bei weitem verfehlt. Die zweite Begebenheit: In derselben Firma durfte ich später eine frühe iPad-App bauen. Alle schauten auf das schöne neue Gerät. Fast jeder war irgendwie Stakeholder. Der CEO kam dann auf die gut klingende Vorgabe, ich solle mit der Veröffentlichung der App 35 % Mobile Traffic erreichen. 30 % hatten wir schon – und jedes Jahr zu Weihnachten kamen durch neu verschenkte Smartphones mit neuen Mobiltarifen automatisch Prozente hinzu. Die netten Verwandten bekamen neue Smartphones, Datenrate inklusive. Das klang erst einmal nicht so schlimm. Die Frage war aber: Warum 35 %? Wären 50 % besser oder schlechter als 35 %? Eigentlich wussten wir das nicht so genau. Denn wir wussten nicht, wie und ob unser mobiler Traffic überhaupt monetarisiert werden, also Umsatz bzw. Gewinn bringen würde. Mein Verdacht ist bis heute, dass es einfach um einen markigen Spruch ging und mehr klingt nun mal entschlossener als differenzierte

12 Growth

197

Diskussionen darüber, welche Ziele des Produkts über erhöhte Werbeeinnahmen hinaus überhaupt Sinn machen. Anspruch auf Wachstum begegnet uns auf allen Ebenen: Firma, Portfolio, Produkt, Teilprodukt usw. Um in solchen Situationen besser bestehen zu können und besser mitdiskutieren zu können, will ich nun vorstellen, was wir zu Wachstum wissen, wo es entsteht und welche Modelle es gibt, um Wachstum zu verstehen. Am Ende will ich noch erklären, was man können muss, um Wachstum managen zu können. Ich hoffe, dass Produktmanager dann ein wenig besser mit Forderungen nach Wachstum umgehen können, um kein uninformiertes „Klar, mache ich!“ oder ein renitentes „Nein, das klappt ja nie“ äußern zu müssen, sondern besser in eine differenzierte, klärende Diskussion einsteigen zu können. Meiner Erfahrung nach hilft das zwar nicht kurzfristig bei jedem Auftrag. Diskussionen über diese Modelle immer wieder anzubringen, hilft aber mittel- und langfristig, ein Bewusstsein dafür zu schaffen.

12.2 Wie lange dauert Wachstum? Wer weiß aus dem Kopf, wie lange es Facebook gibt? Wie verlief das Wachstum bekannter Produkte wie das des Ford Model T? Wie lange dauert Wachstum normalerweise? Wie viel muss man dafür tun? Kann man sich Wachstum oder die Idee dazu einfach ausdenken? Wie kommt jemand darauf, dass tolles Wachstum einfach so klappt? Und wenn wir es versuchen: warum ist es dann so schwer? Gab es schon einmal plötzliches Wachstum? Einfach so, über Nacht? Warum scheint unser Gründer nicht mehr zu wissen, wie schwer, zäh und kriechend langsam Wachstum für ihn selber am Anfang war? Um mehr über Wachstum zu lernen und Erwartungen auf Wachstum realistischer einschätzen zu können, hilft es, sich das Wachstum bekannter Produkte anzuschauen.

12.2.1 Henry Ford und das Model T Die Wachstumskurve des Model T ist recht beeindruckend: selbst die heutigen Zahlen von Tesla wiesen eine sehr ähnliche Kurve auf. Und das, obwohl Tesla sich wirklich Mühe gibt, über einen visionären CEO, modernste Fertigungstechnik und Berater aus aller Welt verfügt. So wie Ford den Verbrennungsmotor und den Vergaser etablieren musste, muss Tesla heute den batteriebasierten E-Antriebsstrang erforschen und etablieren. Beide Unternehmen sind unglaublich erfolgreich in dem, was sie tun. Beide sind von beeindruckenden Persönlichkeiten geleitet. Und dennoch: Die Statistiken des Wachstums sind in Jahren zu betrachten, nicht in Monaten, s. Abb. 12.1. Wachstum geschieht auch heute nicht in Monaten. Im ersten Jahr fertigte Ford gerade ein-

198

M. Andrezak 2,011

1,922 1,912

1,554 1,301

941 735 501

11

19

35

69

170

203

308

972

664 498

400

1909 1910 1911 1912 1913 1914 1915 1916 1917 1918 1919 1920 1921 1922 1923 1924 1925 1926 1927

Abb. 12.1   Produktionszahlen Ford Model T (in Tsd.). (Quelle: Eigene Darstellung mit Daten vom Model T Ford Club of America 2020)

mal 10660 Ford Model T. Im zweiten Jahr dann fast eine Dopplung auf 19.050 Einheiten, schließlich weit weniger als eine Verdopplung, irgendwann ein unglaublicher Produktionssprung. Ab 1919, zehn Jahre nach der Einführung, stotterte dann der Wachstumsmotor und nach 1927 erfolgte das Sunsetting, die Einstellung des Model T. Viel spannender als die eigentliche Wachstumskurve des Produkts ist aber die Vorgeschichte. Wer weiß schon, dass Henry Ford ab seinem 28. Lebensjahr (1891) für ca. acht Jahre bei Thomas Alva Edison als Chefingenieur gearbeitet hat? In seiner Rolle als Chefingenieur hatte er den Vergaser patentieren lassen und das Quadricycle (einen Vorläufer des Autos) gebaut. 1899 gründete er dann Ford und nach einigen Irrungen und Wirrungen mündete 1903 alles in der Henry Ford Company. Das erste Model T war also die Frucht aus 18 Jahren Vorarbeit; davon alleine sechs in Fords eigener Firma.

12.2.2 Das iPhone Abb. 12.2 zeigt die Absatzmengen des vielleicht erfolgreichsten Produkts aller Zeiten. Auch hier ein vergleichsweise bescheidener Anfang: Während heute, zu Zeiten der Stagnation der Verkäufe, nach „nur“ 13 Jahren ca. 217 Mio. iPhones pro Jahr verkauft werden, wurden vom ersten Modell im ersten Jahr „gerade einmal“ 1,4 Mio. iPhones verkauft. Die Presse konnte sich nicht einigen, ob das ein Erfolg war oder nicht. Ob das iPhone kommerziell funktioniert oder nur eine brillante Erfindung sei. Hätte man die Erwartungen dieses Erfolges an das Originalteam herangetragen, wäre dies zum einen lähmend für die Kreativi-

12 Growth

199 231 212

217

218 185

169 150 125

72 40

1 2007

12 2008

21

2009

2010

2011

2012

2013

2014

2015

2016

2017

2018

2019*

Abb. 12.2   Absatz von Apple iPhones weltweit (in Mio.). (Quelle: Statista 2020)

tät hinter der Innovation gewesen. Vor allem aber wären die initialen 1,39 Mio. verkauften Modelle wahrscheinlich als Misserfolg verbucht worden. So geht es heute noch der Apple Watch. Not big enough – obwohl ihre Absatzzahlen höher sind als die von Rolex. Wachstum ist also schwer zu beurteilen. Und sehr relativ: Für Apple ist der Verkauf einer Millionen Einheiten nichts, wenn man von der Größe ihrer Kundenplattform ausgeht. Auch hier ist die Zeit zum wirklichen Erfolg nicht in Wochen oder Monaten, sondern in mehreren Jahren zu messen.

12.2.3 Digitale „Wachstumswunder“ Man könnte auf die Idee kommen, dass die Beispiele aus der Welt der Hardware in einem Buch zu digitalem Produktmanagement irreführend sind. Schauen wir uns also ein digitales, sehr erfolgreiches Produkt an: Facebook! Facebook wurde schon 2004 gegründet. Facebook ist zum Zeitpunkt der Veröffentlichung dieses Buches also ein renitenter Teenager von 16 Jahren. Bis 2008 war das Wachstum noch recht gemächlich, wie Abb. 12.3 zeigt. Zur Erinnerung: Damals dachte Studi-VZ auch noch, man könne Facebook – zumindest lokal – Konkurrenz machen. Die Firma, die Studi-VZ operativ führte, ging dann 2017 mit 45 Mio. EUR Schulden in den Konkurs. Das klingt nach sehr viel Geld. Tatsächlich kumulierte das erfolglose Netzwerk damit in all den Jahren aber nicht einmal so viele Schulden, wie Facebook heute jeden Tag an Gewinn macht.

200

M. Andrezak 1,591 1,393 1,228 1,056 845 608

360 145 1

6

12

2004

2005

2006

58 2007

2008

2009

2010

2011

2012

2013

2014

2015

Abb. 12.3   Anzahl der Facebook-Nutzer weltweit (in Mio.). (Quelle: Statista 2016)

Die Explosion von Facebook kam von 2008 auf 2009, wie Abb. 12.3 zeigt. Das fällt auffällig mit der Einführung des Like-Buttons im Februar 2009 zusammen. Gibt es also doch das „Killer Feature“, das alleinstehend Wachstum auslöst? Wahrscheinlich nicht. Wahrscheinlicher ist, dass bereits in den Jahren vor 2008 und 2009 die Grundlagen für das Geschäftsmodell basierend auf Kundendaten und daraus abgeleitetem Targeting gelegt wurden. Der Like-Button war dann nur ein weiteres Feature, um das Engagement zu erhöhen und zur „Krake“ zu werden. Er ist ein Symptom für ein gefundenes Rezept. Wenn man fragt, wer einen „Overnight Success“ kennt, erhält man gelegentlich als Antwort „Flappy Birds“. Solange sich das Gegenteil nicht beweisen lässt, mag dieses Online-Spiel eventuell die große Ausnahme sein. Allerdings war der Erfolg auch so schnell vorbei, wie er kam. Der „Erfinder“ gab schnell entnervt auf. Am Ende beging er Selbstmord. Ein weiterer Verdacht ist Pokémon GO. Allerdings baut Pokémon GO auf der Markenkraft von Pokémon und der Verbreitung von Nintendo auf. Gewichtiger aber ist, dass der „Erfinder“ von Pokémon GO mit diesem Spiel die Früchte von ca. 20 Jahren Arbeit einfuhr. John Hanke arbeitete seit ca. 1995 an Computerspielen. 2001 gründete er die Firma Keyhole, die große Geolocation Software baute. Immer schon wollte Hanke diese für Unterhaltung einsetzen. Keyhole wurde für Google Maps, Street View und Google Earth eingesetzt. Mit der Hilfe von Google gründete er schließlich Niantic, die Firma, die den Vorläufer von Pokémon GO, „Ingress“, veröffentlichte und nach all den Jahren Arbeit an den Grundlagen nun innerhalb eines Jahres eine Million Spieler rekrutierte. Beeindruckend – aber kein Overnight Success. Pokémon GO baute auf denselben Daten auf und hat mit anderer Spielmechanik inzwischen über eine Milliarde Downloads zu verzeichnen. Wachstum braucht also Grundlagen!

12 Growth

201

12.3 Wachstumssprünge in zwei Phasen Wachstum entsteht auf verblüffend vorhersagbare Weise: Während des Wachstums durchläuft ein – werdendes – Produkt verschiedene Phasen mit sehr unterschiedlichen Herausforderungen. Jede dieser Phasen erfordert ein anderes Denken und Vorgehen sowie eine andere „Kultur“. Es ist wichtig, die unterschiedlichen Phasen zu verstehen, um mit den spezifischen Herausforderungen umgehen zu können. u

Eine kleine Warnung am Rande: Sowohl die Modelle in diesem Abschnitt als auch die im nächsten Abschnitt bereiten einen zwar intellektuell auf das Kommende vor. Treten die vorhergesagten Phänomene aber auf, trifft es einen doch fast wie unvorbereitet und der Umgang mit den Schwierigkeiten bleibt oft emotional schwer. Hier hilft es, noch einmal in die Modelle zu schauen, um entspannter mit der Lage umgehen zu können: „Ach so, war ja klar und vorhersagbar, dass das passieren würde.“ Wachstum ist halt meist nur schön, wenn es schon passiert ist…

Simon Wardley (2018) hat mit seinem Visualisierungs- und Denktool für Strategie, den Wardley Maps, ein Modell zum natürlichen Wachstum von Produkten und Dienstleistungen eingebaut, s. Abb. 12.4. Die vertikale Achse bezeichnet in einer Wardley Map die Sichtbarkeit bzw. Verfügbarkeit eines Angebotes. Je mehr Menschen auf etwas Zugriff haben, umso höher ist das Angebot in der Wardley Map angeordnet. Die horizontale Achse beschreibt die

Abb. 12.4   Wardley Map. (Quelle: Wardley 2018)

202

M. Andrezak

Sicherheit bzw. Reife eines Angebotes. Je klarer, wiederholbarer und vorhersehbarer ein Angebot ist, umso weiter rechts ist es auf einer Wardley Map angeordnet. Links unten sind also vollkommen neue Dinge angeordnet (unsichtbar, nicht verfügbar/unsicher) und oben rechts stehen etablierte, standardisierte Produkte (hohe Verfügbarkeit/Sicherheit). Ein Produkt startet immer in der Genesis-Phase: Ein Startup fängt meist mit einer coolen oder zumindest netten Idee an, die wenige kennen und auf die wenige Zugriff haben (vielleicht sogar noch niemand). Custom bedeutet, dass wir Spezialanfertigungen bauen: Ein Gitarrenbauer stellt einzelne Gitarren auf Kundenwunsch her. Ein wirkliches Produkt hat die Eigenschaft, dass es für alle Kunden gleich ist. Es fällt immer dasselbe Produkt vom Laufband, bzw. es greifen alle auf dasselbe Internetprodukt zu, wie z. B. bei Immobilienscout, Google oder Modellen, bei denen eine Software für alle zentral zur Verfügung gestellt wird: Software as a Service. Muss das Produkt für jeden Kunden geändert werden, ist es kein Produkt, sondern Custom. Wenn ein Angebot zur Commodity wird, ist es für alle Nachfrager im relevanten Markt verfügbar. Die Standardisierung der Angebote ist nun aber so hoch, dass die Angebote weitgehend austauschbar werden. Beispiele für Commodity-Angebote sind Nägel oder Strom aus der Steckdose. „Hauptsache ich habe einen Nagel.“ oder „Bei mir kommt der Strom einfach aus der Steckdose.“ sind typische Äußerungen zu Commodity-Angeboten. Dementsprechend sind Kundenpräferenzen und Gewinnmargen im Commodity-Bereich auch nur noch gering vertreten. Es gibt zwei wesentliche Wachstumssprünge für ein Angebot: Den Übergang von der Custom- zur Produkt-Phase. Das ist die Produktifizierung eines Angebotes. Der Übergang ist verführerisch, weil im Custom-Bereich kein Skalierungseffekt entstehen kann. Um 20-mal so viele Individual-Gitarren zu bauen, benötigt man auch 20-mal so viel Personal. Dafür ist einem die Liebe der Kunden gewiss. Der Übergang zum Produkt besteht nun darin, das Angebot auf fünf fest vorgegebene Gitarrenmodelle zu beschränken. Individualisierung findet nicht mehr statt. Wenn man genug Individual-Gitarren gebaut hat, bekommt man eine Idee davon, wie eine gute Gitarre für viele Leute aussieht. Mit dem Wissen lässt sich eine skalierende Produktionsstrecke für fünf Gitarrenmodelle bauen und benötigt in der Folge für 20-mal so viele Kunden kaum mehr Personal. Da die Gitarre nun ein Standardmodell ist, bleiben die Individualkunden jedoch wahrscheinlich aus oder sind unzufrieden. Das ist der Preis, den man als Produzent zahlt. Um das Produkt in eine Commodity weiterzutreiben, müssten dann die Gitarren einfach in Fernost bestellt werden und die eigene Firma wäre lediglich die Marketing- bzw. Vertriebshülle. Die Gitarren werden wahrscheinlich noch billiger. Sie eignen sich nur noch als Geburtstagsgeschenke für Kindergeburtstage. Aber der Markt dafür ist verblüffend groß. Das Modell macht einen ersten Trugschluss klar: Wir kennen Firmen meistens erst nach ihrem Wachstumssprung zum Produkt. Dabei werden die Vorbedingungen des langsamen Lernens und beschränkten Wachstums im Custom-Bereich vergessen. Dass die Firma und ihr Angebot bekannt und sichtbarer wurden, ist ja aber genau der Grund dafür, dass wir sie kennen. Die landläufige Vorstellung ist daher, dass man direkt zum Produkt

12 Growth

203

kommen kann. Das geht aber nicht, denn man müsste das Rezept zum Produkt erraten. Ein Vorgehen, das Misserfolg garantiert. Es wäre genau das Vorgehen, das Alan Cooper (2019) beschreibt, wenn er sagt: „Satisfying nobody is a by-product of trying to satisfy a large group of users“. Insbesondere erfolgreiche Firmen denken, sie könnten aufgrund ihres Erfolges alles Neue direkt als wiederholbares, gutes Produkt beginnen. Das ist leider ein Trugschluss: Diese Firmen haben zwar eine gewisse Bekanntheit als Plattform und bestehende Vertriebskanäle. Aber jedes zusätzliche Produkt muss über Arbeit und Lernen im Custom-Bereich neu entdeckt werden. Verblüffenderweise „vergessen“ die Gründer von Unternehmen selbst oft, wie anstrengend der Anfang war. Wie sie den Kunden auf dem Schoß gesessen haben, um überhaupt etwas zu erreichen oder zu verkaufen. Welche Rückschläge sie erleben und überstehen mussten. Eine kleine Warnung: Eine Umstellung des Geschäftsmodelles von Custom zu Produkt ist (vor allem sozial und in der Wahrnehmung) schwieriger als man denken möchte. Das Konzept Crossing the Chasm (Moore 1991), das auf der Diffusionstheorie von Everett Rogers (1962) aufbaut, beschreibt den Effekt, der in Abb. 12.5 dargestellt ist. Mit einem neuen Produkt müssen zuerst die sog. „Early Adopter“ angesprochen werden. Early Adopter sind generell begierig nach Neuem. Sie sind die erste Chance: Wenn man sich mit ihnen unterhält, befeuert dies ihre Neugierde und macht sie zufrieden. Sie sind damit eine frühe Quelle qualitativer Informationen anhand derer man lernen und verstehen kann. Nur mit ihnen kann man etwas Neues beginnen. Nur mit ihrem Wissen, kann man Kontext, Markt und Anforderungen wirklich verstehen. Sobald man als Firma genug gelernt hat und uns sich dem großen Markt zuwendet, ändert sich aber die Beziehung zu diesen frühen Kunden: Bis jetzt saß man mit ihnen in Workshops und fragten nach ihren Wünschen. Sobald wir diese endlich identifiziert hatten (Heureka!), versuchte man, sie direkt im Produkt zu beantworten. Im Übergang zum Produkt fragt man dann sehr viele Kunden. Jetzt muss man Kompromisse bauen, die für die meisten Kunden gut passen, aber meist für keinen perfekt sind. Diese sind

Abb. 12.5   Lebenszyklus einer Technologie-Adoption. (Quelle: Dihen 2018)

204

M. Andrezak

das verallgemeinerte Rezept zur Befriedigung vieler Kunden. Damit tut sich eine gefährliche Kluft (englisch: Chasm) aus: Kaum jemand ist noch so begeistert wie früher, aber viele finden es gut. Jeden genau mit seinen Bedürfnissen zu bedienen, wäre der Tod des Produktes, da es zu unübersichtlich und kompliziert würde. Kompliziert dürfen aber nur Produkte für hoch begeisterte Nischen oder Experten sein. Jeder kennt den Effekt aus seinem Leben und hat eine Marke, die früher wirklich toll war und die auf Kunden gehört hat, jetzt aber irgendwie „Masse“ ist. Ed-Hardy-Shirts oder im ganz Großen vielleicht Apple. Wer hat nicht einen „Kreativen“ in der Bekanntschaft, der schon vor 20 Jahren Apple-Produkte gekauft hat, dies auch heute noch tut, aber bei dem der Eindruck ist, dass „früher alles besser war, da haben sie sich noch um uns gekümmert“? Apple geht es mit seinem Wachstum trotz allem Gemecker und Trennungsschmerz von den Early Adoptern aber bis heute sehr gut. Also noch einmal: Es gibt keine Abkürzung. Wir müssen den ganzen, langen Weg gehen. Wachstum zum Erfolg dauert Jahre, nicht Monate und die ersten Verkaufszahlen sind immer mickrig im Verhältnis zum später erwarteten Erfolg oder Potential.

12.4 Modelle zum Wachstum Im Folgenden kommen einige Modelle, die erklären, wie man Wachstum erzeugen kann. Wachstum hat relativ viel mit Disziplin, Intellekt und dem Überschreiben von Instinkten zu tun. Und relativ wenig mit Intuition, Genie und der „richtigen Idee“ unter der Dusche oder beim Spazierengehen. Eigentlich wissen wir, wie es geht. Es fühlt sich nur leider sehr mühsam an, wenn man es macht.

12.4.1 Der Hockey-Stick Karinas und auch mein Chef hatten an uns jeweils eine Forderung, die man grafisch als Hockey-Stick darstellen könnte: „Sorge mal für den Anfang von Wachstum, damit wir bald wie wahnsinnig wachsen“. Alle wollen den Hockey-Stick bzw. ­„Triple-Digit-Growth“. Tatsächlich hat die ursprüngliche Definition des Hockey-Stick-Graphen durch den Klimatologen Jerry Mahlmann eine eher traurige Bedeutung: Wie in Abb. 12.6 dargestellt, zeigt er die dramatische Erwärmung unserer nördlichen Hemisphäre der letzten tausend Jahre auf (Monastersky 2006). Auf diesen Hockey-Stick würden wir alle gerne verzichten, aber selbst daran haben wir lange gearbeitet. Warum ein Hockey-Stick so beliebt ist, hat zwei Gründe: Die Form der exponentiellen Kurve lässt eine süße Explosion nach rechts oben vermuten: Wir wachsen wie wahnsinnig. Bevor die Kurve aber nach oben katapultiert, geht es recht gemächlich nach oben. Als Verantwortungsträger bedeutet die Kurve, dass man „nach oben“ phänomenales Wachstum versprechen kann, aber nicht genau weiß, wann die Explosion

12 Growth

205

Abb. 12.6   Hockey Stick der globalen Temperaturentwicklung. (Quelle: Rahmstorf 2013)

startet. Zu jedem Quartal robbt man eben noch im flachen Bereich der Kurve. Es ist wie das Versprechen eines Lebens nach dem Tod im Paradies: Das Schönste kommt erst noch. Und das zu jedem Quartal. Und jederzeit könnte es beginnen. „Nach unten“ kann man dagegen jederzeit das große Wachstumsziel ausgeben und ungeduldig fragen, wann es denn endlich losgehe mit der Wachstumsexplosion und wer da gerade seinen Job nicht richtig gemacht habe. Schaut man genau hin, so zeigt der Hockey-Stick allerdings erst flach nach unten bevor er steil nach oben geht. Tatsächlich muss man sich den Hockey-Stick also wie eine J-Kurve vorstellen: Die J-Kurve beschreibt den makroökonomischen Effekt, dass eine Geldentwertung wider aller Erwartungen nicht sofort Exporte beflügelt, sondern verrückterweise die Exporte erst einmal schrumpfen lässt, die dann erst mit Verzögerung nach oben gehen, wie auch in Abb. 12.7 dargestellt. Für den J-Kurven-Effekt gibt es einen einfachen Grund: Wenn in einem Unternehmen etwas Neues gemacht wird, werden Mitarbeiter vom Bestehenden abgezogen. Da das Bestehende aber bislang meist noch gut funktioniert (das Unternehmen ist ja nicht pleite), wird zunächst einmal weniger von dem produziert, was funktioniert. Wir denken immer, im Digitalen sei alles anders und die ökonomischen Regeln würden hier nicht gelten. Tatsächlich ist dem aber nicht so: Software und der Betrieb funktionieren nicht, weil sie automatisiert sind, sondern obwohl sie automatisiert sind. Was alles für den Kunden zusammenhält, sind eben doch die Menschen, die sich Produkte ausdenken, definieren, bauen, betreiben, Kunden betreuen oder Marketing machen. Im Digitalen lässt sich einfach nur besser skalieren.

M. Andrezak Neoexporte

206

Abwertung Zeit

A

C

B

Abb. 12.7   Reaktion der Handelsbilanz auf eine Abwertung in Form einer J-Kurve. (Quelle: In Anlehnung an Blanchard und Illing 2014)

Bei der J-Kurve steht man vor folgendem psychologischen Problem: Vor dem Erfolg ist man gezwungen, eine Talsohle des Misserfolgs und Verlusts zu durchschreiten. Leider ist zu Beginn aber nicht klar, ob der Erfolg wirklich kommt. Er kommt ja nicht immer! Und fast so schlimm ist, dass auch nicht klar ist, wann der Erfolg kommt. In der Talwanne der J-Kurve lebt es sich daher sehr ungemütlich. Hier helfen nur Intellekt und Disziplin. Man muss da durch. Die Frage, ob der Erfolg noch kommt, können wir seriös nicht beantworten, da wir keine Daten aus der Zukunft besitzen. Wir stehen also vor dem Halteproblem nach Alan Turing (Davis 1958): Wir wissen nicht, ob es besser ist weiterzumachen oder aufzuhören.

12.4.2 Das 3-Horizonte-Modell Was aber hilft? Welchen konstruktiven Ansatz gibt es, mit Wachstum umzugehen? Das 3-Horizonte-Modell haben Baghei, Coley und White (1999) in dem Klassiker unter den Wachstumsbüchern „The Alchemy of Growth“ beschrieben. Dafür haben sie sich angeschaut, wie Firmen es schaffen, über Jahrzehnte kontinuierlich zu wachsen, obwohl sich die Umwelt ändert. Sie haben beobachtet, dass beständig wachsende Unternehmen zu jedem Zeitpunkt auf drei verschiedene Zeithorizonte hinarbeiten. Die drei Horizonte in Abb. 12.8 stellen eigentlich S-Kurven dar. S-Kurven bilden ursprünglich eine Innovationsdiffusion ab: Wie verläuft die Verbreitung neuer Ideen oder Technologien? Sie verbreiten sich erst langsam, dann schneller, rasend schnell, flachen schließlich ab und sie sterben auch – traurigerweise – irgendwann ab (Sunsetting). Die S-Kurve eignet sich als Modell für Wachstum, da die Kurven von Wachstum und dem Absatz von Innovation ähnlich verlaufen (Baum et al. 2013). Eigentlich haben S-Kurven mehr traurige Abschnitte als fröhliche: Der Anfang ist schwer, das Stagnieren nach dem Wachstum fühlt sich nicht schön an und wenn das Produkt ganz stirbt, ist es noch furchtbarer. Vielleicht hat man hier den Kern des Problems mit dem Wachstum schon erfasst: Man bekommt den schönen Teil des

207

Wachstum

12 Growth

Horizont 3 Oponen für zuküniges Wachstum Zukünige Ween entdecken, Risiko-Porolio auauen R&D, (User)Research, rohe Informaonen, schnell & billig

Horizont 2 Zuküniges Wachstum Neue Segmente und Produkte platzieren und validieren

Horizont 1

Produkt-/Market-Fit, Märkte besetzen

Aktueller Cashflow Aktuelle Produkte maximal monetarisieren Qualität, Vorhersagbarkeit, Perfekon

Zeit

Abb. 12.8   Das 3-Horizonte-Modell. (Quelle: In Anlehnung an Baghei et al. 1999)

rapiden Wachstums nicht ohne die anderen drei, unschöneren Teile. Rosinenpicken funktioniert nicht. Die Wachstumsphase ist im Modell der S-Kurve übrigens auch nicht so schön attribuiert. Probleme, denen man hier begegnet, sind womöglich Luxusprobleme. Das macht sie aber nicht viel besser aushaltbar: Der Markt möchte mehr, als wir liefern können. Die Qualität leidet, weil wir noch nicht gelernt haben, große Mengen in Qualität zu liefern oder viele Kunden gut zu bedienen. Intern leiden wir darunter, dass wir ständig Mangel erleben: Wir bekommen nicht genug Arbeitsmittel und qualifizierte Mitarbeiter sind schwer in genügender Anzahl zu finden. Kurz: Wir werden überrannt.

12.4.2.1 Horizont 1 Stellen wir uns eine Firma mit einem Geschäftsmodell vor. Dann ist der Umsatz dieser Firma durch eine S-Kurve (links unten) gut beschrieben. Das ist der erste Horizont. In ihm befinden sich die aktuell bestehenden Angebote. Aufgabe ist es nun, diese Angebote zu melken, wie es nur geht. Die Firma muss die Qualität steigern und vom Selben immer mehr, immer billiger liefern können. Sie muss sich in „Operational Excellence“ üben, um das bestehende Angebot maximal auszunutzen und so für den Kunden maximal günstig, vorhersagbar und wiederholbar zu werden. Auch in Horizont 1 kann man wachsen. In Horizont 1 wächst man aber linear. Es gibt die Firma und das Produkt ja schon. Der Markt kennt sie; sie ist etabliert. Das ist wahrscheinlich die Situation, in der die allermeisten – auch digitalen – Produktmanager arbeiten. Man kann von der Arbeit am bestehenden, etablierten Produkt keine

208

M. Andrezak

Wachstumssprünge erwarten. Der Hockey-Stick entsteht nicht hier. Wenn die Forderung ist, mit dem Markt mitzuwachsen, muss evolutionäres Wachstum in Horizont 1 gemeint sein! Denn alles, was darüber hinausgeht, funktioniert hier nicht. Neues Wachstum wird erst im zweiten Horizont erzielt.

12.4.2.2 Horizont 2 Man weiß, dass die Kurve des ersten Horizontes irgendwann nach unten gehen wird. Was kann man dagegen tun? Man könnte meinen, ein paar neue Features könnten die Firma retten. Das ist aber so, wie die neuen Features beim neuen iPhone oder Google Pixel: Es handelt sich nur um evolutionäres Wachstum – oder weitere Stagnation. Alles, was man mit neuen Features am Bestehenden erreicht, ist, die erste S-Kurve zu verlängern oder ein paar kleine Höcker einzubauen. Man kann zwar, wie Drucker (1973) sagt, daran arbeiten, bestehende Kunden zu behalten und immer mehr zu monetarisieren. Das große Wachstum liegt aber darin, immer neue Kunden zu generieren. Apple wurde zum Beispiel nachgesagt, dass sie es über 20 Jahre geschafft haben, ein lineares Kundenwachstum hinzubekommen. Die Kurve sah so beängstigend linear aus, dass man meinen könnte, es sei ihre Steuerungsgröße gewesen. Wie bekommt man aber neue Kunden? Indem man Probleme von Leuten löst, die bisher nicht Kunden waren. Wir müssen also größere Probleme lösen, die wir bisher nicht gelöst haben. Unser jetziges Angebot löst im Kern ein bestimmtes Problem. Es reicht nicht zum Gewinn neuer Kunden, hier weiterzuarbeiten. Arbeit am bestehenden Angebot ist dafür da, Kunden nicht abwandern zu lassen (und vielleicht ein paar Neue zu bekommen). Wir müssen uns also neue Produkte ausdenken, die Probleme lösen, die wir bisher nicht gelöst haben. Am besten sind das auch noch Probleme, die wir irgendwie eigentlich schon lösen könnten, aber deren Lösung wir bisher nicht anbieten. Wir müssen die Arbeit im Kern schon können. Wenn wir keine neuen Probleme lösen, greift das 3-Horizonte-Modell nicht, bei dem sich die S-Kurven addieren. Beispiele für neue Produkte, die neue Probleme lösen, sind z. B. das iPhone, das den iPod abgelöst hat, der damals für ca. 70 % des Umsatzes von Apple verantwortlich war. Das iPhone konnte alles, was der iPod konnte – und noch viel mehr: A widescreen iPod touch, a revolutionary mobile phone, and a groundbreaking internet communication device (Apple 2007). Ein anderes Beispiel für neue Produkte, die neue Probleme lösen: Die Einführung des Frappucino bei Starbucks hat ebenfalls Horizont-2-Qualitäten: Für die Firma, die – zumindest zu ihrer Gründung und in den USA – für die Nische „etwas besserer Kaffee zu höheren Preisen, persönliche Bedienung und der dritte Platz zwischen Büro und zu Hause“ steht, war die Einführung des Frappucino etwas völlig Neues. Zielgruppe waren Teenager, die sich unverständlicherweise nachmittags bei Starbucks trafen, um „erwachsen“ zu sein und dort bittere „Plörre“ bestellten. Süßere (manchmal sogar noch) kaffeehaltige Getränke könnten ihnen wirklich gefallen. Das vielleicht radikalste Horizont-2-Produkt vom vielleicht radikalsten 3-HorizonteCEO, Jeff Bezos, sind die Amazon Web Services (AWS). Wer dürfte sonst schon in

12 Growth

209

seiner Firma, die vom Versand von Büchern und anderen Dingen lebt und gerade einen riesigen Umbau auf Logistik (Marketplaces) hinter sich hat, erfolgreich vorschlagen, Rechnerleistung zu verkaufen – und das unter einem Dach. Es gibt zwei Schwierigkeiten beim zweiten Horizont: Die Leute, die an Horizont 1 arbeiten, werden jede Horizont-2-Idee hassen. „Was soll das denn?“, „Und das sollen wir sein?“ sind Sätze, die fallen werden. Und zwar zu Recht: Wer auf Horizont 1 arbeitet, beschützt das Bestehende, hat zig Meetings und 150 E-Mails am Tag und tut alles, um die bestehenden Angebote zu verbessern. „Und das soll nicht genug sein?“, „Frappuccino sollen wir brauchen?“, „Wirklich?“ Das Innovator‘s-Dilemma (Christensen 1997) heißt so, weil es ein Dilemma ist. Das zweite Problem ist, das viele denken, man müsse ständig neue Produkte auf Horizont 2 herausbringen. Das wäre aber töricht und zu viel. Gute Firmen bringen alle paar Jahre ein neues wegweisendes Produkt heraus. Mehr geht nicht, weil wir zum einen dafür auf Ressourcen im Unternehmen zugreifen müssen, die mit Horizont 1 ausgelastet sind, und uns zum anderen verzetteln würden. Viel bringt nicht viel. Wichtiger ist es, ab und zu eine große Wette einzugehen, als viele kleine. Es ist teuer, ein Horizont-2-Produkt auf den Markt zu bringen. Man sagt auch: es ist der Versuch, einen neuen Standard zu etablieren. Das macht man nicht ständig. Ein Horizont-2-Versuch ist geglückt, wenn das Produkt in einen regulären Horizont1-Betrieb übergeht. Aber wie findet man ein neues Horizont-2-Produkt?

12.4.2.3 Horizont 3 Horizont 3 ist dafür da, nach neuen Produkten und Ideen zu suchen, die man in Horizont 2 platzieren und dann zu Horizont 1 entwickeln könnte. Hier werden kleine Proben genommen und Experimente betrieben. Die Aufgabe ist es, rohe Information sehr schnell und oft zu erwerben – und das so billig wie möglich. Hier handelt es sich eher um Forschung und Marktanalyse. Viele kleinere Aktivitäten, die sich zu einem Bild dessen kristallisieren, was man als nächstes versuchen möchte. Man macht das so lange, bis man Gewissheit hat, dass es dieses eine Produkt ist, das man auf die Welt bringen will. Eben z. B. die Apple Watch oder der Frappuccino. Horizont-3-Arbeit kann lange recht enttäuschend sein, denn man sucht ständig nach Spuren, von denen sich die meisten aber als sinn- bzw. wirkungslos herausstellen. 12.4.2.4 Das Zusammenspiel der Horizonte Das 3-Horizonte-Modell stellt klar, dass man ständig in allen drei Horizonten arbeiten muss. Das ist aber schwierig, denn die Arbeit sieht in allen drei Horizonten sehr unterschiedlich aus: • Horizont 3: Suchen und Explorieren im Groben. Billig, schnell und roh („Die spielen ja nur.“). • Horizont 2: Projektmanagement, gegen alle Widerstände (auch von innen) ein neues Produkt – durchaus noch felherbehaftet – auf den Markt bringen („Das soll der Durchbruch sein?“).

210

M. Andrezak

• Horizont 1: Bestehende Produkte maximal ausbeuten: Präzision, Qualität, Wiederholbarkeit, Vorhersagbarkeit („Wie langweilig, die machen immer dasselbe.“). Die Komplexität im Wachstum besteht also darin, alle drei Arbeitsweisen zu koordinieren und nebeneinander bestehen zu lassen, obwohl sie so widersprüchlich sind. Auf Horizont 3 herrschen vor allem qualitative Eindrücke und Daten. Horizont 1 braucht aber quantitative Daten und Präzision. Horizont-3-Arbeit ist aus der Perspektive von Horizont 1 Kinderkram und Spinnerei. Umgekehrt ist Horizont 1 von Horizont 3 aus gesehen pure Verhinderung von Neuem und Bedenkenträgerei. Und Horizont 2 klaut letztlich allen nur Ressourcen für sinnlose neue Ideen, die dann schlecht auf den Markt gebracht werden. Die Geschäftsführung (niemand anders kann dies verantworten) muss all die Arbeitsweisen und Bereiche ermöglichen, unterstützen und miteinander versöhnen. Am besten klappt das, wenn die Geschäftsführung das Miteinander der Kulturen vorlebt. Ebenso ist es wichtig, für jede Arbeit im Unternehmen explizit zu machen, in welchem Horizont sie angesiedelt ist und was erwartet wird: Geht es bei der Arbeit um ein Experiment auf Horizont-3-Ebene, bei dem man sehen möchte, was passiert? Oder handelt es sich um ein neues Feature, das in Horizont 1 direkt für Millionen von Kunden funktionieren soll? In den letzten Jahren kommt immer wieder Kritik am 3-Horizonte-Modell auf. So können z. B. die Zeiträume mit jeweils 18–36 Monaten für die einzelnen Horizonte zu großzügig gewählt sein. Natürlich kann man das Modell in dynamischen Umgebungen auch schneller spielen. Es geht ums Prinzip. Ein anderer Kritikpunkt ist, dass das Modell sehr stark nach einem Wasserfall-Modell aussieht. Tatsächlich ist es aber eine Frage der Interpretation. Genauso gut können die Horizonte (semi-)permeabel sein. In meiner Praxis sehe ich oft, dass sich Horizont 1 gewieft schnell Erkenntnisse von Horizont 3 einverleibt und ausnutzt. So ist das Modell eigentlich auch gedacht.

12.5 Was müssen wir beherrschen, um Wachstum zu erreichen? Schauen wir zum Abschluss noch darauf, was wir können müssen, um erfolgreich Wachstum zu gestalten: Erstens brauchen wir Geduld. Wir wissen, dass die Zeit hin zu erfolgreichem Wachstum in Jahren und nicht in Quartalen, Monaten oder gar Wochen gemessen wird – auch wenn der Rhythmus quartärlicher Geschäftsberichte Anderes suggeriert. Noch einmal: There is no overnight success. Dann müssen wir verstehen, dass unterschiedlichste Arbeitsweisen benötigt werden, um nachhaltig Wachstum zu generieren. Wir müssen verstehen, dass alle guten Produkte im Kleinen und mit qualitativen Daten anfangen. Wenn wir lange genug dranbleiben, haben wir uns die Ausgangslage für quantitative Daten und die Sicherheit, mit einem Rezept ins Große zu skalieren, erarbeitet und verdient. Das Rezept zu erraten, funktioniert praktisch nicht.

12 Growth

211

Wir müssen ebenso verstehen, dass wir anfangs kleine Experimente im Groben machen (Horizont 3), ganz selten mal eine große Wette eingehen (Horizont 2) und fast alle im Unternehmen das Bestehende schützen und verbessern (Horizont 1). Das alles muss explizit gemacht und vorgelebt werden. Insgesamt nennt man das: eine ambidextre Organisation erschaffen. Auch das braucht Geduld und Zeit. Anweisungen helfen nicht. Um die besten Optionen aus Horizont 3 bewerten zu können, benötigen wir ein gutes strategisches Verständnis, um Optionen auszuwählen, die zu unserer Gesamtentwicklung passen. Neue Optionen müssen einen Strategic Fit aufweisen. Um das jeweils beurteilen zu können, müssen die verschiedenen Unternehmensebenen gut vernetzt sein und genug Austausch zwischen Bottom-up und Top-down, hergestellt werden. D. h. Hierarchiestufen müssen durchlässig und miteinander verbunden werden. Pläne können nicht einfach von oben vorgegeben werden, sondern müssen im Miteinander ausgearbeitet werden. Eine gute Möglichkeit, um sich treu zu bleiben, ist es dabei, wie etwa bei Amazon, bestehende interne Fähigkeiten so gut auszubauen, dass sie irgendwann als Angebot nach außen bestehen können (Computing, Logistik im Beispiel Amazon). Im Bereich digitaler Produkte ist noch zu erwähnen, dass einer der Wachstumsmotoren die Personalisierung ist. Personalisierung hilft dabei, im Kern ein Standardprodukt für alle zu haben, das aber für jeden anders aussieht und wirkt. Individuelle Anpassungsfähigkeit an den spezifischen Kunden, eventuell durch ihn selbst, ist also bereits eingebaut. Das sorgt dafür, dass der Kunde das Produkt als „seines“ empfindet, obwohl es eigentlich Standard ist. So können wir der Gefahr von extremem Margenverlust und Gleichgültigkeit bei Kunden im Digitalen recht leicht entgehen. Es zeigt sich also: Wachstum ist schwieriger als gedacht. Schwieriger als Martin sich das dachte, als er zu Karina ging. Karina wird das Problem alleine nicht lösen können. Wachstum hat als Grundlage das Verständnis einer Organisation. Mit genügend Modellen und Wissen und Fähigkeiten können wir lernen, Wachstum als etwas Organisches, Natürliches, Machbares und Managebares zu betreiben. Weg von Magie und Genie hin zu normaler Arbeit. Auch wenn es ein bisschen Geduld erfordert.

Literatur Apple. 2007. Apple reinvents the phone with iPhone, Pressemitteilung vom 09.01.2007. www. apple.com/newsroom/2007/01/09Apple-Reinvents-the-Phone-with-iPhone. Baghei, M., S. C. Coley und H. W. White. 1999. White, „Alchemy of Growth. New York: Basic Books. Baum, H.-G., A.G. Coenenberg, und T. Günther. 2013. Strategisches Controlling, 9. Aufl. Stuttgart: Schäffer-Poeschel. Blanchard, O., Illing, G. 2014. Makroökonomie, 6. Aufl. Pearson: Hallbergmoos. Christensen, C.M. 1997. The Innovator's Dilemma. Boston: Harvard Business School Press. Cooper, A. 2019. https://twitter.com/MrAlanCooper/status/1165088908947800064. Davis, M. 1958. Computability and unsolvability. New York: McGraw-Hill.

212

M. Andrezak

Dihen, R. 2018. Wie sich das Buch Crossing the Chasm auf den Marketing-Erfolg auswirkt! https://diri-socialmedia.de/crossing-the-chasm. Drucker, P. 1973. Management: Tasks, responsibilities. New York: Harper Business. Model T Ford Club of America, Hrsg. 2020. Model T Ford production. www.mtfca.com/encyclo/ fdprod.htm. Monastersky, R. 2006. Climate science on trial. www.chronicle.com/article/Climate-Science-onTrial/34665. Moore, G.A. 1991. Crossing the chasm. New York: Harper Business Essentials. Rahmstorf, S. 2013. Paläoklima: Die letzten 2000 Jahre. https://scilogs.spektrum.de/klimalounge/ palaeoklima-die-letzten-2000-jahre-hockeyschlaeger. Rogers, E. 1962. Diffusion of innovations. New York: Free Press. Statista. 2016. Anzahl der Facebook-Nutzer und Internetnutzer weltweit in den Jahren 2004 bis 2015. https://de.statista.com/statistik/daten/studie/245101/umfrage/facebook-nutzer-vs-internetnutzer-weltweit-zeitreihe. Statista. 2020. Absatz von Apple iPhones weltweit in den Geschäftsjahren 2007 bis 2019. https:// de.statista.com/statistik/daten/studie/203584/umfrage/absatz-von-apple-iphones-seit-demgeschaeftsjahr-2007. Wardley, S. 2018. Wardley Maps. Topographical intelligence in business. https://medium.com/ wardleymaps.

Der Autor Markus Andrezak gestaltet seit Mitte der 90er Internet-Produkte. Er verbindet seitdem Gestaltung mit Kundenorientierung und agiler Arbeit. In den 2000ern erfand er PortfolioManagement mit neuen Techniken aus Kanban für Wissensarbeit. Seine neuesten Arbeiten helfen Unternehmen dabei, Strategie in hoch dynamischen Zeiten besser leben zu können. Er ist Gründer der Produkt- und Strategieberatung überproduct in Potsdam. Kontakt: [email protected]

Produktmanagement ganzheitlich verstanden

13

Hinweise, die helfen sollen, ein herausragender Produktmanager zu werden Patrick Roelofs

Zusammenfassung

Produktmanager sind für die (Weiter-)Entwicklung ihres Produktes verantwortlich und dabei mit einem breiten Spektrum an Aufgaben betraut. Produktentwicklung ist immer aber auch Teamsport im Zusammenspiel mit vielen unterschiedlichen Stakeholdern. Allzu leicht geraten im Berufsalltag die hierbei erforderliche Kommunikation und Abstimmung zwischen Produktmanager und seinen Stakeholdern in den Hintergrund, wenn sich konkrete Produktentscheidungen und akut zu lösende Probleme in den Vordergrund drängen. Der Beitrag zeigt, wie wichtig es ist, dass Produktmanager trotzdem konsequent in die Beziehungspflege zu ihren Stakeholdern investieren, um langfristig effizienter bessere Produkte zu entwickeln.

13.1 Die Aufgaben des Produktmanagers Produktmanager: Dieser Beruf hat im Gegensatz zu vielen anderen Berufen entlang der digitalen Wertschöpfungskette eine Vielzahl gegensätzlicher Facetten, die mit dem Ziel, ein großartiges und kommerziell erfolgreiches Produkt zu erschaffen, ausbalanciert werden müssen. Damit dies gelingen kann, bringt der Job des Produktmanagers in der Regel eine sehr klare Ende-zu-Ende-Verantwortung mit sich. Ende-zu-Ende bedeutet in diesem Kontext, dass es der Produktmanager ist, der sämtliche Prozesse, Maßnahmen und sich ständig verändernde Inputs in den für ein digitales Produkt relevanten Bereichen (Recht, Technik, User Experience, Marketing, Data etc.) P. Roelofs (*)  Lotto24 AG, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_13

213

214

P. Roelofs

im Blick haben muss. Er agiert als Schnittstelle zwischen diesen Kompetenzen, um den Erfolg „seines“ digitalen Produktes sicherzustellen. Schaut man sich also die vielfältigen Herausforderungen an Produktmanager an, stellt sich die Frage, welche Aspekte wichtig sind, um in einem Tech-Unternehmen einen überdurchschnittlichen Wertbeitrag leisten zu können. Dieser Wertbeitrag äußert sich häufig in zwei übergeordneten Ergebnisdimensionen, die gemeinsam erfüllt sein müssen:

13.1.1 Ergebnisdimension 1: Zufriedenheit der Nutzer mit dem Produkt Die Messmethoden, um die Zufriedenheit der Nutzer/Kunden zu erfassen, sind vielfältig. Zwei der häufig angewandten Methoden zu Messung sind der Net Promotor Score und die Nutzer- bzw. Kundenaktivität: Net Promoter Score Der Net Promoter Score (NPS) ist eine Kennzahl, die den Unternehmenserfolg auf der Basis einer einzigen Frage unter Kunden korreliert. Die Frage lautet „Wie wahrscheinlich ist es, dass Sie Unternehmen/Marke X einem Freund oder Kollegen weiterempfehlen werden?“. Die Antwortmöglichkeiten reichen dabei von 10 (sehr wahrscheinlich) bis 0 (sehr unwahrscheinlich). Als „Promotoren“ werden dabei die Befragten bezeichnet, die mit 9 oder 10 antworten. Als „Detraktoren“ werden hingegen diejenigen angesehen, die mit 0 bis 6 antworten. Kunden, die mit 7 oder 8 antworten, gelten als „Indifferente“. Zur Berechnung des Scores wird der prozentuale Anteil an Detraktoren vom prozentualen Anteil an Promotoren abgezogen. Die Differenz ergibt den Net Promoter Score, der sich zwischen –100 und 100 bewegen kann. Nutzer-/Kunden-Aktivität Die Messung, wie viele Personen bzw. zahlende Kunden ein Produkt pro Quartal/Monat/ Woche/Tag nutzen, gibt ebenfalls Aufschluss über die Zufriedenheit der Nutzer mit dem Produkt. Die gängigsten Betrachtungsweisen dieser Aktivitätskennzahl sind • • • •

QAU (Quarterly Active User) MAU (Monthly Active User) WAU (Weekly Active User) DAU (Daily Active User).

Wenn beispielsweise von 1000 Kunden 750 ein Produkt täglich nutzen (DAU), kann man i. d. R. davon ausgehen, dass sie zufrieden mit dem Produkt sind. Im Umkehrschluss muss es aber nicht bedeuten, dass Nutzer, die ein Produkt mehrheitlich „nur“ einmal im Monat nutzen (MAU), damit unzufrieden sind. Vielmehr gilt es zu verstehen, welche Art

13  Produktmanagement ganzheitlich verstanden

215

Produkt ein Unternehmen anbietet: Ist es ein Produkt, das das Ziel hat, Nutzer täglich zu „aktivieren“ (bspw. Instagram)? Oder handelt es sich um ein Produkt, das aufgrund der normalen Interaktionsgewohnheiten und auf der Basis des Geschäftsmodells eher auf eine monatliche Aktivierung des Nutzers abzielt (bspw. das digitale Kundencenter eines Stromanbieters)?

13.1.2 Ergebnisdimension 2: Kommerzieller Erfolg des Produktes Der Produktmanager muss selbstverständlich auch die wichtigsten kommerziellen Kennzahlen im Auge behalten. Ein Produkt, das von Kunden zwar gerne genutzt wird (bspw. in der frei verfügbaren Basisversion), für das Kunden aber kein Geld ausgeben wollen, oder für das das Unternehmen keine umsatzbringende Werbeplätze an Vermarkter verkaufen kann, ist über kurz oder lang nicht finanzierbar. Entwickelt man beispielsweise ein Software-Produkt, das über ein monatlich zu zahlendes Abonnement verkauft wird (bspw. Spotify oder XING), muss ein Produktmanager die anfallenden Entwicklungskosten genau beobachten, vor allem aber auch die Anzahl der verkauften Abonnements, die Verteilung der Abonnement-Laufzeiten (1, 3, 12 Monate), die Churn-Rate (Kunden-Abwanderungsquote) oder mindestens die Umsätze pro Zeitperiode (Umsatz/Monat). Selbstverständlich gibt es darüber hinaus eine Vielzahl weiterer Kennzahlen, die Aufschluss über den kommerziellen Erfolg geben können. Aber mit den hier aufgeführten Basis-Kennzahlen hat man als Produktmanager schon einen guten Startpunkt, um die kommerziellen Aspekte seines Produktes im Blick zu behalten und ggf. Hypothesen zu entwickeln, wie man die Vertriebsleistung weiter steigern könnte. Wichtig ist aber: Die Erfüllung nur einer dieser Ergebnisdimensionen reicht mittelund langfristig nicht aus. Die hier zwingend zu erfüllende Und-Beziehung zeigt, wie anspruchsvoll die Entwicklung eines kundenfreundlichen Produktangebots kombiniert mit straffem Vertriebsmanagement ist. Dies muss eine guter Produktmanager für sein Unternehmen sicherstellen können. Der Produktmanager ist erster Verantwortlicher sowie zentrale Ansprechperson für sämtliche Stakeholder und das höhere Management und wird in den meisten Unternehmen – ob gerechtfertigt oder nicht – für den Produkterfolg verantwortlich gemacht. Auch deshalb ist die Aufgabe des Produktmanagers so anspruchsvoll. Es zeigt sich häufig schon sehr früh im Projektverlauf, ob Produktmanager die Erwartungen an ihre Rolle erfüllen können. Hierin mag auch der Grund liegen, dass der Rekrutierungs- und Auswahlprozess für Produktmanager in vielen Unternehmen äußerst intensiv durchgeführt wird. Das Risiko eines Misserfolgs soll bei dieser zentralen Rolle minimiert werden. Welche Aspekte sind nun aber wichtig, um als Produktmanager in einem Tech-Unternehmen einen herausragenden Wertbeitrag zur Erfüllung der beiden Ergebnisdimensionen leisten zu können? Die häufigsten Antworten, die in der

216

P. Roelofs

­roduct-Community und von Unternehmensseite auf diese Frage gegeben werden, P beziehen sich auf die Methoden- und Prozesskompetenzen von Produktmanagern. Beispiele sind Product-Discovery- bzw. Design-Thinking-Methoden, Agile User Experience Testing und Kenntnisse dazu, wie man Backlogs in Jira aufbaut. Es sind dann häufig auch genau diese Methoden und Prozesse, über die innerhalb der Product-Community referiert wird und die in Fortbildungen geschult werden. Natürlich ist das eine durchaus zulässige Perspektive auf die Rolle des Produktmanagers, ganz sicher ist diese aber nicht die einzige bzw. ausreichend differenzierte: Ebenso wichtig, wenn nicht sogar noch wichtiger, sind die Aspekte, die als „Klebstoff“ zwischen all den Methoden und Prozessen und in der Zusammenarbeit mit vielen unterschiedlichen Experten und Stakeholdern innerhalb eines Unternehmens einen Beitrag leisten. Aspekte, die dem Produktmanager helfen, für sich, sein Team, die Stakeholder und das Unternehmen einen maximalen Wertbeitrag zu erreichen. Denn dazu ist weitaus mehr erforderlich, als nur gute Design-Thinking-Methoden aus dem Effeff zu beherrschen. Leider aber sind es genau diese Aspekte, die heute noch zu wenig in der ­Product-Community diskutiert werden und die sich von Unternehmensseite noch zu selten in Rollenprofilen oder strukturierten Weiterbildungsangeboten für Produktmanager finden lassen. Deshalb wird im Folgenden auf fünf zentrale Aspekte eingegangen, die helfen sollen, ein ganzheitlicheres Verständnis dieser vielfältigen Rolle zu erhalten.

13.2 Der Produktmanager als proaktiver Beziehungsmanager Gute Beziehungen zu seinen Stakeholdern und in Summe ein eigenes gutes Business-Netzwerk sind eigentlich für alle im Berufsleben unerlässlich. Damit sind ­ natürlich nicht die häufig sehr flüchtigen LinkedIn- oder XING-Kontakte gemeint, sondern echte Beziehungen. Beziehungen, die entstehen, wenn man sich persönlich trifft und gemeinsam Zeit, Erlebnisse und Herausforderungen teilt. Für Produktmanager als Schnittstelle zu vielen Bereichen innerhalb eines Unternehmens sind Beziehungsaufbau und -pflege umso mehr eines der wichtigsten Werkzeuge, die es zu beherrschen gilt. Ganz egal, ob es nun darum geht, ein Produkt gemeinsam mit anderen Experten zu entwickeln und erfolgreich am Markt zu etablieren. Oder irgendwann entlang der eigenen Karriere Zugriff auf gute Leute zu haben bzw. sogar selbst den einen entscheidenden Anruf für den noch besseren nächsten Job zu bekommen: All das funktioniert nur, wenn sich Produktmanager ihrer Rolle als Netzwerker und „Beziehungsmanager“ bewusst werden. Und dennoch scheint es häufig noch so zu sein, dass Produktmanager genau diesen Aspekt ihrer Rolle nicht ausreichend verstanden haben. Sie sehen nicht die Notwendigkeit, in den durchaus aufwändigen Prozess des persönlichen Beziehungsaufbaus und der -pflege zu investieren. Denn gute Beziehungen aufzubauen kostet Zeit, erfordert Engagement und manchmal auch den Einsatz von Geld (z. B. für eine Lunch-Einladung).

13  Produktmanagement ganzheitlich verstanden

217

Addiert man all das auf, ist die Rolle eines Produktmanagers als Beziehungsmanager ein recht teurer, aber in jedem Fall für sich und das Unternehmen wertstiftender Beitrag. Bei all der Technologie und den vorhandenen digitalen Kommunikationsmöglichkeiten, wie beispielsweise „Slack“, die den Arbeitsalltag effizienter machen sollen, dürfen besonders für Produktmanager die persönlichen Interaktionen zwischen Menschen nicht fehlen. Das, was am Ende des Tages zu tun ist, nämlich Produkte mit einer Vielzahl von unterschiedlichen Stakeholdern (mit häufig sehr unterschiedlichen Sichtweisen und persönlichen Zielen) zu entwickeln, ist nach wie vor „People’s Business“. D. h. nicht eine künstliche Intelligenz tut diese Arbeit für uns und trifft im besten Fall die immer richtigen Entscheidungen, sondern es sind Menschen. Diese Menschen, müssen tagtäglich miteinander interagieren und Konflikte lösen, um die notwendigen Entscheidungen für das große Ganze treffen zu können. Die Beziehungen, die diese Menschen zueinander haben, haben einen unmittelbaren Einfluss auf die entstehende Produktqualität. Ein guter Startpunkt, um zu verstehen, wie das eigene Netzwerk aufgebaut und gepflegt wird, ist das Buch „Never eat alone“ von Steve Ferazzi und Thal Raz (2005). Darin beschreiben sie auf sehr anschauliche Weise und anhand vieler persönlicher Beispiele, was jeder einzelne tun kann, um ein herausragender Netzwerker und Beziehungspfleger zu werden. Dabei geht es beispielsweise um den Aspekt der „Großzügigkeit“, die ihrer Ansicht nach der Kern eines jeden starken, gesunden Netzwerks ist. Etwas zu geben, ohne etwas zurück zu erwarten, und zu helfen, wann immer Andere Hilfe benötigen, verringert ihrer Ansicht nach auch die eigenen natürlichen Barrieren. So traut man sich auch eher im eigenen Netzwerk nach Hilfe zu fragen (denn die braucht jeder von Zeit zu Zeit) und kann dadurch die sozialen Bindungen weiter festigen. In ihrem Buch zeigen Ferazzi und Raz noch an vielen weiteren Beispielen, dass die Pflege des eigenen Netzwerks ein kontinuierlicher Prozess ist, der im besten Fall einem strategischen „Relationship Action Plan“ folgt. Denn wenn man selbst erst einmal erlebt hat, welche Kraft sich in Teams und unter Kollegen entfalten kann, die gute Beziehungen miteinander pflegen und die sich gegenseitig vertrauen, stellt man diesen zentralen Aspekt der Produktmanager-Rolle vermutlich nie wieder infrage. Auch das ist Produktmanagement.

13.3 Der Produktmanager als herausragender Kommunikator Bereits im vorhergehenden Abschnitt ist klargeworden, dass ein herausragendes Produktmanagement in vielerlei Hinsicht eine direkte und unmittelbare Kommunikation mit Menschen erfordert. Wirklich zu verstehen, was mein Gegenüber spürt, denkt oder wie er meine Botschaften interpretiert, funktioniert nur über einen direkten, persönlichen Kontakt.

218

P. Roelofs

Häufig gehörte (Produktmanager-)Statements wie „Na klar, ich hab das sauber kommuniziert. Ich habe es in unseren Slack-Channel gepostet, jetzt wissen alle Bescheid.“ zeigen jedoch, wie wenig die kommunikative Verantwortung, die diese Rolle mit sich bringt, in der Praxis verstanden wird. Denn mit dem digitalen, schriftlichen Austausch ist es genauso, wie es seit jeher mit dem Austausch über Briefe und E-Mails war: Man mag gar nicht glauben, wie viele Missverständnisse entstehen können, wenn Tonalität, Körpersprache und daraus resultierende Interpretationsmöglichkeiten fehlen. Die direkte, proaktive und reflektierte Kommunikation ist daher ein erfolgskritisches Werkzeug für Produktmanager. In schnellen, komplexen Projekten stellt das Fehlen von guter persönlicher Kommunikation ein enormes Risiko für den Produktmanager und den Projekterfolg dar. „Management by walking around and talking to people“ ist daher ein essentieller Bestandteil der Produktmanager-Rolle. u

Produktmanagement-Kommunikation ist die Fähigkeit, präzise und zum richtigen Zeitpunkt in der richtigen Frequenz und über den richtigen Kanal Informationen zu verteilen und zu beziehen.

Produktmanager, die dies verstanden haben und innerhalb ihrer Organisation bewusst anwenden, werden mehr Erfolg haben als Produktmanager, die Kommunikation „einfach so passieren lassen“ bzw. sich aus Bequemlichkeit und/oder Konfliktscheue auf rein digitale Kanäle in ihrer Kommunikation verlassen. Interessanterweise wird auch heute noch, in der sich rapide wandelnden und kommunikativ herausfordernden Arbeitswelt, Kommunikation nicht als zu erlernendes Werkzeug verstanden. Es wird hingegen implizit erwartet, dass man bereits Kommunikationsexperte ist, sobald man aus der Uni kommt und in die Rolle des Produktmanagers schlüpft. Viel zu selten werden von Unternehmensseite proaktiv Trainings angeboten, die aus den handelnden Akteuren herausragende Kommunikatoren machen, um den vielfältigen Herausforderungen noch besser gerecht zu werden. Dabei sind diese Angebote seit Jahren im Markt verfügbar. Workshops zu „Lateral Leadership“ (Wie führe ich ohne direkte Weisungsbefugnis? Siehe auch Kap. 8 von Tim Herbig „Lateral Leadership im Produktmanagement“), Verhandlungstrainings (Wie verhandle ich richtig, um meine Ziele zu erreichen?) oder zum Thema Change Management (Wie erreiche ich eine Veränderung in meiner Organisation, um einen gewünschten Zielzustand herzustellen?) sind nur einige Angebote, die hier einen wertvollen Beitrag zur professionelleren Kommunikation für Produktmanager leisten können. Es ist dabei allerdings meist Aufgabe der Produktmanager, diese Ausbildungsbausteine aktiv bei seinen Vorgesetzten einzufordern und sich nicht nur auf das Erlernen der nächsten Design-Thinking-Methode zu beschränken. Auch das ist Produktmanagement.

13  Produktmanagement ganzheitlich verstanden

219

13.4 Der Produktmanager als „Entscheidungsmacher“ Als Produktmanager hat man die wichtige Aufgabe, dafür zu sorgen, dass Entscheidungen zu jedem Zeitpunkt und von allen Stakeholdern in ihrem Verantwortungsbereich getroffen werden können. Ein Produktmanager muss sich klar darüber sein, über welche Handlungen er diesen Zustand herstellen kann. Denn nur, wenn kleine und große Entscheidungen getroffen werden, können diese auch zeitnah umgesetzt werden. u

Als Produktmanager muss man sich sehr klar darüber sein, über welche Handlungen alle kleinen und großen Entscheidungen innerhalb komplexer Aufgabenstellungen herbeigeführt werden können, denn letztlich stellen sie die Basis für ein erfolgreiches Produkt dar.

Es geht aber explizit NICHT darum, dass der Produktmanager alle Entscheidungen alleine treffen soll. Es geht darum, all die verschiedenen und sich schnell entwickelnden Arbeitsstränge mit den immer neu eintreffenden Informationen zusammenzuhalten. Und darum, alle an der Produktentwicklung Beteiligten zu befähigen, am Gesamtziel ausgerichtet sowie entscheidungsfähig zu bleiben. Die im Folgenden genannten Aspekte spielen dabei eine wesentliche Rolle:

13.4.1 Klar formulierte Ziele Ziele sind nichts Anderes als klar formulierte Erwartungshaltungen. Es gilt, den Stakeholdern ein klares und nachvollziehbares Bild darüber zu vermitteln, welche Erwartungen an den Erfolg des Produktes gestellt werden. Dabei ist es von enormer Bedeutung so viel relevanten Kontext wie möglich zu geben: Warum etwas passieren soll, welche strategischen Gründe dafür sprechen oder auch, was explizit nicht erreicht werden soll. Zentral dabei ist eine möglichst präzise Beschreibung des zu erzielenden Outputs und des Outcomes. Mit diesen beiden Zielen legt man den Grundstein für weitere Fragestellungen und natürlich auch dafür, die Stakeholder gemeinsam in die richtige Richtung gehen zu lassen: u

Der Output beschreibt dabei das erwartete Produktionsergebnis. Beispielsweise die Umsetzung von zwei optimierten Varianten eines bereits existierenden Eingabeformulars in einer iOS-App, die mittels A/B-Tests den Usern gleichverteilt angezeigt werden sollen. Ziel ist es herauszufinden, ob mit ihnen bessere Registrierungsquoten als mit dem existierenden Eingabeformular erreicht werden können.

220

P. Roelofs

Das Outcome beschreibt, welche Wirkung beim Nutzer erzielt werden soll. Beispielsweise eine Steigerung der Konversionsrate von mindestens +2 %, d. h. +500 Neukundenregistrierungen/Monat. Mit Hilfe dieser bereitgestellten Informationen ist es für die Stakeholder um ein Vielfaches einfacher, nachvollziehbare und am Ziel ausgerichtete Entscheidungen in der Product Discovery (siehe Kap. 3 „Product Discovery“ von Alexander Hipp und Philip Steen) und Product Delivery (siehe Kap. 7 von Tim Adler „Product Delivery“) zu treffen.

13.4.2 Maximale Transparenz („Connecting the dots“) Man kann nur auf das reagieren, was man sieht. Darum ist es wichtig, die erforderliche Transparenz für alle Stakeholder zu gewährleisten, um entsprechend adaptiv auf neue Entwicklungen/Einflussfaktoren reagieren zu können. Dabei geht es einerseits darum, das richtige Maß an Überblick für alle Stakeholder herzustellen, das es ermöglicht, den Fortschritt in den einzelnen beteiligten Teams und deren Abhängigkeiten zu anderen Teams abzubilden. Andererseits ist es wichtig, diese Sicht zu einem übergeordneten „Output“ zusammenzufügen. Zentrale Fragen, die es dabei zu beantworten gilt, sind z. B.: • Verantwortlichkeiten: Sind die Verantwortlichkeiten pro Stakeholder und pro Thema zu 100 % klar? • Arbeitspakete: Sind alle Arbeitspakete und Abhängigkeiten allen Stakeholdern klar? • Schriftliche Übersicht: Gibt es eine konsolidierte Liste der Arbeitspakete und Abhängigkeiten als Referenz dazu? Wo finde ich diese? • Bestehende Unklarheiten: Zu welchen Themenbereichen müssen weitere Informationen gesammelt werden, bevor eine verbindliche Aussage zu Komplexität/Umfang/ Abhängigkeiten/Zeitaufwand getätigt werden kann? • Neue Erkenntnisse: Gibt es neue Entwicklungen, die wir berücksichtigen müssen? Beispielsweise, ob ein Arbeitspaket deutlich aufwändiger als erwartet ist und somit Einfluss auf den Output eines anderen Teams hat? • Projektfortschritt: Welche Arbeitspakete sind aktuell in Bearbeitung und sind diese im Zeitplan? Die so hergestellte Transparenz ist jedoch nur Mittel zum Zweck. Sie hat die Aufgabe, die Stakeholder dazu anzuregen in einen regelmäßigen Austausch miteinander zu gehen. Häufig ergibt sich daraus dann automatisch ein „Redebedarf“ auf der Basis der vorliegenden (nun sehr transparenten) Informationen. Falls das nicht der Fall ist, kann man hier als Produktmanager auch noch einmal nachhelfen.

13  Produktmanagement ganzheitlich verstanden

221

Denn auch, wenn es dem einen oder anderen Stakeholder seinem individuellen Empfinden nach ggf. zu aufwändig erscheint: ein wöchentlich stattfindender einstündiger Termin mit den wichtigsten anderen Stakeholdern ist sinnvoll investierte Zeit, um die neuesten Entwicklungen durchzugehen und als „Organisation“ entscheidungs- und handlungsfähig zu bleiben.

13.4.3 Notwendige und sinnvolle Eskalationen Die Eskalation ist einer der am meisten unterschätzen Aspekte, um in schnellen, komplexen Projekten kritischen Verzögerungen durch nicht getroffene Entscheidungen vorzubeugen. Leider wird Eskalation von den meisten Menschen als etwas Negatives angesehen. Etwas, das nur im äußersten Notfall stattfinden sollte, anstatt es als den „Klärenden und schnell zur Entscheidung führenden Prozess“ bei einem inhaltlichen Konflikt anzusehen. Das mag darin liegen, dass eine Eskalation aus Unwissenheit von den beteiligten Parteien oft nicht nach den richtigen Spielregeln durchgeführt wird. Zu beobachten sind häufig, dass erstens nicht bzw. nicht richtig unter den betroffenen Konfliktparteien kommuniziert wird. Und dass zweitens eine oder mehrere Konfliktparteien bei der Darlegung des Konflikts gegenüber dem finalen Entscheider außen vorgelassen werden. Dadurch wird der Konflikt – mindestens für eine der Konfliktparteien – (zu) einseitig dargestellt. Persönliche Reibungen sind hier vorprogrammiert. Gehen wir also davon aus, dass es in jedem Projekt/jeder größeren Initiative eine Person gibt, die die notwendige Entscheidung final treffen kann (i. d. R. der Produktmanager oder der nächst höhere Bereichsleiter). Gehen wir weiter davon aus, dass zwei Teams jeweils gute, aber doch sehr unterschiedliche Ansätze zur Lösung eines Problems entwickelt haben und diese Teams darauf bestehen, dass genau ihre Lösung umgesetzt wird. Um in dem Fall eine Eskalation fair und transparent für alle Konfliktparteien herbeizuführen, können die folgenden Schritte durchgeführt werden: 1. Eine der beiden Konfliktparteien sollte persönlich und ggf. schriftlich die andere Konfliktpartei darauf hinweisen, dass eine Eskalation durch ausbleibende Einigung erforderlich scheint und diese nun „eingeleitet“ wird. 2. Die andere Konfliktpartei und der Entscheider werden zu einem Klärungstermin eingeladen. 3. Bevor man auf den Entscheider in diesem Termin trifft, werden die Problematik und im Raum stehende Lösungsansätze schriftlich dargestellt und vorab mit der anderen Konfliktpartei abgestimmt („Ist das so richtig dargestellt? Was siehst Du anders?“). 4. Die gemeinsam abgestimmte Beschreibung der Konfliktsituation wird vorab an Entscheider im Namen beider Konfliktparteien gesendet.

222

P. Roelofs

Folgt man diesen Schritten, ist eine ego-freie und sachliche Diskussion in den meisten Fällen möglich. Und auch, wenn es nicht immer so erscheint: Konflikte und Eskalation in komplexen Aufgabenstellungen mit vielen Stakeholdern sind etwas völlig Normales und Notwendiges. Nur so können die richtigen Diskussionen geführt und letztlich die richtigen Entscheidungen getroffen werden. Auch das ist Produktmanagement.

13.5 Der Produktmanager als Antworten-Lieferant Da der Produktmanager als Schnittstelle zu allen am Produktentwicklungsprozess beteiligten Akteuren agiert, gehört es auch zu seinen zentralen Aufgaben, Antworten auf viele relevante Fragen zu geben, die typischerweise in solchen Prozessen aufkommen. Nach einigen Jahren als Produktmanager wird man dabei häufig feststellen, dass es sich vielfach um die immer gleichen Fragen handelt. Und dennoch sind Produktmanager häufig nicht gut genug vorbereitet, um die passenden Antworten unmittelbar, mit möglichst geringem Aufwand und somit wenig Zeitverzug zu liefern. John Cutler, Produktmanager aus Kalifornien/USA, hat genau aus diesem Grund eine umfassende Fragenliste zusammengestellt, die jeder Produktmanager jederzeit beantworten können sollte. Das hierfür verwendete Szenario orientiert sich an einem typischen Dialog zwischen Produktmanager und seinem Vorgesetzten, der fragt: „Lieber Produktmanager, ich spreche in 5 Minuten mit unserem CEO. Du hast 30 Sekunden Zeit, um mich zu informieren: Was muss ich wissen?“

Mit den folgenden Fragen, die augedruckt auf jeden Produktmanager-Schreibtisch gehören, und der kontinuierlichen Selbstüberprüfung dieser Fragen, sollte man für die meisten Situationen gut vorbereitet sein. u Briefingfragen für einen Produktmanager (John Cutler 2018): 

• Hast Du gute Neuigkeiten? Wenn ja, auf Basis welcher Datenpunkte? • Haben wir etwas Neues gelernt, seit wir das letzte Mal sprachen? Wenn ja, auf Basis welcher Datenpunkte? • Was müssen wir noch lernen/verstehen? Wie stellen wir das an? • Hat sich die übergeordnete Geschichte zum Produkt/zum Entwicklungsprozess verändert? Wenn ja, wie? • Brauchst Du Hilfe? Wo kann ich einen „Knoten“ für Dich lösen? • Welche Informationen/welchen Kontext brauchst Du von mir, damit Du gute Produktentscheidungen treffen kannst? • Gab es neue Entwicklungen, von denen ich wissen sollte? • Wie misst Du den Erfolg Deiner aktuellen Mission?

13  Produktmanagement ganzheitlich verstanden

223

• Was ist die eine Sache, an der wir jetzt unbedingt arbeiten sollten? Warum jetzt? • Wie steigert Deine aktuelle Arbeit unseren Umsatz/reduziert unsere Kosten? • Wie verändert Deine aktuelle Arbeit das Kundenverhalten? Von welchen Kunden(-segmenten) genau? • Was wird dadurch (für uns als Unternehmen) möglich? • Warum hast Du genau diese Lösung aus all den möglichen Lösungen ausgewählt, um das Ziel zu erreichen? • Was ist die Wette, die hier eingegangen wird? Wie verhält sich das zu anderen Wetten, die wir hätten eingehen können? • Gibt es auftretende Risiken? Wie begegnen wir diesen Risiken? • Wann würde Deine aktuelle Mission/das Projekt gestoppt werden? •  Wurden erste Arbeitsergebnisse schon Kunden gezeigt? Wie sieht das Kundenfeedback zur aktuellen Mission/zum Projekt aus? • Welches ist der nächste wichtige Meilenstein? • Was ist Deine Vision für die nächsten 6 Monate? • Was müssen Marketing, Sales, Customer Success, Data (und andere Stakeholder) darüber wissen? • Wie ist die Teammoral? Was tust Du, damit sie stark bleibt/sich verbessert? • Was tust Du, um dem Team einen Einblick in den Beitrag, den sie für das Unternehmen leisten, zu geben? Was ist ihr Feedback darauf? • Wenn alte, getroffene Entscheidungen kein Thema wären, was würdest Du in 3, 6, 12 Monaten anders machen? Man darf sich nichts vormachen: Seitens der Stakeholder und des Managements ist der Produktmanager erster Ansprechpartner für all diese Fragen. Je schnell und präziser sie beantwortet werden können, desto mehr Vertrauen und damit Freiheiten werden dem Produktmanager geschenkt werden. Auch das ist Produktmanagement.

13.6 Der Produktmanager ist (klarer) Gedanken-Formulierer Ein weiterer wichtiger Beitrag, den ein Produktmanager innerhalb seiner Organisation liefern muss, sind klare und strukturiert (idealerweise schriftlich) formulierte Gedanken. Klingt simpel? Ist es ganz und gar nicht. Nicht nur muss sich der Produktmanager klar darüber sein, dass dies ein zentraler Teil seines Wertbeitrags für seine Stakeholder ist, er muss sich auch klar darüber werden, dass er es ist, der versuchen muss, alle relevanten Perspektiven mit einzubeziehen. Je klarer der Produktmanager seine Gedanken darlegen kann bzw. andere dazu bringt, dies zu tun, desto einfacher wird es gute Ergebnisse erzielen.

224

P. Roelofs

Und gleichzeitig steht der Produktmanager vor der Herausforderung, dass es in den heutigen agilen Organisationen immer weniger „üblich“ ist, seine Gedanken in erstens strukturierter und zweitens schriftlicher Form auszuarbeiten. Viel zu selten werden heute komplexe Fragestellungen von allen relevanten Seiten beleuchtet. Im Gegenteil: Zu Abstimmungs- und Diskussionszwecken werden überschaubar kurze Präsentationen mit – im besten Fall – ein paar Stichpunkten in PowerPoint vorgelegt. Auf diese Weise wird jedoch lediglich die Oberfläche komplexer Sachverhalte angekratzt. „Eine detaillierte Betrachtung ist zu zeitaufwändig und zudem auch nicht wirklich agil“, sind dann häufig vorgebrachte Einwände (Ausreden?), die gegen einen strukturierten Prozess angeführt werden. Das Ergebnis: Nicht alle Stakeholder haben das gleiche Verständnis zum geplanten Vorgehen, den notwendigen Aspekten der Produktentwicklung oder zum Umfang des Projekts. Je später es dann auffällt, dass die Erwartungen der Stakeholder stark voneinander abweichen, desto größer sind dann die auftretenden Konflikte und der Mehraufwand von eventuellen Korrekturen, da das Projekt schon weit vorangeschritten ist. „Ach so, ich hatte mir das aber ganz anders vorgestellt!“ ist dann eine typische, aber auch folgenschwere Aussage. Hilfe bei der Ausarbeitung einer detaillierten Betrachtung und Abwägung unterschiedlicher Perspektiven bieten mittlerweile recht ausgereifte Frameworks, wie beispielsweise die Auftragsklärung (www.auftragsklaerung.com). Diese wurde von Produktmanagern bei XING genau zum Zweck der frühen Synchronisation der Erwartungshaltungen und zur strukturierten Kommunikation unter Stakeholdern entwickelt (siehe auch Kap. 5 von Arne Kittler „Alignment als Kernkompetenz für Produktmanager“). Die Auftragsklärung bietet als Framework einen soliden Leitfaden entlang relevanter Fragestellungen, die helfen, in einem Produktentwicklungsprozess so früh wie möglich alle Stakeholder „on the same page“ zu bringen. Zudem können Themen in der notwendigen Informationstiefe diskutiert und schließlich verbindlich verabschiedet werden. In diesem Zusammenhang wird bei XING auch häufig von der ­Spice-Girls-Frage gesprochen: „Tell me what you want, what you really, really want“. Einige der in der Auftragsklärung behandelten Aspekte sind: • Komplikationen: Was ist das Problem oder der Auslöser für dieses Projekt/diese Initiative? • Absicht: Was ist es, das wir mit dieser Initiative wirklich erreichen wollen? • Hypothesen: Was muss zutreffen, damit unser „Output“ zu dem gewünschten „Outcome“ führt? Arbeitet man als Produktmanager entlang dieses Frameworks, wird einem selbst – und hoffentlich auch allen Anderen – relativ schnell klar, wie viel Substanz die eigenen (schriftlich dargelegten) Gedanken zum Produktentwicklungsprozess aufweisen.

13  Produktmanagement ganzheitlich verstanden

225

Der echte Wert entsteht aber nicht allein durch das Aufschreiben der Gedanken, sondern vielmehr durch das Teilen mit seinen Stakeholdern und den daraus resultierenden notwendigen Diskussionen. Auch das ist Produktmanagement.

Literatur Cutler, J. 2018. PM tip: 30 seconds answers (to common questions). https://medium.com/@ johnpcutler/pm-tip-30-seconds-answers-to-common-questions-2c8a33b6643c. Ferazzi, S., und T. Raz. 2005. Never eat alone. New York: Currency Doubleday.

Der Autor  Patrick Roelofs  ist als VP Product & User Experience Teil des Führungsteams der Lotto24 AG, dem deutschen Marktführer für Online-Lotterie-Vermittlungen. Davor unterstützte er fast zwei Jahre als freiberuflicher Product Owner Early Stage Startups sowie etablierte Technologieunternehmen beim Management ihrer Produktlösungen. Bei XING war er zudem über fünf Jahre als Director Product Management sowohl für die B2C-Monetarisierung, als auch für diverse B2BProdukte verantwortlich. Vor dieser Zeit gründete er in Hamburg die eparo GmbH, eine der noch immer führenden User-Experience-Agenturen Deutschlands. Kontakt: [email protected]

Die agile Transformation der Hanseatic Bank

14

Wie eine Bank sich den neuen digitalen Herausforderungen stellt Matthias Blaß

Zusammenfassung

Digitales Produktmanagement erfordert ein Umdenken bezüglich klassischer Arbeitsmethoden und etablierter Erkenntnisse. Arbeitsweisen ändern sich und Organisationsformen müssen sich den neuen Gegebenheiten anpassen. Hoher Wettbewerbsdruck und Disruption durch Start-ups beschäftigen Unternehmen vieler Industriebereiche. Das abschließende Kapitel beschreibt den Prozess einer digitalen Transformation im Bankenumfeld. Am Beispiel der Hanseatic Bank wird gezeigt, wie man mit fachbereichsübergreifenden Maßnahmen wie Transformationsworkshops, einem Solution Lab, einer Zukunftswerkstatt und einer gemeinsamen technischen Vision den Wandel auch in einem konservativen und stark regulierten Umfeld angehen kann.

14.1 Über die Hanseatic Bank Die Hanseatic Bank, eine Tochtergesellschaft der Otto Group und der französischen Société Générale Group, ist eine Privatbank aus Hamburg. 1969 als Teilzahlungsfinanzierer für die Otto Katalogkunden gegründet, konzentriert man sich heute auf vier Hauptgeschäftsfelder: das Factoring-Geschäft für Otto und einige Konzerngesellschaften, Konsumentenkredite mit Kreditkarten und Privatkrediten, Einlagen sowie Versicherungen. Das Versicherungsgeschäft dient hauptsächlich der Kreditabsicherung und wird über Kooperationspartner vermittelt.

M. Blaß (*)  Hanseatic Bank GmbH & Co KG, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2020 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-30629-8_14

227

228

M. Blaß

Abb. 14.1   Gesellschafterstruktur. (Quelle: Eigene Darstellung)

Durch diese klare Fokussierung versteht sich die Hanseatic Bank als Direktbank mit starkem Online-Bezug. Als Nischenspezialist ist es das Ziel, konkrete Marktsegmente zu besetzen und genau herauszufiltern, welche Produkte und Lösungen die Kunden und Partner wirklich benötigen, um diese für die Zukunft zu begeistern. An dieser Unternehmensvision arbeiten rund 500 motivierte Mitarbeiter im Unternehmen (Abb. 14.1). Sich zu fokussieren bedeutet, die klassische Frage nach „Make or Buy“ immer häufiger mit „Buy“ zu beantwortet. So führt beispielsweise der Weg klar in Richtung Cloud und damit weg von Inhouse-Lösungen. Die Hanseatic Bank hat erkannt, dass man den Kunden gemeinsam mit Partnern schneller und zielgerichteter optimierte Produkte und Services anbieten kann. Gerade mit den sogenannten FinTechs, auf Finanzprodukte oder -prozesse spezialisierte Start-ups, möchte man innovative und kundennahe Ideen realisieren. Ein wichtiger Treiber ist hierbei die Digitalisierung. Es ist erklärtes Ziel der Hanseatic Bank, schnellere und effizientere digitale Prozesse zu etablieren, um vor allem die Mitarbeiter im Kundenservice von aufwändigen manuellen Aufgaben zu entlasten. Dadurch werden Freiräume geschaffen, die in der persönlichen Beratung von Kunden und Partnern sinnvoll eingesetzt werden können. Geschwindigkeit, Automatisierung und ein bestmögliches Kunden- bzw. Partnererlebnis spielen auch im E-Commerce-Bereich eine wichtige Rolle. So bietet die Bank seit 2008 als eine der ersten Banken eine Sofortentscheidung für Kreditanfragen in der Online-Warenfinanzierung an. Dadurch erhalten Kunden online innerhalb weniger Sekunden eine Kreditzusage und der Händler kann die Ware versenden. Damit die Kunden über jeden Vertriebskanal ein medienbruchfreies Produkterlebnis erfahren, können Kreditkarten komplett online beantragt werden – Von der Datenübernahme aus externen Konten über die Kreditzusage in Echtzeit bis zur digitalen Vertragsunterzeichnung. Gerade für mobile Endgeräte ist ein solch volldigitaler und papierloser Prozess ideal. Digitale Services und Lösungen spielen eine immer wichtigere Rolle im Produktportfolio der Hanseatic Bank. Hinter jedem Kundenprodukt steckt am Ende des Tages ein digitales Konto, umrahmt von weiteren digitalen Services mit dem Ziel, Banking

14  Die agile Transformation der Hanseatic Bank

229

für den Kunden so einfach wie möglich zu gestalten. Das wichtigste Asset ist jedoch der Kunde selbst. Diesen gilt es in einer von Globalisierung, Digitalisierung und Wertewandel geprägten Welt zu sichern und mit bestmöglichen Services zu begeistern. Um dies zu erreichen, hat die Hanseatic Bank ein umfangreiches Transformationsprojekt gestartet.

14.2 Am Anfang steht die Erkenntnis Banking ist schon lange stark mit Technologie verbunden. Seit der Einführung des ersten Bankautomaten in Deutschland im Jahr 1968, dem Online Banking via BTX im Jahr 1983, bis zur ersten Banking App Outbank im Jahr 2009 hat sich viel getan. Einen massiven Schub brachte 2007 die Einführung des ersten iPhones, womit das Internet und die damit verbundenen Handlungen wirklich mobil wurden. Innovative Start-ups und die großen internationalen Technologiekonzerne stellen den Kunden in den Mittelpunkt ihres Handelns und rücken damit auch immer stärker in die Nähe der Banken – und vor allem den Bankkunden. Sie besitzen teilweise Banklizenzen und vor allem zahlreiche Fintech-Patente. Europaweite Regulatorik wie die zweite Zahlungsdiensterichtlinie (PSD2) zwingt die Banken zusätzlich, sich Drittanbietern zu öffnen. So werden die Banken vom Innovationstreiber zum Getriebenen und müssen die wichtige Kundenschnittstelle öffnen. Auch die Hanseatic Bank hat erkannt, dass sowohl Technologie als auch Prozesse nicht über dem Kundennutzen stehen dürfen. Dabei ist es egal, ob es sich um Kunden oder andere (interne) Stakeholder handelt. Nur ein enger Kontakt und ein direkter sowie regelmäßiger Austausch mit Kunden und Dienstleistern ermöglichen es, genau auf Kundenbedürfnisse abgestimmte Produkte und Services zu entwickeln. Bankprodukte werden austauschbar. Gebühren- und Ertragsmodelle lösen sich auf. Eine Differenzierung zu anderen Banken muss daher auf anderer Ebene erfolgen. Zum Beispiel über den Service und auf den Kunden ausgerichtete individuelle Mehrwerte. Schnelle Reaktionszeiten und eine flexible Organisation werden dabei vom Kunden vorausgesetzt. All das funktioniert aber nur, wenn auch das technologische Fundament und eine darauf ausgerichtete Organisation dafür bereitstehen. Bietet eine Bank das nicht, wird sie recht schnell durch einen innovativeren Wettbewerber ersetzt. u

„When the rate of change inside an institution becomes slower than the rate of change outside, the end is in sight. The only question is when.“ (Jack Welch 2001)

Um weiterhin erfolgreich am Markt agieren zu können und die Arbeitsplätze der Mitarbeiter auch in Zukunft sicherzustellen, hat die Hanseatic Bank bereits 2015 mit einem

230

M. Blaß

ersten Digitalisierungsworkshop versucht, alle Führungskräfte auf eine gemeinsame „digitale Linie“ einzuschwören. Die Bank sollte u. a. in der eigenen Unternehmensgruppe noch stärker als digitaler Player wahrgenommen und die Mitarbeiter sowohl in der Bank als auch im Service Center motiviert werden. Die Hoffnung war, dass sich eine digitale Bewegung von den Mitarbeitern bottom-up ergibt. Wie so oft passierte lange über Einzelinitiativen hinaus jedoch nicht viel und der Anfang war sehr holprig. Ein hoher Anteil an Regulatorik, hohe Projektauslastung und der ständige über Bereichsgrenzen und -silos hinaus stattfindende Kampf zwischen fachlichen Anforderungen, zur Verfügung stehenden Mitarbeitern und Budgets machten die ersten Gehversuche in Richtung Transformation mühsam. Mit diesen Herausforderungen sieht sich jedoch nicht nur die Hanseatic Bank konfrontiert, sondern die meisten Finanzinstitute ebenso wie andere Industrien.

14.3 Ein wichtiger Impuls von oben Lange hielt sich der geflügelte Ausspruch „wir müssen agiler werden“ in zahlreichen Meetings. Nur die Wenigsten verstanden darunter den eigentlichen Sinn von Agilität. Die Meisten setzten „agil“ mit „schneller“ gleich. Folgerichtig war die Akzeptanz zunächst gering, weil es für die meisten Mitarbeiter nur nach mehr Zeitdruck und höherer Arbeitslast klang. Die Geschäftsführung der Hanseatic Bank erkannte, dass der nötige Impuls anders gesetzt werden muss. Eine erfolgreiche Transformation kann nur durch die Mitnahme aller Mitarbeiter gelingen. Im Dezember 2016 fand daher ein weiterer Workshop statt. Im Unterschied zur Veranstaltung 2015 nahmen dieses Mal neben den Führungskräften auch Mitarbeiter teil. Das Verhältnis war zwar noch nicht ausgeglichen, aber es war ein erstes Signal ins Unternehmen. Besonders da vor allem Mitarbeiter teilnahmen, die bereits als interne Influencer für digitale Themen agierten. Zudem gab es die klare Ansage der Geschäftsführung, dass alles zu hinterfragen und alles gemeinsam, gleichberechtigt sowie ohne hierarchische Grenzen zu diskutieren sei. In diesem „Disrupt-us-Workshop“ (Abb. 14.2) wurden die wesentlichen Weichen für den folgenden Wandel gestellt. Das Statement der Führung lautete: Wir wollen die Veränderung gemeinsam mit allen Mitarbeitern schaffen und wir tun es jetzt, weil wir es uns jetzt (noch) leisten können! Weiterhin wurde von Beginn an und auch während des gesamten Transformationsprozesses immer wieder herausgestellt, dass der Change nicht der Kostenreduktion dient, was in der Regel mit dem Abbau von Arbeitsplätzen einhergeht. Das Gegenteil ist der Fall. Die Hanseatic Bank stellt Jahr für Jahr neue Rekorde auf und ist sehr erfolgreich in ihren Geschäftsfeldern. Und trotzdem hat sie sich für eine konsequente Transformation entschieden.

14  Die agile Transformation der Hanseatic Bank

231

Chancen Digitalisierung

Potenale „Disrupt us“

Dynamisches Umfeld

Herausforderungen

modern & agil

Risiken

Abb. 14.2   Zielbild Disrupt-us-Workshop. (Quelle: Eigene Darstellung)

Die wesentlichen Ziele des Workshops waren schnell definiert: • Eine deutlich höhere Innovationsfähigkeit • Ein an die Herausforderungen angepasstes und optimiertes Organisationsmodell • Eine flexible technische Plattform für alle Anforderungen Und auch die wichtigsten Maßnahmen, die im Workshop entwickelt wurden, waren erstaunlich klar und von hoher Akzeptanz aller Beteiligten geprägt: • Durchführung eines initialen Solution Lab zum Erlernen agiler Methoden und zum Entwickeln prototypischer Ideen (Abschn. 14.4.1) • Einrichtung einer Zukunftswerkstatt als Transformationseinheit im Unternehmen (Abschn. 14.4.2) • Entwicklung einer Open-Banking-Plattform als Basis künftiger IT-Entwicklungen nach innen und außen (Abschn. 14.4.3) Der daraus resultierende Auftrag der Geschäftsführung war eindeutig und herausfordernd zugleich: Wir wollen die ersten Ergebnisse in spätestens 100 Tagen sehen. Und wir wollen, dass die Mitarbeiter die Umsetzung federführend übernehmen. Das Management wird nur als Sponsor in Erscheinung treten.

14.4 Systeme, Prozesse und Kulturwandel Nach dem Workshop fanden sich schnell weitere interessierte Mitarbeiter aus allen Unternehmensbereichen, die an den unterschiedlichen Arbeitsgruppen mitwirken wollten.

232

M. Blaß

14.4.1 Mit dem Solution Lab beginnt das Abenteuer Anfang April 2017, kurz nach der gesetzten 100-Tage-Frist, ging das erste Solution Lab (Abb. 14.3) als erste sichtbare Maßnahme der Hanseatic Bank an den Start. Zu diesem Zweck wurde eine separate Fläche in einem Coworking Space angemietet. Damit war gewährleistet, dass die Mitarbeiter tatsächlich für den Zeitraum des Labs von ihrer normalen Tätigkeit freigestellt werden. Die Idee hinter diesem Lösungslabor ist es, Mitarbeiter aus dem Büroalltag herauszuholen und ihnen in einem crossfunktionalen Team die Möglichkeit zu bieten, innerhalb von vier Wochen eine Idee bis zu einem Prototyp zu entwickeln. Begleitet von einem Agile Coach lernen die Mitarbeiter unterschiedliche Methoden und Frameworks kennen und versuchen, diese adäquat anzuwenden. Die Teammitglieder durchleben in vier „Ein-Wochen-Sprints“ fast immer alle Teamentwicklungsphasen. Vom Forming (Findungsphase) zum Storming (Konfliktphase) über das Norming (Übereinkommensphase) bis zum Performing (Leistungsphase). Dabei lernt jedes Teammitglied, wie wichtig es ist, sich mit den unterschiedlichen Typen (Kollegen) auseinanderzusetzen, deren Qualifikationen ein- und wertzuschätzen und der gemeinsamen Arbeit einen Sinn zu geben (Tuckmann 1965). Der Weg zu einem Solution Lab folgt bei der Hanseatic Bank einem bestimmten Prozess: • Es beginnt mit der Vorstellung einer Idee und einem Voting in einem Intranetforum. Jeder Mitarbeiter im Unternehmen erhält somit die Chance, eine Idee zu präsentieren. Im Forum kann die Idee vorab bewertet und diskutiert werden. So finden sich schnell Interessierte für die Ideenumsetzung.

Abb. 14.3   Solution Lab. (Quelle: Eigene Abbildung)

14  Die agile Transformation der Hanseatic Bank

233

• Der Ideengeber hat im Forum außerdem die Möglichkeit, weitere Teammitglieder einzuladen, sollte sich noch kein Team mit allen benötigten Skills zusammengefunden haben. • Im Anschluss findet ein öffentlicher Pitch statt, bei dem die Top-3-Ideen einer Jury vorgestellt werden. Die Ideen müssen dabei Mehrwerte für Kunden, Partner oder die Bank erwarten lassen und bestimmte strategische Kriterien erfüllen. Inwieweit diese Kriterien erfüllt sind, entscheidet die Jury, bestehend aus einem Kernteam und den Pitch-Besuchern (Publikum). • Die Siegeridee aus jeder Pitchphase wird dann vier bis sechs Wochen später als neues Solution Lab gestartet. • Ein Team aus durchschnittlich sechs bis acht Mitarbeitern entwickelt sodann im Lab als erstes eine Vision und daraus je nach Thema einen Prototyp oder ein detailliertes Konzept. • Am Ende des Lab-Zeitraums wird das Ergebnis dem Kernteam der Jury vorgestellt und es wird gemeinsam entschieden, wie mit dem Ergebnis weiter umgegangen wird. Bleibt es bei der Idee oder lohnt sich die konkrete Umsetzung eines neuen Produktes oder Services (Abschn. 14.4.4)? Das Ziel der Hanseatic Bank ist es, mindestens drei bis vier Labs pro Jahr durchzuführen. Seit dem Start in 2017 wurden bis Ende 2019 elf reguläre Labs durchgeführt. Die Räumlichkeiten in dem Coworking Space stehen außerhalb der Lab-Phasen jedem Mitarbeiter für Team- oder Projektarbeiten zur Verfügung. Die Idee, mit den Labs den Mitarbeitern eigenverantwortliches Arbeiten und agile Prinzipien in crossfunktionalen Teams näherzubringen, geht auf. Auch wenn jeder Lab-Zeitraum nur von kurzer Dauer ist, so ist doch jeder Teilnehmer über die neue und vor allem selbstbestimmtere Art zu arbeiten begeistert. Mit diesen positiven Erfahrungen gehen die Teilnehmer nach vier Wochen zurück in ihre Linienorganisation. Das Solution Lab „irritierte“ im Organisationsentwicklungssinne die Organisation und bildete die ersten Ansätze für einen „Grassroot-Effekt“1. Das Solution Lab ist zwischenzeitlich etablierter Bestandteil der Veränderung und diese positive Entwicklung ist wiederum Teil des initiierten Changeprozesses und unterstützt vor allem den notwendigen Kulturwandel von innen heraus.

1Das

Ziel von einigen G ­raswurzel-Initiativen ist es, (gesellschaftliche) Alternativen zum Bestehenden aufzubauen, bis hin zum revolutionären Anspruch, grundsätzliche Systemveränderungen zu bewirken (Sprache am Markt GmbH o. J.).

234

M. Blaß

14.4.2 Die Zukunftswerkstatt begleitet den Wandel Wie wollen oder müssen wir künftig zusammenarbeiten? Wie muss ein modernes und flexibles Organisationsmodell aussehen, mit dem wir auch die nächsten zehn Jahre erfolgreich als Bank agieren? Diese Fragen wurden ebenfalls auf dem 2-Tages-Workshop gestellt. Ihrer Beantwortung näherte man sich iterativ etwa ein halbes Jahr später. Losgetreten wurde der Prozess auf Initiative der Bereiche Marketing, Vertrieb und IT, um zu prüfen, warum es immer wieder zu Problemen in der Projektzusammenarbeit kommt. Die drei genannten Bereiche sind traditionell stark vernetzt und unterliegen enormen Abhängigkeiten. Im Juli 2017 fand deshalb eine Workshop-Reihe mit Teilnehmern aus allen drei Bereichen statt. In parallel stattgefundenen Workshops sollten Führungskräfte und Mitarbeiter unabhängig voneinander untersuchen, welche die größten Druckstellen in der Zusammenarbeit sind. Die Ergebnisse wurden zusammengetragen und ausgewertet. Es wurden die typischen Herausforderungen identifiziert: Mangelnde Kommunikation über Bereichsgrenzen hinweg, zu viele gleichzeitige Projekte, eine ständig wechselnde Priorisierung und eine damit verbundene sehr hohe Mitarbeiterauslastung, die auf Dauer zu Unzufriedenheit führt. Gerade weil man feststellte, dass die Druckstellen typisch für alle Unternehmensbereiche sind und eben nicht nur Marketing, Vertrieb und die IT betreffen, wurden ausgewählte Mitarbeiter dieser Bereiche von der Geschäftsführung damit beauftragt, eine erste Idee für eine neue, zukunftsfähige Organisationsform zu entwickeln. Begleitet von Agile Coaches und unterstützt durch parallel im Unternehmen stattfindende agile Trainings, erarbeiteten die Mitarbeiter in weiteren Workshops den Entwurf eines neuen Organisationsmodells. Ein wesentlicher Bestandteil dieser Workshops lag darin, Vertrauen zu schaffen und zu zeigen, dass die Mitarbeiter ihre Zukunft im Unternehmen tatsächlich selbst mitgestalten können und dass keine bereits vorgefertigten Pläne für eine Transformation existieren. Das Ergebnis wurde der Geschäftsführung im September 2017 erfolgreich präsentiert. Den daraus resultierenden Auftrag, das entwickelte Organisationsmodell weiter im Detail auszuarbeiten und einzuführen, erhielt ein kleines Transformationsteam, die sogenannte „Zukunftswerkstatt“. Vier Mitarbeiter aus IT und Marketing erarbeiteten mit Unterstützung durch ein erweitertes Team aus Spezialisten und Führungskräften schließlich den Umsetzungs- und Change-Management-Plan. Ziel war es, im Februar 2018 mit einem Piloten (siehe Abschn. 14.5.1) für die neue Organisation zu starten. In einem internen Wiki wurden die gesamten Arbeitspakete transparent veröffentlicht und alle Mitarbeiter hatten die Möglichkeit, zu kommentieren und mitzudiskutieren. Neben der rein fachlichen Bearbeitung, wie der Entwicklung der zukünftigen Rollen oder dem internen Bewerbungsprozess, beschäftigte sich die Zukunftswerkstatt verstärkt mit dem Veränderungsprozess. Es wurden regelmäßige Informationsveranstaltungen wie

14  Die agile Transformation der Hanseatic Bank

235

Info-Points, World-Cafés und Fishbowls2 mit allen interessierten Mitarbeitern durchgeführt. Zielsetzung war dabei, alle Fragen zu beantworten, Unklarheiten auszuräumen und von Anfang an alle Mitarbeiter im Unternehmen an diesem Prozess teilhaben zu lassen. Der laufende Transformationsprozess im Unternehmen wird aktuell durch die ­HR-Abteilung (siehe Abschn.  14.5.2) begleitet, welche die Aufgaben der Zukunftswerkstatt Ende 2018 übernahm.

14.4.3 Ein Open Banking Framework als technologische Basis Wie die meisten etablierten Finanzinstitute kämpft auch die Hanseatic Bank in vielen Bereichen mit lange gewachsenen IT-Alt-Systemen. Der stete Zwiespalt zwischen Regulatorik, Sicherheit und Stabilität auf der einen Seite sowie Innovationskraft und Flexibilität auf der anderen Seite erfordert jedoch ein deutliches Umdenken. Um an der Kunden- bzw. Partnerschnittstelle zukünftig schneller, zielgerichteter und effizienter Produkte und Services der Hanseatic Bank platzieren zu können, sind bislang genutzte Schnittstellen nicht mehr ausreichend. Ein Schnittstellen-Framework ist notwendig, das modernen Architektur-Anforderungen gerecht wird und eine maximale Flexibilität im Hinblick auf die künftige IT-Gesamtarchitektur der Bank bietet. Realtime statt Batch-Prozesse ist eine Prämisse. Der Weg in die Cloud stellt ein weiteres Szenario dar. Eine kontrollierte Öffnung der Kundenschnittstelle Dritten gegenüber wird bereits durch die zweite Zahlungsdiensterichtlinie PSD2 vom Gesetzgeber gefordert. Nur mit einer modernen IT können die Fachbereiche wirklich agil ihre Produkte und Services umsetzen. Nach der Teilnahme an einem gruppeninternen Open Banking Workshop im Januar 2017 fand sich eine Taskforce zusammen, die im Herbst 2017 das Modell eines passenden Frameworks zunächst bankintern sowie Anfang 2018 auf einem Event gruppenweit vorstellte. Das Konzept umfasst ein mehrschichtiges API-LayerFramework, basierend auf einer im Konzern bereits eingesetzten Open-Source-Lösung. Für das Management externer Zugriffe (z. B. Third-Party-Provider, FinTechs, externe Portale von Vertriebspartnern) wird ein sogenannter App-Store integriert. Über diesen erfolgt u. a. die Steuerung im Rahmen der PSD2, für welche die Hanseatic Bank eine standardisierte Schnittstelle bereitstellt. Alle benötigten Services werden in visualisierten Containern bereitgestellt und über individuelle APIs verfügbar gemacht. Das Open Banking Framework ist seit Ende des zweiten Quartals 2019 produktiv. Zahlreiche APIs sind in der Umsetzung und für das Jahr 2020 ist eine bestmögliche

2World-Cafés

und Fishbowls sind interaktive Formate für Diskussionen in Gruppen (Grolman o. J.).

236

M. Blaß

Anbindung der zentralen Bankservices geplant. Dadurch werden vor allem die eigenen Plattformen der Hanseatic Bank mit Kunden- oder Partnerkontakt schneller in der Lage sein, neue digitale Produkte und Lösungen auf den Markt zu bringen.

14.4.4 Mehr Eigenverantwortung – Die LernBank entsteht Eine gängige These in der modernen Arbeitswelt lautet: Die meisten Mitarbeiter wünschen sich mehr Eigenverantwortung oder überhaupt Verantwortung in ihrer täglichen Arbeit (Bierhoff 2012). Der Frage, ob dem auch bei der Hanseatic Bank so ist, sollte eine Gruppe Mitarbeiter in einem weiteren Arbeitspaket aus dem ­Disrupt-us-Workshop nachgehen. Dabei wurden diverse Aspekte der täglichen Arbeit diskutiert. Abhängigkeiten erkannte man je nach Aufgabenbereich oder Unternehmenseinheit, nach Senioritätslevel der Mitarbeiter oder nach Intensität der gelebten Hierarchie durch die Führungskräfte. Zwei wesentliche Themen wurden identifiziert, die man gemeinsam mit der Personalabteilung diskutierte. Zum einen die Frage, inwieweit Führungskräfte in der Hanseatic Bank ein eigenverantwortliches Arbeiten überhaupt zulassen. Muss sich Führung im Rahmen einer Transformation also auch ändern? Zum anderen, ob die Mitarbeiter überhaupt schon so weit sind, selbst zu entscheiden, wie sie ihre Aufgaben umsetzen wollen. Und falls nicht, wie geht die Bank als Arbeitgeber mit den sich verändernden Rahmenbedingungen um? Wie werden Weiterbildungsmaßnahmen entwickelt, um Mitarbeiter zu mehr Eigenverantwortung zu bewegen und ihnen damit mehr Spaß an ihrer Arbeit zu ermöglichen und ihren Job für die Zukunft abzusichern. Das Führungsthema nahm sich die Personalabteilung separat vor (Abschn. 14.5.2). Die Frage nach der Entwicklung der Mitarbeiter hin zu mehr Eigenverantwortung für sich selbst und ihre tägliche Arbeit, wurde von Mitarbeitern aus der Trainingsabteilung und der ursprünglichen Arbeitsgruppe weiterverfolgt. Es entstand eine Idee, die im dritten Solution Lab im September 2017 entwickelt und die letztendlich im Juli 2018 allen Mitarbeitern vorgestellt wurde: die LernBank (Abb. 14.4). Die LernBank ist ein Konzept zur selbstbestimmten und eigenverantwortlichen Weiterbildung der Mitarbeiter. Hierfür erhält jeder Mitarbeiter ein Guthaben von 50 Credits pro Kalenderjahr. Diese Credits können entweder in Form von 50 Zeitstunden (1 Credit = 1 Arbeitsstunde) oder im Gegenwert von 500 € (1 Credit = 10 €) für seine persönliche Weiterbildung einsetzt werden. Dabei ist es den Mitarbeitern freigestellt, wie sie die Credits verwenden. So kann man die 50 Zeitstunden auf das Jahr verteilt nutzen, um jede Woche eine Stunde während seiner Arbeitszeit ein Fachbuch zu lesen. Oder man bucht online ein Training, setzt dafür 300 € seines LernBank-Budgets ein, und nutzt die verbleibenden 20 Credits, um sich freie Zeit für das Online-Training zu „kaufen“. Es gibt nur wenige Einschränkungen für den Einsatz der Credits. Solange es einen beruflichen Bezug gibt und man die zeitlichen Einsätze mit den Kollegen und seiner Führungskraft abstimmt, besteht maximale Flexibilität. Beim Kauf von Büchern erwirbt der Mitarbeiter lediglich ein Nutzungsrecht. Die Bücher verbleiben im Besitz

14  Die agile Transformation der Hanseatic Bank

237

Abb. 14.4   LernBank-Flyer. (Quelle: Eigene Abbildung)

des Arbeitgebers, können aber solange wie nötig vom Mitarbeiter genutzt werden. Wer nicht alle Credits im Jahr verbraucht, kann diese auch seinen Kollegen „spenden“. Umgekehrt kann man zusätzliche Credits erwerben, indem man eigene Bücher in den ­LernBank-Pool einbringt oder zum Beispiel selbst Microtrainings zu einem erlernten Thema anbietet. Gerade diese Möglichkeit unterstützt, wie grundsätzlich das gesamte LernBank-Konzept, die eigenverantwortliche Weiterentwicklung der Mitarbeiter, um ­ diese für die moderne Arbeitswelt zu befähigen. Was den Mitarbeitern der Hanseatic Bank besonders an der LernBank gefällt, ist die Tatsache, dass das Konzept von Mitarbeitern für Mitarbeiter entwickelt wurde. Im Dezember 2018 erhielt die Hanseatic Bank für die LernBank den HR Excellence Award 2018 in der Kategorie „Corporate Learning & Development“, der von dem Fachmagazin Human Resources Manager sowie der Quadriga Media Berlin GmbH vergeben wird. Seit März 2019 gehört die Hanseatic Bank zu den besten Arbeitgebern Deutschlands und erreichte beim branchenübergreifenden Wettbewerb der ­Great-Place-to-Work-Initiative den 15. Platz in der Kategorie der Unternehmen mit 50 bis 500 Mitarbeitern. Sie ist damit in dieser Größenordnung die bestplatzierte Bank (GPTW Deutschland GmbH 2019).

14.4.5 Techniken & Tools für bessere Zusammenarbeit Was nützt die größte Motivation der Mitarbeiter, wenn die tägliche Zusammenarbeit unter anderem an den passenden Instrumenten scheitert. Dieser Umstand wurde auf dem initialen Workshop intensiv diskutiert. Man könne nicht über Agilität und moderne Arbeitsweisen philosophieren, wenn es zum Beispiel schon an einfachen Tools zum

238

M. Blaß

internen oder externen Austausch von Informationen oder Dateien scheitert. Gerade über verteilte Standorte hinweg sind Kollaborationswerkzeuge unverzichtbar. Mobiles Arbeiten, egal ob im Büro oder im Homeoffice, setzt mobile Arbeitsplätze und die entsprechende technische Ausstattung voraus. Meeting- und Konferenzräume müssen in ausreichendem Umfang zur Verfügung stehen, wenn man möchte, dass sich Teams über Bereichsgrenzen hinweg zusammensetzen und austauschen. Selbstredend, dass diese Räumlichkeiten auch mit der entsprechenden Konferenztechnik ausgestattet sein müssen. u

„A fool with a tool is still a fool.“ (Ron Weinstein zitiert nach Thurlbeck (1989)

Werkzeuge alleine sind keine Lösung, wenn die Menschen den richtigen Umgang mit ihnen nicht beherrschen. Was nützt es, sich über ein Chat-Tool zu einem Meeting zu verabreden, wenn das Meeting selbst schlecht geplant und noch schlechter moderiert wird? Es ist auch nicht damit getan, in jedes Büro moderne Boards zu hängen und diese mit bunten Post-its zu bekleben, wenn man die Prinzipien hinter agilen Frameworks wie Scrum oder Kanban nicht verstanden hat. Damit es nicht beim üblichen Buzzword Bingo bleibt, wurde dieses Thema in der Hanseatic Bank auf zwei Wegen angegangen. Zwei Teilnehmer aus dem Disrupt-us-Workshop, denen das technische Thema sehr am Herzen lag, begannen damit, im kompletten Unternehmen Mitarbeiter nach ihren bevorzugten Tools zu befragen. Es konnten Tools genannt werden, mit denen man gute Erfahrungen bei früheren Arbeitgebern gemacht hatte oder solche, die man aus Gesprächen mit Freunden und Bekannten kannte. Aus einer sehr breiten Sammlung kristallisierten sich schnell wichtige Tools wie Confluence oder Jira der Firma Atlassian heraus, mit denen man schnell und unkompliziert Pilotgruppen ausstattete. Die Atlassian-Tools sind heute bei der Hanseatic Bank Standard. Wohingegen andere Lösungen noch auf die Etablierung warten. So ist die Bank mitten in der Einführung einer unternehmensweiten Cloud-Strategie zur Erleichterung vieler Infrastrukturfragen. Dies erfolgt in enger Abstimmung mit den Mutterkonzernen, um von den Erfahrungen von Otto oder der Société Générale zu profitieren. Mitarbeiter, deren Aufgabenbereich ein mobiles Arbeiten ermöglicht, können heute auf moderne Notebooks oder Convertibles zurückgreifen. Per WLAN und entsprechenden VPN-Lösungen kann flexibel an jedem Arbeitsplatz im Unternehmen, von zu Hause oder aus einem Coworking Office gearbeitet und auf die Unternehmensdaten zugegriffen werden. Die Konferenzräume sind mit modernen Beamern oder Monitoren ausgestattet, sodass standortverteilte Meetings oder Produktreviews vor großen Gruppen heute kein Problem mehr darstellen. Parallel zur Toolauswahl wurden ab Mitte 2017 unternehmensweite Trainings angeboten, um den Mitarbeitern Themen wie agile Organisation, partizipative Entscheidungsfindung und agile Meetings inkl. Frameworks und Methoden wie Scrum, Kanban oder Design Thinking näher zu bringen.

14  Die agile Transformation der Hanseatic Bank

239

14.5 Ein Change über alle Bereiche Innerhalb der Hanseatic Bank hat der „Grassroot-Effekt“ bereits gewirkt. Nahezu alle Bereiche des Unternehmens verändern ihre Zusammenarbeit oder auch die Organisation. Als Grundsatz gilt: Keine Veränderung, nur um der Veränderung willen. Eine Veränderung muss Probleme lösen. Eine große Herausforderung dabei ist, die Freiheit jedes Bereiches zu einem individuell angepassten Change zu akzeptieren, aber auch zu gewährleisten, dass durch den dezentralen Change keine neuen Silos entstehen. Ebenso muss sichergestellt sein, dass alle Bereiche der Gesamtstrategie des Unternehmens folgen. Zum Zeitpunkt der Entstehung dieses Buchbeitrags ist der Wandel in der Hanseatic Bank in den nachfolgend beschriebenen Bereichen in vollem Gange. Ob die Veränderungen auf lange Sicht erfolgreich sein werden, wird zu beweisen sein.

14.5.1 Acceleration Hub Wie im Abschn. 14.4.2 zu lesen war, sollte das neue Organisationsmodell als komplett neuer Bereich gegründet werden. Zum einen, um alle offenen Fragen in einem echten Piloten zu erproben. Quasi als Minimum Viable Product (MVP) eines Organisationsmodells, dem Lean-Startup-Grundprinzip des „Build – Measure – Learn“ (Ries 2011) folgend. Zum anderen, um alle Konsequenzen zu betrachten, die eine Produktentwicklung als Minimum Viable Product nach sich zieht. Also auch der Überprüfung und Fragestellung: Funktioniert das Modell nachhaltig? Wo muss nachjustiert werden? Bei der Entwicklung des Modells orientierte sich die Zukunftswerkstatt zunächst an bereits erfolgreich eingeführten agilen Organisationsstrukturen wie z. B. bei Spotify oder der niederländischen ING Bankengruppe. Diese wurden mit anderen Modellideen wie einer Ausrichtung entlang der Customer Journey verglichen. Letzten Endes basiert der Acceleration Hub auf einem angepassten Spotify-Modell (Kniberg 2014). Wie in Abb. 14.5 zu sehen ist, bedient sich die Hanseatic Bank einer FlughafenMetapher, die den neuen Bereich neben der bisherigen Organisation des „Flughafens“ verortet. Der Acceleration Hub sieht agile, crossfunktionale, eigenverantwortliche Teams (sogenannte Flight-Crews) vor, die an Kundenbedürfnissen (Solution Lines) und nicht an Produkten ausgerichtet sind. Die Flight-Crews haben den Auftrag, bestehende Kundenbedürfnisse zu identifizieren sowie neue Kundenbedürfnisse zu wecken und dafür entsprechende Lösungen effizient und mit hoher Qualität zu entwickeln. Hierbei stehen ihnen maximale Freiheiten im Rahmen der strategischen und regulatorischen Leitplanken sowie eigene Budgets zur Verfügung. Gestartet wurde mit vier wesentlichen Bedürfnissen der Bankkunden: Payment (Kunde braucht Zahlungsmittel), Protection (Kunde braucht Schutz), Financing (Kunde braucht Geld) und Digital Service (Kunde braucht digitale Services). Der neue Organisationsbereich wird im Sinne eines „Servant Leaders“ von einem Business Owner

240

M. Blaß

Abb. 14.5   Schematische Darstellung des Acceleration Hub. (Quelle: Eigene Darstellung)

(Tower) geführt.3 Die Crews werden durch agile Coaches begleitet. Wie an einem Flughafen interagieren die Flight-Crews mit dem Bodenpersonal, also den anderen Bereichen innerhalb des Unternehmens, wie etwa HR, IT, Finanzwesen oder Risikocontrolling. Für die erste Flight-Crew erfolgte eine rein interne Ausschreibung. Man entschloss sich bewusst, keine festen Stellen wie „Marketing Manager“ oder „Software Entwickler“ auszuschreiben, sondern Rollen. Wer welche Aufgabe/Rolle in einer Flight-Crew übernimmt, sollten die Crew-Mitglieder gemeinsam entscheiden. Der Bewerbungsprozess basierte auf Freiwilligkeit. Jeder Mitarbeiter im Unternehmen, der Interesse an neuen Arbeitsweisen, neuen Methoden oder den neuen Aufgaben hatte, konnte sich bewerben. Die Auswahl der Bewerber für die Crew wurde durch ein Team aus Zukunftswerkstatt, Personalbereich und erweitertem Kernteam im Consent-Verfahren durchgeführt. Dabei wurde vor allem auf Softskills und das passende „Mindset“ und weniger auf Fachexpertise Wert gelegt. Nach dem Start der ersten Flight-Crew im Februar 2018 nahmen im Oktober 2018 drei weitere Crews ihre Tätigkeit auf. Die ersten Wochen nach dem Start wurden zur Findungsphase gewährt. Es war der Geschäftsführung bewusst, dass ein enormer Druck auf allen Beteiligten lag. Fehlende Erfahrung in agilen Arbeitsmethoden, komplett neue Teamzusammenstellungen und der Anspruch, die Kunden mit einer passgenauen Lösung zu begeistern, waren große Herausforderungen. Heute nach knapp zwei Jahren ist man um einiges an Erfahrung reicher. Es kann beispielsweise nie zu viel Begleitung durch Agile Coaches geben. Im Gegenteil: agile Arbeitsweisen und eine End-to-End-Verantwortung für die entwickelten Lösungen machen schnell deutlich, ­ dass sich die Gesamtorganisation verändern muss, wenn man gemeinsam herausragende

3Servant

Leadership beschreibt das Wirken von Führenden als Dienst am Geführten, mithin als dienendes Führen im Gegensatz zum beherrschenden Führen (Greenleaf 1991).

14  Die agile Transformation der Hanseatic Bank

241

Kundenlösungen entwickeln will. Ein „schneller“, agiler Bereich kann nur so schnell vorankommen, wie es die Abhängigkeiten zu anderen Bereichen zulassen. Und es geht um Menschen. Menschen die Lust auf Veränderungen haben, aber auch um solche, die lernen, dass eigenverantwortliches Arbeiten und damit die Übernahme von Verantwortung für eine Kundenlösung vielleicht am Ende des Tages doch nicht das Richtige für sie ist. Trotz all der Anfangsprobleme und Schmerzen, die einzelne Flight-Crews hatten und auch noch haben werden, ist die intrinsische Motivation der Mitarbeiter im Acceleration Hub sehr hoch und die Erfolge sind sichtbar. Hat die Einführung der ersten rudimentären Mobile Banking-App auf der Basis eines eingekauften Frameworks und als „Nebenbei-Projekt“ noch recht lange gedauert, konnte die erste Flight-Crew eine komplett neu entwickelte App nach nur rund vier Monaten erfolgreich zum Abheben bringen.

14.5.2 People & Organisation Seit der Einführung einer neuen Marken- und Kommunikationsstrategie Ende 2017 stellt die Hanseatic Bank den Kunden und dessen Bedürfnisse noch stärker in den Mittelpunkt des Handelns. Dazu zählen auch interne Kunden. Eine wichtige Veränderung im Rahmen dieses Changes war daher die folgerichtige Umbenennung des Personalbereichs von „Human Ressources“ in „People & Organisation“. Schließlich soll es nicht länger um Humanressourcen, sondern um Menschen und deren Bedürfnisse in einer neuen Organisation gehen. People & Organisation ist seit August 2018 die neue Personalabteilung, die sich parallel zum Veränderungsprozess entwickelt hat. Um den Anforderungen einer agilen Organisation und der internen Kunden gerecht zu werden, haben sich die Mitarbeiter des ehemaligen Personalwesens ebenfalls zu einer Organisation in eigenverantwortlichen Teams entschieden und wenden agile Methoden bei der eigenen Arbeit an. Getreu dem Motto „Eat your own dog food“. Ende 2018 wurde die Zukunftswerkstatt als Transformationsteam aufgelöst und das Team Culture & Development übernahm das Change-Management. Es unterstützt seitdem explizit alle Bereiche bei der Transformation durch Agile Coaches, Organisationsentwicklung, Teamentwicklung und Training. Neben den Bereichen und Teams unterstützt People & Organisation auch Mitarbeiter direkt. Durch die Transformation verändert sich auch die Art der Führung. Der Weg geht von stark hierarchischer Führung hin zu lateraler Führung, manche Führungsebenen fallen komplett weg. Es gibt Mitarbeiter, wie der Autor selbst, die sich aktiv aus der Führungsrolle in einen anderen Aufgabenbereich verändert haben. Um proaktiv dieser sich verändernden Führungskultur zu begegnen, haben sich Führungskräfte der Bank gemeinsam mit People & Organisation dem Thema „Führung 4.0“ gewidmet und wenden auch hierbei angepasste agile Prinzipien (Abb. 14.6) an.

242

M. Blaß

Kollaboraves Arbeiten

über

Hierarchie

Transparenz

über

Geheimhaltung

Anpassungsfähigkeit

über

Vorschrien

Inspiraon und Engagement

über

Verwalten und Zurückhaltung

Innere Movaon

über

äußere Movaon

Eigener Ansporn

über

Pflichtgefühl

Abb. 14.6   HR-Prinzipien basierend auf dem Agilen Manifest. (Quelle: Eigene Darstellung)

14.5.3 Personal Loan & Deposit Business Der Bereich Personal Loan & Deposit Business kümmert sich um den Verkauf von Finanzdienstleistungsprodukten (Krediten) und Einlagen. Dieser erfolgt über Vertriebspartner oder im Direktvertrieb. Im Zuge der Transformation wurden auch in diesem Bereich Analysen durchgeführt und es wurde erkannt, dass es zur Absicherung eines nachhaltigen Vertriebserfolges einerseits organisatorische und prozessuale Optimierungen, andererseits aber auch Produktoptimierungen in einem sehr kompetitiven Marktumfeld bedarf. Ziel ist die komplette Optimierung entlang des Customer Lifecycles. Die große Herausforderung ist auch hier das Schnittstellenmanagement. Sowohl technisch zu den großen Vertriebsplattformen als auch menschlich zu den Vertriebspartnern, da diese die „API“ zum Kunden sind. Eine Optimierung des Customer Lifecycles ist hauptsächlich eine Optimierung des Customer-Relationship-Managements und die Prozessoptimierung für die Partner. Organisatorisch hat man sich dem Ganzen Anfang 2019 zunächst im Vertrieb der Finanzdienstleistungen genähert. Dort wurden zwei Teams mit unterschiedlichen Schwerpunkten geschaffen. Im Vertriebsaußendienst und dem Partnermanagement geht man dem Thema „Next Generation Sales“ nach, um der Herausforderung des Generationswechsels sowohl intern als auch bei den Vertriebspartnern gerecht zu werden. Ein weiteres, agil arbeitendes Team konzentriert sich selbst organisiert und eigenverantwortlich auf die Schaffung eines „digitalen Ökosystems“ für den B2B-Vertrieb. Werden im Acceleration Hub (Abschn. 14.5.1) digitale Lösungen für Kundenbedürfnisse entwickelt, so stehen im B2B-Vertrieb digitale Lösungen für Partner im Vordergrund.

14.5.4 Payment & Financing Business Durch eine strategische Neuausrichtung des Bereichs Marketing und Kooperationen entstand im zweiten Quartal 2019 der neue Bereich Payment & Financing Business.

14  Die agile Transformation der Hanseatic Bank

243

Wurden drei Jahre zuvor schon die ersten Weichen in Richtung Customer Journey gestellt, so bietet die Neuausrichtung einen noch besseren Fokus auf das Zahlungsund Finanzierungsinstrument Kreditkarte über alle Direktvertriebskanäle. Anlass für die organisatorische Weiterentwicklung des Bereichs war unter anderem die Erfüllung quantitativer Ziele im Kreditkartenvertrieb, qualitativer Ziele bezüglich der Kundenzufriedenheit sowie übergreifender Ziele rund um die neue Marken- und Kommunikationsstrategie der Hanseatic Bank. Payment & Financing Business ist eine klassische „Flughafen“-Einheit der Hanseatic Bank (Abschn. 14.5.1), deren vorrangiges Ziel es ist, Stabilität zu wahren (Beispiel Kundenzufriedenheit) und Leistungen effizient zu erbringen (Beispiel Neugewinnung von Kreditkartenkunden). Die Herausforderungen einer „Operation am offenen Herzen“ in einem solchen auf Effizienz getrimmten Bereich, sind vielfältig. Es gilt, die Jahresziele zu erfüllen. Das bedeutet, es bleibt keine Zeit für eine lange Transformation (siehe auch Abschn. 14.5.5). Demgegenüber stehen persönliche Historien der betroffenen Mitarbeiter und deren individuellen Karriere- und Entwicklungsziele. Werden neue Strukturen geschaffen, bedeutet das in der Regel für die Mitarbeiter, dass Abteilungen und Teams neu organisiert und Führungskräfte anders zugeordnet werden oder im Falle von selbst organisierten Teams die fachlichen Führungskräfte sogar komplett entfallen. Um diesen Change so angenehm wie möglich zu gestalten, wurden auch in diesem Bereich mit Unterstützung von Agile Coaches und Trainern bereits Anfang 2019 diverse Workshops durchgeführt, um möglichst viele individuelle Bedürfnisse zu berücksichtigen. Das große Ziel war es, dort Crossfunktionalität und/oder Selbstorganisation umzusetzen, wo es Sinn macht.

14.5.5 IT In der heutigen Geschäftswelt ist eine leistungsfähige Informationstechnologie wichtiger denn je. Nahezu jeder Geschäftsprozess hängt an Technologie und erfordert einerseits Stabilität, andererseits flexible Reaktionsfähigkeit auf modernste Anforderungen in Echtzeit. Die Kollegen des größten Bereichs der Hanseatic Bank haben dafür zunächst im Jahr 2018 den wesentlichen Teil des Open Banking Frameworks (Abschn. 14.4.3) konzipiert und auf den Weg gebracht. Mit Technologie alleine ist es aber nicht getan, denn die IT ist ein klassischer Servicebereich für zahlreiche interne Kunden. Um den Kundenbedürfnissen gerecht zu werden, musste ähnlich wie beim Acceleration Hub (Abschn. 14.5.1) ein massiver organisatorischer Change vollzogen werden. Wo mit dem Hub ein neuer Bereich geschaffen wurde, der nahezu komplett neu durchstarten konnte, war dies bei der IT nicht möglich. Schließlich muss der Bankbetrieb weiterhin gewährleistet werden. Diese Tatsache stellte das bereichseigene Transformationsteam vor besondere Herausforderungen. Der Transformationsprozess hin zu einer zukunftsorientierten IT in der Hanseatic Bank hat daher am längsten gedauert.

244

M. Blaß

So begann man bereits im September 2018 mit ersten internen Workshops, um Probleme und mögliche Lösungen zu eruieren. Neben den technologischen Herausforderungen an den laufenden Betrieb und einer gleichzeitigen Vorbereitung für die Modernisierung wie zum Beispiel dem Aufsetzen einer Cloud-Strategie, hat man einen besonderen Fokus auf die Mitarbeiter gelegt. So wurde versucht auch hier auf individuelle Wünsche und Entwicklungsmöglichkeiten Rücksicht zu nehmen, um die Zuordnung der Mitarbeiter in die neue Struktur bestmöglich auf freiwilliger Basis zu gewährleisten. Im Mai wurde der weitere Fahrplan festgelegt und nach Einzelgesprächen mit allen IT-Mitarbeitern zu ihrer Zuordnung in der neuen Organisation und einer umfangreichen internen Kommunikation wurde die neue IT-Struktur nach einem Jahr Entwicklungszeit im August 2019 in Kraft gesetzt. Bei der Umsetzung wurde bewusst auf die Kombination eines Big Bangs mit einem gestuften Verfahren gesetzt, um möglichst viele Vorteile beider Varianten zu nutzen – frühzeitige Klarheit für alle Beteiligten, Reduzierung von Zwischenlösungen und die Sicherstellung eines stabilen Produktionsbetriebs. Im Kern der neuen IT-Organisation stehen ähnliche agile Grundprinzipien wie im Acceleration Hub. Ein konsequentes Ausrichten des Handelns an den Kundenbedürfnissen, das Anbieten passender Services und Lösungen, unternehmerisches und eigenverantwortliches Handeln im Rahmen der Unternehmensziele und -werte. Dafür wurden Service-Crews für die unterschiedlichen Business-Services zusammengestellt, die sich an der Wertschöpfungskette der Bank orientieren. Jede Crew hat – ähnlich dem Product Owner in einem Scrum Team – einen Service Owner, ist typischerweise (IT-)crossfunktional aufgestellt und besitzt eine sehr hohe Fachbereichsnähe. Darüber hinaus gibt es unterstützende bzw. beratende Querschnittscrews. Da die Crews in der IT ebenfalls keine klassische fachliche Führung mehr haben, wird der gesamte Bereich disziplinarisch im Sinne einer „Servant Leadership“ durch eine Support-Crew (den Tower) geführt. Der Tower ist darüber hinaus für die strategischen Leitplanken der IT verantwortlich. Im IT-Bereich war die Transformation aufgrund der Größe sicherlich die massivste. Jedoch wurde hier durch die frühe Einbeziehung der Belegschaft ein sehr hohes Commitment erreicht und einige der ehemaligen Führungskräfte haben die Chance wahrgenommen, sich in den Service-Crews weiterzuentwickeln.

14.6 Zwischenfazit Der stark von innen heraus getriebene Change-Prozess wirft in der Organisation eine Vielzahl von Fragen auf, die nicht immer sofort beantwortet werden können. Die Führungsdichte reduziert sich, Führungsrollen und der grundsätzliche Umgang mit Führung verändern sich. Ein agiles Mindset und die dazu passende Unternehmenskultur müssen sich entwickeln. Die Vergütungs- und Zielvereinbarungsmodelle passen in vielen Bereichen nicht mehr zur Organisation. Wesentliche Herausforderungen bilden auch die

14  Die agile Transformation der Hanseatic Bank

245

Schnittstellen zwischen den neuen agilen Teams und den eher traditionell organisierten Bereichen. Ganz zu schweigen vom Umgang mit Projekten und deren Priorisierungen. Hier treffen häufig noch alte und neue Welt mit Unverständnis aufeinander. Im Jahr 2018 hat die Hanseatic Bank zwei Mitarbeiterbefragungen durchgeführt. Die Ergebnisse waren sehr gut und sogar noch besser als in den Vorjahren. Die Ergebnisse der Befragungen im Jahr 2019 werden gespannt erwartet, standen zum Zeitpunkt des Drucks dieses Buches aber noch nicht endgültig fest. Die Transformation ist eine Herausforderung für alle Beteiligten, scheint aber grundsätzlich viel Positives freizusetzen. Ein solcher Transformationsprozess kostet natürlich auch Zeit und Geld. Die Hanseatic Bank hat sich dieses Experiment zu einem Zeitpunkt geleistet, zu dem sie bereits sehr erfolgreich war. Viele Prozesse haben sich seitdem verbessert und es konnten bereits einige Produkte und Services schneller an den Markt gebracht werden. Neue Herausforderungen werden früher identifiziert und konsequent angegangen. Viele Mitarbeiter nutzen bereits die Chance, mehr Verantwortung zu übernehmen und mit dem richtigen Mindset mutig an neue Aufgaben heranzugehen. Welche Art der Transformation am Ende des Tages die „richtige“ oder „bessere“ ist, also eine komplette Neuausrichtung auf interne oder externe Kundenbedürfnisse, die Optimierung von Prozessen entlang des Customer Lifecycles oder der Customer Journey, wird die Zukunft zeigen. Vielleicht kommt es auf diese Frage aber auch gar nicht an. Das Unternehmens-Credo „Einfach machen“ scheint der Hanseatic Bank bislang Recht zu geben.

Literatur Bierhoff, H.-W. 2012. Wie entsteht soziales Engagement und wie wird es aufrechterhalten? In Freiwilligenarbeit. Einführung in das Management von Ehrenamtlichen in der Sozialen Arbeit, 2. Aufl., Hrsg. D. Rosenkranz und A. Weber, 36–45. Weinheim: Beltz Juventa. GPTW Deutschland GmbH Hrsg. 2019. Deutschlands Beste Arbeitgeber 2019. www. greatplacetowork.de/beste-arbeitgeber/deutschlands-beste-arbeitgeber/deutschlands-bestearbeitgeber-2019. Greenleaf, R.K. 1991. The Greenleaf Center for Servant Leadership. Indianapolis: Robert K. Greenleaf Center. Grolman, F. o. J. 11 Methoden für Interaktive Konferenzen, Seminare und Workshops. https:// organisationsberatung.net/methoden-fuer-interaktive-konferenzen-seminare-workshops. Kniberg, H. 2014. Spotify engineering culture (part 1). https://labs.spotify.com/2014/03/27/ spotify-engineering-culture-part-1. Ries, E. 2011. The Lean Startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses. New York: Crown Business. Sprache am Markt GmbH Hrsg. o.  J. Was ist Corporate Grassroots überhaupt? www. corporategrassroots.com/background. Thurlbeck, W.M. 1989. Perestroika, fashion, and the universal glue. The American Review of Respiratory Disease 139 (5): 1280–1281. Tuckman, B.W. 1965. Developmental sequence in small groups. Psychological Bulletin 63 (6): 384–399. Welch, J. 2001. GE annual report 2020, Boston.

246

M. Blaß

Der Autor Matthias Blaß  ist seit mehr als 20 Jahren digital unterwegs, davon über 15 Jahre in der Finanzindustrie. Er kennt die Dienstleisterseite ebenso wie die Unternehmensseite. Zuletzt an der Schnittstelle zwischen Marketing, Vertrieb und IT u. a. für ­E-Business-Plattformen und Bank Produkte mitverantwortlich, entwickelt er aktuell als Product Owner eine neue mobile Plattform mit OnlineBanking-Funktionalitäten für die Kunden der Hanseatic Bank. Dieser Beitrag entstand durch seine Mitarbeit im erweiterten Transformationsteam der Bank, was u. a. in seinem Wechsel in den neu geschaffenen agilen Unternehmensbereich Acceleration Hub resultierte. Kontakt: [email protected]