Eine nützliche Problemstellung beschreibt eine beobachtete Lücke zwischen dem, was Menschen erreichen müssen, und dem, was heute tatsächlich geschieht. Nennen Sie die betroffene Gruppe, die Aufgabe oder den Prozess, die Bedingungen, unter denen die Lücke auftritt, und ihre Folgen. Eine bevorzugte Lösung und eine ungeprüfte Ursache gehören nicht in die Problemstellung, damit beide weiter untersucht werden können.
Es gibt keinen einzigen verpflichtenden Aufbau für Problemstellungen in allen Organisationen. Der folgende Aufbau ist eine praktische Schreibhilfe. Er eignet sich für eine Produkt-Discovery, einen Projektvorschlag oder ein wiederkehrendes Thema aus einer Team-Retrospektive.
Das Prinzip, vor der Festlegung auf eine Lösung das Problem zu verstehen, findet sich auch im Discovery-Leitfaden von GOV.UK. Die Beispiele und der Workshop in diesem Artikel sind eigene hypothetische Veranschaulichungen, keine berichteten Kundenergebnisse.
Eine kopierbare Vorlage für die Problemstellung
Verwenden Sie diesen Satz als Ausgangspunkt:
Wenn [Kontext], muss [betroffene Gruppe] [Aufgabe oder gewünschtes Ergebnis], aber [beobachtete Lücke]. Belege aus [Quelle und Zeitraum] zeigen [Umfang oder Häufigkeit, falls bekannt], was zu [belegter Folge] führt.
Ergänzen Sie anschließend eine kurze Evidenznotiz:
- Bekannt: Beobachtungen, die die Problemstellung stützen.
- Unbekannt: Fragen, deren Antwort die Interpretation ändern könnte.
- Außerhalb des Umfangs: Angrenzende Probleme, die dieses Vorhaben nicht behandelt.
- Erfolgssignal: Welche beobachtbare Veränderung relevant wäre.
Erzwingen Sie nicht in jedem Feld eine Zahl. „Häufigkeit noch nicht gemessen“ ist vertrauenswürdiger als ein erfundener Ausgangswert. Wenn die Quelle nur eine kleine oder ungewöhnliche Stichprobe abdeckt, benennen Sie diese Grenze. Eine Problemstellung sollte mit besserer Evidenz präziser werden.
Was gehört in die Problemstellung?
| Element | Nützliche Formulierung | Zu hinterfragende Formulierung |
|---|---|---|
| Betroffene Menschen | Neue Kontoadministratoren | Alle |
| Aufgabe | Kollegen einladen und Zugriff bestätigen | Unser Produkt besser nutzen |
| Beobachtete Lücke | Ausstehende und angenommene Einladungen sind nicht unterscheidbar | Brauchen ein Dashboard |
| Kontext | Nach dem Versand mehrerer Einladungen | Immer |
| Folge | Wenden sich zur Statusbestätigung an den Support | Verlieren Millionen durch mangelnde Produktivität |
| Evidenz | Geprüfte Fälle aus einem benannten Zeitraum | Das ist offensichtlich |
Eine Folge kann qualitativ sein. Wenn jemand für eine ansonsten selbstständig ausführbare Aufgabe Hilfe benötigt, ist das beispielsweise auch dann bedeutsam, wenn die finanziellen Kosten noch unbekannt sind. Rechnen Sie nicht jede Unannehmlichkeit ohne nachvollziehbare Methode in Umsatzverluste um.
Ausgearbeitetes Beispiel: Von der Anfrage zum Problem
Hypothetisches Beispiel: Ein Projekt beginnt mit der Anfrage „Baut ein Einladungs-Dashboard“. Das ist ein Lösungsvorschlag. Das Team könnte ihn korrekt umsetzen und trotzdem das falsche Problem lösen.
Während der Discovery prüft das Team zwölf Supportgespräche aus einem festgelegten Monat und beobachtet vier Administratoren bei der Einladungsaufgabe. Mehrere fragen, ob eine Einladung zugestellt oder angenommen wurde. Diese Beobachtungen deuten auf ein untersuchenswertes Problem hin, belegen aber nicht seine Verbreitung unter allen Kunden.
Eine bessere Problemstellung lautet:
Nachdem Kontoadministratoren mehrere Kollegen eingeladen haben, müssen sie bestätigen können, wer auf den Arbeitsbereich zugreifen kann. Die Einladungsansicht unterscheidet jedoch nicht zwischen ausstehenden und angenommenen Einladungen. Supportgespräche und vier beobachtete Sitzungen zeigen, dass Administratoren die Bestätigung anderswo suchen und den Onboarding-Prozess dadurch um eine manuelle Prüfung ergänzen.
Das Team ergänzt zwei offene Fragen: Tritt die Unsicherheit auch bei anderen als den beobachteten Kontotypen auf, und tragen Zustellfehler ebenfalls dazu bei? Mögliche Antworten sind nun klarere Statusbezeichnungen, eine Bestätigungsnachricht, eine Aktivitätsansicht oder Änderungen am Einladungsprozess. Die Problemstellung entscheidet nicht vorschnell zwischen ihnen.
Drei gängige Aufbauten und ihre Einsatzgebiete
Kurze Entscheidungsbeschreibung: Verwenden Sie zwei oder drei Sätze in einer Projektbeschreibung, wenn Leser das Problem schnell erfassen müssen. Verlinken Sie die Evidenz, statt die gesamte Forschungsdokumentation anzuhängen.
Istzustand, Sollzustand, Lücke: Verwenden Sie diesen Aufbau, wenn für einen Prozess eine festgelegte Erwartung besteht. Beschreiben Sie den heutigen Zustand, erläutern Sie den erforderlichen Zustand und benennen Sie den Unterschied. Prüfen Sie, ob der Sollzustand tatsächlich notwendig ist und nicht nur der Vorliebe einer Führungskraft entspricht.
Nutzer, Aufgabe, Hindernis, Folge: Verwenden Sie diesen Aufbau, wenn ein Produkt- oder Serviceproblem mit dem Erleben einer Person beginnt. Berücksichtigen Sie betriebliche Einschränkungen, damit die Problemstellung nicht nahelegt, eine Bildschirmänderung allein könne einen umfassenderen Prozess reparieren.
Das sind Schreibstrukturen, keine konkurrierenden Methoden. Wählen Sie den kleinsten Aufbau, der Ihre Entscheidung verständlich macht. Wird ein einzelner Satz unlesbar, verwenden Sie einen Absatz und eine ergänzende Tabelle.
Ein 35-minütiger Workshop zur Problemformulierung
Beteiligen Sie Menschen, die das Problem erleben, und Menschen, die die Evidenz einordnen können. Nehmen Sie jemanden dazu, der die angenommene Lösung hinterfragen kann. Versenden Sie das Quellenmaterial vorab und erläutern Sie, welche Aussagen noch unsicher sind.
- Fünf Minuten: Still lesen. Alle markieren Beobachtungen, Interpretationen und Lösungsvorschläge auf unterschiedliche Weise.
- Acht Minuten: Eigene Problemstellungen schreiben. Bitten Sie alle, die Lücke zu beschreiben, ohne ein Produkt, Werkzeug oder eine Umsetzung zu benennen.
- Zehn Minuten: Grenzen vergleichen. Besprechen Sie, wer betroffen ist, welcher Kontext zählt und was außerhalb des Vorhabens liegt.
- Sieben Minuten: Eine gemeinsame Version schreiben. Halten Sie strittige Aussagen in einer Unsicherheitsnotiz fest.
- Fünf Minuten: Den nächsten Evidenzschritt wählen. Benennen Sie die verantwortliche Person und die Entscheidung, zu der die Evidenz beitragen soll.
Das Ziel ist nicht einhellige Zuversicht. Es ist eine überprüfbare Problemstellung, die zeigt, wo die Sicherheit endet. Kann sich die Gruppe nicht über die betroffene Personengruppe einigen, ist als Nächstes möglicherweise Forschung statt eines Lösungsworkshops nötig.
Versteckte Lösungen und unbelegte Ursachen erkennen
„Kunden brauchen einen KI-Assistenten“ schreibt eine Technologie vor. Fragen Sie, welche Aufgabe schwierig ist und welches Ergebnis die Menschen erreichen wollen. Eine Technologie kann in der Optionsliste bleiben, ohne zur Definition des Bedarfs zu werden.
„Anfragen verzögern sich, weil es dem Team egal ist“ unterstellt ohne Belege eine Motivation. Ersetzen Sie dies durch eine beobachtbare Bedingung, etwa Anfragen, die nach einer Übergabe unzugewiesen bleiben, und untersuchen Sie anschließend, warum diese Bedingung entsteht.
„Die Kommunikation ist schlecht“ ist zu allgemein, um Handlungen anzuleiten. Bestimmen Sie, welche Information zwischen welchen Personen an welchem Entscheidungspunkt fehlt und mit welcher Folge. Die Antwort kann mehrere getrennte Probleme sichtbar machen. Teilen Sie sie auf, statt eine Problemstellung zu schaffen, für die niemand Verantwortung übernehmen kann.
Eine Retrospektive ist ein Weg, wiederkehrende Lücken in der Teamarbeit zu finden. Verwenden Sie ein einfaches Board-Format, um Beobachtungen zu sammeln, und nehmen Sie das ausgewählte Thema anschließend in diesen Prozess der Problemformulierung auf.
Entscheiden, ob die Problemstellung bereit ist
Bitten Sie einen mit dem Projekt nicht vertrauten Kollegen, sie zu lesen. Kann die Person erkennen, wer betroffen ist, beschreiben, was schiefläuft, und zwei unterschiedliche Antworten vorschlagen? Kann sie nur Ihre bevorzugte Lösung wiederholen, überarbeiten Sie die Problemstellung.
Prüfen Sie dann die Nachvollziehbarkeit: Jede Tatsachenbehauptung sollte mit Evidenz verbunden und jede Annahme gekennzeichnet sein. Vereinbaren Sie, wann die Problemstellung erneut geprüft wird. Neue Evidenz kann das Problem eingrenzen, eine andere Ursache offenlegen oder zeigen, dass es keinen weiteren Aufwand rechtfertigt.
Nachdem eine Änderung getestet wurde, prüfen Sie sie mit dem Verbesserungsprozess der Retrospektive. Eine Umsetzung abzuschließen ist nicht dasselbe, wie die beobachtete Lücke zu schließen.
Häufig gestellte Fragen
Wie lang sollte eine Problemstellung sein?
Für die Problemstellung selbst reicht meist ein kurzer Absatz. Halten Sie Evidenz, Annahmen und Grenzen in einer ergänzenden Notiz fest, damit die Präzision die Hauptaussage nicht unlesbar macht.
Sollte eine Problemstellung die Lösung enthalten?
Halten Sie die Lösung getrennt, es sei denn, der Kontext verlangt ausdrücklich eine eingeschränkte Umsetzung. Erklären Sie das Problem auch dann unabhängig, damit Leser beurteilen können, ob die gewählte Antwort es behandelt.
Was, wenn wir noch keine quantitativen Belege haben?
Verwenden Sie konkrete qualitative Beobachtungen und beschreiben Sie deren Grenzen. Halten Sie die fehlende Messung als nächsten Schritt fest, statt eine Häufigkeit, Kosten oder einen erwarteten Nutzen zu erfinden.