Minimum Loveable Product: Was ein Prototyp leisten soll

Ein Prototyp beantwortet eine offene Frage. Verstehen Nutzer den Ablauf? Kann eine Datei zuverlässig gelesen werden? Liefert ein KI-Modell für reale Beispiele brauchbare Vorschläge? Der Prototyp darf dafür Teile vortäuschen oder vereinfachen. Sein Wert liegt in der Erkenntnis, nicht in der Zahl seiner Funktionen.

Ein Minimum Viable Product, kurz MVP, ist die kleinste nutzbare Produktfassung, mit der eine tragende Annahme unter realen Bedingungen geprüft werden kann. „Viable“ bedeutet dabei lebensfähig oder brauchbar. Es bedeutet nicht, dass schlechte Bedienung, fehlender Datenschutz oder unkontrollierbare Fehler plötzlich akzeptabel sind.

Minimum Loveable Product, kurz MLP, ist kein formaler Standard. Ich nutze den Begriff für eine bewusst kleine Lösung, die ihre begrenzte Aufgabe so gut erfüllt, dass die vorgesehene Nutzergruppe sie gern verwendet. Häufig findet man auch die Schreibweise „Lovable“. Gemeint ist nicht mehr Funktionsumfang, sondern mehr Sorgfalt auf einer kleineren Fläche.

Bei einer Sanierung wird manchmal ein Musterraum vollständig hergestellt. Dort lassen sich Material, Licht, Bedienung und Anschlüsse gemeinsam beurteilen. Ein einzelnes Farbmuster hätte diese Fragen nicht beantwortet. Das ganze Gebäude sofort umzubauen wäre dagegen teuer und riskant.

Ein guter Softwareprototyp funktioniert ähnlich. Er bildet einen vollständigen Weg durch eine kleine Aufgabe ab. Ein Antrag wird erfasst, geprüft und übergeben. Eine GAEB-Datei wird gelesen, zugeordnet und mit Fehlern sichtbar dargestellt. So werden die schwierigen Übergänge getestet, ohne bereits jede Etage auszubauen.

Vor dem Bau wird festgelegt, welche Entscheidung der Versuch ermöglichen soll. Weitermachen, wenn die Schnittstelle stabile Daten liefert. Den Ablauf ändern, wenn Nutzer an einer bestimmten Übergabe scheitern. Stoppen, wenn die notwendige Datenqualität nicht erreichbar ist. Ohne diese Messlatte verwandelt sich jeder Prototyp automatisch in ein Dauerprojekt.

Prototypcode kann später weiterverwendet werden, muss es aber nicht. Wenn Geschwindigkeit durch bewusst ausgelassene Sicherheit, Wartbarkeit oder Fehlerbehandlung erkauft wurde, gehört dieser Zustand offen auf den Tisch. Ein MLP braucht dagegen bereits eine tragfähige Grundlage für seinen kleinen Nutzungsbereich. Klein ist keine Ausrede für versteckte Schulden.

„Loveable“ bleibt subjektiv. Deshalb wird es beobachtbar gemacht: Finden Nutzer den Einstieg? Schließen sie den Kernvorgang ohne Hilfe ab? Vertrauen sie dem Ergebnis? Kommen sie freiwillig wieder? Begeisterung lässt sich nicht versprechen, aber schlechte Reibung lässt sich erkennen und bearbeiten.