Was jeder Produktmanager über Produktanalysen wissen sollte

Die Daten aus Produktanalysen zeigen uns, wie die Benutzer das Produkt tatsächlich verwenden.

Sam Tardif Sam Tardif
Browse topics

Als Produktmanager nutzen wir jede Gelegenheit, mehr über unsere Kunden zu erfahren, da wir ihre Anforderungen kennen müssen, um nützliche Produkte zu entwickeln. Wir führen also Kundeninterviews, nutzen Umfragen und beschäftigen uns mit den Ergebnissen der in Produkte integrierten Analysefunktionen. Die Daten aus unseren Produktanalysen zeigen uns, wie die Benutzer unser Produkt tatsächlich verwenden – nicht jedoch, was sie eigentlich tun möchten, wie sie das Produkt ihrer Meinung nach nutzen oder wie sie es unserer Meinung nach nutzen.

Die Softwareentwicklung unterscheidet sich dahingehend, dass hier agile Methoden angewendet werden. Der Hausbau könnte hiervon allerdings sicherlich auch profitieren. Agile Methoden versetzen mehrere Teams in die Lage, schnell auf Änderungen zu reagieren. Doch wie passen langfristige, übergeordnete Planungen in eine agile Methode, die auf Continuous Delivery in schneller Abfolge basiert? Ist es möglich, eine realistische Prognose für einen längeren Zeitraum abzugeben, wohl wissend, dass Veränderung die einzige Konstante ist?

Für einen PM sind Fragen wie "Wie viel Zeit verbringen die Benutzer täglich mit dem Produkt?", "Welche Aktionen werden am häufigsten durchgeführt?" und "Welche Features werden am wenigsten genutzt?" zum Verstehen der Benutzer und als Anhaltspunkte für die Verbesserung der User Experience unglaublich wichtig. In diesem Post werde ich erklären, was Produktanalysen sind und warum du sie nutzen solltest, wie du lernst, deine Benutzer wirklich zu verstehen und somit Einfühlungsvermögen zu entwickeln, und wie du Analysen als Orientierungshilfe für die Entwicklung neuer Features nutzt.

Fangen wir an!

Eine Einführung in die Produktanalyse

Der erste Schritt für ein quantitatives Verständnis davon, wie die Benutzer dein Produkt nutzen, sind Analysen. Dazu sollten bei allen Aktionen, die ein Benutzer mit deinem Produkt durchführen kann, Ereignisse ausgelöst werden. So erhältst du einen Überblick darüber, wie viele Benutzer ein Feature nutzen und wie häufig dies geschieht. Wenn du beispielsweise verfolgen möchtest, wie oft ein Benutzer auf eine bestimmte Schaltfläche klickt, kannst du ein Ereignis namens "Klick-auf-rote-Schaltfläche" auslösen lassen. Auf diese Weise siehst du, an welchen Features gearbeitet werden muss und welche am wichtigsten sind, sodass du anhand dieser Informationen deine Änderungen priorisieren kannst.

Produktanalysen | Atlassian Agile Coach
Profitipp:

Dir stehen unzählige Lösungen zur Verfügung, die dir ein Framework zum Hinzufügen und Verfolgen von Analyseereignissen bieten. Ein guter Einstieg wäre z. B. Google Analytics oder KISSmetrics.

Bei Atlassian haben wir versucht, die Datenerfassung und das Ausführen eigener Anfragen und Berichte so einfach wie möglich zu gestalten. Wir verwenden dafür verschiedene intern entwickelte Tools, aber Standardlösungen wie Google Analytics eignen sich für den Einstieg ebenso. Dank dieser Möglichkeiten stellen nun von den Entwicklern über die Produktmanager bis hin zu den Designern alle Mitarbeiter Fragen zur Nutzung und bemühen sich, die Auswirkungen ihrer Arbeit zu verstehen.

Kundenanalysen: Einfühlungsvermögen ist heutzutage Pflicht

Beschäftigen wir uns ein wenig mit diesem neuen Schlagwort: Einfühlungsvermögen für Kunden.

Im Produkt integrierte Analysen helfen dir in doppelter Hinsicht bei der Entwicklung von Einfühlungsvermögen für Kunden: Du erhältst qualitatives Feedback durch Aktivitäten wie das Testen von Konzepten und Kundeninterviews, du erhältst aber auch quantitative Daten, die im Produkt durch Tools wie Produktanalysen und NPS-Umfragen gesammelt werden.

Confluence gibt es z. B. schon relativ lange, und viele seiner Features verfügen über kaum oder keine Analysemöglichkeiten. Dazu gehört auch das Dashboard, das für die meisten Benutzer der Einstieg in Confluence ist. Wir überarbeiten dies momentan. Zwar haben wir in Kundeninterviews Feedback zum Dashboard erfasst, aber uns fehlen Analysewerte, mit denen wir aus quantitativer Perspektive die Nutzung wirklich verstehen können. Viele Fragen bleiben offen. Ein paar Beispiele:

  • Wie stark wird das Dashboard genutzt? Wie oft wird das Dashboard in einer typischen Confluence-Sitzung aufgerufen?
  • Wofür wird das Dashboard tatsächlich verwendet? Sehen sich die Benutzer den Feed mit allen Updates an? Oder den "Beliebt"-Feed? Navigieren sie zu einem Bereich?
  • Was möchten die Benutzer im Dashboard sehen? Können wir anhand der Aktivitäten direkt nach Besuch des Dashboards bestimmen, bei welchen Aspekten wir auf einen besonders bequemen Zugriff achten sollten?

Dies sind ziemlich grundlegende Fragen, für die wir Antworten benötigen, bevor wir eine der am häufigsten besuchten Seiten in Confluence ändern. Wenn dein Produkt oder ein bestimmtes Feature, das du ändern möchtest, über keine Analysemöglichkeiten verfügt, befindest du dich in derselben Lage und solltest bei der Entscheidungsfindung sehr vorsichtig sein. Es ist höchste Zeit für Kundenanalysen!

In unseren Dashboard-Tests haben wir herausgefunden, dass eine der häufigsten Aktionen auf dem Dashboard das Anzeigen der Favoriten war. Dies war eine enorm wichtige Feststellung, die nicht unbedingt mit unserer ursprünglichen Annahme übereinstimmte. Und nun kommen wir auch schon zur wichtigsten Erkenntnis hieraus: Führe so früh wie nur möglich Kundenanalysen durch – wenn dein Produkt über keine Analysemöglichkeiten verfügt, solltest du diese schnellstmöglich hinzufügen und die daraus gewonnen Daten zur Entscheidungsfindung heranziehen. Andernfalls triffst du wichtige Entscheidungen im Blindflug. Und denke daran, dass Analysen nicht lügen! Sie zeigen uns genau, was die Benutzer mit dem Produkt machen. Du solltest aber noch weiter gehen und die Analysen nutzen, um zu verstehen, was die Benutzer wirklich möchten.

Die Zukunft im Voraus austesten

Produktanalysen können dir helfen, zu verstehen, wie die Benutzer vorhandene Features verwenden. Sie sind aber auch beim Testen neuer Features von großem Wert. Wenn du ein klares Ziel hast, wie stark dein Feature genutzt werden soll, tragen Produktanalysen zur Umsetzung des alten Agile-Mantras bei: Scheitere schnell, und iteriere, bis es klappt.

Der von uns normalerweise verwendete Prozess sieht folgendermaßen aus:

  • Wir formulieren eine klare Hypothese für eine Produktänderung, z. B.: "Durch die Vergrößerung des Kommentarfelds erwarten wir 5 % mehr Kommentare."
  • Wir erstellen eine Implementierung dieser Änderung, die so kostengünstig wie möglich ist und alle benötigten analytischen Ereignisse enthält. Diese nutzen wir nun zum Testen unserer Annahme.
  • Wir stellen die Änderung in einem A/B-Test für eine kleine Kundengruppe bereit.
  • Dann drehen wir Däumchen, während wir auf die Ergebnisse warten.
  • Sobald wir die Ergebnisse erhalten haben, schlüsseln wir diese im Falle von komplexeren Änderungen mit der Hilfe eines Analysten auf und entscheiden, ob die Änderung erfolgreich war.

Im Zuge der Änderungen am Dashboard haben wir letztlich drei Dashboards konzipiert, die sehr stark auf jeweils einen Use Case und bestimmte Verhaltensweisen ausgerichtet waren. Dann haben wir den obigen Prozess auf diese drei Dashboards angewendet (unsere Hypothese war allerdings ein wenig komplizierter), und wir waren sehr zufrieden mit dem Ergebnis. Dabei haben wir allerdings teilweise hohes Lehrgeld bezahlt und einige Lektionen gelernt, die du berücksichtigen solltest, bevor du neue Features auf diese Weise testest.

Einige Anti-Pattern, die vermieden werden sollten:
  • Es gibt nichts Schlimmeres, als zum Ende eines Experiments zu kommen und festzustellen, dass du nicht über alle benötigten Ereignisse verfügst. Führe die Analysen daher mit Pseudodaten durch, bevor du das Experiment beginnst, damit du Lücken in deiner Datenerfassung entdeckst.
  • Die Formulierung einer Hypothese vor einem Test kann zeitaufwendig sein, aber sie ist unabdingbar und muss mit den vorhandenen Produktanalysen belegbar bzw. widerlegbar sein. Eine Analyse mit Pseudodaten vor Testbeginn ist hier ebenfalls hilfreich.
  • Führe deine Tests unbedingt mit genügend Benutzern und über einen ausreichend langen Zeitraum durch. Die Ergebnisse sollen schließlich statistisch relevant sein.
  • Sei bereit, schlechte Ideen zu verwerfen! Wie bereits gesagt, solltest du Features so kostengünstig wie möglich testen und diese Tests so schnell wie möglich ausführen. Schnelles Scheitern ist gut.

Vergiss nur nicht, deinen Benutzern zuzuhören.

Es ist also gut, über möglichst viele Informationen aus Daten zu verfügen, aber sich nur an diesen Daten zu orientieren, kann manchmal den Blick für die User Experience im Ganzen verstellen. Sich vollkommen auf Daten zu stützen, kann auch bei der Entscheidungsfindung hinderlich sein, da möglicherweise nicht alle erforderlichen Daten vorhanden sind.

Agile Produktanalysen | Atlassian Agile Coach

Produktanalysen bringen zwar die nackte Wahrheit der Produkt- oder Feature-Nutzung ans Licht, sind aber manchmal sehr eindimensional. In Kombination mit qualitativem Feedback aus Kundeninterviews, Workshops zum Testen von Konzepten und Sparring sorgen die Erkenntnisse aus Produktanalysedaten für ein vollständigeres Bild, vor dessen Hintergrund du das bestmögliche Produkt erstellen kannst.