Das Feature, das niemand brauchte

Der Launch, auf den niemand wartete

Wir hatten Wochen in diese eine Funktion gesteckt. Sie war durchdacht, sauber gebaut, gründlich getestet, und wir waren sicher, dass unsere Nutzer sie lieben würden. Am Tag, an dem sie live ging, lehnten wir uns kurz zurück und warteten auf die Reaktion. Es kam keine. Keine Begeisterung, keine Beschwerde, einfach nichts. Die Zahlen zeigten in den Tagen danach, was wir nicht wahrhaben wollten: Fast niemand benutzte das, woran wir am längsten gearbeitet hatten.

Dieser Text handelt von genau dieser Funktion, gebaut an einem unserer eigenen Produkte. Wir erzählen ihn nicht, um uns zu geisseln, sondern weil er eine der nützlichsten Lektionen unserer Produktarbeit enthält. Wer selbst Produkte betreibt, läuft genau in solche Wände, und die einzige Frage ist, ob man die richtige Lehre daraus zieht. Wir haben sie teuer bezahlt, damit du sie günstiger haben kannst.

Warum wir so sicher waren

Die Funktion entstand aus einer Überzeugung, nicht aus einer Beobachtung. Wir sassen zusammen, jemand sagte einen klugen Satz, und innerhalb einer halben Stunde stand fest: Das müssen wir bauen. Es klang einleuchtend, es passte zu unserer Vorstellung vom Produkt, und niemand im Raum widersprach. Genau diese Mischung aus innerer Logik und fehlendem Widerspruch ist die gefährlichste Ausgangslage für ein Feature.

Was wir übersprangen, war der Schritt dazwischen: nachzusehen, ob unsere Nutzer dieses Problem überhaupt hatten. Wir hatten viele Signale, aber wir hörten nur die, die zu unserer Idee passten. Eine beiläufige Bemerkung eines einzelnen Kunden wog in unserem Kopf schwerer als das Schweigen aller anderen. Im Nachhinein war das kein Zufall, sondern ein Muster: Wir hatten die Idee zuerst und suchten danach die Belege, statt umgekehrt.

Das Verführerische daran ist, dass sich das Bauen produktiv anfühlt. Man sieht Fortschritt, der Code wächst, etwas entsteht. Dass dieser sichtbare Fortschritt in die falsche Richtung lief, merkt man nicht beim Bauen, sondern erst, wenn das Fertige auf echte Nutzer trifft. Bis dahin hält einen das gute Gefühl der Bewegung bei der Stange.

Was die Stille uns sagte

Die ausbleibende Nutzung war zuerst eine Kränkung und dann eine Information. Als wir aufhörten, sie persönlich zu nehmen, fingen wir an, sie zu lesen. Eine Funktion, die niemand benutzt, ist keine schlechte Funktion, sie ist eine Antwort auf eine Frage, die niemand gestellt hat. Die Aufgabe war herauszufinden, welche Frage unsere Nutzer stattdessen stellten.

Wir schauten genauer auf das Verhalten im Produkt, dorthin, wo Menschen tatsächlich Zeit verbrachten und wo sie hängenblieben. Das Bild war eindeutig und hatte mit unserer neuen Funktion nichts zu tun. Die Leute rangen mit einer ganz anderen, viel banaleren Stelle, die wir nie als Problem wahrgenommen hatten, weil sie uns selbst nie aufgefallen war. Dort lag die Arbeit, die wirklich gebraucht wurde, während unser stolzes Feature daneben unberührt blieb.

Diese Verschiebung siehst du nur, wenn du auf Handeln schaust statt auf Meinungen. Hätten wir nur gefragt, hätten uns höfliche Nutzer bestätigt, dass die Funktion eine gute Idee sei. Erst der Gebrauch, oder in unserem Fall der ausbleibende Gebrauch, sprach eine klare Sprache. Wie man dieses Verhalten systematisch einsammelt und richtig gewichtet, haben wir danach in Nutzer-Feedback einsammeln und priorisieren festgehalten.

Was uns das Feature gekostet hat

Der offensichtliche Verlust waren die Wochen Entwicklung. Der teurere Verlust war ein anderer: Alles, was wir in diese Funktion steckten, fehlte an der Stelle, die unsere Nutzer wirklich umtrieb. Die grössten Kosten eines unnötigen Features sind nicht die Bauzeit, sondern die Lösung, die in derselben Zeit nicht entstanden ist. Jede Woche am Falschen ist eine Woche weniger am Richtigen.

Dazu kommt ein stiller Folgeschaden. Eine Funktion, die kaum jemand nutzt, verschwindet nicht einfach. Sie will gepflegt, mitgetestet und bei jedem Umbau berücksichtigt werden. So wird aus einer einmaligen Fehlinvestition eine kleine Dauerlast, die das Produkt schwerer macht, ohne ihm zu dienen. Wir haben die Funktion später wieder entfernt, was seinerseits Arbeit war.

Der eigentliche Wert dieser Geschichte liegt darin, dass wir sie an unserem eigenen Produkt erlebt haben, mit unserem eigenen Geld und unserer eigenen Zeit. Genau deshalb ist sie heute Teil unserer Arbeitsweise und nicht nur ein kluger Satz auf einer Folie. Wer die Rechnung selbst bezahlt hat, baut danach anders.

Der Reflex, den wir mitgenommen haben

Die Lehre war nicht, langsamer zu bauen oder weniger zu wagen. Sie war, die billige Prüfung vor die teure Umsetzung zu setzen. Bevor wir heute etwas Grösseres bauen, suchen wir zuerst den günstigsten Weg, herauszufinden, ob es überhaupt gebraucht wird. Das kann ein Gespräch sein, ein simpler Test, ein bewusst grober Zwischenstand, alles, was eine Annahme widerlegen kann, bevor sie Wochen verschlingt.

Konkret heisst das, die Reihenfolge umzudrehen. Nicht Idee, bauen, hoffen, sondern Idee, kleinste mögliche Prüfung, dann erst bauen. Eine Annahme, die einen Tag Prüfung nicht übersteht, hätte auch keine vier Wochen Entwicklung verdient. Diese Disziplin, zuerst den echten Kern zu finden, statt vom Naheliegenden auszugehen, beschreiben wir ausführlich in die erste Funktion und den Produktkern finden.

Dieselbe Logik trägt weit über ein einzelnes Feature hinaus. Sie ist der Kern davon, wie aus einem ersten Produkt eines wird, das wirklich passt, Schritt für Schritt entlang dessen, was Nutzer tun, statt entlang dessen, was wir vermuten. Den ganzen Weg dorthin zeichnen wir in vom MVP zum Product-Market-Fit nach.

Die Lektion in einem Satz

Wenn wir diese Geschichte auf einen Satz eindampfen, dann diesen: Die teuerste Funktion ist die, die perfekt gebaut ist und niemand braucht. Gute Umsetzung rettet keine Idee, die am Bedarf vorbeigeht, sie macht den Irrweg nur sauberer. Deshalb beginnt unsere Arbeit heute nicht mit dem Bauen, sondern mit der Frage, ob das, was gebaut werden soll, dem echten Bedarf entspricht.

Genau diese Reihenfolge bringen wir in jedes Produkt mit, das wir für andere entwickeln. Wir haben den Reflex nicht aus einem Buch, sondern aus einem stillen Launch, der uns wachgerüttelt hat. Wenn du ein Produkt planst und sichergehen willst, dass die Arbeit an der richtigen Stelle landet, ist das der Kern unseres Angebots SaaS-Produktentwicklung. Bevor du Wochen in eine Überzeugung steckst, sprich mit uns, und wir prüfen sie gemeinsam zuerst.