Die meisten Post-Mortems sind Zeitverschwendung, weil sie die falsche Frage stellen. Man fragt: "Was haben wir falsch gemacht?" Die richtige Frage lautet: "Welche Annahme haben wir nie getestet, weil wir zu beschäftigt waren, das Ding zu bauen?" Das ist keine semantische Spitzfindigkeit. Wer glaubt, ein gescheitertes Produkt sei ein Ausführungsproblem, wird die nächste Version genauso falsch bauen. Nur schneller.
Das ist die These, über die sich erfahrene Produktleute tatsächlich streiten: Ist ein Produkt, das keine Traktion findet, ein Symptom für schlechte Execution oder für eine nie validierte Kernannahme? Die Execution-Fraktion sagt: bessere Onboarding-Flows, klarere Copy, aggressiveres Pricing-Testing. Die Annahmen-Fraktion sagt: Ihr optimiert die Antwort auf eine Frage, die niemand gestellt hat. Ich gehöre seit einem konkreten Fall zur zweiten Fraktion, und ich werde erklären, warum.
Der Fall: Ein B2B-Tool, neun Monate, 140.000 Euro
Ein Team hatte ein Tool gebaut, das kleinen Steuerkanzleien half, Mandanten-Dokumente automatisch zu kategorisieren. Neun Monate Entwicklung, 140.000 Euro Invest, ein technisch sauberes Produkt mit OCR-Pipeline, Kategorisierungs-Engine und einem ordentlichen Dashboard. Nach dem Launch: 23 zahlende Kunden in vier Monaten, bei einem Ziel von 150. Churn nach dem ersten Monat lag bei 40 Prozent.
Das Team wollte an dieser Stelle das Onboarding überarbeiten. Klassischer Reflex. Stattdessen haben wir etwas anderes gemacht: eine Nutzungsdaten-Chirurgie. Das bedeutet konkret, nicht die Aggregatzahlen anzuschauen (Conversion, Retention, MRR), sondern jede einzelne Session der 23 Kunden Schritt für Schritt zu rekonstruieren und mit den ursprünglichen Annahmen im Pitch Deck abzugleichen.
Die ursprüngliche Kernannahme war: "Steuerberater verbringen zu viel Zeit mit manueller Dokumentensortierung und wollen das automatisieren." Die Daten zeigten etwas anderes. Von den 23 Kunden nutzten 19 das Tool ausschließlich für einen einzigen Anwendungsfall, der im Produkt nur als Nebenfunktion existierte: das automatische Erkennen von Duplikaten bei Belegen, die von Mandanten mehrfach per E-Mail und Portal hochgeladen wurden. Die eigentliche Kategorisierungsfunktion, für die 90 Prozent der Entwicklungszeit draufgegangen war, wurde von genau vier Kunden regelmäßig genutzt.
Das ist keine Onboarding-Frage. Das ist eine Beweis dafür, dass die Kernhypothese falsch war, aber eine Nebenhypothese zufällig stimmte.
Die Reparatur kostete keine neun Monate. Wir haben in elf Tagen einen schlanken Fork gebaut, der die Duplikatserkennung als Hauptfunktion nach vorne stellte und die Kategorisierung als optionales Add-on hinter einem Flag versteckte. Kein Rebuild der Pipeline, nur eine Neupriorisierung der bestehenden Bausteine plus ein neues Landing-Page-Narrativ. Ergebnis nach sechs Wochen: 61 neue Anmeldungen, Churn nach Monat eins bei 12 Prozent. Der entscheidende Hebel war nicht neue Technologie, sondern die Differenz zwischen dem, was das Team dachte, wofür das Produkt gebaut wurde, und dem, wofür es tatsächlich benutzt wurde.
Die Rechnung, die diesen Fall von einem gewöhnlichen Pivot unterscheidet: Von den 140.000 Euro Invest waren schätzungsweise 95.000 Euro in Infrastruktur geflossen, die für beide Versionen des Produkts identisch nutzbar war (Auth, Storage, OCR-Basis, Billing). Nur etwa 45.000 Euro waren spezifisch für die falsche Kernannahme verbrannt worden, also die Kategorisierungs-Engine, die nun als Nice-to-have weiterlebte. Das ist der Unterschied zwischen "wir haben 140.000 Euro verloren" und "wir haben 45.000 Euro Lehrgeld bezahlt und 95.000 Euro Infrastruktur weiterverwendet." Diese Differenzierung ist der eigentliche Wert der Übung. Sie verändert, wie ein Team über sich selbst denkt, und damit, ob es überhaupt die Energie für eine Korrektur aufbringt.
Der Fehlerfall: Wenn die Chirurgie zur Bestätigungssuche wird
Hier liegt die Falle, in die auch erfahrene Teams tappen. Nutzungsdaten-Chirurgie funktioniert nur, wenn man bereit ist, unangenehme Muster zu akzeptieren, die dem eigenen Ego widersprechen. Der häufigste Fehlmodus: Das Team findet in den Daten ein Muster, das die ursprüngliche Vision bestätigt, statt eines, das sie widerlegt, und optimiert dann selektiv auf dieses Muster, weil es sich weniger nach Niederlage anfühlt.
In einem anderen Projekt, das ich begleitet habe, ein Marktplatz für Freelance-Designer, zeigten die Daten, dass ein kleiner Teil der Nutzer (unter 8 Prozent) das Produkt exakt wie geplant nutzte. Das Team klammerte sich an diese 8 Prozent als Beweis, dass die Idee grundsätzlich richtig sei und nur die restlichen 92 Prozent "noch nicht verstanden hätten, wie wertvoll das Produkt ist". Das ist keine Annahmen-Chirurgie, das ist Bestätigungsfischerei mit Datentabellen als Alibi. Neun weitere Monate wurden investiert, um diese 8 Prozent zu bedienen, bevor das Produkt endgültig eingestellt wurde.
Der Unterschied zwischen dem Steuerkanzlei-Fall und diesem Marktplatz-Fall ist nicht die Datenqualität, sondern die Bereitschaft, ein Mehrheitsmuster als Wahrheit zu akzeptieren, auch wenn es die ursprüngliche Gründungsgeschichte entwertet. Die Steuerkanzlei-Gründer mussten akzeptieren, dass ihr eigentliches Produkt ein Nebenprodukt war. Das kostet Ego. Wer diesen Schritt nicht geht, betreibt keine Chirurgie, sondern Kosmetik.
Was daraus für die Praxis folgt
Die praktische Konsequenz ist ein Report, kein Meeting. Meetings erzeugen Konsens durch Ermüdung. Ein schriftlicher Report, der jede ursprüngliche Annahme einzeln gegen tatsächliches Nutzerverhalten stellt, mit Zeitstempeln und Sessionpfaden statt Aggregaten, erzwingt eine andere Art von Ehrlichkeit. Genau diese Struktur, inklusive der Fragenliste, die man an die eigenen
