- Komplex gewordene Produkte lassen sich oft nicht durch noch mehr Erklärungen verbessern, sondern durch das Entfernen unnötiger Elemente; der Fall des Preisrechners von Pinecone zeigt das
- Der Preisrechner sollte nutzungsbasierte Kosten vorab abschätzbar machen, doch schon kleine Eingabefehler konnten die erwarteten Kosten um bis zu das 1.000-Fache aufblähen und Registrierungen verhindern
- Intern versuchte man, das Problem mit Erklärungen und Standardwerten zu beheben, doch jede Korrektur erzeugte neue Verwirrung; in einem eigenen Slack-Channel sammelten sich über 550 Nachrichten
- In einem A/B-Test, bei dem der Rechner entfernt wurde, hatten Besucher ohne Anzeige des Rechners eine um 16 % höhere Wahrscheinlichkeit, sich zu registrieren, und eine um 90 % höhere Wahrscheinlichkeit, eine Anfrage zu stellen; mehr Support-Tickets zu Preisen gab es nicht
- Ein einmal hinzugefügtes Element bleibt leicht bestehen, selbst wenn sein Wert sinkt; deshalb sollte man in Produkten, Projekten und Prozessen bewusst prüfen, ob große Bestandteile entfernt werden sollten
Fallbeispiel: Entfernung des Pinecone-Preisrechners
- Da es bei Pinecones nutzungsbasierter Preisgestaltung für Nutzer schwierig ist, die tatsächlichen Kosten im Voraus genau zu kennen, platzierte Pinecone auf der Preisseite einen Kostenrechner
- Gespräche mit potenziellen Nutzern zeigten, dass manche Nutzer nach sehr hohen Kostenschätzungen im Rechner auf eine Registrierung verzichteten
- Der betreffende Anwendungsfall war nach Pinecone-Maßstäben eher klein
- Der Rechner war deutlich verwirrender und sensibler als erwartet
- Schon ein kleines Missverständnis oder eine falsche Eingabe konnte die erwarteten Kosten um bis zu das 1.000-Fache übertreiben
- Der Rechner gab Nutzern eine falsche Sicherheit, und sie behandelten den Wert des Rechners wie tatsächliche Kosten, ohne die Dokumentation zu prüfen, beim Team nachzufragen oder ihn durch eigene Nutzung zu verifizieren
- Als schnelle Reaktion wurden Erklärungen, Haftungsausschlüsse, Details und Standardwerte ergänzt, doch der Versuch, eine Verwirrung zu reduzieren, erzeugte eine andere
- Auch die internen Diskussionen nahmen zu: In einem eigenen Slack-Channel sammelten sich über 550 Nachrichten, und viel Zeit floss in Meetings und Dokumentation
- Eine Person fragte: „Brauchen wir den Rechner wirklich?“, ging damit zunächst aber in der Mehrheitsmeinung unter
- Anschließend wurde ein A/B-Test durchgeführt, um zu prüfen, ob durch das Entfernen des Rechners und der dadurch verursachten Probleme auch Wert verloren ginge
- Besucher, die den Rechner nicht sahen, hatten eine um 16 % höhere Wahrscheinlichkeit, sich zu registrieren, als Besucher, die ihn sahen
- Die Wahrscheinlichkeit, eine Anfrage zu stellen, war um 90 % höher
- Es gab keinen Anstieg preisbezogener Support-Tickets
- In einer internen Umfrage erwarteten 7 von 10 Mitarbeitenden, dass die Version mit Rechner besser abschneiden würde; das Testergebnis zeigte jedoch das Gegenteil
Warum Entfernen schwierig ist
- Viele Organisationen denken bei der Lösung von Problemen zuerst an Hinzufügen statt an Weglassen
- Selbst wenn Entfernen große Vorteile bringen kann, ist es selten die intuitive Option
- Als einschlägige Studie wird People systematically overlook subtractive changes zitiert
- Auch Anreizsysteme sind in der Regel darauf ausgerichtet, etwas hinzuzufügen; für Entfernen gibt es eher selten Anreize
- Als Beispiel dafür, dass auch Entfernen belohnt werden sollte, wird zusätzlich Negative 2000 Lines Of Code angeführt
- Wer sich stark dafür eingesetzt hat, ein bestimmtes Element hinzuzufügen, tut sich schwer damit einzugestehen, dass es keinen Mehrwert schafft
- Wenn man ein Element entfernen will, für dessen Ergänzung jemand anderes plädiert hatte, kann das wie ein Angriff auf dessen Urteil oder Arbeit wirken; daher lässt man es oft bestehen
- Oft wird angenommen, dass etwas, das bereits existiert, aus gutem Grund existiert, und es wird nicht erneut überprüft
- Wenn man sich an den Status quo gewöhnt hat, lehnt man Veränderung an sich ab, bevor man ausreichend über Entfernen nachdenkt
- Vereinfachung durch das konsequente Abschneiden nicht wesentlicher Elemente kann zu besseren Kundenreaktionsraten, zuverlässigeren Systemen sowie schnellerem Wachstum und höheren Umsätzen führen
- Statt kleiner Kürzungen braucht es Entscheidungen, große Teile von Projekten, Produkten und Prozessen zu entfernen; je stärker der Widerstand im Team gegen eine Entfernung ist, desto größer kann der verborgene Nutzen sein
1 Kommentare
Kommentare auf Hacker News
Ich weiß nicht, ob dieser Rechner gut oder schlecht war, aber die Begründung wirkt auf den ersten Blick ziemlich unsinnig.
Es ist doch klar, dass die Zahl der Anmeldungen steigt, wenn man den Nutzern verbirgt, dass die Produktkosten hoch sein können. Ob es für sie tatsächlich besser wurde, hängt davon ab, ob sie später eine unerfreuliche Rechnung bekommen; das lässt sich mit einem kurzen A/B-Test auf der Registrierungsseite nicht herausfinden.
Man sieht auch oft Beispiele nach dem Muster: Wenn man Informationen aus Snippets in Suchergebnissen entfernt, steigt die Klickrate. Natürlich gibt es mehr Klicks, wenn man nun klicken muss, um die Informationen zu sehen, die vorher schon im Snippet standen. Welche Variante tatsächlich besser ist, gerät dabei in Vergessenheit.
Das Dilemma war: „Wie behebt man solche Fälle?“, und die Lösung lautete: „Schaffen wir den vermurksten Rechner ab.“ Man hat nicht die 1000-fachen Kosten versteckt, sondern vermieden, Nutzer wegen falscher 1000-facher Schätzungen zu verlieren.
Ein Beispiel sind Autohändler, die es erschweren, Preise online zu prüfen, und stattdessen zu E-Mails oder Besuchen drängen. Ein Rechner erleichtert Vergleichskäufe, und viele Unternehmen mögen das nicht. Ob bewusst oder nicht: Dieses Motiv sollte man berücksichtigen.
Wenn man Nutzern gegenüber transparent ist, wird es zwangsläufig verwirrender. Denn der Vergleichsmaßstab selbst behandelt Nutzer wie dummes Vieh, das man zur Schlachtbank treiben kann. Nach diesem Maßstab erzeugt jede Funktion, die Nutzer als denkende Menschen behandelt, Verwirrung und schadet der Conversion Rate.
Natürlich sah die Preisseite dadurch hässlich aus, aber das war egal, weil „die Anmeldungen steigen“. In diesem Fall kann ein Rechner für Menschen, die mit der Terminologie nicht vertraut sind, zwar belastend sein, aber die intuitive Entscheidung hätte zuerst lauten müssen: „Wie vereinfachen wir das?“ Diese A/B-Test-Kultur, in der alles statistisch analysiert und bewiesen werden muss, ist nicht besonders gut.
Wie will man später testen, ob Nutzer zufrieden oder unzufrieden sind, wenn sie von Anfang an gar nicht bleiben? Wenn man den Loop schließt und das Engagement erhöht, steigt auch die Chance, Kunden durch spätere Interaktionen richtig aufzuklären und zufriedenzustellen.
Ich habe den Beitrag empfohlen, weil ich die große Weisheit darin verbreiten wollte, aber die Grenzen können schnell verschwimmen.
Die Denkweise „Verschwindet etwas Wertvolles, wenn wir diesen Teil entfernen?“ hat sich bei frühen Projekten gelegentlich negativ ausgewirkt. Besonders bei Code und Daten ist zukünftiger Wert schwer einzuschätzen.
Einmal hatte ich in einem neuen Projekt ein erstes SQL-Schema mit zusätzlichen Metadaten-Spalten für Beitrags-Tags erstellt; in der Woche darauf entfernte ein Senior Engineer alles mit Verweis auf das YAGNI-Prinzip. Da es damals nicht auf der Roadmap stand, war das technisch gesehen richtig, aber die ursprüngliche Arbeit hatte etwa eine Stunde gedauert, und die Kosten, die Daten beizubehalten, lagen praktisch bei null.
Ein Jahr später war ich am Ende derjenige, der eine Funktion baute, die diese Spalten brauchte, und nun musste ich dieselbe Arbeit noch einmal machen, inklusive Migration einer Produktionsdatenbank mit Nutzern. Deshalb sollte man umgekehrt auch fragen: „Entsteht etwas Wertvolles, wenn wir diesen Teil entfernen?“ In diesem Artikel war die Antwort klar, in meinem Fall nicht.
Ich erinnere mich, dass SpaceX eine Kennzahl hat, die ein ähnliches Konzept erfasst: den Anteil entfernter Funktionen, die ein zweites Mal wieder hinzugefügt werden. Wenn alle entfernten Funktionen wieder hinzugefügt werden, hat man eine Feature-Rückfallquote von 100 % und schneidet zu oft weg; 70 % sind auch hoch, 30 % ebenfalls.
Aber 0 % ist auch schlecht. Wenn man nicht ausreichend versucht, unnötige Funktionen zu entfernen, wird das Produkt am Ende aufgebläht. In der Frühphase eines Produkts dürfte diese Quote höher sein, und mit zunehmender Reife sollte sie idealerweise auf einen niedrigen, aber nicht null betragenden Wert sinken.
Da man zum aktuellen Zeitpunkt nicht genau wissen kann, welche exakte Menge an Funktionen für das beste Produkt nötig ist, ist ein probabilistischer Ansatz beim Entfernen unnötiger Dinge in Ordnung. Wenn nötig, fügt man sie wieder hinzu; solange das nicht zu oft passiert, gibt es keinen Grund, die ursprüngliche Entfernungsentscheidung anzuzweifeln.
Oder man könnte, statt beides in der Realität auszuprobieren und auf die Ergebnisse zu schauen, sechs Monate lang in Meetings über Hypothesen und Proxy-Metriken für unausgesprochene Vorannahmen diskutieren.
Dann heißt es: „Dürfen wir sie benutzen? Dürfen wir sie löschen?“, und irgendjemand denkt an Knight Capital, wo die Wiederverwendung eines alten Feldes in einer großen Katastrophe endete. Deshalb wirkt es immer sicherer, bestehende Felder stehen zu lassen, und am Ende hat man
metadataundmetadata_1. Im nächsten Jahr weiß niemand mehr, warum es zwei Metadatenfelder gibt, und alles wird noch verwirrender.Die schlimmste Codebasis, mit der ich zu tun hatte, war auf komplexe zukünftige Anwendungsfälle hin entworfen. Auch in diesem Beispiel brauchte die Codebasis die Spalte erst ein Jahr später. Deshalb halte ich es für den richtigen Präzedenzfall, alle Codefragmente zu entfernen, die zukünftige Bedürfnisse antizipieren. Selbst wenn sie am Ende wieder gebraucht werden.
Für die einen ist es voreilige Optimierung, für andere: „Ich habe dieses Muster schon einmal gesehen und füge hinzu, was ich damals gern gehabt hätte.“ Es scheint keine zuverlässige Methode zu geben, um zu unterscheiden, welche Seite recht hat.
In der beschriebenen Situation gibt es im Wesentlichen drei mögliche Ergebnisse. Erstens: Das Feld wird genau in der ursprünglich implementierten Form nützlich. Zweitens: Die Funktion wird implementiert, aber mit einem anderen Feld oder einer anderen Umsetzung. Drittens: Die Funktion wird gar nicht implementiert.
Selbst wenn man die Wahrscheinlichkeiten der drei Optionen gleich ansetzt, ist das Vorab-Anlegen nur in einem Drittel der Fälle ein Gewinn. Man sollte auch bedenken, wie viel kognitiver Aufwand in der Zwischenzeit entstanden wäre, um sicherzustellen, dass andere implementierte Funktionen korrekt mit der Metadaten-Spalte zusammenarbeiten.
Diesmal lagst du mit deiner Einschätzung richtig und hattest ein ausgezeichnetes Verständnis des Projekts; ob die Entscheidung richtig war, muss man aber anhand der damals verfügbaren Informationen beurteilen, nicht mit vollständigem Wissen im Nachhinein.
Die Passage, dass „bei einer unternehmensinternen Abstimmung 7 von 10 Personen die Version mit Rechner für besser hielten“, ist interessant und eine typische Dynamik.
Insgesamt war es ein guter Artikel, aber dieser Punkt hätte stärker betont werden können. Wenn 30 % der Beteiligten den Rechner negativ sehen, ist das ein Signal für ein potenziell großes Problem, selbst wenn die Mehrheit ihn okay findet.
Hier muss man auf Politik achten. Ohne politischen Nutzen wollen Menschen normalerweise kein anderes Team kritisieren. Wenn man also im Unternehmen fragt: „Hat das, was unser Team gebaut hat, unterm Strich einen positiven Effekt?“, lautet die Standardantwort leicht „ja“, weil niemand unnötig Streit auslösen will.
Wenn in so einer Situation 30 % die Möglichkeit sehen, dass Wert vernichtet wird, ist das viel wichtiger, als es zunächst scheint. Man sollte ziemlich gründlich prüfen, warum sie das so sehen. In diesem Fall war man sich dessen tatsächlich bewusst und es ging gut aus, aber dieses Abstimmungsergebnis war von Anfang an ein Hinweis auf ein ernstes Problem.
Wenn Interessen hineinspielen, wird es noch komplizierter. Sales will alle möglichen Dark Patterns einschalten, während der Support es vielleicht leid ist, Rückerstattungen zu bearbeiten, weil automatisch eine Garantieverlängerung in den Warenkorb gelegt wurde.
Ich fand die Stelle im Artikel amüsant, in der es hieß, das Entfernen des Rechners könne für Nutzer besser sein, weil dann mehr Käufe abgeschlossen würden. Vielleicht war es für den Nutzer aber gerade die richtige Entscheidung, nach einem angemessenen Preisschock abzuspringen – das wurde einfach ignoriert.
Stell dir vor, der Code des Rechners ist im Vergleich zum Rest des Projekts ein Chaos, nutzt alte Bibliotheken, geht bei Updates kaputt, hat Sicherheitslücken, verbraucht ungewöhnlich viele Ressourcen und zerstört das Build-System. Niemand will sich damit befassen.
Wenn man in dieser Situation fragt, ob das eine gute Idee ist, würden die meisten „nein“ sagen und hoffen, das Chaos loszuwerden. Dann sind 70 % ein sehr guter Wert. Wenn es dagegen ein Feature ist, an dem die Leute gern arbeiten, sind 70 % ein wirklich schlechter Wert.
Natürlich könnten sie das gedacht haben, aber das ist ein ziemlich großer Sprung. Sie könnten auch geglaubt haben, dass es kaum einen Unterschied macht, oder vermutet haben, dass die Performance niedriger ist, weil der Rechner in manchen Fällen falsche Antworten liefert.
Die allgemeine Botschaft ist interessant, aber an dieser Stelle bin ich etwas ins Stocken geraten.
Bedeutet „schon ein kleines Missverständnis oder eine kleine Fehleingabe konnte die Schätzung um bis zu den Faktor 1000 überhöhen“ auch, dass man in der tatsächlichen Nutzung bei einem kleinen Missverständnis oder einer falschen Bewertung der Metriken am Ende 1000-mal höhere Kosten als geplant zahlt?
Bei Online-Abrechnungssystemen ist das durchaus realistisch. Ich habe einmal einen GCP-Prototyp falsch konfiguriert und dachte, es würden etwa 2–3 Dollar werden; nachdem ich ein paar Tage nicht aufgepasst hatte, kam eine Rechnung über mehr als 100 Dollar.
Wenn schon eine kleine Änderung am Slider den erwarteten Preis absurd steigen lässt, ist verständlich, dass Kunden abspringen. Das Tool zu entfernen hilft vielleicht bei der Anmeldung, hilft Kunden aber nicht, wenn sie später auf genau solche Probleme stoßen.
Ein Nutzer dachte, Queries pro Sekunde berechne man als Anzahl der Suchvorgänge × top-k jeder Suche. top-k ist die Anzahl der Ergebnisse, die man zurückbekommen möchte. Wenn top-k also 10 ist, trägt man bei Queries pro Sekunde einen zehnmal höheren Wert als tatsächlich ein und sieht eine Schätzung, die etwa zehnmal höher ist als die reale Rechnung.
Ein anderer Nutzer dachte, die Anzahl der Vektoren ergebe sich aus Anzahl der Embeddings × Anzahl der Dimensionen pro Embedding. 1.536 ist eine häufige Dimensionszahl, daher war der Eingabewert buchstäblich 1.536-mal zu hoch. Die tatsächliche Nutzung wird von Pinecone korrekt berechnet, also würde sie nicht so hoch abgerechnet.
Die Vektordimension ist für AI Engineers ein Grundbegriff, und QPS ist für DB-Administratoren eine grundlegende Kennzahl, aber bei Pinecone gibt es viele Nutzer, für die AI neu ist, oder Datenbankadministration neu ist, oder beides.
Der Autor sollte seinen eigenen Rat befolgen. Er sollte das mitten im Artikel eingeschobene „Psst... Get the next post in your inbox“ entfernen und auch den dämlichen Button, der beim Scrollen mitwandert.
Ich habe auf dieser Seite allein fünf verschiedene Möglichkeiten gezählt, zu abonnieren. Braucht es wirklich fünf? Muss man sie einem mitten im Inhalt vors Gesicht halten? Glaubt man, dass man mehr Abonnenten bekommt, wenn man Menschen unterbricht und nervt? Will man solche Abonnenten überhaupt?
Etwas zu entfernen ist meistens klar. Man muss nur aus dem grubenartigen Denken von „mehr, mehr, mehr, Geld verdienen, Kunden anlocken“ herauskommen und sich fragen: „Was ist richtig, wenn wir Nutzer respektieren wollen, und wie können wir ihnen helfen, indem wir sie als Menschen behandeln statt als Geldbeutel, die man ausquetscht?“
Man sollte im Kopf behalten, dass die meisten Unternehmen existieren, um Geld zu verdienen, nicht um HN-Lesern ein angenehmes Erlebnis zu bieten.
Was es heißt, Nutzer zu respektieren, ist eine separate, aber nicht völlig unabhängige Frage.
Dass ein eigener Slack-Channel entstand, sich dort über 550 Nachrichten mit Meinungen aus dem ganzen Unternehmen ansammelten und man Dutzende Stunden in Meetings sowie Tausende Wörter darauf verwendete, was man noch hinzufügen müsste, um den Rechner zu reparieren, ist ein Symptom von Überbesetzung.
Wenn es zu viele Leute gibt, geht Eigenverantwortung verloren. Wenn man vergisst, was wirklich wichtig ist, und das Gefühl hat, einen Konsens per Komitee herstellen zu müssen, dann hat man zu viele Leute.
Design per Komitee bleibt immerhin auf das Komitee beschränkt.
Wäre es nicht besser, gleich das Preismodell selbst zu entfernen, das so komplex ist, dass Kunden es nicht sinnvoll modellieren können?
Wenn Option A also x Dollar kostet und Option B 10x Dollar, und die meisten Nutzer irrtümlich glauben, sie bräuchten B, dann wird der Rechner zu einem irreführenden Tool.
Ich mag „Preis auf Anfrage“ ziemlich. Für Nutzer, die schnell eine grobe Preisordnung wissen wollen, ist es nervig, aber es hilft dabei zu erkennen, wann Standardpreise oder Preise, die sich online schwer erklären lassen, verhandelbar sein könnten. Man kann damit auch Fälle abfangen, in denen Nutzer sonst einfach weitergezogen wären. Natürlich passt das nicht für die meisten E-Commerce-Szenarien.
In unserem Unternehmen gibt es etwa 250 Produkte, und 5 davon sind für 80 % des Umsatzes verantwortlich.
Die Entwicklungsteams dieser 5 Produkte kommen kaum mit Bugfixes hinterher und haben Mühe, wichtige neue Funktionen hinzuzufügen. Ganz gleich, wer etwas anfragt: Überhaupt etwas auf die Roadmap zu bekommen, ist ein aussichtsloser Kampf.
Das Unternehmen hat Tausende Entwickler, aber die meisten arbeiten an Produkten, die kaum zum Umsatz beitragen.
Es scheint offensichtlich, dass man, um voranzukommen, die meisten Produkte streichen und die Teams neu ausrichten müsste, damit sie die verbleibenden zentralen Umsatzprodukte vorantreiben. Aber das ist nicht passiert, und es gibt weder Anzeichen noch Gerüchte, dass es passieren wird. Unternehmenspolitik ist wirklich brutal.
Ich habe eine ähnliche Erfahrung gemacht. Auf einer Website mit mehreren ziemlich ähnlich wirkenden Produkten befürchteten wir, dass es den Leuten schwerfällt zu entscheiden, was sie kaufen sollen, und dass sie deshalb gar nichts kaufen.
Also haben wir ein Produkt-Empfehlungs-Applet gebaut, bei dem Nutzer ein paar Fragen beantworten und dann ein oder zwei am besten passende Produkte empfohlen bekommen. Es war einiges an Arbeit, es richtig hinzubekommen, aber nach der Fertigstellung funktionierte es gut.
Als wir es auf die Website stellten, brach die Conversion Rate ein. Ein A/B-Test zeigte eindeutig, dass es der Conversion Rate schadete. Warum es schadete, weiß ich bis heute nicht, aber es war tatsächlich so. Also verschoben wir es von der Startseite in den FAQ-Bereich, wo es fast niemand mehr nutzte.
Vielleicht waren die Leute unentschlossen, und es hat ihnen die Mühe erspart, es durch eigenes Ausprobieren herauszufinden.
Wenn es ein Service war, hätte vielleicht eine Amazon-Prime-Strategie funktioniert: bei Unsicherheit erst einmal anmelden und später den Sunk-Cost-Fehlschluss ausnutzen. Oder ohne Applet hätten sie sich vielleicht in der Hoffnung angemeldet, dass die günstigste Version ausreicht, während das Applet diese Hoffnung sofort zunichtemachte.
Bei einem physischen Produkt hat es ihnen womöglich geholfen, einen schlechten Kauf zu vermeiden.
Ich würde nicht erwarten, dass man so etwas in den FAQ sucht. Im Footer vielleicht, aber nicht in den FAQ.
Eine interessante Fallstudie, aber bei den weitergehenden Implikationen bin ich skeptisch. Pinecone ist im Vergleich zu anderen Vektordatenbank-Services bekanntlich teuer. Wenn man die Preise direkt vergleicht, gibt es am Markt mehrere bessere Optionen.
Den Rechner zu entfernen, löst das Kernproblem nicht. Es verschleiert die Kosten nur und erschwert es Nutzern, Optionen von Anfang an zu vergleichen. Aus meiner Sicht reduziert es den Vergleichsschritt und kann dazu führen, dass mehr unzureichend informierte Nutzer Daten hochladen, ohne die Preisfolgen vollständig zu verstehen.
Vereinfachung kann wertvoll sein, aber in diesem Fall scheint sie eher dem Unternehmen als den Nutzern zu nützen. Statt den Rechner komplett zu entfernen, wäre es womöglich besser gewesen, seine Genauigkeit und Benutzerfreundlichkeit zu verbessern. Gerade bei B2B-Services, deren Kosten schnell steigen können, ist Preistransparenz wichtig.