Produkttipps – Lernen oder Geld verdienen?

Funktionierende digitale Produkte schaffen Wert für die Kunden und generieren Umsatz für den Produktanbieter. Trotzdem sind auch immer wieder Tätigkeiten sinnvoll, bei denen der Umgang mit Risiken und das Lernen im Vordergrund stehen und nicht, Wert zu schaffen bzw. Umsätze zu generieren. Diese Tätigkeiten finden sich auf mehreren Stufen in der Produktentwicklung.

Produktentwicklung ist immer mit Unsicherheiten und Risiken behaftet. Durch Product Discovery-Arbeit versuchen wir, diese Risiken möglichst gut zu reduzieren, bevor wir mit der Entwicklung eines Features beginnen. In manchen Fällen müssen wir aber etwas sehr Kleines bauen, um das Risiko zu bewerten.

Das kann beispielsweise ein sogenannter „Spike“ sein. Dabei handelt es sich um einen technologischen Prototyp, auch gerne „Durchstich“ genannt, um das Feasibility Risk in den Griff zu bekommen. Ihr habt z. B. ein neues Produkt, das sich über Affiliate Links finanziert. Die Kunden klicken in eurem Produkt einen Link an, kaufen etwas auf eure Empfehlung in einem Onlineshop und ihr bekommt eine Provision dafür. So weit, so bekannt. In eurem Fall handelt es sich aber um ein neuartiges Konzept und ihr müsst herausfinden, ob es technisch funktioniert, weil ihr euch sonst einen komplett anderen Monetarisierungsansatz für euer Produkt überlegen müsstet.

Bei cosee haben wir 2020 die Online-Spielemesse „SPIEL.digital“ entwickelt. Damit sich die Online-Variante zum einen wie eine richtige Messe und zum anderen wie ein Brettspiel anfühlt, wollten wir virtuelle Themenwelten als zentralen Einstiegspunkt schaffen. Es war aber nicht klar, ob sich eine solche Optik umsetzen lässt. Können wir die Stände dynamisch anordnen? Lässt sich ein Zoomen und Verschieben wie bei Google Maps umsetzen? Um diese Fragen zu klären, brauchte es ebenfalls einen Spike.

Es gibt also Situationen, in denen wir etwas bauen müssen, um eines der vier Produktrisiken in den Griff zu bekommen oder um eine unserer Produkthypothesen zu überprüfen. In diesem Fall schaffen wir aber keinen Wert für den Kunden. Für unsere Firma steht auch der Erkenntnisgewinn im Mittelpunkt und nicht, mit der Entwicklung Geld zu verdienen. Das Buch „Fifty Quick Ideas To Improve Your User Stories“ beschreibt dieses Konzept auf der Basis von User Storys. Es gibt immer wieder User Storys, deren Implementierungsaufwand sich nicht sinnvoll einschätzen lässt. Manchmal neigen die Teams dann dazu, „Fake Stories“ dafür zu schreiben: „Als Entwickler möchte ich wissen, ob sich die Themenwelten so umsetzen lassen, wie wir es uns überlegt haben.“ Das ist sicherlich nicht im Sinne des Erfinders. Die Autoren des Buchs schlagen vor, stattdessen Storys zu schreiben, deren Ziel ganz offensichtlich der Erkenntnisgewinn ist („Learn“) und nicht, Kundenwert zu schaffen bzw. Geld zu verdienen („Earn“). Für jede Story kann ich also entscheiden, ob ich lernen will oder Wert schaffen – „Build to Learn or Build to Earn“.

Dieses Konzept lässt sich nicht nur auf User Storys anwenden, sondern z. B. auch auf die Schritte in Melissa Perris „Product Kata“, die sie im Buch „Escaping the Build Trap“ (die deutsche Übersetzung heißt „Raus aus der Feature-Falle“) beschrieben hat:

1. Im ersten Schritt der Kata legen wir fest, was unser nächstes strategisches Produktziel ist. Dieses Ziel leiten wir aus der Produktstrategie ab, die wir z. B. mit dem Product Vision & Strategy Canvas beschrieben haben.
2. Nachdem das Ziel klar ist, ermitteln wir, ob wir es bereits erreicht haben. Das ist die gute alte Frage aus dem Familienurlaub von der Rückbank des Autos:„Sind wir schon da?“
3. Wenn wir unser Produktziel noch nicht erreicht haben, überlegen wir uns, was unser nächstes Etappenziel sein soll, um uns schrittweise dem Produktziel zu nähern.
4. Für das Etappenziel wählen wir eine Vorgehensweise: Wollen wir das Nutzerproblem besser verstehen (Problem Exploration), herausfinden was passende Lösungsoptionen wären (Solution Exploration) oder eine gewählte Lösung optimieren (Solution Optimization)?

Im vierten Schritt kann es sinnvoll sein, etwas zu bauen, um daran zu lernen, und nicht, um damit direkt Geld zu verdienen.

So lässt sich das Konzept „Build to Learn or Build to Earn“ auch auf die Auswahl der ersten spitzen Zielgruppe anwenden (erstes Kästchen im dem Product Vision & Strategy Canvas). Im Beitrag „Wählt die Zielgruppe nicht zu groß!“ haben wir gezeigt, dass Produktteams sich am Anfang immer möglichst kleine Zielgruppen vornehmen sollten. Jetzt kann es aber sein, dass es zwei Alternativen dafür gibt. Ihr wollt z. B. eine Event App bauen und habt Studenten oder Event-Veranstalter bzw. jeweils Untergruppen davon als Alternativen. Wenn ihr besonders viel über eure Produkthypothesen lernen wollt, solltet ihr die Studenten näher ins Auge fassen. Sie sind zwar nicht besonders kaufkräftig, aber experimentierfreudig und gerne Versuchskaninchen. Wenn ihr direkt Geld verdienen müsst, ist diese Zielgruppe aus den genannten Gründen aber nicht so gut geeignet.

Am Ende ist es aber immer so, wie einmal einer unserer Startup-Kunden sagte: „Entweder du gewinnst – oder du lernst!“