KI hat den Konflikt zwischen Product und Engineering nicht erfunden. Sie hat die Wartezeit abgeschafft, die ihn früher überdeckt hat.
Das richtet sich an CEOs, Aufsichtsräte und alle, die ein digitales Produkt noch mit zwei C-Level-Scoreboards führen: einen Chief Product Officer für die “Big Bet”, einen Chief Technology Officer für das System.
Die gängige Geschichte lautet: Jeder kann jetzt Software bauen, also kann das Organigramm so bleiben - oder dünner werden, weil „die Tools die Teams schon ausrichten werden.” Diese Geschichte kostet Geld. Sie kostet auch Monate.
KI gibt Product-Leuten gerade genug Engineering-Power, um ein überzeugendes Demo zu shippen. Sie gibt Engineers gerade genug Business-Verständnis, um am selben Nachmittag die Roadmap infrage zu stellen. Der Handoff, der früher ein Quartal brauchte, dauert jetzt eine Woche. Zwei Executives, die sich nur in der Eskalation treffen, verhalten sich noch so, als wäre der alte Kalender real.
Diese Verzögerung ist die Rechnung.
Das Zwei-Uhren-Problem
Stellen Sie sich eine Fabrik vor, in der eine Schicht jetzt ein Prototyp-Teil an einem Tag fräsen kann und die andere Schicht im selben Tool das Auftragsbuch sehen kann. Man behält nicht zwei Werksleiter, die sich nur freitags abstimmen. Man bekommt Ausschuss - oder eine Lagerhalle voller falscher Teile, schneller als zuvor.
In Software-Begriffen: Ein Product Manager kann ein grobes MVP hochziehen, ohne auf ein komplettes Engineering-Team zu warten. Ein Engineer kann mehr Code generieren, mit mehr Kontext über den Kunden, als der Prozess des letzten Jahres voraussetzte. Die alte Sequenz - Ticket schreiben, rüberschmeißen, im Sprint Review streiten - ist zu langsam für die neuen Maschinen.
Die Arbeit auf dem Boden ist bereits gemischt. Product Engineers sitzen absichtlich in der Lücke. Sie verbinden ein Kundenproblem mit lauffähiger Software.
Die C-Ebene ist oft nicht gemischt. Der eine Leader sagt noch „baut das Ding.” Der andere sagt noch „erst neun Monate Plattform.” Das Team fragt sich, wer entscheidet.
Diese Frage war früher nervig. Jetzt ist sie teuer. Geschwindigkeit ohne einen einzigen Owner schafft keine Alignment. Sie schafft zwei schnelle, widersprüchliche Pläne.
Was sich wirklich verändert hat
Code ist nicht mehr in jeder Situation die knappe Ressource. Urteilskraft ist es.
Product hat jetzt Engineering-Power. Keine Production-Engineering-Power. Demo-Power. Genug, um zu testen, ob eine Idee echtes Geld verdient. Genug, um - wenn niemand stoppt - einen Prototyp dorthin zu legen, wo zahlende Kunden darüber stolpern können.
Engineering hat jetzt Business-Insight. Keinen zweiten MBA. Genug Kontext, dass „können wir das implementieren?” die falsche erste Frage ist. Die bessere Liste lautet: sollten wir, für wen, welches Outcome, was ist der billigste verlässliche Test, und was kostet es im Unterhalt.
Ein funktionierendes Demo ist kein Production-System. „Jeder kann jetzt Software bauen” enthält noch immer eine großzügige Portion Marketing. Security, Architecture, Reliability, Data Quality und das On-Call-Roster wurden nicht wegautomatisiert. Sie wurden wichtiger, weil schlechte Software jetzt im Maßstab generiert werden kann.
Die Trennung wurde also nicht sauberer. Die Grenze wurde nass.
Wem gehört ein KI-Feature, das zum Kunden zeigt, auf dem Model-Stack sitzt, Inference-Kosten verbrennt und auf eine Weise falsch liegen kann, die Vertrauen zerstört? Product, wegen des Interface? Engineering, wegen des Systems? Keine Antwort reicht. Jemand muss den Schnittpunkt besitzen.
Wenn dieser Jemand der CEO ist, haben Sie den Chief Executive wieder zum Overflow gemacht.
Was die nicht kombinierten C-Rollen kosten
Einen separaten CTO und CPO zu behalten, ist nicht kostenlos. Das war nie so. KI hat den Zinssatz angehoben.
Zeit: jede gemischte Entscheidung braucht jetzt einen Gipfel. Prototyp in Woche 1, Architektur-Veto in Woche 3, umgeschriebene Wette in Woche 5. Wettbewerber, die in einem Kopf oder in einem Raum mit einem Owner entscheiden, sind schon live.
Geld: Sie bezahlen zwei Executive-Sitze, um auszuhandeln, was ein einzelner Trade-off-Owner an einem Dienstag gekillt oder gescoped hätte. Sie zahlen auch die Nacharbeit. Das Demo, das in Production geleakt ist. Der Plattform-Rewrite, der gestartet wurde, weil Product kein „Nein” mit Zahlen gesagt werden konnte. Das Feature, das geshipt wurde, weil Engineering nicht „nicht dieser Kunde, nicht dieses Quartal” gesagt werden konnte.
Talent: Product Engineers bleiben nicht in einer Firma, in der zwei Bosse einander überstimmen können. Sie gehen dorthin, wo das Outcome einen Namen hat.
Das ist kein Argument, dass zwei Gehälter ein Gehalt zu viel sind. Headcount-Theater ist, wie man einen Bottleneck einstellt und ihn Synergie nennt. Die Verschwendung ist die Latenz zwischen „Was” und „Wie”, wenn diese beiden Wörter nicht mehr auf verschiedenen Kalendern leben.
Wann Sie trotzdem trennen - und wie Sie dabei ehrlich bleiben
Ja. Und nein. Und ja.
Behalte zwei C-Rollen, wenn Technologie meist interne Unterstützung ist, wenn Product und Technologie verschiedene Geschäfte sind, oder wenn das Unternehmen groß genug ist, dass jedes Craft einen Spezialisten braucht und das Operating-Modell Trade-offs schon in Tagen, nicht Quartalen auflöst.
Wenn Sie die Trennung in einer Digital-Product-Firma beibehalten, brauchen Sie trotzdem Overlap-Literacy. Der CPO muss über Feasibility, Laufkosten und Failure-Modes nachdenken. Der CTO muss über den Kunden, die Wette und den Wert von „Done” nachdenken. Ein Handschlag im Nachhinein ist kein Modell. Es ist eine Hoffnung.
Kombinieren Sie sie, wenn Sie Software oder digitale Dienstleistungen verkaufen, die Roadmap schon hakt, Technologie den Umsatz bewegt und KI bestimmt, wie das Team jetzt entdeckt und ausliefert. Dann ist die Frage CPTO versus CTO versus CPO nicht mehr theoretisch. Zwei Scoreboards, oder ein Owner.
Der Nachteil des kombinierten Sitzes verschwindet nicht, weil die Tools schneller wurden. Die Person wird zum Craft neigen, dem sie vertraut. Ohne starke Deputies haben Sie einen Single Point of Failure geschaffen, der jetzt Fehler mit KI-Geschwindigkeit shippen kann.
Die Definition des kombinierten Jobs steht auf the-cpto.com/what-is-a-cpto.
Was Sie dieses Quartal fragen sollten
- Wem gehört eine kunden facing KI-Capability, die auch ein System- und Kostenproblem ist?
- Wie viele Tage wartet eine gemischte Product-Engineering-Entscheidung auf einen C-Level-Handshake?
- Was ist in den letzten 2 Quartalen vom Demo in Production geleakt, und wer hatte das Recht, es zu stoppen?
- Wenn wir zwei C-Sitze behalten, wo ist die schriftliche Regel, wer verliert, wenn Value und Reliability kollidieren?
- Zahlen wir für zwei Strategien oder für einen Trade-off?
Wenn Sie die letzte Frage nicht beantworten können, zahlen Sie schon die KI-Steuer. Sie stellen sie nur nicht auf die Agenda.
Die Quintessenz
KI hat Product eine Werkstatt gegeben und Engineering ein Fenster ins Auftragsbuch. Der Boden arbeitet schon als ein System. Zwei C-Level-Uhren auf diesem Boden kosten Zeit und Geld.
Führen Sie die Titel nicht zusammen, um aktuell zu wirken. Behalten Sie sie nicht getrennt, weil sich 2019 ordentlich anfühlte. Entscheiden Sie, wem der Schnittpunkt gehört, bevor das nächste Demo zum Vorfall des nächsten Quartals wird.
Remember: Ein Bottleneck ist nach oben gewandert. Ownership muss folgen.
