KI statt Arbeitskrise: Warum uns die Technik den Rücken freihält
Dezember 4, 2025
Product Vision Board in Minuten erstellen – Anleitung mit KI
Februar 5, 2026
Viele Unternehmen haben gute Ideen, aber keinen klaren Weg zur Umsetzung. Häufig fehlen Zeit, Kapazität oder ein Team, das aus einer Idee schnell etwas Vorzeigbares macht.
Ich zeige dir in nur 3 Schritten meinen Ablauf an einem konkreten Beispiel: CrashRadar. Das ist ein Dashboard, das für verschiedene Märkte ein Risiko als Ampel zeigt. Das Thema ist austauschbar. Entscheidend ist der Workflow.
Am Ende hast du einen klickbaren Prototypen, den du direkt im Team oder mit Stakeholdern abstimmen kannst.
Das Ergebnis kurz
In wenigen Minuten war der erste Prototyp fertig, inklusive Struktur, Screens und Logik. Danach konnte ich bei Bedarf noch echte Daten anbinden.
Schritt 1: Aus der Idee werden saubere Anforderungen (mit Product Done)
Der häufigste Engpass ist nicht die Entwicklung. Der Engpass ist, dass Ideen unscharf bleiben und niemand sie sauber in Anforderungen übersetzt.
Dafür nutze ich meinen Custom GPT Product Done. Er macht aus einer Produktidee automatisch strukturierte User Stories inklusive Akzeptanzkriterien. Das ist besonders hilfreich für Produktverantwortliche, Fachbereiche und Startups, die schnell Klarheit brauchen.
Product Done findest du hier:
Link zum Custom GPT von Andreas Rössler
Prompt 1 für Product Done
Baue mir eine App, die mir das Crash-Risiko über Aktien, Krypto, Immobilien, Anleihen, USD, Gold und Ölmärkte tagesaktuell über ein Risiko als Ampel darstellt. Charts, Korrelation und Alerts bei Regimewechsel.
So gehst du vor
-
Beschreibe deine Idee in wenigen Sätzen: Zielgruppe, Problem, gewünschtes Ergebnis.
-
Lass dir User Stories und Akzeptanzkriterien generieren.
-
Nutze dieses Paket als Briefing für den Prototypen in Schritt 2.
Schritt 2: Aus Anforderungen wird ein klickbarer Prototyp (mit Lovable)
Jetzt kommt der Schritt, der im Alltag richtig wirkt. Du verwandelst Anforderungen in ein sichtbares Produkt, das sich wie eine echte App anfühlt.
Prompt 2 für Lovable Prototyp
🗂️ Epic: Multi-Asset Crash-Radar (Ampel-Risiko tagesaktuell) Ziel: Eine App, die für Aktien, Krypto, Immobilien, Anleihen, USD, Gold und Öl täglich ein Crash-/Stress-Risiko als Ampel zeigt – inkl. Charts, Korrelationen und Alerts bei Regimewechsel. 🧩 Story 1: Asset-Übersicht als Ampel-Dashboard User Story: Als Investor:in möchte ich ein Dashboard mit Ampel-Risiko je Assetklasse sehen, damit ich sofort erkenne, wo Stress/Crash-Risiko steigt. Akzeptanzkriterien: Gegeben sei die App ist geöffnet und Daten sind verfügbar Wenn ich das Dashboard anschaue Dann sehe ich für jede Assetklasse eine Ampel (Grün/Gelb/Rot) und einen numerischen Risikoscore (0–100). Gegeben sei ein Risikoscore ist berechnet Wenn sich der Score über definierte Schwellen bewegt Dann wechselt die Ampelfarbe konsistent nach den Regeln (z. B. Grün < 35, Gelb 35–65, Rot > 65). Gegeben sei die Daten wurden aktualisiert Wenn ich das Dashboard aktualisiere Dann sehe ich den Zeitstempel “Stand: YYYY-MM-DD HH:MM” pro Assetklasse. Gegeben sei ein Asset hat Datenlücken Wenn die Berechnung nicht möglich ist Dann wird der Status als “Unklar” angezeigt inkl. Hinweis (z. B. „Daten fehlen“). Abhängigkeiten: Daten-Pipeline & Risikomodell (Story 2, 3) Tags: dashboard, ux, risk-score, multi-asset Priorität: (noch nicht gesetzt) 🧩 Story 2: Datenanbindung & tägliche Aktualisierung (ETL) User Story: Als Nutzer:in möchte ich, dass die App tagesaktuell Daten für alle Märkte lädt, damit die Ampel auf aktuellen Informationen basiert. Akzeptanzkriterien: Gegeben sei definierte Datenquellen für alle Assetklassen Wenn der tägliche Job läuft Dann werden Preise/Returns je Assetklasse für den letzten Handelstag importiert und gespeichert. Gegeben sei ein Import schlägt fehl Wenn ein Retry möglich ist Dann wird automatisch bis zu N Mal erneut versucht und danach ein Fehler geloggt. Gegeben sei eine Quelle liefert Ausreißerwerte Wenn Validierungsregeln verletzt sind (z. B. Sprung > Xσ) Dann wird der Datensatz markiert und nicht ungeprüft in die Risikoberechnung übernommen. Gegeben sei ein Markt hat Feiertage/Wochenenden Wenn kein neuer Handelstag existiert Dann wird der letzte valide Stand beibehalten und als solcher gekennzeichnet. Abhängigkeiten: Datenprovider/Feeds, Storage, Scheduler Tags: etl, data-quality, scheduler, observability Priorität: (noch nicht gesetzt) 🧩 Story 3: Risikomodell berechnet Crash-/Stress-Score je Assetklasse User Story: Als Investor:in möchte ich einen transparenten Crash-/Stress-Score pro Assetklasse, damit ich Risiken vergleichen kann. Akzeptanzkriterien: Gegeben sei historische Renditen/Volatilität sind vorhanden Wenn der tägliche Score berechnet wird Dann entsteht ein Score (0–100) je Assetklasse. Gegeben sei das Modell nutzt mehrere Signale (z. B. Volatilität, Drawdown, Trendbruch, Credit-Spreads, Risk-Off-Indikatoren) Wenn Signale kombiniert werden Dann wird eine gewichtete Aggregation mit dokumentierten Gewichten verwendet (konfigurierbar). Gegeben sei der Score wird angezeigt Wenn ich “Details” öffne Dann sehe ich die Top beitragenden Faktoren (z. B. „Volatilität ↑“, „Korrelationen ↑“). Gegeben sei Modellparameter werden geändert Wenn ich eine Backfill-/Recompute-Funktion auslöse Dann werden Scores für einen definierten Zeitraum neu berechnet und versioniert. Abhängigkeiten: ETL (Story 2), Modell-Storage/Versionierung Tags: risk-model, explainability, configuration Priorität: (noch nicht gesetzt) 🧩 Story 4: Regimeerkennung (Normal vs. Stress/Crash) & Regimewechsel-Events User Story: Als Nutzer:in möchte ich Regimewechsel erkennen (z. B. Normal → Stress), damit ich frühzeitig auf Marktphasen reagieren kann. Akzeptanzkriterien: Gegeben sei tägliche Scores und Signale sind vorhanden Wenn ein Regimeklassifikator läuft Dann wird pro Assetklasse ein Regime-Status gespeichert (z. B. Normal/Stress/Crash). Gegeben sei ein Regime ändert sich Wenn Normal → Stress oder Stress → Crash eintritt Dann wird ein Regimewechsel-Event erzeugt mit Zeitpunkt und Auslöser-Signalen. Gegeben sei kurzzeitiges Rauschen um Schwellen Wenn Wechsel innerhalb eines “Cool-down”-Fensters passiert Dann wird Hysterese/Glättung angewandt, um Flapping zu reduzieren. Abhängigkeiten: Risikomodell (Story 3), Event-Log Tags: regime, signal-processing, events Priorität: (noch nicht gesetzt) 🧩 Story 5: Charts je Assetklasse (Score, Preis, Volatilität) User Story: Als Investor:in möchte ich Charts sehen (Score-Verlauf, Preis, Volatilität), damit ich Kontext und Trend verstehe. Akzeptanzkriterien: Gegeben sei ein Asset ist ausgewählt Wenn ich die Detailseite öffne Dann sehe ich mindestens: Preis-Chart, Score-Chart, Volatilitäts-Chart. Gegeben sei Regimewechsel existieren Wenn ich den Score-Chart ansehe Dann sind Regimewechsel als Marker/Vertikallinien sichtbar. Gegeben sei ein Zeitraumfilter (z. B. 1M/3M/1Y/5Y) Wenn ich den Filter ändere Dann aktualisieren sich Charts und Kennzahlen entsprechend. Abhängigkeiten: Time-Series-Storage, Frontend Charting Tags: charts, timeseries, ux Priorität: (noch nicht gesetzt) 🧩 Story 6: Korrelationen & Cross-Asset Heatmap User Story: Als Nutzer:in möchte ich Korrelationen zwischen Assetklassen sehen, damit ich Diversifikation und “Risk-Off”-Cluster erkenne. Akzeptanzkriterien: Gegeben sei historische Returns pro Assetklasse Wenn Korrelationen berechnet werden Dann werden rollierende Korrelationen (z. B. 30/90/180 Tage) gespeichert. Gegeben sei ich öffne die Korrelationsansicht Wenn Daten verfügbar sind Dann sehe ich eine Heatmap (Asset × Asset) inklusive Legende. Gegeben sei eine Korrelation steigt stark an (z. B. > 0,7) Wenn ich den Zeitraum wechsle Dann wird die Heatmap neu berechnet/geladen und Extremwerte werden visuell hervorgehoben. Abhängigkeiten: ETL (Story 2), Analytics Jobs Tags: correlation, heatmap, analytics Priorität: (noch nicht gesetzt) 🧩 Story 7: Alerts bei Regimewechsel & Risikoschwellen User Story: Als Investor:in möchte ich Benachrichtigungen bei Regimewechseln oder hohen Scores, damit ich schnell reagieren kann. Akzeptanzkriterien: Gegeben sei ich habe Alerts aktiviert Wenn ein Regimewechsel-Event entsteht Dann erhalte ich einen Alert (Push/E-Mail/In-App) mit Assetklasse, altem/neuem Regime und Zeitpunkt. Gegeben sei ich definiere eine Score-Schwelle (z. B. > 70) Wenn der Score diese Schwelle überschreitet Dann erhalte ich eine Benachrichtigung, maximal einmal pro Cool-down-Zeitraum. Gegeben sei Benachrichtigung wird ausgelöst Wenn ich darauf tippe Dann öffnet sich direkt die Detailseite des betroffenen Assets. Abhängigkeiten: Regime-Events (Story 4), Notification Service Tags: alerts, notifications, thresholds Priorität: (noch nicht gesetzt) 🧩 Story 8: Personalisierung – Watchlist & Gewichtung User Story: Als Nutzer:in möchte ich die Ansicht personalisieren (Watchlist, Gewichtungen), damit die Ampel zu meinem Portfolio passt. Akzeptanzkriterien: Gegeben sei ich nutze mehrere Assetklassen Wenn ich eine Watchlist anlege Dann kann ich Assetklassen ein-/ausblenden und die Reihenfolge ändern. Gegeben sei ich möchte Portfolio-Nähe Wenn ich Gewichtungen setze (z. B. Aktien 50%, Anleihen 30%, Gold 20%) Dann zeigt die App zusätzlich einen Portfolio-Risikoindikator als aggregierten Score. Gegeben sei ungültige Gewichte Wenn Summe ≠ 100% Dann weist die App darauf hin und bietet Auto-Normalisierung an. Abhängigkeiten: User Profile/Settings Storage Tags: personalization, portfolio, settings Priorität: (noch nicht gesetzt) 🧩 Story 9: Vertrauen & Nachvollziehbarkeit – “Warum ist es rot?” User Story: Als Nutzer:in möchte ich nachvollziehen, warum eine Assetklasse auf Gelb/Rot steht, damit ich der Ampel vertrauen kann. Akzeptanzkriterien: Gegeben sei eine Assetklasse ist Gelb/Rot Wenn ich “Warum?” öffne Dann sehe ich die Top 3–5 Treiber (z. B. Volatilität↑, Drawdown↑, Korrelation↑, Trendbruch). Gegeben sei Datenquellen sind hinterlegt Wenn ich in Details gehe Dann sehe ich Quelle, Update-Zeitpunkt und Modellversion. Gegeben sei ein Treiber ist “Korrelation↑” Wenn ich darauf klicke Dann springe ich zur Korrelationsansicht mit relevantem Zeitraum.
So gehst du vor
-
Öffne Lovable und erstelle ein neues Projekt.
-
Kopiere die User Stories aus Schritt 1 hinein.
-
Starte die Generierung und schaue dir das Ergebnis direkt an.
-
Bei Bedarf kannst du Anpassungen ganz simpel via Prompt beauftragen
Der Vorteil ist simpel: Du diskutierst nicht mehr über Vorstellungen, du hast ein konkretes Artefakt auf dem Tisch. Damit werden Abstimmungen schneller und Entscheidungen klarer.
Schritt 3: Optional echte Daten anbinden (Backend und Datenbank)
Für viele Teams reicht Schritt 1 und Schritt 2 völlig aus, um eine Idee zu validieren oder intern ein Go oder No Go zu bekommen.
Wenn du den Prototypen aber realistischer machen willst, kannst du im dritten Schritt echte Daten anbinden, damit aus Demo schnell ein funktionsnahes Modell wird.
Prompt 3 für Lovable Prototyp
Implementiere echte Datenanbindung über Lovable Cloud: Erstelle Edge Functions für den täglichen ETL-Job, der Marktdaten von APIs wie Alpha Vantage, CoinGecko oder Yahoo Finance lädt.
So gehst du vor
-
Füge den oberen Prompt in Lovable ein und sende ihn ab.
- Bestätige, dass Lovable die Backendfunktionen integrieren darf. Klicke hierzu auf "Allow".
-
Lege eine Datenbankstruktur an, damit Werte gespeichert und wieder geladen werden können.
-
Nutze eine Funktion, die Daten regelmäßig aktualisiert, zum Beispiel täglich.
Warum dieser Ablauf so gut funktioniert
Du gewinnst Tempo, weil du zuerst Klarheit schaffst und dann sofort sichtbar machst, was du meinst. Dadurch sparst du Abstimmungsschleifen, weil alle dasselbe sehen und bewerten können.
Verpasse nichts mehr!
Du willst auf dem Laufenden bleiben, wie sich KI in der Produktentwicklung weiterentwickelt?
Dann sichere dir hier regelmäßig Impulse – kostenlos:
