Am 05. + 06. Dezember fand das Design Thinking Barcamp in Berlin statt (#dtcamp14). Wie bei jeder Konferenz haben mich nicht alle Beiträge und Diskussionsrunden inspiriert, einige waren gut, wenige wirklich hervorragend, alles aus meiner subjektiven Wahrnehmung wohlgemerkt. Ein Vortrag aber hat mich selbst im Nachgang noch beschäftigt und dazu animiert, einen neuen Beitrag zu schreiben.

Im Prinzip ist das Thema nichts Neues, völlig logisch und schlüssig – wie die meisten Themen in der agilen Welt. Der Titel hieß „Fake it before you make it.“ (Mario Leupold, @leupoki) und beschäftigte sich mit dem Thema ‚Pretotyping‘. „Oh nein, welche Sau wird denn da schon wieder durchs Dorf gejagt?“ fragt sich bestimmt der ein oder andere jetzt. „Wir verstehen gerade erst, wie wir Prototypen sinnvoll in unserer Produktentwicklung einsetzen können und ganz grob, was ein MVP ist.“

Pretotyping – Um was geht’s denn?

Der Begriff ‚Pretotyping‘ und das Konzept dahinter wurden von Alberto Savoia 2009 entwickelt. Während seiner Zeit als Director Engineering und ‚Innovation Agitator‘ bei Google war er unter anderem verantwortlich für die Entwicklung und den Launch von Google AdWords.

„Pretotyping is an approach to developing and launching innovation that helps you to determine if you are building the right it before you invest a lot of time and effort to build it right. Pretotyping helps you to fail … but fast enough and cheaply enough that you have time and resources to try something different.“ (http://pretotyping.blogspot.de/p/what-is-pretotyping.html)

Oder noch plakativer: „Make sure you’re building the right “it” before you build it right.“ Es geht also darum, so früh als möglich herauszufinden, ob eine Produktidee überhaupt die angenommene Marktfähigkeit besitzt, um dadurch ein hohes finanzielles Risiko für das Unternehmen auszuschließen. Beispiele dafür gibt es genug:

• DropBox: veröffentlichte vor der ersten Zeile Code ein einfaches Video, um das Prinzip des File Sharings zu erklären und damit herauszufinden, ob das mögliche Produkt überhaupt auf Resonanz stößt.
• Zappos: ermittelte die Bereitschaft, Schuhe online zu kaufen, indem es Produktbilder von lokalen Schuhhändlern in einem simplen Shop online stellte. Bei einer Bestellung wurden die Schuhe im entsprechenden Laden gekauft und an die Käufer verschickt.
• Groupon: fand über einen einfachen WordPress Blog heraus, ob Leute bereit sind, Gutscheine über das Internet zu kaufen. Die gekauften Gutscheine wurden dann einzeln als PDF erstellt und per E-Mail versendet.

In meinem letzten Beitrag bin ich schon auf das Prinzip des ‚Ugly Baby‘ eingegangen, als solches sich in vielen Fällen neue Produkte zu einem viel zu späten Zeitpunkt herausstellen. Meist dann erst, wenn der Weg zurück gar nicht mehr möglich ist. Während des oben beschriebenen Vortrags machte es dann häufig ‚Klick‘ und mir fielen spontan eine Reihe von Praxisbeispielen ein.

Fallbeispiele

Pretotyping – Beispiel 1: Aber wir haben es doch getestet!

Ich war als Produktmanager für die Integration zweier erfolgreicher Plattformen mit großer Reichweite verantwortlich. Es ging darum, Händlern in einem hochpreisigen Produktsegment die Möglichkeit zu geben, die Reichweite ihrer aktiven Kleinanzeigen zu erhöhen, indem diese auf der anderen (transaktionsbasierten) Seite eingebunden werden. Die Annahme dahinter war, dass wir damit sowohl für die Verkäufer auf der Anzeigen- als auch für potentielle Käufer auf der Transaktionsplattform einen signifikanten Mehrwert schaffen, somit neue Zielgruppen erschließen und zusätzliche Gebühren für das Feature verlangen können.

Die Herausforderungen und Risiken lagen in der möglichen Komplexität:

1. Zum einen, ob die Nutzer (Käufer) aufgrund des gelernten Verhaltens die Suchergebnisliste mit unterschiedlichen Formaten (Transaktions- und Anzeigenformat) überhaupt verstehen und annehmen.
2. Zum anderen auf der technischen Seite, angefangen bei den Schnittstellen (API), über das Einstellen und Verändern der Angebote, bis hin zur Anzeige-Logik in den Suchergebnissen – ganz zu schweigen von Länderspezifika und ‚Cross-Border‘ Szenarien.

Die Komplexität bedeutete nach einer ersten Aufwandsschätzung mehrere Hunderttausend Euro reine Entwicklungs- bzw. entwicklungsnahe Kosten. In Summe ergab sich natürlich ein weit höherer Wert. Rechnet man die mit einem Projekt verbundenen Aufwände, d.h. für Koordination, Kommunikation und die Vermarktung mit ein, landet man schnell im einstelligen Millionenbereich.

Der zugrundeliegende Business Case ist nicht annähernd eingetreten.

Die Laufzeit des Projekts von Anfang der Konzeptphase bis zum Abschluss der Nachbesserungen betrug knapp ein Jahr. Das Ergebnis? Das Projekt wurde in seinem Kern und in seinem Hauptmarkt nach wenigen Monaten wieder eingestellt. Der zugrundeliegende Business Case ist nicht annähernd eingetreten. Im Gegenteil, das Feature gefährdete sogar das ursprüngliche Transaktionsmodell im betroffenen Produktsegment.

Was war passiert? War die technische Umsetzung nicht gut? Hat die Vermarktung nicht funktioniert? War die Benutzeroberfläche nicht an die Bedürfnisse der Käufer angepasst? Hatten wir keinen ausreichend langen Atem? Nein, nichts von alledem. Einfach gesagt, die Idee war falsch, hat die Bedürfnisse des Marktes komplett verfehlt, und hätte somit niemals in dieser Form ausgerollt werden dürfen.

Aber warum haben wir das erst so spät erkannt? Wir haben doch mit mehr als zehn potentiellen Nutzern (Käufer) im Vorfeld gesprochen, ob sie die Idee eines zusätzlichen Formats annehmen würden, die Antwort war größtenteils (!) positiv. Und, wir haben uns zwei Wochen Zeit genommen für die Berechnung eines fundierten Business Case. Vor allem aber, wir haben bei der Erstellung der Spezifikation für mindestens EUR 30.000,00 mehrere Prototypen (Click Dummies) – sogar in verschiedenen Ländern – getestet, um früh zu erkennen, mit welcher Darstellung die Nutzer auf der  Suchergebnis- und der Produktseite mit dem Anzeigenformat zurecht kommen…

Das eigentlich Irritierende an der Situation war der Umgang mit dem Scheitern der Idee. Noch lange danach haben die Protagonisten das Projekt (u.a. aufgrund seiner technischen Qualität…) vehement verteidigt anstatt kritisch den Marktwert und, was noch viel wichtiger ist, die Vorgehensweise für die zukünftige Produktentwicklung zu hinterfragen. Selbst (oder gerade) auf Managementebene wurde das Projekt und dessen ‚Scheitern‘ weitgehend totgeschwiegen.

Pretotyping – Beispiel 2: Doping für die Shopbesitzer

Als Product Owner war ich für einen spezifischen Geschäftsbereich einer (internationalen) Plattform zuständig. Nutzer konnten eigene Online-Shops in einem gehosteten Szenario betreiben und damit Produkte auf Provisionsbasis verkaufen. Ziel des Projekts war es, die Aktivität der neu registrierten Shopbesitzer schnell zu erhöhen. Der Lösungsansatz dafür war die Einführung von sogenannten ‚Aktivierungsmails‘, damit die Nutzer animiert und unterstützt werden, die Einrichtung ihrer Shops abzuschließen und erste Produkte einzustellen.

Die Durchführung des Projekts für die größten Zielmärkte dauerte inklusive der Konzeptphase ca. fünf Wochen zuzüglich Nachbesserungen und Erweiterungen. Bei durchschnittlich zwei Backend-Entwicklern, einem Designer, einem Tester, zwei Marketing-Experten für Konzept bzw. Tracking/Reporting und einem Product Owner kann man sich leicht ausrechnen, welche direkten und indirekten Kosten damit verbunden sind. Die Komplexität lag auf der technischen Seite in der Logik des Versende-Zeitpunktes und der Frequenz, abhängig vom jeweiligen Nutzerprofil. Und das im ersten Schritt gleich mit einer höchstmöglichen Flexibilität, um das Regelwerk jederzeit einfach anpassen zu können.

Hört sich zunächst sehr valide und nach einer professionellen Durchführung an. Der Effekt und damit der wirtschaftliche Nutzen? Null. In der Analyse mussten wir feststellen, dass die Funktion keine nachweisbaren Auswirkungen auf die Aktivität der Shopbesitzer hatte. Ähnlich dem Fallbeispiel 1 lehnten die Verantwortlichen leider auch hier ein grundsätzliches Infrage stellen der Idee ab. Stattdessen wurde das Projekt unter dem Aspekt der neuen technischen Infrastruktur positiv bewertet, da man damit für die Zukunft bei ähnlichen Anforderungen eine Grundlage geschaffen hätte.

Der Punkt, an dem das ‚Ugly Baby‘ noch hätte eliminiert werden können, war an dieser Stelle schon weit überschritten. Stattdessen schleppte man es weiter und fütterte es mit Feinjustierungen und neuen Konzept-Ideen durch.

Danach ist man schlauer… oder eben nicht

Kommt Euch bekannt vor? Und was sind die immer gleichen Kardinalfehler bei großen Projekten?

• Lösungs- statt Problemansatz: dem Team wurde eine vordefinierte Lösung oktroyiert statt zunächst das Problem und die eigentliche Ursache gemeinsam zu analysieren und es dann dem Team zu überlassen, die richtige Lösung zu finden.
• Entscheidungen auf Basis von Annahmen: ein Business Case dient primär dazu, sich so früh als möglich mit den Zielen, Rahmenbedingungen und möglichen Effekten auseinanderzusetzen. Selbst ein detaillierter Business Case hat aber zu viele kritische Unbekannte (und zu viel Wunschdenken), um ein Produkt in einer so frühen Phase und in seiner vollen Ausbaustufe zu rechtfertigen.
• Fehlende Selbstreflexion beim Management: ‚Scheitern‘ wird noch in zu vielen Firmen mit einem Gesichtsverlust gleichgesetzt. Die eigenen Ideen werden mit allen Mitteln – als falsch verstandener Ausdruck von Stärke – durchgesetzt, statt eine Kultur des kritischen Hinterfragens und Lernens zu etablieren. Hier spielen oft auch fachliche Überforderung in Führungsrollen und ein ausgeprägtes Eigeninteresse eine Rolle.
• Erkenntnis über das Scheitern viel zu spät: die Kosten plus die verpassten Opportunitäten können für manch kleines oder mittelständisches Unternehmen einen finanziellen Genickbruch bedeuten. Bei größeren und wirtschaflich starken Unternehmen eine drohende Gefahr für die Zukunft, hat sich eine bestimmte Mentalität erst einmal etabliert und können unwirtschaftliche Projekte zu lange kaschiert werden.
• Prototypen-Testing als Konzept-Validierung: klassische Prototypen identifizieren das Optimierungspotential, beispielsweise auf der Benutzeroberfläche – oder ermitteln auf technischer Ebene die Machbarkeit. Prototypen spielen zu spät im Prozess eine Rolle, als dass sie noch ein grundsätzliches Hinterfragen der Idee unterstützen könnten.

Wie hätte man denn nun den Ansatz des Pretotypings in den beschriebenen Fällen sinnvoll anwenden können? Im ersten Fallbeispiel durch das ‚manuelle‘ Hochladen der Daten über ein einfaches Format wie CSV und dem Einstreuen der Kleinanzeigen in die Suchergebnislisten der Transaktionsplattform. Und zwar ohne die komplette Integration in die komplexen Szenarien und ohne teure Erweiterungen der Schnittstellen für die automatisierte Synchronisation.

Das ganze zunächst einmal in einem einzigen ausgewählten Zielmarkt und nicht gleich für mehrere Länder gleichzeitig. Damit wären schnell und kostengünstig die grundlegenden Fragestellungen geklärt worden – das heisst: Gibt es einen Kanibalisierungseffekt für die bestehenden Transaktionformate? Wird auf der Produktdetailseite der neue Call-To-Action, nämlich die Kontaktaufnahme mit dem Händler – und nicht der direkte Kaufabschluss – verstanden? Wird damit ein Zusatznutzen, sprich eine höhere Reichweite für die Händler und mehr Kontakte erzielt und rechtfertigt das Ergebnis die zusätzlichen Gebühren?

Im zweiten Fallbeispiel ist der Ansatz ähnlich gelagert. Statt gleich im ersten Schritt die gesamte Infrastruktur für die Logik des Mailversands zu entwickeln, hätten manuell angestoßene Mails an zuvor ausgewählte Nutzer innerhalb der Zielgruppe gereicht, um früh zu erkennen, ob überhaupt ein Effekt erzielt werden kann. Im Idealfall bräuchte man für diesen ‚Fake‘ lediglich einen Designer und einen Marketingspezialisten zur Bedienung eines schon etablierten Newsletter-Tools, für die einfache inhaltliche und optische Gestaltung einer Handvoll Mails und für die Auswertung des Experiments.

Für welche Art des Pretotypings man sich entscheidet ist zunächst zweitrangig (siehe „Prototype It“, Second Edition – ab S. 38). Es geht um das Grundprinzip und das mentale Modell dahinter. Es geht aber auch um die Unternehmenskultur und ganz speziell um die Führungskräfte, die eine Lern-Kultur etablieren und vorleben müssen.

Bild: Peggy Guggenheim Museum Venedig von Martin Heckmann