Standard-Arbeitsleitfaden für PMs
Für jede PM in unserem Produktteam — egal ob mit oder ohne Technikhintergrund. Dieser Leitfaden hat ein Ziel: dich von "trau mich nicht, weiß nicht wie" zu "kann nicht mehr ohne" zu bringen.
Vorab: Keine Angst — einfach loslegen
Wenn du bei Claude Code das Gefühl hast „klingt toll, aber wo fange ich an?" — völlig normal. Erst drei Missverständnisse ausräumen.
Missverständnis 1: Ich kann keinen Code — also kann ich es nicht nutzen
Falsch — und sogar das Gegenteil ist wahr: keine Technikkenntnisse ist ein Vorteil. Du bist nicht gebunden durch „wie schwer ist das umzusetzen" — du formulierst einfach klar, was du willst. Und klar formulieren ist genau das Kernhandwerk von PMs. Die Zukunft gehört dem Prinzip „Sag es, die KI baut es": Ein Satz — und die KI macht es.
Missverständnis 2: Ich könnte es kaputt machen oder Schaden anrichten
Falsch. Im eigenen Projektordner kann man nach Herzenslust experimentieren. Das Schlimmste, was passieren kann: es ist nicht gut geworden — dann sagt man „falsch, nochmal".
Missverständnis 3: Es ist ein Tool — ich muss lernen, es zu „bedienen"
Umdenken: Es ist kein Tool — es ist dein Mitarbeiter. Ein unermüdlicher, jederzeit verfügbarer Allrounder-Praktikant, der alles ein bisschen kann. Du gibst Aufgaben einfach klar weiter — wie du es mit einem Menschen tun würdest.
Erster Schritt: In 5 Minuten das Gespräch lernen
Keine Befehle lernen nötig. In den Projektordner gehen, einfach in normaler Sprache sprechen. Drei Kernsätze reichen.
Mit dem Einfachsten anfangen
Erstelle eine Webseite mit dem Titel "Hallo", hellblauem Hintergrund, und starte einen lokalen Server, damit ich sie im Browser sehen kann.
Im Browser erscheint die Seite = Glückwunsch, du kannst es schon nutzen.
Die drei Kernsätze
- „Hilf mir, … zu machen" — Aufgabe erteilen
- „Das stimmt nicht, es sollte … sein" — Feedback geben
- „Stell mir erst ein paar Fragen, bevor du anfängst" — lass es dir beim Durchdenken helfen
Kernkonzept: Vier Voraussetzungen
| Voraussetzung | Bedeutung |
|---|---|
| Kein Code nötig — aber klare Beschreibung | Es ist die Übersetzungsmaschine von Idee zu Produkt — je klarer man es sagt, desto präziser das Ergebnis. |
| Für alle nutzbar — unterschiedliche Tiefe | Keine Einstiegshürde, nur unterschiedlicher Übungsstand. |
| Prototyp = wirklich lauffähig | Klickbar, interaktiv, für User testbar — kein statisches Bild. |
| Das ganze Team zieht mit | Neue Standardarbeitsweise des Teams, kein Einzelexperiment. |
Fünf-Phasen-Workflow (detailliert)
PM-Arbeit in fünf Phasen unterteilt. Jede Phase: Ziel, wie man es formuliert, Abschlusskriterium, typische Stolperstellen.
Entdecken
Ziel: Herausfinden, was Nutzer wollen, was Wettbewerber tun, wohin der Markt geht.
/competitor-watch Analysiere [Wettbewerber-URL], Fokus auf [Preise/KI-Features], als Vergleichsbericht aufbereiten
Kann in drei Sätzen erklären, was den Nutzern am meisten wehtut; weiß, wie Wettbewerber es lösen und wo unser Unterschied liegt.
Zu vage gefragt. Lösung: konkretes Ziel + konkreter Fokus + konkretes Ausgabeformat angeben.
Definieren
Ziel: Aus einer vagen Idee klare Anforderungen machen, die jeder versteht (PRD).
/office-hours Ich möchte [Idee] machen, gib noch keine Lösung, stell mir zuerst 5 Schlüsselfragen → /prd-generator Schreibe ein vollständiges PRD
Klare Erfolgskennzahlen vorhanden; Edge Cases aufgelistet; auch Außenstehende verstehen es.
Direkt schreiben lassen — dann erfindet es Details. Lösung: immer zuerst Fragen stellen lassen, dann schreiben.
Gestalten
Ziel: Vor dem Bauen sehen, „wie es ungefähr aussieht", und eine Richtung wählen.
/design-shotgun Erstelle 3 Stil-Varianten für die Login-Seite: A Minimal B Business C Verspielt — als nebeneinander vergleichbare Seite
Eine Richtung gewählt; Schlüsselseiten im Kopf klar.
Von Anfang an Perfektion anstreben und zögern. Lösung: erst 3 grobe Varianten anfordern, dann aus dem Sichtbaren wählen.
Prototyp entwickeln
Ziel: Das Design in einen wirklich klickbaren, interaktiven, nutzertestbaren Prototyp verwandeln. Kernprinzip: kleine Schritte, schnelles Tempo.
/design-html Als Prototyp umsetzen → dann jeweils ein Feature hinzufügen: „Diagramm in Markenblau" „CSV-Export-Button hinzufügen"… im Dialog iterieren
Läuft wirklich im Browser; Hauptflow komplett durchklickbar ohne Fehler; Dummy-Daten reichen für Demo.
20 Anforderungen auf einmal. Lösung: immer nur eine! Keine Qualitätsdiskussion über Prototyp-Code.
Validieren
Ziel: Echte Nutzer testen lassen, datenbasiert — nicht bauchgefühlbasiert — entscheiden.
/qa Teste diesen Prototyp, klick alles Klickbare durch, finde Fehler, Hänger und Abweichungen vom Soll, liste sie auf
Hauptflow fehlerfrei; echte Nutzer haben es getestet; Frage „lohnt es sich weiterzumachen?" mit Belegen beantwortbar.
Selbst zweimal klicken und urteilen. Lösung: unbedingt andere testen lassen — schweigen und schauen, wo sie hängen bleiben.
Kompetenz-Wachstumspfad
Kein sofortiger Sprung nötig — in diesem Tempo wachsen.
Grenzen: Sicherheitsnetz — keine Fessel
Gerade weil diese 5 Leitplanken da sind, kann man oberhalb davon frei ausprobieren und mutig vorgehen.
- Keine echten sensiblen Daten eingeben — für Prototypen Dummy-Daten oder anonymisierte Daten verwenden.
- Keine Schlüssel in den Code schreiben — Testzugangsdaten vom Team anfordern.
- Nicht-umkehrbare Aktionen selbst bestätigen — Veröffentlichen, Löschen, Zahlen: du drückst den letzten Knopf.
- Keine Produktivsysteme anfassen — Prototypen laufen nur lokal oder in Testumgebungen.
- Bei Unsicherheit fragen — Compliance, Bezahldienste, Datenschutz, technische Weichenstellungen: erst Team Lead fragen.
Drei-Wochen-Wachstumspfad
| Woche | Ziel | Konkrete Aktionen |
|---|---|---|
| Woche 1 | Hemmungen abbauen | Umgebung einrichten, erste Webseite zum Laufen bringen, täglich 3 Gespräche üben. |
| Woche 2 | Praxiseinsatz | Mit einer echten kleinen Anforderung einmal den kompletten „PRD schreiben → Prototyp bauen" durchführen. |
| Woche 3 | Selbstständiger Zyklus | Den kompletten Ablauf durchführen: „Idee → Prototyp → Kolleginnen testen lassen → verbessern". |
Anhang
A · Die vier Prompt-Regeln
| Regel | ❌ So sagen | ✅ So sagen |
|---|---|---|
| Konkret sein | Mach eine schöne Seite | Login-Seite, zentrierte Karte, E-Mail + Passwort, blauer Button #3B82F6 |
| Kontext geben | Füge eine Exportfunktion hinzu | Oben rechts im Dashboard einen Export-Button hinzufügen, aktuell gefilterte Ergebnisse als CSV herunterladen |
| Schrittweise | 15 Anforderungen auf einmal | Eine nach der anderen — Ergebnis sehen, dann weiter |
| Referenz geben | Farbe anpassen | Primärfarbe #3B82F6, Farbgebung an Stripe orientieren |
B · Schnellübersicht häufig genutzter Skills
Im Gespräch einfach / eingeben — alle Skills erscheinen. Am häufigsten genutzte für PMs: /office-hours Idee schärfen · /prd-generator PRD schreiben · /competitor-watch Wettbewerb · /design-shotgun Mehrere Varianten · /design-html Prototyp · /qa Testen · /make-pdf PDF exportieren.
C · Einsteiger-FAQ
F: Es hat etwas falsch gemacht — ich kann keinen Code, wie soll ich es ändern?
Einfach sagen „Das stimmt nicht, ich möchte …". Es korrigiert sich selbst.
F: Kann der Prototyp direkt als echtes Produkt für Nutzer eingesetzt werden?
Kleinere Tests sind möglich, aber nicht als offizielles Release. Für den Live-Betrieb müssen Entwickler eine produktionstaugliche Version bauen.
F: Wie lange dauert ein Prototyp ungefähr?
Einfaches: ein paar Stunden. Komplexes: 1 Tag. Wenn nach 1 Tag noch kein Ergebnis da ist, ist die Anforderung zu groß — aufteilen.
F: Ich habe Angst, Zeit mit Ausprobieren zu verschwenden.
Ausprobieren und Irren ist der Kernwert dieser Arbeitsweise. Je schneller man scheitert, desto früher findet man die richtige Richtung.
