Propose & Curate: Wie Guided AI Development die Rolle des Product Owners verändert
Wenn Engineers schneller bauen als Product Owner spezifizieren können,
braucht es ein neues Modell.
Die kurze Version
Wenn ein Engineer seine AI durch die Entwicklung führt, entstehen Features in Minuten bis Stunden statt Wochen. Bei dieser Geschwindigkeit ist Upfront-Spezifikation teurer als Bauen und Verwerfen. An die Stelle von "Kunde bestellt, Berater liefert" tritt Propose & Curate: Der Engineer schlägt fertige Features vor. Der Product Owner entscheidet, was shipped wird.
Das verändert die Rolle des Product Owners (PO) fundamental. Weniger schreiben, mehr entscheiden.
Was ist Guided AI Development?
Ein erfahrener Engineer führt eine AI durch die Entwicklung. Er gibt Richtung, Kontext und Domänenwissen. Die AI liefert Geschwindigkeit, Codequalität und systematische Validierung.
Der Engineer versteht das Kundenproblem, trifft Architekturentscheidungen und steuert die Richtung. Die AI liest die Codebase, implementiert, testet und validiert. Kein Teil funktioniert ohne den anderen: Die AI ohne Führung produziert technisch korrekte, aber fachlich irrelevante Ergebnisse. Der Engineer ohne AI arbeitet in klassischer Geschwindigkeit.
Die AI implementiert ein Feature in 30 Minuten bis 4 Stunden. Der Engineer denkt in der gleichen Zeit die nächsten drei Features vor.
Das Ergebnis ist keine Automatisierung. Es ist eine Verstärkung.
Die stille Annahme im Consulting
Der Kunde zahlt für Entwicklungszeit. Jede Stunde in die falsche Richtung kostet Geld und Vertrauen. Beide Seiten investieren in Spezifikation: Der Kunde will sicher sein, dass er bekommt was er bestellt. Der Berater will sicher sein, dass er liefert was vereinbart wurde.
Die stille Annahme dahinter: Implementierung ist teuer. Fehlentwicklung ist geschäftsschädigend. Deshalb investiert man in Spezifikation, Abstimmung und Abnahme.
Diese Annahme war jahrzehntelang korrekt. Guided AI Development verändert die Kostenstruktur so radikal, dass die darauf aufbauenden Prozesse nicht mehr passen.
Die Ökonomie dahinter
| Modell | Feature-Dauer | Kosten bei Verwerfung |
|---|---|---|
| Klassisch (1 Entwickler) | 1-2 Wochen | 7.500-15.000 EUR |
| Klassisch (Team) | 1-2 Sprints | 30.000-60.000 EUR |
| Guided AI Development | 30 Min bis 4 Std | 100-500 EUR |
Ein typischer Spezifikationsworkshop: 2-3 Stunden, PO plus Berater plus Fachexperten. Dazu die Nachbereitung: Spec schreiben, Review, Freigabe. Gesamtkosten für eine solide Spezifikation: 2.000-4.000 EUR.
Im gleichen Zeitraum kann Guided AI Development das Feature bauen, testen und als fertiges Ergebnis präsentieren. Der Kunde sieht nicht eine Beschreibung dessen, was er bekommen soll. Er sieht das Ergebnis.
Wenn Fehlentwicklung billiger wird als Spezifikation, kehrt sich die Logik um. Es ist günstiger, ein Feature zu bauen und zu verwerfen, als es vorab vollständig zu spezifizieren.
Warum klassische Abnahme nicht funktioniert
Der Flaschenhals
6 Features pro Tag, ein Kunde, der jedes einzeln abnehmen muss. Features stapeln sich. Das Team wartet. Der Geschwindigkeitsvorteil verpufft.
Konkreter: 6 Features warten auf der Staging-Umgebung. Der Kunde prüft Feature 3. Features 4 bis 6 bauen darauf auf. Ein Änderungswunsch bei Feature 3 invalidiert alles danach.
Abnahme ohne Auftrag
Formale Abnahmeprozesse sichern ab: Der Kunde bestätigt, dass er bekommt was er bestellt hat. Aber wenn der Kunde nichts bestellt hat, sondern etwas vorgeschlagen bekommen hat, ist die formale Abnahme ein Fremdkörper. Der Kunde hat keinen Auftrag erteilt, den er abnehmen könnte. Er bewertet einen Vorschlag.
Qualität und Produktwert trennen
Zwei verschiedene Fragen, die im klassischen Modell vermischt werden:
| Frage | Wer antwortet | Wann |
|---|---|---|
| Funktioniert es? | Engineer + AI (Tests, CI, Review) | Vor der Präsentation |
| Ist es sicher? | Engineer + AI (Security Audit) | Vor der Präsentation |
| Passt es zum Produkt? | Kunde | Bei der Präsentation |
| Wollen wir das? | Kunde | Bei der Präsentation |
Der Engineer und die AI sichern Qualität. Der Kunde bewertet Produktwert. Das sind zwei verschiedene Tätigkeiten. Im klassischen Modell sitzt der Kunde im Acceptance Testing und klickt Buttons. Im Propose & Curate Modell trifft er Produktentscheidungen.
Propose & Curate
Der Ablauf ist kurz: Engineer und AI identifizieren eine Verbesserung, oder der Kunde hat eine Idee. Das Feature entsteht auf einem Branch in 30 Minuten bis 4 Stunden. Der Engineer präsentiert: Was wurde gebaut, warum, Vorher/Nachher. Der Kunde entscheidet: Accept, Reject oder Modify. Accept bedeutet Merge und Ship. Reject bedeutet Branch löschen. Modify bedeutet Anpassung und erneute Präsentation.
Drei Rollen
Engineer (Navigator): Versteht die Kundendomäne, erkennt Probleme und Chancen, steuert die AI, präsentiert Ergebnisse. Kein Promptschreiber. Ein erfahrener Architekt, der seine Expertise durch die AI verstärkt.
AI (Driver): Liest die Codebase, implementiert, testet, validiert. Arbeitet nicht autonom. Jede Entscheidung über Architektur, Scope und Richtung trifft der Mensch.
Kunde (Kurator): Bewertet fertige Features. Entscheidet, was ins Produkt gehört. Gibt Richtung vor, ohne jedes Detail vorspezifizieren zu müssen.
Nicht nur der Kunde hat Ideen
Im klassischen Consulting hat der Kunde das Monopol auf Anforderungen. Der Berater führt aus. Guided AI Development öffnet drei Feature-Quellen:
Kunden-initiiert. Der Kunde beschreibt eine Idee in ein bis drei Sätzen. Kein vollständiger Spec nötig. Die Kosten einer Fehlinterpretation sind gering. Der Engineer steuert die AI, das Feature entsteht. Passt es nicht, wird nachjustiert.
Audit-generiert. Der Engineer lässt die AI automatisierte Audits ausführen. Product Audits analysieren Code gegen Engineering-Standards. UX Audits bewerten Usability-Heuristiken pro Nutzerrolle. Security Audits identifizieren Angriffsvektoren. Der Engineer filtert die Ergebnisse, steuert die AI bei der Umsetzung. Der Kunde sieht fertige Verbesserungen, keine Audit-Reports.
Engineer-initiiert. Beim Arbeiten an einem Feature erkennt der Engineer ein angrenzendes Problem. Er dokumentiert es als Vorschlag. Der Kunde entscheidet.
Egal woher ein Feature kommt, der Kunde entscheidet ob es shipped wird. Die Quelle ändert sich, die Entscheidungshoheit nicht.
Im klassischen Consulting wäre das undenkbar: Ein Berater, der unbeauftragt Features baut. "Wer zahlt das?" Aber wenn die Baukosten gegen null gehen, dreht sich die Frage um: "Warum sollte ich ein Problem beschreiben, wenn mein Berater es schon gelöst hat?"
Die neue PO-Rolle
Vom Auftraggeber zum Kurator
| Vorher | Nachher |
|---|---|
| Schreibt User Stories | Bewertet fertige Features |
| Plant Sprints | Entscheidet: Ship oder nicht? |
| Definiert Akzeptanzkriterien | Prüft: Passt das zum Produkt? |
| Kontrolliert Umsetzung | Gibt Richtung vor |
Die zentrale Fähigkeit ist nicht mehr "gute Requirements schreiben". Sie ist "schnell und sicher entscheiden, was ins Produkt gehört."
Mehr Kontrolle, nicht weniger
Der naheliegende Einwand: "Der Kunde verliert die Kontrolle."
Das Gegenteil. Im klassischen Modell kontrolliert der Kunde den Input (Spezifikation) und hofft, dass der Output stimmt. Im Propose & Curate Modell kontrolliert er den Output direkt. Er sieht das fertige Feature. Keine Interpretation, keine Lücke zwischen Anforderung und Umsetzung. Keine Überraschung bei der Sprint Review.
Präsentation: 80/20
Wie zeigt der Engineer ein Feature?
Für 80% reichen Screenshots und Screencasts. Vorher/Nachher, verschiedene Ansichten, Mobile und Desktop. Der Kunde entscheidet in Minuten.
Für die restlichen 20% (neue Workflows, veränderte Navigation) ist ein kurzer Call mit Bildschirmfreigabe effektiver als automatisierte Preview-Infrastruktur.
Verträge neu denken
Das klassische Modell basiert auf: Kunde spezifiziert, Berater liefert, Abnahme bestätigt Erfüllung. Time & Material oder Festpreis, die Spezifikation ist immer die Grundlage.
Propose & Curate bricht das auf. Wenn 60% der Features nicht vom Kunden spezifiziert wurden, gibt es keine Spezifikation, gegen die abgenommen werden kann. Aber die Beauftragung bleibt beim Kunden. Er entscheidet, was shipped wird. Verworfene Features sind seine Richtungsentscheidung, nicht das Risiko des Beraters.
Was sich ändert: Der Berater bringt eine neue Fähigkeit mit. Ein Engineer, der mit AI entwickelt, liefert den Output eines kleinen Teams. Das erfordert kontinuierliche Weiterbildung, AI-Tooling und Infrastruktur auf Beraterseite. Der Preis ist höher pro Person, der Output pro Euro ist massiv höher.
Paketpreis. Der Kunde definiert ein Ziel: "Webapp mit 4 Rollen, Auth, Cloud-Deployment." Festpreis für das Paket. Was innerhalb des Pakets entsteht, ist der Mehrwert. Klassisch bekommt der Kunde 5 Features in einer Woche. Mit Guided AI Development bekommt er 30. Der Paketpreis bleibt gleich, das Ergebnis vervielfacht sich.
Kuratierungs-Pauschale. Fester Betrag pro Zeitraum. Engineers liefern kontinuierlich Features, der Kunde kuratiert was shipped wird. Höherer Monatspreis als klassische Einzelentwickler, weil AI-Tooling, Infrastruktur und spezialisierte Engineers Investitionen erfordern. Dafür: messbarer Output auf Team-Niveau statt Einzelleistung.
Hybrid. Paketpreis für den Kern (definiertes Produktziel). Kuratierungs-Pauschale für laufende Verbesserungen danach. Der Übergang ist fließend: Nach dem Kern-Paket kennt der Engineer die Domäne, die AI kennt die Codebase. Die Pauschale wird produktiver, nicht teurer.
Voraussetzungen
Dieses Modell funktioniert nicht überall.
- Niedrige Baukosten. Wenn ein verworfenes Feature Wochen kostet, lohnt sich Upfront-Spezifikation. Wenn es Stunden kostet, nicht.
- Erfahrene Engineers. Guided AI Development funktioniert nicht mit Juniors, die Prompts schreiben. Es braucht Leute, die Architektur, Domäne und Kundenbedürfnisse verstehen.
- Klare Präsentation. Der Kunde entscheidet in Minuten. Das erfordert visuelle Proposals, nicht technische Dokumentation.
- Vertrauen. Der Kunde traut dem Berater zu, sinnvolle Vorschläge zu machen. Der Berater traut dem Kunden zu, schnell zu entscheiden.
- Ein PO, der kuratieren kann. Nicht jeder PO ist dafür geeignet. Manche brauchen den Prozess der Spezifikation, um ihre eigenen Anforderungen zu verstehen. Das Schreiben einer User Story ist für sie ein Denkwerkzeug. Im Propose & Curate Modell verschiebt sich die Denkarbeit: Der PO muss erkennen, ob das Gebaute das ist, was er will. Das erfordert Urteilsvermögen, Produktgefühl und Entscheidungsfreude.
- Engineers, die loslassen können. Verworfene Features sind kein Misserfolg. Sie sind der günstige Preis für schnelles Lernen.
Zahlen aus der Praxis
Full-Stack-Webapp, circa 100 API-Endpoints, 4 Nutzerrollen, Cloud-Infrastruktur. Eine Woche, ein Engineer mit AI.
| Metrik | Klassisch | Propose & Curate |
|---|---|---|
| Features in einer Woche | 3-5 | 30+ |
| Idee bis Ship | 2-4 Wochen | 30 Min bis 4 Stunden |
| Kundenzeit pro Feature | 4-8 Stunden | 10-30 Minuten |
| Verworfene Features | Selten (zu teuer) | Regelmäßig (günstig) |
| Feature-Quellen | 90% Kunde | 40% Kunde, 40% Audit, 20% Engineer |
60% der Features wurden nicht vom Kunden initiiert.
Der Kunde hat sie kuratiert, nicht bestellt.
Für den Kunden: Er bekommt mehr als er bestellt hat.
Für den Berater: Sichtbarer Mehrwert über den Auftrag hinaus.
Skalierung: Enterprise-Plattform
Dasselbe Modell funktioniert auch mit größeren Teams und höherer Komplexität. Eine Enterprise-SaaS-Plattform (Desktop-OS mit Fenstermanager, AI-Agent-Studio, Marketplace, Sandbox für Code-Execution, 100.000+ Zeilen Code) entstand mit 7 Engineers im gleichen Ansatz in 4 Wochen. Jeder Engineer arbeitet mit seiner AI im gleichen Tempo. Die Koordination skaliert, die Geschwindigkeit pro Engineer bleibt.
| Aspekt | Kundenprojekt | Enterprise-Plattform |
|---|---|---|
| Team | 1 Engineer + AI | 7 Engineers + AI |
| Zeitraum | 1 Woche | 4 Wochen |
| Features | 30+ | 150+ |
| Codebase | ~20.000 LOC | ~100.000+ LOC |
| Scope | Domänen-Webapp, 4 Rollen | 10 Epics, Desktop-OS, Sandbox, Marketplace |
Gleicher Tech Stack, gleiche Organisation, gleiches Modell. Jeder Engineer arbeitet im Propose & Curate Modus mit seiner AI. Der PO kuratiert den Strom aus 7 parallelen Feature-Quellen statt einer.
Fazit
Guided AI Development verändert nicht die Geschwindigkeit allein. Es verändert die Beziehung zwischen Berater und Kunde.
Der PO wird nicht überflüssig. Seine Entscheidungen werden wertvoller, weil mehr Optionen auf dem Tisch liegen. Statt fünf Features pro Sprint zu priorisieren, kuratiert er aus dreißig Vorschlägen die besten zwanzig.
Der Engineer verändert sich ebenfalls. Sein Wert liegt nicht mehr in der Umsetzungskompetenz allein. Er liegt in der Fähigkeit, zusammen mit seiner AI die richtigen Dinge vorzuschlagen.
Die AI baut. Der Engineer navigiert. Der Kunde entscheidet, was sein Produkt wird.
Das ist kein Kontrollverlust. Es ist eine Verschiebung der Kontrolle dorthin, wo sie am meisten Wirkung hat: An die Frage "Wollen wir das?" statt an die Frage "Wie soll das aussehen?"
