Ein Ingenieur steckt seit Wochen an einem Gehäuse. Es wird zu schwer, die Wandstärke ist schon am Minimum, und jede weitere Iteration bringt kaum noch etwas. Ein erfahrener Kollege schaut kurz drauf und fragt: „Was muss das Gehäuse eigentlich leisten?" Er fragt nicht, wie es gebaut ist.

Das ist der Unterschied.

Juniors optimieren die gegebene Struktur. Seniors hinterfragen, ob die Struktur überhaupt richtig ist. Diese Fähigkeit wird selten explizit gelehrt. Sie entsteht durch Jahre der Erfahrung, manchmal durch einen guten Mentor. Dieser Artikel versucht, diesen Weg abzukürzen.

Was Forschung dazu sagt

Die Kompetenzlücke ist empirisch belegt. Eine Studie von Harlim & Belski (International Journal of Engineering Education, 2017, N=215) zeigt: Ingenieure ohne Industrieerfahrung verbrachten nur 28 % ihrer Zeit damit, ein Problem zu verstehen, bevor sie zu lösen begannen. Die Autoren schreiben direkt: „Novice engineers did not spend sufficient time understanding a problem, as they lack the awareness and have a misconception on how experts resolve problems." Ungefähr zehn Jahre Industrieerfahrung, so das Ergebnis, bilden echte Engineering-Expertise aus.

Eine Pilotstudie der Virginia Tech (Song et al., Journal of Technology Education, 2016, N=50) bestätigt das Muster: Experten zerlegten Probleme zuerst in die Breite, Studenten tauchten sofort in ein Teilproblem ein. „Students spend less cognitive effort on the problem-definition stage than engineering experts."

Ein Industrie-Datenbericht von Snubber (2026, über 20.000 KI-bewertete Interview-Sessions) fasst es knapp zusammen: „Engineers can solve problems. They just can't define the problem." Die Stichprobe ist selbstselektiert, kein Peer-Review, aber das Muster deckt sich mit dem, was die Forschung zeigt.

Funktion vs. Komponente: der entscheidende Denkwechsel

Eine echte Problemzerlegung trennt die Funktionen, die ein Design erfüllen muss, von den Komponenten, die diese Funktionen gerade erfüllen.

Ein Beispiel: Die Komponente ist das Wandmaterial eines Kaffeebechers. Die Funktion ist, Hitze zu isolieren, damit die Hand nicht verbrennt. Diese Funktion könnte auch ein Luftspalt, eine Beschichtung oder eine andere Geometrie erfüllen. Sobald Funktion und Komponente getrennt sind, öffnet sich der Lösungsraum erheblich.

Wir denken automatisch in Bauteilen. Das ist keine Schwäche, sondern Erfahrung. Aber genau diese Erfahrung schränkt ein, wenn das eigentliche Problem auf einer anderen Ebene liegt. Funktionsanalyse fragt nicht nach der Fehlerursache. Sie fragt: Was muss hier eigentlich passieren, unabhängig davon, wie es bisher gelöst wurde?

Der häufigste Fehler: ein Problem, das eigentlich mehrere sind

Wenn die Entwicklung feststeckt, lohnt eine einfache Übung. Alle Anforderungen aufschreiben, dann prüfen: Welche hängen wirklich zusammen? Welche sind unabhängig, werden aber als ein einziges Problem behandelt?

„Das Bauteil muss leichter und günstiger werden" klingt nach einer Aufgabe. Aber Leichtigkeit betrifft Material und Geometrie, Kosten betreffen Fertigungsverfahren und Lieferkette. Das sind zwei verschiedene Problemräume mit verschiedenen Lösungsansätzen.

Wer technische Probleme systematisch lösen will, beginnt hier: nicht mit Lösungsideen, sondern mit dem Aufdröseln der Anforderungsstruktur. Häufig ist das vermeintliche Problem in Wirklichkeit mehrere unabhängige Anforderungen, die vorgeben, eines zu sein.

Wenn die Zerlegung stimmt, kommen Widersprüche von selbst

Sobald Funktionen klar getrennt sind, taucht das eigentliche Hindernis oft von selbst auf. Ein Bauteil muss für Funktion A steif sein, für Funktion B aber flexibel. Ein Werkstoff soll für Funktion C leitfähig sein, für Funktion D isolierend. Das sind keine Optimierungsprobleme mehr. Das sind technische Widersprüche.

Ein technischer Widerspruch liegt vor, wenn die Verbesserung einer Eigenschaft eine andere zwingend verschlechtert. Wer nur Parameter verschiebt, optimiert den Kompromiss, löst aber nicht den Konflikt. Die Lösung liegt im Neu-Mappen der Funktionen auf andere Wirkprinzipien.

Das Lösen von Zielkonflikten in der Produktentwicklung ist genau das, womit Teams am häufigsten feststecken: nicht wegen fehlender Ideen, sondern weil der Widerspruch nie sauber benannt wurde.

Was TRIZ damit zu tun hat

TRIZ ist die formalisierte Version genau dieser Denkweise. Genrich Altshuller analysierte ab 1946 als Patentprüfer bei der sowjetischen Marine Patente systematisch. Aus der Auswertung von Hunderttausenden Patenten destillierte er ein zentrales Ergebnis: Technische Durchbrüche folgen Mustern. Dieselben Arten von Widersprüchen tauchen branchenübergreifend auf, und dieselben Lösungsprinzipien lösen sie.

Das Ergebnis sind unter anderem die 40 Innovationsprinzipien. Sie beschreiben keine fertigen Lösungen, sondern Denkrichtungen: Segmentierung, Übergang in ein anderes Aggregat, Nutzung von Verbundstrukturen. Sie zeigen Wege, wie ein Widerspruch aufgelöst werden kann, ohne Kompromiss.

Wer tiefer in die Grundlagen einsteigen will, findet im Artikel Was ist die TRIZ-Methode eine strukturierte Einführung. TRIZ ist keine Kreativitätstechnik. Es ist eine Methode zur systematischen Ideenfindung, die auf empirischen Mustern aus der Patentgeschichte basiert. Samsung führte TRIZ ab 2000 ein und erzielte laut AITRIZ.org bereits 2003 über 50 neue Patente. Intel dokumentierte einen durch die eigene Finanzabteilung verifizierten ROI von über 212 Millionen US-Dollar über 21 Monate. Beide Zahlen stammen aus internen Fallstudien ohne unabhängiges Peer-Review.

Der Einstieg ohne Methodenausbildung

Wer anfangen will, braucht für den ersten Schritt keine Methodenausbildung. Eine einfache Abfolge hilft bereits: Zuerst alle Anforderungen aufschreiben, ohne zu filtern. Dann für jede Anforderung fragen, welche Funktion dahintersteckt. Anschließend Funktionen von den aktuellen Bauteilen trennen und prüfen, welche Anforderungen wirklich zusammenhängen und welche unabhängig sind. Schließlich Widersprüche markieren, also Stellen, wo eine Funktion das Gegenteil einer anderen verlangt, und fragen: Liegt das Problem an der Lösung, oder an der Struktur der Aufgabe?

Wenn bei diesem letzten Schritt mehrere Widersprüche auftauchen, ist das ein gutes Zeichen. Das Problem ist jetzt sichtbar. Wie KI diesen Prozess ergänzen kann, beschreibt der Artikel zu KI in der Produktentwicklung.

Wann strukturierte Unterstützung sinnvoll ist

Diese Denkweise lässt sich lernen. Sie unter Zeitdruck und mit festgefahrenen Annahmen in einem Team zu verankern, ist eine andere Aufgabe.

Truinorva bietet dafür strukturierte Formate: vom Innovation Impulse Day für schnelle Problemklärung bis zum TRIZ Basic Training für Teams, die die Methode selbst anwenden wollen. 2026 starten die Think.Solve.Create. Praxistage in München, Frankfurt und Hamburg, ein niedrigschwelliger Einstieg für Entwickler, die diese Denkweise in einem halben Tag erleben wollen.

Zerlege das Problem zuerst nach Funktion. Die Lösung wird oft offensichtlich, statt nur clever.

Quellen