"Wenn du dich nicht für die erste Version deines Produkts schämst, hast du zu spät gelauncht." — Reid Hoffman Bei Splits verfolgen wir diesen Ansatz beim Softwarebau: erst zum Laufen bringen → dann richtig machen → dann schnell machen. Die Reihenfolge ist wichtig. Hier ist, was wir aus dem Versand jeder Phase gelernt haben:

Mach es funktionsfähig = funktionaler Prototyp. Es sollte grob sein. Es sollte ungeschliffen sein. Bring es schnell vor die Nutzer. Wie wir das MVP abstecken: 1) Liste alles auf, was wir für wichtig oder relevant für das Projekt halten könnten. 2) Was ist das *absolute Minimum* aus dieser Liste, das wir abschließen können, um einen funktionalen Prototyp zu haben?

Mach es richtig = behebe alle defekten Teile. Gehe mit klaren Signalen vom Markt in diese Phase: konsistentes Feedback, wachsender Gebrauch trotz offensichtlicher Mängel. Jetzt hast du dir das Recht verdient, mehr Ressourcen zu investieren.

Mach es schnell = optimiere die Leistung. Ehrlich gesagt, wir lernen immer noch über diese Phase. Die meisten Teams sind derzeit im "mach es richtig"-Modus 🤷‍♂️ Aber hier ist die Inspiration, die uns antreibt:

Warum dieser Ansatz funktioniert: Sequenzierung ist Strategie. Was du heute lernst, prägt, was du morgen aufbaust. Wenn du vorspringst, hast du nicht die Informationen, die du benötigst, um Probleme korrekt zu lösen. Handeln produziert Informationen. Aber *absichtliches* Handeln produziert *nützlichere* Informationen.

Die Falle besteht darin, es gleichzeitig richtig zu machen, während du es zum Laufen bringst. NEIN. "Gib dir die Erlaubnis, etwas zu versenden, von dem du weißt, dass es nicht richtig ist." — @wminshew