Sechs Wochen sind für einen B2B-SaaS-MVP knapp, aber nicht unrealistisch — vorausgesetzt, man versteht, was ein MVP beantworten soll. Er soll nicht zeigen, dass man bauen kann. Er soll herausfinden, ob jemand für die Lösung eines Problems zahlt.
Die meisten Verzögerungen entstehen nicht beim Bauen, sondern beim Aushandeln des Umfangs mit sich selbst.
Was den Umfang tatsächlich sprengt
Drei Dinge fressen in B2B-Produkten überproportional Zeit, und alle drei wirken auf den ersten Blick unverzichtbar.
Das erste sind feingranulare Rollen und Rechte. Der Wunsch, von Anfang an Administratoren, Bearbeiter und Betrachter zu unterscheiden, ist verständlich und kostet mehr als jede Fachfunktion. Für einen MVP genügt fast immer eine einzige Rolle pro Konto.
Das zweite sind Einstellungen. Jede Option, die konfigurierbar sein soll, verdoppelt die Zustände, die funktionieren müssen. Eine getroffene Entscheidung ist schneller als eine Einstellung, die sie offenlässt.
Das dritte sind Integrationen. Sie klingen nach wenig Aufwand und sind es nie, weil fremde Schnittstellen eigene Fehlerfälle, Grenzen und Authentifizierungswege mitbringen.
Was nicht weggelassen werden darf
Umgekehrt gibt es Dinge, deren Fehlen den MVP wertlos macht. Dazu zählt an erster Stelle eine funktionierende Zahlungsstrecke. Ein Produkt ohne Möglichkeit zu zahlen beantwortet die Frage nicht, für die es gebaut wurde.
Ebenfalls unverzichtbar ist ein Weg, Konten samt Daten zu löschen. Rechtlich erforderlich und nachträglich schwer einzubauen, wenn das Datenmodell es nicht vorsieht.
Und drittens: eine Möglichkeit zu erfahren, wenn etwas kaputt ist. Ohne Fehlererfassung merkt man Ausfälle daran, dass niemand mehr kommt.
Eine Wochenaufteilung, die sich bewährt hat
Die erste Woche gehört nicht dem Code, sondern der Festlegung: Welche eine Aufgabe löst das Produkt, für wen, und was ist der kleinste Weg von der Registrierung bis zu dem Moment, in dem diese Person einen Nutzen sieht. Alles, was auf diesem Weg nicht liegt, ist nicht Teil des MVP.
Die zweite und dritte Woche gehören dem Fundament: Konto, Zugang, Datenmodell, Mandantentrennung. Das sind die Teile, die später am teuersten zu ändern sind.
Vierte und fünfte Woche gehören der Fachfunktion — dem eigentlichen Grund, warum jemand das Produkt benutzt.
Die sechste Woche gehört der Zahlungsstrecke, den rechtlichen Dokumenten und dem Durchspielen der Abläufe. Diese Woche wird regelmässig unterschätzt und dann geopfert, was den Start um Wochen verzögert statt um Tage.
Der Punkt, an dem die meisten Pläne scheitern
Nicht an der Technik, sondern daran, dass in Woche vier eine Funktion dazukommt, weil ein Gespräch mit einem Interessenten sie nahegelegt hat. Das ist gut gemeint und verschiebt den Start.
Die brauchbare Regel: Alles, was nach Woche eins dazukommt, verdrängt etwas anderes. Wenn nichts verdrängt wird, kommt nichts dazu. Das erzwingt die Priorisierung, die sonst nie stattfindet.
Was nach dem Start zuerst kommt
Die ersten Nutzenden liefern mehr Information als jede Planung. Der wertvollste Bau nach dem Start ist deshalb kein Feature, sondern die Fähigkeit zu sehen, wo Menschen aussteigen — an welcher Stelle sie aufhören und nicht wiederkommen.
Erst danach lohnt sich der Ausbau. Was vorher gebaut wird, ist eine Wette auf eine Vermutung.