Als Product Owner haben wir die Aufgabe, den Wert des Produktes zu maximieren. Das ist eine ziemlich breite Aufgabe. Und das schon, bevor man sich bewusst die Frage stellt, was es überhaupt bedeutet, den Wert zu maximieren. Naheliegend wäre eine Optimierung des Gewinns. Das ist aber nicht so einfach, da am Gewinn einige Variablen hängen. Dies kann man in der Entwicklung von digitalen Produkten etwas vereinfachen. Die meisten Kosten, nämlich die der Softwareentwicklung, sind fix. Mit einer Umsatzoptimierung geht also automatisch eine Gewinnmaximierung einher. Doch auch da ist es ziemlich schwierig, das handfest an Features zu knüpfen. Viele Produkte werden von verschiedenen Teams entwickelt und die Geschäftsmodelle sind nicht offensichtlich.

In der Konsequenz behelfen sich Teams häufig mit der Optimierung des gefühlten Wertes des Produktes. “Wir machen es besser für unsere Kunden.” Diese Herangehensweise hat allerdings zwei entscheidende Nachteile. Zum einen kann es sich anfühlen, als würde man durch Treibsand waten, weil die Verbesserung nicht messbar ist. Zum anderen sind Verhandlungen zu Budgets oft schwierig, weil es keine direkte Verknüpfung zwischen gefühltem Wert des Produktes und Return on Invest gibt.

Wir wollen die Featureentwicklung handfester steuern und nutzen dafür die Pirate Metrics. Einige kennen sie vielleicht aus dem Marketing, doch auch in der Produktentwicklung sind sie Gold wert. Sie geben Messpunkte vor, die direkt mit dem Geschäftsmodell zusammenhängen. Mit ihnen kannst Du als Product Owner sichtbar machen, wo das wirtschaftliche Bottleneck Deines Produktes gerade ist. Dies ermöglicht Dir, Features zu priorisieren, die darauf einzahlen, dieses Bottleneck zu optimieren.

Das Business Model quantifizierbar machen

Die Pirate Metrics sind die 5 Metriken Acquisition, Activation, Revenue, Retention und Referral. Ihre Anfangsbuchstaben ergeben den Ruf eines Piraten.

AARRR!

Damit unser Pirat nicht AAURW rufen muss, benutzen wir in diesem Artikel die englischen Begriffe.

Mit diesen 5 Metriken können wir die Wertschöpfung eines Produktes handfester aufteilen. Das funktioniert in allen Geschäftsmodellen. Solltest Du an einem mehrseitigen Geschäftsmodell arbeiten, kannst Du jede Kundenbeziehung einzeln mit den Pirate Metrics abbilden. Im Beispiel eines Marktplatzes hast Du also ein Set an Pirate Metrics für die Anbieter- und eines für die Nachfrageseite.

Bei der Erfassung der einzelnen Metriken kann es sein, dass man verschiedene Zahlen zu Rate ziehen muss. Die Pirate Metrics sind ein vereinfachtes Modell, damit man den Überblick behält. Unser Rat ist, es am Anfang nicht perfektionieren zu wollen. Pirate Metrics sind nur ein Modell. Man kann es für seinen Zweck adaptieren. Das Bottleneck sieht man meist auch mit nicht so perfekten Daten.

Acquisition

Der erste Schritt für den Aufbau einer Kundenbeziehung ist, dass Menschen auf unser Produkt aufmerksam werden. In den Pirate Metrics heißt dieser Schritt Acquisition. Für die Erfassung kommen je nach Produkt verschiedene Zahlen in Frage. Häufig sind es Besucher auf einer Landingpage oder App-Store-Besucher.

Activation

Der zweite Schritt ist die Activation. Sie beschreibt den Zustand, dass Kunden den Wert eines Produktes erleben. Das einfachste Beispiel dafür sind Produkte mit einer kostenlosen Testphase. In dieser Testphase generieren die Nutzer noch keinen Umsatz und können den Nutzen der App am eigenen Leib erfahren.

Beim Herausfinden darüber, was man messen möchte, ist die Activation die anspruchsvollste Metrik. Fragen, die dabei helfen können, sind:

● Wann erfahren Nutzer das erste mal den Wert?
● Ab wann werden Nutzer zu Power-Usern?
● Lässt sich die Value Proposition als Zahl abbilden?

Das ist ein Prozess, an den man sich iterativ rantasten kann. Wenn man diesen Prozess startet, kann man sich mit Registrierungsraten, durchschnittlicher Sessiondauer oder aufgerufenen Seiten behelfen.

Auch wenn Dein Produkt keine Testphase hat, gibt es einen Punkt, an dem Interessenten das Produkt als wertvoll empfinden. Ist das der Fall, solltest Du den Zeitpunkt abbilden, bei dem die Interessenten den Wert Deines Produktes für sich erkennen. Das kann beispielsweise der Fall sein, wenn jemand mehrere Blogartikel auf dem Firmenblog gelesen hat.

Revenue

Im dritten Schritt wird es endlich wirtschaftlich. Kunden machen Umsatz. Nicht in allen Kundenbeziehungen fließt an dieser Stelle direkt Geld. Bei Facebook zahlen Nutzer nicht für die Benutzung, sondern generieren einen Wert durch ihr Engagement. Je mehr sie auf der Plattform interagieren, desto häufiger werden ihnen Werbeanzeigen ausgespielt. In diesem Beispiel würden wir aktive Nutzer unter der Metrik Revenue erfassen.

Retention

Der Kunde hat zum ersten mal Umsatz gemacht. Jetzt stellt sich aus Produktsicht die Frage, wie lange man ihn als Kunden halten kann. Wie häufig wird er das Produkt noch einmal kaufen? Oder wie lange bleibt er Abonnent? Gerade bei Abonnements steckt in der Retention ein großer Hebel zum wirtschaftlichen Erfolg. Um die Retention zu erhöhen, müssen wir dafür sorgen, dass Nutzer sie über einen längeren Zeitraum hinweg als nützlich und hilfreich empfinden.

Die Wichtigkeit der Retention wird insbesondere im Customer Lifetime Value sichtbar. Diesen kann man berechnen, indem man den monatlichen Umsatz (Revenue) mit der Retention multipliziert. So wird ersichtlich, wie viel Umsatz der Durchschnittskunde insgesamt macht.

Eine Schwierigkeit bei der Erfassung der Retention ist es, dass man sie erst im Nachhinein messen kann. Haben wir also ein Produkt mit einer durchschnittlichen Customer Lifetime von 2 Jahren, müssen wir im Zweifel 2 Jahre warten, um eine Veränderung zu beobachten. Um das zu umgehen, behilft man sich mit der Churn-Rate. Diese beschreibt, wie viele Nutzer aufgehört haben, das Produkt zu benutzen. Aus ihr lässt sich näherungsweise die Retention berechnen. So kann man, schon in den ersten Monaten nach dem Launch, Aussagen über die Retention treffen.

Customer Lifetime in Monaten = 1 geteilt durch die Churn Rate

In der App-Entwicklung ist es üblich, die Retention deutlich kleinteiliger zu messen. Dafür nutzt man die D1-, D7- und D20-Retention. Diese beschreiben, wie viele Nutzer nach 1, 7 und 20 Tagen noch aktiv sind.

Referral

Die Referral-Rate beschreibt, wie viele der akquirierten Nutzer (Acquisition) auf Empfehlungen aktueller Nutzer basieren. Dieser Wert ist aus zwei Gründen interessant. Zum einen sorgt eine hohe Referral-Rate für eine günstige Kundenakquisition. Ist die Referral-Rate hoch genug, kann sie sogar für virales Wachstum sorgen. Zum anderen spricht eine hohe Referral-Rate dafür, dass Nutzer so zufrieden mit dem Produkt sind, dass sie bereit sind, es zu empfehlen. Sie sind bereit, ihre eigene Reputation zu riskieren und für das Produkt einzustehen.

Am Anfang der Produktentwicklung empfehlen wir allerdings mit einer Referral-Rate von 0% zu starten. Es gehört viel dazu, für eine signifikante Referral-Rate zu sorgen. Eine zu optimistische Bewertung kann Dich in falscher Sicherheit wiegen.
Bottleneck identifizieren

Um den wirtschaftlichen Erfolg unseres Produktes treiben zu können, müssen wir das aktuelle Nutzerverhalten messen, interpretieren und beeinflussen. Was wir messen müssen, geben uns die Pirate Metrics vor. Der nächste Schritt ist die Interpretation. Die zu beantwortende Frage ist: Welche der Pirate Metrics ist gerade das Bottleneck für unser Geschäftsmodell?

Häufig wird das klar, wenn man die Pirate Metrics das erste Mal erfasst. Über alle Branchen hinweg geht man pauschal von durchschnittlichen Conversion Rates von 10% aus. Das bedeutet, dass man davon ausgeht, dass 10% aller akquirierten Besucher aktiviert werden und 10% aller aktivierten Nutzer für Umsatz sorgen. Diese können allerdings je nach Branche stark abweichen.

Ist man sich bei den Erwartungswerten unsicher, schlagen wir meistens eine andere Herangehensweise vor. Bei dieser bewerten wir, wie einfach eine Verbesserung der einzelnen Metriken ist. Die Pirate Metric, die wir einfach stark verbessern können, ist unser Bottleneck. Zur Bewertung nutzen wir die Kriterien Reach, Impact, Confidence und Ease (RICE).

RICE-Priorisierung von User Stories

Zur wirtschaftlichen Priorisierung müssen wir bewerten, mit welchen User Stories wir, mit möglichst wenig Aufwand und möglichst wenig Risiko, einen hohen Impact haben. Das ist eine Einschätzung mit relativ vielen Stellschrauben, die deutlich einfacher fällt, wenn wir diese einzeln betrachten.

Reach: Für wie viele Nutzer ist das Feature wichtig?
Impact: Wie groß ist der Effekt auf die Pirate Metrics?
Confidence: Wie viel Evidenz haben wir, dass der Impact eintreten wird?
Ease: Wie viel Aufwand ist es, das Feature zu implementieren?

Für eine erste Priorisierung ignorieren wir die Confidence. Das heißt, wir vergeben für jede User Story einen Wert zwischen 0 und 10 für die Werte Reach und Impact. Für die Einschätzung des Ease (Aufwand) können wir Story Points aus einer Magic Estimation nutzen. Nun können wir schon eine erste Priorisierung vornehmen, in dem wir Reach mit Impact multiplizieren und durch Ease teilen. Wenn wir die User Stories nach diesem Scoring sortieren, haben wir das größte wirtschaftliche Potenzial pro Aufwand oben.

Dieses wirtschaftliche Potenzial ist eine Hypothese der Form:

Wir glauben, dass die User Story x für y% unserer Nutzer den wirtschaftlichen Impact z hat.

Was allerdings noch keine Berücksichtigung findet, ist unsere Sicherheit darüber, dass diese Hypothese stimmt. Um dies zu berücksichtigen, ziehen wir die Confidence hinzu. Welche Daten haben wir, um diese Behauptung zu untermauern?

Wie viele Daten haben wir?

Im letzten Abschnitt haben wir die der User Story zugrunde liegenden Hypothesen offengelegt. Die Datengrundlage für diese ist häufig Bauchgefühl in Form von Erfahrung.

Wir empfehlen, die anhand von Reach, Impact und Ease priorisierte Liste von oben nach unten abzuarbeiten. Dabei heißt abarbeiten aber nicht immer die direkte Softwareentwicklung.

Wenn das Verhältnis zwischen dem Invest (Ease) und der Datengrundlage (Confidence) nicht dem Risikoprofil Eurer Firma entspricht, sollte der nächste Schritt nicht die Entwicklung, sondern das Sammeln von Daten sein. In der modernen Produktentwicklung nennt sich das Product Discovery. Es ist wichtig, dass Du Dir dieses Risikoprofils bewusst wirst. Mehr Daten sind nicht immer besser, denn die verlässlichsten Daten bekommst Du im Endeffekt nur durch einen Launch. Ein großes Feature ausschließlich durch Bauchgefühl gestützt zu entwickeln, ist allerdings grundsätzlich nicht zu empfehlen.

Pitfalls bei der Entwicklung nach Metriken

Wir sehen immer wieder, was für einen großartigen Effekt es haben kann, wenn man sich durch Pirate Metrics auf das Wesentliche konzentriert. Doch am Ende des Tages sind auch Pirate Metrics nur nackte Zahlen. Und blind auf diese zu optimieren birgt Risiken, derer man sich bewusst sein sollte.

Key Performance Indicators (KPI) zeigen an, ob eine Maßnahme erfolgreich war. Man sieht aber immer nur ein Was und nicht das Wie oder Warum. Beispielsweise kann ein Anstieg an besuchten Seiten pro Session (das Was) verschiedene Gründe haben. Zum einen kann die App wertstiftender geworden sein und Kunden nutzen sie gerne. Es kann aber auch dadurch begründet sein, dass die Navigation unübersichtlicher geworden ist und Nutzer nur die richtigen Informationen suchen.

Eine weitere Gefahr in der Steuerung durch Pirate Metrics ist die lokale Optimierung. Wenn wir versuchen, die Activation zu steigern und dadurch den Revenue, müssen wir darauf achten, dass die Retention darunter nicht leidet. Wenn wir eine Hypothese definieren, dass sich eine Pirate Metric durch die Feature-Entwicklung verbessert, gibt es immer die implizite Annahme, dass sich die anderen Pirate Metrics dadurch nicht verschlechtern.

Zu guter letzt ist die Sicht auf die Pirate Metrics ausschließlich eine wirtschaftliche Betrachtung. Bei jedem Feature musst Du Dich natürlich in die Lage der Nutzer versetzen und darfst ihre Bedürfnisse nicht außer Acht lassen. Im Prinzip ist aber auch dieser Blickwinkel nur eine andere Facette der Gefahr vor lokaler Optimierung. Die Nutzerperspektive einzunehmen stellt sicher, dass Du keine Entscheidungen triffst, Die Dir langfristig (auch wirtschaftlich) schaden.

Der Prozess im Überblick

Die Pirate Metrics legen offen, ob eine User Story auf das Bottleneck des Produktes einzahlt oder nicht. Wir haben die Erfahrung gemacht, dass es ein leichtgewichtiger Start ist, um mit der Formulierung von Business-Hypothesen zu starten. Diese entfernen den Bias, an schönen Features zu arbeiten, die aber keinen nachhaltigen wirtschaftlichen Effekt haben. Ein Beispiel dafür sind Features, die dafür sorgen, dass das Produkt einfacher zu bedienen ist, obwohl die Neukundengewinnung das eigentliche Bottleneck darstellt. Ist das der Fall, muss man herausfinden, welche neuen Features das Produkt “sichtbarer” oder attraktiver für Neukunden machen. Zusammengefasst ist der Prozess wie folgt:

1. Mappe die Pirate Metrics auf Dein Geschäftsmodell
2. Finde Dein Bottleneck mit AARRR
3. Mappe Features auf die Pirate Metrics
4. Priorisiere Lösungsansätze mit RICE
5. Sortiere Dein Backlog um

Erzähle mir von Deinen Erfahrungen mit der wirtschaftlichen Betrachtung Deines Produktes. Formulierst Du schon Business Hypothesen? Wenn nein, warum nicht? Schreibe mir an f.vosberg@tarent.de.