„Minimum Viable Product“ ist eine der meistzitierten und am seltensten befolgten Ideen der Softwarebranche. In der Praxis scheitern MVPs auf zwei Arten. Entweder sind sie so minimal, dass sie nichts beweisen, oder sie wachsen still zu einer Version 1.0 mit einem Jahr an Funktionen heran, nach denen noch niemand gefragt hat. Beides verschwendet die eine Ressource, die ein junges Produkt nicht ersetzen kann: Zeit zum Lernen.
Hier ist die Methode, mit der wir gemeinsam mit Gründern und Produktteams eine erste Version zuschneiden, die klein ist, ausgeliefert werden kann und trotzdem eine echte Frage beantwortet.
Die Annahme benennen, die Sie testen
Ein MVP ist ein Experiment, und ein Experiment braucht eine Hypothese. Schreiben Sie vor jeder Feature-Liste die riskanteste Annahme hinter dem Produkt auf. Meist ist es eine dieser:
- Nachfrage: Die Menschen, die wir im Blick haben, haben dieses Problem so stark, dass sie ihre Arbeitsweise ändern.
- Nutzen: Unsere Lösung ist deutlich besser als das, was sie heute tun, einschließlich nichts zu tun.
- Zahlungsbereitschaft: Sie oder ihr Unternehmen zahlen einen Preis, mit dem das Geschäft funktioniert.
- Machbarkeit: Wir können das Ergebnis tatsächlich liefern, etwa mit akzeptabler KI-Genauigkeit oder mit Daten, auf die wir rechtlich zugreifen dürfen.
Wählen Sie die Annahme, die das Produkt beenden würde, wenn sie sich als falsch erweist, und schneiden Sie das MVP so zu, dass es genau sie testet. Ein Produkt, dessen größtes Risiko die Zahlungsbereitschaft ist, braucht schon in der ersten Version einen Checkout und eine Preisseite. Ein Produkt, dessen größtes Risiko die Machbarkeit ist, braucht vielleicht gar keine Oberfläche, sondern nur eine Pipeline, die zeigt, dass das Ergebnis gut genug ist.
Den einen Weg zeichnen, der funktionieren muss
Beschreiben Sie als Nächstes die eine Strecke, die ein Nutzer zurücklegen können muss, damit der Test überhaupt etwas aussagt. Nicht das ganze Produkt: ein Weg vom ersten Kontakt bis zum Moment des Nutzens.
Für ein B2B-Tool zur Schichtplanung könnte das sein: Eine Teamleiterin registriert sich, importiert ihr Team, veröffentlicht einen Dienstplan, und die Mitarbeitenden sehen ihre Schichten auf dem Handy. Alles auf diesem Weg muss ordentlich funktionieren. Alles daneben ist ein Kandidat für später.
Den Weg als kurze Geschichte aufzuschreiben, Bildschirm für Bildschirm, ist außerdem der schnellste Weg herauszufinden, dass zwei Menschen im Team zwei verschiedene Produkte im Kopf hatten.
Entscheiden, was simuliert wird
Ein überraschend großer Teil eines frühen Produkts lässt sich von Hand oder mit vorhandenen Tools erledigen, solange der Nutzer es nicht als kaputt erlebt:
- Onboarding durch einen Menschen im Call statt eines Self-Service-Assistenten;
- Berichte als Tabelle oder PDF statt eines Analytics-Dashboards;
- Abrechnung per Rechnung oder gehostetem Zahlungslink statt eines vollständigen Abo-Systems;
- ein Admin-Bereich auf Basis eines Standardtools statt eines eigenen Backoffice;
- Integrationen per geplantem Export statt Echtzeit-API.
Jede dieser Entscheidungen spart Wochen. Und jede lehrt etwas: Wenn Kunden immer wieder nach der Self-Service-Variante fragen, wissen Sie, was als Nächstes gebaut wird.
Was man nie weglässt
Minimal im Umfang heißt nicht nachlässig beim Fundament. Manches ist später teuer nachzurüsten und von Anfang an günstig richtig zu machen:
- Authentifizierung und Berechtigungen über einen bewährten Anbieter statt eines selbstgebauten Logins.
- Ein Datenmodell, das zum Geschäft passt, vor allem bei Konten, Organisationen und Rollen. Mandantenfähigkeit nachträglich einzubauen ist schmerzhaft.
- Grundlegende Sicherheits- und Datenschutzhygiene: verschlüsselte Verbindungen, Secrets außerhalb des Codes, personenbezogene Daten mit Blick auf die DSGVO.
- Analytics auf dem einen Weg, damit Sie sehen, wo Menschen abspringen. Ohne sie hat das Experiment kein Ergebnis.
- Automatisierte Deployments, damit ein Fix in Minuten live ist und niemand Angst vor Releases hat.
- Grundlagen von Barrierefreiheit und Performance, die in neuem Code wenig kosten und in altem Code viel.
Langweilige Technologie wählen
Ein MVP ist nicht der Ort, um drei neue Frameworks auszuprobieren. Wählen Sie einen Stack, den das Team gut kennt und der auch dann noch vernünftig ist, wenn das Produkt Erfolg hat: Für viele SaaS-Produkte heißt das TypeScript mit React oder Next.js, eine verwaltete PostgreSQL-Datenbank und eine etablierte Cloud. Ziel ist, dass ein erfolgreiches MVP zum Fundament des Produkts wird und nicht zu einem Prototyp, den man unter Druck wegwerfen muss.
Erst die Zeit festlegen, dann den Umfang
Legen Sie zuerst die Zeit fest und passen Sie den Umfang hinein. Wenige Wochen bis zu den ersten echten Nutzern sind für die meisten B2B-MVPs ein gesundes Ziel. Passt der gezeichnete Weg nicht hinein, kürzen Sie entlang des Weges, nicht quer dazu: Schritte vereinfachen, mehr simulieren, die Zielgruppe eingrenzen. Liefern Sie nicht von jeder Funktion die Hälfte.
Vereinbaren Sie vorab, welches Ergebnis als Erfolg zählt, welches als Misserfolg und was Sie jeweils tun. So wird ein Launch zu einer Entscheidung statt zu einem Bauchgefühl.
Nach dem Launch: erst lernen, dann bauen
Das wertvollste Ergebnis eines MVP ist nicht der Code, sondern das, was Sie in den ersten Wochen der Nutzung lernen. Sprechen Sie mit jedem frühen Nutzer, den Sie erreichen. Beobachten Sie die Analytics auf dem Weg. Führen Sie eine kurze Liste dessen, wonach gefragt wird und wie oft. Planen Sie Version zwei dann auf Grundlage von Belegen.
Wenn Sie ein neues Produkt vorbereiten, kann unser SaaS- und MVP-Team mit Ihnen eine kurze Discovery durchführen, Weg und Experiment definieren und die erste Version mit den oben beschriebenen Grundlagen bauen. Unsere UX- und UI-Designer prototypen den Weg, bevor eine Zeile Code entsteht. Erzählen Sie uns von Ihrer Idee.