Digitales Produktmanagement: Methoden - Instrumente - Praxisbeispiele [2., überarbeitete und erweiterte Auflage] 3658418796, 9783658418793, 9783658418809

Table of contents :
Vorwort zur 2. Auflage
Inhaltsverzeichnis
Herausgeber- und Autorenverzeichnis
1 Einführung in das digitale Produktmanagement
Zusammenfassung
1.1 Produktmanagement vs. Projektmanagement
1.2 Grundlagen des agilen Produktmanagements
1.3 Digitale Produktentwicklung nach Scrum
1.4 Digitale Produktentwicklung mit Kanban
1.5 Weitere agile Methoden im digitalen Produktmanagement
Literatur
2 Nutzerzentrierte Produktvisionen
Zusammenfassung
2.1 Was ist eine Produktvision?
2.2 Warum man eine Produktvision braucht
2.3 Woran man eine gute Produktvision erkennt
2.4 Tools zur Erstellung einer guten Produktvision
2.4.1 Das Vision Statement
2.4.2 Das Product Vision Board
2.4.3 Das Product Vision Template
2.4.4 Der Visiontype
2.5 Der Visions-Workshop
2.5.1 Die richtige Vorbereitung
2.5.2 Der Workshop
2.5.3 Nach dem Workshop
2.6 Woran man erkennt, dass die Produktvision funktioniert
2.7 Ein kurzer Ausblick zum Schluss
Literatur
3 Produktstrategie – Das Fundament des Produktmanagements
Zusammenfassung
3.1 Einleitung
3.2 Was ist Produktstrategie?
3.3 Die Bedeutung der Produktstrategie
3.4 Die Elemente der Produktstrategie
3.4.1 Das Produktspielfeld
3.4.2 Der Startpunkt
3.4.3 Die Zukunftsfaktoren
3.4.4 Das Ziel
3.4.5 Der Weg
3.5 Der Entstehungsprozess der Produktstrategie
3.6 Die Operationalisierung der Produktstrategie
3.6.1 Das Alignment Gap
3.6.2 Das Effects Gap
Literatur
4 Produktstrategie umsetzen und validieren mit Objectives und Key Results (OKR)
Zusammenfassung
4.1 Worum geht es bei Objectives und Key Results?
4.2 Welche Probleme löst das OKR-Framework?
4.3 Wie werden Objectives und Key Results definiert?
4.3.1 Mittelfristiges strategisches Ziel
4.3.2 Objective
4.3.3 Key Results
4.4 Der OKR-Zyklus
4.4.1 Workshop zur OKR-Definition
4.4.2 OKR-Alignment-Workshop
4.4.3 Initiativenplanung
4.4.4 OKR-Check-ins
4.4.5 Strategie-Check-ins
4.4.6 OKR-Reflexion
4.4.7 Strategie-Review
4.4.8 OKR-Systemreflexion
4.5 OKR-Einführung
4.6 OKR-Architektur
4.6.1 Dynamische Netzwerke anstatt strikter Kaskadierung
4.6.2 Arten von OKR-Teams
4.7 Rollen im OKR-Prozess
4.7.1 Führungskräfte
4.7.2 Team-Mitglieder
4.7.3 Interne OKR-Agents
4.8 Wirkprinzipien
4.8.1 Richtige Balance zwischen top-down und bottom-up finden
4.8.2 OKR nicht mit Performance-Management verknüpfen
4.8.3 OKR nicht für alle und alles einsetzten
4.9 Abschließende Gedanken
Literatur
5 Product Roadmaps
Zusammenfassung
5.1 Einordnung Product Roadmaps
5.2 Arten von Product Roadmaps
5.2.1 Der „Klassiker“: Die Feature-Based Roadmap
5.2.2 Vom Ende gedacht: Goal-Oriented und Outcome-Driven Roadmaps
5.2.3 In Boxen gepackt: Theme-Based Roadmaps
5.3 Der Nutzen von Product Roadmaps
5.4 Die Risiken von Product Roadmaps
5.4.1 Risiken für das Stakeholder-Management
5.4.2 Risiken für die Produktentwicklung
5.5 Erfolgsfaktoren für Product Roadmaps
5.5.1 Problem- statt Lösungsfokus
5.5.2 Kurze Review- und Update-Zyklen
5.5.3 Scheingenauigkeit und künstliche Deadlines vermeiden
5.5.4 Nicht weniger, sondern bessere Kommunikation
5.5.5 Von der Produktstrategie und -vision zur Roadmap
5.5.6 Datengetrieben priorisieren und mit Stakeholdern abstimmen
5.5.7 Verschiedene Darstellungen für verschiedene Zielgruppen
5.6 Product Roadmaps für Hardware- bzw. IoT-Produkte
5.6.1 Hardware- versus Softwareentwicklung
5.6.2 Anforderungen an Hardware-Roadmaps
5.6.3 Roadmaps für IoT-Produkte
5.7 Fazit
Literatur
6 Product Discovery
Zusammenfassung
6.1 Ziele von Product Discovery
6.2 Grundprinzipien einer Product Discovery
6.2.1 Outcome-Orientierung
6.2.2 Nutzerzentrierung und Problemfokussierung
6.2.3 Iteratives und experimentelles Vorgehen
6.2.4 Interdisziplinarität
6.3 Ausprägungen einer Product Discovery
6.3.1 Projektbezogene Discovery
6.3.2 Kontinuierliche Discovery
6.4 Frameworks zur Strukturierung einer Product Discovery
6.4.1 Design Sprint
6.4.2 Product Kata
6.4.3 Opportunity Solution Tree
6.5 Product Discovery Toolbox
6.6 Praktische Hinweise zur Anwendung einer Product Discovery im Unternehmen
6.6.1 Folgen einer Fokussierung auf die Product Delivery
6.6.2 Potenzielle Stolpersteine bei der Einführung von Product Discovery
6.6.2.1 Fremdbestimmung von Produktteams
6.6.2.2 Output statt Outcome
6.6.2.3 Kein regelmäßiger Austausch mit dem User
Literatur
7 Validierung von Produktideen am Markt
Zusammenfassung
7.1 Warum Validierung?
7.1.1 Worum wird es hier gehen?
7.1.2 Wie lange dauert so eine Validierung normalerweise?
7.1.3 Was für ein Team brauche ich zur Validierung?
7.2 Research – Womit fangen wir an?
7.2.1 Hypothesen – Was nehmen wir bisher an?
7.2.2 Marktanalyse und Zielgruppendefinition – Worauf beziehen sich unsere ersten Annahmen?
7.2.3 Qualitativer Research – Was sagt die Zielgruppe?
7.2.4 Quantitative Validierung – Wie viele gibt es davon?
7.2.5 MVP-Definition und Ressourcenbedarf – Was brauchen wir zum Testen?
7.2.6 Design vs. Technik – Worauf liegt der Fokus bei der MVP-Erstellung?
7.3 Prototyping – Was bauen wir jetzt?
7.3.1 Testplan & Feature-Definition – Was wollen wir wissen und was brauchen wir dafür?
7.3.2 UX und UI – Wie soll das MVP aussehen?
7.3.3 Entwicklung – Wie und mit welcher Technologie wird das MVP umgesetzt?
7.3.4 Team – Wer baut das?
7.3.5 Zeitabschätzung – Wie lange brauchen wir dafür?
7.4 Testing – Wie kommen wir an die Zahlen?
7.4.1 Launch- & Marketing-Plan – Wer testet das MVP?
7.4.2 Pivot – Alles noch mal neu?
7.4.3 KPIs & Businessplan – Verdienen wir jetzt damit Geld?
7.5 Und wie geht’s jetzt weiter?
Literatur
8 Product Delivery
Zusammenfassung
8.1 Los geht’s
8.2 Was man braucht, bevor es losgeht
8.2.1 MVP vs. MLP
8.2.2 Features dokumentieren
8.2.3 Erstmal „hübsch“ machen – Design vorbereiten
8.3 Vorher wissen, was es kosten wird
8.3.1 Klassisches Projektmanagement FTW
8.3.2 Eine Idee von Teamgröße
8.3.3 Zeit- und damit Kostenabschätzung
8.3.4 Was tun, wenn es zu teuer oder zu langsam ist?
8.4 Werkzeugkasten einrichten
8.4.1 Noch mehr Vorbereitung, ernsthaft?
8.4.2 Einen Namen wählen
8.4.3 Backlog vorbereiten
8.4.4 Sprint-Board einrichten
8.5 Marathon laufen
8.5.1 Sprintlänge wählen
8.5.2 Meetings, Meetings, Meetings … sind der Sprint
8.5.2.1 Sprintplanung
8.5.2.1.1 Schätzung
8.5.2.1.2 Nicht abgeschlossene Tickets
8.5.2.1.3 Sprintgröße und Velocity
8.5.2.2 Daily(-Standup)
8.5.2.3 Sprint-Review
8.5.2.4 Retrospektive
8.5.3 Sind wir noch im Plan …?
8.5.4 … und falls nicht, wie kommen wir wieder zurück „auf Plan“?
8.6 Kleine Helferlein im Alltag
8.6.1 Entwickler rufen nach „Refactoring!“
8.6.2 Kundensupport warnt vor „Bugs!“
8.7 Das war’s
9 Growth
Zusammenfassung
9.1 Alle wollen Wachstum
9.2 Wie lange dauert Wachstum?
9.2.1 Henry Ford und das Model T
9.2.2 Das iPhone
9.2.3 Digitale „Wachstumswunder“
9.3 Wachstumssprünge in zwei Phasen
9.4 Modelle zum Wachstum
9.4.1 Der Hockey-Stick
9.4.2 Das 3-Horizonte-Modell
9.4.2.1 Horizont 1
9.4.2.2 Horizont 2
9.4.2.3 Horizont 3
9.4.2.4 Das Zusammenspiel der Horizonte
9.5 Was müssen wir beherrschen, um Wachstum zu erreichen?
Literatur
10 Produktänderungen
Zusammenfassung
10.1 Abneigung gegen Veränderung
10.2 Warum Veränderungen abgelehnt werden
10.2.1 Nutzern ist Design (überwiegend) egal
10.2.2 Nutzer lieben Routinen
10.2.3 Nutzer mögen Vertrautes
10.2.4 Nutzer tendieren zum Status quo
10.2.5 Nutzer bevorzugen, was sie bereits besitzen
10.2.6 Nutzer befürchten Kontrollverlust
10.3 Akzeptanz für Veränderungen erzeugen
10.3.1 Veränderung nicht als Selbstzweck
10.3.2 Veränderungen nutzerzentriert begleiten
10.3.3 Veränderungen für Nutzer vorab testbar machen
10.3.4 Nutzern die Auswahl lassen
10.3.5 Inkrementelle Veränderungen bevorzugen
10.3.6 Veränderungen kommunizieren und schmackhaft machen
10.3.7 Abwarten und in Geduld üben
10.4 Fazit
Literatur
11 A/B-Testing im digitalen Produktmanagement
Zusammenfassung
11.1 Einleitung
11.2 Grundlagen der Hypothesenbildung
11.3 Die Statistik beim A/B-Testing
11.4 A/B-Tests in der Praxis
Literatur
12 Produktmanagement ganzheitlich verstanden
Zusammenfassung
12.1 Die Aufgaben des Produktmanagers
12.1.1 Ergebnisdimension 1: Zufriedenheit der Nutzer mit dem Produkt
12.1.2 Ergebnisdimension 2: Kommerzieller Erfolg des Produktes
12.2 Der Produktmanager als proaktiver Beziehungsmanager
12.3 Der Produktmanager als herausragender Kommunikator
12.4 Der Produktmanager als „Entscheidungsmacher“
12.4.1 Klar formulierte Ziele
12.4.2 Maximale Transparenz („Connecting the dots“)
12.4.3 Notwendige und sinnvolle Eskalationen
12.5 Der Produktmanager als Antworten-Lieferant
12.6 Der Produktmanager ist (klarer) Gedanken-Formulierer
Literatur
13 Product Sense
Zusammenfassung
13.1 Einleitung
13.2 Was ist Product Sense?
13.3 Die Bedeutung von Product Sense
13.4 Wie Product Sense entwickelt werden kann
13.4.1 Empathie aufbauen
13.4.2 Produkt- und Domänen-Wissen stärken
13.4.2.1 Grundlegendes Produktwissen
13.4.2.2 Spezifisches Domänenwissen
13.5 Product-Sense-Schnellstart
Literatur
14 Product Leadership
Zusammenfassung
14.1 Laterale Führung
14.1.1 Laterale Führung durch Verständigung
14.1.2 Laterale Führung durch Macht
14.1.3 Laterale Führung durch Vertrauen
14.1.4 Das Zusammenspiel von Verständigung, Macht und Vertrauen
14.2 Disziplinarische Führung
14.2.1 Klare Strukturen
14.2.2 Ein klarer Zielkorridor
14.2.3 Kompetente Produktmanager*innen
14.2.4 Starke Produktteams
14.2.5 Interdisziplinäre Führung
14.2.6 Schlussbetrachtung
Literatur
15 Alignment
Zusammenfassung
15.1 Warum ist Alignment wichtig im Kontext moderner Produktentwicklung?
15.1.1 Alignment schafft Vertrauen
15.1.2 Alignment hilft Ressourcenverschwendung zu vermeiden
15.1.3 Alignment hilft Entscheidungen herbeizuführen
15.2 Mit wem sollte man sich als Produktmanager aktiv abstimmen?
15.3 In welchen Kontexten ist Alignment besonders wichtig?
15.4 Wann sollte eine systematische Abstimmung am sinnvollsten erfolgen?
15.5 Welche Vorgehensweisen helfen bei der Abstimmung?
15.5.1 Die richtigen Gesprächspartner*innen in der richtigen Reihenfolge
15.5.2 Sinnvolle Konstellationen und Methoden für eine aktive Abstimmung
15.6 Wichtige zu klärende Fragen im Rahmen der Abstimmung
15.6.1 Ausgangslage aus Nutzer*innenperspektive
15.6.2 Zielbild aus Nutzer*innenperspektive
15.6.3 Hypothesen
15.6.4 Input – und Rollen
15.6.5 Output – und Grenzen
15.6.6 Outcome – und Grenzen
15.7 Konflikte identifizieren und zur Klärung bringen
15.8 Abstimmung in der Praxis: Auftragserklärung bei XING
15.8.1 Ursprung und Entwicklung der Auftragsklärung
15.8.2 Wesentliche Artefakte und übliche Praktiken
15.8.3 Einführung, Anwendung und Missverständnisse
15.9 Grenzen sinnvoller Abstimmung
Literatur
16 Product Evangelizing und Storytelling
Zusammenfassung
16.1 Warum Storytelling im Produktmanagement wichtig ist
16.2 Warum unsere Gehirne Geschichten lieben
16.3 Was Geschichten im beruflichen Kontext bewirken können
16.3.1 Elemente einer guten Geschichte
16.3.2 Geschichten sind das perfekte Design-Tool
16.4 Wie man gute Geschichten erdenkt und erzählt
16.4.1 Was hat das alles mit Produktmanagement zu tun?
16.4.2 Die Angst vor dem leeren Blatt überwinden
16.5 Wie man die Botschaft nachhaltig verankert
16.6 (M)Ein Fazit
Literatur
17 Product Owner und Scrum Master
Zusammenfassung
17.1 Mehr als ein Rollenbild aus einem Framework
17.2 Wie eine gute Zusammenarbeit gelingen kann
17.2.1 Start with Why
17.2.2 Gemeinsame Visionen
17.2.3 Vertrauen
17.2.4 Agile Prinzipien
17.2.5 Wann hören wir auf?
17.2.6 Warum machst Du das so?
17.2.7 Seid Partner
17.2.8 Gemeinsame Rituale
17.2.9 Euer PDCA-Zyklus
17.2.10 Führen über Warum und Transparenz
17.2.11 Führen über Haltung
17.2.12 Gemeinsam geteilte Führung
17.3 Was folgt?
17.4 Lernende Teams
Literatur
18 User Experience verstehen
Zusammenfassung
18.1 Die Bedeutung eines positiven Nutzererlebnisses
18.2 Der iterative UX-Designprozess
18.3 Die Kerndisziplinen im User Experience-Bereich
18.3.1 Der UX-Designer
18.3.2 Der Visual Designer
18.3.3 Der User Researcher
18.4 Die verschiedenen Arten von UX-Teams
18.4.1 Das klassische UX-Team
18.4.2 Das „UX-Team of one“
18.4.3 Das hybride „UX- & Visual-Design-Team“ mit separater User-Research-Dimension
18.5 Die beste Organisationsform
18.6 Die richtige Menge an UX
18.7 Die Zukunft von UX
Literatur
19 Data Analytics
Zusammenfassung
19.1 Einleitung
19.2 Rollen und Organisationen
19.3 Die Fallstricke
19.3.1 Die Feel-Good-Analyse
19.3.2 Die Rechtfertigungsanalyse
19.3.3 Die Symptom-Analyse
19.3.4 Einfache Fragen, komplexe Antworten
19.3.5 Selbstüberschätzung
19.3.6 Selbstverliebtheit
19.3.7 Einfach falsch
19.3.8 „Nicht signifikant“
19.3.9 Zu anspruchsvoll
19.3.10 Fehlende Distanz – Sunk costs
19.3.11 Zu wenig Daten
19.4 Fazit
20 Produktorganisationen
Zusammenfassung
20.1 Was ist eine Produktorganisation?
20.2 Fünf Eigenschaften erfolgreicher Produktorganisationen
20.3 Strukturen, Abläufe, Mitarbeitende
20.3.1 Struktur
20.3.2 Abläufe
20.3.3 Mitarbeitende
20.4 Archetypen von Produktorganisationen
20.5 Veränderungs- und Anpassungsprozesse
20.5.1 Transformation in eine Produktorganisation
20.5.2 Transformation innerhalb einer Produktorganisation
20.6 Fazit
Literatur
21 Wahl des „richtigen“ agilen Frameworks für das Unternehmen
Zusammenfassung
21.1 Einleitung
21.2 Das passende Framework für den agilen Piloten
21.2.1 Scrum vs. Kanban
21.2.2 Die Sache mit den Glaubenssätzen
21.2.3 Agiles Vorgehen im Startup vs. Konzern
21.3 Agiles Arbeiten in der ganzen Produktentwicklung
21.3.1 Abhängigkeiten minimieren
21.3.2 Abhängigkeiten managen
21.3.3 Plattformen
21.3.4 Vorsicht mit Top-Down-Standardisierung
21.3.4.1 Widerstand der Mitarbeitenden
21.3.4.2 Verlust an Agilität
21.3.5 Bleibt mir mit den Tools weg
21.4 Agiles Arbeiten im ganzen Unternehmen
21.4.1 Autonomie und Alignment
21.4.2 Anpassungsfähige Struktur
21.4.2.1 Marktkontakt durch externe Referenzen
21.4.2.2 Unternehmensanpassung mit Soziokratie 3.0
21.5 Zusammenfassung
Literatur

Citation preview

Sascha Hoffmann   Hrsg.

Digitales Produktmanagement Methoden – Instrumente – Praxisbeispiele 2. Auflage

Digitales Produktmanagement

Sascha Hoffmann (Hrsg.)

Digitales Produktmanagement Methoden – Instrumente – Praxisbeispiele 2., überarbeitete und erweiterte Auflage

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

ISBN 978-3-658-41879-3 ISBN 978-3-658-41880-9  (eBook) https://doi.org/10.1007/978-3-658-41880-9 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, 2023 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

Vorwort zur 2. Auflage

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 Meta 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 Potenzials, ü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.

V

VI

Vorwort zur 2. Auflage

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 zeitgemäß und erfolgreich eingesetzt wird. Seit dem Erscheinen der 1. Auflage dieses Buches im Jahr 2020 hat die Digitale Transformation unserer Welt noch weiter an Fahrt aufgenommen. Aktuelle Trends bzw. Hypes, wie beispielsweise das Metaverse oder die immer breitere Anwendung von Künstlicher Intelligenz, lassen eine weiterhin stark wachsende Bedeutung des digitalen Produktmanagements erwarten. Höchste Zeit also für eine 2. Auflage des Buches zum digitalen Produktmanagement. Die meisten Autorinnen und Autoren aus der 1. Auflage sind mit ihren aktualisierten Beiträgen wieder dabei. Zudem sind weitere Expertinnen und Experten mit neuen Beiträgen hinzugekommen. Dadurch ist das Buch gegenüber der 1. Auflage nicht nur vom Umfang her deutlich gewachsen, sondern bietet nun Experten wie Einsteigern einen noch umfassenderen Einblick in das digitale Produktmanagement. Im ersten Beitrag gebe ich zunächst eine grundlegende Einordnung des digitalen Produktmanagements. Dazu 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. Die weiteren Beiträge greifen jeweils ein spezielles Thema aus dem digitalen Produktmanagement auf und geben dazu einen vertiefenden Überblick. Sie reichen von den strategischen Grundlagen, über ganz operative Fragestellungen bis hin zur persönlichen Entwicklung von Produktmanagern und ihrem Zusammenwirken innerhalb von Produktorganisationen. In dem Beitrag von Inken Petersen geht es darum, wie eine nutzerzentrierte Produktvision im Team entwickelt werden kann und anschließend auch wirklich im Unternehmensalltag präsent wird. Christian Becker erläutert in seinem Beitrag, weshalb es gerade für agile Produktorganisationen wichtig ist, eine Produktstrategie zu haben, was eine gute Strategie auszeichnet und wie sich diese ermitteln lässt.

Vorwort zur 2. Auflage

VII

In ihrem Beitrag erklärt Cansel Sörgens ausführlich das populäre Objektives- & Key-Results-Framework, mit dem sich eine langfristig formulierte Produktstrategie in typischerweise quartalsweise festgelegte Ziele herunterbrechen lässt. Dabei beschreibt sie u. a., wie sinnvolle OKR-Sets definiert werden und was Organisationen bei der Einführung von OKR beachten sollten. Dominik Busching und Lutz Göcke erläutern anschließend, wie sich die Produktstrategie und -ziele in einer konkreten Product Roadmap manifestieren. Dabei gehen sie auf die Vor- und Nachteile unterschiedlicher Roadmap-Arten ein und zeigen auf, welche Faktoren eine Product Roadmap erfolgreich machen. Der Beitrag von Philip Steen und Alexander Hipp zeigt auf, wie wichtig eine intensive Product Discovery ist, um die wirklich relevanten Nutzerprobleme zu verstehen und darauf basierend erfolgversprechende Lösungsideen zu entwickeln. Bevor die identifizierten Lösungsideen direkt auf die Product Roadmap kommen, sollte ihre Tragfähigkeit jedoch noch validiert werden. Welche Aspekte dabei zu beachten sind und welche Tools sich dabei sinnvoll einsetzen lassen, beschreibt Anna Wicher in ihrem Beitrag. 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 erläutert Markus Andrezak in seinem Beitrag, wie allgegenwärtig – und gleichzeitig 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. Rainer Gibbert zeigt auf, dass die Weiterentwicklung von digitalen Produkten nicht nur schwierig sein kann, sondern zudem häufig mit Widerständen ihrer Nutzer einhergeht. Dabei beschreibt er, wie sich Vorbehalte gegenüber Produktänderungen reduzieren lassen und weshalb manchmal auch bloßes Abwarten und Aushalten eine Lösung sein kann. In einem weiteren Beitrag erläutere ich, wie sich die marktrelevante Weiterentwicklung von digitalen Produkten durch A/B-Testing sicherstellen lässt, welche Statistik sich dahinter verbirgt und was bei der praktischen Umsetzung zu beachten ist. Patrick Roelofs gibt anschließend wichtige Hinweise, wie aus einem guten ein herausragender Produktmanager werden kann, indem er den Blick von reinen Methodenund Toolkenntnissen auf eine ganzheitliche Sicht weitet. Eine besonders wichtige Fähigkeit erfolgreicher Produktmanager ist es, gerade dann gute Produktentscheidungen zu treffen, wenn die Validierung von Produktideen keine eindeutigen Ergebnisse liefert. Dafür ist ein tiefes „Gespür“ für ihr Produkt und seine Zielgruppe unablässig. Wie dieser sogenannte Product Sense entwickelt werden kann, erklären Robert Schulke und Nikkel Blaase in ihrem Beitrag. Erfahrene Produktmanager übernehmen häufig Führungsverantwortung in Produktorganisationen. Dazu erläutert Tobias Freudenreich in seinem Beitrag zu Product

VIII

Vorwort zur 2. Auflage

Leadership, wie Produktmanager die Instrumente einer lateralen Führung nutzen können, um innerhalb ihres Produktteams wirksam zu werden, und wie disziplinarische Führungskräfte im Produktmanagement ihre Produktteams befähigen können, statt sie zu befehligen. Produktmanagement bedeutet immer auch Schnittstellenmanagement mit unterschiedlichen Stakeholdern in einem Unternehmen. Dies ist oft nicht 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. Daran anschließend beschreibt Petra Wille, wie andere mit einem geschickten Storytelling von den eigenen Produktplänen überzeugen werden können. Dabei geht sie u. a. darauf ein, wieso Geschichten eine große Überzeugungskraft ausüben, was eine gute Geschichte ausmacht und wann sich welche Formen besonders gut eignen. Die Entwicklung digitaler Produkte ist Teamarbeit. Eine besonders wichtige Vertrauensperson für einen Produktmanager sollte der Scrum Master sein. Jan Köster und Florian Meyer beschreiben, wie eine gute, und vertrauensvolle Zusammenarbeit zwischen Scrum Master und Product Owner gelingen kann, von der das gesamte Produktteam profitiert. Inken Petersen erläutert im Anschluss in ihrem zweiten Buchbeitrag, wie wichtig eine gute User Experience, also ein positives Nutzungserlebnis eines digitalen Produkts, für seinen Erfolg 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. Michael Schultheiß, David Gehrke und Lutz Göcke beschreiben in ihrem Beitrag, welche Eigenschaften erfolgreiche Produktorganisationen insgesamt aufweisen, welche Organisationsformen typisch sind und was bei der Transformation einer Produktorganisation zu beachten ist. Zum Abschluss stellt Stefan Roock darauf aufbauend dar, welche agilen Frameworks in welcher Phase einer Produktorganisation besonders erfolgversprechend sind und agile Arbeitsweisen innerhalb eines Unternehmens skalieren können, und rundet damit die Betrachtung des digitalen Produktmanagements ab. Das Buch wäre ohne tatkräftige Unterstützung nicht gelungen. Mein besonderer Dank gilt zunächst natürlich meinen Co-Autorinnen und -Autoren, ohne deren großes Engagement neben ihren eigentlichen Berufen das Buch nie entstanden wäre. Darüber hinaus danke ich Stella Ruthe und Leon Sebening, die in mühevoller Kleinarbeit die Beiträge formatiert und Korrektur gelesen haben. Zudem bedanke ich mich sehr bei Imke Sander vom Springer-Gabler-Verlag für die unkomplizierte Zusammenarbeit und das sorgfältige Lektorat.

Vorwort zur 2. Auflage

IX

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 in seiner zweiten, deutlich erweiterten Auflage zu einem guten Ende zu bringen, den Rücken freigehalten hat. 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 Arbeitsund Erfahrungswelt. Ergänzende Hinweise zum Buch und spannende Neuigkeiten zum digitalen Produktmanagement finden Sie unter www.digitales-produktmanagement.de. Hamburg im Mai 2023

Sascha Hoffmann

Inhaltsverzeichnis

1

Einführung in das digitale Produktmanagement. . . . . . . . . . . . . . . . . . . . . . 1 Sascha Hoffmann 1.1 Produktmanagement vs. Projektmanagement . . . . . . . . . . . . . . . . . . . . . . 2 1.2 Grundlagen des agilen Produktmanagements . . . . . . . . . . . . . . . . . . . . . . 6 1.3 Digitale Produktentwicklung nach Scrum. . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4 Digitale Produktentwicklung mit Kanban. . . . . . . . . . . . . . . . . . . . . . . . . 25 1.5 Weitere agile Methoden im digitalen Produktmanagement. . . . . . . . . . . . 29 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2

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

XI

XII

Inhaltsverzeichnis

3

Produktstrategie – Das Fundament des Produktmanagements. . . . . . . . . . 49 Christian Becker 3.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 3.2 Was ist Produktstrategie?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 3.3 Die Bedeutung der Produktstrategie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 3.4 Die Elemente der Produktstrategie. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 3.4.1 Das Produktspielfeld . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 3.4.2 Der Startpunkt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.4.3 Die Zukunftsfaktoren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.4.4 Das Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.4.5 Der Weg. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 3.5 Der Entstehungsprozess der Produktstrategie. . . . . . . . . . . . . . . . . . . . . . 59 3.6 Die Operationalisierung der Produktstrategie. . . . . . . . . . . . . . . . . . . . . . 62 3.6.1 Das Alignment Gap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 3.6.2 Das Effects Gap. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

4

Produktstrategie umsetzen und validieren mit Objectives und Key Results (OKR). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Cansel Sörgens 4.1 Worum geht es bei Objectives und Key Results?. . . . . . . . . . . . . . . . . . . . 65 4.2 Welche Probleme löst das OKR-Framework?. . . . . . . . . . . . . . . . . . . . . . 67 4.3 Wie werden Objectives und Key Results definiert?. . . . . . . . . . . . . . . . . . 68 4.3.1 Mittelfristiges strategisches Ziel . . . . . . . . . . . . . . . . . . . . . . . . 69 4.3.2 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 4.3.3 Key Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 4.4 Der OKR-Zyklus. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.4.1 Workshop zur OKR-Definition . . . . . . . . . . . . . . . . . . . . . . . . . 75 4.4.2 OKR-Alignment-Workshop. . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 4.4.3 Initiativenplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 4.4.4 OKR-Check-ins. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.4.5 Strategie-Check-ins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.6 OKR-Reflexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 4.4.7 Strategie-Review . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 4.4.8 OKR-Systemreflexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.5 OKR-Einführung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 4.6 OKR-Architektur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 4.6.1 Dynamische Netzwerke anstatt strikter Kaskadierung . . . . . . . 87 4.6.2 Arten von OKR-Teams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 4.7 Rollen im OKR-Prozess. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 4.7.1 Führungskräfte. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Inhaltsverzeichnis

XIII

4.7.2 Team-Mitglieder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 4.7.3 Interne OKR-Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.8 Wirkprinzipien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91 4.8.1 Richtige Balance zwischen top-down und bottom-up finden. . . 91 4.8.2 OKR nicht mit Performance-Management verknüpfen. . . . . . . 92 4.8.3 OKR nicht für alle und alles einsetzten. . . . . . . . . . . . . . . . . . . 92 4.9 Abschließende Gedanken. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 5

Product Roadmaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Dominik Busching und Lutz Göcke 5.1 Einordnung Product Roadmaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 5.2 Arten von Product Roadmaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 5.2.1 Der „Klassiker“: Die Feature-Based Roadmap. . . . . . . . . . . . . 97 5.2.2 Vom Ende gedacht: Goal-Oriented und Outcome-Driven Roadmaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 5.2.3 In Boxen gepackt: Theme-Based Roadmaps. . . . . . . . . . . . . . . 99 5.3 Der Nutzen von Product Roadmaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100 5.4 Die Risiken von Product Roadmaps. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103 5.4.1 Risiken für das Stakeholder-Management. . . . . . . . . . . . . . . . . 103 5.4.2 Risiken für die Produktentwicklung. . . . . . . . . . . . . . . . . . . . . . 104 5.5 Erfolgsfaktoren für Product Roadmaps. . . . . . . . . . . . . . . . . . . . . . . . . . . 106 5.5.1 Problem- statt Lösungsfokus. . . . . . . . . . . . . . . . . . . . . . . . . . . 107 5.5.2 Kurze Review- und Update-Zyklen. . . . . . . . . . . . . . . . . . . . . . 107 5.5.3 Scheingenauigkeit und künstliche Deadlines vermeiden. . . . . . 108 5.5.4 Nicht weniger, sondern bessere Kommunikation. . . . . . . . . . . . 109 5.5.5 Von der Produktstrategie und -vision zur Roadmap. . . . . . . . . . 110 5.5.6 Datengetrieben priorisieren und mit Stakeholdern abstimmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110 5.5.7 Verschiedene Darstellungen für verschiedene Zielgruppen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 5.6 Product Roadmaps für Hardware- bzw. IoT-Produkte. . . . . . . . . . . . . . . . 111 5.6.1 Hardware- versus Softwareentwicklung . . . . . . . . . . . . . . . . . . 112 5.6.2 Anforderungen an Hardware-Roadmaps. . . . . . . . . . . . . . . . . . 113 5.6.3 Roadmaps für IoT-Produkte. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 5.7 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

6

Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 Philip Steen und Alexander Hipp 6.1 Ziele von Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.2 Grundprinzipien einer Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . 120

XIV

Inhaltsverzeichnis

6.2.1 Outcome-Orientierung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 6.2.2 Nutzerzentrierung und Problemfokussierung . . . . . . . . . . . . . . 121 6.2.3 Iteratives und experimentelles Vorgehen. . . . . . . . . . . . . . . . . . 121 6.2.4 Interdisziplinarität . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.3 Ausprägungen einer Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.3.1 Projektbezogene Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 6.3.2 Kontinuierliche Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 6.4 Frameworks zur Strukturierung einer Product Discovery. . . . . . . . . . . . . 125 6.4.1 Design Sprint. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 6.4.2 Product Kata. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127 6.4.3 Opportunity Solution Tree. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128 6.5 Product Discovery Toolbox. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130 6.6 Praktische Hinweise zur Anwendung einer Product Discovery im Unternehmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131 6.6.1 Folgen einer Fokussierung auf die Product Delivery. . . . . . . . . 132 6.6.2 Potenzielle Stolpersteine bei der Einführung von Product Discovery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133 6.6.2.1 Fremdbestimmung von Produktteams . . . . . . . . . . . 133 6.6.2.2 Output statt Outcome . . . . . . . . . . . . . . . . . . . . . . . . 133 6.6.2.3 Kein regelmäßiger Austausch mit dem User. . . . . . . 134 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134 7

Validierung von Produktideen am Markt. . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 Anna Wicher 7.1 Warum Validierung?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 7.1.1 Worum wird es hier gehen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 7.1.2 Wie lange dauert so eine Validierung normalerweise?. . . . . . . . 139 7.1.3 Was für ein Team brauche ich zur Validierung?. . . . . . . . . . . . . 140 7.2 Research – Womit fangen wir an?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141 7.2.1 Hypothesen – Was nehmen wir bisher an?. . . . . . . . . . . . . . . . . 141 7.2.2 Marktanalyse und Zielgruppendefinition – Worauf beziehen sich unsere ersten Annahmen?. . . . . . . . . . . . . . . . . . . . . . . . . . 143 7.2.3 Qualitativer Research – Was sagt die Zielgruppe?. . . . . . . . . . . 143 7.2.4 Quantitative Validierung – Wie viele gibt es davon?. . . . . . . . . 145 7.2.5 MVP-Definition und Ressourcenbedarf – Was brauchen wir zum Testen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 7.2.6 Design vs. Technik – Worauf liegt der Fokus bei der MVPErstellung?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148 7.3 Prototyping – Was bauen wir jetzt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149 7.3.1 Testplan & Feature-Definition – Was wollen wir wissen und was brauchen wir dafür? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 7.3.2 UX und UI – Wie soll das MVP aussehen?. . . . . . . . . . . . . . . . 153

Inhaltsverzeichnis

XV

7.3.3

Entwicklung – Wie und mit welcher Technologie wird das MVP umgesetzt? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.3.4 Team – Wer baut das? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 7.3.5 Zeitabschätzung – Wie lange brauchen wir dafür? . . . . . . . . . . 156 7.4 Testing – Wie kommen wir an die Zahlen?. . . . . . . . . . . . . . . . . . . . . . . . 157 7.4.1 Launch- & Marketing-Plan – Wer testet das MVP?. . . . . . . . . . 157 7.4.2 Pivot – Alles noch mal neu?. . . . . . . . . . . . . . . . . . . . . . . . . . . . 158 7.4.3 KPIs & Businessplan – Verdienen wir jetzt damit Geld?. . . . . . 159 7.5 Und wie geht’s jetzt weiter?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 8

Product Delivery. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Tim Adler 8.1 Los geht’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 8.2 Was man braucht, bevor es losgeht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 8.2.1 MVP vs. MLP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 8.2.2 Features dokumentieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 8.2.3 Erstmal „hübsch“ machen – Design vorbereiten. . . . . . . . . . . . 166 8.3 Vorher wissen, was es kosten wird. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8.3.1 Klassisches Projektmanagement FTW. . . . . . . . . . . . . . . . . . . . 169 8.3.2 Eine Idee von Teamgröße. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 8.3.3 Zeit- und damit Kostenabschätzung. . . . . . . . . . . . . . . . . . . . . . 170 8.3.4 Was tun, wenn es zu teuer oder zu langsam ist? . . . . . . . . . . . . 171 8.4 Werkzeugkasten einrichten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 8.4.1 Noch mehr Vorbereitung, ernsthaft? . . . . . . . . . . . . . . . . . . . . . 173 8.4.2 Einen Namen wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 8.4.3 Backlog vorbereiten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174 8.4.4 Sprint-Board einrichten. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 8.5 Marathon laufen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.5.1 Sprintlänge wählen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 8.5.2 Meetings, Meetings, Meetings … sind der Sprint. . . . . . . . . . . 179 8.5.2.1 Sprintplanung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180 8.5.2.2 Daily(-Standup). . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 8.5.2.3 Sprint-Review. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 8.5.2.4 Retrospektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.5.3 Sind wir noch im Plan …?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 8.5.4 … und falls nicht, wie kommen wir wieder zurück „auf Plan“?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 8.6 Kleine Helferlein im Alltag. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 8.6.1 Entwickler rufen nach „Refactoring!“. . . . . . . . . . . . . . . . . . . . 187 8.6.2 Kundensupport warnt vor „Bugs!“. . . . . . . . . . . . . . . . . . . . . . . 188 8.7 Das war’s. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

XVI

Inhaltsverzeichnis

9 Growth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Markus Andrezak 9.1 Alle wollen Wachstum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 9.2 Wie lange dauert Wachstum?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 9.2.1 Henry Ford und das Model T. . . . . . . . . . . . . . . . . . . . . . . . . . . 195 9.2.2 Das iPhone. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 9.2.3 Digitale „Wachstumswunder“ . . . . . . . . . . . . . . . . . . . . . . . . . . 197 9.3 Wachstumssprünge in zwei Phasen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198 9.4 Modelle zum Wachstum. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.4.1 Der Hockey-Stick. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202 9.4.2 Das 3-Horizonte-Modell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204 9.4.2.1 Horizont 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 9.4.2.2 Horizont 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206 9.4.2.3 Horizont 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207 9.4.2.4 Das Zusammenspiel der Horizonte. . . . . . . . . . . . . . 207 9.5 Was müssen wir beherrschen, um Wachstum zu erreichen? . . . . . . . . . . . 208 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209 10 Produktänderungen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Rainer Gibbert 10.1 Abneigung gegen Veränderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 10.2 Warum Veränderungen abgelehnt werden. . . . . . . . . . . . . . . . . . . . . . . . . 213 10.2.1 Nutzern ist Design (überwiegend) egal. . . . . . . . . . . . . . . . . . . 213 10.2.2 Nutzer lieben Routinen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214 10.2.3 Nutzer mögen Vertrautes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215 10.2.4 Nutzer tendieren zum Status quo. . . . . . . . . . . . . . . . . . . . . . . . 215 10.2.5 Nutzer bevorzugen, was sie bereits besitzen . . . . . . . . . . . . . . . 215 10.2.6 Nutzer befürchten Kontrollverlust. . . . . . . . . . . . . . . . . . . . . . . 216 10.3 Akzeptanz für Veränderungen erzeugen. . . . . . . . . . . . . . . . . . . . . . . . . . 216 10.3.1 Veränderung nicht als Selbstzweck. . . . . . . . . . . . . . . . . . . . . . 216 10.3.2 Veränderungen nutzerzentriert begleiten. . . . . . . . . . . . . . . . . . 217 10.3.3 Veränderungen für Nutzer vorab testbar machen. . . . . . . . . . . . 217 10.3.4 Nutzern die Auswahl lassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 218 10.3.5 Inkrementelle Veränderungen bevorzugen. . . . . . . . . . . . . . . . . 219 10.3.6 Veränderungen kommunizieren und schmackhaft machen. . . . 219 10.3.7 Abwarten und in Geduld üben. . . . . . . . . . . . . . . . . . . . . . . . . . 221 10.4 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223

Inhaltsverzeichnis

XVII

11 A/B-Testing im digitalen Produktmanagement. . . . . . . . . . . . . . . . . . . . . . . 225 Sascha Hoffmann 11.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 11.2 Grundlagen der Hypothesenbildung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227 11.3 Die Statistik beim A/B-Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 228 11.4 A/B-Tests in der Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231 12 Produktmanagement ganzheitlich verstanden. . . . . . . . . . . . . . . . . . . . . . . . 233 Patrick Roelofs 12.1 Die Aufgaben des Produktmanagers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233 12.1.1 Ergebnisdimension 1: Zufriedenheit der Nutzer mit dem Produkt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234 12.1.2 Ergebnisdimension 2: Kommerzieller Erfolg des Produktes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235 12.2 Der Produktmanager als proaktiver Beziehungsmanager . . . . . . . . . . . . . 236 12.3 Der Produktmanager als herausragender Kommunikator . . . . . . . . . . . . . 238 12.4 Der Produktmanager als „Entscheidungsmacher“. . . . . . . . . . . . . . . . . . . 239 12.4.1 Klar formulierte Ziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 12.4.2 Maximale Transparenz („Connecting the dots“). . . . . . . . . . . . 240 12.4.3 Notwendige und sinnvolle Eskalationen . . . . . . . . . . . . . . . . . . 241 12.5 Der Produktmanager als Antworten-Lieferant. . . . . . . . . . . . . . . . . . . . . . 242 12.6 Der Produktmanager ist (klarer) Gedanken-Formulierer. . . . . . . . . . . . . . 244 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245 13 Product Sense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Robert Schulke und Nikkel Blaase 13.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 13.2 Was ist Product Sense?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248 13.3 Die Bedeutung von Product Sense. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 13.4 Wie Product Sense entwickelt werden kann . . . . . . . . . . . . . . . . . . . . . . . 250 13.4.1 Empathie aufbauen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 13.4.2 Produkt- und Domänen-Wissen stärken. . . . . . . . . . . . . . . . . . . 253 13.4.2.1 Grundlegendes Produktwissen. . . . . . . . . . . . . . . . . 253 13.4.2.2 Spezifisches Domänenwissen. . . . . . . . . . . . . . . . . . 254 13.5 Product-Sense-Schnellstart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256 14 Product Leadership. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Tobias Freudenreich 14.1 Laterale Führung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259 14.1.1 Laterale Führung durch Verständigung . . . . . . . . . . . . . . . . . . . 259 14.1.2 Laterale Führung durch Macht. . . . . . . . . . . . . . . . . . . . . . . . . . 261

XVIII

Inhaltsverzeichnis

14.1.3 Laterale Führung durch Vertrauen. . . . . . . . . . . . . . . . . . . . . . . 262 14.1.4 Das Zusammenspiel von Verständigung, Macht und Vertrauen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 14.2 Disziplinarische Führung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264 14.2.1 Klare Strukturen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266 14.2.2 Ein klarer Zielkorridor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267 14.2.3 Kompetente Produktmanager*innen . . . . . . . . . . . . . . . . . . . . . 270 14.2.4 Starke Produktteams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273 14.2.5 Interdisziplinäre Führung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275 14.2.6 Schlussbetrachtung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278 15 Alignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Arne Kittler 15.1 Warum ist Alignment wichtig im Kontext moderner Produktentwicklung?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 15.1.1 Alignment schafft Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . 280 15.1.2 Alignment hilft Ressourcenverschwendung zu vermeiden . . . . 280 15.1.3 Alignment hilft Entscheidungen herbeizuführen. . . . . . . . . . . . 281 15.2 Mit wem sollte man sich als Produktmanager aktiv abstimmen? . . . . . . . 282 15.3 In welchen Kontexten ist Alignment besonders wichtig? . . . . . . . . . . . . . 283 15.4 Wann sollte eine systematische Abstimmung am sinnvollsten erfolgen?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283 15.5 Welche Vorgehensweisen helfen bei der Abstimmung?. . . . . . . . . . . . . . . 283 15.5.1 Die richtigen Gesprächspartner*innen in der richtigen Reihenfolge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 15.5.2 Sinnvolle Konstellationen und Methoden für eine aktive Abstimmung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 15.6 Wichtige zu klärende Fragen im Rahmen der Abstimmung . . . . . . . . . . . 285 15.6.1 Ausgangslage aus Nutzer*innenperspektive. . . . . . . . . . . . . . . 285 15.6.2 Zielbild aus Nutzer*innenperspektive. . . . . . . . . . . . . . . . . . . . 286 15.6.3 Hypothesen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 15.6.4 Input – und Rollen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 15.6.5 Output – und Grenzen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 15.6.6 Outcome – und Grenzen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 15.7 Konflikte identifizieren und zur Klärung bringen . . . . . . . . . . . . . . . . . . . 288 15.8 Abstimmung in der Praxis: Auftragserklärung bei XING. . . . . . . . . . . . . 289 15.8.1 Ursprung und Entwicklung der Auftragsklärung. . . . . . . . . . . . 290 15.8.2 Wesentliche Artefakte und übliche Praktiken . . . . . . . . . . . . . . 290 15.8.3 Einführung, Anwendung und Missverständnisse. . . . . . . . . . . . 292 15.9 Grenzen sinnvoller Abstimmung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293

Inhaltsverzeichnis

XIX

16 Product Evangelizing und Storytelling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Petra Wille 16.1 Warum Storytelling im Produktmanagement wichtig ist. . . . . . . . . . . . . . 296 16.2 Warum unsere Gehirne Geschichten lieben. . . . . . . . . . . . . . . . . . . . . . . . 297 16.3 Was Geschichten im beruflichen Kontext bewirken können. . . . . . . . . . . 300 16.3.1 Elemente einer guten Geschichte. . . . . . . . . . . . . . . . . . . . . . . . 300 16.3.2 Geschichten sind das perfekte Design-Tool. . . . . . . . . . . . . . . . 301 16.4 Wie man gute Geschichten erdenkt und erzählt. . . . . . . . . . . . . . . . . . . . . 302 16.4.1 Was hat das alles mit Produktmanagement zu tun?. . . . . . . . . . 303 16.4.2 Die Angst vor dem leeren Blatt überwinden . . . . . . . . . . . . . . . 305 16.5 Wie man die Botschaft nachhaltig verankert. . . . . . . . . . . . . . . . . . . . . . . 306 16.6 (M)Ein Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310 17 Product Owner und Scrum Master. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313 Jan Köster und Florian Meyer 17.1 Mehr als ein Rollenbild aus einem Framework. . . . . . . . . . . . . . . . . . . . . 313 17.2 Wie eine gute Zusammenarbeit gelingen kann . . . . . . . . . . . . . . . . . . . . . 315 17.2.1 Start with Why. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315 17.2.2 Gemeinsame Visionen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 17.2.3 Vertrauen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 17.2.4 Agile Prinzipien. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 17.2.5 Wann hören wir auf? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 17.2.6 Warum machst Du das so?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 17.2.7 Seid Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319 17.2.8 Gemeinsame Rituale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 17.2.9 Euer PDCA-Zyklus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 17.2.10 Führen über Warum und Transparenz . . . . . . . . . . . . . . . . . . . . 322 17.2.11 Führen über Haltung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323 17.2.12 Gemeinsam geteilte Führung. . . . . . . . . . . . . . . . . . . . . . . . . . . 323 17.3 Was folgt?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324 17.4 Lernende Teams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326 18 User Experience verstehen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Inken Petersen 18.1 Die Bedeutung eines positiven Nutzererlebnisses. . . . . . . . . . . . . . . . . . . 328 18.2 Der iterative UX-Designprozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328 18.3 Die Kerndisziplinen im User Experience-Bereich. . . . . . . . . . . . . . . . . . . 330 18.3.1 Der UX-Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330 18.3.2 Der Visual Designer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331 18.3.3 Der User Researcher . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332

XX

Inhaltsverzeichnis

18.4 Die verschiedenen Arten von UX-Teams. . . . . . . . . . . . . . . . . . . . . . . . . . 332 18.4.1 Das klassische UX-Team. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332 18.4.2 Das „UX-Team of one“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 18.4.3 Das hybride „UX- & Visual-Design-Team“ mit separater User-Research-Dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333 18.5 Die beste Organisationsform. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 18.6 Die richtige Menge an UX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335 18.7 Die Zukunft von UX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336 19 Data Analytics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 Jan Martens 19.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339 19.2 Rollen und Organisationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 19.3 Die Fallstricke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340 19.3.1 Die Feel-Good-Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 19.3.2 Die Rechtfertigungsanalyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . 341 19.3.3 Die Symptom-Analyse. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 342 19.3.4 Einfache Fragen, komplexe Antworten . . . . . . . . . . . . . . . . . . . 342 19.3.5 Selbstüberschätzung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343 19.3.6 Selbstverliebtheit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 19.3.7 Einfach falsch. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344 19.3.8 „Nicht signifikant“. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 19.3.9 Zu anspruchsvoll . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346 19.3.10 Fehlende Distanz – Sunk costs. . . . . . . . . . . . . . . . . . . . . . . . . . 347 19.3.11 Zu wenig Daten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347 19.4 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348 20 Produktorganisationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 Michael Schultheiß, David Gehrke und Lutz Göcke 20.1 Was ist eine Produktorganisation?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 20.2 Fünf Eigenschaften erfolgreicher Produktorganisationen. . . . . . . . . . . . . 352 20.3 Strukturen, Abläufe, Mitarbeitende. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 20.3.1 Struktur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353 20.3.2 Abläufe. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358 20.3.3 Mitarbeitende. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 360 20.4 Archetypen von Produktorganisationen. . . . . . . . . . . . . . . . . . . . . . . . . . . 365 20.5 Veränderungs- und Anpassungsprozesse. . . . . . . . . . . . . . . . . . . . . . . . . . 366 20.5.1 Transformation in eine Produktorganisation. . . . . . . . . . . . . . . 367 20.5.2 Transformation innerhalb einer Produktorganisation. . . . . . . . . 367 20.6 Fazit. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369

Inhaltsverzeichnis

XXI

21 Wahl des „richtigen“ agilen Frameworks für das Unternehmen. . . . . . . . . 373 Stefan Roock 21.1 Einleitung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373 21.2 Das passende Framework für den agilen Piloten. . . . . . . . . . . . . . . . . . . . 375 21.2.1 Scrum vs. Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 21.2.2 Die Sache mit den Glaubenssätzen . . . . . . . . . . . . . . . . . . . . . . 377 21.2.3 Agiles Vorgehen im Startup vs. Konzern. . . . . . . . . . . . . . . . . . 378 21.3 Agiles Arbeiten in der ganzen Produktentwicklung. . . . . . . . . . . . . . . . . . 379 21.3.1 Abhängigkeiten minimieren. . . . . . . . . . . . . . . . . . . . . . . . . . . . 379 21.3.2 Abhängigkeiten managen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 380 21.3.3 Plattformen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382 21.3.4 Vorsicht mit Top-Down-Standardisierung. . . . . . . . . . . . . . . . . 383 21.3.4.1 Widerstand der Mitarbeitenden. . . . . . . . . . . . . . . . . 383 21.3.4.2 Verlust an Agilität. . . . . . . . . . . . . . . . . . . . . . . . . . . 384 21.3.5 Bleibt mir mit den Tools weg. . . . . . . . . . . . . . . . . . . . . . . . . . . 384 21.4 Agiles Arbeiten im ganzen Unternehmen . . . . . . . . . . . . . . . . . . . . . . . . . 385 21.4.1 Autonomie und Alignment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385 21.4.2 Anpassungsfähige Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387 21.4.2.1 Marktkontakt durch externe Referenzen. . . . . . . . . . 387 21.4.2.2 Unternehmensanpassung mit Soziokratie 3.0. . . . . . 388 21.5 Zusammenfassung. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Literatur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

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  Hamburg Markus Andrezak  überproduct GmbH, Potsdam Christian Becker  leanproductable GmbH, Berlin Nikkel Blaase  Orbit Ventures GmbH, Hamburg

Dominik Busching  tado°, München Tobias Freudenreich  Freier Product Leadership Coach & Berater, Hamburg David Gehrke  Hochschule Nordhausen, Nordhausen

Rainer Gibbert  Star Finanz GmbH, Hamburg Lutz Göcke  Hochschule Nordhausen, Nordhausen

Sascha Hoffmann  Hochschule Fresenus, Hamburg Alexander Hipp  Beyond, London Arne Kittler  facelift, Hamburg XXIII

XXIV

Jan Köster  Gruner + Jahr, Hamburg Jan Martens  Lotto24 AG, Hamburg Florian Meyer  Gruner + Jahr, Hamburg Inken Petersen  Hamburg

Patrick Roelofs  Aroundhome, Berlin Stefan Roock  it-agile GmbH, Hamburg Robert Schulke  Freiburg Michael Schultheiß  McKinsey & Co, Kiel Cansel Sörgens  Köln Philip Steen  Norderstedt Anna Wicher  MissionMe, Hamburg Petra Wille  Strong Product People, Hamburg

Herausgeber- und Autorenverzeichnis

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 einer klassischen, projektbasierten und einer agilen Entwicklung digitaler Produkte ein und stellt dabei die Vorteile der agilen Vorgehensweise dar. Danach werden die einzelnen Phasen der digitalen Produktentwicklung erläutert. Diese reichen von der Produktvision und dem Ableiten einer geeigneten Produktstrategie über die Ermittlung der marktseitig „richtigen“ Produkte bzw. Produkteigenschaften im Rahmen einer Product Discovery bis hin zur eigentlichen Produktentwicklung, der Product Delivery. Anschließend wird Scrum, als die in der Praxis dominierende agile Entwicklungsmethode, im Detail erläutert. Mit Kanban wird danach eine weitere, ebenfalls sehr populäre Methode beschrieben, bevor zum Schluss im Überblick auf Mischformen sowie andere Weiterentwicklungen agiler Methoden zur digitalen Produktentwicklung eingegangen wird.

S. Hoffmann (*)  Professur für Online-Management, Hochschule Fresenius, Hamburg, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-41880-9_1

1

2

S. Hoffmann

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 insbesondere mit der Wasserfall-Methode assoziiert (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 adressierten Zielgruppe und ggf. weiterer relevanter Stakeholder an das neue Produkt zusammengetragen. Ist diese Phase abgeschlossen, werden in der Planungs- bzw. Konzeptionsphase die Spezifikationen für das zu entwickelnde digitale Produkt abgeleitet und in einem ausführlich beschriebenen Anforderungskatalog (Lastenheft) schriftlich fixiert. Dieser dient in der Folge als Pflichtenheft für die Entwickler. 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 und 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. Review-Phase, 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 bzw. live genommen (englisch: released) (Laudon et al. 2016). Ein Entwicklungsprojekt im klassischen Projektmanagementsinn ist bereits dann erfolgreich abgeschlossen, wenn sämtliche inhaltlichen Anforderungen innerhalb des

Anforderungsanalyse Konzeptentwicklung Development Test & Review Release Zeit

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

1  Einführung in das digitale Produktmanagement

3

vorgegebenen Zeit- und Budgetrahmens umgesetzt wurden, also der geforderte Output geliefert wurde. Im Produktmanagement wird dagegen erst dann von einem erfolgreichen Produkt gesprochen, wenn es von den Nutzern angenommen wird und es bei ihnen zu der gewünschten Verhaltensänderung führt (Outcome), durch die sich das Unternehmen einen positiven Effekt auf seine (monetären) Erfolgskennzahlen verspricht (Impact). 

Eine hervorragende Beschreibung, was ein Produkt im Produktmanagement-Sinne ist, wird im aktuellen Scrum Guide gegeben: „Ein Produkt ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder:innen, eindeutig definierte Benutzer:innen oder Kund:innen. Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.“ (Schwaber und Sutherland 2020)

Ob die bezweckte Verhaltensänderung allerdings wirklich eintritt, ist unsicher. Vor allem, weil annahmegemäß die Umwelt- und Marktverhältnisse einem steten Wandel unterliegen. Zur Beschreibung wird dafür oft von VUCA gesprochen. 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).1 Im Produktmanagement geht es in dem Zusammenhang 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. Produktideen sind in gewisser Weise also immer „Wetten“, die sich erst noch als richtig erweisen müssen. Die vermeintliche Planungssicherheit des klassischen Projektmanagements entpuppt sich demnach vielfach als Scheinsicherheit. Selbst die detailliertesten Spezifikationen am Anfang einer Produktidee 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 erst am Ende bemerkt, wenn das Produkt vom Markt nicht angenommen wird bzw. durch beispielsweise zwischenzeitlich

1  Als

Abwandlung von VUCA wird die Welt neuerdings auch mit dem Akronym BANI charakterisiert, das für brittle (brüchig), anxious (ängstlich), non-linear (nicht-linear) und incomprehensible (unbegreiflich) steht. Beide Konzepte beschreiben die Herausforderung, in einer sich schnell ändernden Umwelt erfolgreich zu sein. Während das VUCA-Modell die Komplexität von Entscheidungen und Handlungsfolgen betont, geht das BANI-Modell von zunehmend chaotischen und damit unvorhersagbaren Einflussfaktoren insbesondere im Zusammenhang mit dem exponentiellen technologischen Fortschritt aus (Cascio 2020).

4

S. Hoffmann

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 digitalen Produktmanagement wird dagegen akzeptiert, dass zu Beginn der Softwareentwicklung typischerweise 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 CynefinFramework 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. 17 von Jan Köster und Florian Meyer). Im Gegensatz zum klassischen Projektmanagement hat sich daher im Produktmanagement eine andere Art der digitalen Produktentwicklung durchgesetzt: sie findet agil statt. Das bedeutet, dass ein Produkt entlang des gesamten Entwicklungsverlaufs schrittweise (inkrementell) 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 jeweils aktuellen Anforderungen und Bedürfnissen des Marktes entspricht. Das Ergebnis jeder Feedbackschleife beeinflusst dabei unmittelbar die weitere Produktentwicklung (Abb. 1.2). Ganz neu ist die agile Vorgehensweise im digitalen Produktmanagement nicht: Zum Beispiel hat Tom Gilb (1988) in den 1980er Jahren eine Methode namens „Evolutionäres Projektmanagement“ entwickelt, die viele Grundprinzipien der agilen Entwicklung vorwegnahm. Ebenso hat Kent Beck (2000) in den 1990er Jahren die Extreme Programming (XP)-Methodologie entwickelt, die bereits agile Konzepte wie Test-Driven Development (TDD) und Continuous Integration (CI) beinhaltet.

Vision

Zeit

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

1  Einführung in das digitale Produktmanagement

5

Im Jahr 2001 wurde methodenübergreifend das Manifest für Agile Softwareentwicklung (www.agilemanifesto.org) verfasst, das als konzeptioneller Rahmen der modernen digitalen Produktentwicklung gilt. Darin wurden vier grundlegende Werte sowie daraus abgeleitet zwölf Prinzipien aufgestellt, wie digitale Produkte entwickelt werden sollten. 

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. 5. (Beck et al. 2001) Oberstes Ziel ist es, ein funktionierendes Produkt bereitzustellen, das am Markt auch wirklich angenommen wird. Um dies zu erreichen sind u. a. eine enge, vertrauensvolle Zusammenarbeit mit dem Kunden bzw. den internen Stakeholdern eines Unternehmens sowie das Einholen von Marktfeedback notwendig. Grundvoraussetzung ist dabei die aufrichtige Bereitschaft, jederzeit offen für Anforderungsänderungen im Entwicklungsprozess zu sein (Cagan 2018). 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. 

„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.)

Während klassische Projekte meist mit temporären, projektspezifisch zusammengesetzten Teams umgesetzt werden, wird im digitalen Produktmanagement bevorzugt 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, 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

6

S. Hoffmann

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 Frameworks bzw. Methoden entwickelt, die jedoch alle auf grundlegenden agilen Prinzipien basieren.

1.2 Grundlagen des agilen Produktmanagements Unabhängig vom einzelnen Framework bzw. der konkreten Methode ist es das generelle Ziel, möglichst frühzeitig und regelmäßig funktionierende Software auf dem Markt zu veröffentlichen. Dazu werden digitale Produkte inkrementell, d. h. in aufeinander aufbauenden Versionen entwickelt, um das Marktfeedback zu einem releasten Produktinkrement als Input in die weitere Produktentwicklung der einfließen zu lassen. Auf diese Weise können die Prognosesicherheit für einen späteren Markterfolg gesteigert und die Risiken in der Produktentwicklung kontrolliert werden (Cagan 2018). Das erste am Markt veröffentlichte Produktinkrement wird vielfach als Minimum Viable Product (MVP) bezeichnet2 und soll sich auf die notwendigsten Produktmerkmale (englisch: Features) beschränken, um so früh wie möglich echtes Marktfeedback in die weitere Produktentwicklung einfließen zu lassen (Krasadakis 2019; Gibbert 2014a). Dieses Vorgehen entspricht dem validierten Lernen aus dem PDCA-Zyklus, der auf Arbeiten von Walter Sheward und William Deming aus den 1930er Jahren zurückgeht. Dabei handelt es sich um ein Konzept zur kontinuierlichen Verbesserung von Produkten bzw. Prozessen in Organisationen. Der Zyklus besteht aus vier Schritten: Planung (Plan), Durchführung (Do), Überprüfung (Check) und Ableitung von Maßnahmen (Act), s. Abb. 1.3.3 In der Planungsphase werden Ziele und Maßnahmen definiert, die in der Durchführungsphase umgesetzt werden. In der Überprüfungsphase werden die Ergebnisse analysiert und bewertet, worauf im letzten Schritt ggf. notwendige Anpassungen bzw. Verbesserungen vorgenommen werden und der Zyklus von neuem startet (Deming 1982, zum PDCA-Zyklus, siehe auch ausführlich Kap. 17 von Jan Köster und Florian Meyer).

2 Es

gibt auch abweichende Definitionen von einem Minimum Viable Product. So bezeichnen Eric Ries und Steve Blank (2011) das erste offizielle Produktinkrement als Minimal Marketable Product (MMP). Nach Ries kann es davor jedoch bereits andere MVPs geben, die aber nicht veröffentlicht, sondern „nur“ als Prototypen in User-Tests etc. getestet werden. 3 In Ihrem Buch „The Lean Startup“ haben Eric Ries und Steve Blank (2011) den vierphasigen PDCA-Zyklus zu einem dreiphasigen Build-Measure-Learn-Zyklus verdichtet, der heute in der Startup-Szene weit verbreitet ist.

1  Einführung in das digitale Produktmanagement

7

Plan

Do

Act

Check

Abb. 1.3   Der PDCA-Zyklus. (Quelle: In Anlehnung an Deming 1982)



„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) „If you are not embarrassed by the first version of your product, you’ve launched too late.“ (Reid Hoffman 2017)

In aller Regel gibt es in der Produktorgnisation eine Person, die das Hauptaugenmerk auf den marktseitigen Erfolg des Produkts hat. Ihre Jobbezeichung ist üblicherweise Produktmanager, Product Manager bzw. Product Owner.4 Der Produktmanager 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 Marktbzw. Nutzerbedürfnisse auf sein (digitales) Produkt, s. Abb. 1.4. Um in dieser Schnittstellenposition erfolgreich zu sein, tauscht sich der Produktmanager regelmäßig mit den anderen Stakeholdern des Produktes aus, um deren Wünsche bzw. Anforderungen zu verstehen (Cagan 2018; Neuberger 2014). Um ein Produkt zielgerichtet zu entwickeln, sollte der Produktmanager 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

4 Eigentlich

gibt es den Product Owner als Rolle nur in Scrum, jedoch wird die Bezeichnung auch in Produktorganisationen verwendet, die nicht (mehr) nach Scrum arbeiten.

8

S. Hoffmann

Markt/Nutzer (User Experience)

Technologie

Business

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

skizziert und ein mit der Entwicklung des Produktes verfolgtes, motivierendes Ziel formuliert (zur Produktvision siehe ausführlich Kap. 2 von Inken Petersen). Damit das Produkt im Unternehmen die benötigten Ressourcen und eine positive Aufmerksamkeit bekommt, ist es von enormer Bedeutung, dass die Produktvision vom gesamten Unternehmen mitgetragen wird. Um dies zu erreichen, sollte das Produktteam die Produktvision möglichst in enger Abstimmung mit weiteren Stakeholdern entwickeln. Neben anderen Formaten ist das Product Vision Board ein gutes Vehikel, das genutzt werden kann, um die Produktvision zu visualisieren und damit ins Unternehmen zu transportieren (Abb. 1.5). 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). Getreu dem Ausspruch des legendären Eishokey-Spielers Wayne Gretzky „I skate to where the puck is going to be, not where it has been“ gibt die Produktvision die Richtung vor und im Rahmen der Produktstrategie muss bestimmt werden, wie die Produktoganisation dorthin gelangen soll. In der Produktstrategie werden also die konkreten Ziele sowie der Weg dorthin festgelegt (zur Produktstrategie siehe ausführlich Kap. 3 von Christian Becker). In einer agilen, nutzerzentrierten Produktentwicklung stellen dabei sowohl die Ziele als auch der abgeleitete Weg dorthin zunächst nur Hypothesen („Wetten“) dar. Es

1  Einführung in das digitale Produktmanagement

9

Vision Target Group

Needs

Product

Business Goals

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

muss daher überprüft werden, ob es auch wirklich Nutzer in einer ausreichend großen Zahl gibt, die das geplante Produkt haben möchten, damit für das Unternehmen ein wirtschaftlicher Erfolg erwartbar ist. Um möglichst rasch die Unsicherheiten bei der Produktentwicklung abzubauen, müssen frühzeitig die grundlegenden Annahmen zum sog. Product-Market-Fit validiert werden, Diese beziehen sich auf die tatsächlichen Bedürfnisse der Zielgruppe, die wirtschaftlichen Annahmen aber auch die technische Umsetzbarkeit (Cagan 2016). Insbesondere bei größeren, grundlegenden Produktneuentwicklungen wird dazu vor der eigentlichen Produktentwicklung eine eigene Discovery-Phase vorgeschaltet (zur Product Discovery siehe ausführlich Kap. 6 von Philip Steen und Alexander Hipp). In der Praxis besteht dabei 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 beispielsweise für Pharmazieunternehmen Normalität ist, dass sich ein Großteil der Arzneiinnovationen während der Discovery-Phase doch als nicht marktfähig herausstellt, ist diese Denkweise in der Digitalbranche deutlich seltener anzutreffen. Dort wird häufig 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).

10

S. Hoffmann

In der Discovery-Phase stehen dem Produktteam 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. 18 von Inken Petersen).  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 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. Neben Desk Research ist es wichtig, dass das Produktteam dafür mit Menschen aus der Zielgruppe in den Austausch kommt. Idealerweise besteht die Möglichkeit, die Menschen 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 Produktteam 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 Visulaisierungsmethode ist die Erstellung von Customer Journey Maps (auch User Journey Maps genannt). Sie dienen dazu, die einzelnen Phasen, die ein User bei einer Aufgabe, Problembewältigung o. ä. durchläuft, zu veranschaulichen und damit im Detail zu verstehen, siehe Abb. 1.6. In der Produktentwicklung wird versucht, daraus abzuleiten, an welcher Stelle (Touchpoint) und in welcher Form ein neues Produkt für die User möglicherweise einen Mehrwert bieten kann (vgl. dazu ausführlich Kempe 2022 sowie Nielsen Norman Group 2016).5

5 Ein

weiteres populäres Einsatzfeld von Customer Journeys stellt das (Online-)Marketing dar. Anders als in der Produktentwicklung geht es dabei jedoch um die Visualisierung der Touchpoints, die ein User mit einem bestehenden Produkt eines Unternehmens hat. Daraus abgeleitet wird dann

1  Einführung in das digitale Produktmanagement Phase 1

11

Phase 2

1

4

2

Phase 3

Phase 4

5

7

6

8

3

8 1 5

3 2

Opportunies

6

4

Opportunies

7

Opportunies

Opportunies

Abb. 1.6   Customer Journey Map. (Quelle: In Anlehnung an Nielsen Norman Group 2016)

Die analysierten User werden häufig zu sog. Personas (auch: Personae) verdichtet. 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 (Revella 2015 sowie Cooper 1999). Nachdem der Problemraum von allen Teammitgliedern wirklich erfasst wurde, geht es im Design-Thinking-Prozess daran, Lösungsansätze zu erarbeiten. Dabei werden im ersten Schritt viele unterschiedliche Ideen entwickelt, um einen möglichst breiten Lösungsraum aufzuspannen. Zur Inspiration können hier neben klassischem Brainstorming viele weitere Kreativitätstechniken 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 zu validieren (vgl. zur Validierung ausführlich Kap. 7 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).

insbesondere, an welchem Touchpoint der User welchen Content benötigt, um ihn zu einer Kaufentscheidung zu motivieren (vgl. Kempe 2022).

12

S. Hoffmann

 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 User-Tests von (Ziel-)Nutzern bewertet. Dabei sollen sie nicht nur helfen, die erdachten Lösungsideen zu validieren, sondern auch 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 in einem Testlabor am Bildschirm die digitalen Prototypen in Form von Mockups bzw. Click-Dummies gezeigt, die möglichst ausprobiert werden können, und es wird aufgezeichnet, wohin ein Nutzer blickt bzw. wie er sich auf den Testseiten verhält. Ein ä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.  Auf der Basis des Design-Thinking-Ansatzes wurde bei Google Ventures

der Design Sprint entwickelt. Dabei handelt es sich um einen fünftägigen strukturierten Prozess, der sich auf eine klar umrissene Herausforderung bzw. eine spezifische Fragestellung konzentriert. Während des Design Sprints arbeitet ein multidisziplinäres Team eine Woche intensiv zusammen, um schnell Ideen zu entwickeln, zu testen und zu verfeinern. Die Methode ist besonders nützlich für überschaubare Fragestellungen, bei denen schnelle Entscheidungen und schnelle Ergebnisse erforderlich sind (Jake Knapp et al. 2016). Noch einen Schritt weiter geht die kontinuierliche Discovery, bei der statt isolierter Discovery-Phasen regelmäßig, oft wöchentlich, kleinere Überprüfungen von Produktannahmen (Hypothesen) mit Usern vorgenommen werden (Torres 2021).

1  Einführung in das digitale Produktmanagement

13

Wenn sich in der Discovery-Phase ein konkreter Produktansatz als Erfolg versprechend erwiesen hat, muss der Produktmanager das zu entwickelnde Produkt auf die Product Roadmap bringen. Die Product Roadmap definiert die Meilensteine und Ziele, die ein Produktteam typischerweise in den kommenden 12 bis 18 Monaten erreichen möchte. Dazu beschreibt sie die wesentlichen zu erstellenden Produkt-Features bzw. -versionen. Die Verwendung einer Product Roadmap ist sehr hilfreich in der Kommunikation mit Stakeholdern; insbesondere, um mit dem Top-Management die Unternehmensziele und die Produktziele abzugleichen und gleichzeitig die für die Produktentwicklung notwendigen Investitionsentscheidungen und damit verbundenen Ressourcenallokationen abzustimmen (siehe zu Product Roadmaps ausführlich Kap. 5 von Dominik Busching und Lutz Göcke sowie Pichler 2014). 

Immer mehr Unternehmen setzen auf Objectives and Key Results (OKR), um ihre Unternehmensaktivitäten zielgerichtet einzusetzen. Das Framework besteht aus einem System von Zielen (Objectives) und zugehörigen Leistungskennzahlen (Key Results). Durch die Verwendung des OKR-Ansatzes in Verbindung mit einer Product Roadmap können Unternehmen sicherstellen, dass das gesamte Unternehmen an den zentralen Fragestellungen arbeitet. Die Product Roadmap hilft dabei, die einzelnen Schritte des Entwicklungsprozesses besser zu planen und die OKRs stellen sicher, dass die entwickelten Funktionen und Features den strategischen Zielen des Unternehmens entsprechen. Vgl. zum Einsatz der OKRMethode in Produktorganisationen ausführlich Kap. 4 von Cansel Sörgens.

Um alle Stakeholder wirklich „abzuholen“, sollte der Produktmanager die Product Roadmap im Dialog erstellen und abstimmen. Nur so erhält er das für eine erfolgreiche Umsetzung notwendige individuelle Commitment6 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 („Bring everybody on the same page“, New Work SE o. J.). Nur, wenn das tatsächlich gegeben ist, kann das Produktteam sein Produkt selbstbestimmt umsetzen. Um diese „Autonomy through alignment“ herzustellen, wurde beispielsweise bei XING (New Work SE) das Canvas der Auftragsklärung (www. auftragsklaerung.com) entwickelt und in der Product-Community verbreitet (siehe hierzu ausführlich Kap. 15 von Arne Kittler).

6 Um

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).

14



S. Hoffmann

„[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.)

1.3 Digitale Produktentwicklung nach Scrum Die eigentliche Programmierung der digitalen Produkte findet in der Product Delivery statt (vgl. hierzu ausführlich Kap. 8 von Tim Adler). Hierfür wurden verschiedene agile Frameworks entwickelt. Das populärste ist Scrum, das 2022 von fast 90 % der Unternehmen eingesetzt wurde (Digital.ai 2022). Scrum, das aus dem Rugby stammend so viel wie „Gedränge“ bedeutet, wurde erstmals 1986 von Takeuchi und Nonaka (1986) als Bild für eine eng zusammenarbeitendes Team aus Softwareentwicklern verwendet. Indem sie damals erfolgreiche Unternehmen in den USA und Japan analysierten, fanden sie sechs grundlegende Prinzipien, die einer erfolgreichen Produktentwicklung zugrundeliegen. Dazu zählen insbesondere Outcomestatt Output-Zielvorgaben, Arbeiten in selbstorganisierten Teams mit einem agilen Vorgehen bei der Produktentwicklung inklusive frühzeitiger und regelmäßiger Marktchecks. Als eigenständiges agiles Framework wurde Scrum dann 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 2020).  „Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren. […] Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden.“ (Schwaber und Sutherland 2020, S. 3) Die drei Säulen von Scrum sind Transparenz, Überprüfung und Anpassung. Transparenz gilt dabei sowohl für das Scrum-Team als auch für die Stakeholder und bezieht sich sowohl auf das geplante Vorgehen als auch auf die getroffenen Entscheidungen. Der

1  Einführung in das digitale Produktmanagement

15

Fortschritt der (inkrementellen) Entwicklung hin zu einem werthaltigen Produkt soll dafür regelmäßig überprüft und bei neuen Erkenntnissen unmittelbar angepasst werden (Schwaber und Sutherland 2020). Um erfolgreich sein zu können, benötigt ein Scrum-Team insbesondere Autonomie und das Vertrauen der Organisation, selbstorganisiert und ergebnisverantwortlich arbeiten zu können. Gleichzeitig muss sich das Scrum-Team aber auch zu den Werten Commitment, Fokus, Offenheit, Respekt und Mut bekennen. Das Scrum-Team muss sich demnach auf seine Ziele committen und durch eine fokussierte Verfolgung der Ziele ein werthaltiges Produkt schaffen wollen. In einem respektvollen Miteinander soll das Scrum-Team dabei die Offenheit und den Mut haben, an schwierigen Problemen zu arbeiten und eigenständig ggf. auch mutige Entscheidungen zu treffen (Schwaber und Sutherland 2020). Innerhalb eines Scrum-Teams, das maximal zehn Mitglieder umfassen sollte, gibt es drei definierte Verantwortlichkeiten: den Product Owner, den Scrum Master sowie die idealerweise interdisziplinär aufgestellten Entwickler (Schwaber und Sutherland 2020).7 In Scrum wird der in Abschn. 1.2 charakterisierte Produktmanager als Product Owner bezeichnet. Er ist für die Wertmaximierung des Produktes verantwortlich, indem er sicherstellt, dass die Entwickler an den richtigen Aufgaben arbeiten und das Produkt einen Mehrwert für die Kunden bzw. die Stakeholder bietet (Schwaber und Sutherland 2020; Neuberger 2014). Für seine anspruchsvolle Aufgabe erhält der Product Owner Beistand 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 seiner Interaktion besser zu werden, und sorgt dafür, dass Hindernisse, welche das Scrum-Team behindern, möglichst beseitigt werden (Petersen 2017; Jungwirth 2016); siehe dazu auch Kap. 17 von Jan Köster und Florian Meyer. Um eine reibungslose Product Delivery zu gewährleisten, besteht eine der Hauptaufgaben für den Product Owner darin, neben der Entwicklung und Kommunikation des Produktziels das Product Backlog zu pflegen (Schwaber und Sutherland 2020). Darin enthalten sind alle Aufgaben, die von den Entwicklern bearbeitet werden müssen, um das Produkt weiterzuentwickeln.

7 Bis

zur 2017er Version wurde im Scrum-Guide statt von Verantwortlichkeiten noch von Rollen gesprochen, die neben dem Product Owner und dem Scrum-Master ein EntwicklerTEAM umfassten (Schwaber und Sutherland 2017). Um die in der Praxis insbesondere zwischen Product Owner und Entwicklern gelegentlich vorkommenden Konflikte zu adressieren und klarzustellen, dass innerhalb des Scrum-Teams alle für den Erfolg ihres Produktes gleichermaßen verantwortlich sind, wird inzwischen nicht mehr von einem Sub-Team gesprochen, sondern nur noch von Verantwortlichkeiten.

16

S. Hoffmann

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 DeliveryPhase bei neuen Erkenntnissen 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 von den Entwicklern usw. inhaltlich 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 wird jedoch meist das User-Story-Format 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 den Entwicklern 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 Produktentwicklung erfüllt werden müssen, damit die User Story erfolgreich umgesetzt worden ist (Cohn 2004). 

Der schematische Grundaufbau einer User Story für neue Produkt-Features lautet: „Als [Anwender] möchte ich [Aktion], um [Ziel]“, also beispielsweise: „Als User möchte ich den Feed neu laden können, um zu sehen, welche neuen Inhalte zwischenzeitlich veröffentlicht wurden.“ Müssen z. B. Produktfehler („Bugs“) behoben werden, ist es i. d. R. nicht sinnvoll, die Backlog-Einträge als User Story zu formulieren: „Als User möchte ich, dass die App in iOS nicht abstürzt, damit ich sie normal nutzen kann.“

Eine gute User Story sollte den INVEST-Kriterien entsprechen. 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

17

• 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 von den Entwicklern implementiert. Weniger wichtige Einträge sind dagegen oftmals noch gar nicht im Detail ausformuliert, sondern stehen als „Platzhalter“ am Ende des Product Backlog. Die Priorisierung der User Stories stellt regelmäßig eine große Herausforderung dar. Zentrale Kriterien sind der Business Value, ggf. vorhandene inhaltliche Abhängigkeiten, die Auslieferbarkeit sowie das Ausmaß an Unsicherheit und natürlich der geschätzte Aufwand bei der Umsetzung einer User Story. Grundsätzlich sollten User Stories, die hoch priorisiert und damit zeitnah umgesetzt werden, einen hohen Business Value bzw. Impact 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 aufbauen, natürlich bei der Umsetzung vorgezogen werden müssen (Gibbert 2014a; Pichler 2014). Für die konkrete Priorisierung von Product-Backlog-Einträgen stehen zahlreiche Modelle für eine strukturierte und transparente Entscheidungsfindung zur Verfügung. Dazu zählt beispielsweise das in Abb. 1.7 dargestellte Kano-Modell (Kano et al. 1984), welches inhaltlich auf der Zwei-Faktoren-Theorie von Frederick Herzberg (Herzberg et al. 1959) basiert. In der Grundform unterteilt das Modell Product Backlog-Einträge in Basis-, Leistungs- und Begeisterungsmerkmale und fokussiert damit auf deren Marktrelevanz. Basismerkmale machen ein Produkt nicht wesentlich besser, würden bei einem Fehlen jedoch zu Unzufriedenheit führen (beispielsweise Sicherheitsgurte bei einem Auto). Leistungsmerkmale steigern die Zufriedenheit der User mehr oder weniger linear (z. B. der Kraftstoffverbrauch eines Autos) und Begeisterungsmerkmale schließlich sind solche, die beim User einen „Wow-Effekt“ auslösen sollen bzw. eine echte

18

S. Hoffmann Kundenzufriedenheit

Begeisterungsmerkmale Leistungsmerkmale

Erwartungen Basismerkmale

Abb. 1.7   Das Kano-Modell. (Quelle: In Anlehnung an Nielsen Norman Group 2016)

Differenzierung gegenüber dem Wettbewerb darstellen (z. B. die Selbstfahrfunktion bei einem Auto) (Wille 2016). In eine ähnliche Richtung geht die MuSCoW-Methode, nach der Backlog-Einträge in „absolut zwingend“ (Must have), „bevorzugt“ (Should have), „optional“ (Coud have) und „sollte nicht“ (Won’t have) umgesetzt werden eingeteilt werden (Wille 2016). In einer Impact-Effort-Matrix wird der von einer Produktanforderung erwartete marktseitige Mehrwert dem mit der Umsetzung verbundenen Aufwand gegenübergestellt. Bei Backlog-Einträgen, die einen hohen Impact erwarten lassen und gleichzeitig mit wenig Aufwand verbunden sind, ist die Priorisierung vergleichsweise einfach (ebenso bei sog. „Money Pits“, die bei viel Aufwand nur einen geringen Mehrwert erwarten lassen). Schwieriger ist die Priorisierung von Anforderungen, die zwar einen großen Mehrwert in Aussicht stellen, aber auch mit einem hohen (zeitlichen) Aufwand einhergehen („Big Bets“). Im letzteren Fall hilft z. B. die Rocks, Pebble & SandMethode, nach der sich Scrum-Teams Teile ihrer Arbeitszeit grundlegend für die großen Themen, die einen wirklichen Unterschied machen („Big Rocks“), blocken (z. B. 70 %), einen weiteren Teil für die Dinge, die einen gewissen Mehrwert bieten und das Produkt weiterbringen, aber bewusst auch einen kleinen zeitlichen Anteil für Themen einplanen, die „mal eben“ gemacht werden sollen bzw. müssen, etwa die Aktualisierung eines SSLZertifikats oder Bugfixes (Wille 2016). Bei der Priorisierung von Product-Backlog-Einträgen geht es aber nicht nur darum, in welcher Reihenfolge Produktideen implementiert werden sollen, sondern auch, bewusst zu entscheiden, ob sie überhaupt umgesetzt werden sollen: Rechtfertigt der – möglichst durch belastbare Markthinweise aus der Product Discovery erwartete – Nutzen die mit der Umsetzung verbundenen Aufwände (Gibbert 2014b; Wille 2016)?

1  Einführung in das digitale Produktmanagement

19

Die Entscheidung trifft der Product Owner im Normalfall nicht alleine, sondern in Abstimmung mit seinen wichtigsten Stakeholdern. Für sein „Standing“ ist es wichtig, dass der Product Owner dabei als aktiv handelnde Person wahrgenommen wird. D. h., dass er proaktiv „sein“ Product Backlog präsentiert, diskutiert und aligned und nicht bloß passiv darauf wartet, dass ihm von anderen die Product-Backlog-Einträge bzw. Reihenfolge der Einträge diktiert werden. Die dadurch gewonnene (laterale) Führung verschafft dem Product Owner das benötigte Standing im Unternehmen, um nicht zum Spielball mikropolitischer Interessen zu werden (siehe zum Thema Führung und Alignment ausführlich die Kap. 14 von Tobias Freudenreich und Kap. 15 von Arne Kittler). Die eigentliche Produktentwicklung findet in sog. Sprints statt. Sprints sind feste Intervalle, die je nach Unternehmen zwischen einer und vier Wochen dauern.8 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. Sprints folgen einem festen Ablauf mit mehreren Zeremonien (Meetings) sowie Artefakten (Dokumente), wie Abb. 1.8 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 Planning-Meeting zeigt der Product Owner den Entwicklern auf, wie im kommenden Sprint der Wert/Nutzen des Produkts gesteigert werden soll, und erläutert im Anschluss die einzelnen User Stories aus dem Product Backlog, die von ihm zur Erreichung des Sprint-Ziels am höchsten priorisiert wurden (Schwaber und

Aktualisierung des Product Backlog

Daily Scrums

Product Backlog

Sprint Planning

Sprint (2-4 Wochen) Sprint Backlog

Sprint Review

Retrospecve Produktinkrement

Abb. 1.8   Der Scrum-Prozess im Überblick. (Quelle: Eigene Darstellung)

8 Ursprünglich waren Sprints auf 30 Tage ausgelegt. Mittlerweile entwickeln die meisten Unternehmen jedoch in ein- bzw. zweiwöchigen Sprints.

20

S. Hoffmann

Sutherland 2020). 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.9 Sollte eine User Story für die Entwickler 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. 

Wenn unklar ist, wie eine Produktanforderung umgesetzt werden sollte, wird häufig ein sog. Spike angesetzt. Im Rahmen des Spike werden alternative (technische) Lösungen entwickelt und über Prototypen getestet. Ziel des Spike ist es nicht, bereits eine vollständig ausgearbeitete, finale Lösung zu entwickeln, sondern lediglich einen „Proof of Concept“, d. h. einen Machbarkeitsnachweis, zu erhalten.

Im Anschluss an die Vorstellung der User Stories besprechen die Entwickler untereinander, wie die einzelnen Stories umzusetzen sind und welche entwicklungsseitigen Aufgaben (Tasks) zur Umsetzung erforderlich sind. Product Owner und Entwickler „einigen“ sich zudem darauf, anhand welcher Akzeptanzkriterien am Ende des Sprints entschieden wird, ob die Umsetzung einer User Story erfolgreich war. Nicht-funktionale Anforderungen an das zu entwickelnde Produkt, wie beispielsweise Performance-Vorgaben, werden als Nebenbedingungen (englisch: Contraints) formuliert. Neben den spezifischen Akzeptanzkriterien für jede User Story sollte von einem Scrum-Team zudem eine grundlegende Definition of Done (DoD) für Sprint-BacklogEinträge vereinbart werden. Dadurch soll sichergestellt werden, dass alle ein gleiches Verständnis davon haben, wann ein entwickeltes Produkt veröffentlichungsfähig ist. Eine DoD umfasst z. B.: • Der Code wurde deployed und von einem anderen Teammitglied getestet. • Neue Features wurden von einem Designer abgenommen. • Der Code wurde dokumentiert. Im letzten Teil des Sprint Planning-Meetings findet eine Aufwandsschätzung (englisch: Sizing) der einzelnen User Stories durch die Entwickler statt. Der Aufwand wird dabei üblicherweise in Story Points geschätzt, die relative Schätzwerte in Form einer nicht-

9 Ausnahmensweise

kann eine Story auch in den kommenden Sprint gezogen werden, obwohl sie faktisch noch nicht bearbeitbar ist, da z. B. Zugangsdaten fehlen, die aber sicher zugesagt wurden. In einem solchen Fall kann ein Product Owner die Entwickler bitten, die Story trotzdem in den Sprint aufzunehmen und dabei mit einem Hinweis zu flaggen.

1  Einführung in das digitale Produktmanagement

21

linearen Zahlenfolge darstellen: meist 0, 1, 2, 3, 5, 8, 13, 20, 40.10 Führt ein Entwicklerteam erstmalig eine Aufwandsschätzung durch, einigt sich die Gruppe zu Beginn auf eine mittelgroße Referenz-Story und gibt ihr beispielsweise den Story-Point-Wert 3. Alle weiteren Stories werden nachfolgend in Relation zu der Referenzstory bewertet. Eine verbreitete Methode zur Ermittlung der Story Points ist das Planning Poker. Jeder Entwickler erhält dabei einen Stapel Karten, auf denen die unterschiedlichen Story-Point-Werte vermerkt sind (bei einem remote stattfindenden Sprint Planning, kann das Planinng Poker auch digital mithilfe von Apps Miro vorgenommen werden.). 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 die Entwickler 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 unter den Entwicklern gefunden wurde (Pichler 2014). Dabei geht es nicht darum, auf Zwang eine Einigung herbeizuführen, sondern über die abweichenden Schätzungen in einen inhaltlichen Austausch über die Umsetzung einer User Story zu kommen, der zu mehr Klarheit und Sicherheit bei allen führt. Haben die Entwickler alle hoch priorisierten Einträge im Product Backlog geschätzt, legen sie gemeinsam mit dem Product Owner das übergeordnete Sprint-Ziel fest und verpflichten sich selber (englisch: to commit), wie viele Einträge sie im kommenden Sprint umsetzen werden. Aus der mit den jeweiligen Story Points gewichteten Anzahl der 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 (Schwaber und Sutherland 2020; Domin 2019). 

Der Product Owner gibt über die Priorisierung des Product Backlogs vor, in welcher Reihenfolge die Einträge umgesetzt werden. Die Entwickler legen mit der Aufwandschätzung fest, wie viele Einträge in einem Sprint realisiert werden.

Die von den Entwicklern für den nächsten Sprint zugesagten Einträge werden, runtergebrochen auf ihre abgeleiteten Tasks, als Tickets in das Sprint Backlog übertragen und der eigentliche Sprint kann beginnen. Das Sprint Backlog besteht im einfachsten Fall

10  Grundlage 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, gröberen Aufwandsschätzung werden für die einzelnen User Stories T-Shirt-Größen (Skala XS, S, M, L, XL, XXL) bestimmt (Wiegand 2015).

22

S. Hoffmann

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.9   Zusammenhang zwischen Product Backlog und Sprint Backlog. (Quelle: Eigene Darstellung)

aus drei Spalten, siehe Abb. 1.9. Zum Teil werden jedoch weitere Spalten für separate Entwicklungsschritte, wie Testing oder Deployment, hinzugefügt. 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 – bzw. war bis zur Corona-Pandemie – jedoch durchaus üblich, dass es zusätzlich auch ein physisches Sprint Backlog Board gibt, das im Team Space des Scrum-Teams aushängt und an dem die einzelnen Tickets auf Post-its geschrieben in den jeweiligen Spalten hängen. Das Sprint Backlog Board sorgt auf diese Weise für eine hohe Transparenz über den Sprint-Fortschritt und fördert die teaminterne Kommunikation. Ergänzend wird häufig noch ein Burn-Down(-Up)Chart 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 zumeist vom Scrum Master moderiert, folgt einer festgelegten Struktur und sollte maximal 15 min dauern. Im Daily Scrum geht es einzig darum, dass im Scrum-Team alle einen einheitlichen Informationsstand über den Sprint-Verlauf haben. Inhaltliche Diskussionen sind im Daily Scrum nicht vorgesehen.

1  Einführung in das digitale Produktmanagement



23

Die Entwickler geben im Daily Scrum ihr Update standardisiert, indem sie üblicherweise folgende drei Fragen beantworten: 1. Was habe ich gestern getan, das dem Team hilft, das Sprint-Ziel zu erreichen? 2. Was werde ich heute tun, um dem Team beim Erreichen des Sprint-Ziels zu helfen? 3. Sehe ich ein Hindernis, das mich bzw. das Team daran hindert, das SprintZiel zu erreichen? 4. (Schwaber und Sutherland 2017)11.

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, d. h. Probleme bzw. Störungen, die die Entwickler von ihrer Arbeit abhalten, und entlastet somit die Entwickler. 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 potenziell auslieferfähiges Produktinkrement (englisch: potentially releasable product increment) vorliegen (in einem Sprint können dabei durchaus mehrere Produktinkremente fertiggestellt werden). 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 2020). Jeder Sprint endet mit einem Sprint-Review-Meeting. Darin präsentiert das ScrumTeam den Stakeholdern die fertiggestellten Produktinkremente des abgelaufenen Sprints. Dies erfolgt nach Möglichkeit nicht mithilfe von PowerPoint-Folien oder Click Dummies o. ä., sondern das Ergebnis soll real am funktionierenden System vorgeführt werden. Das Produktinkrement ist zu dem Zeitpunkt aber in der Regel noch nicht allgemein veröffentlicht, sondern läuft auf einer Testumgebung. Das Sprint Review ist als Arbeitsmeeting angelegt, in dem gemeinsam festgestellt wird, ob sich das Scrum-Team auf dem richtigen Entwicklungsweg befindet, bzw. um frühzeitig ggf. notwendige Anpassungen für das Produkt zu identifizieren. Mit dem Sprint Review ist in Scrum damit ein in kurzen Zeitabständen regelmäßig stattfindendes Format verankert, in dem alle Stakeholder die Möglichkeit haben, sich über den

11  In

der Version von 2020 wurden die 3 Fragen aus dem offiziellen Scrum Guide herausgenommen. Gleichwohl dienen sie in vielen Unternehmen noch immer als Strukturierung des Daily Scrum.

24

S. Hoffmann

jeweiligen Produktentwicklungsstatus zu informieren und dem Scrum-Team Feedback zu geben. 

Die regelmäßige Präsentation und gemeinsame Diskussion der Produktinkremente dient u. a. dazu, dass sich die relevanten Stakeholder „abgeholt“ fühlen und so Vertrauen in die Arbeit des Scrum-Teams erwächst. Dies führt im Normalfall dazu, dass das Scrum-Team größere Freiheiten bei der Umsetzung seiner Tasks erhält und eher Outcome- als Outputziele bekommt. Die enge Einbindung der Stakeholder stellt damit die bessere Alternative zu den aus dem klassischen Projektmanagement stammenden, bis ins letzte Detail ausformulierten Pflichtenheften dar, zumal diese in komplexen Umgebungen eh nur eine Scheinsicherheit suggerieren.

Formale Aufgabe des Product Owners ist es am Ende eines Sprints zu überprüfen, ob die User Stories von den Entwicklern gemäß der vereinbarten Definition-of-DoneKriterien 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 das Sprint-Review-Meeting zur Veröffentlichung bereitgestellt. Am Ende eines Sprints findet zudem 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). Am Sprint-Ende wird zudem eine teaminterne Retrospektive durchgeführt. Dort reflektiert das Scrum-Team 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. 

Im Scrum Famework ist die Rolle (Verantwortlichkeit) des Scrum Masters fest in einem Scrum-Team vorgesehen. In Produktorganisationen, die nicht nach Scrum arbeiten, wird diese Person häufig auch als Agile Coach bezeichnet. Die Tätigkeiten eines Agile Coach und eines Scrum Masters sind durchaus vergleichbar. Jedoch sind Agile Coaches anders als Scrum Master typischerweise nicht Teil des eigentlichen Produktteams, sondern choachen dieses „von außen“ (auch wenn sie im selben Unternehmen angestellt sind). Da Scrum Master häufig aber auch in mehreren Scrum Teams tätig sind, verschwimmt dieser Unterschied in der Praxis, weshalb viele beide Rollen als synonym ansehen.

1  Einführung in das digitale Produktmanagement

25

Am Ende der Retroperspektive sollen konkrete Verbesserungen für eine effektivere und zufriedenstellendere Arbeitsweise vereinbart werden, deren Umsetzung im nächsten Sprint in der folgenden Retrospektive in Form einer Selbstüberprüfung kontrolliert wird (Schwaber und Sutherland 2020).

1.4 Digitale Produktentwicklung mit Kanban Neben Scrum existieren zahlreiche 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 gleichmäßigen „Fluss“ (englisch: Flow) in der Autoproduktion herzustellen und die vorhandenen Lagerbestände an Einzelteilen zu reduzieren. Vor dem Hintergrund der KaizenPhilosophie12, 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.13 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 einige Ähnlichkeiten auf. Ein wesentlicher Unterschied besteht jedoch 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

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

26

S. Hoffmann

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 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. Kanbanspezifische 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 2018). Analog zu Scrum wird auch das Kanban Board im einfachsten Fall in drei Spalten unterteilt: „To Do“, „(Work) In Progress“ und „Delivered“ bzw. „Done“. Häufig werden jedoch weitere Spalten verwendet, indem z. B. 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 die Softwareentwickler nicht völlig frei entscheiden können, welche Aufgabe als nächstes aus der Spalte „To Do“ bearbeiten sollten. 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. Dabei wird meist in „(New) Feature“ (neue Produkteigenschaft), „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 „Standard“, „Dringende Bearbeitung“, „Fester Liefertermin“ sowie „Unbestimmte Kosten“.

1  Einführung in das digitale Produktmanagement

27

Der Großteil der Aufgaben sollte als „Standard“ klassifiziert sein. Hier gilt als Bearbeitungsregel in der Regel das FiFo-Prinzip (First in, First out). Aufgaben, die als „dringend zu bearbeiten“ gekennzeichnet sind, sollten dagegen unmittelbar in Angriff genommen werden, weil sie anderenfalls zu hohen Kosten führen. Dies sollte jedoch die absolute Ausnahme sein, in der ggf. 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.14 Ist der Aufwand geklärt, kann die Bearbeitung rechtzeitig genug beginnen, um den benötigten Auslieferungstermin zu gewährleisten. 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 zudem 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. Service Level Agreements können dabei 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).

14 Analog zu Scrum erfolgt die Aufwandsschätzung zumeist in Form von Storypoints oder T-ShirtSizes, s. Abschn. 1.3.

28

S. Hoffmann

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. 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.10. Damit in Kanban der Arbeitsfluss optimal verläuft, bedarf es einer engen Abstimmung, 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 regelmäßig, häufig alle ein bis zwei Wochen, statt. Darin besprechen das Produktteam 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

Work in Progress

To Do Design In Progress

Done

Development In Progress

Done

Delivered Tesng In Progress

Done

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

1  Einführung in das digitale Produktmanagement

29

jedoch kein festes Intervall vorgesehen. Gleichwohl wirkt eine gewisse Regelmäßigkeit auf die Stakeholder vertrauensfördernd. Die Teamretrospektive schließlich hat wie in Scrum die Funktion, dass das Produktteam seine bisherige Zusammenarbeit regelmäßig Revue passieren lässt und nach Ansätzen für eine Verbesserung sucht. Die regelmäßige, schrittweise Verbesserung aus dem Kaizen-Prinzip 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 von Produktteams bzw. bei 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.5 Weitere agile Methoden im digitalen Produktmanagement Scrum als dominierende agile Entwicklungsmethode im digitalen Produktmanagement weist wie beschrieben einen relativ festen und umfassenden Rahmen an Verantwortlichkeiten und organisationalen Regeln auf. Unternehmen, die sich entschließen, Scrum einzuführen, stehen daher oft vor der Herausforderung, ihre bisherige Produktentwicklung grundlegend 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 PlanningMeeting 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 auch von „Scrum-And“ sprechen, um das Grundgerüst von Scrum sinnvoll an die jeweiligen organisationalen Gegebenheiten optimal anzupassen (Schwaber 2012). Unternehmen, für die eine strikte Anwendung von Scrum nicht (mehr) sinnvoll erscheint, orientieren sich häufig in Richtung Kanban (Anderson 2016b; Ammons 2015). Für die digitale Produktentwicklung bedeutet dies, dass in 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

30

S. Hoffmann

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). 

„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 ausschließlich anlassbezogen 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).

1  Einführung in das digitale Produktmanagement

31

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), Designdriven Development (DDD), Featuredriven Development (FDD) etc., die in der digitalen Produktentwicklung eingesetzt 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 abschließenden Überblick zu geben, erscheint aussichtslos und auch immer nur eine Zeitpunktbetrachtung. Unternehmen, die sich für ein (neues) agiles Framework entscheiden müssen, erhalten in Kap. 21 von Stefan Roock wertvolle Hinweise zur Wahl des „richtigen“ agilen Framework. Unabhängig vom konkret eingesetzten agilen Framework ist für ein erfolgreiches digitales Produktmanagement vor allem ein agiles Mindset essentiell. D. h., dass Produktmanager zwar ein gutes Verständnis für ihr Produkt und die Zielgruppe haben müssen, sie sich gleichzeitig aber auch die Haltung bewahren sollten, Produktideen stets nur als Hypothesen („Wetten“) anzusehen, deren Nutzen sich erst durch ein entsprechendes Marktfeedback ergibt.

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. Cagan, M. 2018. Inspired. 2. Aufl. New Jersey: Hoboken. Cascio, J. 2020. Facing the age of Chaos. https://medium.com/@cascio/facing-the-age-of-chaosb00687b1f51d. 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.

32

S. Hoffmann

Connor, D. 2012. Understanding, commitment, and alignment. www.connerpartners.com/ frameworks-and-processes/understanding-commitment-and-alignment. Deming, W. E. 1982. Out of the crisis. Cambridge. Dickmann, P., Hrsg. 2007. Schlanker Materialfluss mit Lean Production, Kanban und Innovationen. Heidelberg: Springer. Digital.ai. 2022. State of Agile report. 16. Aufl. https://digital.ai/resource-center/analyst-reports/ state-of-agile-report. 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. Gibbert, R. 2014a. Das MVP – Problemlösung mit minimalem Feature-Umfang. www.produktbezogen.de/das-mvp-problemloesung-mit-minimalem-feature-umfang. Gibbert, R. 2014b. First things first – Priorisierung von Ideen + Anforderungen. https://www. produktbezogen.de/first-things-first-priorisierung-von-ideen-anforderungen/. 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. Herzberg, F., B. Mausner, und B. B. Snyderman. 1959. The motivation to work. New York. 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. Kano, N., F. Seraku, F. Takahashi, und S. Tsuji. 1984. Attractive quality and must-be quality. Journal of the Japanese Society for Quality Control 14(2):14–156. Kelley, T. 2001. The art of innovation. Lessons in creativity from IDEO, America’s leading design firm. New York: Doubleday. Kempe, M. 2022. Customer Journey in a Nutshell – Eine methodische Einführung. In Integriertes Online- und Offline-Channel-Marketing, Hrsg. Kristin Butzer-Strothmann, 79–110. Wiesbaden. Knapp, J., J. Zeratsky, und B. Kowitz. 2016. Sprint: How to solve big problems and test new ideas in just five days. New York. 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.

1  Einführung in das digitale Produktmanagement

33

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. Nielsen Norman Group (NN/g). 2016. When and how to create customer journey maps. https:// www.nngroup.com/articles/customer-journey-mapping. 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. Reddy, A. 2015. The scrumban [R]Evolution: Getting the most out of agile, scrum, and lean kanban. New York: Addison. Reid Hoffmann 2017. https://twitter.com/reidhoffman/status/847142924240379904?lang=de Revella, A. 2015. Buyer personas. New Jersey: Hoboken. Ries, E., und S. Blank. 2011. The lean startup: How today’s entrepreneuers use continuous 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. 2020. Der Scrum Guide. Der gültige Leitfaden für Scrum: Die Spielregeln. https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-German.pdf. 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/State-ofScrum-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.

34

S. Hoffmann

Takeuchi, H., und I. Nonaka. 1986. The new new product development game. Harvard Business Review 64(01):137–146. Torres, T. 2021. Continuous Discovery Habits, Bend. 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. Wille, S. 2016. Sag mal… wie priorisierst du eigentlich? 10 Techniken für klare Entscheidungen. https://www.produktbezogen.de/sag-mal-wie-priorisierst-du-eigentlich-7-techniken-fuer-klareentscheidungen/.

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 sowie 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? 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

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

35

36

I. Petersen

gute Vision beschreibt, warum es das Produkt gibt und welchen Mehrwert es seinen Nutzern und der Welt bieten kann. 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 VMOSTModell 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. ◄

2  Nutzerzentrierte Produktvisionen

37

(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 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.

38

I. Petersen

(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. (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. 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. H für „Huge“ Die Produktvision sollte ein großes und anspruchsvolles Ziel formulieren. Ambitionierte und gute Ziele sind eine wichtige Motivation. 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. 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.

2  Nutzerzentrierte Produktvisionen

39

L für „Long Term“ Eine Vision sollte langfristig ausgerichtet und nicht nur kurzfristig gedacht sein. 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

40

I. Petersen

Vision Target Group

Needs

Product

Business Goals

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

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: • • • •

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.

2  Nutzerzentrierte Produktvisionen

41

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.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.

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)

42

I. Petersen

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). 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.

2  Nutzerzentrierte Produktvisionen

43

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) 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 Jobs-to-bedone-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.

44

I. Petersen

(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 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 VisionsWorkshop bereits alle gemeinsam an den Nutzerinterviews für die Jobs-to-be-doneAnalyse 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.

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 nachhalg finanziellen Nutzen?

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

2  Nutzerzentrierte Produktvisionen

45

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.

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.

46

I. Petersen

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 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  Nutzerzentrierte Produktvisionen

47

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.

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.

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

Produktstrategie – Das Fundament des Produktmanagements Christian Becker

Zusammenfassung

Eine wesentliche Aufgabe des digitalen Produktmanagements besteht darin, in einem komplexen Umfeld mit nahezu unendlichen Handlungsoptionen Entscheidungen zu treffen. Dabei ist die Festlegung auf eine Produktstrategie die wohl grundlegendste Entscheidung, die eine Produktorganisation fällen muss. Überraschend viele Unternehmen arbeiten aber ohne eine Produktstrategie – teils aus Angst davor, sich auf etwas festzulegen, teils aus Unsicherheit darüber, wie überhaupt eine Produktstrategie aufzubauen ist. Das Kapitel beschreibt, warum eine Produktstrategie notwendig ist und wie sie definiert werden kann.

3.1 Einleitung Viele Konzepte aus dem digitalen Produktmanagement werden durchaus kontrovers diskutiert. Sinn und Zweck einer Produktstrategie sind jedoch weitgehend unstrittig. Gleichzeitig gibt es aber wohl kaum ein Konstrukt, bei dem Anspruch und Wirklichkeit in der Praxis so weit auseinanderlaufen: Ein großer Teil der digitalen Produktorganisationen hat gar keine Produktstrategie und der überwiegende Rest definiert allenfalls Fragmente, die die Bezeichnung „Strategie“ nicht wirklich verdienen.

C. Becker (*)  leanproductable GmbH, Berlin, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-41880-9_3

49

50

C. Becker

Die praktischen Probleme einer Produktstrategie beginnen bereits mit dem Begriff an sich. Es existiert eine erschreckend große Anzahl von unterschiedlichen Definitionen von „Strategie“, was dazu führt, dass in Produktorganisationen entsprechend viele mehr oder weniger explizite Meinungen und Annahmen nebeneinanderstehen, was genau eine Produktstrategie sein soll. Dazu kommt eine gehörige Portion Methodenverwirrung, die einen klaren Blick auf Struktur und Inhalt einer Produktstrategie verhindert. Strategie verschwimmt zwischen Frameworks wie (Produkt) Vision, Mission, Objectives and Key Results, Value Proposition und Business Model Canvas oder wird in den Grundprinzipien des agilen Arbeitens zerrieben. Einen Weg aus der Unschärfe zu finden ist schwer, weil im täglichen operativen Hamsterrad oft die notwendige Zeit fehlt, um sich mit dem Thema Produktstrategie methodisch und inhaltlich tief genug auseinanderzusetzen. Alle Faktoren zusammen bilden einen perfekten Nährboden, auf dem „Produktstrategie“ zu etwas Ungreifbarem verkommt. Oft diskutiert, kaum definiert, aber trotzdem irgendwie da. Denn: keine Strategie zu haben, ist auch keine Option. Dieses Kapitel zeigt eine mögliche Struktur auf, um eine Produktstrategie in der Praxis zu definieren und umzusetzen. Wie immer im digitalen Produktmanagement gibt es unterschiedliche Wege und Vorlieben, um zum Ziel zu kommen. Abhängig vom individuellen Kontext eines Unternehmens und seiner Produktorganisation muss der hier beschriebene Ansatz im Zweifel angepasst werden. Viel wichtiger als das eigentliche Format ist am Ende ohnehin die aktive inhaltliche Auseinandersetzung mit dem Thema und eine bewusste Entscheidung innerhalb der Produktorganisation für eine Richtung.

3.2 Was ist Produktstrategie? Die Frage, was genau eine „Produktstrategie“ ist, kann schnell in einer längeren philosophischen Diskussion enden. Je nachdem, aus welchem Kontext heraus auf das vielschichtige Thema geschaut wird, sind ganz unterschiedliche Aspekte wichtig, die sich in unterschiedlichen Definitionen widerspiegeln und alle ihre Berechtigung haben.1 Aus dem hier relevanten Blickwinkel des Produktmanagements, das grundsätzlich alle wesentlichen Stellschrauben einer Produktorganisation beinhaltet, die über Erfolg oder Misserfolg entscheiden, bietet sich eine entscheidungsorientierte Definition an, wie sie zum Beispiel Alfred D. Chandler (1962) vorschlägt: „The determination of the basic long-term goals and objectives of [a product organization], and the adoption of courses of action and the allocation of resources for carrying out these goals.“

1  Eine umfassende Übersicht über verschiedene Definitionen findet sich bei Mainardes et al. (2014).

3  Produktstrategie – Das Fundament des Produktmanagements

51

Alfred D. Chandler folgend beinhaltet Produktstrategie also im Kern die Festlegung von grundlegenden, langfristigen Zielen („basic long-term goals and objectives“) für die Produktorganisation sowie die Ableitung eines Weges in Form von Handlungen („courses of actions“) und der notwendigen Ressourcen („allocation of resources“), um diese zu erreichen. Produktstrategie definiert also weit mehr als Funktionen oder Features.

3.3 Die Bedeutung der Produktstrategie Jeder Produktmanager zielt darauf ab, dass das Produkt ein für den Kunden wichtiges Problem löst (Desirability), dass es für das Unternehmen technisch umsetzbar ist (Feasibility), und dass sich mit dem Produkt die finanziellen Ziele des Unternehmens erreichen lassen (Viability) (Maurya 2019). Technologische Risiken verlieren zunehmend ihren Schrecken, denn digitalen Produkten sind technisch heute kaum noch Grenzen gesetzt. Selbst komplexe Funktionen sind vielfach bereits als Standardkomponenten verfügbar – oft sogar umsonst und als Open Source. Mit einer immer einfacher zur Verfügung stehenden und mächtiger werdenden Technologie und der gleichzeitig immer tiefer verankerten Digitalisierung in den Zielgruppen werden immer mehr und fragmentiertere Kundenprobleme ohne große Hürden lösbar. Als direkte Folge nimmt der Wettbewerbsdruck für digitale Produkte zu. Das digitale Produktmanagement steht also im Bereich der Desirability vor einem wachsenden Berg von Optionen und Ansprüchen, der bis zur Entscheidungsparalyse führen kann. Als zweite große Herausforderung für Produktorganisationen bleibt die Viability: Bei steigendem Wettbewerbsdruck und oft vorhandenen digitalen Netzwerkeffekten, die zu einer extremen Konzentration auf sehr wenige Gewinner führen, können die finanziellen Möglichkeiten und damit die Ressourcen nicht annähernd mit den Optionen Schritt halten, sodass eine immer größer werdende Lücke entsteht, siehe Abb. 3.1. Oponen

Ressourcen Zeit

Abb. 3.1   Die Optionen-Ressourcen-Lücke. (Quelle: Eigene Darstellung)

52

C. Becker

In diesem Umfeld ist es mehr denn je ein wesentlicher Wettbewerbsfaktor für digitale Produktorganisationen, schneller als der Wettbewerb zu lernen, welche Optionen Erfolg bringen – und welche nicht. Lernen aber kostet auch mit schlanken, agilen Methoden immer eine Menge Zeit. Deshalb fokussieren sich selbst (oder gerade) die ganz großen digitalen Unternehmen auf einige wenige strategisch wichtige Bereiche. Wer ohne eine klar definierte Kombination aus Ziel und Weg handelt, verliert sich leicht in den zahlreichen, vermeintlich attraktiv erscheinenden Optionen, macht schnell beliebige Dinge und reduziert damit die so wichtige Lerngeschwindigkeit tendenziell gegen Null. Im Kern ist die Produktstrategie also eine ganz wesentliche notwendige Bedingung, um Fokus und Richtung in einer Organisation herzustellen und sie zu befähigen, schnelle, effiziente Entscheidungen zu treffen und knappe Ressourcen zielführend einzusetzen.

3.4 Die Elemente der Produktstrategie Auch wenn die Produktstrategie im eigentlichen Sinne das festgelegte Ziel und der Weg dahin ist, so ist natürlich keine Produktstrategie ohne eine Analyse des Startpunkts denkbar. Wer nicht weiß, wo die aktuelle Position ist, wird große Schwierigkeiten haben, ein Ziel und einen Weg festzulegen und unterwegs Kurs zu halten. Da das Ziel in einer (unsicheren) Zukunft liegt, macht es zudem Sinn, in dem Entstehungsprozess der Produktstrategie weitere relevante interne wie externe Zukunftsfaktoren zu berücksichtigen, die für die Produktorganisation (angenommene) wichtige Rahmenbedingungen beschreiben und damit einen Einfluss darauf haben, welches Ziel bzw. welcher Weg am besten gewählt wird. Angesichts nahezu unendlicher Optionen bei gleichzeitig limitierten Ressourcen braucht eine effiziente Strategiefindung schließlich als letztes Element starke Leitplanken bzw. ein Produktspielfeld, um den Lösungsraum von vornherein zu begrenzen und die Komplexität beherrschbar zu halten, siehe Abb. 3.2. Produktspielfeld Zukunsfaktoren Ziel Weg Start Zeit

Abb. 3.2   Elemente der Produktstrategie. (Quelle: Eigene Darstellung)

3  Produktstrategie – Das Fundament des Produktmanagements

53

Da das Produktspielfeld naturgemäß einen massiven Einfluss auf die inhaltliche Ausgestaltung der Produktstrategie hat, wird es im Folgenden als erstes näher dargestellt, bevor die anderen vier Elemente (Startpunkt, Zukunftsfaktoren, Ziel und Weg) detaillierter beschrieben werden.

3.4.1 Das Produktspielfeld Das Produktspielfeld ist für jede Produktorganisation von fundamentaler Bedeutung, da es die grundlegende Positionierung des gesamten Unternehmens – vor allem auch im Vergleich zum Wettbewerb – auf lange Zeit definiert. Aufgrund der Tragweite drücken sich viele Unternehmen in der Praxis davor, eine Produktvision zu definieren, um mehr Handlungsspielraum und Flexibilität zu erhalten. Aber jedes gute Produkt braucht einen klaren Fokus, und ein Produktspielfeld ist eine dafür zwingend notwendige Bedingung. Die Basis für eine Definition des Produktspielfelds bilden die Vision und die Mission des Gesamtunternehmens, die idealerweise bereits vorhanden sind. Während die Vision einen relativ groben Zielzustand für die Kunden, das Unternehmen oder andere Stakeholder beschreibt, legt die Mission den grundsätzlichen Weg dorthin fest. Für das fiktive Unternehmen VetService GmbH, das im Bereich der Tiergesundheit aktiv ist, könnte die Vision zum Beispiel „Gesunde Haustiere und zufriedene Tierärzte“ sein und die zugehörige Mission „Digitalisierung aller Prozesse beim Tierarzt“. Sowohl Vision als auch Mission sind definitionsgemäß unscharf, lassen nahezu unendliche Handlungsoptionen zu und sind deshalb als Produktspielfeld für eine Produktstrategie ungeeignet. Um das Produktspielfeld zu definieren, hat sich deshalb in der Praxis das Konstrukt der Produktvision entwickelt, die sich hierarchisch der Vision und Mission unterordnet und daraus ableitet, siehe Abb. 3.3. Um ein ausreichend enges Produktspielfeld über eine Produktvision zu formulieren, gibt es verschiedene Formate (siehe Kapitel „Nutzerzentrierte Produktvision“ von Inken Petersen). Egal welche Variante am Ende gewählt wird, für die Produktstrategie bedeutend ist die Frage, ob der Handlungsraum klar genug definiert ist, um möglichst effektive Vision Mission Produktvision = Produktspielfeld

Abb. 3.3   Die Produktvision als Produktspielfeld. (Quelle: Eigene Darstellung)

54

C. Becker

­ ntscheidungen zu Inhalten der Elemente der Produktstrategie zu ermöglichen und sich E nicht in endlosen und immer wiederkehrenden Diskussionsschleifen zu verfangen, die nur unnötig Energie kosten und von der eigentlich notwendigen Arbeit ablenken. Im Folgenden wird eine relativ einfach strukturierte Frage zur Formulierung der Produktvision verwendet: Für welche Zielgruppe(n) und in welchem Kontext lösen wir mit welcher Priorität welche Probleme, um für die Zielgruppe(n) welche Ziele zu erreichen? Beispiel VetService GmbH

Für das Produkt der VetService GmbH könnte eine Produktvision auf der Basis der oben beschriebenen Vision und Mission zum Beispiel wie folgt aussehen: • Variante A: Unser VetService Produkt ermöglicht es Tierärzten, alle notwendigen Aufgaben in der Tierarztpraxis hocheffizient abzuwickeln. Auf diese Weise ermöglichen wir es den Tierärzten, ihre Zeit für die Behandlung und Betreuung ihrer Patienten zu maximieren. • Variante B: Unser VetService Produkt ermöglicht es mittelgroßen Tierarztpraxen für alle Tierarten mit Niederlassungen von 4 bis 8 Ärzten in der EU und den USA, alle Aufgaben von der Terminvereinbarung über die medizinische Behandlung, Abrechnung und Bezahlung bis hin zum Einkauf der notwendigen Materialien hocheffizient abzuwickeln. Auf diese Weise ermöglichen wir es den Tierärzten, ihre Zeit für die Behandlung und Betreuung ihrer Patienten zu maximieren. Beide Varianten der Produktvision sind bewusst unterschiedlich eng definiert, um die mögliche Bandbreite bei der Formulierung eines Produktspielfelds als Grundlage für die Produktstrategie aufzuzeigen. Wie konkret oder unkonkret eine Produktvision ist, hängt immer von den gegebenen Rahmenbedingungen der jeweiligen Produktorganisation ab. In der Variante B braucht die Produktorganisation der VetService GmbH entweder ein deutlich engeres Spielfeld, um mögliche Optionen von vornherein zu beschränken und effizient Entscheidungsprozesse zur Produktstrategie zu ermöglichen – oder aber die Rahmenbedingungen, wie zum Beispiel die Regionen, in denen das Produkt verfügbar sein soll, sind durch grundsätzliche Entscheidungen auf höherer Unternehmensebene der VetService GmbH bereits zentral vorgegeben und nicht mehr zu diskutieren. ◄ Neben einer qualitativen Beschreibung sind passende langfristige Key Performance Indikatoren (KPIs) zur Erfolgsmessung wesentliche weitere Bestandteile der Produktvision. Sie konkretisieren den qualitativen Inhalt und vereinfachen die Bewertung und Analyse des Startpunkts und die Definition des Ziels.

3  Produktstrategie – Das Fundament des Produktmanagements

55

Leider werden KPIs bei der Produktvision in der Praxis oft sträflich vernachlässigt, weil sie zum Teil sehr schwierig zu definieren sind. Es lässt sich zum Beispiel intensiv darüber diskutieren, wie die in der Produktvision angestrebte „hocheffiziente Abwicklung der Aufgaben“ aus Kundensicht am besten zu messen ist. Aber gerade weil die Diskussion über die „richtigen“ KPIs anstrengend sein kann, ist sie eine elementare Voraussetzung, um das Spielfeld für die Produktorganisation und darauf aufbauend die gesamte Produktstrategie sauber zu definieren.

3.4.2 Der Startpunkt Der Startpunkt als Element der Produktstrategie beinhaltet alle wesentlichen Zahlen, Daten, Fakten, aber natürlich auch Annahmen, die zur Analyse und Bewertung der aktuellen Situation der Produktorganisation notwendig sind. Gemäß der hier verwendeten Definition von Produktstrategie, die sich aus dem Produktmanagement ableitet, sind dabei neben dem Produkt an sich auch andere Stellschrauben zu betrachten, die notwendig sind, um das Produkt zu bauen. Wer sich im Vorfeld genügend Zeit genommen hat, um das Produktspielfeld sauber mit Hilfe einer Produktvision und den zugehörigen KPIs zu definieren (und diese natürlich auch zu messen), sollte es leicht haben, die wesentlichen Daten zum Startpunkt des Produkts zu beschreiben. Zudem werden mögliche inhaltliche Lücken der Produktvision schnell klar, wenn zum Beispiel eine Region (EU oder USA) bislang noch nicht adressiert wurde. Hinzu kommen Metriken, die sich aus der zugrunde liegenden Mechanik des Geschäftsmodells ergeben (z. B. Conversions oder Nutzungsgrad) und schließlich direkt oder indirekt zuzuordnende Finanzkennzahlen. Auch qualitative Rückmeldungen zum Produkt können für die Beschreibung des Startpunkts zum Scope wertvoll sein. Die Analyse des Startpunkts – natürlich möglichst immer im Vergleich zum relevanten Wettbewerb – ist ein effektiver Gradmesser für Klarheit und Fokus innerhalb der Produktorganisation. Wenn die genannten Datenpunkte für die Produktstrategie nicht schnell und transparent verfügbar sind, lohnt es sich eigentlich immer, vor den weiteren Schritten die Zeit zu investieren, um die dafür notwendigen Strukturen aufzubauen. Wenn das Fundament nicht steht, wird die Produktstrategie zwangsläufig wackelig und das eigentliche Ziel verfehlt. Etablierte Produkte und solche, die neu am Markt sind, kämpfen bei der Analyse des Startpunkts mit umgekehrten Herausforderungen: Eine längere Historie bringt den Vorteil, mehr und differenzierte Daten zur Verfügung zu haben, birgt aber die Gefahr, vor lauter Informationen den Blick für das Wesentliche zu verlieren. Junge Produkte hingegen sind zwangsläufig fokussierter, haben im Zweifel jedoch nicht genügend Messpunkte, um überhaupt datengetrieben arbeiten zu können. Die anderen Elemente des Produktmanagements werden im Rahmen der Startpunktanalyse häufig vergessen, weil sich schnell alle Blicke auf das Produkt richten. Dabei

56

C. Becker

sind die in der Produktorganisation arbeitenden Menschen, deren Fähigkeiten, das zur Verfügung stehende Budget und nicht zuletzt auch die zugehörigen Prozesse in der Operationalisierung erst die Voraussetzung, um Produkte bauen zu können – und diese lassen sich gleichzeitig nur sehr langfristig ändern. Eine realistische Einschätzung zu diesen Startpunktfaktoren ist daher eine ganz wesentliche und notwendige Bedingung für die Definition von effektiven Produktstrategien.

3.4.3 Die Zukunftsfaktoren Sicher eintretende bzw. angenommene zukünftige Ereignisse können im Zweifel einen großen Einfluss auf Entscheidungen zum Ziel und zum Weg der Produktstrategie haben. Je nach Produkt und Branche kann die Analyse dieser Zukunftsfaktoren ganz unterschiedliche Aspekte beinhalten. Typische Faktoren sind Änderungen im Wettbewerb, wie zum Beispiel die Neuausrichtung bestehender oder der Markteintritt zusätzlicher Wettbewerber, die Entwicklung des Zielmarktes (für die VetService GmbH z. B. die Anzahl der Haustiere), allgemeine makroökonomische Entwicklungen, rechtliche Vorgaben (z. B. Bestimmungen, wer überhaupt tierärztliche Leistungen anbieten kann) oder auch – zunehmend seltener – technologische Sprünge. Da Zukunftsfaktoren naturgemäß überwiegend unsicher sind, bietet es sich an, unterschiedliche Szenarien zu entwickeln, indem die relevanten Faktoren in ihren Ausprägungen miteinander kombiniert und mit groben Wahrscheinlichkeitswerten hinterlegt werden. Um die Komplexität dabei in Grenzen zu halten und sich auf das Wesentliche zu konzentrieren, hilft oft der Blick zurück auf die Entwicklung der eigenen Produktorganisation und die Faktoren, die in der Vergangenheit wirklich einen Unterschied gemacht haben. Alternativ können auch Erfahrungswerte zu Entwicklungen von anderen Unternehmen, die in einer ähnlichen Ausgangslage gewesen sind, wichtige Erkenntnisse liefern.

3.4.4 Das Ziel Das Ziel der Produktstrategie steht für sich, ist aber niemals ohne den Kontext der hierarchisch übergeordneten Ziele sowie der Strategie des Gesamtunternehmens denkbar. Je nach Fokus der Gesamtstrategie können (Teil)Ziele der Produktstrategie sogar schon explizit vorgegeben sein. In der Regel sind die strategischen Gesamtziele jedoch auf die möglichen Hebel der Produktorganisation weiter herunterzubrechen. Da das in der Einleitung geschilderte Problem der fehlenden Strategie nicht exklusiv im digitalen Produktmanagement anzutreffen ist, sondern in der Praxis mindestens genauso häufig für die Gesamtunternehmensstrategie gilt, besteht oft die Herausforderung, das Ziel der Produktstrategie ohne einen übergeordneten strategischen Rahmen definieren zu müssen. Im Zweifel entsteht das Ziel der Produktstrategie also vor

3  Produktstrategie – Das Fundament des Produktmanagements

57

denen der Gesamtunternehmensstrategie, sollte aber natürlich nicht ohne eine intensivere Diskussion mit dem Unternehmensmanagement entschieden werden. Ziele für die Produktstrategie benötigen immer einen klaren zeitlichen Bezug und können grundsätzlich über alle Handlungsfelder des Produktmanagements definiert werden: Produkt und Ressourcen sowie die zugehörigen Prozesse in der Operationalisierung. Das Ziel der Produktstrategie beeinflusst die gesamte Produktorganisation langfristig und bestimmt, wo ein Großteil der zukünftigen Zeit und Energie investiert werden. Daher muss der Anspruch bestehen, sich mit der Zielerreichung einen nachhaltigen Wettbewerbsvorteil zu erarbeiten: „The essence of strategy is to perform activities differently than rivals do.“ (Porter 1996). Der Unterschied kann dabei über die inhaltliche Ausrichtung des Ziels (das Was) und/oder das definierte Zielniveau (wieviel von dem Was) erreicht werden. Um das Ziel greifbar zu machen und die unterstellte Logik für den angestrebten Wettbewerbsvorteil besser herauszuarbeiten, ist es von Vorteil, das Ziel als Wenn-Dann-Sätze zu formulieren: „Wenn wir das Ziel A bis zum Zeitpunkt B erreicht haben, dann haben wir den Wettbewerbsvorteil C, weil …“. Beispiel VetService GmbH

Je nach Komplexität der Rahmenbedingungen kann die Menge an potenziellen Zielen und inhaltlichen Ausrichtungen ganz unterschiedlich sein. Für die VetService GmbH könnten sich zum Beispiel die folgenden relevanten Zielszenarien ergeben: • Wenn die Anzahl unserer Kunden in Frankreich, Italien und Spanien in den nächsten 12 Monaten um 50 % gestiegen ist, dann haben wir in den stärksten Wachstumsmärkten Europas gegenüber unserem Hauptwettbewerber einen nachhaltigen Größenvorteil, der es uns erlaubt, schneller und mehr in die weitere horizontale und vertikale Abdeckung des Tierarztprozesses zu investieren und darüber unseren Vorsprung im Produkt weiter auszubauen. • Wenn wir in den nächsten 6 Monaten die technischen Voraussetzungen für eine Lokalisierung der Tierarztkernprozesse realisiert haben, dann haben wir die notwendige Bedingung für die in der Gesamtunternehmensstrategie geplante Internationalisierung in das europäische Ausland geschaffen. • Wenn wir den durchschnittlichen Zeitbedarf für den Teilprozess „Rechnungsstellung“ für unsere Tierärzte in den nächsten 9 Monaten um 75 % reduziert haben, dann haben wir in einem für unsere Kunden langfristig sehr wichtigen Bereich die Zufriedenheit um 25 % gesteigert und einen signifikanten Vorteil gegenüber unserem Hauptwettbewerber erreicht. • Wenn wir es in den nächsten 8 Monaten geschafft haben, die Dauer für einen Lernzyklus (von der Definition des Experiments auf Basis der aktuellen kritischen Annahmen über die Durchführung bis zur Auswertung und Ableitung der Hand-

58

C. Becker

lungsempfehlung) im Durchschnitt von 4 auf 2 Wochen zu halbieren, dann werden wir bei der Kundenzufriedenheit gegenüber unserem Hauptwettbewerber einen dauerhaften Vorteil herausarbeiten können. • Wenn wir in den nächsten 6 Monaten eine Schnittstelle zu unserem strategischen Partner A umgesetzt haben, dann werden wir den Buchhaltungsprozess für unsere Tierärzte signifikant vereinfachen und gleichzeitig die Kosten für einen Wechsel zu einem anderen Produkt so erhöhen, dass der Customer Lifetime Value langfristig um 50 % steigt. ◄ Es kann im Zweifel Probleme bereiten, wirklich messbare Kausalitäten und Ziele zu formulieren, da strategische Ziele naturgemäß langfristig sind und unterschiedliche Maßnahmen in der Wirkung über die Zeit verschwimmen können. Umso mehr lohnt es sich, ausreichend Zeit zu investieren, da nur über eine wirklich intensive Diskussion die notwendige Klarheit über die möglichen Hebelkräfte verschiedener Optionen in der Produktorganisation entstehen kann. Häufig in der Praxis anzutreffende schwammige Schlagwörter („world-class UX“), KPIs ohne klare Problemstellung und Wirkungsbeziehung („Steigerung des NetPromotor-Scores um 30 %“), nackte Finanzziele („30 Mio. EUR Umsatz 2030“) oder konkrete Aufträge für einzelne Features („Baue eine native mobile App für Tierärzte“) sind als strategische Ziele ungeeignet, weil sie beliebig sind und keine klare Richtung erzeugen. Früher oder später werden schlechte strategische Ziele über zusammengestückelte Produktinkremente für jeden sicht- und spürbar. Gute strategische Ziele dagegen haben durch einen Bezug zur Produktvision und auf der Basis der Analyse des Startpunkts eine qualitative Richtung, eine klar formulierte Ursache-Wirkungs-Beziehung und sind messbar. Gleichzeitig lassen sie der Produktorganisation genug Freiheiten, um unterschiedliche Wege zum Ziel gehen zu können. Angesichts begrenzter Möglichkeiten und oft mehrerer möglicher Ziele, sind eine Bewertung, Priorisierung und Auswahl der Ziele notwendig. Welche und wie viele Ziele es konkret werden, hängt im Wesentlichen davon ab, was die Rahmenbedingungen der Produktorganisation erlauben, ohne den Fokus zu verlieren. Im Zweifel ist die Konzentration auf ein Ziel immer besser, als sich in zu vielen Zielen gleichzeitig zu verlieren.

3.4.5 Der Weg Weg und Ziel sind in der Produktstrategie notwendigerweise eng miteinander verknüpft. Oft erscheint eine scharfe Abgrenzung schwierig oder der Weg durch das Ziel bereits vorgegeben zu sein. In der bewussten Trennung von Ziel (dem Was) und Weg (dem Wie) liegt aber ein großer Wert, da bei näherer Betrachtung nahezu jedes Ziel auf unterschiedlichen Wegen erreicht werden kann. Bei begrenzten Kapazitäten kommt es darauf an, den effizientesten Weg zu wählen, um insgesamt die Lerngeschwindigkeit der Produkt-

3  Produktstrategie – Das Fundament des Produktmanagements

59

organisation zu maximieren. Werden Weg und Ziel von vornherein als ein Element behandelt, ist die Gefahr groß, in zu engen Bahnen zu denken und den effizientesten Weg zu übersehen. Als Grundlage für eine Ideenfindung für das Wie kann das Ziel als Herausforderung umformuliert werden. Da viele Ziele nicht alleine in der Hand der Produktorganisation liegen, sind dabei meist angrenzende Funktionen, wie zum Beispiel Vertrieb, Marketing und auch die Entwicklung, zu berücksichtigen. Beispiel VetService GmbH

Für die beispielhaften Ziele der VetService GmbH könnten die Fragen wie folgt aussehen: • Wie können wir es (zusammen mit Vertrieb und Marketing) schaffen, die Anzahl unserer Kunden in Frankreich, Italien und Spanien in den nächsten 12 Monaten um 50 % zu steigern? • Wie können wir es (zusammen mit der Entwicklung) schaffen, in den nächsten 6 Monaten die technischen Voraussetzungen für eine Lokalisierung der Tierarztkernprozesse zu realisieren? • Wie können wir es (zusammen mit der Entwicklung) schaffen, den durchschnittlichen Zeitbedarf für den Teilprozess „Rechnungsstellung“ für unsere Tierärzte in den nächsten 9 Monaten um 75 % zu reduzieren? • Wie können wir es schaffen, die Dauer für einen Lernzyklus (von der Definition des Experiments auf Basis der aktuellen kritischen Annahmen über die Durchführung bis zur Auswertung und Ableitung der Handlungsempfehlung) in den nächsten 8 Monaten im Durchschnitt von 4 auf 2 Wochen zu halbieren? • Wie können wir es (zusammen mit der Entwicklung) schaffen, in den nächsten 6 Monaten eine Schnittstelle zu unserem strategischen Partner A umzusetzen? ◄ Das Ergebnis der Ideenfindung ist dann in vielen Fällen wieder eine Wette. Ob der ausgewählte Weg tatsächlich zum Ziel führt, ist daher während der Operationalisierung kontinuierlich zu prüfen.

3.5 Der Entstehungsprozess der Produktstrategie Das theoretische Ideal des Entstehungsprozesses einer Produktstrategie sähe wohl so aus, dass zunächst der Startpunkt und dann die relevanten Zukunftsfaktoren analysiert werden, um daraufhin das Ziel zu definieren und als letztes schließlich den besten Weg zum Ziel festzulegen, siehe Abb. 3.4. Ein solch linearer Entstehungsprozess der Produktstrategie setzt voraus, dass von Anfang an alle notwendigen Informationen zur Verfügung stehen und jeder Schritt

60

C. Becker

Startpunkt

Zukunsfaktoren

Ziel

Weg

Abb. 3.4   Linearer Entstehungsprozess der Produktstrategie. (Quelle: Eigene Darstellung)

sauber vor dem nächsten abgeschlossen werden kann, was praktisch jedoch unmöglich ist. Zum einen gibt es viel zu viele potenziell relevante Daten, als dass sie überhaupt vollständig und valide erfasst werden könnten, und es sind Faktoren aus der Zukunft zu berücksichtigen, die per se unsicher sind bzw. sich verändern können. Zum anderen findet der Prozess nicht auf einer grünen Wiese statt, sondern immer in einem gegebenen Kontext und einem sich daraus resultierenden Bias. Insbesondere an bereits vorhandenen Ideen zum konkreten Was (Ziel) und Wie (Weg) der Produktstrategie wird es selten einen Mangel geben. In diesem Umfeld ist die Gefahr extrem groß, dass die Informationssammlung und Diskussion vorab – und wenn auch nur unterbewusst – genau so gesteuert werden, dass die bereits vorhandenen Meinungen zu Weg und Ziel lediglich bestätigt und bessere Strategien übersehen werden. Der eigentlich logisch und objektiv erscheinende lineare Prozess unterstützt und legitimiert also im Zweifel von vornherein ein suboptimales Ergebnis. Eine Alternative zum linearen Prozess ist ein bewusst heuristischer, in dem die inhaltlich eng verzahnten und sich gegenseitig beeinflussenden Elemente der Produktstrategie in keiner festen Reihenfolge und beliebig oft betrachtet werden können. So können eine Vielzahl von unterschiedlichen Betrachtungswinkeln eingenommen und alternative Szenarien entwickelt werden, bevor weitreichende Entscheidungen zur Produktstrategie getroffen werden. Auch ein heuristischer Ansatz garantiert natürlich nicht, dass das beste Ziel und der beste Weg gefunden werden, aber zumindest ist die Wahrscheinlichkeit um einiges höher. Der komplexe und unsichere Strategieprozess sollte also nicht nur die Freiheit haben, über alle wesentlichen Elemente hinweg iterieren zu können. Die Exploration unterschiedlicher Optionen sollte, wie im Modell in Abb. 3.5 dargestellt, fester und regelmäßiger Bestandteil des gesamten Prozesses sein.

Startpunkt

Zukunsfaktoren

Weg

Ziel

Abb. 3.5   Explorativer Entstehungsprozess der Produktstrategie. (Quelle: Eigene Darstellung)

3  Produktstrategie – Das Fundament des Produktmanagements

61

Die Grundidee hinter dem explorativen Entstehungsprozess der Produktstrategie ist, dass es einen neutralen Punkt außerhalb der inhaltlichen Analyse und Diskussion zu den vier Elementen gibt, wo je nach Kontext bewusst entschieden wird, welches Element als nächstes betrachtet wird – und zwar so lange und in möglichst schnellen Zyklen, bis eine Entscheidung zur Produktstrategie feststeht. Beispiel VetService GmbH

Hier sind drei Beispiele für einen explorativen Entstehungsprozess der Produktstrategie für die fiktive VetService GmbH: • Es gibt eine sehr attraktiv erscheinende Option für eine strategische Partnerschaft mit einem anderen Unternehmen (potenzieller Weg), aber wo stehen wir eigentlich gerade wirklich (Startpunkt) und wäre das Ergebnis der strategischen Partnerschaft ein lohnendes strategisches Ziel? • Aus der übergeordneten Unternehmensstrategie ist das Ziel der Internationalisierung festgesetzt. Der Weg leitet sich daraus zumindest bezüglich des Scopes relativ klar ab. Aber wie sehen eigentlich der Startpunkt zu den Ressourcen und die Operationalisierung aus, und welchen Einfluss haben diese auf den Weg? • Die Verordnung für Tierärzte wird in den kommenden 12 Monaten in weiteren europäischen Ländern dereguliert (Zukunftsfaktor). Welche lohnenden strategischen Ziele ergeben sich daraus, und ist unsere Produktorganisation dafür passend aufgestellt (Startpunkt)? ◄ Wann ist ein explorativer Entstehungsprozess einer Produktstrategie nun fertig? Und welche der entwickelten strategischen Optionen ist die beste? Jede strategische Entscheidung ist und bleibt eine betriebswirtschaftliche Bauchentscheidung, die auf Annahmen basiert. Es wird niemals sauber zu beweisen sein, dass ein längerer Prozess oder eine andere strategische Entscheidung zu besseren Ergebnissen geführt hätte, weil nicht mehrere Optionen im selben zeitlichen und inhaltlichen Kontext gegeneinander getestet werden können. Eine natürliche Reaktion, um mit der Unsicherheit umzugehen, besteht darin, über Risikobewertungen oder Erfolgswahrscheinlichkeiten eine Vergleichbarkeit herzustellen, aber auch das kann im strategischen Kontext, der sich auf die Zukunft bezieht, nur eine Pseudo-Objektivierung sein. Eine weitere Möglichkeit besteht darin, von vornherein alternative Strategien mitzudenken. Aber solche alternativen Pläne im Hinterkopf bergen auch die Gefahr, dass dann überhaupt keine strategische Richtung mit der notwendigen Energie verfolgt wird und die Strategie verwischt. Sinnvoller erscheint es, nach der Festlegung einer Produktstrategie eine regelmäßige Bewertung im Rahmen der Operationalisierung vorzunehmen und im Zweifel die Strategie zu ändern, wenn es notwendig ist.

62

C. Becker



Die Definition einer Produktstrategie ist ein bewusster Entscheidungsprozess und erfordert Mut. Nichts ist für eine Produktorganisation schlimmer als strategische Unsicherheit.

3.6 Die Operationalisierung der Produktstrategie Die beste Produktstrategie ist ohne ihre Umsetzung nichts wert. Das Problem dabei ist, dass die Umsetzung einer Strategie noch einmal deutlich schwieriger ist als die Definition: „Strategy is a commodity, execution is an art.“2 Der Operationalisierung der Produktstrategie kommt also eine ganz besondere Bedeutung zu, und ein Verständnis ihrer Hürden ist für jede Produktorganisation essentiell. Nach Stephen Bungay (2010) gibt es davon zwei: das „Alignment Gap“ und das „Effects Gap“.

3.6.1 Das Alignment Gap Das Alignment Gap beschreibt den Unterschied zwischen dem, was die Produktorganisation gemäß der Strategie eigentlich tun soll, und dem, was dann tatsächlich umgesetzt wird. („The difference between what we want people to do and what they actually do.“). Mögliche Gründe, warum der geplante Weg nicht ausgeführt wird, gibt es in einer Organisation viele: unklare und missverständliche Kommunikation der Strategie zwischen Sender und Empfänger, zu viele parallele Projekte oder unerwartete Ereignisse, durch die der Fokus verloren geht, eigene Meinungen, Kontexte und Pläne in den Umsetzungsteams oder auch ganz einfach zwischenmenschliche Probleme. Produktorganisationen, die einem strukturierten Entstehungsprozess bei der Definition der Produktstrategie folgen und die Schlüsselpersonen der Organisation dabei einbeziehen, können das Alignment Gap von vornherein verringern. Die Erfahrung in der Praxis zeigt aber, dass im Laufe der Zeit Verständnis und Wahrnehmung von Produktstrategien selbst in relativ kleinen Organisationen oftmals auseinanderlaufen und nur durch weitere bewusste Maßnahmen während der Umsetzung wieder zusammengeführt werden können. Dies gilt umso mehr in bewusst lose gekoppelten Organisationen, in denen weitgehend autonome Teams eigenverantwortlich arbeiten – aber natürlich trotzdem der vorgegebenen strategischen Linie folgen müssen, um nicht im Chaos zu enden. Als zentrales Mittel zum Alignment schlägt Bungay (2010) das Prinzip des „Briefing and Backbriefing“ vor, bei dem alle relevanten Stakeholder in regelmäßigen Abständen die Ableitung und Inhalte der Strategie aus ihrem spezifischen Kontext heraus darstellen, wiederholen und spiegeln, um über eine intensive und sehr regelmäßige Kommunikation

2 Das

Zitat wird allgemein Peter F. Drucker zugeordnet – auch wenn es nicht in seinen Büchern gedruckt steht und sich auch keine andere gesicherte Quelle finden lässt.

3  Produktstrategie – Das Fundament des Produktmanagements

63

möglichen Missverständnisse vorzubeugen. Wesentliche Grundlage für das Briefing und Backbriefing ist eine sauber dokumentierte Herleitung der Strategie. Sehr hilfreich kann auch das Format der „Auftragsklärung“ sein, in dem alle wesentlichen Elemente und Argumentationen aus dem Entstehungsprozess der Strategie zentral zusammengefasst und nachverfolgt werden können (vergleiche Kapitel XY Alignment von Arne Kittler).

3.6.2 Das Effects Gap Das Effects Gap beschreibt den Unterschied zwischen dem, was als kausales Ergebnis der Handlungen erwartet wird, und dem, was dann tatsächlich in der Realität passiert. („The difference between what we expect our actions to achieve and what they actually achieve.“) Auch beim Effects Gap handelt es sich wie beim Alignment Gap um eine fundamentale, empirische Wahrheit, die nicht wegzudiskutieren ist. Egal wie gut die Umsetzung ist, der Plan wird den Kontakt mit der Realität nicht überleben. Auch das Effects Gap ist deshalb als feste Rahmenbedingung bei der Operationalisierung einer Produktstrategie zu berücksichtigen, wobei das Gap gleich auf zwei Stufen auftritt, da sowohl der Weg nicht zum gewünschten Ziel, als auch das Ziel nicht zum angestrebten strategischen Wettbewerbsvorteil führen müssen. Zum Glück ist die Antwort auf das Effects Gap bereits im agilen Produktmanagementansatz angelegt. Wer das große Ganze auf der Basis einer kontinuierlich gepflegten und priorisierten Liste von kritischen Annahmen in möglichst kleine Inkremente unterteilt und kontinuierlich Hypothesen-getrieben testet, wird frühzeitig Abweichungen erkennen und in der Lage sein, gegenzusteuern – je nach Auswirkung über einen neuen Weg zum Ziel, oder aber, bei zu stark veränderten Rahmenbedingungen, durch eine komplette Neuausrichtung des Ziels.

Literatur Bungay, S. 2010. The art of action: How leaders close the gaps between plans, actions and results. Boston: Nicholas Brealey Publishing. Chandler, A. D. 1962. Strategy and structure: Chapters in the history of the American industrial enterprise. Cambridge: MIT Press. Mainardes, E. W., J. J. Ferreira, und M. L. Raposo. 2014. Strategy and strategic management concepts: Are they recognizes by management students? Ekonomika a Management 17(1):43–61. Maurya, A. 2019. Lean startup, or business model design, or design thinking? Is the wrong question. https://medium.com/lean-stack/lean-startup-or-business-model-design-or-design-thinking-is-thewrong-question-f84216fad869. Porter, M. E. 1996. What is strategy? Harvard Business Review 74(6):61–78.

64

C. Becker

Christian Becker unterstützt Unternehmen, schnell und planbar von der ersten Idee bis zum validierten digitalen Produkt und Business Modell zu kommen. Schwerpunkte sind dabei Produktstrategie, User Research, Konzeption und Testing – als Coach, eingebettet in Teams oder in Interimspositionen. Bevor er vor 2013 Jahren sein eigenes Unternehmen gründete, leitete er das Produktmanagement-, UX- und Content- Team bei mobile.de. Kontakt: [email protected]

4

Produktstrategie umsetzen und validieren mit Objectives und Key Results (OKR)

Ein Framework zum Navigieren in komplexen Welten Cansel Sörgens Zusammenfassung

Objectives und Key Results (OKR) als Framework verspricht mehr Fokus, Transparenz und vor allem Alignment in einer Organisation. Innerhalb der letzten zehn Jahren ist die Popularität von OKR rasant gestiegen und sein Einsatz im digitalen Produktmanagement ist mittlerweile unverzichtbar. Denn Objectives und Key Results ermöglicht eine kundschaftzentrierte Denkweise, indem die Produktentwicklung auf die erzeugte Wirkung und Resonanz bei der Zielgruppe und nicht mehr nur auf die Umsetzungsgeschwindigkeit fokussiert. Außerdem fördert OKR, wenn richtig eingesetzt, dass die kontinuierliche Strategieentwicklung und -umsetzung Teil des beruflichen Alltags von allen Beteiligten in einer Organisation wird. In diesem Kapitel werden die Wirkprinzipien beleuchtet und es wird beschrieben, wie die Anwendung des OKR-Frameworks in der Praxis einer Produktorganisation aussieht.

4.1 Worum geht es bei Objectives und Key Results? Objectives und Key Results (auf Deutsch „Ziele und Schlüsselergebnisse“) ist ein Framework, das Organisationen dabei hilft, eine Vision und Strategie umzusetzen, indem alle Beteiligten kollaborativ ihre Kapazitäten auf priorisierte Themen und messbare Ergebnisse ausrichten, in kurzen Iterationen fokussiert daran arbeiten, um

C. Sörgens (*)  Köln, Deutschland E-Mail: [email protected] © Springer Fachmedien Wiesbaden GmbH, ein Teil von Springer Nature 2023 S. Hoffmann (Hrsg.), Digitales Produktmanagement, https://doi.org/10.1007/978-3-658-41880-9_4

65

66

C. Sörgens

s­ chnellstmöglich die Lösungsideen zu validieren, und daraus lernen, ihre Herangehensweise an strategische Themen kontinuierlich zu verbessern. Objectives und Key Results (OKR) gibt eine Orientierung, um in der Komplexität zu navigieren, indem abstrakte Themen greifbar gemacht werden und durch messbare Ergebnisse überprüft wird, ob der einmal gewählte Weg immer noch der richtige ist. „We start our journey to our dreams by wanting, but we arrive by focusing, planning and learning.“ (Wodtke 2016, S. 102)

OKR besteht aus zwei Elementen, die als Set zu betrachten sind und nicht voneinander getrennt werden sollten: Während ein Objective die inhaltliche Richtung vorgibt, konkretisieren die Key Results den Weg dorthin.  Objective ist eine qualitative Beschreibung eines angestrebten und zeitgebundenen Ziels, das zur Umsetzung einer Vision bzw. Strategie beiträgt.  Key Results sind quantitative Beschreibungen, die das Erreichen des Objectives messbar machen. Objective: User können das Produkt plattformübergreifend nutzen

• Key Result 1: Die Nutzung auf mobilen Geräten wurde um 50 % erhöht. • Key Result 2: Daily Active User (DAU) wurden um 30 % erhöht. • Key Result 3: Die Nutzenden auf den mobilen Geräten sind 50 % aktiver. ◄ Objective: Mit der neuen Website erzeugen wir Aufmerksamkeit für das Thema „Diversität in Unternehmen“

• Key Result 1: 30 % der Besuchenden kehren innerhalb von 5 Tagen zurück. • Key Result 2: 10 % der Besuchenden kontaktieren uns für mehr Infos. • Key Result 3: Der Hashtag der Kampagne wurde 5000 Mal erwähnt. ◄ Der Ursprung von OKR geht zurück bis in die 1950er Jahre. Peter Druckers (1954) Methode „Management by Objectives“ (kurz MbO) war in mehreren Unternehmen im Einsatz, so auch bei Intel. Als Intel in den 1970er Jahren mit wirtschaftlichen Problemen zu kämpfen hatte, entschied Andy Grove, damaliger CEO von Intel, das bestehende Managementsystem anzupassen, um die Adaptionsfähigkeit seines Unternehmens zu erhöhen. Aus jährlichen wurden vierteljährliche Ziele, um mit kurzfristigen Objectives eine klare Richtung und Fokus zu definieren, die immer zu den aktuellen Umständen passten. Außerdem ergänzte Grove die Objectives mit konkreten, messbaren Schlüsselergebnissen (Key Results), um erzielte Fortschritte greifbar zu machen. Diese angepasste Form von MbO gilt als Ursprung von OKR.

4  Produktstrategie umsetzen und validieren mit Objectives …

67

John Doerr, damals Intel-Mitarbeiter, später Investor im Silicon Valley, stellte 1999 den beiden Google-Gründern Larry Page und Sergey Brin das OKR-Framework vor, und seitdem arbeitet Google mit OKR. 2013 veröffentlichte Rick Klau, damals YouTube-Produktverantwortlicher, ein Video (Klau 2013), in dem er erklärte, wie Google mit OKR arbeitet. Seitdem übernehmen unzählige renommierte Unternehmen weltweit das OKR-Framework. Nicht nur große Unternehmen, wie Amazon, Spotify, Netflix, Slack, Daimler, Bosch, Telekom, haben heutzutage OKR im Einsatz, sondern auch viele Start-ups sowie kleine und mittelständische Unternehmen weltweit. Durch den Einsatz in unterschiedlichen Unternehmenskontexten und dank der Expertise von einigen einflussreichen Personen im Bereich Produktmanagement weltweit entwickelt sich OKR immer weiter, sodass Andy Groves ursprüngliche Idee von Output-Management (Grove 2015) heute stark abgewandelt wurde, und zwar Richtung „Outcomes“ (s. Abschn. 4.3.3). Wenn es um die Vorteile von OKR-Framework geht, werden i. d. R. Folgende genannt. • Fokus: Der Austausch um OKR herum erzeugt Klarheit darüber, was in der jeweils aktuellen Situation das Wichtigste ist und was nicht. Fragen wie „Wozu“, „Warum“, „Warum jetzt“ fordern die Beteiligten, sich über die Gründe zu unterhalten und gemeinsam zu entscheiden, woran sie als Nächstes arbeiten sollten. • Alignment: Die Verknüpfung der tagtäglichen Arbeit mit dem Unternehmenserfolg sorgt für einen organisationsweiten Zusammenhalt und sinnstiftende Arbeit. • Commitment: OKR fördert Strukturen, um „Aligned Autonomy“ zu ermöglichen, was die intrinsische Motivation und das Engagement der Mitarbeitenden erhöht. • Trackability: Durch messbare Ergebnisse wird kontinuierlich überprüft, ob die ausgewählten Initiativen bzw. Maßnahmen hilfreich sind oder überdacht werden müssen. • Stretch: Mit ambitionierten Zielen werden Limits gepusht, und es wird ein Raum zum Experimentieren erschaffen, in dem kreative und innovative Ideen entstehen können.

4.2 Welche Probleme löst das OKR-Framework? Die meisten der derzeit verwendeten Managementkonzepte lösen Probleme von „gestern“, als die effiziente Massenproduktion die größte Herausforderung beim Übergang von kleinen lokalen Märkten zu größeren Märkten war. Doch seit der Liberalisierung und Globalisierung der Märkte in den letzten Jahrzehnten des 20. Jahrhunderts und insbesondere seitdem das Internet die Welt mit einem Klick verbindet, spielen Entfernungen keine Rolle mehr. Aus lokalen Märkten wurde ein globales Dorf. Dieses Phänomen hat die Art und Weise, wie wir denken, konsumieren und

68

C. Sörgens

kommunizieren, stark verändert. Allerdings wurde die Art und Weise, wie wir arbeiten, vielfach noch nicht zeitgemäß angepasst. In vielen Unternehmen wird wochen- bzw. monatelang daran gearbeitet, AOPs (Annual Operating Planning), Roadmaps bzw. Projektpläne für die nächsten ein bis drei Jahre zu erstellen. Eine solch detaillierte Planung von vorgefertigten Lösungen suggeriert, dass die richtigen Lösungen bereits bekannt sind, und die internen und externen Faktoren, die auf die Umsetzung und Ergebnisse Einfluss nehmen, unter Kontrolle sind. Und obwohl dann Jahr für Jahr immer wieder festgestellt wird, dass diese Pläne bestenfalls eine Gültigkeit von drei bis sechs Monaten haben, werden diese Praktiken jedes Jahr wiederholt. Warum? Weil es ein (Schein-)Gefühl von Sicherheit und Kontrolle gibt. Gibt es eine Möglichkeit, das Gefühl von Sicherheit und Kontrolle zu haben, ohne alles akribisch vorzuplanen? Ja, die gibt es. Dafür müssen die Volatilität, Ungewissheit, Komplexität und Ambiguität (VUKA) unserer Zeit jedoch anerkannt werden und es muss akzeptiert werden, dass es nicht möglich ist, alle Lösungen und Antworten bereits im Voraus zu kennen bzw. vorhersagen zu können. Das Arbeiten mit Hypothesen sollte, wie in der Wissenschaft üblich, die neue Norm aller Organisationen werden. In komplexen Kontexten, wie Dave Snowden (2020) es im Cynefin-Framework beschreibt, ist der Zusammenhang zwischen Ursache und Wirkung nicht vorher bekannt und kann nur im Nachhinein analysiert werden. Je höher die Ungewissheit, desto höher sind die Risiken, „aufs falsche Pferd“ zu setzen. Aus diesem Grund ist es wirtschaftlich ratsam, in komplexen Umfeldern den Umsetzungsaufwand möglichst niedrig zu halten, bis der Mehrwert der Idee validiert ist. Da bei komplexen Problemen das Wissen der Fachleute allein nicht ausreicht, muss in kurzen Iterationen mit „Safe to fail“Experimenten gearbeitet werden (Probe). Danach können Hypothesen validiert werden (Sense), um aus dem Gelernten die nächsten Schritte abzuleiten (Respond). Die Arbeitsweise „Probe-Sense-Respond“ ist der Kern des OKR-Frameworks und kann daher der Rettungsring für komplexe Herausforderungen sein. Die Arbeit in kurzen OKR-Zyklen (drei bis vier Monate) durch Experimentieren (Probe), Messen (Sense) und Reflektieren (Respond) fördert eine Arbeitsweise mit Hypothesen anstatt vorgefertigten Lösungen und ermöglicht eine adaptive Umsetzung der Strategie.

4.3 Wie werden Objectives und Key Results definiert? Ein OKR-Set besteht aus einem Objective mit jeweils zwei bis drei Key Results pro Objective. Beide Elemente liefern unterschiedliche Informationen, die sich gegenseitig ergänzen. Daher sind Objectives und Key Results nicht separat zu betrachten, sondern nur zusammen erzeugen sie eine vollständige Zielbeschreibung. OKR-Sets werden idealerweise alle drei bis vier Monate definiert. Um einen Fokus zu erzeugen, sollte dabei die Anzahl der OKR-Sets limitiert werden. Nach dem Motto „Start less – finish more“ empfiehlt es sich, maximal drei OKR-Sets (3 × Objectives und

4  Produktstrategie umsetzen und validieren mit Objectives …

69

zwei bis drei Key Results pro Objective) zu definieren, denn nur fertiggestellte Lösungen können einen Mehrwert erzeugen. Bevor die Definition von Objectives und Key Results erklärt wird, muss erst verständlich werden, auf welcher Arbeitsebene, für wen und wozu OKR-Sets wertvolle Informationen liefern. OKR-Sets werden als Bindeglied zwischen (Produkt-)Vision und (Produkt)-Strategie sowie deren Umsetzung eingesetzt. Wie in Abb. 4.1 visualisiert, sind eine (Produkt-)Vision und (Produkt-)Strategie daher Voraussetzungen für wirkungsvolle OKR, so wie die OKR-Sets die Voraussetzung für die Definition der Initiativen bzw. eines Action Plans sind. 

Transparenz ist ein unverzichtbares Prinzip bei der Arbeit mit OKR. Um ein vertikales (top-down – bottom-up) und horizontales (team- und bereichsübergreifendes) Alignment zwischen Vision, Strategie und Umsetzung herzustellen, müssen alle Informationen (Vision, Strategie, OKR-Sets, Initiativen) für alle frei und uneingeschränkt zugänglich sein.

4.3.1 Mittelfristiges strategisches Ziel Die (Produkt-)Vision ist zwar eine unverzichtbare Information, aber sie ist i. d. R. recht abstrakt, sodass der Raum zur Interpretation groß ist und Teams möglicherweise in unterschiedliche Richtungen arbeiten. Um sicherzustellen, dass alle Kräfte in die gleiche Richtung kanalisiert werden bzw. sich die kurzfristigen OKR-Sets (drei bis vier Monate) aus unterschiedlichen Teams in die gleiche Richtung bewegen, braucht es ein greifbares

Vision (∞) Mielfrisges strategisches Ziel (12-18 Monate)

OKR

(3-4 Monate)

Iniaven

(1-4 Wochen)

Abb. 4.1   OKR als Teil des gesamten Bildes

70

C. Sörgens

strategisches Ziel für eine vorhersehbare Zukunft (12 bis 18 Monate), damit strategisches Alignment und Fokus hergestellt werden können. In der Praxis hat sich öfter gezeigt, dass die üblichen Business-KPI-Dashboards bzw. visionären Evergreen-Statements für ein strategisches Alignment nicht ausreichen. Das mittelfristige strategische Ziel sollte vielmehr zwei zentrale Fragen konkret beantworten, die Roger L. Martin (2013, S. 14–15) in seinem Framework „Playing to Win“ stellt: „Where to play“ und „How to win“. Das mittelfristige Ziel soll demzufolge eine Synthese aus kontinuierlichen Marktbeobachtungen, -analysen und Kontakt mit der Kundschaft sein und eine Hypothese beschreiben, wie die Kundenbedürfnisse bzw. -probleme und Markttrends Wettbewerbsvorteile verschaffen könnten. Richard Rummelt (2011) beschreibt eine gute Strategie wie folgt: „The core content of a strategy is a diagnosis of the situation at hand, the creation or identification of a guiding policy for dealing with the critical difficulties, and a set of coherent actions.“ (Rummelt 2011, S. 78)

Demnach soll das mittelfristige Ziel richtungweisend sein und Fokus erzeugen, ohne zu sagen, was genau zu tun ist, und gleichzeitig ausschließen, was nicht zu tun ist. Die strategische Klarheit hilft den Beteiligten später, im OKR-Prozess autonom Entscheidungen zu treffen, und reduziert somit den Abstimmungsbedarf Dieses kundschaftzentrierte und qualitative mittelfristige Ziel kann durch quantitative Metriken messbar gemacht werden. Neben den üblichen Business-KPIs, wie Umsätzen und Marktanteilen, ist die sogenannte North Star Metric eine ideale Ergänzung, die den Kernwert repräsentiert, den ein Produkt für die Kundschaft anbieten soll. Im „North Star Playbook“ beschreibt John Cutler (2022) die North Star Metric wie folgt: „… is the North Star Metric, a single critical rate, count, or ratio that represents your product strategy.“ (Cutler 2022)

Beispiele für die North Star Metric

• Netflix: Anzahl der Abonnierenden, die mehr als X Stunden pro Monat Inhalte schauen • Airbnb: Gebuchte Nächte • Spotify: Zeit, die ein User mit Zuhören verbringt ◄

4  Produktstrategie umsetzen und validieren mit Objectives …

71

4.3.2 Objective Ein Objective wird aus dem mittelfristigen strategischen Ziel abgeleitet und ist eine qualitative Beschreibung eines angestrebten Zielzustandes. Die Objectives geben Orientierung und sind aktivierend. Wie in Abb. 4.2 dargestellt, beschreibt ein Objective eine konkrete Veränderung, die einen Mehrwert für eine bestimmte Zielgruppe liefert und am Ende eines OKR-Zyklus sichtbar erlebbar wird. Das Objective wird von dem (Produkt-)Team selbst definiert, das auch daran arbeiten und es innerhalb der nächsten drei bis vier Monate selbstständig umsetzen kann. Folgende Fragen können helfen, die relevantesten Objectives zu identifizieren: • „Warum ist das wichtig/wichtiger?“ • „Warum ist es jetzt wichtig?“ • „Zahlt die Idee auf die (Produkt-)Vision und (Produkt-)Strategie ein?“ • „Wenn an den ein bis drei Objectives gearbeitet wird, welche anderen Themen müssten dafür gestoppt bzw. verzögert werden?“ Diese Fragen helfen nicht nur dabei, die Anzahl der OKR-Sets zu limitieren, sondern fördern auch einen wertvollen Austausch über situationelle Wahrnehmung. Es empfiehlt sich, ambitionierte Objectives zu definieren, damit die Beteiligten ihre Grenzen herausfordern und auch unkonventionelle Ideen ausprobieren, damit kreative und innovative Lösungsideen entstehen können. Ob ein Objective ambitioniert genug ist, sollte die Entscheidung des (Produkt-)Teams allein sein.

Was möchten wir erreichen / verändern / neugestalten?

Objecve Qualitave Beschreibung eines angestrebten Zieles, das zur Umsetzung der Strategie beiträgt. • • • • • • •

Movierend Akvierend Beschreibt eine Veränderung Zielgruppenorienert Ambioniert und realissch Durch das Team umsetzbar Zeitraum: 3-4 Monate

Mehrwert

Veränderung Zum Beispiel Erschaffen Opmieren Lösen

• • •

• • • • •

Zielgruppe

(Warum)

(Was)

• • •

Zum Beispiel Ermöglichen Vereinfachen Befähigen

(Wer)

• • •

Zum Beispiel Kundscha‡ Nutzerscha‡ Kollegscha‡

Beispiele User können das Produkt pla”ormübergreifend nutzen. Mit der neuen Webseite erzeugen wir Aufmerksamkeit auf das Thema „Diversität“ in Unternehmen. Unsere Kundscha‡ ist von dem vereinfachten Checkout-Prozess begeistert. Besuchende des Online-Shops lieben das neuen SSO-Login Das Führungsteam versteht die Wirkprinzipien von OKR und bezieht die Teams in die strategische und taksche Entwicklung der Strategie ein, damit das Engagement verbessert wird.

Abb. 4.2   Wie werden Objectives definiert?

72

C. Sörgens



Objective ist nicht ein neuer Begriff für ein Projekt, sondern beschreibt im OKRZusammenhang den Mehrwert, der für eine bestimmte Zielgruppe geschaffen werden soll.

4.3.3 Key Results Key Results sind quantitative Beschreibungen, die die Fortschritte beim Erreichen des Objectives messbar machen. Jedes Key Result deckt dabei eine andere Perspektive des Objectives ab, damit ein Gleichgewicht zwischen unterschiedlichen Aspekten hergestellt wird. Wie in Abb. 4.3 dargestellt, sollte ein Key Result typischerweise folgende Frage beantworten: „Wie können wir messbar beobachten, ob bzw. inwiefern das Objective erreicht wird?“ Folgende fünf Kriterien helfen bei der Definition von guten Key Results. 1. Wirkungsorientierung – Output vs. Outcome Wenngleich ursprünglich Key Results die messbaren Schritte zum Erreichen des Objectives waren, etabliert sich mittlerweile eine wirkungsorientierte Denkweise. Danach sollte ein Key Result nicht die Produktivität bzw. Performance messen, sondern die Effektivität bzw. Wirkung von Maßnahmen. Zwei Begriffe haben sich mittlerweile in dem Zusammenhang etabliert, um den Unterschied zwischen Produktivität und Wirkung zu verdeutlichen:

Woran erkennen wir, ob wir es erreichen bzw. erreicht haben? Verhaltensveränderung

Key Results Quantave Beschreibungen, die das Erreichen des Objecves messbar machen. • • • • • • •

Wirkungsorienert (Outcome) Messen zum Lernen Beeinflussbar durch das Team Konnuierlich messbar Keine Impact-orienerten KPIs Kein Acon Plan (Output) Zeitraum: = Objecve

x% aus der [Zielgruppe] verwenden [Produkt / Feature]

• • • • •

Wirkung • Die Nutzung von [Feature] ist von x auf y gesegen. • Conversion rate der Touchpoint A ist um x% erhöht.

Resonanz

Die Reviews von [Produkt / Feature] sind von 3,5 auf 4 Sterne gesegen.

Beispiele Die Nutzung auf mobilen Geräten wurde um 50% erhöht . 60% der Kundscha nutzt den neuen Service. 20% der Kollegscha nimmt an der Infoveranstaltung teil. 20 % der Nutzenden, die Feature X verwenden, bezahlen. 80% der Besuchenden, die den neuen Onboarding-Prozess durchlaufen, werden zu akven Nutzenden.

Abb. 4.3   Wie werden Key Results definiert?

4  Produktstrategie umsetzen und validieren mit Objectives …

73

1. Output: Das Erzeugnis, das Gelieferte bzw. Produzierte 2. Outcome: Die Wirkung, Resonanz bzw. Verhaltensveränderung Joshua Seiden (2019) beschreibt in seinem Buch „Outcomes over Output“ ein Outcome wie folgt: „Outcome is a change in human behaviour that drives business results.“ (Seiden 2019, S. 12)

Das Gelieferte bzw. Produzierte ist zwar ein konkretes Ergebnis, allerdings ist die Nutzung der Erzeugnisse (Output) nicht immer gesichert. Deswegen ist es problematisch, den Output allein dadurch zu steuern, indem einem Produktteam vorgeschrieben wird, was es machen soll. Vielmehr sollten der erwartete Mehrwert bzw. die Wirkung des Outputs im Mittelpunkt stehen. Wenn also ein Produktteam aufgefordert wird, eine bestimmte Wirkung bzw. ein bestimmtes Verhalten bei der Kundschaft zu erzeugen bzw. zu verändern, befähigt dies das Produktteam, freier an adäquaten Lösungen zu arbeiten, die diesen gewünschten Mehrwert auch liefern. 

Durch Outcome-orientierte Key Results steht für das Produktteam die Wirkung ihrer Arbeit mehr im Fokus und nicht bloß die Anzahl oder die Umsetzungsgeschwindigkeit der gelieferten Features.

Während z. B. ein Output-orientiertes Key Result wie „Fünf Blogposts geschrieben“ nur die Produktivität messbar macht, würde ein Outcome-orientiertes Key Results wie „Blogposts wurden 100-mal geteilt“ die erzeugte Wirkung bzw. Resonanz bei der Leserschaft in den Fokus stellen. 2. Messen, um zu Lernen Es sollte vermieden werden, dass die Metriken in Key Results zum Selbstzweck werden. Das heißt, es sollte nicht das Erreichen einer Metrik das Ziel sein, sondern wichtig sollte sein, was diese Metriken über die Wirkung der Arbeit signalisieren. „When a measure becomes a target, it ceases to be a good measure.“ (Goodhart’s law Wikipedia o. J.)

Goodharts Gesetz beschreibt: Wenn eine Metrik zu einem Ziel wird, verliert sie ihre Wirkung als Metrik, weil dann nicht die tatsächliche Wirkung im Vordergrund steht, sondern das Erreichen des Ziels um jeden Preis (Wikipedia o. J.). Die Key Results sollen vielmehr dabei helfen, in komplexen Kontexten zu navigieren, um trotz Ungewissheit Sicherheit zu gewinnen, indem die Metriken Arbeitshypothesen validieren und darauf hinweisen, welche Art von Arbeit gut funktioniert und was bei der jeweiligen Zielgruppe resoniert. Ein nicht erreichtes Key Result kann somit genauso wertvoll sein wie ein erreichtes, wenn dadurch neue Erkenntnisse über Produkte, Kundschaft bzw. Umfeld gewonnenen wurden.

74

C. Sörgens

3. Beeinflussbar durch das Produktteam Damit ein Produktteam die Wirkung seiner Arbeit messen, reflektieren und anpassen kann – was die Kernidee der Arbeit mit OKR ist, um in komplexen Kontexten zu navigieren – sollten die Teams ihre Key Results selbst beeinflussen können. Denn wenn wochen- oder gar monatelang an einer Lösung bzw. Hypothese gearbeitet wurde, aber das Team die Ergebnisse nicht unmittelbar einsehen kann, weiß das Team nicht, ob und inwiefern seine Arbeit eine positive oder negative Auswirkung auf das Ergebnis hat. Dies bedeutet, dass das Team keine Möglichkeit zum Lernen hat, weil es nicht über Ursache und Wirkung reflektieren kann. Außerdem gibt es vermutlich nichts Frustrierenderes, als wenn die Wirkung eigener Arbeit nicht gesehen bzw. gemessen werden kann. 4. Kontinuierliche Messbarkeit Wenn Key Results zum Lernen eingesetzt werden, sollte die Wirkung der Arbeit zeitnah gemessen werden, damit validiert werden kann, was gut bzw. schlecht funktioniert bzw. wovon mehr oder weniger gemacht werden soll bzw. wann ggf. der richtige Zeitpunkt zum Pivotieren (Schwenk in der Produktstrategie/-ausrichtung) ist. Wenn ein Produktteam drei bis vier Monate an Ideen arbeitet, deren Wirkung es erst am Ende von einem OKR-Zyklus oder gar noch später einsehen kann, heißt dies, dass das Team drei bis vier Monate seine Kapazitäten für etwas eingesetzt hat, ohne zu wissen, ob es nun wirklich einen Mehrwert erzeugt hat. Um dagegen zu wirken, hilft das Konzept der Lead & Lag Measures (siehe Tab. 4.1) aus dem Buch „Die 4 Disziplinen der Umsetzung“ von den Autoren Sean Covey, Chris McChesney, Jim Huling, und Andreas Maron (Covey et al. 2016, S. 55–73). Lead-Measures, die kontinuierlich gemessen werden und die Wahrscheinlichkeit bzw. Vorhersehbarkeit der Erreichung der gewünschten Ziele erhöhen können, helfen dabei, rechtzeitig datengetriebene Entscheidungen zu treffen. Aus diesem Grund sollten eher Lead-Measures verwendet werden, wenn OKR-Sets definiert werden, um schnelles und kontinuierliches Lernen zu ermöglichen.

Tab. 4.1  Vergleich zwischen Lead- & Lag-Measures (in Anlehnung an Covey et al. 2016, S. 55–73) Lead-Measures

Lag-Measures

Zeitraum

Sagen voraus, ob und inwiefern ein Ziel erreicht wird

Zeigen, ob ein Ziel erreicht wurde

Vorhersehbarkeit

Treiben Fortschritte voran und Demonstrieren den Erfolg vererhöhen die Wahrscheinlichkeit, ein gangener Leistungen Ziel zu erreichen

Einflussfaktoren

Werden direkt vom Team beeinflusst Werden von verschiedenen Faktoren beeinflusst

Handlungsfähigkeit

Sind dynamisch anpassbar

Können nicht mehr beeinflusst werden

4  Produktstrategie umsetzen und validieren mit Objectives …

75

5. Verzicht auf Impact-orientierte KPIs Das Konzept von „Lead & Lag Measures“ hilft auch dabei, zu verstehen, dass finanzielle Unternehmensziele (Business KPIs) wie EBITDA, Umsätze, Marktanteile, etc. als Key Results nicht gut geeignet sind, weil sie a) zum Zeitpunkt der Messung die Ergebnisse der vergangenen Leistungen messen und b) zu abstrakt und außerhalb des Einflussbereichs eines Produktteams sind. Joshua Seiden (2019) erklärt in seinem Buch „Outcomes over Output“ diese Art von Unternehmenszielen mit dem Begriff Impact und betont, dass die Outcomes so ausgewählt werden sollten, dass sie möglichst den (Business) Impact positiv beeinflussen. Beispiel: Zusammenhang zwischen Output, Outcome und Impact

Die Veröffentlichung von fünf Blogposts pro Monat (Output) hilft möglicherweise, die Anzahl der Website-Besuche um 20 % zu erhöhen (Outcome), damit möglicherweise die Anzahl der Kundenanfragen und die Umsätze (Impact) um 10 % erhöht werden können. ◄

4.4 Der OKR-Zyklus Gute OKR-Sets zu definieren allein reicht nicht, denn diese müssen auch umgesetzt werden. Um an OKR-Sets zu arbeiten und die Fortschritte zu besprechen, müssen entsprechende Routinen vereinbart werden. Der in Abb. 4.4 vorgestellte OKR-Zyklus dient als Hilfestellung, um eine regelmäßige Unterhaltung zwischen den (Produkt-)Teams und Leadership zu ermöglichen, und kann je nach Kontext und Umfeld angepasst werden.

4.4.1 Workshop zur OKR-Definition Nachdem das Management bzw. Leadership die (Produkt-)Vision und das mittelfristige strategische (Produkt-)Ziel für die nächsten 12 bis 18 Monate definiert hat, können die Produktteams am Anfang eines OKR-Zyklus (Dauer drei bis vier Monate) ihre OKRSets definieren. Die zentrale Fragestellung des OKR-Definitionsworkshops ist: „Was wollen wir, als Team, im nächsten OKR Zyklus erreichen, um einen wirkungsorientierten und sichtbaren Beitrag zum mittelfristigen strategischen Ziel zu leisten?“ Für produktive OKR-Definitionsworkshops ist eine gute Vorarbeit in den Produktteams essentiell. Idealerweise sammeln Produktteams Informationen über Probleme bzw. Bedürfnisse ihrer Zielgruppe und veranschaulichen diese anhand von Customer Journeys, Touchpoint-Beschreibungen etc. für alle Teammitglieder.

Abb. 4.4   OKR Zyklus (drei bis vier Monate)

76 C. Sörgens

4  Produktstrategie umsetzen und validieren mit Objectives …

77

Im OKR-Definitionsworkshop, der in der Regel drei bis vier Stunden dauert, können die Teammitglieder sich über ihre Beobachtungen und Analysen austauschen, mögliche Strategien und Taktiken besprechen und entscheiden, worauf sie sich als Nächstes fokussieren sollten. Am Anfang des Workshops sollten alle möglichen Ideen unzensiert gesammelt werden (Divergenz), die dann im aktiven Austausch gruppiert und kategorisiert werden, um ähnliche Ideen bzw. Tendenzen zu verdeutlichen (Konvergenz). Durch die gemeinsame Diskussion wählt das Produktteam die ein bis drei wichtigsten Objectives aus und definiert anschließend die dazu passenden Key Results. Die aktive Beteilung aller Teammitglieder an diesem Workshop ist sehr wichtig, da die Perspektiven jeder einzelnen Person einen wertvollen Beitrag in die Diskussion einbringt und der Austausch über die erzielte „Wirkung“ oft als Augenöffner dient, im Gegensatz zu den üblichen Roadmap-Besprechungen. 

Eine gute Facilitation und Moderation spielen für den Ablauf aller Workshops eine große Rolle und sollten daher nicht unterschätzt werden. Aus diesem Grund sollten alle „Events“ im OKR-Zyklus von einer Person begleitet werden, die für eine gute Facilitation und Moderation sorgt und zudem mit ihrer OKR-Expertise hilft. Je nach Organisation wird diese Rolle OKR-Master, OKR-Champion, OKR-Ambassador, OKR-Shepard oder OKR-Agent genannt (s. Abschn. 4.7.3).

4.4.2 OKR-Alignment-Workshop Die Ziele des OKR-Alignment-Workshops sind vielfältig: Auf der einen Seite dient er dem Aufbau eines gemeinsamen Verständnisses der Strategie und der Auswahl an Fokusthemen für den nächsten OKR-Zyklus. Zudem hilft ein OKR-Alignment in skalierten Umgebungen, wenn zum Beispiel mehrere Sub-Produktteams an dem gleichen Produkt arbeiten, dabei, Abhängigkeiten, Synergien bzw. Dopplungen zu identifizieren. Wenn Teams feststellen, dass sie an ähnlichen strategischen Themen arbeiten, könnten sie in einem Alignment-Workshop ihre OKR-Sets miteinander verknüpfen und gegebenenfalls ein gemeinsames OKR-Set definieren. Die Erkenntnisse aus dem OKR-AlignmentWorkshop können zur Verschlankung des OKR-Systems, möglicherweise auch der Organisationsstrukturen insgesamt, genutzt werden. Idealerweise nehmen alle Teams, die gemeinsam an einem Produkt arbeiten, inkl. Infrastruktur, Marketing, Vertrieb etc., an diesem OKR-Alignment-Workshop teil. Denn ein gemeinsames Verständnis für die Strategie und Taktiken herzustellen, hilft allen Beteiligten. Formate wie ein Open Space bzw. Marktplatz funktionieren wunderbar für OKRAlignment-Workshops: Als Erstes stellt jedes Team allen Teilnehmenden kurz und knackig seine OKR-Sets vor. Währenddessen machen sich die Zuhörenden Notizen

78

C. Sörgens

(Abhängigkeiten, Synergien, Dopplungen) zu allem, was sie später diesbezüglich besprechen möchten. Danach können Räume für Breakout Sessions geöffnet werden, in denen die Team-Repräsentierenden sich gegenseitig besuchen können, um Feedback zu geben/nehmen, Lösungsideen auszutauschen, wie die identifizierten Abhängigkeiten gelöst werden könnten, oder wie sie sich gegenseitig bei der Umsetzung ihrer OKR-Sets unterstützen könnten. Nach diesen Breakout Sessions kommen alle wieder zusammen, alle Teams stellen ihre wichtigsten Erkenntnisse vor und teilen mit, welche Anpassungen sie an ihren OKRSets vornehmen werden. Die Dauer eines OKR-Alignment-Workshops variiert je nach Anzahl der Teams und Teilnehmenden stark. Bei fünf bis zehn Teams kann der Workshop zwei bis vier Stunden dauern, während er bei zehn bis 20 Teams auch einen ganzen Tag sowie bei über 20 Teams auch zwei Tage dauern kann. Nach dem OKR-Alignment-Workshop sollten die Teams in den nächsten ein bis zwei Wochen die getroffenen Absprachen mit den anderen Teams angehen, notwendige Anpassungen vornehmen und die OKR-Sets finalisieren, damit der nächste OKR-Zyklus offiziell starten kann.

4.4.3 Initiativenplanung Initiativen sind Maßnahmen, Experimente oder Lösungsideen, die innerhalb von ein bis vier Wochen umgesetzt werden können, um ein schnelles Feedback hinsichtlich ihrer Wirkung bei der Zielgruppe zu bekommen. Die Ergebnisse umgesetzter Initiativen sollten auf die Key Results der OKR-Sets einzahlen. Um gegen das Phänomen „Set und Forget“ zu wirken, ist die Initiativenplanung ein zentrales Event, in dem jedes Team die Maßnahmen und Aktivitäten für die tatsächliche Umsetzung seiner OKR-Sets plant. Wie genau dieser Termin strukturiert wird, hängt vom Team-Kontext ab. Wichtig ist, dass dieser Termin Teil des beruflichen Alltags des Teams wird. Wenn bereits TeamMeetings stattfinden, können sie um den Punkt „Initiativenplanung“ erweitert werden. Erfahrungsgemäß dauert die initiale Initiativenplanung, also das erste Meeting nach der Definition neuer OKR-Sets, ca. zwei Stunden. Danach sollte das Team sich regelmäßig treffen (z. B. alle zwei Wochen), damit die Initiativen je nach Zwischenergebnissen kontinuierlich angepasst bzw. neue definiert werden können. Die Aufgaben für die Umsetzung der Initiativen müssen innerhalb des Teams klar verteilt werden, damit alle jederzeit wissen, woran aktuell gearbeitet wird. 

Wenn das Produktteam mit Scrum arbeitet, besteht die Möglichkeit, beide Frameworks miteinander zu verknüpfen. Dazu kann das Scrum-Team seine Produktziele als OKR formulieren und das Produkt Backlog nach seinen OKR-Sets ausrichten. Die Initiativen (Epics, User Stories, Features, etc.), die in

4  Produktstrategie umsetzen und validieren mit Objectives …

79

den Sprint Plannings für die Verwirklichung der OKR-Sets definiert wurden, werden dann in den Sprints umgesetzt.

4.4.4 OKR-Check-ins Die zentrale Fragestellung in einem OKR-Check-in lautet: „Welche Fortschritte erkennen wir durch die umgesetzten Initiativen in den Key Results und was sagt dies über unsere nächsten Schritte aus?“ In OKR-Check-ins kommt das Produktteam sowie ggf. auch deren Führungskräfte zusammen, um sich über die Effektivität der Initiativen auszutauschen. Dieser Termin findet, wie die Initiativenplanung auch, regelmäßig (mindestens alle zwei Wochen) statt und sollte möglichst kurzgehalten werden (maximal 30 min). Damit der Termin effektiv ablaufen kann, muss er gut strukturiert werden und braucht eine gute Moderation. Folgende drei Fragen können für eine gute Struktur sorgen: 1. Fortschritt: Welche Fortschritte haben wir bisher gemacht? Produktteams sollten den aktuellen Stand der Key Results vor dem Termin in dem vom Team vereinbarten Tool (Excel, Miro, Jira, Wiki etc.) eintragen, damit die Veränderungen im Termin direkt eingesehen werden können und der inhaltliche Austausch darüber sofort starten kann. Hierbei kann jedes Team für sich eine Art „Erfüllungsgrad“ festhalten. Zum Beispiel: •