problem-statement

Überblick über die problem-statement-Funktion

Die problem-statement-Funktion hilft dir, eine vage Produktanfrage in ein nutzerzentriertes Problem Statement zu überführen, das klar beschreibt, wer blockiert ist, was die Person erreichen will, warum das wichtig ist und wie sich das anfühlt. Besonders nützlich ist problem-statement, wenn du vor der Lösungsfindung Abstimmung brauchst: in Discovery, Priorisierung, PRDs und Stakeholder-Reviews.

Wofür problem-statement gedacht ist

Diese problem-statement-Funktion ist für das Framing gedacht, nicht für das Feature-Design. Sie hilft dir, das Problem aus Sicht der Nutzer zu beschreiben, damit Teams vor der Implementierungsdebatte beurteilen können, ob sich die Arbeit überhaupt lohnt.

Für wen es am besten passt

Nutze problem-statement, wenn du Product Briefs, technische Spezifikationen, Research-Zusammenfassungen oder Roadmap-Notizen schreibst und dafür eine klarere Problemerzählung brauchst. Für Technical-Writing-Workflows ist die Funktion besonders stark, wenn du unsauberen Input in ein präzises, empathisches Statement übersetzen musst.

Was problem-statement unterscheidet

Die Funktion stellt den Problem-Frame in den Mittelpunkt: I am, Trying to, But, Because und Which makes me feel plus Kontext und Einschränkungen. Diese Struktur ist für Entscheidungen hilfreicher als ein allgemeiner Prompt, weil sie dich zwingt, sowohl die funktionale Blockade als auch die menschliche Wirkung festzuhalten.

So verwendest du die problem-statement-Funktion

Die Funktion installieren und prüfen

Installiere sie mit:

npx skills add deanpeters/Product-Manager-Skills --skill problem-statement

Lies danach zuerst skills/problem-statement/SKILL.md, anschließend template.md und examples/sample.md. Das ist der schnellste Weg, um die erwartete Form, das Endergebnis und ein gutes fertiges Problem Statement zu verstehen.

Was du im Prompt liefern solltest

Für eine gute Nutzung von problem-statement gib der Funktion eine grobe, aber konkrete Ausgangslage: den Nutzertyp, die Aufgabe, die er erledigen will, den Blocker und eventuelle Einschränkungen. Wenn du nur eine Feature-Anfrage gibst, driftet das Ergebnis in Lösungssprache ab, statt ein echtes Problem zu beschreiben.

Ein stärkerer Input sieht so aus:

• Persona: „neue Support-Agents auf dem Smartphone“
• Goal: „Tickets lösen, ohne zwischen Tools zu wechseln“
• Blocker: „sie verlieren den Kontext zwischen CRM und Chat“
• Constraints: „hohes Volumen, wenig Einarbeitungszeit, Remote-First-Team“

Empfohlener Workflow

Starte mit einem kurzen Entwurf und schärfe ihn dann zu einer Fünf-Teile-Erzählung. Nutze das Template als Checkliste: Wenn Because nach einer Lösung klingt, geh einen Schritt zurück und frage, was den Schmerz tatsächlich verursacht. Wenn Which makes me feel zu generisch wirkt, ersetze es durch eine echte Nutzeremotion, die an den Workflow gekoppelt ist.

Dateien, die du zuerst lesen solltest

Priorisiere SKILL.md, template.md und examples/sample.md. Die Beispiel-Datei ist besonders hilfreich, weil sie sowohl ein gutes Framing-Muster als auch ein Anti-Muster zeigt. So vermeidest du, versehentlich eine getarnte Lösung statt eines Problem Statements zu schreiben.

FAQ zur problem-statement-Funktion

Ist problem-statement nur eine Prompt-Vorlage?

Nein. Die problem-statement-Funktion ist eine wiederverwendbare Framing-Methode, nicht nur ein Lückentext-Prompt. Ihr Wert liegt darin, vor dem Schreiben eines PRD oder dem Vorschlagen eines Fixes Klarheit über den Nutzer, die Blockade und die Ursache zu erzwingen.

Wann sollte ich sie nicht verwenden?

Nutze problem-statement nicht, wenn du bereits ein sauber abgegrenztes Requirements-Dokument hast oder wenn du ein Implementierungsdetail dokumentierst. Sie passt auch schlecht, wenn das Ziel Brainstorming von Lösungen ist; diese Funktion dient dazu, zuerst das Problem zu definieren.

Ist problem-statement anfängerfreundlich?

Ja, wenn du einen Nutzer und einen Schmerzpunkt in einfacher Sprache beschreiben kannst. Das Template ist einfach, aber die Qualität hängt davon ab, ob du das Problem des Nutzers von deiner bevorzugten Lösung trennen kannst.

Wie passt das in Technical-Writing-Arbeit?

Für Technical Writing ist die Funktion nützlich, wenn du Nutzerprobleme schärfen, einen Doku-Request unterstützen oder eine Content-Lücke vor dem Schreiben rahmen musst. Sie hilft dir, das Dokument ergebnisorientiert zu halten, statt in eine reine Funktionsbeschreibung abzurutschen.

So verbesserst du die problem-statement-Funktion

Gib der Funktion Belege, keine Schlagworte

Die besten problem-statement-Ergebnisse entstehen aus konkreten Beobachtungen: Was hat der Nutzer versucht, wo blieb er hängen, was hat er stattdessen verwendet und was ist dabei schiefgelaufen. „Nutzer sind verwirrt“ ist schwach; „erstmalige Admins können das Setup nicht abschließen, weil die UI das Pflichtfeld für den API-Key versteckt“ ist deutlich besser.

Trenne Problem und Lösung sauber

Ein häufiger Fehler ist, bereits eine Lösung einzuschmuggeln. Wenn dein Entwurf sagt „Nutzer brauchen ein Dashboard“, formuliere ihn um zu „Nutzer können die Systemgesundheit über mehrere Services hinweg nicht vergleichen, weil die Statussignale verstreut sind.“ So bleibt problem-statement auf die eigentliche Hürde fokussiert.

Füge Einschränkungen hinzu, die die Antwort verändern

Nenne alles, was die Form des Problems beeinflusst: Gerät, Teamgröße, Zeitdruck, Compliance, Erfahrungsniveau oder Plattformgrenzen. Solche Details machen das Problem Statement glaubwürdiger und helfen dem Endergebnis, bessere Priorisierung zu unterstützen.

Vom Entwurf zur entscheidungsreifen Fassung iterieren

Prüfe nach der ersten Ausgabe, ob das Statement spezifisch genug ist, um ein Stakeholder-Review zu bestehen. Wenn nicht, schärfe die Persona, mache das Because kausaler und stelle sicher, dass der letzte Satz auch ohne zusätzliche Erklärung verständlich ist.