Es ist ein abgefahrenes Gefühl, ein neues Produkt zu bauen. Egal, ob im heimischen Wohnzimmer oder im Büro des Großkonzerns — wenn aus vorsichtigen Skizzen ein Prototyp wird, wenn die ersten Codezeilen entstehen und schließlich der erste, echte Betatester das Produkt von innen sieht, dann fühlen sich alle Beteiligten wie die Neuentdecker Amerikas. Mindestens. Schließlich hat man etwas gebaut, auf das die Welt, oder zumindest die anvisierte Zielgruppe, nur gewartet hat!
Oder?
Irgendwo, versteckt unter dem Gründergeist, gibt es dieses leichte Unbehagen. Die Angst, dass das Produkt am Ende doch keiner braucht. Nicht so sehr jedenfalls, dass man als Erfinder echtes Geld dafür bekommt. Vielleicht ist der USP auch gar nicht klar. Der Name kacke. Das Preismodell überzogen. Die Konkurrenz gar nicht mal so schlecht.
Vielleicht ist die Idee auch einfach ziemlich blöd.
Haben auch wir bei sipgate solche Zweifel, wenn wir eine Produktidee angehen? Klar. Wir provozieren sie sogar, lassen neue Ideen bewusst und immer wieder gegen Misstrauen und Skepsis rennen. Nicht, weil wir keine Erfahrung im Bauen von Produkten haben, sondern genau deswegen. Wir wissen, dass man zwar viele Produktentscheidungen mit einer Mischung aus Erfahrung, Intuition und Nachdenken ziemlich zuverlässig treffen kann, viele aber auch nicht.
Dann nämlich, wenn man etwas wirklich Neues macht, liegen nicht nur die Antworten im Dunkeln — zuweilen wissen wir noch nicht einmal, welche Fragen wir überhaupt stellen sollen. Ist das Kundenproblem, das wir erkannt haben, vielleicht nur ein Symptom? Oder, noch schlimmer, wird es sich in wenigen Monaten von selbst erledigen? Gibt es da etwas, das wir nicht durchblickt, erahnt, vorausgesehen haben?
Diese dunkle Rumpelkammer voller “unknown unknowns” ist dummerweise genau der Ort, an dem sich Innovation heimisch fühlt. Und je innovativer Produktideen sind, desto schwächer wird unsere Taschenlampe, mit der wir in die Zukunft schauen.
Macht es denn trotzdem Spaß, in dieser Rumpelkammer zu arbeiten? Ja!
Aber wie? Einfach losrennen und machen? Jein.
Fail fast, fail often, fail richtig
Wir bei sipgate finden Experimente nicht nur notwendig, sondern haben auch Spaß daran, sie einzusetzen. Kein Tag vergeht, an dem wir nicht irgendeine Annahme validieren, auf einem Produkt iterieren und uns komplexen Fragen in Trippelschritten nähern.
Allerdings kostet auch Ausprobieren Geld und das ist es, was die “Fail fast, fail often“-Mentalität manchmal zu vergessen scheint. Täglich gehen Startups beim Ausprobieren die Puste aus. Und Firmen unserer Größe passiert es ebenfalls regelmäßig.
Der Grund ist offensichtlich: Experimente können grandios scheitern, per Definition. Deswegen werden wir bei sipgate misstrauisch, wenn ein Experiment mit sehr hoher Wahrscheinlichkeit erfolgreich sein wird. Dann ist es nämlich mit genauso hoher Wahrscheinlichkeit überhaupt kein Experiment. Und auch nur selten ein Hebel für Innovation. Mist!
Das Dilemma, gewagte, neue Dinge auszuprobieren, ohne nach drei fehlgeschlagenen Experimenten das Licht ausmachen zu müssen, ist natürlich kein exklusives Problem. Und wir bei sipgate sind auch nicht die Ersten, die einen Rahmen gefunden haben, um Experimente im Alltag einzubinden.
Allerdings haben wir festgestellt, dass viele unserer Gäste begeistert auf unser Framework zum Validieren von Ideen reagieren und Teile davon übernehmen möchten. Deswegen möchte ich in diesem und den nächsten Artikeln zeigen, wie dieses Framework funktioniert. Zunächst geht es um einige Grundsätze, die uns wichtig sind, dann um die Tools, die wir verwenden, und schließlich um ein konkretes Beispiel: Die Produktidee phonestats.io.
Klingt interessant? Lasst es uns probieren :)
Wie wir experimentieren
Experimente auf Produktebene sehen bei uns sehr, sehr unterschiedlich aus. Egal aber, wie wir eine Sache angehen, drei Dinge sind uns wichtig:
1. Bestehendes Wissen nutzen
sipgate hat in den letzten 10 Jahren sehr viel Erfahrung und Wissen aufgebaut. Das Teuerste, was uns passieren kann, ist, dass wir als Organisation die gleiche Sache zweimal lernen. Oder dreimal. Deswegen ist alles bei uns, auch der Prozess für Experimente, darauf ausgelegt, gemeinsames sipgate-Wissen anzuzapfen. Das bedeutet nicht, dass wir schon auf alles eine Antwort hätten.
“The real issue is not how do you find your voice, but how to get rid of it.”
Philipp Glass, Composer
Die innere Stimme, gerade wenn sie durch langjährige Erfahrung geprägt ist, kann einen ordentlich in die Irre führen und manchmal geht es eher darum, diese Stimme loszuwerden, statt auf sie zu hören. Märkte ändern sich, Kunden ändern sich.
Trotzdem wollen wir nicht ignorieren, was sipgate gelernt hat, sondern darauf iterieren. Apropos iterieren …
2. Kleine Iterationen
Wir versuchen, uns Problemen möglichst kleinschrittig zu nähern. Gerade zu Anfang ist die Anzahl der beteiligten Leute und der Umfang minimal. Experimente, die sich voraussichtlich über mehrere Wochen hinziehen würden, bekommen eine Diät verpasst. Meist geht das sehr einfach, indem wir uns auf die Faustregel besinnen: 1 Experiment = 1 Learning. Sobald man sich auf die eine Sache, die man herausfinden möchte, konzentriert, schrumpft sich ein Experiment meist ganz von alleine gesund.
Ein paar Beispiele:
- Zwei Entwickler bauen ein Feature innerhalb weniger Tage für eine Handvoll von Testkunden. Dann sammeln wir Feedback.
- Zwei UXer konzepten ein neues Interface, testen es erst intern, dann extern und iterieren darauf.
- Ein PO ruft zehn Kunden an und interviewt sie zu einem bestimmten Problem.
Diese Experimente sind so klein, dass sie — wenn wir sie nicht visualisieren würden — unter dem Radar fliegen könnten. Umfangreicher und sichtbarer ist die Arbeit der Scrum-Teams, crossfunktional aufgestellter Gruppen, die Produkte und Features bauen. Ihre Projekte stellen bei uns den größten Scope eines Experiments da (mehr dazu im nächsten Artikel), aber ihnen gehen fast immer viele kleine Experimente voraus.
Warum aber legen wir so viel Wert auf Kleinst-Iterationen? Weil es weniger kostet? Oder weil wir zu feige für riskante, große Schritte sind? Nein. Wir möchten “Bold Moves” wagen, hinter denen das beste und vielversprechendste steht, das wir als Firma hinbekommen — aber das extrem schnell.
In dem wunderbaren Buch “Creativity, Inc.” vergleicht Pixar-Regisseur Andrew Stanton den kreativen Prozess mit einer Schiffmannschaft, die mitten auf dem Ozean die Orienterung verloren hat. Irgendjemand muss entscheiden, dass dort hinten, an dieser bestimmten Stelle des Horizonts, Land ist. Vielleicht hat er recht, vielleicht auch nicht. Solange die Mannschaft aber darüber diskutiert, wo ihr Ziel sein könnte, wird das Schiff nirgendwo ankommen.
Und zu der Kostenfrage: Ja, “einfach mal Ausprobieren” im kleinen Rahmen ist am Ende günstiger, als endlos darüber zu philosophieren, was “der Kunde” braucht. Deswegen machen wir das auch nie.
(Habt ihr das gerade geglaubt? Natürlich gibt es solche Meetings — aber inzwischen erwischen wir uns ziemlich schnell dabei.)
3. Standardisierung und Rituale
Wir sind Fans von Standardisierung, auch beim Experimentieren. Anstatt das (Prozess-)rad jedesmal neu zu erfinden, können wir uns so nämlich voll auf das Problem konzentrieren. Die Domäne, in der sich unsere Produktprobleme bewegen, ist schließlich schon komplex genug. Wenn wir zusätzlich vor jedem Experiment überlegen müssten, in welchem Rahmen wir unsere Annahmen validieren dürfen, würden wir ob der unendlichen Möglichkeiten wahrscheinlich gar nicht erst beginnen. (Das Codewort bei sipgate hierfür ist “Dachlatten” — die wir in absehbarer Zeit nicht verkaufen werden. Obwohl wir inzwischen echt coole Ideen haben, wie man den Markt aufmischen könnte.)
Die meisten der Rituale und Werkzeuge, die wir benutzen, haben wir uns nicht selbst ausgedacht. Wir bedienen uns großzügig bei Methoden aus dem Design Thinking, der agilen Welt und der Lean Startup Methodik. Entstanden ist ein Framework, das nun schon seit einigen Monaten im Einsatz ist uns echt weiterhilft (ohne, dass es schon perfekt wäre).
Wie sieht dieses Framework aus? Wie sammeln wir Ideen und unter welchen Umständen wird ein Experiment oder sogar ein Produkt daraus? Darum geht es im nächsten Artikel.
Möchtest du dich mit uns über das Thema austauschen? Komm zum Essen bei uns im Büro vorbei oder schreib mir über Twitter.
