Eine Produktanalyse-Metrikenhierarchie ist ein strukturiertes Framework, das die Metriken eines Produkts von der übergeordneten North Star Metric über führende Indikatoren bis hin zu diagnostischen Metriken organisiert – wodurch jedes Team versteht, wie seine täglichen Entscheidungen mit dem wichtigsten Ergebnis des Unternehmens zusammenhängen, und schnell erkennen kann, welcher spezifische Hebel Änderungen in der North Star Metric bewirkt.
?
Wie identifizieren und definieren SaaS-Unternehmen ihre North Star Metric?
Die North Star Metric (NSM) ist die einzelne Metrik, die den Kernwert, den das Produkt den Kunden liefert, am besten erfasst – und die, wenn sie wächst, am zuverlässigsten mit langfristigem Geschäftserfolg korreliert. Sie steht an der Spitze der Metrikenhierarchie, da jede andere Metrik Bewegungen in der NSM erklären sollte. Die Auswahl der richtigen NSM erfordert die Beantwortung der Frage: Welche spezifische Aktion führen Kunden aus, die, wenn sie häufig und intensiv durchgeführt wird, bedeutet, dass sie den vollen Wert aus dem Produkt erhalten? Gute NSM-Beispiele: Slack verwendet „Gesendete Nachrichten“ (wenn Teams Nachrichten senden, kommunizieren sie in Slack statt per E-Mail – der Kernwert); Amplitude verwendet „Wöchentlich abfragende Benutzer“ (Benutzer, die aktiv Erkenntnisse aus dem Produkt extrahieren); Zendesk verwendet „Gelöste Tickets“ (die Kernaufgabe jedes Support-Teams, das die Plattform nutzt). Schlechte NSMs: Umsatz (ein nachlaufender Indikator, keine direkte Messung der Wertlieferung); registrierte Benutzer (eine Vanity Metric, die von der tatsächlichen Nutzung losgelöst ist); oder Seitenaufrufe (ein Proxy, der aus den falschen Gründen wachsen kann). Die NSM sollte für jede Person im Unternehmen verständlich und von mehreren Teams direkt verbesserbar sein.
?
Wie sollte Product Ops einen Metrikenbaum entwerfen, der die North Star Metric mit den täglichen operativen Metriken verbindet?
Ein Metrikenbaum (auch Driver Tree oder KPI-Baum genannt) ist ein hierarchisches Diagramm, das mathematisch zeigt, wie sich operative Metriken auf niedrigerer Ebene kombinieren, um die North Star Metric zu erzeugen. Konstruktionsprozess: Beginnen Sie mit der NSM an der Spitze. Fragen Sie: „Was sind die zwei oder drei Faktoren, die, wenn sie multipliziert oder summiert werden, die NSM ergeben?“ Diese werden zu Metriken der Ebene 2. Für jede Metrik der Ebene 2 stellen Sie dieselbe Frage – was sind die Faktoren, die sie erzeugen? Diese werden zu Metriken der Ebene 3. Fahren Sie fort, bis Sie Metriken erreichen, die spezifische Teams durch ihre tägliche Arbeit direkt beeinflussen können. Beispiel eines Teilbaums: NSM = Wöchentlich aktive Benutzer × Genutzte Funktionen pro Benutzer. Ebene 2a: Wöchentlich aktive Benutzer = Neu gewonnene Benutzer × 1-Wochen-Bindungsrate. Ebene 2b: Genutzte Funktionen pro Benutzer = Breite der angenommenen Funktionen × Tiefe der Nutzung pro Funktion. Ebene 3a unter Neu gewonnene Benutzer: Teststarts × Testaktivierungsrate. Product Ops erstellt und pflegt diesen Baum in Notion oder einem BI-Tool und verwendet ihn in jedem Produkt-Review-Meeting, um zu erklären, was NSM-Änderungen antreibt: „Die NSM ist diese Woche um 5 % gesunken – die Analyse der Ebene 2 zeigt, dass die wöchentlich aktiven Benutzer stabil sind, aber die Funktionen pro Benutzer zurückgegangen sind: Ebene 3 zeigt, dass die Breite der Akzeptanz speziell für Funktion X gesunken ist.“
?
Wie nutzen Produktteams diagnostische Metriken, um die Ursachen von Bewegungen der North Star Metric zu identifizieren?
Diagnostische Metriken (auch „Guardrail Metrics“ oder „Health Metrics“ genannt) befinden sich in der Hierarchie unterhalb der NSM und werden untersucht, wenn sich die NSM unerwartet bewegt. Das Prinzip: Eine Änderung der North Star Metric hat einen spezifischen, identifizierbaren Treiber, der durch das Durchlaufen des Metrikenbaums gefunden werden kann. Eine effektive diagnostische Untersuchung folgt der Baumstruktur: Wenn die NSM zurückgegangen ist, überprüfen Sie die Metriken der Ebene 2 – kam der Rückgang vom Benutzeranzahl-Zweig oder vom Nutzungsintensitäts-Zweig? Wenn Ebene 2 zeigt, dass die Benutzeranzahl der Treiber ist, überprüfen Sie Ebene 3 – kommt der Rückgang von der Akquisition (weniger neue Benutzer) oder der Bindung (bestehende Benutzer wechseln schneller ab)? Wenn die Bindung der Treiber ist, überprüfen Sie Ebene 4 – konzentriert sich der Rückgang auf ein bestimmtes Benutzersegment, einen bestimmten Produktbereich oder eine bestimmte Kohorte aus einem bestimmten Akquisitionszeitraum? Wenn die Untersuchung drei oder vier Ebenen durchlaufen hat, ist die Ursache typischerweise spezifisch genug, um handlungsrelevant zu sein: „Die 7-Tage-Bindung für Benutzer, die sich über den Product Hunt Launch angemeldet haben, sank von 45 % auf 28 % im Vergleich zu unserer Standardkohorte – die Benutzer dieser Kampagne tendieren zu kleineren Teams, die das Funktionslimit des kostenlosen Plans erreichen, bevor sie vollständig aktiviert werden können.“ Dieses spezifische Ergebnis ermöglicht eine gezielte Reaktion, keine breite, ungerichtete Verbesserungsanstrengung.
Wissens-Challenge
Produktanalyse-Metrikenhierarchie gemeistert? Versuchen Sie nun, das verwandte 5-Buchstaben-Wort zu erraten!
Tippen oder Tastatur benutzen