Drivers Model
Was ist es?
Ein Modell, das eine zentrale Erfolgskennzahl (meist die North Star Metric) hierarchisch in ihre kausalen Treiber ("Drivers") zerlegt – von der übergeordneten Geschäftskennzahl bis hinunter zu konkreten Metriken, die einzelne Teams direkt beeinflussen können. Typischer Aufbau (Baumstruktur):
Ebene 0 – North Star / Fokusmetrik: z. B. "Weekly Active Teams", "wöchentliche abgeschlossene Bestellungen"
Ebene 1 – Treiber (Drivers): 3–5 Faktoren, die die North Star direkt bestimmen (z. B. Neukunden-Aktivierung, Nutzungstiefe, Kundenbindung)
Ebene 2 – Team-/Input-Metriken: von einzelnen Teams tatsächlich beeinflussbare Stellhebel (z. B. Qualifizierte Pipeline, Conversion-Rate, Produktqualität)
Ebene 3 – Aktivitätsmetriken: konkrete, tägliche Leading Indicators (z. B. Kampagnen gestartet, MQL-Volumen)
Ziel: Statt eine einzelne Kennzahl isoliert zu betrachten, wird sichtbar, welcher Hebel an welcher Stelle die Gesamtzahl bewegt – und wer im Unternehmen dafür verantwortlich ist.
Zielgruppe
Produkt-/Growth-Teams, die eine North-Star-Metrik bereits definiert haben, aber die tägliche Handlungsableitung ("was genau bewegt die Zahl?") noch fehlt
Unternehmen mit mehreren Teams/Abteilungen, die auf eine gemeinsame Top-Kennzahl einzahlen sollen, aber unterschiedliche Stellhebel haben (Marketing, Vertrieb, Produkt)
Führungsebenen, die KPI-Sprawl (zu viele unverbundene Einzelkennzahlen) auflösen und Verantwortlichkeiten klären wollen
Weniger geeignet für: sehr frühe Unternehmen vor Product-Market-Fit (North Star ändert sich noch zu oft), Teams, bei denen eine einzige Person/Abteilung ohnehin alle relevanten Metriken kontrolliert (dort reicht eine einfache KPI-Liste), Organisationen mit inkonsistenter Datenbasis (Baum verstärkt dann nur Streit über Definitionen)
Vorteile
Macht abstrakte Ziele ("mehr Wachstum") in konkrete, teamspezifische Stellhebel übersetzbar
Schafft organisationsweite Klarheit, wer welchen Hebel verantwortet – reduziert Silo-Optimierung auf Kosten anderer Bereiche
Ermöglicht Diagnose statt nur Reporting: Bei Rückgang der North Star lässt sich im Baum nachvollziehen, welcher Treiber ursächlich war
Verbindet Tagesgeschäft (Aktivitätsmetriken) direkt mit Unternehmensstrategie (North Star) – gute Grundlage für OKRs
Visuell leicht kommunizierbar (Whiteboard/Miro-Vorlagen verbreitet)
Nachteile / Risiken
Reale Kausalität ist oft komplexer als der Baum: Metriken beeinflussen sich gegenseitig in Feedback-Schleifen (z. B. Engagement → Retention → Weiterempfehlung → Neukunden → wieder Engagement), während das Modell meist nur eine Richtung (Treiber → North Star) abbildet
Erfordert bereits eine solide, konsistente Datenbasis – bei uneinheitlichen Metrik-Definitionen entstehen mehr Konflikte als Erkenntnisse
Baum kann bei zu häufiger Anpassung der North Star (typisch in frühen Phasen) schnell veralten
Nur die halbe Arbeit: Der Baum zeigt Hebel, aber keine Priorisierung, welcher Hebel den größten Effekt bei geringstem Aufwand hat (braucht zusätzliche Priorisierungsmethode)
Gefahr der Übermodellierung: Zu viele Ebenen/Äste machen den Baum selbst unübersichtlich (Empfehlung meist: max. 3 Ebenen, wenige Knoten pro Ebene)
Alternativen / ergänzende Frameworks
Ansatz | Ausrichtung |
|---|---|
North Star Metric Framework (Amplitude) | Definiert die Spitzenkennzahl, Drivers Model ist die typische Ergänzung zur Zerlegung |
AARRR / Pirate Metrics | Funnel-orientierte Struktur (Acquisition–Activation–Retention–Referral–Revenue) statt reiner Baumhierarchie |
Balanced Scorecard | Breiterer strategischer Rahmen (Finanzen, Kunde, Prozesse, Lernen), nicht nur eine Kennzahl im Zentrum |
OKRs | Zielsystem statt Kennzahlenbaum – Drivers Model liefert oft die Kandidaten für Key Results |
Growth Loops (Reforge) | Modelliert Wachstum als sich selbst verstärkende Schleifen statt linearer Treiber-Hierarchie – realistischer bei Netzwerkeffekten |
RICE/ICE-Priorisierung | Ergänzt den Drivers Baum um eine Rangfolge, welcher Hebel zuerst bearbeitet wird |
Sonstiges wichtig für die Entscheidung
Bewährte Einstiegsvariante: einfaches Dashboard mit drei Sektionen (North Star oben, Drivers in der Mitte, Inputs unten) testen, bevor in ein aufwendiges Tool investiert wird
Vor dem Bau des Baums: Metrik-Definitionen unternehmensweit klären – sonst wird der Baum selbst zum Streitpunkt statt zur Lösung
Kritikpunkt namhafter Praktiker: Das reine "Input → North Star"-Modell ist einseitig; wachstumsstarke Unternehmen (v. a. mit Netzwerkeffekten) sollten es um zirkuläre Wachstumsschleifen (Growth Loops) ergänzen
In der Praxis oft Teil eines größeren Growth-Systems: North Star definieren → Drivers/Metric Tree bauen → Wachstumsengine(s) identifizieren → Roadmap darauf ausrichten
Fazit für Entscheider:
Sehr nützliches Werkzeug, um eine bestehende North-Star-Metrik in handlungsfähige Teilziele für einzelne Teams zu übersetzen und Verantwortlichkeiten zu klären. Sollte nicht isoliert, sondern als Ergänzung zu einer bereits definierten North Star Metric sowie zu Priorisierungs- und OKR-Prozessen eingeführt werden – und mit Vorsicht bei Geschäftsmodellen mit starken Netzwerk-/Feedback-Effekten, wo lineare Treiberketten die Realität nur unvollständig abbilden.