Zum Inhalt springen
ProductLeadership-as-a-Service

DubuchstkeinenInterimProductOwner.DubuchsteinLiefersystem.

Als Interim Product Owner bringe ich ein erprobtes Delivery-System mit: Wissenskorpus, 48-Stunden-Taktung und die eiserne Regel, dass nichts Ungeklärtes dein Sprint-Backlog erreicht. Produktiv ab Woche 1 — ohne Einarbeitungstheater.

30 Minuten. Kein Pitch. Du bekommst eine ehrliche Einschätzung, ob dein Setup passt.

Mandate u. a. bei
JungheinrichEnBWFRANK OriginalDICTUMFUNKE MediengruppeRapid DataDevelopXBIKELEASING.DE
Das Problem

Ein wartender Entwickler ist der teuerste Mitarbeiter deiner Firma.

Du zahlst dein Dev-Team pro Monat — nicht pro gelieferter Story. Ob es liefert, hängt an einer einzigen Sache: ob entwicklungsreife Anforderungen vor ihm liegen. Genau da reißt die Kette. Dann passiert eins von drei Dingen — und alle drei kosten dich Geld:

01

Dein Team wartet.

Sichtbar im Sprint-Burndown, unsichtbar auf der Rechnung. Der Sprint läuft, das Gehalt läuft — nur die Arbeit nicht.

02

Dein Team rät.

Es baut die wahrscheinlichste Interpretation der halbfertigen Anforderung. Und baut sie nächsten Monat wieder um.

03

Dein Refinement wird zur Werkstatt.

Sechs Entwickler klären 90 Minuten lang, was eine Person hätte vorbereiten müssen. Jeden zweiten Tag.

Ein klassischer Interim-PO bringt gegen dieses Problem vor allem eines mit: seinen Kalender. Ich bringe ein System mit, das genau dafür gebaut wurde — in einem Enterprise-Digitalisierungsprogramm, in dem Entwickler-Leerlauf sechsstellig kostet.

Was kostet dich ein halb ausgelasteter Sprint?

Konservativ gerechnet: 2-Wochen-Sprint, 10 Arbeitstage.
Verbrannt pro halbem Sprint
16.250 €
Pro Jahr — wenn nur jeder 4. Sprint so läuft
105.625 €
Gegen diese Zahl ist jedes Interim-Mandat ein Rundungsfehler. Ein einziger verhinderter Leerlauf-Sprint bezahlt Wochen meiner Arbeit.
Die Erkenntnis

Entwicklungsreife ist eine Lieferkette. Und bei dir fehlt ein Glied.

Von der vagen Idee bis zur Story, die ein Entwickler ohne Rückfrage umsetzen kann, passieren vier Dinge — ob du sie organisierst oder nicht:

Die meisten Unternehmen haben für diese Kette niemanden. Sie haben Entwickler (teuer, warten) und einen Fachbereich (überlastet, klärt nicht). Ich bin das fehlende Glied — mit einem System, das bleibt, wenn ich gehe.

Mein Operating Model

Du kippst Rohes rein. Ich liefere Sprint-fähiges raus. Dazwischen: mein System.

01
Schritt 01

Input — ungefiltert.

Meeting-Mitschnitte, Notizen, halbfertige Tickets, Fachkonzepte. Kein Aufbereiten nötig — genau das ist ja das Problem, das ich dir abnehme.

02
Schritt 02

Lücken erkennen — in 48 Stunden.

Mein Delivery-System gleicht jeden Input gegen den wachsenden Wissenskorpus deines Produkts ab: Was fehlt? Was widerspricht sich? Was ist nicht entschieden? Du bekommst Entwurf + Klärungsliste.

03
Schritt 03

Ich kläre selbst.

Ich warte nicht auf besseren Input — ich hole ihn mir. Gezielte Rückfragen, kurze Klärungscalls mit deinem Fachbereich, Entscheidungen werden herbeigeführt statt verschleppt.

Eiserne Regel: Nichts Ungeklärtes kommt ins Sprint-Backlog.
04
Schritt 04

Sprint-ready + vertreten.

Stories mit Akzeptanzkriterien und technischen Notizen, direkt in deinem Jira oder Azure DevOps. Und ich sitze im Refinement und vertrete jede einzelne davon.

Was mit mir einzieht

Kein Body-Leasing. Kein Berater. Ein Liefersystem mit Gesicht.

Wissenskorpus

Dein Produkt-Gedächtnis: Domänen-Glossar, Systemlandschaft, Build-Historie. Wächst mit jedem Sprint — und bleibt bei dir, wenn mein Mandat endet.

Entscheidungslog

Jede herbeigeführte Entscheidung dokumentiert, mit Datum und Kontext. Nie wieder „Wer hat das eigentlich entschieden — und warum?“

48-h-Taktung

Von Rohinput zu Entwurf + Klärungsliste in maximal 48 Stunden. Verlässlich, jede Woche.

Null-Ungeklärt-Regel

Nichts, was eine offene Frage enthält, erreicht dein Sprint-Backlog. Punkt.

Direkt in Jira & ADO

Ich liefere in dein System, in deinem Format. Dein Team merkt nur, dass die Tickets besser werden.

Mehr Durchsatz

Das System trägt die Produktion — dadurch halte ich den Anforderungsdurchsatz für mehrere Teams parallel.

Die naheliegende Frage

„Kann das nicht einfach ChatGPT?“

Den Text? Ja. Deshalb ist der Text auch nicht das, wofür du mich buchst. Kipp deine Notizen in ein AI-Tool und du bekommst in 30 Sekunden plausibel klingende Stories — die im ersten Refinement zerfallen. Denn ein Modell weiß nicht, was ihm niemand gesagt hat. Es merkt nicht, dass die Anforderung dem widerspricht, was ihr im März gebaut habt. Und es ruft ganz sicher nicht deinen Fachbereich an, um eine Entscheidung einzufordern.

Der Engpass war nie das Schreiben. Der Engpass ist das Klären, Entscheiden und Verantworten. Genau das übernehme ich — die Texte schreibt mein System.
Der Vergleich

Deine Optionen. Ehrlich verglichen.

Interner PO (Neueinstellung)Klassischer Interim-POSelbst + AI-ToolInterim PO mit System
Produktiv abMonat 3–6Woche 2–4sofort — Qualität: siehe obenWoche 1
Klärung & Entscheidungenja, wenn gutja, wenn gutneinja — mit System-Rückendeckung
Durchsatz1 Team1 Teammehrere Teams parallel
Produkt-Gedächtnis nach dem Mandatim Kopf, geht mit ihmim Kopf, geht mit ihmneinWissenskorpus — bleibt bei dir
Dokumentierte EntscheidungenseltenseltenneinEntscheidungslog, lückenlos
Verantwortung für Entwicklungsreifediffuspersonengebundenbei dirvertraglich, mit 48-h-Taktung

„Ja, wenn gut“ ist ernst gemeint: Ein starker interner PO ist die beste Lösung — wenn du ihn findest, bezahlst und hältst. Bis dahin gibt es mich. Und wenn du ihn gefunden hast, übergebe ich ihm ein gepflegtes System statt eines Chaos.

Aus der Praxis

Ich habe das System nicht für diese Seite gebaut. Sondern weil ich es selbst gebraucht habe.

Das Delivery-System hinter meiner Arbeit läuft im Digitalisierungsprogramm eines globalen Industriekonzerns im täglichen Einsatz: Demands, User Stories, Prozessdiagramme und Release Notes für mehrere Entwicklungsteams — dort, wo Entwickler-Leerlauf sechsstellig kostet und Anforderungsqualität kein Nice-to-have ist.

Es ist aus Notwehr entstanden: Ein einzelner Product Lead kann den Anforderungsdurchsatz für mehrere Teams sonst nicht halten. Erst als es lief, wurde daraus mein Operating Model.

Kein AI-Berater, der letztes Jahr umgeschult hat. Ein Praktiker, der sein eigenes Werkzeug gebaut hat — und es in jedes Mandat mitbringt.

AK

Alexander Karl

Interim Product Owner · Product Lead
Mandate u. a. bei
JungheinrichEnBWFRANK OriginalDICTUM
Bevor du fragst

Die Fragen, die ich am häufigsten höre.

Woche 1. Onboarding heißt bei mir: Zugang zu euren Quellen plus ein Setup-Gespräch — dann initialisiere ich den Wissenskorpus aus eurer Bestandsdoku. Ab dann gilt die 48-Stunden-Taktung.
Begrenzte Kapazität

Ich fahre maximal zwei Mandate parallel.

Qualität vor Auslastung — jedes Mandat bekommt das volle System und meine volle Aufmerksamkeit. Wenn du wissen willst, ob dein Setup passt: 30 Minuten, kein Pitch, ehrliche Einschätzung. Im schlechtesten Fall gehst du mit einer klaren Diagnose deines Anforderungsprozesses raus.

P.S. Du bist unsicher, ob euer Problem groß genug ist? Rechne oben nach, was ein halber Sprint kostet. Wenn die Zahl dich nicht stört, brauchst du mich nicht — ehrlich.