So nutzt Atlassian das Framework aus Goals, Signals, Metrics für die Entwicklung neuer Features

Beim “Goal, Signals, Metrics-Framework” geht es darum, Erfolg aus der Sicht des Nutzers zu definieren. Zwei Produktmanagerinnen von Atlassian erklären, wie sie das Modell für neue Features bei den populären Tools Jira und Confluence eingesetzt haben.

• In diesem Text lernst Du
• wie Du den Erfolg des Nutzers in den Mittelpunkt stellst.
• wie Du Metriken definierst, die auch das Richtige messen.
• wie Du mit Signals erkennst, ob Du auf dem richtigen Weg bist.
• was Goals, Signals, Metrics von OKRs unterscheidet und wie sie sich ergänzen.

Ein häufiges Problem in der Produktentwicklung ist, dass Teams dazu neigen, den Erfolg ihres Produkts über die Menge neu entwickelter Features zu definieren. Dabei gerät allzu leicht in Vergessenheit, dass es darum geht, den User zufrieden zu stellen. Das Framework aus Goals, Signals, Metrics (GSM) hilft Teams dabei, den Fokus wieder auf die Nutzer zu richten. Im Mittelpunkt stehen drei Fragen:

1. Wie sieht Erfolg für unsere User aus?
2. Wie messen wir diesen Erfolg?
3. Woran erkennen wir, dass unser Produkt die User wirklich unterstützt?

Ein Fehlstart mit Happy End

Isha Mehta war sehr zufrieden mit sich, als die neuen Sprachversionen für Confluence rauskamen. Das beliebte Kollaborationstool zu internationalisieren und damit die Nutzung von Confluence für nicht-englischsprachige Nutzer zu verbessern, war ein Ziel der  Produktmanagerin beim Softwareunternehmen Atlassian gewesen. Als Confluence in zehn neuen Sprachen ausgerollt wurde, schien dieses Ziel erreicht. Dann kamen die ersten Reaktionen der Nutzer auf Twitter rein.

Das harte Feedback hatte sein Gutes. Es erinnerte Isha und ihre Kollegen daran, dass es wichtiger ist, sich in die Lage der Nutzer zu versetzen, anstatt einfach eine bestimmte Anzahl neuer Features rauszuhauen. Um sicherzustellen, dass sich das Sprachfiasko nicht wiederholt, stellten sie ihre Prozesse und ihre Zielsetzung um. Anstelle output-orientierter KPIs trat das System von Goals, Signals and Metrics.

Die Vorteile von Goals, Signals, Metrics

Neben Isha Mehta arbeitet auch Josephine Lee bei Atlassian intensiv mit dem GSM-Framework. Josephine ist Produktmanagerin im Notifications-Team von Confluence und Jira. Beide haben inzwischen eine Fülle an Erfahrungen gesammelt, wie man sich die richtigen Ziele setzt und misst, ob man sich auf dem richtigen Weg dahin befindet, diese zu erreichen. Die Vorteile von GSM liegen für beide auf der Hand:

1. Es zwingt einen dazu, den Nutzer an den Anfang zu stellen, anstatt darüber nachzudenken, welches Feature als nächstes released werden soll.
2. Man ist in der Lage, die eigenen Ziele und Metriken schnell anzupassen, wenn man neue Informationen erhält.
3. Man vermeidet, wochen- oder monatelang auf Metriken zu optimieren, die unerreichbar sind oder nicht wirklich messen, was man messen möchte.

Für Teams, die mit GSM arbeiten möchten, empfehlen Isha und Jo folgende Vorgehensweise.

Wie man Ziele setzt

Zunächst sollte sich das ganze Team über die Mission einig sein. Das ist wichtig, um überhaupt zu verstehen, worauf man hinarbeitet. Isha sagt: „Eine typische Falle, in die Teams immer wieder tappen, ist, dass man Erfolg über Metriken definiert, die auf den Output bezogen sind.

„Wir sind es gewöhnt, auf typische KPIs wie Daily Active Users, Monthly Active Users, Retention oder Conversion Rate zu optimieren.“

Diese Metriken verraten einem nichts darüber, ob man mit einem neuen Feature tatsächlich dem Nutzer weitergeholfen hat. Und es ist auch in der Datenanalyse sehr schwierig nachzuweisen, dass wirklich dieses eine Feature auf die Veränderung einer Metrik eingezahlt hat. Stattdessen definiert man, was für den Nutzer ein Erfolg wäre. Erst im nächsten Schritt klärt man, wie man diesen Erfolg messbar machen kann.

Zehn neue Sprachversionen für Confluence herauszubringen, hat sich für Ishas Team als schlechtes Ziel erwiesen. Es orientierte sich rein am Output. Besser funktionierte es, als sie sich zum Ziel setzten, auch nicht-englischsprachigen Nutzern zu ermöglichen, Confluence für erfolgreiche Zusammenarbeit zu nutzen. Auch wenn der Weg dahin relativ klar ist, sind genug Freiheiten vorhanden, um unterschiedliche Dinge auszuprobieren und zu testen. Zuvor ging es lediglich darum, Sprachversionen von einer Liste abzuhaken. Nun war das Team gefordert sich überlegen, wie man dieses Ziel messbar macht.

Wie man Indikatoren definiert

Nun beginnt der anspruchsvolle Teil: Es gilt die Indikatoren festzulegen, an denen man erkennt, dass man auf dem richtigen Weg ist. Diese Indikatoren können quantifizierbar sein, müssen es aber nicht. Es können auch beobachtbare Verhaltensänderungen sein. Wichtig: Signals sind noch kein Garant für Erfolg. Was sie garantiert anzeigen, ist, wenn man in die völlig falsche Richtung läuft. Anders gesagt: Wenn die Signale auf Rot stehen, ist es ziemlich sicher, dass man noch mal zurück ans Whiteboard muss. Aber nur weil die Signale alle auf grün stehen, heißt das noch nicht, dass man sich bequem zurücklehnen kann.

Im Falle von Confluence waren Signale für eine erfolgreiche Einführung von Sprachversionen, dass

1. nicht-englischsprachige Nutzer auf die neue Sprachversion wechseln und
2. Confluence dauerhaft in der Landessprache benutzen.

Wichtig bei diesen Signalen ist, dass sie noch nicht mit einer exakten KPI versehen sind. Bei den Signals geht es zunächst darum, ein Gefühl für die Nutzer und ihr Verhalten zu entwickeln. Zeit spielt hier eine wichtige Rolle, sagt Isha: “Wir geben uns nach dem Release eines neuen Features immer ein paar Wochen, erstmal Daten und Feedback zu sammeln. Dabei kombinieren wir quantitative Methoden mit qualitativen Nutzerbefragungen.”

Signals sollen anzeigen, ob überhaupt das passiert, was man erwartet hat. Wenn das der Fall ist: Gut. Nun kann man daran arbeiten, die gesetzten Ziele für ein erfolgreiches Feature zu erreichen. Zeigen die Signale hingegen, dass die Nutzer sich nicht verhalten wie erwartet, ist man auf dem falschen Weg und man muss gar nicht erst versuchen, für den Erfolg zu optimieren.

Wie man Erfolgsbedingungen festlegt

Ob ein Feature tatsächlich erfolgreich ist, weiß man erst, wenn man die harten Erfolgsbedingungen erfüllt hast. Wichtig hierbei wieder: Man muss sich fragen, wie Erfolg für den Nutzer aussehen würde? Im Falle der Sprachversionen ging es für das Confluence-Team darum, das Produkt für nicht-englischsprachige Nutzer zu verbessern. Das bedeutet: Die Nutzer sollten nicht nur wechseln, sondern im Idealfall auch dauerhaft bei der neuen Version bleiben. Damit diese Signale zu sauberen Metriken werden, müssen sie nun operationalisiert werden, das heißt mit einer Nummer versehen sein. Isha und ihr Team setzten sich zwei Ziele:

1. Mindestens 30 Prozent der nicht-englischsprachigen Nutzer sollten Confluence in der gleichen Sprache benutzen, in der sie auch den Browser benutzen.
2. Mindestens die Hälfte der Nutzer, die auf eine Übersetzung wechseln, sollten in den nächsten sechs Monaten nicht zurück auf Englisch wechseln.

Entscheidend ist dabei, diese Metriken so festzulegen, dass sie tatsächlich einen Erfolg anzeigen. Sie sollten also nicht zu leicht zu erreichen sein. Gleichzeitig sollten sie nicht völlig utopisch sein, um Frust zu vermeiden. Für das Atlassian-Team wäre es zum Beispiel schlicht unrealistisch gewesen sich vorzunehmen, 100 Prozent der nicht-englischsprachigen Nutzer dazu zu bringen, die neue Übersetzung zu nutzen.

Um auf die richtige Messgröße zu kommen, kann man entweder auf Erfahrungen mit vergleichbaren Produkten oder Features zurückgreifen. Gibt es keine Erfahrungen, empfiehlt Isha aufs Bauchgefühl zu hören: “Es reicht für den Anfang, einfach eine Nummer festzulegen, der man vertraut. Im Laufe des Prozesses wird man merken, ob man richtig hart daneben gelegen hat, oder tatsächlich einen guten Riecher für seine Nutzer hatte.”

Ein zweiter Weg, eine Ausgangsmetrik zu finden, ist eine Art Reverse Engineering aus dem Team heraus, empfiehlt Josephine.

„Man kann das Team fragen, welcher Wert sie enttäuschen würde.“

Die meisten Teams haben ein ganz gutes Gespür für ihrer Nutzer und können gut einschätzen, was realistisch zu erreichen ist, aber trotzdem immer noch eine spannende Herausforderung darstellt.

Im Unterschied zu Signals signalisiert das Erreichen einer Metrik, dass man ein Feature oder Produkt tatsächlich erfolgreich gelauncht hat. Das bedeutet nicht, dass man in diesem Moment die Arbeit komplett niederlegen kann. Aber jetzt ist es erlaubt, den Fuß vom Gas zu  nehmen. Eine gute Metrik sollte sich wie ein wichtiger Meilenstein anfühlen. Ist der erreicht, wird man automatisch über die nächsten Schritte nachdenken. Und der Prozess beginnt im Grunde von vorne.

Ständige Iteration

Ein wichtiger Faktor des GSM-Frameworks ist, dass nichts in Stein gemeißelt ist. Das Ziel, das man erreichen möchte, sollte natürlich stabil sein (ansonsten würde das bedeuten, wieder komplett bei Null anzufangen). Aber Signals und Metrics können sich im Verlauf eines Prozesses verändern. Hier spielt User Feedback eine große Rolle. So kann es passieren, dass man feststellt, dass die Metrik, die man nutzt, um den Erfolg der Nutzer zu messen, nicht wirklich akkurat ist.

Josephine hat mit ihrem Team beispielsweise festgestellt, dass es für Jira E-Mail-Benachrichtigungen nicht ausreichte, die Öffnungsrate zu tracken, um zu überprüfen, ob die Nutzer mit dem Feature zufrieden sind. Manche Benachrichtigungen erfordern eine Reaktion, wie zum Beispiel, wenn man in einem Kommentar erwähnt wurde oder einem ein Task zugewiesen wurde. In diesen Fällen ist eine Nachricht erst dann erfolgreich, wenn der Nutzer den zugewiesenen Task auch tatsächlich angeklickt und ausgeführt hat. Im Laufe des Prozesses veränderten Josephine und ihr Team die entsprechende Metrik mehrmals. Am Ende verständigten sie sich darauf zu tracken, ob Nutzer nach Benachrichtigungen, die eine Aktion veranlassen, auch tatsächlich auf das Issue klicken und mindestens 40 Sekunden auf dem Issue bleiben. Diese Dauer galt als Indikator, dass die Nutzer die gestellte Aufgabe auch tatsächlich annehmen.

Aber vorsichtig: Man kann sich auch zu Tode optimieren, warnt Isha: “Man muss aufpassen, dass man sich nicht in den Metriken verliert. Es hat immer Vorrang, das Produkt oder das Feature zu entwickeln.”

Aufpassen bei Countermetrics

Was man im Blick haben sollte, sind so genannte Countermetrics. Das sind Metriken, die man nicht negativ beeinflussen möchte, nur, um eine andere Metrik nach vorne zu bringen. Es ist für die Nutzer sicher angenehm, wenn man ihnen weniger Email-Benachrichtigungen schickt. Wenn das aber dazu führt, dass die Nutzer weniger aktiv im Produkt sind, ist das kontraproduktiv. Das Ziel, den Nutzern weniger irrelevante Nachrichten zu schicken, sollte nicht dazu führen, dass die Zahl der aktiven Nutzer zurückgeht. Hier gilt es, die richtige Balance zwischen zwei Metriken zu finden.

Abgrenzung und Integration von OKRs

Auf den ersten Blick scheint das GSM-Framework nichts anderes zu sein, als ein leicht abgewandelte Variante von Objectives and Key Results. Man hat ein Ziel, also ein Objective. Und prüft anhand verschiedener Metriken, also Key Results, ob dieses Ziel erreicht wird. Auch OKR-Profis empfehlen, eher output-orientiert zu arbeiten und den User und dessen Verhalten in den Fokus zu nehmen.

Tatsächlich ähneln sich die beiden Frameworks sehr. Es ist aber keine Frage von Entweder-Oder. Isha und Jo glauben, dass sich OKRs und GSM sogar gut ergänzen. Auch bei Atlassian gibt es ein OKR-System. Diese werden vierteljährlich überprüft und orientieren sich am großen, unternehmensübergreifenden BHAG, dem “Big, Hairy, Audacious Goal”.

Goals, Signals, Metrics erlauben es den Teams, losgelöst vom Rhythmus der OKRs Ziele noch enger am Produkt und projektbezogen festzulegen. Während die OKRs aufs große Ganze einzahlen, lassen sich Goals, Signals, Metrics flexibel aufs Tagesgeschäft runterbrechen. Wenn man sich OKRs wie Fixsterne am Firmament vorstellt, an denen man sich orientieren kann, sind GSMs eher die Kometen, denen man mit hoher Geschwindigkeit durchs Sonnensystem folgt.

Unterstützung mit Data Science

Ein weiterer wichtiger Faktor bei GSMs im Unterschied zu OKRs ist, dass sie sehr eng am Produkt sind und fast immer auf einer Hypothese beruhen. “Wenn unsere User XY tun, dann nehmen wir an, dass sie mit dem Produkt zufrieden sind.” Das bedeutet:  “Wann immer möglich, versuchen wir Kollegen aus dem Data Science-Team hinzuzuziehen”, sagt Josephine. Insbesondere bei der Entwicklung der richtigen Metriken zur Erfolgsmessung, hilft es, Experten für die Datenanalyse hinzuziehen. Sonst können leicht typische statistische Fehlinterpretationen passieren, etwa, dass man Korrelation mit Kausalität gleichsetzt. Der beste Weg, sich gegen Fehlinterpretationen und Scheinkorrelationen abzusichern, bleibt aber nach wie vor der Kontakt zum User. “Egal, welche Metrik man misst: Man wird sehr schnell merken, ob es die Falsche ist, wenn man früh mit den Usern spricht”, sagt Jo. Oder, wenn sie einem wütende Tweets schicken.

(Titelfoto: Atlassian)