- Die meisten Nutzer verwenden nur etwa 20 % der Anwendungsfunktionen, die sie tatsächlich brauchen – und diese 20 % sind für jeden anders
- Die übrigen 80 % der Funktionen werden oft als Störfaktor empfunden und verursachen eher Unannehmlichkeiten oder Frust
- Wer Nischenmärkte präzise adressiert, kann eine starke Nutzerbasis aufbauen
- Beispiele wie Kagi, Figma und Notion, die die von großen Unternehmen ignorierten 20 % gut gelöst und daraus einen loyalen Markt geschaffen haben, zeigen neue Marktchancen
- VS Code, Slack und Discord unterstützen durch Erweiterbarkeit und Personalisierung, dass Nutzer ihre eigenen 20 % selbst optimieren können
- Der Kern ist nicht, ein Produkt für alle zu bauen, sondern Werkzeuge zu schaffen, die den jeweils gewünschten Teil tiefgehend zufriedenstellen – und das ist der Weg, Feature Bloat zu vermeiden
Kindheitserfahrungen und die Art, wie Software genutzt wird
- Der Autor hat als Kind beim Verwalten von 2 GB Speicherplatz oft den Computer beschädigt, weil er unnötige Dateien löschte
- Nachdem er wichtige Systemdateien wie
.ini-Dateien gelöscht hatte, musste er Windows und Office 97 von Grund auf neu installieren
- Sein Vater betonte immer, dass Excel unbedingt installiert sein müsse, aber für den Autor war Excel nicht mehr als ein Werkzeug, um Tabellen in Word einzufügen
- Von Excels unzähligen Funktionen war für ihn nur das Kopieren und Einfügen von Tabellen sinnvoll
- Auch ein Bekannter nutzte Excel nur als Haushaltsbuch und fasste andere Funktionen nie an
Für jeden andere 20 %
- Bei der Softwarenutzung gilt die '80/20-Regel': Die meisten Nutzer verwenden nur 20 % der gesamten Funktionen
- Aber die 20 %, auf die sich jeder Nutzer konzentriert, sind unterschiedlich, und jeder hält den von ihm genutzten Teil für den wichtigsten
- Beispiele: In Word werden Tabellen genutzt, Seriendruck aber nicht; in Excel Pivot-Tabellen, aber keine Skripte; in PowerPoint keine Animationen
- Wenn durch neue Funktionen oder UI-Änderungen bei Updates das Gefühl entsteht, dass eine Anwendung langsamer wird oder unnötige Funktionen hinzukommen, führt das zu Unzufriedenheit
- Die ungenutzten 80 % der Funktionen können sogar als Elemente wahrgenommen werden, die den Workflow der eigenen 20 % behindern
Die Sehnsucht nach perfekten Ergebnissen
- Dieses Phänomen zeigt sich nicht nur bei Microsoft, sondern genauso bei anderen IT-Unternehmen
- Wer zum Beispiel in Google Search eine exakte Keyword-Suche möchte, empfindet unnötige Ergebnisse mit verwandten Begriffen eher als frustrierend
- Unternehmen mögen das als „Anforderung von 1 % der Nutzer“ abtun, aber 1 % von 1 Milliarde Menschen sind 10 Millionen – ein gewaltiger Markt
- Kagi zielt auf einen kleinen Markt, den Google übersieht, und differenziert sich dort mit datenschutzorientierter, werbefreier und qualitätsfokussierter Suche
- Wer Lücken großer Unternehmen angreift, kann Nischenmärkte schaffen, die kleine Nutzergruppen zufriedenstellen
- Es ist nicht nötig, alle zufriedenzustellen; möglich ist vielmehr eine Strategie, die die 20-%-Erfahrung einer bestimmten Gruppe perfekt erfüllt
Die vergessenen 20 % finden
- Viele innovative Unternehmen konzentrieren sich gezielt auf bestimmte Nutzergruppen, die große Unternehmen übersehen
- Figma konzentrierte sich darauf, Adobe im Bereich kollaboratives Design zu übertreffen, und Notion etablierte sich als hybrides Tool, das auf die Anforderungen bestimmter Nutzer optimiert ist
- Erfolgreiche Software gewinnt mit der Zeit zwar immer mehr Funktionen, doch dabei entstehen Nischen, in denen die 20 % bestimmter Nutzer untergehen
- Open-Source-Software ist hier besonders stark, weil sich damit Custom Builds für bestimmte Workflows erstellen lassen
- Zum Beispiel könnte man von Blender eine schlanke Version entwickeln, die nur für Architekturvisualisierung gedacht ist
Für die richtigen 20 % entwerfen
- Diese Philosophie ist in VS Code gut umgesetzt
- Die Grundfunktionen konzentrieren sich auf einfache Textbearbeitung, aber über Erweiterungen lässt sich für jeden die gewünschte Entwicklungsumgebung zusammenstellen
- Die Struktur ermöglicht es allen Nutzern, ihre eigenen 20 % zu individualisieren
- Slacks Integrationen und Discord-Bots folgen demselben Prinzip und erlauben es Nutzern, ihre Erfahrung selbst anzupassen
- Die 20 % aller Nutzer von vornherein vorherzusagen ist schwierig, aber mit Erweiterbarkeit und Anpassbarkeit kann jeder seine optimale Nutzung erreichen
Fazit: Statt eines Produkts für alle lieber auf die jeweils „nötigen 20 %“ konzentrieren
- Wenn man versucht, alle Funktionen gleichermaßen gut zu machen, endet das am Ende in Software, die schwerfällig wird und mehr Unzufriedenheit erzeugt
- Wichtig ist, dass jede Funktion für die Nutzer, die genau diese Funktion suchen, perfekt funktioniert
- Da Nutzer ohnehin nur einen Teil des gesamten Funktionsumfangs verwenden, ist es oft wirkungsvoller, sich darauf zu konzentrieren, bestimmte Funktionen wirklich hervorragend zu machen
- Man sollte anerkennen, dass Software auf unvorhergesehene Weise genutzt werden kann, und im Produktdenken Raum für diese Vielfalt lassen
- Größere Zufriedenheit entsteht, wenn man nicht alles den Nutzern aufzwingt, sondern sich in der Entwicklung nur auf die Teile konzentriert, die wirklich geliebt werden
2 Kommentare
Immer gleich stur das Pareto-Prinzip draufzukleben;; Es könnten doch auch 15 % sein, oder? hahaha
Hacker-News-Kommentare
Bei einem SaaS-Unternehmen, bei dem ich gearbeitet habe, haben wir einmal versucht zu analysieren, welche Teilmenge der Funktionen die Nutzer tatsächlich verwenden. Ziel war es, die Produktkomplexität für einige zentrale Nutzertypen zu reduzieren und störende Funktionen zu entfernen. Am Ende stellte sich heraus, dass – abgesehen vom Login-Bildschirm – für jeden ein völlig anderes 20-%-Set wichtig war. Das Ergebnis der Analyse unterschied sich kaum von einer gewichteten Zufallsstichprobe
Dem stimme ich voll zu. Aber sobald man anfängt, das Produkt an Enterprise-Kunden zu verkaufen, ändert sich die Lage komplett. Wenn auch nur eine einzige „Hygienefunktion“ fehlt, kann ein Deal platzen. Und jedes Enterprise hat andere Funktionen, die es unbedingt braucht. Mit Hygienefunktion ist so etwas wie eine Toilette gemeint: ein minimales Muss, das jeder braucht
Das erinnert an ähnliche Beiträge aus Spolskys Blog
strategy-letter-iv-bloatware-and-the-8020-myth
simplicity
Ich habe selbst einmal eine kleine Hobby-App gebaut und denke gelegentlich daran, sie noch etwas aufzupolieren und zu veröffentlichen. Aber ich habe überhaupt keinen Antrieb, meine App zu promoten oder bekannt zu machen, daher erscheint mir eine Veröffentlichung sinnlos. Der größere Grund ist allerdings, dass ich keine Lust habe, die übrigen 80 % der Funktionen zu bauen, die ich selbst nicht benutze
Im Marketing gibt es das Konzept eines Modified Pareto. Nicht 80/20, sondern 60/20. Die 20 % Heavy User konsumieren 60 % des Produktwerts, die 80 % Light User 40 %. Das ist kein so kleiner Anteil, dass man ihn ignorieren könnte, daher muss man sich auch um die gelegentlichen Nutzer kümmern
value-paretos-bottom-80
So ungefähr. In Wirklichkeit ist viel wichtiger, dass Nutzer wahrnehmen, dass die Software ihr Problem lösen kann. Wenn man erreichen will, dass sie Geld ausgeben, muss die Software den Eindruck vermitteln, potenziell auch viele verschiedene Probleme lösen zu können. Dazu können auch Funktionen gehören, die ein bestimmter Nutzer nie verwendet. Ein Rigging-System in 3D-Software wird vielleicht nur von 2 % der Nutzer und nur 1 % der Zeit verwendet – aber ohne diese Funktion würden manche das Produkt gar nicht erst in Betracht ziehen
Ich bin schlecht darin vorherzusagen, wie meine Arbeit tatsächlich genutzt wird, deshalb mag ich nur den Ansatz, Wege auf bereits sichtbaren Trampelpfaden zu pflastern – was oft mit „Desire paths“ beschrieben wird
the-road-most-traveled-by-paving
Ich stimme der Aussage zu, dass man nicht versuchen sollte, das Anwachsen von Funktionen zu verhindern, sondern akzeptieren muss, dass Software auf Weise genutzt werden kann, die man sich nie vorgestellt hat. Deshalb halte ich Interoperabilität für den wichtigsten Aspekt von Software. Das Hauptproblem hier scheint mir die Abgeschlossenheit von dateiformatspezifischen Silos zwischen Softwareprodukten und Versionen zu sein. Ich habe kein Problem damit, mehrere Tools zu kombinieren, aber das Problem ist, dass die Tools in einer Pipeline nicht gut zusammenarbeiten. Der Unix-Traum ist wirklich schwer umzusetzen
In Apps einer gewissen Größenordnung werden fast nie alle Funktionen zu 100 % genutzt. Meiner Erfahrung nach gibt es in fast jeder Anwendung etwa 10 bis 30 % Bereiche, die praktisch gar nicht genutzt werden. Das liegt meist daran, dass sie nur auf eine Weise funktionieren, die außer dem Entwicklungsteam kaum jemand versteht, oder daran, dass der Workflow miserabel und ineffizient ist, oder daran, dass die Funktion so grundlegend ist, dass Unternehmen, die sie tatsächlich brauchen, sich die Software wirtschaftlich gar nicht leisten können
Stimmt, aber viele Nutzer haben jeweils unterschiedliche 20 % der Funktionen, die ihnen wichtig sind, daher muss man alle Funktionen behalten, wenn man die aktuelle Nutzerzahl halten will. Trotzdem steigt der ROI, wenn man kaum genutzte Funktionen entfernt, die in Wartung oder Entwicklung viel Zeit verschlingen
Aber Nutzer legen nicht unbedingt auf dieselben 20 % Wert. Ein weiterer Punkt ist, dass Nutzer oft gar nicht wissen, welche Funktionen eine App hat, bevor sie sie tatsächlich verwenden. Die Installationsentscheidung basiert nicht auf den Funktionen, die die App wirklich hat, sondern auf den Funktionen, die die Nutzer vor der Installation erwarten. Das ist ein wichtiger Unterschied. Selbst wenn man viel Aufwand in Funktionen steckt, zahlt sich das oft erst aus, nachdem man überhaupt Nutzer gewonnen hat.
Bei einem MVP ist das besonders wichtig: In den meisten Fällen scheitern Installation und dauerhafte Nutzung nicht an fehlenden Funktionen. Meistens liegt es an Messaging, Marketing oder schlicht daran, dass es keinen Wert gibt, der Nutzer überhaupt anzieht. Wild Funktionen hinzuzufügen löst diese Probleme nicht. Das klingt einfach, wird aber von vielen Unternehmen übersehen.
Das einfachste MVP ist zunächst, gar nichts zu bauen und stattdessen Menschen zur Vorregistrierung zu bewegen. So kann man testen, ob die Botschaft richtig ankommt. Wenn sie sich nach der Anmeldung enttäuscht fühlen, hat zumindest die Botschaft funktioniert.
Allerdings bringt man so ein MVP auf den Markt, das das Versprochene noch nicht einlöst, und riskiert Enttäuschung durch ein unfertiges Versprechen. Außerdem sind viele Funktionen in Wirklichkeit verzichtbar, besonders bei SaaS, wo viele davon nicht essenziell genug sind, dass jemand dafür tatsächlich Geld bezahlt. Statt Kundenanforderungen sofort als Muss zu übernehmen, sollte man unbedingt klären, ob sie etwas wirklich als wertvoll empfinden, tatsächlich bereit sind, dafür zu zahlen und ob damit ein wirklich wichtiger Schmerzpunkt gelöst wird. Zu verstehen, warum ein Kundenwunsch geäußert wurde, ist viel wichtiger, als die Funktion sofort zu bauen