Free Competency Framework Template | Role-Based Examples & Proficiency Levels
Free Competency Framework Template | Role-Based Examples & Proficiency Levels
Ein Product-Manager-Kompetenzrahmen strukturiert, welche Fähigkeiten auf welchem Level erwartet werden — von Discovery über Delivery bis Strategie. Diese Vorlage deckt vier Stufen ab (Associate PM bis Lead PM) mit konkreten Erwartungen pro Kompetenzbereich und einem bewährten Bewertungsraster für Recruiting, Performance-Reviews und Karrieregespräche.
Warum ein PM-Kompetenzrahmen wichtiger ist als ein Job-Titel
In der Praxis unterscheiden sich die Erwartungen an eine „Senior Product Managerin" zwischen Unternehmen erheblich. Was bei einem 50-Personen-Startup Senior bedeutet, ist bei einem Konzern bestenfalls Mid-Level. Ohne einen gemeinsamen Rahmen entstehen drei Probleme: Beförderungsentscheidungen wirken willkürlich, Lücken bleiben unerkannt, und neue PMs haben keine klare Orientierung für ihre Entwicklung.
Ein strukturierter Kompetenzrahmen löst das, indem er:
- Level-Definitionen von subjektiven Urteilen löst
- Recruiting-Kriterien für alle Stufen vereinheitlicht
- Entwicklungsgespräche konkret macht: „Welche Kompetenz fehlt noch bis zum nächsten Level?"
- Kalibrierungen im Team fair und nachvollziehbar macht
Die vier PM-Levels: Scope, Autonomie und Zeithorizont
Der wesentliche Unterschied zwischen den Levels ist nicht Erfahrung in Jahren, sondern Scope und Autonomie. Jede Stufe erweitert den Wirkungskreis und die erwartete Selbstständigkeit.
| Level | Typischer Scope | Zeithorizont | Entscheidungsautonomie |
|---|---|---|---|
| Associate PM | Einzelnes Feature / Komponente | Sprint / kurzfristig | Lösungen vorschlagen, Abwägungen eskalieren |
| PM | Produktbereich / Domain | Quartal | Priorisierungsentscheidungen im eigenen Bereich |
| Senior PM | Mehrere Bereiche / komplexe Initiativen | Jahresplanung | Cross-funktionale Abhängigkeiten verhandeln |
| Lead PM | Portfolio / Mehrere Teams | Mehrjährige Perspektive | Strategische Wetten genehmigen oder ablehnen |
Kompetenzrahmen: Die sechs Kerndimensionen
Ein robuster PM-Kompetenzrahmen braucht mindestens sechs Dimensionen. Weniger unterschätzt die Breite der Rolle, mehr wird schwer handhabbar.
1. Discovery & Customer Research
Discovery ist die Fähigkeit, echte Kundenprobleme zu identifizieren, bevor Lösungen gebaut werden. Sie trennt gute von schlechten PM-Entscheidungen stärker als jede andere Kompetenz.
| Level | Erwartung |
|---|---|
| Associate PM | Nutzt Forschungsergebnisse und fasst Insights zusammen; führt strukturierte Interviews mit Anleitung durch |
| PM | Plant und moderiert qualitative User-Research eigenständig; leitet aus Daten klare Problem-Statements ab |
| Senior PM | Definiert die Research-Agenda für den Bereich; kombiniert Quali- und Quanti-Methoden für strategische Entscheidungen |
| Lead PM | Baut Research-Kapazitäten im Team auf; verankert kundenzentrierte Entscheidungskultur organisationsweit |
2. Delivery & Execution
Delivery misst, ob Features tatsächlich geliefert werden — zuverlässig, in Qualität und im Rahmen der Ressourcen. Es ist die am stärksten mit Engineering verwobene PM-Kompetenz.
| Level | Erwartung |
|---|---|
| Associate PM | Schreibt klare Anforderungen; pflegt Backlog; koordiniert mit Engineering in Sprints |
| PM | Liefert Quartals-Roadmap zuverlässig; managt Risiken und Abhängigkeiten; kommuniziert Scope-Änderungen proaktiv |
| Senior PM | Koordiniert Delivery über mehrere Teams; identifiziert systemische Lieferhindernisse und löst sie |
| Lead PM | Setzt Delivery-Standards fürs Portfolio; baut Prozesse, die Teams ohne direkte Kontrolle lieferfähig machen |
3. Strategie & Priorisierung
Priorisierung bedeutet Nein-Sagen zu guten Ideen, um das Beste zu ermöglichen. Auf höheren Levels bedeutet Strategie: Marktpositionierung, langfristige Differenzierung, Make-or-Buy-Entscheidungen.
| Level | Erwartung |
|---|---|
| Associate PM | Priorisiert mit einfachen Frameworks (RICE, MoSCoW) unter Anleitung |
| PM | Trifft Priorisierungsentscheidungen im eigenen Bereich mit klarer Begründung; hinterfragt Annahmen |
| Senior PM | Entwickelt Produktstrategie für den Bereich; verknüpft Feature-Roadmap mit Unternehmenszielen |
| Lead PM | Definiert Portfolio-Vision; trifft Ressourcen-Allokations-Entscheidungen über Produkte hinweg |
4. Stakeholder-Management & Kommunikation
PMs haben keine disziplinarische Autorität über ihre Teams. Einfluss entsteht durch Klarheit, Vertrauen und die Fähigkeit, unterschiedliche Interessen auf ein Ziel auszurichten.
| Level | Erwartung |
|---|---|
| Associate PM | Kommuniziert Status klar an direktes Team; zeigt erste Präsenz in Stakeholder-Meetings |
| PM | Managt Erwartungen aktiv; eskaliert zeitgerecht und lösungsorientiert |
| Senior PM | Verhandelt Scope und Timeline mit Engineering- und Sales-Leadership; moderiert Konflikte |
| Lead PM | Repräsentiert Product-Interessen in Executive-Planungsrunden; baut strategische Beziehungen zu C-Level |
5. Technisches Verständnis
PMs müssen keine Entwicklerinnen oder Entwickler sein, aber sie müssen die technischen Implikationen ihrer Entscheidungen verstehen. Das verändert sich mit dem Level.
| Level | Erwartung |
|---|---|
| Associate PM | Versteht Grundbegriffe (API, Datenbank, Frontend/Backend); stellt gezielte Fragen statt zu raten |
| PM | Versteht technische Trade-offs; führt produktive Diskussionen mit Engineering ohne Übersetzer |
| Senior PM | Bewertet technische Schulden-Auswirkungen auf Roadmap; erkennt Architektur-Risiken frühzeitig |
| Lead PM | Setzt technische Kompetenz-Erwartungen im PM-Team; versteht Make-or-Buy-Entscheidungen strategisch |
6. Datenkompetenz & Metriken
Ohne Daten ist Product Management Meinung. Datenkompetenz bedeutet nicht SQL-Beherrschung — es bedeutet, die richtigen Fragen zu stellen und Antworten aus Daten abzuleiten.
| Level | Erwartung |
|---|---|
| Associate PM | Liest und interpretiert Dashboards; erkennt einfache Muster in Kennzahlen |
| PM | Definiert Feature-Success-Metriken vor dem Launch; bewertet A/B-Test-Ergebnisse selbstständig |
| Senior PM | Entwickelt Measurement-Frameworks für den Bereich; identifiziert Leading vs. Lagging Indicators |
| Lead PM | Definiert Portfolio-Metriken; stellt sicher, dass das gesamte PM-Team datengetrieben arbeitet |
Bewertungsraster: So nutzen Sie die Matrix im Alltag
Ein vierstufiges Bewertungsschema bewährt sich in der Praxis, weil es präzise genug für echte Differenzierung und einfach genug für konsistente Kalibrierung ist:
| Bewertung | Bedeutung | Typische Konsequenz |
|---|---|---|
| 1 — Nicht erfüllt | Unter Level-Erwartung, auch nach angemessener Zeit | Performance-Improvement-Plan, enge Begleitung |
| 2 — In Entwicklung | Fortschritt sichtbar, aber noch nicht konsistent auf Level | Gezieltes Coaching, klarer Zeitrahmen |
| 3 — Erfüllt | Zuverlässig auf Level — der erwartete Normalzustand | Stabiles Feedback, Entwicklungsgespräch |
| 4 — Übertrifft | Nachhaltiger Impact über den Scope hinaus | Signal für nächstes Level, Beförderungsgespräch |
Wichtig: „Erfüllt" ist kein schlechtes Ergebnis. Die meisten PMs sollten die meiste Zeit auf 3 sein. Eine Verteilung mit vielen 4ern zeigt oft Kalibrierungsprobleme oder zu niedrig gesetzte Level-Erwartungen.
Vorlage: Kompetenzrahmen als strukturierte Übersicht
Die vollständige Matrix kombiniert alle sechs Dimensionen für alle vier Levels. Für den Einsatz in Ihrer Organisation empfehlen sich drei Anpassungsschritte:
- Kontext anpassen: Welche Dimensionen sind in Ihrem Unternehmen besonders kritisch? B2B-SaaS priorisiert Stakeholder-Management und technisches Verständnis anders als ein Consumer-Produkt.
- Level-Bezeichnungen angleichen: Intern genutzte Titel (z. B. „Junior PM", „Staff PM") sollten den vier Framework-Stufen zugeordnet werden.
- Kalibrierung vereinbaren: Führen Sie eine erste Kalibrierungsrunde mit den PM-Leads durch, um Bewertungsunterschiede zu identifizieren und ein gemeinsames Verständnis aufzubauen.
Häufig gestellte Fragen
Wie viele Kompetenzen sollte eine PM-Skill-Matrix haben?
Sechs bis acht Dimensionen sind in der Praxis handhabbar. Weniger unterschätzt die Komplexität der Rolle; mehr als zehn wird schwer konsistent zu bewerten. Lieber wenige Dimensionen präzise definiert als viele vage.
Wie oft sollte die Matrix im Performance-Review verwendet werden?
Als Grundlage für halbjährliche oder jährliche Performance-Reviews. Zusätzlich als strukturierendes Element in monatlichen 1:1-Gesprächen: nicht jedes Mal alle Dimensionen, sondern jeweils die Entwicklungsfelder, auf die sich die Person konzentriert.
Gilt dieser Rahmen auch für Produkt-Designerinnen und Entwicklerinnen?
Nicht direkt. Die Dimensionen überschneiden sich teilweise, aber die spezifischen Erwartungen unterscheiden sich erheblich. Für Design und Engineering sind eigene Kompetenzrahmen sinnvoll, die mit dem PM-Rahmen aligniert, aber nicht identisch sind.
Wie geht man mit Level-Erwartungen in kleinen Produktteams um?
In kleinen Teams übernehmen PMs häufig Aufgaben, die in größeren Organisationen auf mehrere Levels verteilt wären. Hier empfiehlt sich, den Rahmen als Orientierung, nicht als striktes Regelwerk zu nutzen, und die Bewertung entsprechend zu kontextualisieren.
Wer sollte an der Entwicklung des Kompetenzrahmens beteiligt sein?
Mindestens: Head of Product / VP Product, erfahrene Senior PMs und eine HR-Business-Partnerin. Optional: Engineering-Leadership für technische Dimensionen, ein externer PM-Coach für Kalibrierung. Das Ergebnis hat höhere Akzeptanz, wenn PMs selbst mitwirken.
Jürgen Ulbrich
Jürgen Ulbrich has more than a decade of experience in developing and leading high-performing teams and companies. As an expert in employee referral programs as well as feedback and performance processes, Jürgen has helped over 100 organizations optimize their talent acquisition and development strategies.
