Relaunch vermeiden: Warum es so schwer ist und wie es trotzdem klappen kann

Nahezu jedes etablierte Unternehmen hat bereits die schmerzliche Erfahrung eines Relaunches gemacht. Dabei ist die Strategie, einen Relaunch zu vermeiden, denkbar einfach und wird in diesem Artikel vorgestellt. Allerdings erfordert diese Strategie große Disziplin – vor allem, da sie Verzicht auf kurzfristige Umsätze bedeutet. Langfristig gesehen lohnt sie sich trotzdem.

Kontinuierliche Produktentwicklung ist notwendig

Online-Geschäftsmodelle müssen kontinuierlich weiterentwickelt werden, damit das Produkt weiterhin im Markt gegen die Konkurrenz bestehen kann. Neue Features werden kontinuierlich benötigt, um weitere Zielgruppen zu erschließen oder neue Erlösmodelle aufzubauen.

Ein simples Beispiel ist der Einbau der Funktion zum Teilen von Inhalten auf Facebook, um mehr Kunden über diesen Kanal zu generieren. Sehr viel komplexer wird es hingegen, will man beispielsweise ein neuen Label „Plus/Premium-Angebot“ einführen, mit dem man solche Kunden ansprechen möchte, die gesteigerten Wert auf ein gutes Preis-/Leistungsverhältnis legen: Ein solches neues Label muss selbstverständlich an verschiedenen Stellen in das bereits vorhandene Produkt eingepasst werden. Die Integration neuer Technologien wiederum kann weitere interessante Features ermöglichen: Zum Beispiel lassen sich dann Ergebnislisten  ohne Seitenreload aktualisieren, die Seite reagiert automatisch auf verschiedene Geräte beziehungsweise Displaygrößen und vieles mehr. Und natürlich werden zugleich vorhandene Funktionalitäten auf Basis der tatsächlichen Nutzung stetig verbessert und weiterentwickelt.

Kurzum: Die Notwendigkeit das Produkt ständig zu verbessern, ist mittlerweile in (fast) alle Unternehmen der Onlinebranche vorgedrungen.

Änderungen blockieren zukünftige Weiterentwicklungen

Durch diese permanenten Änderungen am Produkt lässt sich früher oder später eins kaum noch vermeiden: der Relaunch. Da helfen auch agile Methoden nicht viel. – Etablierte Unternehmen stehen möglicherweise bereits vor dem zweiten oder dritten Relaunch. Dadurch macht sich intern eventuell eine gewisse Ernüchterung breit. Denn aus Business-Sicht bedeutet ein Relaunch vor allem Ressourcen-Einsatz für Umbaumaßnahmen ohne einen kurz- bis mittelfristig messbaren, signifikanten Mehrwert für den Kunden zu generieren.

Dass Online-Unternehmen es nicht schaffen, dem Relaunch zu entkommen, entsteht im Wesentlichen aus zwei Quellen:

• Um weitere Zielgruppen zu erschließen oder neue Erlösmodellen aufzubauen, sind größere Programmierarbeiten notwendig.
• Der Zeitpunkt, in dem neue Technologien ohne viel Aufwand ausprobiert werden können, wird häufig verpasst. Der Grund dafür: Bei einer neuen Technologie ist der Wert fürs Geschäft oft noch nicht zu erkennen. Deshalb wird sie als weniger wichtig priorisiert und tritt erst wieder auf dem Plan, wenn ein Business Value erkannt wird. Doch dann ist die Implementierung meistens bereits mit höheren Kosten, sprich größerem Entwicklungsaufwand, verbunden.

Um nun diese größere Programmierarbeiten (gilt sowohl für neue Produktfeatures als auch für neue Technologien) zu managen und möglichst effizient umzusetzen, setzen Unternehmen auf das Konzept des MVP (Minimum Viable Product = Problemlösung mit minimalem Umfang).

Dieses Konzept kennt man vor allem aus dem Umfeld der „Lean Startup“-Bewegung. Christian Häfner hat in einem UPLOAD-Artikel über seine Praxiserfahrungen mit der Lean-Startup-Methode berichtet. Die Befürworter des Lean Startup empfehlen, so früh es nur geht mit einem Produkt, einem Prototypen oder vielleicht sogar nur mit einer Landing Page herauszukommen.

Aus Business-, Produkt- und auch Development-Sicht ist dies die präferierte Herangehensweise. Im Sinne von agiler Entwicklung lassen sich schnell Daten darüber sammeln, wie gut die eigene Idee tatsächlich ist, ob die Umsetzung in die richtige Richtung geht und welche Wünsche die ersten Nutzer äußern.

Allerdings gilt hier auch: Time-to-market schlägt technische Exzellenz. Das bedeutet: Es wird bewusst in Kauf genommen, dass so genannte „Technical Debt“ (technische Schuld) und/oder „Product Debt“ (Produkt Schuld) entsteht. Darunter versteht man, dass die technische Qualität oder die generelle Produkt-Qualität noch nicht auf dem definierten oder gewünschten Niveau ist.

Der Nachteil der MVP-Herangehensweise: Schulden blockieren zunächst die zukünftige Weiterentwicklung des Produkts oder des Features. Das ändert sich erst, wenn die Schulden zurückgezahlt sind, also der Funktionsumfang und die Qualität den Plänen und Ansprüchen genügen. Im Idealfall passiert das Zurückzahlen der Schulden zeitnah nach dem Livegang. Für diese Arbeiten werden jedoch in Startups genauso wie auch in etablierten Unternehmen recht häufig keine oder nicht ausreichend Ressourcen bereitgestellt. In der Folge werden die Schulden nie ganz abgetragen. Nehmen die durch Schulden blockierten Bereiche überhand, kann das Produkt in keine Richtung mehr weiterentwickelt werden.

Es kommt zum Stillstand. Als einziger Ausweg bleibt: der Relaunch.

Exkurs: Das Relaunch-Frühwarnsystem „Debt-Map“

Fragen Sie sich gerade, wie dicht Sie bereits an einem notwendigen Relaunch sind? Um das zu evaluieren, kann eine „Debt-Map“ helfen. Dazu eine rudimentäre 5-Schritte-Blaupause:

1. Debt zusammentragen. Auch wenn es etwas Aufwand bedeutet, lohnt es sich, jede User-Story seit dem letzten Relaunch, mindestens aber der letzten 12 Monate, noch einmal anzuschauen. (In der agilen Entwicklung beschreibt eine „User-Story“ eine umzusetzende Funktionalität aus der Sicht des Nutzers. Man formuliert sie also so, wie der fiktive Nutzer seinen Wunsch artikulieren würde.) Dabei sollten Sie kritisch hinterfragen, ob Debt durch Umsetzung der jeweiligen User-Story entstanden ist. Unabhängig davon können die Entwickler ergänzen, wo sich weitere Debt versteckt. Jede gefundene Debt wird eine neue User-Story.
2. Aufwand und Schmerz-Faktor schätzen. Der Aufwand („Effort“) der einzelnen gesammelten Debt-Stories wird nun im Team geschätzt. Ob zur Abschätzung T-Shirt-Größen (XS, S, M, L, XL, …) oder Story-Points (1, 2, 3, 5, 8, 13, …) verwendet werden, ist zunächst zweitrangig. Es sollte lediglich die gleiche Metrik verwendet werden, die Sie für die übrigen, „normalen“ Feature-User-Stories nutzen. Zusätzlich wird der Schmerz-Faktor („Pain“) der einzelnen Debt geschätzt, also die Größe des blockierten Bereichs. Hierbei ist eine Unterteilung in klein/mittel/groß ausreichend.
3. Geschäftsmodell unterteilen. Als Nächstes wird das Geschäftsmodell in einzelne Bereiche zerlegt. Hierzu ist es hilfreich so zu tun, als ob man es ein zweites Mal aufbauen würde. Hierbei spielen „Epics“ eine Rolle: Darunter versteht man Anforderungen auf einer höheren Abstraktionsebene, die zur Umsetzung dann detaillierter in die schon genannten User-Stories zerlegt werden können. Die Epics entstehen aus einzelnen „Use Cases“: einzelne Anwendungsfälle; z.B. Produkt kaufen, Produkt inserieren, Kundenanfrage an Support stellen, usw.
   Für einen Onlineshop könnten die ersten frontendseitigen Epics sein: „Startseite mit Suchmaske“, „Ergebnisliste“, „Filter und Sortiermöglichkeiten“, „Produktdetails“, „Warenkorb und Checkout-Prozess“, „Payment“ usw.
   Backendseitig wären zum Beispiel denkbar: „Manuelles Produkt inserieren“, „Schnittstelle zu Partner XY“, „Produkt Freischaltungsprozess“, „Kundenselektion für CRM-Newsletter“, usw.
4. Epics bewerten. Jedes Epic wird aus Unternehmenssicht bewertet, ob es innerhalb des nächsten strategischen Horizonts weiterentwickelt werden soll. Hier reicht eine einfache Unterscheidung zwischen „Ja“ und „Nein“ aus.
5. Debt einzelner Bereiche zuordnen. Die Epics bilden die einzelnen Bereiche, denen die Debt-Stories nun zugeordnet werden. Mehrfachzuordnungen sind möglich; sollten jedoch die Ausnahme bleiben. Häufige Mehrfachzuordnungen sind ein Indiz, dass das Geschäftsmodell nicht ausreichend in einzelne Epics zerlegt wurde.

Auf der Debt-Map können Sie dann ablesen, wie stark das Gesamtgeschäftsmodell mit Debt belastet ist, welche Bereiche besonders stark betroffen sind und ob belastete Bereiche für die nächsten strategischen Ziele weiterentwickelt werden müssen. Grenzwerte, ab denen sich ein Produkt im Relaunch-kritischen Bereich befindet, sind äußerst subjektiv und variieren je nach Geschäftsmodell. Aber Sie bekommen auf diese Weise einen sehr viel besseren Überblick, wie dicht Sie sich bereits einem Relaunch angenähert haben.

• Hier können Sie sich eine fiktive Debt Map als PDF herunterladen…

Ausweg: Disziplin bei der Ressourcenzuteilung

Und jetzt eine gute Nachricht: Einem Relaunch kann man auf denkbar einfache Weise dauerhaft entgehen. Zumindest in der Theorie. Denn stehen stets genügend Ressourcen zur Verfügung, um die im Entwicklungszyklus N entstandenen Schulden im Entwicklungszyklus N+1 zurückzuzahlen, bleibt die Debt-Map sauber. Produktmanagement und Entwickler können das Produkt in dieser Situation ohne Einschränkungen weiterentwickeln. Ein Relaunch ist und bleibt auch in Zukunft nicht notwendig.

Dabei ist eine solche dauerhafte und ausreichende Ressourcen-Zuteilung für „Debt zurückzahlen“ und „neue Technologien ausprobieren“ auch aus Sicht des Unternehmens in Summe günstiger. Denn spätestens wenn sich der Relaunch nicht mehr vermeiden lässt, wird ohnehin der Aufwand für das Zurückzahlen der aufgelaufenen Schulden fällig. Außerdem kommt aber zusätzlicher Aufwand durch die Komplexität des Relaunch-Projekts hinzu. Dieser Zusatzaufwand ließe sich bei einem kontinuierlichen Zurückzahlen vermeiden.

Um das zu erreichen, hat sich die folgende Ressourcen-Dreiteilung bewährt:

• 70% für Feature-Entwicklungen im Tagesgeschäft
• 20% um Debt aus letztem Entwicklungszyklus zurückzahlen
• 10% um neue Technologien frühzeitig erproben

Der Markt lockt mit kurzfristigem Umsatz

Soweit zur Theorie. In der Praxis funktioniert diese Strategie äußerst selten, da sie von allen Beteiligten große Disziplin abverlangt und das besonders von den Businessverantwortlichen. Schnell kommt da beispielsweise eine neue Marketing-Aktion in die Quere, die sofort stattfinden muss und deren Umsetzung bisher nicht geplant war. Kurzfristig lässt sich damit Umsatz generieren. Schon ist die Verlockung zu groß und das Unternehmen greift auf die 30% Ressourcen zu, die für „Debt zurückzahlen“ und „neue Technologien erproben“ geblockt waren. Den so entstehenden Rückstand beim Zurückzahlen der Debt holen Unternehmen nur äußerst selten wieder auf. Durch diese kleine Spontanentscheidung befindet sich das Produkt nun schon wieder den ersten Schritt auf dem Weg in Richtung Relaunch – obwohl langfristig der andere Weg ökonomischer wäre.

---

Dieser Artikel gehört zu: UPLOAD Magazin 38

In dieser Ausgabe dreht sich alles darum, wie man einen eleganten Neustart hinlegt (oder vielleicht sogar ganz verhindern kann) – ob nun als Unternehmen oder als Privatperson oder für eine Website.

• Weitere Artikel aus dieser Ausgabe kostenlos auf der Website lesen ...
• Bleib auf dem Laufenden über neue Inhalte mit dem „Update am Montag“ …

Schon gewusst? Mit einem Zugang zu UPLOAD Magazin Plus oder zur Content Academy lädst du Ausgaben als PDF und E-Book herunter und hast viele weitere Vorteile!