Wie man die idealen Kennzahlen für ein agiles Produkt definiert

Entwickeln wir als Team in die richtige Richtung? Haben wir im Sinne unserer Stakeholder die richtigen Anforderungen priorisiert? Wie stelle ich sicher, dass unsere Lösungen auf die Erfüllung der Anforderungen zielen? Genau hier müssen Kennzahlen ins Spiel gebracht werden. Wählt man diese mit Bedacht, kann man im Rahmen von regelmäßigen Feedbacks bestmögliche Lösungen erreichen. Die Geschwindigkeit der Erreichung des angestrebten Mehrwerts ist erst dann ideal.

Kennzahlen als Allerheilmittel?

Nein, Kennzahlen können immer nur unterstützen. Nichtsdestotrotz sind sie unheimlich hilfreich. Sie sollten einen großen Anteil an der Entscheidungsfindung ausmachen.

Warum man sich nicht ausschließlich auf Kennzahlen verlassen sollte, ist recht einfach an einem Beispiel erklärt. Hätte man zwischen 2007 und 2009 verschiedenste Menschen gefragt, ob sie ein Gerät kaufen würden, welches etwas größer als ein Mobiltelefon ist und etwas kleiner als ein Laptop, aber ohne Tastatur – was wäre wohl rausgekommen? Das Interessante ist: genau diese Frage wurde von Marktforschungsinstituten mehrfach gestellt. In über 95% der Fälle sagtendie Befragten aus, dass sie an einem solchen Gerät nicht interessiert sind.

Trotzdem baute Apple das iPad. Schaut man sich heutzutage um, gibt es kaum noch einen Haushalt, in dem kein Tablet zu finden ist. Das bedeutet im Umkehrschluss, dass man sich auch auf das Bauchgefühl verlassen muss. Dabei ist wichtig zu erwähnen, dass Apple diese Bauchentscheidung durch sinnvolle Kennzahlen begründen konnte. Fakt ist somit: damit war es keine Bauchentscheidung. Man hatte sich einfach andere, treffendere Kennzahlen angeschaut als bloße Marktumfragen.

Was sind gute Kennzahlen in der agilen Entwicklung?

Diese Übung machen wir bei unseren Scrum Product Owner Trainings regelmäßig. Die Teilnehmer müssen sich eine x-beliebige App überlegen und diese durch eine möglichst griffige Product Vision greifbar machen. Gleichzeitig sollen sie in der Praxisübung den Scope und möglichst gute Kennzahlen definieren. Diese sollen den Produktentwicklungsprozess steuern können.

Oftmals werden dann KPIs wie Anzahl der Downloads, Bewertungen, Umsatz, etc. genannt. Diese sind prinzipiell nicht schlecht oder falsch. Sie helfen jedoch überhaupt nicht bei der Entwicklung oder Validierung von einzelnen Entwicklungsschritten. Im schlimmsten Fall werden mit ihnen sogar falsche Entscheidungen getroffen. Die Gefahr durch solche Kennzahlen unsere Strategie aus dem Auge zu verlieren oder unwissentlich zu verändern ist groß.

Gehen wir davon aus, wir würden eine App entwickeln wollen, mit der man beim Wandern die Pflanzen am Wegesrand auswerten könnte. Ich könnte also mit der App meine Kamera aktivieren und auf dem Bildschirm würde mir kurz darauf alles Wissenswerte über die Pflanze angezeigt werden. Wie sie heißt, ob sie unter Naturschutz steht, ob man sie pflücken oder gar essen darf. Einfach alle wissenswerten oder wichtigen Informationen.

Auch Buchempfehlungen auf Amazon könnten dazugehören. Oder Rezepte auf Chefkoch.de und welche Nährwerte diese bei 100g hat. Vielleicht würde sie mich auch direkt zur nächsten Alm navigieren, wo es ein ganz tolles Hüttengericht mit dieser Pflanze als Gewürz gibt.

Wie würden uns jetzt die genannten Kennzahlen helfen? Die richtige Antwort lautet: kaum. Sie sind einfach zu global und helfen mir als Product Owner nicht bei der Priorisierung. Doch was wären gute Kennzahlen?

Definiere die User Gruppen

Roman Pichler hat ein vereinfachtes Canvas Board entwickelt und es Product Vision Board genannt. Es ist ist sehr einfach und hilft ungemein, die verschiedenen Stakeholder zu identifizieren. Die erste Frage, die wir uns stellen müssen ist: wer ist eigentlich der Kunde?

Es gibt einen sehr richtigen Ausspruch im Englischen: If something is free, you‘re not the customer. You‘re the product!

Wir müssen uns also bei dieser App Gedanken machen, wie man mit der App Geld verdienen kann. Auch ist es wichtig zu überlegen ab wann damit Geld verdient werden soll. Wenn man die App nicht zum Geldverdienen entwickelt, sondern als Wissenstool für Wanderer (z.B. könnte der Auftraggeber der Naturschutzverbund sein), dann wäre das eine völlig andere Perspektive.

Die Frage ist also, wer ist später der Kunde und wer der User? Das muss nicht immer der gleiche Personenkreis sein. Und in fast allen Fällen gibt es nicht „den User“. Es gibt eine Vielzahl von verschiedenen Usern, die aus unterschiedlichsten Interessen heraus die App benutzen werden.

Will man mit User Stories arbeiten, wären dass in diesem Rahmen die Persona, die man möglichst klar definieren und voneinander abgrenzen sollte.

Entwickle eine Produktstrategie

Gehen wir in unserem Beispiel davon aus, dass die Wanderer die App kostenfrei nutzen dürfen. Zumindest zu Beginn ist es nicht geplant, die App zu verkaufen. Und gehen wir davon aus, dass wir zwar etwas Entwicklungsbudget haben, uns aber doch möglichst zeitnah refinanzieren müssen.

Wir müssen uns also Kennzahlen überlegen, die uns dabei helfen, unseren eigentlichen Kunden einen Mehrwert zu verschaffen. Also: wer könnte unser Kunde sein? Zum einen könnte das der angesprochene Naturschutzverbund sein, der unbedingt die Wanderer über die regionale Flora und Fauna aufklären möchte.

Zum Anderen könnten das aber auch lokale Geschäfte sein, denen wir als Affiliate neue Kunden zuspielen. Es könnten auch digitale Plattformen sein, die ihr Geschäft wittern. Oder gar Schulen oder andere Bildungseinrichtungen, die damit gezielt ihren Schülern einen interessanteren Biologieunterricht bieten wollen.

Als Product Owner müssen wir jetzt überlegen auf welche Kunden wir uns zu Beginn fokussieren wollen. Wo sehen wir das größte Potential und wie können wir es realisieren? Fakt ist auch, dass wir die Antwort nicht wissen. Wir müssen also schnellstmöglich erste Lösungen (MVPs) entwickeln. Der Fokus liegt darauf so früh wie möglich unsere Thesen zu prüfen.

Beispiel für gute Kennzahlen

Sagen wir, dass wir uns jetzt auf die Schulen konzentrieren wollen. Welche Kennzahlen wären jetzt interessant?

Wie viele Pflanzen haben wir in der Datenbank, die der Lehrer im Unterricht besprechen könnte?
Anzahl der Schüler, die unsere App aktiv nutzen und wie oft im Schnitt (täglich, wöchentlich)?
Kann ein Lehrer seine Klasse als User-Gruppe schnell genug anlegen?
Ist der Export der gewünschten Auswertungen schnell genug?
Wie viele Klassen wurden angelegt und wie viele sind aktiv (Ist die Lehrerin von der App überzeugt?)
Anzahl der Schulen, die die App einsetzen
Dauer, bis die App eine Pflanze erkennt
Dauer, bis alle relevanten Informationen bereit gestellt werden (z.B. inklusive Fotos)
Abdeckung der Regionen, wo unsere App einwandfrei funktioniert (Thema Datenverbindung, Datenvolumen und Empfang)
Navigationsverhalten (wie oft „verirrt“ sich der User in der App)
usw.

Auf Basis dieser ersten beispielhaften KPIs könnte man mit der Entwicklung starten und dann über Feedback die nächsten Anforderungen einsammeln. Diese wiederum könnten neue Kennzahlen in den Fokus rücken, die wir aktuell noch gar nicht auf dem Schirm haben.

Kennzahlen haben (teilweise) eine zeitlich limitierte Relevanz

Das bedeutet, Kennzahlen sind temporär. Während unserer Entwicklungszeit definierte KPIs, können später im Entwicklungsprozess für nicht so wichtig erachtet werden. Andere Kennzahlen werden uns hingegen während des gesamten Produktlebens begleiten.

Am Anfang wird uns in unserem Beispiel sicherlich die Größe und Qualität der Pflanzendatenbank beschäftigen. Doch irgendwann haben wir so viele Pflanzen im System, dass wir uns dann ggf. auf andere Dinge konzentrieren können.

Andere Kennzahlen, werden uns wohl immer begleiten. Zum Beispiel die Anzahl der aktiven Schüler und Lehrer. Übrigens, hätten wir uns zu Beginn für eine andere User Gruppe entschieden, wären unter Umständen komplett andere Kennzahlen in den Fokus gelangt. Nicht selten entstehen daraus dann auch weitere Produktversionen – teilweise Whitelabel-Produkte oder sogar komplett neue Marken.