Man liest ja oft von "fail early, fail often", aber das finden wir etwas negativ formuliert. Wer will schon scheitern? Deshalb sagen wir lieber "try often, learn fast". Aber was bedeutet das ganz konkret?
Wir sind häufig in Situationen, in denen unsere Kund:innen bereits einen Großteil der geplanten Funktionen in der allerersten Version ihres Produkts sehen wollen. Sie sind der Meinung, dass das Produkt mit einer möglichst ausgereiften Version auf den Markt gebracht werden sollte – denn nur dann habe es eine Chance, sich auf dem Markt durchzusetzen. In der Realität entpuppt sich das oft als großes Problem.
Warum ist das so? Entwicklung kostet eine Menge Ressourcen - und je mehr Funktionen im Vorfeld entwickelt werden, desto mehr Zeit und Geld stecken wir womöglich in etwas, das am Ende niemand benutzen will.
Planung, Design und Entwicklung kosten viel Geld und Zeit - je mehr man am Anfang macht, desto höher ist die Anfangsinvestition. Und mit höheren Investitionen steigt auch das Risiko: Was ist, wenn die Nutzer:innen andere Prioritäten haben und Du dies erst nach dem Start feststellst? Ebenso steigt die Frustration des Teams, wenn das Produkt trotz aller Bemühungen beim Start nicht den gewünschten Erfolg bringt.
Natürlich kann man dieses Risiko verringern, indem man Nutzer:innenforschung betreibt. Und das solltest Du auch tun - wir plädieren immer wieder dafür! Allerdings wird die Markteinführung dadurch nicht zu 100% risikofrei, denn die Forschung wird in der Regel auf der Grundlage eines Konzepts oder Prototyps durchgeführt, der je nach Funktion nicht immer die tatsächliche Interaktion und Verwendung widerspiegeln kann.
Bringen den MVP schnell auf die Straße
Verkürze die erste Entwicklungsphase, indem Du Dich auf das "Minimum Viable Product" (MVP) konzentrierst. Und mit minimal meinen wir minimal: Die Funktionen, die Du zu Beginn entwickelst, werden auf das Wesentliche reduziert - und zwar den Kern, der bereits das zentrale Nutzer:innenbedürfnis erfüllt. All die anderen coolen Funktionen, die Dir vorschweben, werden vorerst ins Backlog gestellt. Das spart nicht nur Zeit und Geld, sondern reduziert auch die technischen Herausforderungen, zumindest zu Beginn.
Außerdem kannst Du auf diese Weise die Kund:innen frühzeitig einbeziehen und das Produkt benutzerorientiert entwickeln (wir alle kennen die Feature-Request-Listen für unsere Lieblingstools). Auf diese Weise wird sichergestellt, dass mit jeder neuen Version des Produkts nur die Funktionen hinzugefügt werden, die die Benutzer:innen wirklich brauchen. Dadurch setzen wir Ressourcen gezielter ein.
Wenn dieser Ansatz während des gesamten Produktentwicklungszyklus beibehalten wird, kann die Akzeptanz immer wieder getestet werden - ganz im Sinne von "try often, learn fast".
Schüchternheit überwinden
Nichts wird perfekt geboren - vor allem nicht die erste Version Deines Produkts. Aber "minimal" bedeutet nicht, dass Du mit unfertigen Funktionen in Betrieb gehen solltest. Dies sollte sogar vermieden werden, da die Benutzer:innen dadurch abgeschreckt werden und im schlimmsten Fall das Produkt nie wieder benutzen. Stattdessen müssen die Anforderungen auf ihre Kernfunktionalität heruntergebrochen werden. In einem ersten Schritt sollte der Umfang nur so viel umfassen, dass ein Grundnutzen für die Benutzer:innen übrig bleibt. Alles andere wird herausgeschnitten und in das Backlog aufgenommen.
Es ist auch wichtig zu erwähnen, dass MVP nicht bedeutet, die gleiche Standardfunktionalität zu haben wie Deine Konkurrent:innen da draußen. Ganz im Gegenteil. Es bedeutet, genau die Kernfunktionalität zu haben, die Dich von anderen unterscheidet – all das, was Dein Produkt besonders macht. Wenn Du Dich beispielsweise entscheidest, eine neue Aufgaben-App zu entwickeln, muss Deine allererste Version mehr sein als nur eine Standardliste von abhakbaren Kästchen. Du brauchst etwas Einzigartiges, das Dich von Deinen Mitbewerber:innen abhebt.
Nehmen wir doch das Kästchen der To-Do-App als Beispiel. Die App (Not Boring) Habits von Andy Works war ursprünglich genau das: ein Kästchen, mit dem man abhaken konnte, ob man die tägliche Gewohnheits-Aufgabe erledigt hat. Aber sie wussten, dass der Markt überfüllt war und viele andere Gewohnheits-Tracker bereits ausgefeilte Tracking-, Statistik- und Dashboard-Funktionen hatten. Wie kann man da mithalten? Sie konzentrierten sich auf das Wesentliche: Die Freude am Abhaken einer Aufgabe. Also schufen sie das beste abhakbare Kästchen, das die Welt je gesehen hat! Dafür haben sie sich auf das Design, das Verhalten und die Art und Weise, wie man es abhakt, fokussiert. Erst später fügten sie weitere Funktionen hinzu.
Ein Ansatz für alle?
Wir sind der Meinung, dass dieser Ansatz für alle Produkte geeignet ist. Allerdings darf man auch den spezifischen Kontext Deines Unternehmens nicht außer Acht lassen. Was wollen wir damit sagen?
Wenn Dein Produkt unter dem Schirm eines bekannten Unternehmens entsteht, das sich durch qualitativ hochwertige digitale Erfahrungen auszeichnet, kannst Du sicher sein, dass die Erwartungen Deiner Benutzer:innen hoch sind. Du musst diese Erwartungen erfüllen und dafür sorgen, dass Deine Nutzer:innen ein gutes Erlebnis mit Deinem Produkt haben. Sprich: Du musst Dein Image - Deine Marke - schützen.
In diesem Fall kann es sinnvoll sein, die erste Version eines Produkts nicht für die Öffentlichkeit freizugeben. Du könntest es zunächst nur bestimmten Gruppen durch geschlossene Betatests oder interne Pilotprojekte zugänglich machen. Auf diese Weise kannst Du frühzeitig echtes Feedback einholen – ohne Deinen Ruf aufs Spiel zu setzen.
Andererseits geht es in einem Startup-Kontext darum, Dein Produkt oft und früh auszuliefern. Dies kann auf finanziellen Druck zurückzuführen sein oder einfach darauf, als einer der Ersten auf den Markt zu kommen. Startups basieren in der Regel auf einer Kernidee und um ihr Stück vom Kuchen zu bekommen, müssen sie schnell auf dem Markt sein. Sie müssen also das richtige Gleichgewicht zwischen der Markteinführung eines Produkts und dessen Reifegrad finden.
Wie lassen sich Funktionen priorisieren?
Bislang haben wir eine wichtige Frage vermieden: Woher weiß man, auf welche Funktion man sich konzentrieren soll?
Eine bewährte Methode, die wir gerne zur Priorisierung und Planung der Entwicklung einsetzen, ist die User-Story-Mapping-Methode, die von Jeff Patton entwickelt wurde. Sie dient dazu, alle möglichen und gewünschten Schritte der Nutzer:innen zu durchdenken. Gemeinsam erzählen wir in einem Workshop zusammen mit Product Owner:in, Entwickler:innen und Designer:innen die Geschichte der Nutzung eines Produktes, indem wir die großen Nutzeraktivitäten auf Post-It's sammeln und von links nach rechts auflisten. Im zweiten Schritt sehen wir uns diese Nutzer:innenaktivitäten noch einmal an und ergänzen sie um Details. Daraus entsteht dann eine Karte, die in etwa so aussieht:
Wir können die Nutzer:innenaktivitäten dann hin und her schieben – oder auch ganz weglassen und uns nur auf das Nötigste konzentrieren. Im Beispiel der Karte oben etwa: Wie sieht der MVP von "zur Arbeit gehen" aus? Was können wir weglassen? Geht es auch ohne Duschen oder ohne Frühstücken?
Aktionen, die nicht zentral für die Erfüllung des Nutzer:innenziels sind, verschieben wir einfach nach unten, in eine eigene Linie. Jede dieser so entstehenden Linien kann ein eigener Release sein, den wir nach Veröffentlichung des MVPs angehen.
Ganz im Sinne von "früh ausprobieren, schnell lernen" haben wir nach jedem Release die Möglichkeit, den Erfolg zu evaluieren und gegebenenfalls Anpassungen an der Ausrichtung des nächsten Releases vorzunehmen. So geben wir jeder Veröffentlichung die Chance, dass wir daraus lernen können und entwickeln am Ende ein Produkt, dass die Bedürfnisse seiner Nutzer:innen vollumfänglich erfüllt.
