Claude Code für Product Manager: das Setup, das aus einem Chatfenster einen Mitarbeiter macht

Warum dein Claude-Setup scheitert, bevor du den ersten Prompt schreibst

Kurz: Ein Agent scheitert selten am Modell. Er scheitert daran, dass niemand ihm gesagt hat, woran ihr arbeitet, wie bei euch gearbeitet wird und wann eine Änderung gut genug ist. Das sind drei Sätze, die du einem neuen Teammitglied in der ersten Stunde sagen würdest – und die in den meisten Repos nirgends stehen.

Ich sehe dieses Muster bei fast jedem Product-Team, mit dem ich spreche. Die Coding-Agents sind eingeführt, die Lizenzen bezahlt, und trotzdem fühlt sich die Arbeit an wie vorher: Du promptest, du korrigierst, du promptest nochmal. Product Leader sagen es im Gespräch meist so – «mein Wissen liegt über zwanzig Tabs verteilt». Solange das stimmt, kann kein Agent etwas anderes tun als raten.

Greg Isenberg hat dafür in seinem Durchgang durch die neuen Claude-Code-Funktionen ein brauchbares Bild gefunden: Wer will, dass sich ein Agent wie ein Mitarbeiter verhält, muss ihm dasselbe geben wie einem Menschen am ersten Tag – einen Arbeitsplatz, Gedächtnis, ein Briefing, einen klaren Auftrag, Augen, ein Review, einen Kalender und Rechte. Das ist keine Metapher fürs Marketing. Es ist eine Einrichtungsliste, und jeder Punkt darauf ist eine Datei oder eine Einstellung.⁴

Meine These für diesen Beitrag: Der Unterschied zwischen einem Chatfenster und einem Mitarbeiter ist kein besserer Prompt, sondern ein eingerichteter Arbeitsplatz. Alles Weitere hier ist der Beweis – in der Reihenfolge, in der ich es aufsetzen würde.

Wie du den Arbeitsplatz einrichtest: ein Repo, drei Dateien, zwei Ordner

Kurz: Der Arbeitsplatz ist ein Repository. Nicht eine Chat-Historie, nicht ein Notion-Space. Ein Ort, an dem Dateien liegen, die versioniert sind, in dem der Agent lesen und schreiben kann und in dem jede Änderung nachvollziehbar bleibt.

Als Product Manager musst du dafür nicht in fremden Code eingreifen. Es reicht ein eigener Kontext-Ordner im Produkt-Repo – oder ein eigenes kleines Repo daneben, wenn dir das lieber ist. Wichtig ist nur, dass es dort liegt, wo der Agent ohnehin arbeitet.

Drei Dateien tragen das Ganze. CLAUDE.md beschreibt, wie bei euch gearbeitet wird. ROADMAP.md beschreibt, was gerade zählt. REVIEW.md beschreibt, wann eine Änderung gut genug ist. Dazu zwei Ordner: einer für Kundensprache im Original – Support-Notizen, Gesprächsprotokolle, Einwände, Zitate – und einer für wiederkehrende Aufträge, die du später als Routine planst.

Der Kundensprache-Ordner ist der, den fast alle auslassen, und er ist der wertvollste. Wenn dort echte Sätze von echten Nutzern liegen, baut der Agent nicht mehr aus deiner Meinung, sondern aus dem, was der Markt tatsächlich sagt. Das ist derselbe Mechanismus, den wir bei Teklens meinen, wenn wir von der Context Engine sprechen: nicht mehr Intelligenz, sondern mehr belastbarer Kontext.

Du kannst das Gerüst von Claude selbst anlegen lassen – mit einem Auftrag, der den Geschäftskontext gleich mitliefert: Produkt in einem Satz, Käufer, Schmerz, Versprechen, aktuelles Ziel. Ein Zusatz lohnt sich immer: «Frag mich vorher nach fehlendem Kontext, der die Struktur wesentlich verändern würde, und halte die erste Version einfach.» Diese eine Zeile spart dir die erste Aufräumrunde.⁴

Was in CLAUDE.md gehört – und was besser in eine Regel oder ein Skill

Kurz: In CLAUDE.md gehört, was in jeder Session gelten soll: Arbeitsweise, Konventionen, Projektaufbau, Befehle. Anthropic empfiehlt dafür unter 200 Zeilen pro Datei – längere Dateien verbrauchen mehr Kontext und senken die Befolgung.¹

Der wichtigste Satz der Dokumentation steht etwas versteckt: Claude behandelt diese Dateien als Kontext, nicht als erzwungene Konfiguration. Die Datei wird gelesen, und Claude versucht ihr zu folgen – garantiert ist nichts. Wer eine Aktion unabhängig von der Entscheidung des Modells blockieren will, braucht einen Hook oder eine Deny-Regel. Das ist der Unterschied zwischen «wir haben es aufgeschrieben» und «es kann nicht passieren».¹

Praktisch heisst das: Halte die Arbeitsweise kurz und konkret. Kleine, prüfbare Änderungen. Plan vor der Umsetzung, wenn Produktverhalten betroffen ist. Bestehenden Codestil verwenden. Nach jeder Änderung die relevanten Checks laufen lassen. Am Schluss zusammenfassen, was geändert wurde, was getestet wurde und was ein Mensch prüfen muss. Fünf Punkte, nicht fünfzig.

Was nicht hineingehört: mehrstufige Prozeduren und alles, was nur einen Teil der Codebase betrifft. Prozedurales gehört in ein Skill, das nur bei Bedarf geladen wird – wie du eines schneidest, steht im Beitrag über Skill Files als nächste KI-Kompetenz nach dem Prompting. Pfad-spezifisches gehört in eine Regeldatei unter .claude/rules/ mit einem paths-Feld, damit sie nur greift, wenn Claude passende Dateien anfasst.¹

Und ein Detail, das im Alltag zählt: Widersprüche sind teurer als Lücken. Wenn zwei Regeln sich widersprechen, wählt Claude laut Dokumentation womöglich willkürlich eine davon. Eine kurze, widerspruchsfreie Datei schlägt eine vollständige, die sich selbst im Weg steht.¹

Warum Plan Mode aus einem Wunschzettel einen Auftrag macht

Kurz: Plan Mode ist der Moment, in dem der Agent liest, statt zu schreiben. Er sieht sich das Projekt an, liest deine Kontextdateien und legt dir den Ansatz vor, bevor er eine Datei anfasst. Du bekommst etwas, worauf du reagieren kannst – und das ist der ganze Punkt.

Laut Dokumentation liest Claude in diesem Modus Dateien und führt nur lesende Shell-Kommandos aus, ändert aber keine Quelldateien. Das ist keine Höflichkeitsgeste, sondern eine Rollentrennung: Erst denken, dann bauen. Für alles, was Produktverhalten verändert, würde ich es zur Gewohnheit machen.³

Der Auftrag im Plan Mode sollte immer dieselben fünf Dinge verlangen: welche Dateien sich ändern, die kleinste saubere Umsetzung, die Nutzererfahrung, die Risiken, und was bewusst weggelassen wird. Der letzte Punkt ist der wichtigste. Was ein Agent bewusst weglässt, verrät dir, ob er den Auftrag verstanden hat.

Ein Zusatz gehört zwingend dazu: «Lies zuerst die Kontextdateien.» Ohne diese Zeile plant der Agent aus dem, was er im Code sieht, statt aus dem, was ihr entschieden habt. Der Plan sieht dann kompetent aus und zielt am Vorhaben vorbei – die teuerste Art von Fehler, weil sie erst im Review auffällt.

Wie du ein Ticket schneidest, das in einem Diff prüfbar bleibt

Kurz: Ein gutes Ticket nennt die Aufgabe, den Umfang, die erwartete Nutzererfahrung und die Grenze. «Mach die App besser» ist keins. «Ergänze das Anmeldeformular um Name, E-Mail und Firma, zeig nach dem Absenden eine einfache Erfolgsmeldung und bleib beim bestehenden Designsystem» ist eins.

Der Massstab für die Grösse ist nicht der Aufwand des Agenten, sondern deine Prüfzeit. Ein Ticket ist richtig geschnitten, wenn du die Änderung im Diff lesen kannst, ohne dir dafür einen Termin zu blockieren. Das ist eine ungewohnte Umstellung: Bisher hat die Ticket-Grösse die Kapazität des Teams abgebildet. Jetzt bildet sie deine Review-Kapazität ab, und die ist der neue Engpass.

Genau hier greift die kanonische Regel, die wir bei Teklens seit Jahren wiederholen: Wer schlechten Input automatisiert, liefert den Schlamassel nur schneller aus. Ein vager Auftrag erzeugt jetzt nicht mehr eine vage Rückfrage, sondern zweihundert Zeilen plausibel aussehenden Code. Der Aufwand verschiebt sich vom Schreiben ins Zurücknehmen.

Was ein Ticket zusätzlich braucht, wenn ein Agent es ausführt, steht ausführlich in der Anatomie eines Jira-Tickets für KI-Product-Management: Kontext, der sonst im Kopf des Entwicklers steckt, muss ins Ticket. Für den Abschluss lohnt sich ein fester Zusatz – nach der Umsetzung die relevanten Checks laufen lassen, zusammenfassen, was geändert wurde, was getestet wurde und was ein Mensch prüfen muss.

Warum ein Agent Augen braucht – und Review in zwei Schichten läuft

Kurz: «Augen» heisst nicht nur Bildschirm. Es heisst: Der Agent prüft, was er gebaut hat – öffnet die Anwendung, klickt den Ablauf durch, liest die Konsole, lässt die Tests laufen und beurteilt das Ergebnis aus der Sicht des Käufers.

Für Produktarbeit ist das der Unterschied zwischen «lädt» und «funktioniert». Eine Seite kann fehlerfrei rendern und trotzdem verwirren. Ein Formular kann absenden und sich falsch anfühlen. Ein Button kann sichtbar sein und übersehen werden. Wer den Agenten nur Dateien ändern lässt, bekommt technisch korrekte Arbeit ohne Produkturteil.

Das Review danach läuft in zwei Schichten. Die erste ist deine: Du öffnest den Diff und stellst drei Fragen – passt das zum Ticket, passt das zum Plan, ist etwas Überraschendes dabei. Überraschungen sind fast immer die Stelle, an der das Risiko sitzt. Wenn ein Auftrag ein Formular betraf und die Änderung plötzlich Routing und Datenbank anfasst, willst du das sofort wissen.

Die zweite Schicht ist die Prüfung gegen deinen Massstab – dafür liegt REVIEW.md im Repo. Der brauchbarste Auftrag dazu verlangt eine Dreiteilung: muss behoben werden, sollte behoben werden, kann so ausgeliefert werden. Diese drei Bänder sind der Grund, warum das Review nicht zur zweiten Vollzeitstelle wird – sie sagen dir, wo du hinschauen musst, statt dir alles gleich wichtig zu machen.

Was in REVIEW.md steht, ist eure Sache, aber ein paar Zeilen gehören in jedes Projekt: Passt die Änderung zum aktuellen Fokus? Ist sie klein genug, um sie zu prüfen? Funktioniert der Hauptablauf noch? Gibt es Layout-Probleme auf dem Handy? Sind Formularfehler sauber behandelt? Besteht ein Risiko für Anmeldung, Zahlung oder Produktivdaten? Wurde unnötige Komplexität hinzugefügt?

Was du an Routinen abgibst – und wo die Rechte-Grenze liegt

Kurz: Eine Routine ist eine gespeicherte Konfiguration – Auftrag, Repositories, verbundene Werkzeuge – die automatisch läuft. Sie startet nach Zeitplan, über einen HTTP-Aufruf oder als Reaktion auf GitHub-Ereignisse und läuft in der Cloud, auch wenn dein Rechner zu ist.²

Die erste Routine sollte nichts verändern. Ich würde mit einem Morgenbericht anfangen: Lies die Kundennotizen und die offenen Issues, schreib den grössten wiederkehrenden Schmerzpunkt auf, ein Produktrisiko, eine empfohlene Aufgabe für heute und eine Frage, die ich Kunden stellen sollte. Kein Code, kein Pull Request, unter 500 Wörter. Das ist nicht spektakulär – aber es ist die Art Arbeit, die sonst niemand macht und die den Tag sortiert.

Ein Detail aus der Dokumentation, das man nicht überlesen sollte: Routinen laufen autonom, ohne Berechtigungsabfragen. Es gibt während des Laufs keinen Modus-Wähler und keine Rückfrage – Claude kann jedes Werkzeug jedes eingebundenen Konnektors nutzen, Schreibzugriffe eingeschlossen. Deshalb entfernst du beim Anlegen alles, was die Routine nicht braucht. Der zweite Grund für lesende Routinen zuerst.²

Für interaktive Sessions gilt das Gegenteil, und dort liegt deine eigentliche Steuerung. Berechtigungsregeln werden in der Reihenfolge Deny, Ask, Allow ausgewertet, und der erste Treffer entscheidet – Spezifität ändert daran nichts. Ein breites Verbot lässt sich also nicht mit einer engeren Erlaubnis aufweichen. Wenn du «keine Migrationen» sagst, bleibt es dabei, auch wenn ein anderer Eintrag eine bestimmte Migration erlaubt.³

Die Grenze selbst würde ich in drei Zonen ziehen und einmal schriftlich festhalten. Allein erlaubt: lesen, Codebase durchsuchen, Pläne vorschlagen, lokale Tests laufen lassen, auf einem Branch arbeiten, Dokumentation aktualisieren, einen Entwurf für einen Pull Request anlegen. Vorher fragen: Abhängigkeiten installieren, Migrationen, Anmeldung, Zahlungslogik, Dateien löschen. Beim Menschen: Produktiv-Deploys, Entscheidungen über Kundendaten, Abrechnung, sicherheitsrelevante Änderungen. Die dritte Zone bleibt beim Menschen, auch wenn die ersten beiden gut laufen.

Warum der zweite Agent teurer ist, als er aussieht

Kurz: Parallelisieren ist verlockend und funktioniert – aber nur, wenn jede Session einen eigenen, klar abgegrenzten Auftrag und eine definierte Übergabe hat. Ohne das entsteht kein Team, sondern ein Stapel Arbeit, den du am Abend entwirren darfst.

Der belastbarste Datenpunkt dazu kommt von Anthropic selbst: Ihr internes Multi-Agenten-System schlug einen Einzelagenten deutlich, verbrauchte dabei aber rund fünfzehnmal mehr Tokens. Mehr Agenten sind also eine Kosten-Wert-Entscheidung, kein Fortschritt an sich. Wann sich der Aufwand lohnt und wann eine einzelne, gut kontextualisierte Schleife gewinnt, steht im Beitrag über Graph Engineering und Multi-Agenten-Workflows.⁶

Am weitesten getrieben hat das öffentlich Allie K. Miller. Sie beschreibt eine digitale Belegschaft von rund 34 Agenten nach dem Hub-and-Spoke-Prinzip: ein Chief of Staff, mit dem sie als Einzige spricht, darunter sechs Direktberichte mit je eigenen Unteragenten. Ihre Kernaussage ist die interessante: Das Nabe-Speiche-Modell sei zwar zentral, aber der eigentliche Durchbruch liege in Orchestrierung und Dokumentation. Nicht in der Zahl der Agenten.⁵

Der zweite Teil ihres Aufbaus ist der, den ich für Produktteams am ehesten übernehmen würde: Sie hat die Projektsteuerung aufgeteilt. Ein Agent orchestriert und denkt, ein zweiter überwacht und pflegt das Gedächtnis – meldet, wenn vom Ziel abgewichen wird, erkennt wiederkehrende Probleme, führt Protokoll. Ein Wächter, der selbst keine Arbeit liefert, sondern dir sagt, was du nicht geprüft hättest.⁵

Und damit schliesst sich der Kreis zum Anfang. Beide Beispiele – Isenbergs Einrichtungsliste und Millers Belegschaft – sagen dasselbe mit unterschiedlichem Massstab: Der Ertrag kommt aus der Struktur, nicht aus der Rechenleistung. Die Agenten sind austauschbar. Das Repo, in dem Kontext, Massstab und Entscheide versioniert liegen, ist es nicht.

Genau das baut Teklens als Produkt: einen Kontext, der Jira, Confluence, Code und Mail verbindet und nicht bei jedem Sessionstart neu aufgebaut werden muss – ein Layer über deinen Tools, kein Ersatz. Wer das lieber selbst als Dateien im Repo pflegt, kommt weit; die Grenze liegt dort, wo der Kontext den Code selbst kennen muss.

Häufige Fragen

Empfehlungen

• Schreib die drei Dateien, bevor du den nächsten Prompt tippst. Arbeitsweise, aktueller Fokus, Qualitätsmassstab. Je eine Seite reicht. Alles, was du sonst in jeder zweiten Session neu erklärst, gehört dort hinein.
• Leg einen Ordner für Kundensprache im Original an. Support-Notizen, Einwände, Zitate – ungefiltert, nicht zusammengefasst. Ohne diesen Ordner baut der Agent aus deiner Meinung statt aus dem Markt.
• Halte CLAUDE.md unter 200 Zeilen. Prozedurales in ein Skill, Pfad-spezifisches in eine Regel mit paths-Feld. Und einmal im Quartal auf Widersprüche durchsehen – die kosten mehr als Lücken.
• Schneide Tickets nach deiner Prüfzeit, nicht nach Aufwand. Wenn du die Änderung nicht in einem Diff lesen kannst, ist das Ticket zu gross. Der Engpass ist nicht mehr die Umsetzung, sondern das Urteil darüber.
• Starte mit einer lesenden Routine. Ein Morgenbericht aus Kundennotizen und offenen Issues, kein Code, kein Pull Request. Nimm beim Anlegen jeden Konnektor raus, den die Routine nicht braucht.
• Halte die Rechte-Grenze einmal schriftlich fest. Drei Zonen: allein erlaubt, vorher fragen, beim Menschen. Was wirklich verbindlich sein muss, gehört in eine Deny-Regel oder einen Hook – nicht in eine Kontextdatei.
• Führ den zweiten Agenten erst ein, wenn der erste prüfbar liefert. Parallelität multipliziert, was schon funktioniert – und ebenso das, was nicht funktioniert. Erst Struktur, dann Skalierung.

Einordnung & Grenzen

• Die Angaben zu CLAUDE.md, Routinen und Berechtigungen stammen aus der offiziellen Claude-Code-Dokumentation, Stand August 2026. Routinen laufen laut Anthropic als Research Preview – Verhalten, Limits und Schnittstellen können sich ändern. Prüf vor dem Aufsetzen den aktuellen Stand.
• Die Setups von Greg Isenberg und Allie K. Miller sind Praxisberichte einzelner Anwender, keine Studien. Millers Zahl von rund 34 Agenten und die Rollenverteilung ihrer digitalen Belegschaft sind Selbstauskünfte aus ihrem eigenen Betrieb; sie zeigen, was möglich ist, nicht, was für ein Produktteam von zwanzig Leuten optimal wäre.
• Anthropics Vergleich von Multi-Agenten- und Einzel-Agenten-System stammt aus einem internen Recherche-Eval, nicht aus einer unabhängigen Untersuchung. Der Tokenfaktor gilt für diese Aufgabenklasse und lässt sich nicht ungeprüft auf Produktarbeit übertragen.
• Zu Teklens nennen wir hier keine Vorher-Nachher-Zahlen. Die Pilotbelege laufen; bis sie vorliegen, beschreiben wir die Fähigkeit und nicht die Wirkung.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Anthropic, «How Claude remembers your project» – Claude Code Docs (2026) ↗ – CLAUDE.md als Kontext statt erzwungener Konfiguration, Richtwert unter 200 Zeilen, Regeln mit paths-Feld.
2. 2.Anthropic, «Automate work with routines» – Claude Code Docs (2026) ↗ – Routinen als gespeicherte Konfiguration mit Zeitplan-, API- und GitHub-Auslösern; autonome Läufe ohne Berechtigungsabfrage.
3. 3.Anthropic, «Configure permissions» – Claude Code Docs (2026) ↗ – Berechtigungsmodi inklusive Plan Mode; Auswertungsreihenfolge Deny, Ask, Allow mit erstem Treffer als Entscheid.
4. 4.Greg Isenberg, «Claude Code New Features, Explained» – YouTube (2026) ↗ – Die Einrichtungsliste für einen KI-Mitarbeiter: Arbeitsplatz, Gedächtnis, Briefing, Ticket, Augen, Review, Zeitplan, Rechte.
5. 5.Allie K. Miller bei Greg Isenberg, «My top secrets to running an AI Agent Workforce» – YouTube (2026) ↗ – Rund 34 Agenten im Hub-and-Spoke-Modell mit Chief of Staff; Orchestrierung und Dokumentation als eigentlicher Hebel.
6. 6.Anthropic, «How we built our multi-agent research system» (2025) ↗ – Interner Eval: deutlicher Vorsprung des Multi-Agenten-Systems bei rund fünfzehnfachem Tokenverbrauch.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.