Der Lösungsreflex: Warum wir Probleme übersehen und Lösungen bauen, die keiner braucht

In unserer Arbeit mit Produktteams, System Engineers und Requirements Engineers begegnet uns eine Frage immer wieder – und sie ist fast schon ein Reflex:

„Was sind euere Anforderungen an das System?“

Die Intention ist gut. Die Wirkung oft fatal. Denn: Die Mehrzahl aller Projekte scheitert nicht an der Technik – nicht an Java-Versionen, Container-Setups oder Testabdeckung. Sie scheitert daran, dass Anforderungen geschrieben werden, bevor überhaupt klar ist, was wirklich gebraucht wird.

Willkommen im Requirements Engineering, wie wir es nicht mehr brauchen.

„Was sind euere Anforderungen?“ – die gefährlichste Frage im Requirements Engineering

Zu oft starten wir mit dem Was, obwohl das Warum noch völlig unklar ist.

Produkt Owner wollen liefern, Requirements Engineers wollen dokumentieren, Entwickler:innen wollen umsetzen. Alles gut gemeint – aber angetrieben von einem Reflex: Wir springen zu schnell in die Lösung.

Warum? – Weil wir helfen wollen. Weil wir liefern wollen. Und – Hand aufs Herz – weil es uns in Trainings, Lehrbüchern und Prozessen genau so beigebracht wurde.

Doch in komplexen oder neuartigen Situationen verhindert dieser Reflex echte Innovation – und produziert Systeme, die formal korrekt, aber praktisch irrelevant sind.

Reflex: Lösungsbias

„Ich möchte mein Haustier mit in den Urlaub nehmen.“

Sofort entstehen erste Lösungsideen: Transportbox, App-Filter, haustierfreundliche Hotels. Klingt logisch. Bis der Satz endet mit:

„Mein Haustier ist ein Koi.“

Stille. Ein Moment – und ein deutliches Eingeständnis: Unsere erste Lösung ist nutzlos.

Warum? Weil wir ein vermeintliches Problem gelöst haben – ohne zu verstehen, was wirklich dahintersteckt.

Das nennen wir: Lösungsbias – der Drang, auf unvollständige oder vermeintlich bekannte Probleme mit gewohnten Antworten zu reagieren. In agilen Umfeldern mit hohem Teamverständnis kann dieser Reflex funktionieren. Aber überall sonst wird er zum Bremsklotz für echte Wirkung.

Funktional ≠ relevant

Zu viele System-Anforderungen entstehen aus Halbwissen, Handlungsdruck oder blindem Umsetzungsdrang. Sie sind technisch korrekt, testbar, sauber dokumentiert – aber völlig wirkungslos.

Weil sie nicht auf ein reales Problem zurückgehen. Weil niemand gefragt hat: Wer hat hier eigentlich Schwierigkeiten – und wobei genau?

Unsere Empfehlung: Denk in Problemen – nicht in Tickets

Was wir in unseren Coachings und Projekten immer wieder betonen: Requirements Engineering braucht einen Paradigmenwechsel.

Nicht weg vom RE – aber zurück zu seinem Kern: dem Problem.

Wir nennen das: Problem Engineering.

Was das konkret bedeutet?

• Mehr Mut zur Lücke – statt hektischer Vollständigkeit
• Mehr Geduld fürs Warum – bevor über das Wie gesprochen wird
• Mehr echtes Problemverständnis – statt reflexhafter Umsetzung

Der Schlüssel? Problem Statements.

Sie bringen auf den Punkt:

• Wer hat ein Ziel?
• Woran scheitert diese Person oder Organisation?
• Und warum ist es relevant, dieses Problem zu lösen?

Was du mitnehmen solltest

Wir erleben in der Praxis: Teams, die ihre Probleme präzise formulieren können, treffen bessere Entscheidungen, sparen sich überflüssige Features – und steigern die Zufriedenheit ihrer Nutzer:innen spürbar.

Deshalb ist unser Rat klar: Versteh das Problem – bevor du eine Lösung formulierst.

Ausblick: Struktur in die Unsicherheit bringen

Im nächsten Teil zeigen wir dir zwei Templates, mit denen du aus vagen Ideen glasklare Problemstellungen entwickelst – konkret, nachvollziehbar und sofort nutzbar.

Wenn du wissen willst, wie du Problem Statements im Team einführst – oder typische Stolperfallen erkennst:

Sprich uns an. Wir helfen Teams, mehr Wirkung mit weniger Aufwand zu erzielen.

Bis dahin: Kill the Requirement – aber mit Verstand.