Claude im Produktmanagement nutzen: PRDs, Feedback und Priorisierung

Man braucht keinen langen Kurs, um Claude gut für PM-Arbeit zu nutzen. Drei kostenlose Lektionen decken genau die Gewohnheiten ab, die diese Seite beschreibt, in der Reihenfolge, in der sie aufeinander aufbauen.

Der Einstieg ist Context Is Everything aus dem Kurs Strategic Prompting, eine fünfminütige Lektion über die eine Gewohnheit, die einen brauchbaren PRD-Entwurf von generischer Füllsprache unterscheidet: Claude die echte Problembeschreibung, Recherche und Rahmenbedingungen zu geben statt eines Einzeilers.

Danach deckt Research and Thinking in Master the Essentials (sieben Minuten) ab, wie man mit Claude an strukturierter Analyse arbeitet, dieselbe Fähigkeit, die Feedback-Synthese und Wettbewerbsrecherche nützlich statt vage macht.

Zum Abschluss Power Prompts: Pre-Mortems, Steelmanning & Red-Teaming, ebenfalls in Master the Essentials (sieben Minuten). Das ist die Lektion hinter dem Priorisierungs-Hinterfragen: Claude zu bitten, gegen die eigene Tendenz zu argumentieren, bevor es ein Stakeholder tut. Zusammen sind diese drei Lektionen ein schnellerer Weg zu gutem PM-Output als Trial-and-Error in einem leeren Chatfenster.

Der Großteil der PM-Arbeit passiert in normaler Konversation mit Claude, das, was der Kurs Three Modes Chat und Co-Work nennt. Claude AI: Chat That Thinks (sieben Minuten) deckt den schnellsten Modus ab: eine einzelne Frage oder Entwurfsanfrage, nützlich für einen schnellen PRD-Abschnitt oder eine einmalige Feedback-Zusammenfassung.

Claude Co-work: Your Thinking Partner (sechs Minuten) deckt den Modus ab, in dem der Großteil der PM-Arbeit tatsächlich stattfindet: ein längeres Hin und Her, bei dem man an einem Dokument iteriert, einem Entwurf widerspricht und Claude den Kontext von allem, was schon besprochen wurde, behalten lässt.

Eine kleinere Gruppe von PMs greift auch zu Claude Code: Build With Words (sechs Minuten), dem dritten Modus, wenn sie eine Codebase selbst durchlesen müssen, um eine technische Rahmenbedingung direkt zu verstehen, statt sich auf die Paraphrase eines Engineers zu verlassen. Das ist eine wirklich eigenständige Fähigkeit gegenüber der Arbeit in normaler Sprache oben, und die meisten PMs brauchen sie nie, um Nutzen aus Claude zu ziehen.

Der mit Abstand größte Hebel ist, Claude echten Kontext zu geben statt eines vagen Prompts. "Entwirf ein PRD für ein Benachrichtigungsfeature" produziert generische Füllsprache. Die echte Nutzerforschung, die technischen Rahmenbedingungen, die das Team im Standup erwähnt hat, und ein Beispiel-PRD, das dem Team gefällt, einzufügen, produziert etwas, das man tatsächlich überarbeiten kann, statt es wegzuwerfen.

Dieselbe Regel gilt für Wettbewerbsrecherche und Priorisierung. Claude kann nicht sagen, was tatsächlich zu den aktuellen Preisen eines Wettbewerbers oder zur echten Nutzung des eigenen Produkts stimmt. Wer Claude bittet, eine Analyse zu strukturieren, sollte geben, was tatsächlich beobachtet wurde. Vage Eingaben produzieren selbstbewusst klingende, aber unzuverlässige Ergebnisse.

In derselben Konversation zu iterieren ist besser, als jedes Mal neu anzufangen. Trifft ein PRD-Entwurf nicht den Punkt, sollte man Claude konkret sagen, was falsch ist, und ihn überarbeiten lassen, statt den Prompt von Grund auf neu zu schreiben. Claude behält innerhalb einer Konversation den Kontext von allem, was schon besprochen wurde, und daher kommt ein großer Teil der Zeitersparnis.

Claude kennt die eigenen Nutzer, den eigenen Markt oder die Risikobereitschaft des Unternehmens nicht, es sei denn, man sagt es ihm. Ein Priorisierungs-Framework ist nur so gut wie die Eingaben, die man ihm gibt, und Claude produziert bereitwillig eine selbstbewusst klingende Empfehlung aus dünnem Kontext. Das Ergebnis sollte als strukturierte Meinung behandelt werden, auf die man reagiert, nicht als Urteil.

Claude kann auch nicht sagen, was tatsächlich zur Nutzung des eigenen Produkts oder zum aktuellen Stand der Wettbewerber stimmt. Claude ist stark im Organisieren und Nachdenken über gelieferte Informationen; es ist kein Live-Recherche-Tool, das sich selbstständig aktuelle Daten holt.

Vorsicht bei dem, was eingefügt wird. Rohes Nutzerfeedback, Interview-Transkripte und Support-Tickets enthalten oft identifizierende Details zu echten Kunden. Namen und Kontokennungen sollten, wo möglich, entfernt werden, bevor ein Stapel Feedback in eine Konversation eingefügt wird, genauso wie man diese Daten in jedem anderen Tool behandeln würde.

Die Synthese, die Claude erstellt, sollte gegen das Rohmaterial geprüft werden, bevor sie an Stakeholder, Kunden oder Engineering geht, genauso wie man die Zusammenfassung eines Junior-Analysten prüfen würde. Das zählt am meisten, wenn Feedback-Synthese in eine Entscheidung mit echten Kosten einfließt, etwa das Streichen eines Features oder die Neupriorisierung eines Quartals.