CPO

Ein CPO besitzt das Produkt. Nicht das Design, nicht das Engineering, nicht das Marketing, sondern die Frage, was Kunden in welcher Reihenfolge bekommen. Die Rolle existiert, weil jede Shipping-Entscheidung gleichzeitig eine Entscheidung dagegen ist, etwas anderes zu shippen, und ab einer gewissen Größe braucht diese Wahl einen Verantwortlichen. Kombiniere sie mit dem CTO-Mandat in einer Person, und du bekommst einen CTPO; halte sie in Teilzeit, und du bekommst einen Fractional CPO.

Ein guter CPO spricht drei Sprachen fließend: Kunden (was schmerzt), Engineers (was möglich ist), Executive-Team (was die P&L bewegt). Fehlt eine dieser drei, entsteht Produkt-Schuld: gebaut, aber niemand kaufte; verkauft, aber niemand baute.

Beispiel für das Fehlende-Sprache-Versagen: Ein CPO, frisch aus einer sales-getriebenen Org, spricht P&L und Kunden fließend, kann aber nicht lesen, was Engineering ihm über Kosten sagt. Er legt die Roadmap auf ein Quartal voller „Quick Wins" fest, die in Wahrheit sechs Monate Plattformarbeit sind, die Termine rutschen, und auf beiden Seiten erodiert das Vertrauen. Das Spiegelbild-Versagen ist der Engineer-gewordene-CPO, der alles scopen kann, aber nicht sagen kann, welches Feature tatsächlich Umsatz bewegt. Der Job ist die Übersetzung zwischen allen dreien, und Schwäche in einer davon zeigt sich darin, dass selbstbewusst das Falsche gebaut wird.

Der ehrliche Trade-off und der häufige Fehler: Founder greifen zu früh nach einem dedizierten CPO. Vor PMF ist die Rolle Overkill, weil die eigene Kundenintuition des Founders das wertvollste Produkt-Asset der Firma ist und sich nicht delegieren lässt. Die Arbeit wird vom Founder oder einem CTPO absorbiert, bis das Engineering-Team so groß ist, dass die Entscheidung, was als Nächstes gebaut wird, ein Vollzeitjob ist. Vor diesem Punkt schiebt ein CPO meist nur eine Schicht zwischen Founder und Kunde, was das Gegenteil von dem ist, was ein frühphasiges Produkt braucht. Verwandt: Fractional CTO Österreich.