Digitale Transformation bedeutet, Leistungen neu zu denken, vom Kunden her. Alle wollen dieses Neue, das Dumme ist nur: Mit dem Neuen hat noch keiner Erfahrung. Es fehlt der Beleg, dass genau der gewählte Ansatz zum Ziel führt. Marktforschung hilft leider kaum weiter. Chancen bleiben ungenutzt, weil Erfolgsgarantieren fehlen. Der Vortrag zeigt anhand echter praktischer Erfahrungen, wie die Methode Lean Startup das Dilemma auflöst: Die digitale Transformation wird hier in stetem, engem Austausch mit den Kunden gestaltet. Das eigene Unwissen darüber, was Kunden nun wirklich wollen, wird zunächst akzeptiert. In kleinen, schnellen Schritten werden Minimum Viable Products erstellt, die Kunden bewerten. Damit wird sehr früh immer wieder in die richtige Richtung gesteuert. Wie man Lean Startup in großen Organisationen einsetzt, wie das Team zusammengestellt wird, wie Lean Startup zu Scrum passt – alle Aspekte sind im Vortrag berücksichtigt.

1. Auf zu neuen Ufern! Mit „Lean Startup“
den Kundengeschmack treffen.
INNOVATIONSforBANKS 2016
03. Mai 2016, Köln

2. Gestatten: Elmar Borgmeier.
Die Digitale Transformation treibt den fundamentalen
Wandel der Finanzbranche.
Sie hat weder einen klar definierten Anfang, noch ein
Ende, dafür aber einen Mittelpunkt: den Kunden.
Ihren Kunden. Ihn gilt es mit neuen Lösungen zu
begeistern. Und zwar nicht einmal, sondern immer
wieder. Banken bringen dafür andere
Voraussetzungen mit als FinTech-Startups.
ELMAR BORGMEIER
Prokurist bei der SYNGENIO AG

3. Die Agenda.
A Die Frage.
B Die Methode.
C Der Nutzen.
D Die Praxis.
E Die Erfolgsfaktoren.
Alle auf einen Blick.

4. A Die Frage.

5. A Die Frage.
Innovation
Wir alle wollen mit Innovationen erfolgreich sein.

6. Was wollen die Kunden wirklich?
Marktforschung ist hier nur begrenzt hilfreich:
Hypothetische Fragen nach Unbekanntem bringen keine belastbaren
Ergebnisse. Weil Kunden dann nicht aus Erfahrung sprechen.
Die Folge:
Innovationen gehen knapp, aber entscheidend am Bedarf vorbei.
Weil erst der Go Live zeigt, ob die Kunden richtig eingeschätzt wurden.
A Die Frage.
Wie werden die RICHTIGEN Innovationen umgesetzt?
Innovationsmanagement und Produktentwicklung.
Wandel des Kundenverhaltens in der digitalen Welt.

7. Produktentwicklung bedeutet Investition.
Sie erfordert angemessene Planbarkeit.
Bei echter Innovation ist die Planung nicht belastbar.
Weil für das wirklich Neue keine Erfahrungswerte vorliegen.
Für Innovationen werden oft große Budgets mit
unsicherem Business Case beantragt.
Die Folge: Entscheidung werden wiederholt verschoben,
de fakto wird in Vorstudien statt Entwicklung investiert.
A Die Frage.
Wie werden Innovationen RICHTIG umgesetzt?
Gesamtbank: Business Pläne, Investitionskontrolle, Stage Gates.
Innovationen: Neu. Unbekannt. Agil arbeiten. Lernen.

8. A Die Frage.
Banksteuerung vs. Agilität. Ein eingebauter Antagonismus.
Management: Business Pläne, Investitionskontrolle, Stage Gates, Vorstudien,
Go / No Go -Entscheidungen
Innovationen: Neu. Keine Erfahrungswerte. Agil arbeiten. Ausprobieren. Lernen.

9. A Die Frage.
„Immer, wenn Software entwickelt wird, gibt es einen Auftraggeber,
 der die fachliche Sicht vertritt,
 der Anforderungen stellt
 der die Umsetzung seiner Wünsche im Hinblick auf Funktionalität, Benutzbarkeit, Performance
und Qualität beurteilt.
In Scrum ist das der Product Owner.“
(zitiert nach Scrum-Master.de).
Die Sicht des Projektmanagement.

10. A Die Frage.
„Immer, wenn Software entwickelt wird, gibt es einen Auftraggeber,
 der die fachliche Sicht vertritt,
 der Anforderungen stellt
 der die Umsetzung seiner Wünsche im Hinblick auf Funktionalität, Benutzbarkeit, Performance
und Qualität beurteilt.
In Scrum ist das der Product Owner.“
(zitiert nach Scrum-Master.de).
Die Sicht des Projektmanagement.

11. B Die Methode.

12. B Die Methode.
Lean Startup
Die Methode. Von Eric Ries.

13. B Die Methode.
Ein Startup ist:
 eine menschliche Institution
 mit dem Ziel ein neues Produkt oder Service zu schaffen
 unter extrem unsicheren Rahmenbedingungen.
Auch Einheiten, die in einem großen Haus Innovationen schaffen, können in diesem Sinne Startups sein.
Allerdings sollte man die Methode dann geeignet ausprägen. Fokus ist dann die MVP-basierte
Produktentwicklung.
Wieso Startup? Wir sind doch ein etabliertes Unternehmen!

14. B Die Methode.
Validiertes Lernen. So schnell und günstig wie möglich.
1. Gib zu, dass dein Produktkonzept Annahmen enthält.
Mache Sie explizit.
2. Definiere, was minimal nötig ist, damit Kunden eigene
Erfahrungen mit dem Produkt machen können.
Und zwar so, dass du aus diesen Erfahrungen lernen
kannst, ob deine Annahmen stimmen.
3. Baue dieses Minimum Viable Product. Schnell.
4. Beobachte, wie Kunden es wirklich nutzen.
5. Lerne daraus, was funktioniert und was nicht.
6. Wiederhole den Kreis mit einem Schritt für Schritt
validerten Produktkonzept.
Minimum Viable Products – MVP.

15. B Die Methode.
Minimum Viable Products – MVP.

16. B Die Methode.
Die zentrale Entscheidung.
 Annahme bestätigt: Weitermachen!
 Die Richtung stimmt, aber das Produkt ist noch nicht gut
genug: Optimieren!
 Wir haben die Kunden falsch eingeschätzt. Unser Ansatz
überzeugt nicht.
1. Wir konnten aber eine neue Annahme erkennen, was
die Kunden überzeugen würde: Neuen Kurs definieren.
Neu Planen, neu Freigeben lassen.
In die neue Richtung gehen.
2. Oder schlicht: Die Investition stoppen.
Optimierung oder Kurskorrektur?
Lernen
Produkt weiter
optimieren
Kurs
korrigieren

17. C Der Nutzen.

18. C Der Nutzen.
Innovationen werden entscheidbar.
 Die Budgetfreigabe erfolgt schrittweise.
 Das direkte Kundenfeedback liefert die nötige Entscheidungsgrundlage für die nächste Stufe.
 Budgets steigen parallel zur zunehmenden Belastbarkeit der Planung.
Vorteile für Entscheidungsgremien

19. C Der Nutzen.
Budgets werden zielgerichteter eingesetzt.
 Frühes echtes Feedback trennt Erfolgsfaktoren von wenig relevanten Features.
 Fehlentwicklungen werden im Großen wie im Kleinen schnell gestoppt.
 Was gut ankommt, wird ausgebaut.
 Besser kann das Geld nicht investiert sein.
Vorteile für den Controller.

20. C Der Nutzen.
Das Produkt wird auf die Funktionen ausgerichtet, die für Kunden entscheidend sind.
 Der Product Owner bekommt eine Basis für seine Priorisierungen:
Echte Kundenaussagen und Messungen.
 Der Product Owner kann mit offenen Punkten umgehen – indem entsprechende Annahmen
explizit gemacht werden.
Vorteile für den Product Owner / Produktmanager.

21. D Die Praxis.

22. D Die Praxis.
Projektbeispiel.
 Projekt: SYNGENIO und Unterschied & Macher für
Postbank
 Inhalt: Vertraulich.
 Methode: MVP-Entwicklung nach Lean Startup

23. D Die Praxis.
Projektbeispiel.
Build:
 EIN Team mit allen nötigen Skills:
 Inhaltlich-fachliches Konzept.
 UI-Konzept. Design.
 Agile Entwicklung.
 Continuous Delivery.
 Dauer: 2 Wochen, später 4 Wochen

24. D Die Praxis.
MVP-Entwicklung und Agile Softwareentwicklung.
MVP MVP
Back
log
Build: Sprint MVP
Measure / Learn 1
Learn 2: Konzeption
MVP
Findi
ngs
Findi
ngs
Back
log
Variante 1
Ein Team führt die gesamte Umsetzung
des MVP in einem Sprint durch. Konzept,
Design, Programmierung,…
Variante 2
Aufteilung Produktmanagement,
Konzeption, Entwicklung in separate, aber
parallele Sprints.

25. D Die Praxis.
Beispiele für Mechanismen für MVPs:
Concierge-Tests
 Gar keine Software. Service wird komplett manuell erbracht.
Entkopplung durch Mocken von Schnittstellen
 Bis hin zur reinen Frontend-Anwendung
Vorberechnung von Daten für die Testkunden
 Auslieferung per Datei an Servlet Engine vorab
„Wizard of Oz“-Testing
 Backend-Funktionen werden manuell ausgeführt
Wie kann man Annahmen schnell testen?

26. D Die Praxis.
Projektbeispiel.
Measure:
 Nutzer-Labs – 6 bis 12 Personen
 Kunden-Labs
 Internet-Community
 Web Analytics
 Fragebogen

27. D Die Praxis.
Projektbeispiel.
Learn:
 Customer Value Proposition aktualisieren
 Entscheidung über Ausrichtung
 Planung des nächsten MVP
 Gesamtprojektplan: Internet-Umfrage rechtzeitig
vorbereiten

28. E Die Erfolgsfaktoren.

29. E Die Erfolgsfaktoren.
Annahmen wirklich explizit machen.
 Man täuscht sich öfter, als man denkt. (siehe IMVU-Story von Eric Ries.)
 Nicht unterschätzen: Das ist ein eher ungewohntes Verhaltensmuster und braucht Übung.
ALLE Kompetenzen für die Umsetzung im Team haben.
 MVPs müssen in sehr schneller Folge entstehen. Um schnell zu lernen.
 Dazu müssen alle relevanten Kompetenzen im Team sein und eng zusammenarbeiten.
 Inkl. Business Case / Fachkonzept / UI-Konzept / Design / Frontend / Backend.
Ein Team, das mitdenkt.
 MVPs sind keine Wegwerf-Prototypen. Aus der Folge der MVPs entsteht das reale Produkt. Darauf muss
das Team hinarbeiten. Fachlichkeit und IT-Architektur der Bank müssen verstanden sein.
Entscheidungskompetenz gebündelt
 Der Product Owner braucht kurze Abstimmungswege mit den Stakeholdern.
Projektsetup. Die Zutaten für ein gelingendes Projekt.

30. E Die Erfolgsfaktoren.
Sich wirklich dem Kundenfeedback stellen.
 Das Projektteam möchte sich gern bestätigt sehen. Da hört man leicht, was man hören will.
 Das killt den Nutzen der Methode. MVPs helfen nur, wenn wir den Kunden genau zuhören.
Richtig Messen. Keine „Vanity Metrics“.
 Auch bei bester Absicht findet man nicht immer gleich die aussagekräftigen Messwerte. Beispiele:
 Nur für das aktuelle MVP auswerten, nicht für die Gesamtlaufzeit.
 Besser „Anzahl Fans“ auswerten statt Durchschnittsbewertung.
Initial ist schlechtes Feedback normal
 Ein MVP ist Minimal – natürlich fehlt den Kunden anfangs einiges an Funktion. Das macht überhaupt nichts,
solange die Annahmen bestätigt werden, für die das MVP gebaut wurde.
Konzernrestriktionen berücksichtigen
 MVPs in geschlossenen Bereichen mit Pilotgruppen einsetzen.
Durchführung. MVP-Entwicklung bringt neue Handlungsprinzipien mit sich.

31. E Die Erfolgsfaktoren.
MACHEN.
Der wichtigste Erfolgsfaktor: Nicht reden, machen.
Mit MVP-Entwicklung bekommt man schneller echte Ergebnisse
als mit ewiger Vorprüfung.

32. Dankeschön!
Sie haben Fragen? Wir die Antworten.
ELMAR BORGMEIER
Elmar.Borgmeier@syngenio.de
+49 172 / 86 72 016