Die Markteinführung ist nur der Anfang: Warum Produktunterstützung wichtiger ist, als es scheint
Die meisten Unternehmen betrachten Produktsupport als Kostenfaktor. Wir erläutern, warum es sich um eine Investition handelt und was mit einem digitalen Produkt ohne ordnungsgemäße Wartung passiert.
Wenn ein Unternehmen eine Entwicklung in Auftrag gibt, liegt die ganze Aufmerksamkeit auf der Markteinführung. Das Veröffentlichungsdatum, das Entwicklungsbudget, der Funktionsumfang der ersten Version. Unterstützung wird am Rande oder gar nicht besprochen. „Wir werden es nach dem Start herausfinden.“
Dies ist einer der häufigsten Fehler bei der Arbeit mit digitalen Produkten. Denn der Start ist nicht das Finale. Es ist der Punkt, an dem das eigentliche Leben des Produkts beginnt. Und was danach passiert, entscheidet maßgeblich darüber, ob die Entwicklung eine Investition oder nur eine Ausgabe war.
Was passiert mit einem Produkt ohne Support?
Plattform-Update – das Produkt geht kaputt
Apple veröffentlicht eine neue Version von iOS. Google aktualisiert Android. Browser ändern Standards. Jedes dieser Updates kann zu Schäden an Ihrem Produkt führen – von visuellen Artefakten bis hin zum völligen Ausfall bestimmter Funktionen. Eine App, die nicht aktualisiert wird, wird früher oder später nicht mehr richtig funktionieren oder ganz aus den Stores verschwinden – der App Store und Google Play entfernen regelmäßig Apps, die nicht den aktuellen Anforderungen entsprechen.
Technische Schulden häufen sich
Code, der heute geschrieben wird, beginnt schon morgen veraltet zu sein. Bibliotheken veröffentlichen neue Versionen, die Schwachstellen beheben. Abhängigkeiten werden inkompatibel. Ohne geplante Wartung häufen sich die technischen Schulden so stark an, dass jede Änderung am Produkt riskant und teuer wird – weil niemand versteht, was was beeinflusst.
Die Sicherheit nimmt ab‘),
Regelmäßig werden Schwachstellen in Bibliotheken entdeckt. Ohne rechtzeitige Aktualisierung der Abhängigkeiten wird Ihr Produkt zum Ziel. Bei Finanzdienstleistungen, dem Gesundheitswesen oder anderen Produkten, die personenbezogene Daten verarbeiten, handelt es sich hierbei nicht um ein abstraktes Risiko, sondern um eine direkte rechtliche Verantwortung.
Fehler bleiben ungelöst
Jedes Produkt weist nach der Markteinführung Fehler auf – das ist normal. Die Frage ist, wie schnell sie behoben werden. Ohne engagierten Support wird jeder Fehler zu einem separaten Projekt: Einen Auftragnehmer finden, sich mit dem Code vertraut machen und einen Preis vereinbaren. Kunden stoßen auf das Problem und gehen – während über die Lösung verhandelt wird.
Siehe auch: Betreuung und Entwicklung digitaler Produkte
Siehe auch: Wie professioneller Produktsupport funktioniert und welche Formate es gibt
Beim Support geht es nicht nur darum, „das Problem zu beheben, wenn es kaputt geht“.
Reaktiver Support – das Beheben bereits defekter Geräte – ist das absolute Minimum. Ein Produkt, das nur repariert, aber nie weiterentwickelt wird, verliert nach und nach an Konkurrenten, die neue Funktionen hinzufügen und das Benutzererlebnis verbessern.
Die professionelle Unterstützung umfasst mehrere Ebenen.
Überwachung und proaktive Reaktion
Das System verfolgt den Zustand des Produkts in Echtzeit: Reaktionsgeschwindigkeit des Servers, Fehler in den Protokollen, Anomalien im Benutzerverhalten. Ein Problem wird erkannt und behoben, bevor sich Benutzer beschweren. Das ist ein grundlegend anderes Maß an Zuverlässigkeit im Vergleich zu „Ein Kunde hat uns geschrieben, dass etwas nicht funktioniert“.
Geplante Updates
Regelmäßige Aktualisierung der Abhängigkeiten, Anpassung an neue Plattformversionen, Leistungsoptimierung bei steigender Auslastung. Dabei handelt es sich nicht um Notfallaufgaben, sondern um geplante Wartungsarbeiten, die Notfälle verhindern.
Feature-Entwicklung
Das Geschäft verändert sich – das Produkt sollte sich mit ihm verändern. Neue Integrationen, zusätzliche Szenarien, Anpassung an neue Kanäle oder Märkte. Das Team, das das Produkt ursprünglich entwickelt hat, erledigt dies schneller und kostengünstiger – es kennt die Architektur und verschwendet keine Zeit damit, sich von Grund auf auf den neuesten Stand zu bringen.
Warum ein Teamwechsel nach dem Start eine teure Angelegenheit ist
Ein häufiges Szenario: Ein Team baut das Produkt, der Support wird an ein anderes Team übergeben – das ist billiger. Auf den ersten Blick ist es logisch. In der Praxis verbringt das neue Team ein oder zwei Monate damit, den Code einer anderen Person herauszufinden. In dieser Zeit arbeitet es langsam und mit einem hohen Fehlerrisiko – nicht weil es schlecht ist, sondern weil es das Produkt nicht kennt.
Die Kosten für die Übergabe eines Projekts an ein neues Team bestehen aus der Einarbeitungszeit und dem Fehlerrisiko bei der Änderung unbekannten Codes. In den meisten Fällen werden die Einsparungen beim Support durch genau diese versteckten Kosten aufgezehrt.
Das Team, das das Produkt entwickelt hat, kennt jede architektonische Entscheidung und den Grund dafür. In diesem Fall handelt es sich bei der Unterstützung nicht um eine Übergabe der Angelegenheiten, sondern um eine Fortsetzung der Arbeit. Die Reaktion ist schneller, die Risiken geringer und die Kosten von Änderungen vorhersehbarer.
Siehe auch: Prüfung und Gestaltung digitaler Produkte
So planen Sie die Unterstützung richtig
Vor dem Start, nicht danach
Das Gespräch über den Support sollte vor der Unterzeichnung des Entwicklungsvertrags stattfinden – nicht nach der Veröffentlichung. Es wirkt sich auf Architekturentscheidungen aus: Ein Produkt, das auf langfristige Unterstützung ausgelegt ist, wird anders gebaut, als wenn man es sich nur als einmalige Entwicklung vorstellt.
Legen Sie ein SLA fest
Ein Service Level Agreement definiert die Reaktionszeit für Vorfälle unterschiedlicher Kritikalität und die Zeit für deren Behebung. Ohne SLA funktioniert der Support auf der Basis „wenn wir soweit sind“. Bei einem SLA handelt es sich um eine vertragliche Verpflichtung. Bei Produkten, von denen ein Geschäftsprozess abhängt, ist das ein grundlegender Unterschied.
Separate Unterstützung und Entwicklung im Budget
Dabei handelt es sich um zwei verschiedene Arten von Arbeiten mit unterschiedlichen Kosten und unterschiedlicher Priorisierung. Support ist die Pflichtaufgabe, die Dinge am Laufen zu halten. Entwicklung ist eine Investition in neue Fähigkeiten. Wenn sie in einem Pool gemischt sind, ist es schwierig zu planen und Prioritäten zu setzen.
Wie viel richtiger Support kostet?
Die Marktnorm für die meisten Mittelklasseprodukte beträgt 15–25 % der Entwicklungskosten pro Jahr für Support und Wartung. Dabei handelt es sich nicht um eine feste Regel, sondern um einen Anhaltspunkt für die Budgetplanung.
Support ohne Entwicklung ist günstiger. Der Support bei der aktiven Funktionsentwicklung ist teurer, aber zu diesem Zeitpunkt handelt es sich nicht mehr um eine Kostenlinie, sondern um eine Investition in die Wettbewerbsfähigkeit des Produkts.
Die richtige Frage bei der Budgetplanung lautet nicht „Wie viel kostet der Support“, sondern „Wie viel kostet der Verzicht auf Support“. Eine Stunde Ausfallzeit für ein umsatzgenerierendes Produkt ist ein direkter Verlust. Der Reputationsschaden durch einen öffentlichen Ausfall ist schwerer zu berechnen, aber genauso real.
Häufig gestellte Fragen
Kommt man ohne Support für eine einfache Website aus?
Für eine statische Visitenkarten-Site ohne komplexe Funktionalität – ja, minimaler Support. Für jedes Produkt mit einer Datenbank, Autorisierung, Zahlungen oder Integrationen – nein. Solche Systeme erfordern trotz ihrer scheinbaren Einfachheit eine regelmäßige Wartung.
Wie wähle ich zwischen Retainer-Support und On-Demand-Support?
Der Retainer-Support bietet ein vorhersehbares Budget, eine Prioritätswarteschlange und proaktive Überwachung. Es eignet sich für Produkte, die geschäftskritisch sind oder sich aktiv weiterentwickeln. Der On-Demand-Support ist flexibel, aber in Bezug auf Zeitpunkt und Kosten unvorhersehbar. Es eignet sich für stabile Produkte mit seltenen Änderungen.
Was soll ich tun, wenn ein anderes Team das Produkt erstellt hat?
Beginnen Sie mit einem technischen Audit. Das Audit zeigt den Zustand des Codes, der Architektur und der technischen Schulden und hilft bei der Beurteilung des Umfangs der Übergabearbeiten und der mit der Durchführung von Änderungen verbundenen Risiken. Nach dem Audit können Sie eine fundierte Entscheidung über die Form der weiteren Unterstützung treffen.
Woher weiß ich, dass ein Produkt ein Architektur-Update benötigt?
Signale: Jede Änderung der Funktionalität dauert unverhältnismäßig lange, Entwickler haben Angst, bestimmte Teile des Codes zu berühren, die Leistung nimmt mit zunehmender Last ab, das Hinzufügen neuer Integrationen erfordert erhebliche Überarbeitung. Wenn Sie sich selbst erkennen, ist es Zeit für ein technisches Audit.