Das moderne Toolset für Produktmanager und Design Thinker
Produktentwicklung verändert sich von Dokument-Übergaben zu einer Artefakt-Kette. Welche Tools in welcher Phase helfen — von Research über UX und Prototyp bis Codex, Supabase und Automatisierung.
TL;DR: Das moderne Toolset für Produktmanager und Design Thinker ist keine lose Liste von AI-Tools. Es ist eine Artefakt-Kette: Jede Phase erzeugt ein Ergebnis, das die nächste Phase direkt weiterverwenden kann — vom Research-Kontext über UX-Flows und klickbare Prototypen bis zu Datenmodell, Code-Agent und Automatisierung.
Die meisten Teams reden über moderne Produkt-Tools wie über eine Einkaufsliste:
ChatGPT für Research. Stitch für Screens. v0 für Prototypen. Codex für Code. Supabase für Daten. n8n für Automatisierung.
Das ist nicht falsch. Aber es ist zu flach.
Die bessere Frage lautet nicht: Welches Tool ist am besten?
Die bessere Frage lautet: Welches Artefakt muss in dieser Phase entstehen — und kann die nächste Phase damit arbeiten?
Genau hier verändert sich Produktentwicklung.
Früher erzeugte der Produktprozess vor allem Übergabe-Dokumente: Research-Notizen, Personas, PRDs, Wireframes, Figma-Dateien, Tickets, Akzeptanzkriterien. Diese Artefakte halfen einer anderen Rolle zu verstehen, was als Nächstes passieren soll.
Heute können viele Artefakte direkt von Tools weiterverarbeitet werden. Ein Research-Notebook wird zum Produkt-Frame. Der Frame wird zum UX-Flow. Der Flow wird zu Screens. Die Screens werden zum klickbaren Frontend. Das Frontend landet im Repo. Das Repo wird von einem Code-Agenten bearbeitet. Das Produkt ruft Modelle, Tools und Automatisierungen auf.
Das macht Produkturteil nicht weniger wichtig. Es macht schlechte Inputs teurer, weil sie weiter reisen.
Früher vs. heute: die neue Artefakt-Kette
| Stufe | Früher | Heute | Tool-Fit | Output |
|---|---|---|---|---|
| 1. Verstehen | Interview-Notizen, Workshop-Fotos, Desk Research | Quellenbasierter Kontext mit Annahmen und Lücken | ChatGPT, NotebookLM, Gemini | Kontext-Pack |
| 2. Framen | Persona, PRD, Value-Proposition-Slide | Produkt-Frame mit Problem, Nutzer, Scope und Evidenz | ChatGPT, strukturierte Prompts | MVP-Scope |
| 3. Flow formen | Journey Map, Wireframe, Design-Briefing | UX-Flow mit konkreten Zuständen | Stitch, Figma, Referenzbibliotheken | Screen-Set |
| 4. Sichtbar machen | Klickdummy oder statisches Mockup | Laufendes Frontend mit Mock-Daten | v0, Next.js, shadcn/ui | Repo-Prototyp |
| 5. Real machen | Tickets, Sprintplanung, Engineering-Übergabe | Repo-Änderung mit Datenmodell, Constraints und Review | Codex, Git, Supabase | Reviewbarer Feature-Diff |
| 6. Intelligenz einbauen | „Wir brauchen auch AI“ als Feature-Wunsch | Eine begrenzte AI- oder Automatisierungsfähigkeit im Produkt-Loop | AI SDK, OpenRouter, n8n | AI-/Automation-Boundary |
| 7. Entscheiden | Roadmap-Meeting | Evidenzreview: bauen, stoppen oder weiter testen | User Tests, Logs, Analytics, Security Review | Nächste Investitionsentscheidung |
Das Muster ist wichtiger als die Logos. Jede Stufe hat einen Job. Jedes Tool sollte gewählt werden, weil es das nächste Artefakt in der Kette erzeugt.
1. Research wird zu Kontext, nicht zu „Insights“
Produktarbeit beginnt selten sauber. Meistens liegt ein Haufen Rohmaterial vor: Kunden-Calls, Sales-Notizen, Support-Tickets, Marktbeobachtungen, Screenshots, Strategiefragmente, Bauchgefühl.
Früher hat ein Product Manager oder Researcher daraus ein Dokument synthetisiert. Heute kann der erste Layer stärker quellenbasiert arbeiten.
ChatGPT ist stark, wenn du Material mitbringst und es strukturieren, challengen und in Hypothesen übersetzen willst. NotebookLM hilft, wenn Antworten eng an hochgeladene Quellen und Originalstellen gebunden sein sollen. Gemini-Research-Flows können eine breitere Markt- und Wettbewerbsrecherche unterstützen.
Der Output sollte aber nicht „spannende Insights“ heißen. Das ist zu weich.
Der Output ist ein Kontext-Pack:
- Problem
- Zielgruppe
- aktueller Workaround
- Wertversprechen
- Annahmen
- offene Fragen
- Beispiele und Zitate
- Evidenzstärke
Wenn diese Stufe vage bleibt, verstärken alle späteren Tools nur die Vagheit.
2. Aus Kontext wird ein Produkt-Frame
Die nächste Stufe ist kein vollständiges PRD. Sie ist ein Frame.
Ein guter Frame sagt:
- Für wen bauen wir?
- Welcher Workflow verändert sich?
- Was heißt „besser“ konkret?
- Welche Constraints sind nicht verhandelbar?
- Was ist bewusst außerhalb des Scopes?
- Was muss die erste Version beweisen?
Viele Teams verlieren hier den Plot. Sie fragen AI nach Features, bevor sie den Test definiert haben.
Besser ist: Das Modell in Produktlogik zwingen.
Aus diesem Kontext: Welche Produktwetten sind stark? Was würde jede Wette widerlegen? Welcher Scope liefert das schnellste glaubwürdige Signal?
Der wichtige Begriff ist glaubwürdiges Signal. Ein Prototyp, der intern beeindruckt, aber kein echtes Nutzerverhalten testet, ist Theater. Ein kleinerer Prototyp, der eine Workflow-Entscheidung sichtbar macht, ist wertvoller.
3. UX wird sichtbar, bevor Design perfekt ist
Design Thinking war immer stark in Alignment. Schwerer war, jede plausible Idee schnell genug sichtbar zu machen, um sie wirklich zu prüfen.
Diese Kosten fallen.
Tools wie Stitch können aus natürlicher Sprache UI-Richtungen und Screen-Explorationen erzeugen. Das ist nützlich, wenn der Produkt-Frame steht und das Team sehen muss, wie ein Flow konkret aussehen könnte.
Der Fehler ist, das Tool „das Produkt designen“ zu lassen.
Das bessere Artefakt ist ein kleiner UX-Flow:
- Einstieg
- Hauptpfad
- Erfolgszustand
- leerer Zustand oder Fehlerzustand
- ein Edge Case
Nicht: „Mach es schön.“ Sondern: Mach die Entscheidung sichtbar.
4. Aus Screens wird ein laufender Prototyp
Statische Screens sind hilfreich. Laufende Prototypen sind hilfreicher, weil sie fehlende Zustände zeigen.
v0 passt gut, wenn das Ziel ein funktionierendes Frontend ist: React, Next.js, Komponenten, Mock-Daten, Interaktion. Das ist ein anderer Job als visuelle Exploration.
Die Grenze muss klar bleiben: Das ist noch nicht Produktion.
v0 sollte in dieser Phase ein Frontend erzeugen, kein Backend erfinden. Keine stillen Architekturentscheidungen. Keine automatisch hinzugedichtete Auth. Keine Datenbanklogik, nur weil der Prompt vollständig klingt.
Der wichtige Schritt ist der Übergang ins Repo. Sobald der Prototyp in GitHub liegt, wandert die Wahrheit aus einer Prompt-Session in eine Codebasis. Das ist der Übergang von Produkt-Exploration zu engineering-förmiger Arbeit.
5. Aus Prototyp wird reviewbare Implementierung
Ab hier wird AI-gestützte Produktarbeit ernst — oder teuer.
Wenn ein Prototyp im Repo liegt, werden Code-Agenten wie Codex nützlicher. Sie können eine Codebasis lesen, Dateien ändern, Tests laufen lassen, Fehler beheben und Änderungen als reviewbaren Diff vorbereiten.
Der entscheidende Zusatz lautet: mit Review.
Ein moderner Product Manager muss nicht so tun, als wäre er Senior Engineer. Aber er muss genug Systemverständnis haben, um Constraints zu führen:
- Welches Datenmodell braucht das Feature?
- Was gehört serverseitig?
- Welche Nutzerdaten sind sensibel?
- Welche Routes existieren schon?
- Wie wird getestet?
- Was wäre unsicher zu shippen?
Hier kommen Supabase, Datenverträge, lokale Entwicklung, Projektregeln und Git ins Spiel. Der Agent wird nicht gebeten, „eine App zu machen“. Er wird gebeten, ein begrenztes System zu verändern.
Das ist der Unterschied zwischen Vibe Coding als Demo und AI-gestütztem Bauen als Produktdisziplin.
6. AI kommt erst rein, wenn der Produkt-Loop klar ist
„Wir brauchen AI“ ist keine Produktanforderung.
Es ist meistens ein Zeichen, dass noch nicht entschieden wurde, welcher Teil des Workflows intelligenter werden soll.
Vier Muster sind praktisch:
- mit dem Produkt chatten
- ein Artefakt generieren
- einen Fall analysieren
- einen Schritt automatisieren
Wenn AI im Produkt selbst passiert, ist ein Application-Layer wie AI SDK sinnvoll: Modellaufrufe, Streaming, strukturierte Outputs, Tool Calling. Wenn ein Geschäftsprozess über mehrere Systeme laufen soll, passt ein Workflow-Layer wie n8n besser: Trigger, Aktionen, APIs, Freigaben.
Die eigentliche Entscheidung ist architektonisch:
- Wo darf das Modell entscheiden?
- Wo muss Software erzwingen?
- Wo braucht es menschliche Freigabe?
In regulierten Teams ersetzt diese Tool-Kette keine Governance. Sie zieht Governance nach vorne: Datensensibilität, Rollen, Review, Deployment und Ownership müssen geklärt sein, bevor der Prototyp zu überzeugend wirkt.
Was sich für PMs und Design Thinker wirklich ändert
Die Rolle verschiebt sich nicht von Produkt zu Engineering. Sie verschiebt sich von Übergabe-Verantwortung zu Loop-Verantwortung.
Früher war ein guter PM im Vorteil, wenn er ein klares PRD schreiben konnte.
Heute ist ein guter PM im Vorteil, wenn er aus Ambiguität eine testbare Artefakt-Kette bauen kann.
Nicht, weil Engineering verschwindet. Sondern weil die Kosten sinken, herauszufinden, was Engineering wirklich besitzen sollte.
Vor jedem Tool in der Kette helfen fünf Fragen:
- Welches Artefakt muss am Ende dieser Stufe existieren?
- Wer oder was nutzt dieses Artefakt als Nächstes?
- Was muss deterministisch bleiben?
- Welche Evidenz würde unsere Entscheidung ändern?
- Was ist die Stop-Regel?
Wenn diese Fragen offen sind, hilft kein weiteres Tool.
Es erzeugt nur beeindruckendere Unklarheit.
Weiterführend
Dr. Ronny Schüritz
Co-Founder von Build With Vibe. Technical Lead und AI-Enthusiast.
Bereit, Vibe Coding selbst auszuprobieren?
Lerne in unseren Vor-Ort-Workshops in Berlin, wie du durch KI zum Product Engineer wirst. Keine Vorkenntnisse nötig.
Workshop buchen