Ein vor fünf Jahren ausgebildeter Product Manager konnte ein Problem rahmen, eine Roadmap priorisieren und Stakeholder ausrichten. 2026 bleiben diese drei Fähigkeiten notwendig, reichen aber nicht mehr, um einen starken PM von einem überholten zu unterscheiden. Geändert hat sich nicht die Natur der Rolle, sondern die Grenzkosten einer Entscheidung: ein schlecht gerahmtes KI-Feature rechnet bei jeder Anfrage ab, eine falsch gelesene Metrik lenkt ein ganzes Quartal, ein auf falscher Unit Economics gebautes Pricing zerstört die Marge im Maßstab. Die Ausbildung ist dieser Verschiebung gefolgt: weg vom Vortrag über konzeptionelle Frameworks, hin zu angewandtem, beziffertem und geprüftem Training.
Learning by Doing allein trägt nicht mehr
PMs haben ihr Handwerk lange über Praxis, Mentoring und eine generalistische Business-Bildung gelernt. Dieses Modell hielt, solange der Zuschnitt der Rolle stabil blieb. Es hält nicht mehr, wenn dieselbe Position Finanzmodellierung, die Bewertung von KI-Systemen und echten organisatorischen Einfluss aufnimmt. Die inhaltlichen Kernaufgaben — Geschäftssinn, funktionsübergreifende Ausrichtung, strategische Führung, wie sie Gorchels in The Product Manager’s Handbook als Rolle des „General Managers des Produkts“ beschreibt — sind nicht verschwunden; erweitert hat sich der Kranz an Fähigkeiten darum herum, und genau dort hängt die klassische Ausbildung hinterher.
Vier strukturelle Verschiebungen erklären das. Erstens ist KI zur Produktkomponente geworden und kein Engineering-Thema mehr: Der PM muss verstehen, wie ein Modell evaluiert wird, wo es versagt, was es pro Inferenz kostet und wie sich das auf die Unit Economics durchschlägt. Zweitens ist Datenkompetenz vom Bonus zur Voraussetzung geworden: einen Aktivierungsfunnel lesen, eine Retention-Kurve nach Kohorten deuten, Leading von Lagging Indicators trennen ist keine Spezialität mehr, sondern Eintrittsbedingung. Drittens formalisieren Organisationen Kompetenzrahmen, um die chronische Rollenunklarheit zu senken. Und viertens muss Ausbildung den realen Druck von Delivery und Experiment abbilden, was ein Vortrag nicht leistet.
Was ein ernsthaftes Programm heute abdeckt
KI-Kompetenz auf Produkt-, nicht Ingenieursniveau. Von einem PM wird nicht erwartet, ein Modell zu trainieren, sondern die Entscheidungen darum zu lesen: wie ein Modell trainiert, evaluiert und ausgerollt wird; welche Metriken wirklich zählen — Accuracy, Latenz, Drift, Kosten pro Inferenz; wo die Risiken liegen — Bias, Halluzinationen, Datenschutz, Compliance. Die Trennlinie ist ökonomisch: Ein PM, der die Kosten pro Inferenz ignoriert, lässt ein Feature durch, dessen Marge negativ wird, sobald 5 % der Nutzer es intensiv adoptieren. Diese Lesart unterscheidet eine Produktentscheidung von einer Demo.
Verhaltens- und Produktanalytik. Der Kern liegt bei Aktivierungsfunnels und Feature-Adoption, Retention und Kohorten, North-Star-Frameworks und Experimentation: A/B, Inkrementalität, Sequencing. Der wiederkehrende Fehler ist nicht fehlende Daten, sondern ihre Überinterpretation: Ein Engagement-Anstieg kann ein Saisonartefakt sein, und eine Metrik, die steigt, ohne die Retention zu verbessern, ist eine Vanity Metric. Ein brauchbares Programm trainiert vor allem, Rauschen zu erkennen und eine falsifizierbare Hypothese vor dem Test zu formulieren, nicht danach.
Unit Economics und Finanzmodellierung. Der PM muss ein einfaches Modell aufsetzen können: CAC, CLV, Payback, Deckungsbeitrag je Segment, Preis- und Packaging-Szenarien, der Business Case einer Roadmap-Initiative. Die entscheidende Übung verbindet eine Produktwahl mit ihrer Margenwirkung: nicht „dieses Feature gefällt“, sondern „es kostet im Schnitt 0,30 €, am P99 aber 12 €, gehört also in eine höhere Stufe oder unter einen Deckel“. Ohne diese Lesart bleibt Priorisierung Meinungssache.
Funktionsübergreifende Führung. Der Wert eines PM entscheidet sich oft an der Schnittstelle zu Sales, Engineering, Design und Marketing, wo die Klarheit des Rahmens mehr wiegt als formale Autorität. Die eigentliche Kompetenz ist nicht die Präsentation, sondern der explizite Trade-off: benennen, was geopfert wird, warum, und was die Meinung ändern würde. Ein gut gerahmter Dissens bringt voran; ein weicher Konsens kostet ein Quartal.
Customer Discovery. In der Linie des Customer Development, das Steve Blank in The Startup Owner’s Manual beschreibt, trainiert die Ausbildung, Hypothesen iterativ zu validieren: kontinuierliche Interviews, Personas und Jobs-to-be-done, schnelles Lesen von Marktsignalen. Es geht darum, quantitative Daten (was passiert) und Interview (warum) auszubalancieren. Ein Team, das sich nur auf Dashboards stützt, optimiert Reibungen, die es nie verstanden hat.
Systemdenken und outcome-orientiertes Roadmapping. Je mehr der PM verbundene Portfolios steuert, desto mehr muss er Abhängigkeiten kartieren, Feedback-Schleifen verstehen und die Roadmap an messbaren Outcomes ausrichten statt an einer Liste von Deliverables. Genau das rechtfertigt das Bild vom PM als „Mini-GM“: Er verantwortet ein Ergebnis, keine Produktion.
Vom Kompetenzrahmen zur Praxis
Ein stimmiges Programm folgt einer Progression, keiner Modulsammlung. Es beginnt mit einem expliziten Kompetenzmodell (Strategie, Analytik, Execution, Leadership, Nutzerverständnis, technisches Verständnis), weil das Benennen der Erwartungen die Unklarheit senkt, die die Rolle abdriften lässt. Es folgen die Fundamente: Produktlebenszyklus, Discovery/Delivery-Schleifen, Priorisierungsmethoden (RICE, gewichtetes Scoring, Impact Modeling) und die Basis der Unit Economics.
Darauf baut die Daten- und Experimentpraxis auf: Funnel-Interpretation, Metrik-Design, Aufsetzen von Experimenten, Lesen verrauschter Daten und Erkennen von Vanity Metrics. Die KI-Module kommen erst danach, wenn das analytische Fundament steht, sonst beurteilt der PM ein KI-Feature, ohne messen zu können, was es produziert: konzeptionelle Funktionsweise von LLMs, sinnvolle Integrationsentscheidungen, Kosten- und Risikogrenzen, Bewertung von Features. Zwei Stufen machen den Unterschied zwischen Theorie und Kompetenz: Simulationen — Produktstrategie, dynamische Marktmodelle, funktionsübergreifende Rollenspiele, Priorisierung unter Budgetdruck — reproduzieren den realen Entscheidungskontext, in dem Information fehlt und Zeit drängt; und die Bewertung schließt die Schleife, indem sie angewandte Analyse misst, nicht auswendig gelerntes Vokabular.
Sieben Bausteine, fünf Formatentscheidungen
Ein vollständiges Curriculum deckt sieben Bausteine ab: essenzielle PM-Frameworks, Daten- und Metrik-Beherrschung, KI-Kompetenz, Markt- und Finanzmodellierung, Leadership und Kommunikation, Ethik und Regulierung, Experimentation und Validierung. Der am häufigsten vernachlässigte ist der vorletzte: Ethik und Compliance sind kein moralischer Zusatz, sondern eine Design-Restriktion, sobald ein Modell personenbezogene Daten verarbeitet.
Beim Format strukturieren fünf Entscheidungen ein wirksames Programm: Theorie und Praxis verzahnen statt trennen, auf Entscheidungssimulationen setzen, die echten Werkzeuge des Berufs integrieren, Mentoring und Peer-Learning organisieren und den PM für ein Portfolio verantwortlich machen statt für ein isoliertes Feature. Das Format zählt so viel wie der Inhalt: Dieselben Begriffe, im passiven Kurs oder in der Simulation gelernt, erzeugen nicht dieselbe Kompetenz.
Drei Profile, drei Wege
Der Übergang vom Ingenieur zum PM startet mit einem echten Vorteil (der Vertrautheit mit KI-Systemen), muss aber Business Modelling und Discovery nachholen, genau das, was Engineering nicht trainiert. Der PM eines AI-first-Unternehmens braucht Verstärkung bei Evaluierungsmetriken, Feasibility-Analysen und Unit Economics, weil sein Alltag darin besteht, die Kosten der Modelle zu steuern. Interne PM-Akademien schließlich tragen, wenn sie auf Simulationen, Analytics-Labs und konkreten Stakeholder-Workshops beruhen, und scheitern, wenn sie zu einem Katalog von Slides schrumpfen.
Zu viele Werkzeuge, zu wenig strukturiertes Denken
Der häufigste Fehlschlag eines Programms ist kein Mangel an Inhalt, sondern ein Ungleichgewicht. Man lehrt Werkzeuge ohne das Denken, das sie nützlich macht; man lehrt Analytik losgelöst von der Strategie, der sie dienen soll; man unterschätzt Leadership und Kommunikation zugunsten des Technischen; man behandelt KI als Ingenieurskompetenz, obwohl sie ein Produktthema ist; und man schiebt Unit Economics und Produktökonomie zu spät ins Curriculum, obwohl sie jeden Trade-off bedingen.
Wo anfangen, je nach Level
Ein einsteigender PM gewinnt am meisten, wenn er Analytik, Kundenverständnis, Business Modelling und Kommunikation festigt: das Fundament, das alle folgenden Entscheidungen lesbar macht. Ein PM auf mittlerem Niveau verlagert den Aufwand auf Strategie, Portfoliomanagement, Experimentiersysteme und KI. Ein Product Leader arbeitet an Coaching, Organisationsdesign und Finanz-Frameworks, weil sein Hebel nicht mehr die eigene Entscheidung ist, sondern die Qualität der Entscheidungen seines Teams.
Muss man technisch sein, braucht man Zertifikate
Die Fähigkeiten, die 2026 den Unterschied machen, in der Reihenfolge des täglichen Gebrauchs, nicht des Prestiges: Datenbeherrschung, ein produktseitiges KI-Verständnis, strategische Modellierung, experimentelle Strenge und funktionsübergreifende Führung. KI-Expertise ist dabei nicht auf Ingenieursniveau gefordert, wohl aber auf konzeptioneller und Produktebene: Ein PM, der ein Modell nicht bewerten und seine Kosten nicht lesen kann, kann die darauf gebauten Features nicht abwägen. Zertifikate behalten Wert, wenn sie eine angewandte, an Fällen geprüfte Kompetenz bestätigen — nicht, wenn sie das Auswendiglernen von Vokabular belohnen; der Markt hat gelernt, den Unterschied zu sehen. Finanzmodellierung übt man an Szenarien, die Preis, Kosten und Kundenwert auf einem Modell verbinden, und variiert dann eine Annahme nach der anderen, um zu sehen, welche die Marge bewegt. Und PMs bildet man intern über Simulationen, explizite Kompetenzrahmen, Analytics-Labs und Kompetenzbewertungen aus, ein Aufbau, der die reale Entscheidung reproduziert, statt sie zu beschreiben.
Am Ende trennt einen ausgebildeten PM von einem bloß zertifizierten eine einzige Fähigkeit: eine Produktentscheidung mit ihrer bezifferten Wirkung zu verbinden — auf Retention, auf Marge, auf die Kosten eines Modells — und diesen Trade-off vor Teams zu verteidigen, die nicht dieselbe Sprache sprechen. Frameworks und Zertifikate helfen dorthin; sie ersetzen den Nachweis von Wirkung nicht.