Der Unterschied zum erfolgreichen Produktlaunch ist mindestens 20x
MVPs, Prototypen und Produkte
Wenn man sich die Pitchdecks vieler Start-ups in der Frühphase ansieht, findet man in den Roadmaps oft ein merkwürdiges Zeitkonzept. Die Gründer sehen in der Regel eine Zeit X von Null bis zu einem funktionierenden Prototyp vor und eine Zeit Y, um vom Prototyp zu einem fertigen Produkt zu gelangen. Das Spannende ist nun, dass X und Y in der Regel in der gleichen Größenordnung liegen. Bisher haben wir noch kein einziges Unternehmen gesehen, für das das zutrifft. Zumindest beträgt Y - die Zeit vom Prototyp zum Produkt - das 20-fache von X - der Zeit von Null bis zum Prototyp. Das Missverstehen dieses Gesetzes bringt Unternehmen kaum um, führt aber zu Stress und Frustration.
Bevor wir uns mit den Gründen für dieses Gesetz befassen können, müssen wir drei Schlüsselbegriffe definieren:
MVP: Ein Minimum Viable Product (MVP) hat in letzter Zeit eine Fülle verschiedener Bezeichnungen erhalten. Unabhängig von der Bezeichnung ist ein MVP das Mindestkonzept, mit dem ein Wertversprechen erzielt werden kann. Die gängige Vorstellung, dass das typische MVP mindestens eine Größenordnung zu groß ist, rührt von der Tendenz technischer Gründer her, eine technische Lösung zu entwickeln. Ein MVP ist jedoch nicht technischer Natur, sondern auf den Markt fokussiert. Es geht nicht um künstliche Intelligenz, Blockchain oder ein anderes Schlagwort, das derzeit in aller Munde ist, sondern darum, die Bedürfnisse eines potenziellen Kunden zu erfüllen. Ein MVP kann per E-Mail, mit Stift und Papier oder in Handarbeit erstellt werden.
Prototyp: Ein Prototyp ist ein Entwurf der technischen Lösung für das im MVP identifizierte Problem. Ein Prototyp sollte normalerweise funktionieren und zeigen, wie die Lösung funktionieren soll. Er funktioniert unter kontrollierten Bedingungen und in einer Losgröße von eins.
Produkt: Ein Produkt ist eine zertifizierte, skalierbare und verkaufsfähige Implementierung der Wertposition. Es funktioniert in allen unterstützten Umgebungen und ohne Überwachung durch den Hersteller. Darüber hinaus läuft es stabil und zuverlässig während der Betriebszeit, so dass sich die Nutzer darauf verlassen können.
Der Weg zum Prototyp
Die Entwicklung eines Prototyps ist in der Regel ein aufregendes Unterfangen. Mit viel technischem Aufwand können die Entwickler an den modernsten Tech-Stacks herumtüfteln und einen Dienst erstellen, der in 95 % der Fälle funktioniert. Die Kanten sind hier und da ein wenig rau, aber es bringt uns von Null auf Eins. Mit dem Prototyp können Start-ups Pilotkunden anlocken, die so begierig darauf sind, den Dienst zu nutzen - um ihre Bedürfnisse zu befriedigen -, dass sie die Mängel und gelegentlichen Ausfälle in Kauf nehmen. Da nur wenige Nutzer unterstützt werden, können Fehler vom Entwicklungsteam schnell behoben werden.
Um von einem MVP zu einem Prototyp zu gelangen, ist eine strenge Konzentration auf die Wertschöpfung erforderlich, nur um die Funktionen zu implementieren, die der vorgesehene Benutzer dringend benötigt. Es besteht also ein interner Konflikt zwischen der Benutzererfahrung und der Entwicklungsseite darüber, welche Funktionen aufgenommen werden sollen und welche nicht. Das technische Projektmanagement umfasst zahlreiche Schleifen, um praktikable technische Lösungen für die Herausforderungen zu finden. Auf der anderen Seite sind die Werkzeuge einfach, wie ein Kanban-Board und eine Deployment-Pipeline von der Stange. Qualität ist zweitrangig gegenüber der Erfüllung abstrakter Leistungsmetriken. Das Ziel des Prototyps ist es nicht, skalierbar zu sein, sondern in einer einzigen Integration zu arbeiten und für die Zukunft zu lernen, in der wir daraus ein Produkt entwickeln wollen.
Das Erreichen des Prototyps fühlt sich oft wie ein Heureka-Moment an. Endlich wird die Vision zur Realität und der Wert wird auf magische Weise von einer Maschine geschaffen - nicht wie im MVP von den Gründern, die an einem Ende einer Massageschnittstelle sitzen. Da es in fast allen Fällen funktioniert, sollte es nur noch eine kleine Anzahl von Optimierungen geben, um ein Produkt zu schaffen.
Der Weg zum Produkt
Die Produktentwicklung ist der langweilige Onkel der Prototypentwicklung. Wenn die Produktentwicklung beginnt, sollte der Prototyp die technischen Lösungen für komplexe Probleme skizzieren. Das Ziel der Produktentwicklungsphase besteht nicht darin, das Problem des Kunden zu lösen, sondern es in großem Umfang zu lösen. Diese Ziele bedeuten Stabilität, Skalierbarkeit und Konformität. Daher muss in dieser Phase ein Großteil des alten Codes umgeschrieben und durch konservativere Lösungen ersetzt werden.
Auch das Projektmanagement erfordert in dieser Phase mehr Stabilität und weniger Experimente. In dieser Phase ist es nur sinnvoll, SCRUM in Betracht zu ziehen, das Prozesse bietet, die die neuen Anforderungen besser unterstützen können als der experimentellere vorherige Prozess. Es erfordert auch einen disziplinierteren Entwicklungsstil von der Organisation selbst. Daher kann dieser Wechsel für viele Entwickler in der Anfangsphase frustrierend und problematisch sein. Diese Entwickler werden Zeit brauchen, um sich anzupassen. Aufgrund der höheren Komplexität - raue Kanten werden in einem Produkt nicht mehr akzeptiert - muss das Projektmanagement auch eine Spezialisierung fordern. Im einfachsten Fall sollten die Benutzeroberflächen von den technischen Maschinen getrennt werden.
Dieser Veränderungsbedarf im Projektmanagement wird oft nicht ausreichend beachtet. Sie ist aber nicht der Grund für die Explosion der Komplexität.
Es wurden Fehler gemacht
Wir gehen zurück zu den Zielen Stabilität, Skalierbarkeit und Compliance für die Fehler und betrachten die Versäumnisse in all diesen Bereichen. Zusammen verursachen sie eine 20-fache Explosion der Komplexität für die Organisation.
Wenn wir mit der Stabilität beginnen, müssen wir von 95 % auf mindestens 99,95 % kommen. Das sieht zwar auf den ersten Blick so aus, als ob wir schon fast am Ziel sind, aber es reduziert die Fehlerquote von 1 zu 20, was kein Benutzer akzeptieren würde, auf 1 zu 2000. Das heißt, 100 von 2000 auf 1 von 2000 oder eine Verringerung der Ausfälle um 99 %. Bitte beachten Sie auch, dass eine Stabilität von 99,95 % ein kaum akzeptables Minimum ist. Wenn wir uns den Entwicklungsaufwand so vorstellen, können wir leicht erkennen, warum die Komplexität zunimmt. Damit erhält die gängige Weisheit "die leichten Dinge sind die schweren Dinge" eine solide Grundlage. Das Akzeptanzniveau hängt auch von der Art des Dienstes ab. Kritische Dienste für den Kunden müssen stabiler sein als unbedeutende Dienste. Die Komplexität der Integration steht in umgekehrtem Verhältnis zur Geschäftsmöglichkeit. Außerdem können Fehler in einem Produkt nicht einfach von den Entwicklern behoben werden, da sie sich auf den restlichen Code auswirken könnten. Außerdem müssen die Entwickler eine breitere Installationsbasis unterstützen.
Als Ausweg aus dem zweiten Punkt betrachten wir die Skalierbarkeit. Skalierbarkeit bedeutet in der Regel, dass die Prozesse alle Produktions-, Vertriebs- und Supportszenarien unterstützen müssen. Insbesondere die Produktionsprozesse sind eine komplette technische Herausforderung, die im Prototypenstadium nicht berücksichtigt werden muss. Mehr noch: Produktion und Produkt sind eng miteinander verwoben. Eine Funktionsänderung in letzter Minute erfordert die Rekonstruktion zumindest von Teilen der Produktionsprozesse. Dies ist zwar bei physischen Produkten offensichtlich, gilt aber auch für digitale Produkte. Support und Vertrieb sind zwar weniger eine technische Aufgabe, aber auch sie sind eng mit dem Produkt verbunden und wohl ein Teil davon. Vor allem der Vertrieb kann in den ersten Tagen der Marktabdeckung mit einer Wildwest-Attitüde davonkommen, behindert aber langfristig die Skalierbarkeit, wenn Marketing und Vertrieb nicht hoch integriert und gut koordiniert sind. Diese Prozesse werden in der Produktentwicklung neue Felder von langwieriger Arbeit hinzufügen.
Das kleinste und am besten planbare Ziel der Produktentwicklung ist die Einhaltung von Vorschriften. Die meisten Start-ups wissen zwar, welche Vorschriften sie einhalten müssen, aber sie unterschätzen oft den Zeitaufwand und die erforderlichen Arbeitskräfte. Die einfachste Methode besteht darin, ein ähnliches Start-up-Unternehmen nach seinen Erfahrungen mit der Einhaltung der Vorschriften zu fragen und deren Schätzungen zu kopieren.
Während die drei oben genannten Argumente zu unterschätzten Produktentwicklungszeiten führen, gibt es ein viertes Ärgernis, das in allen Unternehmen in der Anfangsphase vorkommt und um das sich viele größere Unternehmen nicht in dieser Tiefe kümmern müssen: die Kundenfindung. Während wir im Idealfall in der Prototyping-Phase etwas über die Kundenpersona oder die Organisation erfahren, um zu verstehen, was wir unterstützen müssen. In Projekten und Gesprächen werden wir herausfinden, dass es ein allgemeines Missverständnis bei den Funktionen gibt. Das Phänomen, das in zahllosen schlecht gezeichneten Comics diskutiert wird, ist wohlbekannt, aber die Ursache ist es nicht. Wenn ein Produkt mehr ein Konzept als eine Tatsache ist, werden alle Beteiligten die Lücken so ausfüllen, wie es ihnen am liebsten ist. Hören Sie also nie auf, Feedback einzuholen. Zum anderen unterschätzen die Kunden die Komplexität und Langsamkeit auf ihrer Seite und zwingen die Entwickler, mit einer großen Sicherheitsmarge für realistische Schätzungen zu arbeiten.
Comments