Vom Thema zum Problemraum — Wie aus einer Idee eine bearbeitbare Projektfrage wird

Warum gute KI-Projekte nicht mit einer Lösung beginnen, sondern mit einem Problemraum, der groß genug zum Verstehen und eng genug zum Bearbeiten ist.

Viele Projekte beginnen mit einem Satz, der sich bereits nach Richtung anhört: „Ich möchte eine App bauen." „Wir wollen KI im Unternehmen einsetzen." „Ich brauche ein automatisiertes System." „Ich möchte mein Portfolio neu aufstellen." Solche Sätze sind wertvoll, weil sie Energie erzeugen. Für eine belastbare Projektarbeit reichen sie trotzdem noch nicht aus.

Denn eine Idee kann drei völlig unterschiedliche Dinge gleichzeitig enthalten: ein wahrgenommenes Problem, einen Wunschzustand und bereits eine bevorzugte Lösung. Genau diese Vermischung ist gefährlich. Wenn die Lösung zu früh feststeht, wird die spätere Recherche leicht zur Bestätigung dessen, was man ohnehin schon tun wollte. Wenn das Problem zu weit formuliert ist, verliert sich das Projekt in Möglichkeiten. Wenn es zu eng formuliert ist, werden relevante Alternativen ausgeschlossen, bevor man sie überhaupt gesehen hat.

Eine bewährte Methodik setzt deshalb vor Konzept und Projektplan einen eigenen Arbeitsschritt: Aus einer Ausgangsfrage wird zunächst ein Problemraum. Erst danach folgen Recherche, Anforderungen, Ideenraum, Variantenbewertung, Architekturentwurf, Plausibilitätsprüfung und schließlich das Konzept.

Der Problemraum ist damit keine akademische Zwischenübung. Er ist der Ort, an dem entschieden wird, welche Welt das Projekt überhaupt betrachtet.

Ein Thema ist noch keine Projektfrage

„KI im Kundenservice" ist ein Thema. „Eine lokale KI für Kundenservice" ist bereits eine Lösungsrichtung. „Wie kann unser Supportteam wiederkehrende Anfragen schneller bearbeiten, ohne sensible Kundendaten unnötig an externe Systeme weiterzugeben?" ist dagegen eine bearbeitbare Projektfrage.

Der Unterschied liegt nicht in der Länge, sondern in der Struktur.

Ein Thema bezeichnet ein Feld. Eine Idee fügt oft eine Absicht hinzu. Eine Projektfrage beschreibt eine konkrete Veränderung, einen Kontext und einen Prüfbedarf. Sie lässt noch mehrere Lösungen offen und ist präzise genug, um gezielt Informationen zu sammeln.

Das ist besonders bei KI wichtig. Sprachmodelle reagieren sehr gut auf Lösungsvorgaben. Wer nach einer „KI-App für X" fragt, bekommt schnell eine Architektur für eine KI-App. Wer nach einem „Agenten für Y" fragt, bekommt einen Agentenentwurf. Das kann nützlich sein — aber nur, wenn vorher geklärt wurde, ob App oder Agent überhaupt die richtige Form sind.

Eine bearbeitbare Projektfrage schützt deshalb vor einem typischen Fehler: Die Form der ersten Idee wird nicht automatisch mit dem eigentlichen Problem gleichgesetzt.

Der Problemraum ist größer als die erste Lösung

Ein Problemraum enthält alle Bedingungen, Spannungen und offenen Fragen, die für die Entscheidung relevant sein könnten. Er ist absichtlich breiter als die spätere Lösung.

Angenommen, jemand möchte „einen KI-Agenten für Social Media". Die vorschnelle Projektplanung könnte sofort Tasks erzeugen: Plattformen anbinden, Posting-Zeitplan erstellen, Promptbibliothek aufbauen, Freigaben automatisieren. Doch der Problemraum könnte ganz anders aussehen:

• Es fehlt nicht an Content, sondern an einer klaren Positionierung.

• Es fehlt nicht an Automatisierung, sondern an verlässlicher Qualitätskontrolle.

• Es fehlt nicht an Geschwindigkeit, sondern an konsistenten Quellen.

• Es fehlt nicht an Ideen, sondern an einem Workflow, der aus Rohmaterial markenkonforme Beiträge macht.

• Es gibt möglicherweise rechtliche, organisatorische oder reputative Grenzen, die eine Vollautomatisierung ausschließen.

Erst wenn diese Unterschiede sichtbar sind, kann die Frage sinnvoll lauten: Was genau soll verbessert werden, für wen, unter welchen Bedingungen und woran erkennen wir später, dass die Verbesserung eingetreten ist?

Der Problemraum verhindert somit nicht Kreativität. Er gibt Kreativität eine Richtung.

Ausgangsfrage: der erste brauchbare Schnitt

Die Konzeptkette beginnt mit einer Ausgangsfrage. Diese Frage muss noch nicht perfekt sein. Sie soll vor allem verhindern, dass das Projekt lediglich als Produktwunsch beschrieben wird.

Eine gute Ausgangsfrage enthält möglichst wenig Lösung und möglichst viel Beobachtung. Statt „Wie baue ich einen KI-Agenten für mein Unternehmen?" ist beispielsweise „Welche wiederkehrenden Arbeitsabläufe binden aktuell viel Zeit, und welche davon könnten mit vertretbarem Risiko teilweise automatisiert werden?" die stärkere Startfrage.

Die zweite Formulierung öffnet mehr sinnvolle Wege. Vielleicht ist später ein Agent die beste Lösung. Vielleicht genügt eine kleine Automatisierung. Vielleicht liegt das eigentliche Problem in der Datenqualität. Vielleicht ist eine Prozessänderung wichtiger als neue Software.

Das Ziel der Ausgangsfrage ist daher nicht, sofort den richtigen Weg zu benennen. Sie soll die richtige Untersuchung starten.

Vom Satz zum Problemraum

Eine Ausgangsfrage wird erst dann zu einem Problemraum, wenn sie in mehrere Perspektiven zerlegt wird. Dabei helfen fünf einfache Dimensionen.

1. Betroffene

Wer erlebt das Problem tatsächlich? Wer arbeitet mit dem späteren Ergebnis? Wer muss zustimmen? Wer trägt Nachteile, wenn die Lösung scheitert?

Die Person, die ein Projekt bestellt, ist nicht automatisch die Person, die das Problem im Alltag erlebt. Diese Differenz verändert Anforderungen oft fundamental.

2. Ist-Zustand

Was passiert heute konkret? Wo entstehen Verzögerungen, Fehler, Reibung, Kosten oder Unsicherheit? Welche Workarounds existieren bereits?

Der Ist-Zustand sollte beschreibbar sein, ohne KI zu erwähnen. Das ist ein guter Test. Wenn sich das Problem nur in Form der gewünschten Technologie erklären lässt, ist es meist noch nicht sauber formuliert.

3. Veränderungsziel

Was soll nach dem Projekt anders sein? Schneller? Günstiger? Sicherer? Verständlicher? Konsistenter? Skalierbarer? Kreativer? Weniger abhängig von Einzelpersonen?

Ein Veränderungsziel ist noch keine Lösung. Es beschreibt eine Richtung, die später mit mehreren Varianten erreicht werden kann.

4. Rahmenbedingungen

Welche Ressourcen, Fristen, Systeme, Kompetenzen, Datenbestände, Zuständigkeiten und Abhängigkeiten existieren bereits?

Rahmenbedingungen sind keine lästigen Einschränkungen. Sie machen ein Projekt real.

5. Grenzen

Was gehört ausdrücklich nicht zum Problem? Was soll in dieser Projektstufe nicht gelöst werden? Welche Entscheidungen werden bewusst später getroffen?

Ohne Grenzen wächst ein Problemraum leicht zur allgemeinen Weltbeschreibung. Mit Grenzen wird er bearbeitbar.

Gute Fragen öffnen und begrenzen zugleich

Das klingt zunächst widersprüchlich. Eine gute Projektfrage soll offen genug sein, damit nicht schon die erste Lösung feststeht. Gleichzeitig muss sie eng genug sein, damit Recherche und Planung nicht beliebig werden.

Dafür braucht es zwei Bewegungen.

Die erste Bewegung ist Divergenz: Wir öffnen das Thema. Welche Ursachen könnten hinter dem beobachteten Problem liegen? Welche Stakeholder sehen es anders? Welche Alternativen existieren? Welche Annahmen stecken in der ersten Idee?

Die zweite Bewegung ist Konvergenz: Wir begrenzen. Welche Teilfrage ist für dieses Projekt entscheidend? Welche Perspektiven sind relevant? Welche Bedingungen sind nicht verhandelbar? Was wird bewusst ausgeschlossen?

Ein Problemraum ist gut, wenn beide Bewegungen stattgefunden haben. Nur Öffnung führt zu endloser Analyse. Nur Begrenzung führt zu Tunnelblick.

Hypothesen statt versteckter Gewissheiten

Viele Projektideen enthalten Annahmen, die sprachlich wie Tatsachen behandelt werden.

„Unsere Kunden wollen einen Chatbot."

„Die Mitarbeitenden verlieren zu viel Zeit durch manuelle Recherche."

„Ein lokales Modell wäre günstiger."

„Automatisierung wird unsere Qualität verbessern."

Diese Sätze können stimmen. Solange sie nicht geprüft sind, sollten sie jedoch als Hypothesen behandelt werden.

Das ist ein entscheidender methodischer Unterschied. Eine Hypothese darf sich als falsch erweisen. Eine versteckte Gewissheit lenkt dagegen die gesamte Arbeit in Richtung Bestätigung.

Für den Problemraum ist deshalb eine kleine Hypothesenliste hilfreich:

# HYPOTHESEN

H1: Das beobachtete Problem tritt häufig genug auf, um ein Projekt zu rechtfertigen.
H2: Die vermutete Ursache ist tatsächlich relevant.
H3: Die betroffenen Personen erleben das Problem ähnlich.
H4: Eine technische Intervention kann den Zustand verbessern.
H5: Die Verbesserung lässt sich messen oder zumindest nachvollziehbar bewerten.

Diese Liste ist keine wissenschaftliche Studie. Sie macht lediglich sichtbar, welche Aussagen noch überprüft werden müssen.

Annahmen, Wissen und offene Fragen trennen

Ein besonders wirksamer Schritt besteht darin, den Problemraum in drei Spalten zu zerlegen:

Wir wissen: Dinge, die durch Beobachtung, Daten oder verlässliche Quellen bereits gestützt sind.

Wir nehmen an: Dinge, die plausibel erscheinen, aber noch nicht geprüft wurden.

Wir müssen herausfinden: Informationen, die für eine spätere Entscheidung fehlen.

Diese Trennung verhindert, dass ein langer KI-Output wie gesichertes Wissen behandelt wird. Sie bereitet außerdem direkt Artikel 3 dieser Reihe vor: Deep Research wird dann nicht mehr als allgemeines „Recherche bitte alles"-Kommando eingesetzt, sondern als gezielte Bearbeitung konkreter Wissenslücken.

So entsteht ein wichtiger Übergang: Der Problemraum definiert die Fragen, die Recherche beantwortet. Recherche definiert nicht rückwirkend, welches Problem man haben wollte.

Der Fokus entsteht durch Ausschlüsse

Ein Projekt wird nicht nur klarer durch das, was es einschließt. Es wird vor allem klarer durch das, was es bewusst nicht einschließt.

Ein Non-Scope kann beispielsweise lauten:

• keine vollständige Unternehmensautomatisierung;

• keine Migration aller Alt-Systeme;

• keine autonome Veröffentlichung ohne Freigabe;

• keine neue Markenstrategie;

• keine technische Eigenentwicklung im ersten Prototyp;

• keine Entscheidung über den finalen Anbieter in der Konzeptphase.

Solche Ausschlüsse sind keine Schwäche. Sie schützen den Erkenntniswert des Projekts.

Wenn zu viele Probleme gleichzeitig gelöst werden sollen, lässt sich später kaum erkennen, warum etwas funktioniert oder scheitert. Ein klarer Scope macht dagegen Ursache und Wirkung besser sichtbar.

Von der Problemformulierung zur Projektfrage

Am Ende dieser Arbeit sollte der Problemraum in eine Frage verdichtet werden, die fünf Eigenschaften besitzt.

Sie ist kontextgebunden

Sie nennt, in welchem Umfeld die Veränderung stattfinden soll.

Sie ist lösungsoffen

Sie zwingt nicht schon im Satz zu App, Agent, Modell, Plattform oder Anbieter.

Sie enthält einen Veränderungswunsch

Es ist erkennbar, was besser werden soll.

Sie ist prüfbar

Man kann später begründet sagen, ob eine Variante die Frage überzeugend beantwortet.

Sie ist begrenzt

Die Frage hat einen Scope, der im verfügbaren Projekt bearbeitbar ist.

Eine praktische Formel lautet:

Wie können wir [beobachteten Zustand / Problem]
für [Betroffene / Nutzungskontext]
so verändern, dass [gewünschter Effekt],
unter den Bedingungen [wichtige Grenzen],
ohne [kritischer Non-Scope / unerwünschter Effekt]?

Diese Formel ist kein Zwang. Sie ist ein Test. Wenn die Elemente nicht ausgefüllt werden können, ist der Problemraum wahrscheinlich noch nicht klar genug.

Beispiel: von „Ich will eine KI-App" zur Projektfrage

Nehmen wir eine Ausgangsidee:

„Ich möchte eine KI-App für meine Kundinnen und Kunden bauen."

Die Idee enthält bereits die Lösung „App", sagt aber kaum etwas über das Problem.

Schritt 1: Beobachtung

Kundinnen und Kunden stellen häufig ähnliche Fragen und warten auf Antworten, wenn das Team nicht verfügbar ist.

Schritt 2: Betroffene

Kundschaft, Supportteam und gegebenenfalls Fachabteilungen, die komplexe Fälle übernehmen.

Schritt 3: Ziel

Einfache Fragen sollen schneller beantwortet werden, ohne die Qualität komplexer Beratung zu verschlechtern.

Schritt 4: Annahmen

Wir nehmen an, dass ein relevanter Anteil der Anfragen wiederkehrend ist und dass sich verlässliche Antwortgrundlagen bereitstellen lassen.

Schritt 5: Grenzen

Keine autonomen Entscheidungen über individuelle Verträge; keine Ersetzung persönlicher Beratung bei komplexen Fällen.

Verdichtete Projektfrage

„Wie können wir wiederkehrende Kundenanfragen außerhalb der direkten Supportzeiten schneller beantworten, ohne komplexe Fälle oder individuelle Entscheidungen aus der menschlichen Beratung herauszulösen?"

Jetzt ist die App nur noch eine mögliche Variante. Genau das ist methodisch wertvoll.

KI kann den Problemraum erweitern — aber nicht besitzen

Generative KI eignet sich hervorragend dafür, blinde Flecken zu finden. Sie kann Stakeholder-Perspektiven simulieren, Gegenfragen erzeugen, alternative Ursachen vorschlagen oder eine zu enge Problemformulierung kritisieren.

Aber auch hier gilt: Die KI besitzt den Problemraum nicht. Sie hat keinen direkten Zugang zur Organisation, zu implizitem Erfahrungswissen oder zu den Folgen einer Entscheidung. Ihre Aufgabe ist daher nicht, den Problemraum endgültig zu definieren, sondern den Menschen dabei zu unterstützen, ihn sichtbar zu machen.

Nützliche Arbeitsaufträge sind beispielsweise:

Welche Annahmen verstecken sich in meiner Projektidee?

Welche drei alternativen Ursachen könnten das beobachtete Problem erklären?

Welche Stakeholder würden meine Problemdefinition wahrscheinlich anders formulieren?

Welche Lösung setze ich in meiner Formulierung bereits voraus?

Welche Grenzen fehlen, damit diese Frage in vier bis acht Wochen sinnvoll bearbeitbar wäre?

Welche Informationen müsste ich kennen, bevor ich zwischen drei Lösungsvarianten entscheide?

Solche Fragen nutzen KI als Perspektivmaschine, nicht als Orakel.

Der Problemraum ist ein lebendes Arbeitsobjekt

Ein häufiger Fehler besteht darin, die Problemdefinition einmal zu schreiben und dann nie wieder anzusehen. In der Konzeptlogik sind Rückschleifen jedoch ausdrücklich Teil der Methode.

Recherche kann zeigen, dass eine angenommene Ursache unwichtig ist. Anforderungen können einen Konflikt sichtbar machen. Eine Variante kann offenlegen, dass der Scope zu breit ist. Eine Plausibilitätsprüfung kann die Ausgangsfrage verändern.

Das bedeutet nicht, dass man ohne Richtung arbeitet. Im Gegenteil: Änderungen werden begründbar.

Ein guter Problemraum besitzt deshalb Versionen. Zum Beispiel:

• v0.1: erste Problemhypothese;

• v0.2: nach Stakeholder-Perspektiven;

• v0.3: nach Grundlagenrecherche;

• v0.4: nach Anforderungen und Non-Scope;

• v1.0: ausreichend stabil für Konzept- und Variantenarbeit.

So wird aus „wir haben unsere Meinung geändert" eine nachvollziehbare Lernbewegung.

Wann ist der Problemraum gut genug?

Perfekt wird er nicht. Das Ziel ist Arbeitsfähigkeit.

Ein Problemraum ist ausreichend reif, wenn folgende Fragen beantwortet werden können:

• Was beobachten wir konkret?

• Wer ist betroffen?

• Was soll sich verändern?

• Welche Ursachen sind nur Hypothesen?

• Was wissen wir bereits?

• Welche Wissenslücken sind entscheidungsrelevant?

• Welche Grenzen gelten?

• Was gehört ausdrücklich nicht in das Projekt?

• Welche Projektfrage leitet die nächste Recherche?

• Woran würden wir erkennen, dass wir die Frage später überzeugend beantwortet haben?

Wenn diese Punkte klar sind, kann Deep Research gezielt beginnen. Vorher produziert zusätzliche Recherche oft nur mehr Material.

Klarheit vor Tiefe

KI verführt dazu, sehr schnell sehr tief zu gehen. Man kann in Minuten lange Marktanalysen, technische Architekturen oder Projektpläne erzeugen. Doch Tiefe auf der falschen Frage ist kein Fortschritt.

Der Problemraum ist deshalb ein Filter für Aufmerksamkeit. Er entscheidet, welche Fragen wichtig sind und welche nur interessant klingen.

Die eigentliche Produktivität entsteht nicht dadurch, dass jede denkbare Perspektive recherchiert wird. Sie entsteht dadurch, dass ein Projekt zuerst weiß, welche Unsicherheit es reduzieren muss.

Genau an dieser Stelle beginnt der nächste Artikel: Deep Research ist dann keine Taste und kein langer Bericht, sondern eine Kette aus gezielten Fragen, Quellen, Zwischenergebnissen und Anschlussrecherchen.

Arbeitsblatt: Vom Thema zur bearbeitbaren Projektfrage

1. Schreibe dein Thema in einem Satz

Noch keine Lösung erklären. Nur das Feld und den wahrgenommenen Veränderungsbedarf benennen.

2. Notiere die erste Lösung, die dir spontan einfällt

Schreibe sie bewusst separat auf. Sie darf später zurückkehren, aber sie soll den Problemraum nicht dominieren.

3. Beschreibe den Ist-Zustand

Was passiert heute konkret? Nenne beobachtbare Situationen statt allgemeiner Bewertungen.

4. Benenne Betroffene und Perspektiven

Wer erlebt das Problem, wer entscheidet, wer nutzt das Ergebnis und wer trägt Risiken?

5. Trenne Wissen, Annahmen und offene Fragen

Erstelle drei Spalten. Markiere besonders Annahmen, die bisher wie Tatsachen behandelt wurden.

6. Formuliere drei Hypothesen

Welche Annahmen müssen sich als ausreichend richtig erweisen, damit das Projekt sinnvoll bleibt?

7. Setze Scope und Non-Scope

Was soll dieses Projekt lösen? Was ausdrücklich nicht?

8. Formuliere zwei alternative Projektfragen

Eine etwas breiter, eine enger. Vergleiche, welche bessere Recherche und bessere Entscheidungen ermöglichen würde.

9. Wähle eine Arbeitsfrage

Nutze bei Bedarf die Formel:

Wie können wir [beobachteten Zustand / Problem]
für [Betroffene / Nutzungskontext]
so verändern, dass [gewünschter Effekt],
unter den Bedingungen [wichtige Grenzen],
ohne [kritischer Non-Scope / unerwünschter Effekt]?

10. Definiere die erste Wissenslücke

Welche eine Frage muss als Nächstes recherchiert werden, bevor du sinnvoll weiterplanen kannst?

Reflexion

Die Lösung, die ich bisher zu früh vorausgesetzt habe: _________________________________________________

Die wichtigste Annahme, die ich prüfen muss: __________________________________________________________

Die Grenze, die mein Projekt endlich bearbeitbar macht: _______________________________________________

Alle Materialien zum Download – die Themenübersicht und das Übungsblatt: