Von der Idee zum MVP: So kommen wir zu einer ersten funktionierenden Version

Fast jedes Softwareprojekt beginnt mit einer Liste. Alles, was das Produkt irgendwann können soll, aufgeschrieben an einem begeisterten Nachmittag. Diese Liste ist wertvoll. Nur ist sie kein Plan.

Denn wer alles gleichzeitig bauen will, steht Monate später immer noch ohne Nutzer da und ohne Antwort auf die Frage, auf die es wirklich ankommt: Werden Menschen das nutzen? Deshalb beginnen wir mit einem MVP. In diesem Artikel liest du, wie wir von einer Idee zu einer ersten funktionierenden Version kommen und welche Entscheidungen wir unterwegs treffen.

Was ein MVP ist, und was nicht

MVP steht für Minimum Viable Product. Die kleinste Version deines Produkts, mit der echte Nutzer etwas tun können und mit der du etwas lernst.

Das Letzte wird oft vergessen. Ein MVP ist keine Demo, die in einer Präsentation gut aussieht. Es ist auch keine erste Phase eines festgelegten Projektplans, in dem schon alles entschieden ist. Es ist ein funktionierendes Stück Software, das eine wichtige Annahme testet. Zum Beispiel, ob Kunden ihre Anfrage lieber selbst eingeben als anzurufen, oder ob Monteure einen Einsatzplan auf ihrem Handy wirklich nutzen.

Klein heißt übrigens nicht schlampig. Was drin ist, muss gut funktionieren. Es ist nur weniger drin.

Schritt 1: das Problem schärfen

Wir fangen nicht bei Funktionen an, sondern bei Menschen. Wer wird das nutzen? Was machen sie jetzt, und wo hakt es? Meist sprechen wir mit ein paar künftigen Nutzern und schauen ihnen bei ihrer heutigen Arbeit über die Schulter. Tabellen, E-Mails und lose Zettel sagen oft mehr als ein Anforderungsdokument.

Schritt 2: die wichtigste Annahme wählen

Hinter jeder Idee stecken Annahmen. Dass Kunden bezahlen wollen. Dass Mitarbeitende eine neue App öffnen. Dass die Daten, die du brauchst, schon irgendwo verfügbar sind. Wir suchen die riskanteste Annahme: Wenn sie nicht stimmt, hat der Rest wenig Sinn. Die testet die erste Version.

Schritt 3: den Umfang reduzieren

Hier wird es schwierig, und auch spannend. Wir gehen die Liste gemeinsam durch und stellen bei jedem Punkt dieselbe Frage: Brauchen wir das, um die Annahme zu testen? Ein umfangreiches Rechte- und Rollensystem, Berichte, eine Anbindung an die Buchhaltung: wichtig, aber oft nicht für Version eins. Was wegfällt, verschwindet nicht. Es kommt auf die Roadmap.

Schritt 4: in kurzen Runden bauen (Iterationen)

Wir bauen in Runden von ein bis zwei Wochen. Nach jeder Runde siehst du etwas, das funktioniert, keinen Fortschrittsbericht. So merkst du früh, wenn etwas anders ausfällt als gedacht, und dann ist eine Kurskorrektur noch günstig.

Technisch wählen wir eine Basis, die mitwachsen kann. Ein MVP darf klein sein, aber wir bauen es nicht so, dass du nach einem halben Jahr neu anfangen musst.

Schritt 5: live mit echten Nutzern

Ein MVP ist erst fertig, wenn jemand damit arbeitet. Wir stellen die erste Version einer kleinen Gruppe von Nutzern zur Verfügung und schauen, was passiert. Was nutzen sie, wo steigen sie aus, wonach fragen sie? Das sind die Antworten, um die es von Anfang an ging.

Und nach der ersten Version?

Dann beginnt die eigentliche Arbeit. Mit echten Nutzern und echten Daten wählst du den nächsten Schritt nicht mehr aus dem Bauch heraus. Manchmal stellt sich heraus, dass eine Funktion, die ganz oben auf der Liste stand, kaum vermisst wird. Manchmal fragen Nutzer nach etwas, an das niemand gedacht hatte.

Es kann auch passieren, dass die wichtigste Annahme nicht stimmt. Das fühlt sich wie ein Rückschlag an, ist aber genau das, was ein MVP liefern soll: eine Antwort, bevor der größte Teil des Budgets aufgebraucht ist.