Minimum Worthy Product: das kleinste Produkt, das Vertrauen verdient

Während ich die öffentlichen Oberflächen von ResumeGeni neu baue, stoße ich immer wieder auf dieselbe unbequeme Grenze. Die Version, die technisch funktioniert, ist nicht immer die Version, die ich einem Jobsuchenden vorsetze. Der Parser läuft. Die Ausgabe lädt. Der Ablauf kommt ans Ziel. Und trotzdem verbraucht dieses Erlebnis Vertrauen, statt es zu verdienen. Ich sitze eine Stunde daran, baue die Oberfläche neu, und das Gefühl verschwindet — die Uhr läuft trotzdem weiter.

Genau diese Spannung ist das Thema dieses Textes. Zwei Kräfte ziehen gegeneinander: früh genug zu veröffentlichen, damit das Produkt überhaupt in die Welt kommt, und sich zu weigern, ein Produkt auszuliefern, das das Vertrauen der Nutzer verbraucht. Wer Produkte baut, löst die Spannung meist auf, indem er sich eine Seite aussucht und verteidigt. Die MVP-Kultur entscheidet sich für Tempo, der Perfektionismus für Feinschliff. Beide Antworten scheitern, denn genau die Spannung ist der Kern der Sache.

Minimum Worthy Product setzt einen anderen Maßstab: Veröffentlichen Sie das kleinste Produkt, das Vertrauen verdient — nicht das kleinste Produkt, das Sie als funktionsfähig verteidigen können. „Würdig“ ist die Untergrenze, nicht die Obergrenze. „Minimal“ beschränkt den Umfang, es ist kein Qualitätsrabatt. Wer nach MWP arbeitet, streicht Funktionen, bis das Produkt lieferbar ist, und hält jede verbleibende Oberfläche auf einem Niveau, das der Nutzer spürt. Wer nach MVP arbeitet, macht zu oft das Gegenteil: Er senkt die Qualität, um den Umfang zu retten. Genau diese Vertauschung schlägt sich in den Zahlen nieder, und die Nutzer spüren sie.

TL;DR

MVP war als Lerninstrument gedacht: das kleinste Artefakt, mit dem sich eine echte Hypothese an echten Nutzern prüfen lässt. In der verwässerten Fassung wurde daraus ein Freibrief für schwache Arbeit. Minimum Worthy Product stellt die fehlende Beschränkung wieder her. Erst günstig validieren, dann das kleinste Produkt bauen, das Vertrauen verdient. „Minimal“ schneidet den Umfang. „Würdig“ hält die verbleibende Oberfläche auf einem Niveau, das der Nutzer spürt.

---

Was MVP richtig gemacht hat

Die ursprüngliche Idee hinter MVP war kein Freibrief für schwache Arbeit. Sie gab Gründern ein Mittel an die Hand, um nicht länger monatelang das Falsche zu bauen.¹

Eric Ries schrieb The Lean Startup gegen ein ganz bestimmtes Versagensmuster: Ingenieure, die aufwendige Produkte für Märkte bauten, die es nicht gab. Das MVP war ein Lerninstrument. Man baute das kleinste Artefakt, mit dem sich eine konkrete Hypothese an echten Nutzern prüfen ließ, führte das Experiment durch, maß das Ergebnis und korrigierte sein Bild davon, ob die Hypothese den Kontakt mit der Wirklichkeit überstand. Das „Minimum“ in MVP meinte das Zurückschneiden des Umfangs zugunsten des Lernens, nicht das Preisgeben der Qualität zugunsten der Auslieferung.

Der ursprüngliche Rahmen hält stand. Ich arbeite damit. Meine Sequenz zur Startup-Validierung (Problem, Lösung, Kanal, Umsatz, Skalierung) steht in der Nachfolge von Ries. Wer dafür argumentiert, billig prüfbare Annahmen zu testen, bevor Code entsteht, argumentiert mit demselben Gedanken für MWP nach der Validierung: Zu jeder Phase gehört das passende Instrument. Landingpages und Interviews sind MVPs für die Wünschbarkeit. Prototypen und Spikes sind MVPs für die Machbarkeit. MWP ist der Maßstab, den Sie anlegen, wenn die Belege aus der Validierung vorliegen und Sie das erste echte Ding bauen, dem echte Nutzer vertrauen sollen.

Ich argumentiere also nicht gegen MVP. Ich argumentiere gegen das, was aus MVP in der Praxis geworden ist.

Wo die MVP-Kultur weich geworden ist

Irgendwann unterwegs wurde aus „schnell lernen“ ein „irgendetwas ausliefern“, und diese Vertauschung hat echten Schaden angerichtet.

Drei Umdeutungen haben die ursprüngliche Idee zerbrochen:

1. „Wenn Ihnen die erste Version Ihres Produkts nicht peinlich ist, haben Sie zu spät gestartet“ (der Satz stammt von Reid Hoffman⁴) wurde zum Freibrief, sich für die Machart zu schämen statt für den Umfang. Die ursprüngliche Aussage zielt auf die Zahl der Funktionen: Liefern Sie so wenige Funktionen aus, dass Ihnen später peinlich ist, wie wenig das Produkt konnte. Die verwässerte Fassung zielt auf die Verarbeitung: Liefern Sie so grob aus, dass Ihnen später peinlich ist, wie das Produkt aussah und sich anfühlte. Das ist nicht derselbe Satz.

2. „Schnell ausliefern“ ersetzte „schnell lernen“ als messbares Ergebnis. Lernen ist ein langsamer, lästiger Vorgang, der qualitative Einsicht hervorbringt. Ausliefern ist ein schneller, gut ablesbarer Vorgang, der ein datiertes Artefakt hervorbringt. Wo sich beides nicht auseinanderhalten lässt, gewinnt das Artefakt von allein. Teams liefern jede Woche aus und hören vollständig auf zu lernen, weil niemand misst, was das Team gelernt hat.

3. Das Venture-Muster (Kapital einsammeln, wachsen, aussteigen) belohnt es stärker, irgendetwas auszuliefern, als richtig auszuliefern. Wenn Ihre Aufgabe darin besteht, dem nächsten Geldgeber Schwung vorzuführen, nimmt ein verwässertes Produkt zumindest die Hürde „wir haben geliefert“. Ein verzögertes, aber würdiges Produkt sieht von außen genauso aus wie ein Team, das feststeckt. Das Anreizgefälle zeigt nach unten.

Keine dieser Verwässerungen geht auf MVP zurück, wie es ursprünglich formuliert wurde. Sie sind das, was aus MVP im Mund derer wurde, die eine Rechtfertigung dafür brauchten, schwach auszuliefern.

Nutzer spüren das Ergebnis. In den Zahlen spüren Sie es auch. Das Onboarding wird abgeschlossen, aber zur zweiten Sitzung kommt es nie. Nutzer öffnen die Registrierungs-E-Mail und klicken den Link nie an. Support-Tickets ballen sich um genau die Aufgaben, die das Produkt zu beherrschen behauptet. Die Abwanderungskurve fällt gegen null, statt in einen festen Kern abzuflachen. Das sind keine Randfälle. Das ist der zentrale Preis dafür, auf ein Niveau zu bauen, an das der Nutzer nicht glauben kann.

Minimal heißt nicht unfertig

Minimal beschränkt den Umfang, es ist kein Qualitätsrabatt.

Praktisch heißt das: Definieren Sie den Nutzer. Definieren Sie das eine Ergebnis, das das Produkt zu liefern verspricht. Streichen Sie jede Funktion, die für dieses Ergebnis nicht nötig ist. Und halten Sie dann die verbleibende Oberfläche auf dem vollen Qualitätsniveau. Minimal schneidet den Umfang, bis das Produkt lieferbar ist. Minimal senkt nicht den Maßstab, damit das Produkt früher hinausgeht.

Die beiden Maßstäbe nebeneinander:

Dimension	MVP (in der Praxis)	MWP
Ziel	Irgendetwas ausliefern, um Bewegung zu belegen	Etwas ausliefern, das Nutzervertrauen verdient
Umfang	Kleinstes Artefakt, das sich als funktionsfähig verteidigen lässt	Kleinste Oberfläche, die das validierte Versprechen einlöst
Qualitätsniveau	Funktioniert gut genug, um zu laufen	Das Niveau, das der Nutzer spürt
Abbruchregel	„Wir haben geliefert“	Beide Prüfungen bestanden; nach drei gescheiterten Neubauten wird das Briefing neu gebaut
Erfolgssignal	Datum im Changelog	Fünf Vertrauensindikatoren: zweiter Erfolg, Verhältnis Tag 30 zu Tag 1, Kurvenform der Kohorte, organische Empfehlungen, Qualitätsreibung
Versagensmuster	Ein schwacher erster Eindruck verbrennt Nutzervertrauen	Der Feinschliff wird zum Versteck

Ein durchgerechnetes Beispiel. Das Versprechen von ResumeGeni lautet: ein ATS-tauglicher Lebenslauf, der sauber durch Bewerbermanagementsysteme läuft und einem Jobsuchenden eine echte Chance gibt, bis zum Personalverantwortlichen durchzudringen. Die minimale Fassung dieses Versprechens darf Folgendes weglassen:

• Eigene Vorlagen
• Zusammenarbeit im Team
• Analyse-Dashboards
• Anbindungen an LinkedIn, Indeed oder Jobbörsen
• Versionsverlauf
• Exportformate über eines hinaus

Was die minimale Fassung nicht weglassen darf: das präzise Einlesen des vorhandenen Lebenslaufs, eine ehrliche Einschätzung der Lücken, konkrete Umformulierungen, die wirklich zur Stellenanzeige passen, einen Export, der sich in Word sauber öffnet, und einen Ablauf, bei dem sich der Jobsuchende sicher fühlt. Ohne Vorlagen können Sie ausliefern. Mit vagen Ratschlägen, kaputten Exporten oder Texten, die einem verletzlichen Menschen das Gefühl geben, das Produkt halte ihn für einen Trottel, können Sie es nicht.

Minimal ist ein Messer, das man an das Produkt-Backlog anlegt. Würdig ist ein Messer, das man an die Oberfläche anlegt, die übrig bleibt.

Würdig ist die Untergrenze

Ein würdiges Produkt muss nicht alles enthalten, was Sie sich ausmalen. Alles, was es enthält, muss den Nutzer respektieren.

Würdig heißt im praktischen Sinn: Das Produkt löst das validierte Problem gut genug, dass der Nutzer Vertrauen in die nächste Begegnung mitnimmt. Er erkennt, woran Sie gebaut haben, und glaubt, dass da noch mehr kommt. Die erste Sitzung ist dann keine Prüfung mehr, die man übersteht, sondern ein Handschlag, der die Tür zur zweiten öffnet. Würdige Produkte bauen Vertrauen auf. Halbwegs würdige Produkte verbrauchen es.

Vertrauen lässt sich nicht vortäuschen. Was Nutzer von Ihrem Produkt erwarten, prägen die Produkte, die sie ohnehin schon kennen.⁵ Liegt Ihr Produkt unter diesen Erwartungen — Schaltflächen, die nicht reagieren, Texte, die sich herauswinden, Abläufe, die den Nutzer auf halbem Weg stehen lassen —, registrieren die Nutzer die Lücke, bevor sie sie benennen können. Sie gehen, sie kommen nicht wieder, und keine Reaktivierungs-E-Mail rettet die Sitzung, die sie längst abgeschrieben haben.

Die Frage Ist es würdig? ist keine Geschmacksfrage. Sie ist eine Vertrauensfrage. Die Antwort des Nutzers zeigt sich im Verhalten.

Erst die Validierung, dann die Würdigkeit

Der stärkste Einwand gegen MWP lautet: Über Würdigkeit entscheiden Nutzer im Kontakt mit dem Produkt, nicht die Überzeugung des Machers. Stimmt. MWP ersetzt das Urteil der Nutzer nicht. MWP verhindert, dass Sie validiertes Vertrauen verbrennen, bevor die ersten echten Nutzer überhaupt urteilen können.

Der Kontakt mit Nutzern gehört zur Validierung. Bevor Sie bauen, prüfen Sie, ob das Problem echt ist, ob Ihr Lösungsvorschlag es trifft, ob Sie die Nutzer erreichen und ob sie zahlen. Die Belege liefern Landingpages, Interviews, Concierge-Tests, Prototypen und Wartelisten. Über diese Abfolge habe ich ausführlich geschrieben. Eine Hypothese, die dieses Spießrutenlaufen übersteht, hat sich das Recht verdient, gebaut zu werden.

MWP beginnt nach der Validierung. Die Validierung fragt, ob überhaupt jemand das Versprechen will. MWP fragt, ob die ausgelieferte Oberfläche das Vertrauen verdient, das die Validierung bereits erworben hat. Ob das Urteil trägt, entscheiden die Daten zu Bindung, Weiterempfehlung und Qualitätsreibung.

Wer die Validierung überspringt und das Ergebnis MWP nennt, liefert eine schöne Antwort auf eine Frage, die niemand gestellt hat. Wer MWP überspringt und das Ergebnis „lean“ nennt, liefert ein verwässertes Produkt, das genau das Vertrauen kostet, das die Validierung schon eingebracht hatte.

Die richtige Reihenfolge: erst günstig an echten Nutzern validieren, dann das kleinste würdige Produkt für das validierte Versprechen bauen. Machen Sie beides. Lassen Sie nichts davon aus.

Die zwei Prüfungen: Jiro und Steve

Ein Produkt muss zwei verschiedene Prüfungen bestehen, bevor ich es fertig nenne.

Der Jiro-Test fragt, ob die Arbeit korrekt ist. Belege dafür, dass das Produkt funktioniert. Das Produkt beherrscht seine Randfälle. Die unsichtbaren Details halten. Behauptungen führen konkrete Nachweise an. Kein Herumdrucksen; ich glaube ist kein Beleg. Der Jiro-Test trennt Handwerk von Absichtserklärung. Über die Jiro-Qualitätsphilosophie habe ich mit Blick auf KI-Agenten geschrieben; dieselbe Disziplin gilt für jede Produktoberfläche. Mit der Beweispflicht setze ich diese Prüfung in Code-Berichten praktisch um.

Der Steve-Test fragt, ob die Arbeit es verdient zu existieren. Eine erkennbare Haltung. Stimmigkeit über das gesamte Produkt hinweg. Die Oberfläche wahrt die Würde des Nutzers. Ein Mechanismus für Freude oder Klarheit, den der Leser benennen kann, statt vage darauf zu deuten. Der Steve-Test trennt Produkt von Lagerbestand. Etwas Ausgeliefertes ist nicht automatisch etwas Würdiges. Die vollständige Begründung dafür, dass Geschmack ein technisches System ist, steht in einem eigenen Essay; für diesen Text trägt die praktische Definition oben.

Beide Prüfungen müssen bestanden sein. Fällt Jiro durch, halten Sie an und reparieren Sie. Fällt Steve durch, bauen Sie neu. Fallen beide durch, sitzt das Problem weiter oben, im Briefing.

Wenn das Urteil unsicher ist, gilt die einfachste Frage im ganzen Stapel: Würde ich das ohne Zucken mit meinem Namen unterschreiben? Lautet die Antwort Nein, ist die Arbeit noch nicht würdig.

Der Beleg unter Ihren Füßen: blakecrosley.com

Die Seite, die Sie gerade lesen, begann als kleines Experiment während meines Übergangs ohne vorgezeichneten Weg. Sie ist zugleich Teil des Arguments.

Es gibt kein React. Es gibt kein Tailwind. Es gibt kein webpack, kein Vite, keinen Bundler, keinen Build-Schritt. FastAPI liefert die gesamte Website direkt aus: HTMX, Alpine.js, Jinja2 und schlichtes CSS, nichts dazwischen. Im Build vom 17. April 2026 liegt die erste Seitenübertragung bei 45 bis 60 KB, und Lighthouse meldet 100 von 100 Punkten in Performance, Barrierefreiheit, Best Practices und SEO.³ Die Website läuft in zehn Sprachen, bringt neue Guide- und Blog-Inhalte mit einem einzigen git push von Anfang bis Ende live und enthält nirgendwo im Repository ein einziges node_modules/.

Die MVP-Variante dieser Website wäre dem Standardrat des Jahres 2026 gefolgt: Next.js, Tailwind, Vercel. Sie wäre an einem Wochenende fertig gewesen. Sie wäre in Ordnung gewesen. Sie wären hier gelandet, die Seite hätte in respektabler Zeit geladen. Der Unterschied läge nicht im Können. Der Unterschied läge im Geschmack. Ich habe darüber geschrieben, wie ein perfekter Lighthouse-Score tatsächlich zustande kommt; kurz gesagt: Jedes Kilobyte, das der Leser nicht herunterladen muss, ist eine Form von Respekt.

Die MWP-Variante hat länger gedauert. Sie verlangte, die HTMX-Muster von Grund auf zu schreiben, die Typografie von Hand zu justieren, die Schriften selbst zu hosten, die i18n-Verarbeitung über Cloudflare D1 laufen zu lassen und das Fehlen von Build-Werkzeugen als Funktion zu behandeln. Technisch kann die MWP-Variante nicht mehr als der Standard-Stack. Sie ist absichtsvoller. Und diese Absicht zeigt sich darin, dass es für den Leser weniger Nahtstellen zu bemerken gibt.

Unsichtbares Handwerk. Der Leser sieht die Entscheidungen nicht. Er spürt das Ausbleiben von Reibung. Genau dieses Ausbleiben ist der Mechanismus.

Der Beleg beim Kunden: ResumeGeni

Bei ResumeGeni liegt die Latte höher, denn der Nutzer stöbert nicht. Er versucht, ein Dokument zu verbessern, das darüber entscheiden kann, ob er zum Vorstellungsgespräch eingeladen wird.

Die Validierung von ResumeGeni fiel eindeutig aus: Landingpage, Warteliste, gezielte Beiträge auf Reddit und LinkedIn, 340 E-Mail-Anmeldungen in zwei Wochen, 12 direkte Anfragen, wann das Produkt öffne, und 3 unaufgeforderte Angebote, für einen frühen Zugang zu zahlen.⁷ Die Validierungssequenz sagte: bauen. Zu bauen war die leichte Entscheidung. Wie das Gebaute aussehen würde, war die schwere — und dort hat MWP die eigentliche Arbeit geleistet.

Zwei Arten von Streichungen. Die erste betraf Funktionen: Vorlagen, Zusammenarbeit, Analysen, Dutzende Exportvarianten, Anbindungen an Jobbörsen. Alles gestrichen. Nichts davon gehört zum Versprechen.

Die zweite betraf den Maßstab, den ich für das Verbliebene halten wollte. Der Maßstab wird nicht gestrichen. Der Parser darf nicht schwach sein. Die Ratschläge dürfen nicht vage sein. Die Exporte dürfen nicht kaputt sein. Die Texte dürfen einen verletzlichen Menschen nicht als Conversion-Kennzahl behandeln. Der Ablauf darf niemanden mitten im Prozess stehen lassen, nur weil ich lediglich für den Idealfall Zeit hatte.

Die MVP-Variante hätte einen zehnstufigen Assistenten ausgeliefert, dazu generische Ergebnisse, eine Abo-Schranke im besten Moment und eine Roadmap-Seite, die alles Gestrichene verspricht. Sie hätte funktioniert. Sie hätte vielleicht einige Nutzer einmal konvertiert. Sie hätte der ersten Kohorte aber auch beigebracht, dem Produkt nicht zu trauen, und diese Lektion ist ein schlechtes Fundament für einen so verletzlichen Anwendungsfall.

Die MWP-Variante ist kleiner, als ich sie haben will. Jede gestrichene Funktion werde ich zurückhaben wollen. Der Maßstab lautet: Das Produkt, auf dem die Nutzer landen, respektiert sie. Auf einem anderen Fundament kann ich nicht bauen.

Was Nutzer Ihnen wirklich sagen

Nutzer sagen selten Ich glaube jetzt an dieses Produkt. Ihr Verhalten hinterlässt aber Spuren.⁶

Fünf Signale, die ich beobachte, zugeschnitten auf ein Publikum, das selbst Produkte baut:

1. Quote des zweiten Erfolgs. Der Anteil der aktivierten Nutzer, die zurückkehren und das Kernergebnis innerhalb des natürlichen Nutzungsfensters ein zweites Mal erreichen. Vertrauen entsteht beim zweiten Erfolg, nicht beim ersten. Bei Produkten mit wiederkehrender Nutzung werte ich einen zweiten Erfolg unter 30 % als Signal zum Neubau. Bei episodischen Produkten messen Sie den nächsten natürlichen Nutzungszyklus, statt ein 30-Tage-Fenster zu erzwingen.

2. Bindung an Tag 30 im Verhältnis zur Aktivierung an Tag 1. Mit Reaktivierungs-E-Mails lässt sich die rohe Bindungsrate schönrechnen. Das Verhältnis nicht. Bei Produkten mit wöchentlicher oder monatlicher Nutzung sagt Ihnen das Verhältnis, ob die Aktivierung Vertrauen war oder einmalige Neugier. Unter 0,25 gilt mir als Warnung, unter 0,15 als Urteil.

3. Form der Kohorten-Bindungskurve. Würdige Produkte flachen nach dem frühen Abfall ab. Schwache Produkte fallen weiter. Zeichnen Sie die Kurven; die Form erzählt die Geschichte, die Durchschnittswerte verbergen. Flacht die Kurve nie ab, gibt es keinen Kern von Nutzern, die dem Produkt tatsächlich vertrauen.

4. Anteil organischer Empfehlungen ohne Anreiz. Der Anteil neu aktivierter Nutzer, die über eine direkte Empfehlung, geteilte Ergebnisse oder Mundpropaganda kommen — nicht über bezahlte Kanäle, nicht über die Prämien eines Empfehlungsprogramms. Über würdige Produkte reden Nutzer. Schwache vergessen sie. Hat die Kategorie einen natürlichen Moment zum Teilen und liegen organische Empfehlungen trotzdem unter 10 % der Neugewinnung, verdient sich das Produkt keine Weiterempfehlung.

5. Quote der Qualitätsreibung. Erfassen Sie Rückerstattungen, Wutklicks, Support-Tickets, fehlgeschlagene Exporte und manuelle Korrekturen pro 100 aktivierte Nutzer, nach Kohorte. Diese Quote ist der Schmerz, den das Produkt den Nutzern zufügt, denen es zu dienen behauptet. Sie sollte sinken, während das Produkt reift. Bleibt sie flach oder steigt sie, liegt das Problem am Produkt, nicht am Support-Prozess.

Keines dieser Signale ist eine Eitelkeitskennzahl. Jedes lässt sich schwer fälschen. Jedes verweist auf eine echte Nutzererfahrung, die entweder Vertrauen erworben hat oder eben nicht. Wenn Sie für alle fünf nicht die Zahlen einer konkreten Kohorte nennen können, wissen Sie noch nicht, ob Ihr Produkt würdig ist.

Wann MVP oder Prototyp weiterhin die richtige Wahl sind

MWP ist nicht für jedes Artefakt der richtige Maßstab.

Drei Fälle, in denen die Logik von MVP oder Prototyp weiterhin stimmt:

• Vor der Validierung. Landingpages, Interviews, Concierge-Tests, klickbare Prototypen. Das Ziel ist Lernen, nicht Handwerk. Liefern Sie die hässliche Fassung aus, die die Hypothese prüft. Und zwar heute. Hier ist die Validierungssequenz das richtige Playbook, nicht MWP.

• Machbarkeits-Spikes. Wenn das Unbekannte technisch ist — kann das Modell diese Art von Anfrage in der Latenz beantworten, die ich brauche? hält die API der Last stand? funktioniert der Parser auch bei den seltenen Sonderfällen echter Eingaben? —, bauen Sie das kleinste Wegwerf-Instrument, das die Frage beantwortet. Versuchen Sie nicht, es würdig zu machen. Machen Sie es wahrhaftig.

• Beta-Oberflächen mit Netzwerkeffekt. Marktplätze, Community-Produkte und Werkzeuge mit Netzwerkeffekt brauchen eine echte Nutzerbasis, bevor überhaupt jemand urteilen kann; das richtige Artefakt ist deshalb eine klar gekennzeichnete Beta mit Messung nach Kohorten. Eine Beta zu veröffentlichen ersetzt die würdige Fassung nicht — es ist der einzige Weg, herauszufinden, was würdig hier überhaupt heißt. Kennzeichnen Sie die Oberfläche ehrlich als Beta. Verkaufen Sie sie nicht als v1.

MWP gilt für die erste echte Produktoberfläche. Wenn Sie noch davor stehen — lernen, testen, entdecken —, liegen die richtigen Werkzeuge weiter vorn in der Abfolge.

Die Obergrenze für Neubauten

Ein hoher Maßstab ohne Abbruchregel wird zur Vermeidung.

Die Doktrin, die ich auf jede nicht triviale Arbeit anwende, kennt eine Obergrenze von drei ehrlichen Versuchen.² Ein ehrlicher Versuch heißt: Sie haben die gescheiterte Achse benannt, den konkreten Korrekturschritt festgelegt, den Ansatz wesentlich geändert und die Arbeit erneut an beiden Prüfungen gemessen. Dreimal derselbe Feinschliff zählt nicht als drei Versuche. Er zählt als ein gescheiterter Versuch, dreimal wiederholt.

Wenn nach drei ehrlichen Neubauten kein würdiges Produkt entsteht, liegt es nicht am Handwerk. Das Problem sitzt weiter oben: in der Rahmung, im Umfang, im Briefing oder im Team. Hören Sie auf, die Oberfläche neu zu bauen, und sehen Sie sich die Prämisse an. Manchmal war das Versprechen zu groß für den Umfang, den Sie realistisch auf Niveau halten können. Manchmal war die Validierung weicher, als Sie dachten. Manchmal ist das Problem überhaupt kein Produktproblem.

Die Obergrenze löst zwei entgegengesetzte Fehler. Sie segnet schwache Arbeit nicht ab, und sie verhindert, dass der Feinschliff zum Versteck wird. Das Ziel ist nicht Perfektion. Das Ziel ist würdig und ausgeliefert. Nicht rein und ewig ausstehend.

Perfektionismus ist Handwerk ohne Mut. Wer beim vierten Neubau derselben Oberfläche angekommen ist, baut kein Produkt mehr, sondern benutzt das Projekt als Versteck.

Das Wichtigste in Kürze

Für Gründer und Einzelentwickler: - Validieren Sie günstig, bevor eine Zeile Code entsteht. MWP greift nach der Validierung, wenn der Markt bestätigt ist. - Streichen Sie Funktionen kompromisslos. Halten Sie die verbleibende Oberfläche auf dem vollen Qualitätsniveau. - Liefern Sie aus, sobald es würdig ist. Begrenzen Sie Neubauten auf drei. Danach geht es an das Briefing.

Für Produktverantwortliche und PMs: - Messen Sie Vertrauensindikatoren direkt: Quote des zweiten Erfolgs, Verhältnis der Bindung an Tag 30 zur Aktivierung an Tag 1, Form der Kohortenkurve, Anteil organischer Empfehlungen, Qualitätsreibung pro 100 Nutzer. - Trennen Sie Gespräche über den Umfang von Gesprächen über die Qualität. Über Streichungen am Umfang lässt sich verhandeln, über Abstriche an der Qualität nicht. - Schützen Sie das Erlebnis der ersten Kohorte. Ein verwässerter erster Eindruck bei verletzlichen Nutzern kostet Jahre der Wiedergutmachung.

Für Entwicklungsleiter: - Legen Sie für jede Oberfläche, die Sie ausliefern, eine Jiro-Prüfgrenze und eine Steve-Prüfgrenze fest. Beide müssen bestanden werden. - Planen Sie unsichtbares Handwerk ein. Der Unterschied zwischen „funktioniert“ und „würdig“ steckt meist in den Details, auf die niemand zeigt. - Bauen Sie eine Obergrenze für Neubauten in Ihren Prozess ein, damit sich Perfektionismus nicht länger als Feinschliff tarnt.

Für Designer: - Eine Haltung ist keine Dekoration, sondern der Mechanismus, der das Produkt wiedererkennbar macht. - Eine würdige Oberfläche verweigert Dinge, und zwar sichtbar. Hat das Team nichts verweigert, stimmt der Umfang nicht. - Die entscheidende Prüfung im Zweifel: Würden Sie diese Entscheidung ohne Zucken mit Ihrem Namen unterschreiben?

Schluss: Ausliefern, wenn es Vertrauen verdient

Die leitende Frage in der Produktarbeit lautet nicht Ist es fertig? Die leitende Frage lautet Verdient es zu existieren?

Lautet die Antwort Ja, liefern Sie aus. Lautet sie „noch nicht, aber innerhalb von drei ehrlichen Neubauten wird es so weit sein“, arbeiten Sie weiter. Lautet sie Nein und bleibt sie auch nach drei Versuchen Nein, bauen Sie das Briefing neu, nicht die Oberfläche.

So baue ich jedes Produkt, auf das ich meinen Namen setze. Die MVP-Denkweise optimiert auf Zyklen. Die MWP-Denkweise wächst zu einem Werk zusammen.

Liefern Sie das kleinste Produkt aus, das Sie respektieren können. Vorher nicht. Länger warten auch nicht. Minimal und würdig sind dieselbe Anweisung, gleichzeitig gehalten.

---

FAQ

Was ist ein Minimum Worthy Product?

Ein Minimum Worthy Product ist die kleinste öffentliche Fassung eines validierten Produkts, die Nutzervertrauen erwirbt, statt es zu verbrauchen. Minimal heißt: Der Umfang ist auf das Kernversprechen zusammengeschnitten. Würdig heißt: Die verbleibende Oberfläche erfüllt das Qualitätsniveau, das der Nutzer spürt. Das erste echte Ding, das echte Nutzer zu sehen bekommen, muss ihr Vertrauen verdienen und nicht bloß funktionieren.

Worin unterscheidet sich MWP von MVP?

Ein Minimum Viable Product war ursprünglich ein Lerninstrument: das kleinste Artefakt, um eine konkrete Hypothese zu prüfen. In der Praxis verkam MVP zum Freibrief für schwache Arbeit. Ein Minimum Worthy Product stellt die fehlende Beschränkung wieder her. Die Validierung klärt, ob überhaupt jemand die Sache will — dafür sind MVPs, Landingpages und Interviews da. MWP klärt den Maßstab, den Sie halten, wenn Sie die erste echte Fassung dessen bauen, was die Validierung bestätigt hat.

Wann sollten Teams ein MVP statt MWP einsetzen?

Drei Fälle, in denen die Logik von Minimum Viable Product oder Prototyp weiterhin gilt: vor der Validierung (Landingpages, Interviews, Concierge-Tests, klickbare Prototypen), bei Machbarkeits-Spikes (Wegwerfcode, der Latenz oder Qualität prüft) und bei Produkten mit Netzwerkeffekt, die eine gekennzeichnete Beta mit echten Nutzern brauchen, bevor das Team überhaupt definieren kann, was würdig heißt. MWP gilt für die erste echte Produktoberfläche, nicht für jedes Artefakt davor.

Wie misst man, ob ein Produkt würdig ist?

Über fünf verhaltensbasierte Vertrauensindikatoren statt über Eitelkeitskennzahlen: die Quote des zweiten Erfolgs (Anteil der aktivierten Nutzer, die das Kernergebnis ein zweites Mal erreichen), die Bindung an Tag 30 im Verhältnis zur Aktivierung an Tag 1 (als Verhältnis, nicht absolut), die Form der Kohorten-Bindungskurve (abflachend oder weiter fallend), der Anteil organischer Empfehlungen ohne Anreiz und die Quote der Qualitätsreibung (Rückerstattungen, fehlgeschlagene Exporte, Support-Tickets pro 100 aktivierte Nutzer). Ein würdiges Produkt ist in allen fünf stark; ein schwaches fällt in mindestens einem auf, oft in allen.

---

Die Würdigkeitsprüfung

Ein Entscheidungswerkzeug, um den Rahmen auf Ihre eigene Arbeit anzuwenden. Gehen Sie die fünf Eingaben durch, dann die drei Leitplanken der Doktrin. Keine Punktzahl, keine spielerische Anzeige. Ein Urteil, das die Achse benennt und den nächsten Schritt.

---

Quellen