Wer schon einmal in einer Roadmap-Priorisierung gesessen hat, ist von der Zahl nicht überrascht: Laut dem CHAOS Report der Standish Group werden rund 80 % aller Software-Features selten oder nie genutzt. Die Zahl kursiert seit Jahren. Trotzdem ändert sich wenig. Roadmaps werden voller, Teams beschäftigter, Produkte schwerer zu bedienen.

Die interessante Frage ist nicht, ob das stimmt, sondern warum Teams immer wieder Features bauen, die keiner braucht, obwohl alle es besser wissen.

Die falsche Diagnose: Feature-Bloat ist kein Priorisierungsproblem

Die übliche Antwort lautet: bessere Priorisierung. RICE-Scores berechnen den erwarteten Nutzen eines Features anhand von Reichweite, Wirkung, Wahrscheinlichkeit und Aufwand. Die MoSCoW-Methode teilt Anforderungen in vier Kategorien ein. Backlog-Grooming bezeichnet das regelmäßige Überarbeiten offener Aufgaben. Vernünftige Werkzeuge, aber sie lösen das falsche Problem.

Feature-Bloat ist ein Widerspruchsproblem.

Teams stehen vor einem echten Zielkonflikt: Der Vertrieb will mehr Funktionen, der Wettbewerb zieht nach, Kunden schicken Feature-Requests. Gleichzeitig leidet mit jedem neuen Feature die Bedienbarkeit, die Wartbarkeit und der Fokus des Produkts. Priorisierungs-Frameworks entscheiden nur, was als Nächstes gebaut wird. Sie beantworten nicht die eigentliche Frage: Wie kann ein Produkt gleichzeitig mehr können und einfacher bleiben? Solange diese Frage unbeantwortet bleibt, ist Feature-Bloat das unvermeidliche Ergebnis.

Was die TRIZ-Methode ist, kurz erklärt

TRIZ ist eine Erfindungsmethodik, die der sowjetische Ingenieur Genrich Altschuller ab den 1940er Jahren entwickelte. Er wertete hunderttausende Patente aus und stellte fest: Erfolgreiche Innovationen folgen wiederkehrenden Mustern. Wer diese Muster kennt, löst technische Probleme strukturierter und schneller als durch Brainstorming allein.

Die Grundlogik ist direkt: Ein konkretes Problem wird in ein abstraktes Problem übersetzt. Für das abstrakte Problem gibt es generische Lösungsmuster. Diese werden zurück in eine konkrete Lösung übertragen.

Die wichtigsten Bausteine für den Einstieg sind technische Widersprüche, die Contradiction Matrix und die 40 innovativen Prinzipien. Wer tiefer einsteigen will, findet im Artikel Was ist die TRIZ-Methode und wie löst sie Widersprüche? einen strukturierten Überblick.

Den Unterschied verstehen: Kompromiss vs. Auflösung

Teams lösen Zielkonflikte meist durch Kompromiss statt durch echte Auflösung. Das klingt pragmatisch, ist aber oft die Quelle des nächsten Problems.

Ein Kompromiss bei Feature-Bloat sieht so aus: „Wir bauen das Feature, aber schlanker." Beide Seiten verlieren ein bisschen. Das Produkt wird trotzdem komplexer, nur etwas langsamer.

Eine Auflösung sieht anders aus: Beide Ziele werden gleichzeitig erreicht. Ein klassisches Beispiel ist das Fahrrad mit Gangschaltung. Das Ziel war mehr Geschwindigkeit ohne mehr Kraftaufwand. Der Kompromiss wäre ein leichteres Fahrrad gewesen. Die Auflösung war ein variables Übersetzungsverhältnis, keine Abstriche, kein Mittelweg. Genau für diese Art von Denken wurde TRIZ entwickelt. Und genau dieses Denken lässt sich auf Feature-Bloat anwenden.

Feature-Bloat als Widerspruch formulieren: Ein Beispiel aus der Widerspruchs-Matrix

Statt zu fragen „Welches Feature priorisieren wir?", lautet die TRIZ-Frage: „Was ist der genaue Widerspruch, den wir auflösen müssen?"

Der erste Schritt ist, den Widerspruch zu benennen: „WENN wir mehr Funktionalität hinzufügen, DANN steigt die Vielseitigkeit des Produkts, ABER die Bedienbarkeit leidet." Das ist ein technischer Widerspruch im TRIZ-Sinne: Parameter A verbessert sich, Parameter B verschlechtert sich.

Im zweiten Schritt werden die Parameter abstrahiert. Die Matrix 2003 arbeitet mit 48 typischen Parametern. „Funktionsumfang" lässt sich auf Parameter 32 (Adaptionsfähigkeit/Vielseitigkeit) abbilden, „Bedienbarkeit" auf Parameter 34 (Bedienungsfreundlichkeit/Erlernbarkeit). Wer stärker auf die wachsende Bedienlogik abzielt, liest zusätzlich die Kombination mit Parameter 46 (Komplexität der Kontrolle) ab.

Dann kommt die Widerspruchsmatrix ins Spiel. Sie ist eine 48×48-Tabelle, die für jedes Parameterpaar konkrete Lösungsprinzipien empfiehlt, sortiert nach absteigender Häufigkeit ihrer Nennung. Für 32 → 34 schlägt sie IP #15, IP #24, IP #3, IP #4 und IP #28 vor, für 32 → 46 unter anderem IP #28, IP #25, IP #3 und IP #1.

IP #15 (Anpassung, auch Dynamisierung) steht in dieser Kombination an erster Stelle und weist auf adaptive Interfaces hin: Ein Experten-Modus und ein vereinfachter Modus existieren gleichzeitig, weil die Oberfläche sich dem Nutzungskontext anpasst. IP #1 (Zerlegen, Zerteilen – Segmentierung) deutet auf modulare Features hin. Statt alle Funktionen in einer Oberfläche zu bündeln, werden sie in optionale Module aufgeteilt: Der Nutzer bekommt, was er braucht, ohne den Rest zu sehen. IP #25 (Selbstversorgung und -bedienung) schlägt Automatisierung vor. Statt ein neues Feature zu bauen, das der Nutzer manuell bedient, übernimmt das System die Aufgabe selbst – weniger Bedienschritte, gleicher konkreter Nutzen.

Das sind keine Kompromisse. Das sind Lösungsrichtungen, die direkt aus dem Widerspruch abgeleitet werden. Wer Zielkonflikte in der Produktentwicklung lösen will, findet hier einen strukturierten Ausgangspunkt.

TRIZ vs. Design Thinking: Ergänzung, kein Ersatz

Design Thinking ist nutzerzentriert und divergent. Es ist stark darin, herauszufinden, was Nutzer wirklich brauchen, und viele Ideen zu generieren. TRIZ ist wissensbasiert und konvergent. Es hilft nicht beim Verstehen des Problems, sondern beim systematischen Auflösen des Widerspruchs, sobald das Problem klar ist.

Design Thinking hilft herauszufinden, dass ein Feature nicht gebraucht wird. TRIZ hilft, den Zielkonflikt aufzulösen, der dazu geführt hat, dass das Feature überhaupt in Betracht gezogen wurde. Beide Ansätze schließen sich nicht aus. Einen direkten Vergleich bietet der Artikel TRIZ vs. Design Thinking.

Der wiederholbare Prozess in fünf Schritten

Technische Widersprüche systematisch lösen ist kein Einzelkunststück. Es ist ein Prozess, den Teams wiederholt anwenden können.

Zuerst wird das Problem konkret beschrieben, ohne sofort eine Lösung zu suchen. Dann wird der genaue Widerspruch identifiziert: Was verbessert sich, was verschlechtert sich? Im dritten Schritt werden die widersprüchlichen Eigenschaften auf TRIZ-Standardparameter abstrahiert. Danach kommen die Widerspruchs-Matrix oder die 40 Prinzipien zum Einsatz. Schließlich werden die generischen Lösungsrichtungen in konkrete Produktentscheidungen übertragen.

Dieser Prozess ist teamfähig und wiederholbar. Er macht Produktentscheidungen belastbarer, weil sie auf Struktur beruhen, nicht auf Bauchgefühl. Bei Truinorva setzen wir ergänzend KI-gestützte Workflows ein, um die Analyse schneller und belastbarer zu machen, besonders bei komplexen Widersprüchen mit vielen Parametern.

Vom Feature-Friedhof zur systematischen Innovation

80 % ungenutzte Features sind kein Beweis für schlechte Priorisierung. Sie sind ein Symptom ungelöster Widersprüche in der Produktstrategie.

Der erste praktische Schritt ist einfach: Beim nächsten Roadmap-Konflikt nicht fragen, welches Feature wichtiger ist, sondern welcher Widerspruch dahintersteckt. Was verbessert sich, wenn man das Feature baut? Was verschlechtert sich? Wer diese Frage sauber beantwortet, hat den Einstieg in systematische Innovation bereits gemacht.

Wer dabei Unterstützung sucht: Truinorva bietet einen Innovation Impulse Day zur schnellen Problemschärfung, TRIZ Basic Training für Teams, die methodisch einsteigen wollen, und das Buch Think. Solve. Create. für alle, die selbstständig tiefer einsteigen möchten.

Quellen

  • Standish Group: CHAOS Report (aktuelle Ausgabe). standishgroup.com
  • Altschuller, Genrich: Erfinden, Wege zur Lösung technischer Probleme. Hanser, 1984
  • Altschuller, Genrich: Creativity as an Exact Science. Gordon and Breach, 1988
  • Darrell Mann: Hands-On Systematic Innovation. IFR Press, 2002
  • Contradiction Matrix und 40 innovative Prinzipien: triz40.com
  • Oxford Creativity: TRIZ Contradiction Matrix Online Tool. triz.co.uk
  • Pugh, Stuart: Total Design. Addison-Wesley, 1991 (Hintergrund zu Entscheidungsmatrizen in der Produktentwicklung)
  • Truinorva: Erfahrungen aus TRIZ-Workshops und Produktentwicklungsprojekten. truinorva.de