PM-Engineer-Ratio: Warum ein CPO Product Management bereut – und trotzdem PMs einstellt

Warum sagt ein CPO, er bereue Product Management?

Weil die Formulierung das Team zwingt, jede PM-Stelle zu begründen. Die PM-Engineer-Ratio folgt bei Whatnot keinem festen Schlüssel: «We regret that product management exists» heisst dort nicht, PMs abzuschaffen – sondern keinen einzustellen, nur weil das Org-Chart ein Feld frei hat.¹

Tom Verrilli führt das Product-Team von Whatnot, der Live-Shopping-Plattform, die als schnellstwachsendes US-Marketplace-Business gilt; davor war er sieben Jahre bei Twitch, zuletzt als Chief Product Officer, und Director of Product Growth bei Twitter. Im Gespräch mit Lenny Rachitsky erklärt er das Credo so: «You don't hire a PM just for the sake of hiring one. You hire one where there's really specific need.»¹

Die Zahl dazu schrieb er selbst öffentlich: In zwei Jahren bewarben sich 31'832 Menschen als Product Manager bei Whatnot. Eingestellt wurde eine Person. Das Team zählt gut 20 PMs – klein gemessen am Handelsvolumen, das die Plattform bewegt. Dieser Artikel nimmt die Provokation ernst und fragt, was davon ein DACH-Org-Chart übernehmen kann.¹

Woher die Pod-Ratio kommt – und warum sie nie ein Produktprinzip war

Die Pod-Ratio entstand als Skalierungs-Reflex, nicht als Design-Entscheidung. Verrillis Rekonstruktion: Product Management gab es ursprünglich gar nicht – Gründer sprachen direkt mit Engineering und Design. Erst die Wachstumsgeschwindigkeit der Internet-Firmen erzwang Delegation, und irgendwann «popped this HR ratio of a pod into being»: sechs Engineers, ein Designer, ein PM, ein Engineering Manager.¹

Die Folge bei Produkten mit Milliarden täglichen Nutzern: sehr viele Engineers, also sehr viele PMs – auch dort, wo wenig zu entscheiden ist. «You probably don't need a PM for notifications infrastructure», sagt Verrilli. Und schärfer: Zu viele PMs «infantilize the engineers and the designers who are perfectly capable of making good decisions, but just never had to because there was always a PM to babysit them.»¹

Die Ratio erzeugte ausserdem ihre eigene Arbeit. Mehr Ebenen bedeuten mehr Alignment-Meetings, mehr Reviews, mehr Übersetzungsschichten – Systeme gebären Systeme. Wer schon einmal erlebt hat, wie ein Squad-Modell an der eigenen Koordinationslast scheitert, kennt den Mechanismus.¹

PM ist ein Trade, kein Titel: das Muskel-Argument

Das einzige belastbare Argument für PM als Spezialistenrolle ist laut Verrilli zugleich ihr Risiko: «It's a trade, not a qualification. It's something you get good at by doing. It's a muscle.» Muskeln wachsen durch Wiederholung – und verkümmern, wenn jemand anderes die Reps übernimmt.¹

Deshalb schneidet die Pod-Logik doppelt: Sie verteilt die knappe Kernfähigkeit auf zu viele Stellen und nimmt gleichzeitig Engineers und Designern die Gelegenheit, den Entscheidungsmuskel selbst zu trainieren. Übrig bleibt ein Rollenprofil, das Verrilli in Interviews sofort erkennt: Kandidaten, «whose specialty wasn't technical, it was politics.»¹

Lenny Rachitsky verweist im Gespräch auf Marty Cagans Begriff dafür: Product Theater – die Tätigkeit sieht aus wie Produktarbeit, besteht aber aus Meetings, Dokumenten und Framings für die Führung. Verrillis Einstellungspraxis zieht die Konsequenz: Jede Kandidatin und jeder Kandidat bearbeitet eine Case Study mit echten Daten und verteidigt die eigene Position mündlich. «How quickly the thinking decays from folks who are good at the theater but not the specifics is kind of really telling.»¹

Wie du PMs auf Probleme statt auf Teams mappst

Der Kern des Whatnot-Modells ist ein anderer Allokations-Mechanismus: PMs gehören keinem Team, sie gehören einem Problem. Alle sechs Monate definiert die Führung, was wahr werden muss – Outcomes und kritische Projekte – und besetzt pro Punkt eine direkt verantwortliche Person (DRI). Erst dann wird entschieden, wer die passende Person ist.¹

Übersetzt für ein DACH-Org-Chart heisst das: Erstens: Plane Probleme, nicht Kästchen – die Planungsliste nennt Ergebnisse («was muss wahr werden»), keine Team-Zuordnungen. Zweitens: Erlaube Nicht-PM-DRIs – ein Engineer oder eine Designerin kann ein Vorhaben führen, durchläuft aber dieselben Product Reviews wie alle. Drittens: Akzeptiere PM-freie Phasen – ein Team kann Monate ohne PM laufen, solange der Produktkontext da ist. Viertens: Versetze PMs regelmässig. Verrillis Begründung: «You're going to work out more muscle groups by moving around on the things you work on.»¹

Damit das nicht in Beliebigkeit kippt, hält Whatnot zwei Disziplinen dagegen. «Verify then trust»: Die Führung delegiert nicht blind, sondern sitzt periodisch mit in den Details – der CEO räumt auch einmal seinen Kalender, um mit dem Team Tickets, Code und Daten Zeile für Zeile durchzugehen. Und «know then go»: alle Skalierungs- und Risikofragen einmal durchdenken, dann trotzdem ziehen. Produktarbeit bleibt Arbeit; sie wird nur nicht mehr automatisch an eine Rolle geheftet.¹

Warum deine besten Leute IC-Arbeit machen sollten

Die zweite Verschiebung betrifft die Karriereleiter. «We took all of our A players and then promoted them out of doing things», sagt Verrilli über die alte Welt. Bei Whatnot verbringen selbst die PM-Manager über 90 Prozent ihrer Zeit mit IC-Arbeit, der CPO selbst rund die Hälfte.¹

Das Argument ist Effizienz, nicht Nostalgie: Ein erfahrener Product Leader mit fünfzehn Jahren Instinkt entscheidet schneller und sieht mehr vom Brett – «why wouldn't you want Messi playing for your team rather than trying to have the academy coming along all the time?» Wer mehrere Bereiche gleichzeitig hält, richtet sie nebenbei aufeinander aus und spart die Monate an Verhandlungen zwischen konkurrierenden Teams.¹

Auch die Vergütungsfrage beantwortet Verrilli unaufgeregt: Wer die Vergütung einer ganzen PM-Pyramide zusammenzählt, kann stattdessen drei ausserordentliche ICs auf VP-Niveau bezahlen. Die Bewegung ist real – im Gespräch fällt die Liste von CTOs grosser Tech-Firmen, die als Individual Contributors zu Anthropic gewechselt sind. Für die Betroffenen heisst das: IC-Arbeit ist kein Abstieg mehr, sondern der Ort, an dem Wirkung entsteht.¹

Die Voraussetzung, über die niemand spricht: Kontext für alle

Das ganze Modell steht auf einer Annahme: Engineers und Designer treffen nur dann gute Produktentscheidungen, wenn sie den Kontext dazu haben – Kundensignale, Geschäftsziele, Code-Realität. Verrilli sagt es explizit: Es wäre «way better if engineering and design had the context that they needed to just make great decisions». Und er nennt den Grund, warum das heute erreichbar ist: «It's easier to kind of like converse directly with the codebase and talk to engineers than it ever has been.»¹

Genau diese Voraussetzung ist der Job von Teklens: Die Context Engine liest Jira, Confluence und den echten Code und gibt jedem im Team den Kontext deiner besten PM – Prioritäten mit Begründung, Specs, die gegen den Code geprüft sind, Antworten auf «was wurde dazu je entschieden?». Zur Einordnung gehört der Satz, der bei dieser Kategorie immer mitfährt: Teklens ersetzt deine PMs nicht. Es nimmt ihnen die Arbeit ab, die sie vom Produkt fernhält – damit die wenigen, senioren PMs dort arbeiten, wo Verrilli sie hinstellt: auf den schwersten Problemen. Ob das für euer Org-Chart trägt, klärst du am schnellsten in 30 Minuten mit einem Founder.

Das stärkste Argument: die Zahlen hinter dem Regret

Zum Schluss die Evidenz, an der das Modell hängt. Whatnot bewegt als schnellstwachsendes US-Marketplace-Business Milliarden an Handelsvolumen – mit gut 20 PMs, lose in drei Gruppen organisiert (Buyer, Seller, Trust & Risk) und regelmässig neu auf Probleme verteilt. Die Organisation, die nach jeder Pod-Formel unterbesetzt wäre, liefert schneller, als die Formel es erlaubt hätte.¹

Und die 31'832 Bewerbungen mit einer Anstellung sind keine Arroganz-Anekdote, sondern eine Diagnose des Marktes: Der Titel ist inflationär geworden, die Kernfähigkeit nicht. Verrilli stellt weiter ein – kurz vor dem Gespräch zwei Personen an einem Tag – aber gegen Bedarf, nicht gegen Ratio.¹

Damit schliesst sich der Bogen zur Eingangsfrage. «We regret that product management exists» ist keine Absage an Product Management – es ist die schärfste verfügbare Formulierung dafür, die Rolle wieder an ihren Zweck zu binden. Die Pod-Ratio beantwortete die Frage, wie viele PMs auf einen Engineer kommen. Die bessere Frage war immer: Wo braucht dieses Produkt gerade die Fähigkeit, Entscheidungen zu treffen – und wer hat den Kontext dazu?

Häufige Fragen

Empfehlungen

• Liste Vorhaben, nicht Teams. Gehe die laufenden Vorhaben durch und markiere, wo tatsächlich Produktentscheidungen anstehen. PM-Bedarf entsteht aus Problemen, nicht aus Headcount-Feldern.
• Formuliere Halbjahresziele als «was wahr werden muss». Outcomes und kritische Projekte, je ein DRI – Engineer, Designerin oder PM. Wer DRI ist, durchläuft dieselben Product Reviews wie alle anderen.
• Prüfe Hiring auf Substanz statt Theater. Case Study mit echten Daten, Position mündlich verteidigen lassen. Das trennt schärfer als jede Interview-Erzählung über «driving alignment».
• Halte Senior-Leute in der IC-Arbeit. Reserviere für Directors und VPs einen fixen IC-Anteil und honoriere ihn in der Vergütung – sonst befördert ihr eure besten Leute aus der Wirkung heraus.
• Baue zuerst den Kontext, dann die neue Ratio. Engineers und Designer können nur entscheiden, was sie sehen. Erst wenn Kundensignale, Ziele und Code-Wissen zugänglich sind, kannst du PM-Stellen auf Probleme konzentrieren.
• Miss die Umstellung an Entscheidungen, nicht an Stimmung. Steigt die Zahl der Entscheidungen ohne Eskalation und sinkt die Wartezeit auf PM-Kapazität, funktioniert die neue Verteilung. Wenn nicht: Kontext prüfen, bevor du Stellen nachbesetzt.

Einordnung & Grenzen

• Alle Zahlen und Zitate dieses Beitrags stammen aus einem einzigen Gespräch: Lenny's Podcast mit Tom Verrilli (2026). Sie sind Selbstauskünfte eines beteiligten CPO, nicht unabhängig verifiziert; Zitate sind aus dem Transkript übernommen und für die Lesbarkeit minimal geglättet.
• Whatnot ist ein Consumer-Live-Commerce-Marketplace mit produktnahen Founder-CEOs und einer Kultur, die auf dieses Modell eingestellt ist. Verrilli betont selbst, dass es nicht überall passt – und rät: «assume that at least half of what I've said is wrong.»
• Im DACH-B2B-Mittelstand mit gewachsener Codebase und Regulierung können Compliance-Gates, Enterprise-Stakeholder und Kundenzugänge einen höheren PM-Anteil rechtfertigen als bei Whatnot. Die Richtung des Arguments bleibt; die Ziel-Ratio ist kontextabhängig.
• Die Teklens-Aussagen beschreiben Fähigkeiten des Produkts, keine gemessenen Kundenresultate; Pilot-Metriken stehen aus.

Quellen

Jede externe Zahl und jedes Zitat in diesem Beitrag – nachprüfbar verlinkt.

1. 1.Lenny's Podcast, «This CPO regrets that product management exists» – Tom Verrilli (Whatnot), 2026 ↗ – Alle Zitate und Zahlen dieses Beitrags stammen aus dieser Episode; Originalzitate auf Englisch belassen.

Weiterlesen im PM Lab

Verwandte Deep Dives – aus demselben Pillar und den angrenzenden Phasen.

Passende Use Cases aus der Bibliothek

Vom Beitrag direkt in die Praxis: Diese Use Cases setzen die Konzepte mit Teklens um.