Gutes Scope Management heißt auch: Scope so strukturieren, dass man frühzeitig realistisches Feedback einholen kann. Nicht nur Feedback hinsichtlich der Qualität des Codes, sondern auch hinsichtlich des zu erwartenden Nutzens. Ich will das heute mal an einem Beispiel erläutern: Auf der Detailsseite zu einem Produkt sollen weitere Produkte zum Kauf empfohlen werden, es geht also um eine “Recommendation Engine” für unseren Webshop.

Wonach kann man diese Empfehlungen machen? Da gibt es viele Möglichkeiten. Man kann nach Produkteigenschaften gehen, also für einen grünen Rock einfach weitere grüne Röcke vorschlagen. Oder, das wohl bekannteste Verfahren, Warenkörbe auswerten: Kundinnen, die grüne Röcke gekauft haben, haben auch weiße Handtaschen gekauft. Wenn man eine Fachabteilung fragt, wird sie sich wahrscheinlich alle denkbaren Möglichkeiten wünschen. Besonders, wenn das Budget nur einmal im Jahr freigegeben wird, bestellt man im Fachkonzept lieber alles auf einmal.

Diese Fragen sollten im Konzept unbedingt beantwortet werden:

• Wie messen wir den Erfolg des Projekts?
• Wie können wir frühzeitiges Feedback einholen?
• Wo sind Optionen zum vorzeitigen Abbruch?

Für den Erfolg einer Recommendation Engine kann man verschiedene Metriken ansetzen:

• Umsatz, der mit Artikeln aus der Empfehlung gemacht wurde, abzüglich Retouren. Das wird den Mehrumsatz überschätzen, weil dieselben Artikel ja auch ohne Empfehlungen im Warenkorb landen könnten.
• Analog für den Deckungsbeitrag.
• Anzahl angenommener Empfehlungen, d.h. empfohlene Artikel, die im Warenkorb gelandet sind. Das ist zwar ungenauer, könnte aber einfacher zu realisieren sein.
• A/B-Test: mit Empfehlungen vs. ohne Empfehlungen. Das ist eine realistische Bewertung: Wir lassen z.B. 50% der Besucher ohne Empfehlungen (Variante A) und die anderen 50% bekommen Empfehlungen zu sehen (Variante B). Weil wir den Besucherstrom abwechselnd auf A und B leiten, werden andere Einflüsse (Wochentag, Wetter, Marketingkampagnen) kompensiert.

Frühzeitiges Feedback ist wichtig, weil wir so unsere (immer begrenzten) Mittel sinnvoll konzentrieren können. Dazu sollten wir uns immer fragen: Wie können wir so früh wie möglich Feedback bekommen? In der Lean-Startup-Bewegung hat man das verinnerlicht: Wie erfahre ich möglichst früh, ob überhaupt jemand mein neuentwickeltes Produkt haben will? Dazu erstellt man ein “Minimum Viable Product” (MVP), das gerade genug Funktionalität hat, um am Markt Feedback zu bekommen. Das MVP ist oft überraschend klein, meist viel kleiner als man zunächst denken würde.

Für unsere Produktempfehlungen sollten wir das Projekt so aufbauen, dass wir eine ganze Reihe von Feedback-Zyklen durchlaufen können, statt nur eine einzige Maximalvariante zu implementieren und ganz am Ende zu testen. Für den ersten Feedback-Zyklus können wir gewissermaßen mit zwei MVPs starten:

• Die primitivste Methode für Empfehlungen: Der Algorithmus wählt drei Artikel zufällig aus und präsentiert sie als “Das könnte Sie auch interessieren”.
• Die beste Empfehlung, die wir derzeit kennen: Ein Experte wählt drei passende Artikel manuell aus.

Die erste Methode (zufällige Auswahl) ist nicht nur sehr einfach zu implementieren. Sie gibt uns auch die erste Messlatte: alle weiteren Methoden sollten signifikant besser sein.

Ich weiß nicht, ob man eine sorgfältig gemachte manuelle Empfehlung mit einem automatisierten Verfahren überbieten kann. Wir sollten es auf jeden Fall versuchen. Das wird also unser Benchmark: Ein Algorithmus, der manuelle Empfehlungen signifikant übertrifft, ist richtig gut.

Manuelle Empfehlung wird wahrscheinlich nicht für alle Artikel möglich sein, es heißt dann “That won’t scale”. Zum Vergleich: der Adidas Onlineshop hat “über 7000 Produkte”. Wir könnten einfach eine zufällig gewählte Teilmenge von 200 Podukten manuell bearbeiten, um damit eine Grundlage für Tests zu haben.

Obwohl: man sollte die manuelle Empfehlung nicht voreilig verwerfen. Derek Sivers hat als CEO bei CD Baby anfangs alle neu hereinkommenden CDs persönlich mit Empfehlungen versehen. Als es dann 100 Alben pro Tag waren, haben sie jemanden in Vollzeit eingestellt, um sich das anzuhören. Mit ein bißchen Unterstützung kann man bestimmt 10 Produkte pro Stunde mit Empfehlungen versehen, das wären dann einmalig 700 Stunden Zeitaufwand für den ganzen Adidas Onlineshop.

Übrigens: Die Alternative “es von Hand machen” wird oft voreilig ausgeschlossen, analog zum Make or Buy Test für gutes Scope Management können wir formulieren:

Wenn das Scope Management nicht zugunsten einer manuellen Lösung entscheiden kann, dann ist es nicht hoch genug angesiedelt.

Wir machen also die beiden Minimalvarianten (zufällige und manuelle Empfehlungen) zuerst, um so frühzeitig eine Recommendation Engine im Produktivbetrieb zu haben. Das hat etliche Vorteile:

• Messbarkeit wird frühzeitig verankert. Da wir schon die Baseline messen (zufällige und manuelle Empfehlungen), haben wir wenn’s ernst wird alle Mittel, um z.B. A/B Tests zu machen. Wir haben uns auch darüber verständigt, woran wir genau den Erfolg messen wollen. Für schnelle Experimente reicht vielleicht schon die Anzahl akzeptierter Empfehlungen.
• Wir können das Potenzial abschätzen. Wenn die besten (manuellen) Empfehlungen uns 5% Mehrumsatz bringen, ist klar, wieviel wir in dieses Thema maximal investieren sollten. Das Feature “Empfehlungen” wird somit vergleichbar zu anderen Optimierungen, wie z.B. Ladezeit der Webseiten verkürzen.
• Es gibt einen Maßstab für spätere Verbesserungen. Alles, was später an Extras dazu programmiert wird, muss mindestens so gut wie die zufälligen Empfehlungen sein (klingt, als wäre das leicht zu erreichen, ist es aber nicht immer). Auch später gibt es immer einen aktuellen “Gewinner-Algorithmus”, an dem sich die Verbesserungen messen lassen müssen. Dasselbe gilt für irgendwelche dazugekauften AI-basierten Lösungen. Statt sich eine PowerPoint-Verkaufspräsentation anzusehen, kann man die Lösung einfach eine Woche parallel laufen lassen.
• Wir können auf unerwartete Probleme frühzeitig reagieren. Auch die besten manuellen Empfehlungen bringen kaum Mehrumsatz? Vielleicht sind sie auf der Seite falsch platziert? Oder die Ladezeit wird so lang, dass vorzeitige Kaufabbrüche den Mehrumsatz zunichte machen?
• Wir können unerwartete Erfolge ausnutzen. Es kann ja sein, dass wir schon weit vor Projektende eine Recommendation Engine haben, die wesentlich besser ist als der status quo. Dann könnten wir, statt den Algorithmus weiter auszufeilen, dieselben Empfehlungen auf das Email-Marketing ausdehnen.
• Wir können andere Aspekte der Gesamtlösung optimieren. So können wir auch schon in der primitiven Ausbaustufe mit der Platzierung der Empfehlungen experimentieren.
• Wir bekommen Optionen zum vorzeitigen Abbruch. Vielleicht ist ja die manuelle Empfehlung schon so gut und günstig zu haben, dass wir auf die anderen Ausbaustufen verzichten können? Auch später können wir fast jederzeit abbrechen und wissen genau, was wir bekommen: den aktuellen “Gewinner-Algorithmus” mit belastbaren Kennzahlen zu seinem Nutzen.
• Es gibt einen Anreiz, die Architektur auf der IT-Seite besser zu strukturieren. Weil wir schon am Anfang zwei Lösungen miteinander vergleichen wollen, wird die Umsetzung auf Unterstützung von Experimenten, statt einer einzigen vorgegebenen Lösung, ausgerichtet sein. Auch werden die Entwickler motiviert, das System zu modularisieren. Man sollte z.B. die Auswahl empfohlener Produkte ganz unabhängig machen von der Präsentation der Empfehlungen.

Apropos Feedback: Haben Sie auch schon mal erlebt, dass eine eher “primitive” Ausbaustufe eines Features überraschend effektiv war? Antworten Sie einfach auf diese Email.

Matthias Berth