Verliebt ins Problem, nicht in die Lösung: warum ich zuerst frage, ob es das richtige Problem ist.

Ein Industrieprodukt. In seiner Software stecken mehrere tausend Open-Source-Komponenten, also frei verfügbare Bausteine. Zu jedem gehört ein Lizenztext. Das sind Rechtstexte, in der Regel auf Englisch.

Nun soll das Produkt in einen Markt mit strengen Sprachvorgaben. Dort sollen diese Texte in der Landessprache vorliegen, damit der Nutzer sie lesen kann und weiß, was drinsteht. Tausende Rechtstexte, vor jeder neuen Version. Die Kosten dafür wären enorm.

Die Entwickler hatten schnell eine Lösung. Nach unserem Entwicklungsprozess müssen wir immer alles übersetzen – also lassen wir es automatisch übersetzen.

Bei Rechtstexten geht das aber nicht. Unter Anwälten ist es gang und gäbe, dass ein Mensch prüft, ob nach der Übersetzung inhaltlich noch dasselbe drinsteht. Stimmt die Auslegung nicht, kann eine Klage drohen.

Ich habe dieses Projekt geleitet. Und ich kenne den Reflex von mir selbst. Ich bin sehr lösungsorientiert. Ich denke immer sofort an Lösungen. Als Projektleiter gehört das dazu: Man muss schnell Probleme lösen, um das Ziel zu erreichen, und will den Punkt abarbeiten. Die Erkenntnis, dass man das Problem besser erst verstehen sollte, kam bei mir später.

Heute will ich vor allem eines nicht: das falsche Problem lösen.

Bezahlt wird für Lösungen, nicht fürs Verstehen

Ein Problem zu lösen ist Machermentalität. Es zeigt Erfolg, und zwar sichtbar.

Daran ist nichts falsch. Nicht jedes Problem verdient eine Analyse. Was klein ist und sich zurückdrehen lässt, probiert man einfach aus.

Schwierig wird es bei den größeren Vorhaben. Meine Beobachtung: Für Lösungen wird bezahlt. Für die Analyse des Problems erst einmal nicht.

Das rächt sich. Gehe ich das falsche Problem an, kostet die Lösung viel Aufwand und viel Geld – und die Ursache behebt sie in der Regel nicht.

Wer das falsche Problem löst, zahlt viel und hat die Ursache danach meist immer noch.

Eine Zahl dazu gibt es, wenn auch eine alte. Die GPM Deutsche Gesellschaft für Projektmanagement und die PA Consulting Group haben 2004 Projektleiter, Geschäftsführer und Vorstände in Deutschland befragt. 98 Fragebögen kamen zurück. Fast 70 Prozent nannten unklare Anforderungen und Ziele als häufigste Ursache für das Scheitern ihrer Projekte. Zu hohe technische Anforderungen waren es bei weniger als 10 Prozent.

Unklare Ziele sind nicht dasselbe wie ein falsches Problem. Und die Studie ist über zwanzig Jahre alt. Aber sie deckt sich mit dem, was ich in großen Organisationen selbst erlebt habe: Gescheitert wird selten an der Technik. Meist war vorher nicht klar, worum es eigentlich geht.

Wenn das falsche Problem so teuer ist, lohnt eine Frage vor allen anderen.

Ist es wirklich das Problem?

Für mich hat das Priorität: das Problem wirklich hinterfragen. Es von verschiedenen Seiten beleuchten. Ist es das Problem – oder nur das, was davon sichtbar ist?

Eine einfache Probe hilft: Formulieren Sie das Problem, ohne eine Lösung zu nennen. „Uns fehlt ein Chatbot“ ist kein Problem. Es ist eine Lösung, die sich als Problem ausgibt.

Das bekannteste Beispiel für die verschiedenen Seiten ist die Bohrmaschine. Niemand will eine Bohrmaschine. Die Leute wollen ein Loch in der Wand. Und eigentlich wollen sie nicht einmal das – sie wollen ein Bild aufhängen. Jede Ebene lässt andere Lösungen zu.

Dasselbe gilt für KI. Angenommen, ein Unternehmen sagt: KI soll unsere Angebote schneller schreiben. Beim Hinsehen zeigt sich, dass das Schreiben gar nicht lange dauert. Das Angebot liegt tagelang zur Freigabe. Eine KI, die schneller schreibt, würde am falschen Schritt ansetzen. Das Beispiel ist gedacht, nicht erlebt.

Darum denke ich gern zwei Schritte weiter, als gefragt war – bis zum Problem hinter dem genannten Problem.

Damit zurück zu den Lizenztexten. Die Entwickler fragten: Wie übersetzen wir alles? Ich habe das Problem analysiert. Im Kern ging es um etwas anderes: Ein Nutzer, der danach fragt, soll die Texte in seiner Sprache bekommen.

Also habe ich eine andere Perspektive hineingebracht und gefragt, wie viele Leute solche Texte in einem anderen Markt überhaupt jemals angefragt hatten. Es waren wenige. Für den neuen Markt habe ich eher noch weniger erwartet.

Mein Vorschlag war deshalb schlicht. Übersetzt wird erst, wenn jemand anfragt. Dann bekommt er das übersetzte Material.

So wurde es umgesetzt. Der Weg wurde mit der zuständigen Behörde abgestimmt, sie hat zugestimmt. Heute ist er im Einsatz.

Mit KI hatte dieser Fall nichts zu tun. Im KI-Kontext habe ich ihn so klar noch nicht erlebt.

Nur kann man das Hinterfragen auch übertreiben.

Nicht bis zum Tod analysieren – klein ausprobieren

Ein Problem lässt sich zu Tode analysieren. Das will ich nicht.

Deshalb gehe ich früh mit kleinen Lösungsversuchen hin. Einen Prototyp bauen und schauen: Haben wir das Problem wirklich getroffen und verstanden?

Mit KI ist ein solcher Prototyp heute so schnell gebaut wie nie. Die HPI d-school am Hasso-Plattner-Institut in Potsdam schreibt, KI könne helfen, Prototypen in beeindruckender Geschwindigkeit zu erstellen. Nur: Wenn Lösungen billig werden, wird das Verstehen zum Engpass.

Problem und Lösung beeinflussen sich gegenseitig. Das eine befruchtet das andere. Es ist ein iterativer Prozess, man geht also in Schleifen. Dieselbe Schule lehrt dafür Design Thinking, ein Vorgehen in sechs Phasen. Am Anfang steht das Verstehen, am Ende das Testen. Und aus dem Test ergibt sich die nächste Schleife.

Damit der Versuch nicht selbst zur voreiligen Lösung wird, steht vorher zweierlei fest. Woran würden wir merken, dass das Problem weg ist? Und wann ist Schluss?

Wer die erste Frage nicht beantworten kann, hat das Problem noch nicht verstanden. Die zweite ist mir sogar wichtiger. Ein Fall, nicht zehn – und das Abbruchkriterium zählt mehr als das Erfolgskriterium.

Verstehen und Ausprobieren gehören also zusammen. Bleibt die Frage, wer sich die Zeit dafür nimmt.

Unbequem, aber Sache der Führung

Sich mit dem Problem auseinanderzusetzen ist unbequem. Eine Zeit lang gibt es nichts vorzuzeigen.

Eine gescheite Führungskraft weiß trotzdem: Ich muss mich erst wirklich mit dem Problem auseinandersetzen. Es ist der deutlich bessere Weg, um am Ende Erfolg zu haben.

Hinterfragen Sie sich dabei ruhig selbst. Wann haben Sie zuletzt eine Lösung beauftragt – und wer hat das Problem formuliert?

Im Englischen gibt es dafür einen Satz: „Fall in love with the problem, not the solution.“ Verlieben Sie sich in das Problem, nicht in die Lösung. Bekannt ist er durch Uri Levine, den Mitgründer der Navigations-App Waze, und sein gleichnamiges Buch von 2023.

Wer am Problem hängt, lernt aus einem gescheiterten Versuch. Wer an der Lösung hängt, verteidigt sie.