Anforderungen sind schnell gesammelt – aber selten durchdacht. Was wirklich fehlt? Ein gemeinsames Verständnis vom Problem. Warum Problem Engineering kein Trend, sondern die Grundlage für gute Produkte ist – und wie du mit zwei einfachen Templates sofort bessere Diskussionen führst.
Problem Engineering statt Requirements Engineering: Was sich wirklich ändern muss
Wir sagen es in jedem Training, jedem Workshop, jedem Strategiemeeting:
Ein gutes Requirements Engineering erkennt man nicht daran, wie viele Anforderungen dokumentiert wurden – sondern wie viele unnötige vermieden werden.
Und genau hier setzen wir an. Denn viele Teams entwickeln mit hohem Engagement – aber auf Basis von System-Anforderungen, die nie hinterfragt wurden. Sie dokumentieren sauber, schätzen fleißig, liefern pünktlich – aber für ein Problem, das keiner richtig verstanden hat.
Problem Engineering: Kein Buzzword, sondern Basis
Während das klassische Requirements Engineering fragt:
„Was sind die Anforderungen?“
stellt Problem Engineering eine viel entscheidendere Frage:
„Welches Problem gibt es hier überhaupt?“
Es geht nicht um Umsetzung. Es geht um Orientierung. Um Klarheit. Um Wirkung.
In unserer Beratungspraxis nennen wir das strategisches Denken im Problemraum. Es beginnt mit der ehrlichen Analyse: Was ist hier wirklich los? Es verlangt, Problem- und Lösungsraum sauber zu trennen – und erst dann System-Anforderungen zu formulieren, wenn das Ziel klar ist. Und genau das verändert Projekte fundamental
Warum Requirements Engineering so oft scheitert
Viele der Teams, mit denen wir arbeiten, erleben genau das:
Anforderungen werden umgesetzt, aber sie bringen keinen Nutzen.
Warum?
Weil Ziele unklar sind.
Weil Anforderungen widersprüchlich sind.
Weil Stakeholder-Annahmen nie validiert wurden.
Die Folge: Überarbeitung, Projektverzögerungen, Frustration – und Backlogs, die mehr Verwaltung als Wert schaffen. Das ist kein technisches, sondern ein systemisches Problem im RE-Prozess.
Was du stattdessen brauchst: Ein Denkrahmen für echte Probleme
Unsere Empfehlung: Starte nicht mit der Lösung – starte mit einem strukturierten Problem Statement.
Hier zwei Formate (Inspired by Design Thinking und UX-Kontext), die wir seit Jahren mit unseren Kunden erfolgreich einsetzen – in Projekten, in Reviews, in Roadmap-Entscheidungen.
Template 1 – Problemzentriert
„Als [Rolle] versuche ich [Ziel], aber ich scheitere an [Hindernis], weil [Ursache], was dazu führt, dass [Konsequenz].“
Beispiel:
„Als verantwortungsvolle Tierhalterin versuche ich, zu verreisen, aber ich kann meinen kranken Koi nicht in fremde Hände geben, weil seine Pflege komplex ist, was dazu führt, dass ich mich dauerhaft belastet und eingeschränkt fühle.“
Was daran so stark ist? Es macht sichtbar, wer betroffen ist, woran er oder sie scheitert – und was es kostet, dieses Problem ungelöst zu lassen. Es erzeugt Kontext, Empathie und Dringlichkeit – statt rein technischer Beschreibung.
Template 2 – Lösungsnah mit Wertbezug
„[Zielgruppe] brauchen [etwas], weil [Kontext]. Die bisherige Lösung ist [so], was dazu führt, dass [Konsequenz]. Eine bessere Lösung könnte [Ansatz] sein.“
Beispiel:
„Koi-Halter:innen brauchen eine Möglichkeit, gezielt Medikamente zu verabreichen, weil eine Behandlung über den gesamten Teich auch gesunde Fische belastet und die Wasserqualität beeinträchtigt. Die bisherige Lösung ist: den ganzen Teich medikamentieren oder den Fisch mühsam separieren, was dazu führt, dass hohe Kosten, Stress und Nebenwirkungen entstehen. Eine bessere Lösung könnte ein punktgenaues, mobiles Verabreichungssystem sein.“
Dieses Format bringt Struktur in Diskussionen – und hebt die Frage: „Was bringt es wirklich?“ auf ein neues Niveau.
Warum das in der Praxis funktioniert
Problem Statements richten den Blick auf Menschen – nicht nur auf Features.
Sie helfen Teams, Wert statt Aufwand zu priorisieren.
Und sie schaffen eine Gesprächsqualität, die aus reiner Umsetzung echte Innovation macht.
In unseren Projekten sehen wir:
Wer Problem Statements einführt, braucht weniger Abstimmungen, weniger Schleifen, weniger Rechtfertigungen – und hat deutlich mehr Klarheit im Team.
Was sich dafür im Team verändern muss
Problem Engineering ist keine Methode, die man zusätzlich macht – es ist ein Haltungswandel. Es braucht:
Einzelgespräche statt starrer Workshops
Interesse an den echten Bedürfnissen – nicht nur an Rollen
und ein:e Problem Engineer:in, der oder die zuhören, übersetzen und einordnen kann
Diese Rolle ist in modernen Entwicklungsprozessen zentral – und wir unterstützen regelmäßig Teams dabei, sie gezielt aufzubauen oder als Kompetenz im Product Team zu etablieren.
Ausblick: Entscheidungen durch Bedeutung
Im nächsten Teil zeigen wir dir, warum gute Problemgeschichten mehr bewegen als jede noch so präzise System-Anforderung – und wie du Storytelling im RE-Kontext ganz pragmatisch nutzen kannst.
Wenn du bis dahin Klarheit schaffen willst: Lass uns sprechen.
Wir helfen dir, das Problem wieder zum Zentrum deiner Produktstrategie zu machen.
Bis bald – mit Teil 3 von „Kill the Requirement“.