Mehr Features, besseres Produkt?
Feature-Explosion von Sprint zu Sprint. Was dabei auf der Strecke bleibt.
74 % der SaaS-Unternehmen monetarisieren inzwischen AI-Features. Gleichzeitig entstehen in vielen Produkten immer mehr Funktionen in kurzer Zeit. Produktteams berichten deshalb häufiger über ein anderes Problem: Viele Nutzer erkennen keinen klaren Mehrwert im Produkt.
Der Amplitude Product Benchmark Report 2025, der Daten aus mehr als 2.600 Unternehmen analysiert, zeigt eine deutliche Tendenz: Über 98 % der Nutzer werden innerhalb der ersten zwei Wochen inaktiv, wenn sie in dieser Zeit keinen erkennbaren Mehrwert erleben.
Für Produkte mit wachsender Feature-Komplexität ist das ein Warnsignal. Jedes neue Feature, das den Kernwert eines Produkts schwerer erkennbar macht, erhöht die Wahrscheinlichkeit, dass Nutzer das Produkt wieder verlassen.
Das ist kein Technologieproblem. Es ist ein Strukturproblem.
Die eigentliche Frage ist nicht: Welches Feature bauen wir als Nächstes?
Wenn ein AI-Assistent hinzukommt, ein Chat-Interface ergänzt wird, ein „Smart Mode“ eingeführt wird und ein Agent Prozesse übernimmt, passiert das selten als koordinierte Entscheidung. Es passiert Feature für Feature – Sprint für Sprint.
Jedes einzelne Feature kann sinnvoll sein. Das Gesamtbild wird dadurch trotzdem komplexer. Denn mit jedem neuen Feature verändern sich nicht nur Funktionen eines Produkts. Es verändern sich auch grundlegende Fragen der Nutzung: Was entscheidet das System und was der Nutzer? Wer trägt Verantwortung für automatisierte Aktionen? Was passiert, wenn ein Button geklickt wird? Und kann der Nutzer eingreifen oder etwas rückgängig machen?
Wenn diese Fragen in der Nutzerführung nicht klar beantwortet werden, steigt die kognitive Belastung. Forschung aus der Human-Computer-Interaction zeigt, dass zusätzliche gleichzeitige Wahlmöglichkeiten die wahrgenommene Komplexität deutlich erhöhen können. Der Effekt ist nicht linear – er summiert sich.
Features können Komplexität reduzieren – oder neue erzeugen.
Ein verbreitetes Missverständnis: Mehr Features erhöhen automatisch die Produktkomplexität. Das stimmt nicht. Features können Komplexität auch reduzieren – etwa wenn sie Entscheidungen vereinfachen oder irrelevante Optionen ausblenden.
Features als Komplexitätsreduzierer sind zum Beispiel adaptive Interfaces, die irrelevante Funktionen ausblenden, Onboarding-Flows, die Nutzer direkt zum ersten erkennbaren Nutzen führen, oder Automatisierungen, die wiederkehrende Entscheidungen übernehmen.
Features als Komplexitätstreiber entstehen dagegen, wenn ein Chat-Interface über einer unklaren Informationsarchitektur liegt, ein Agent Entscheidungen trifft, die nicht nachvollziehbar sind, oder ein „Magic Button“ etwas auslöst, dessen Wirkung niemand genau versteht.
Der Unterschied liegt nicht im Feature selbst. Er liegt in der Struktur, in die es eingebettet wird.
Drei Arten von AI-Features – drei UX-Anforderungen.
Ein Fehler, der in der Praxis häufig passiert: AI-Funktionen werden nach demselben Muster integriert. Dabei stellen unterschiedliche AI-Feature-Typen sehr unterschiedliche Anforderungen an die Nutzerführung.
AI als Automatisierung übernimmt klar definierte Aufgaben – etwa E-Mails kategorisieren, Termine vorschlagen oder Texte formatieren. Nutzer brauchen hier vor allem Sichtbarkeit darüber, was automatisch passiert, Eingriffsmöglichkeiten sowie klare Fehlerrückmeldungen.
AI als Entscheidungsinstanz trifft Bewertungen auf Basis von Mustern – etwa bei Lead-Priorisierung oder Risikoanalysen. Hier werden zusätzlich Erklärbarkeit und die Möglichkeit zur Übersteuerung wichtig.
AI als generativer Assistent erstellt Inhalte, Zusammenfassungen oder Vorschläge. Hier steht weniger Prozesskontrolle im Vordergrund als Vertrauen in die Qualität der Ergebnisse: Ist der Output zuverlässig? Und wann sollte er überprüft werden?
Diese Unterscheidung wirkt technisch. In der Praxis entscheidet sie oft darüber, ob ein Feature genutzt wird – oder ignoriert wird.
Warum Chat-Interfaces das Problem nicht lösen.
Chat gilt derzeit als universelle Antwort auf wachsende Produktkomplexität. Die Idee dahinter: Wenn Nutzer Fragen in natürlicher Sprache stellen können, brauchen sie keine komplexe Navigation mehr.
Das funktioniert jedoch nur unter einer Bedingung: Die Struktur darunter muss klar sein. Ein Chat-Interface kann Eingaben vereinfachen und komplexe Aktionen abstrahieren. Es kann aber keine fehlende Informationsarchitektur ersetzen, keine unklaren Systemzustände erklären und keine inkonsistenten Prozesse ausgleichen. Wenn ein Nutzer fragt „Wo finde ich meine Rechnungen?“ und die Struktur dahinter unklar ist, löst der Chat das Problem nicht. Er verschiebt es nur eine Ebene weiter.
Progressive Disclosure – die unterschätzte Methode.
Wachsende Feature-Sets brauchen nicht zwingend mehr Erklärung. Sie brauchen bessere Schichtung.
Das UX-Prinzip Progressive Disclosure zeigt Funktionen schrittweise – ausgehend vom Kernwert und nicht von der Vollständigkeit aller Möglichkeiten. Forschung der Nielsen Norman Group zeigt, dass Progressive Disclosure die Erfolgsrate bei Aufgaben deutlich verbessern kann. Nicht durch weniger Funktionen, sondern durch weniger gleichzeitige Optionen.
In der Praxis bedeutet das: Kernfunktionen sind sofort zugänglich, erweiterte Funktionen erscheinen kontextuell, und neue Features tauchen dort auf, wo sie im Nutzungsmoment sinnvoll sind.
Duolingo nutzt dieses Prinzip konsequent. Neue Nutzer sehen zunächst nur eine einzige Aktion. Weitere Funktionen werden erst mit der Nutzung sichtbar – Komplexität entsteht schrittweise statt auf einmal.
Prototyping als Strukturtest.
Neue Features werden häufig isoliert entwickelt. Die zentrale Frage lautet dann: Funktioniert dieses Feature? Die wichtigere Frage bleibt oft unbeantwortet: Was macht dieses Feature mit dem Gesamtprodukt?
Hier bekommt Prototyping eine andere Rolle. Ein Prototyp, der ein neues Feature in bestehende Nutzungspfade integriert, zeigt schnell, wo Nutzer den Überblick verlieren, welche Zustände unklar werden oder wie ein neues Feature mit vorhandener Automatisierung interagiert. In diesem Kontext ist Prototyping kein reiner Designschritt. Es ist ein Test für strukturelle Risiken im Produkt.
Der EU AI Act – Transparenz wird zur Anforderung.
Seit 2025 gilt der EU AI Act. In bestimmten Fällen müssen Unternehmen erkennbar machen, wenn Nutzer mit einem AI-System interagieren. Bei automatisierten Entscheidungen mit relevanten Auswirkungen gelten zusätzliche Transparenzpflichten.
Das ist keine abstrakte Regulierung. Es ist eine konkrete UX-Anforderung. Produkte müssen verständlich machen, wann AI aktiv ist, warum Entscheidungen getroffen werden und wo Nutzer eingreifen können. Transparenz erfüllt damit zwei Ziele gleichzeitig: regulatorische Anforderungen und Vertrauen.
Was das für Mittelständler bedeutet.
Im Mittelstand werden AI-Features häufig in bestehende Systeme integriert – etwa ERP-, CRM- oder Produktionssoftware.
Die Herausforderung ist nicht nur UX-Komplexität. Es ist Vertrauen. Viele Mitarbeitende müssen Entscheidungen an Systeme abgeben, die sie bisher selbst getroffen haben. Studien zeigen, dass viele AI-Projekte in Unternehmen nicht an der Technologie scheitern, sondern an mangelnder Nutzerakzeptanz.
Wenn Mitarbeitende verstehen, was das System tut, wie es entscheidet und wo sie eingreifen können, steigt die tatsächliche Nutzung deutlich.
Was das für Startups bedeutet.
Die Phase macht einen Unterschied:
Early Stage (Pre-PMF): Hier geht es vor allem darum herauszufinden, ob der Kernwert eines Produkts überhaupt stimmt. Zu frühe Strukturarbeit kann diese Lernphase verlangsamen. Features sollten sparsam eingesetzt werden – um den Kernwert schneller sichtbar zu machen, nicht um zu beeindrucken.
Scale-ups (Post-PMF): Hier treten die beschriebenen Probleme deutlich auf. Wenn Feature-Sets wachsen und Nutzerzahlen steigen, ohne dass die Struktur mitwächst, zeigen sich die Folgen schnell: Nutzer erkennen keinen klaren Mehrwert, Supportanfragen steigen und Funktionen bleiben ungenutzt.
Hier werden Progressive Disclosure, strukturiertes Onboarding und Prototyping zu wichtigen Werkzeugen.
Typische Symptome – und was sie bedeuten.
SaaS-Scale-ups: Trial-Nutzer erkennen keinen klaren Mehrwert im Produkt, „Power Features“ werden kaum genutzt und Support beantwortet immer wieder dieselben Fragen.
Mittelständische Softwareanbieter: Mitarbeitende umgehen neue AI-Features, Trainingsaufwand steigt mit jedem Release und alte Systeme werden parallel weiter genutzt.
Diese Symptome sind keine Designprobleme. Sie sind Hinweise auf fehlende Strukturarbeit im Produkt.
Was daraus folgt.
Feature-Explosion beschleunigt Innovation. Das ist real – und oft wertvoll. Aber dieselbe Geschwindigkeit, die neue Funktionen schneller möglich macht, macht auch Strukturprobleme schneller sichtbar.
Der Wettbewerbsvorteil liegt selten im einzelnen Feature. Er liegt darin, Komplexität verständlich zu machen – durch klare Schichtung, durchdachte Einbettung und Transparenz darüber, was ein System eigentlich macht.
Das Produkt, das komplexe Funktionen verständlich macht, gewinnt. Nicht das mit den meisten Features.