Was ich in 4 Jahren gelernt habe, ein Unternehmen in einem hart umkämpften SaaS-Markt zu betreiben

xguru · 2025-04-14T11:01:01+09:00

OnlineOrNot, gegründet von Max Rozen, startete in einem Markt, in dem bereits über 200 Konkurrenzprodukte existierten Anfangs waren viele Produkte umständlich zu benutzen; später tauchten unzählige Wettbewerber auf und verschwanden schnell wieder Einige Konkurrenzprodukte erhielten VC-Finanzierung und wurden von Großunternehmen übernommen, woraufhin sich die User Experience zunehmend verschlechterte OnlineOrNot zielt auf ein langfristig tragfähiges Unternehmen ab, das aus eigenen Mitteln betrieben wird Der Autor behält weiterhin seinen Vollzeitjob und entwickelt das SaaS konsequent weiter Jedes Jahr schreibt er einen Rückblick, und einige Lehren aus der Vergangenheit haben sich mit der Zeit als falsch erwiesen Unveränderte Prinzipien Über die Jahre habe ich viel darüber gelernt, ein Unternehmen zu führen, aber es gibt weiterhin einige zentrale Prinzipien, die sich nicht verändert haben. Jeden Werktag 2 Stunden investieren Schon vor dem Start von OnlineOrNot habe ich mich jeden Morgen vor der Arbeit 2 Stunden lang auf persönliche Projekte konzentriert In dieser Zeit habe ich Hunderte von Artikeln, ein Buch und mehrere Softwareprojekte fertiggestellt Wichtiger als die Menge an Zeit pro Tag ist die tägliche Konsequenz selbst Um diese Zeit freizuschaufeln, bin ich 2 Stunden früher aufgestanden und habe meinen Tagesablauf angepasst Keine anderen Side Projects Wie das Sprichwort sagt: Wer zwei Hasen jagt, fängt keinen — also fokussiere ich mich auf eine Sache Manche Ausnahmen schaffen mehrere erfolgreiche Projekte, aber ich erkenne an, dass ich nicht so bin Der Weg von $0 auf $500 MRR ist am schwierigsten, und ich hielt es nicht für sinnvoll, ihn immer wieder zu wiederholen Ich konzentriere mich auf ein Modell, das bereits funktioniert, und treffe Marketingentscheidungen aus derselben Perspektive Vorrang hat, den Schmerz der Kunden zu lösen Wenn sich Nutzer anmelden, schicke ich per automatischer E-Mail die Frage: „Warum haben Sie sich angemeldet?“ Ich lese jede E-Mail und antworte persönlich; das liefert die wichtigsten Erkenntnisse für Produktverbesserungen Herausfinden, was Nutzer frustriert, und es tatsächlich lösen Hartnäckig iterieren und verbessern Wenn ich etwas nicht innerhalb von 2 Stunden deployen kann, verkleinere ich den Umfang und deploye zuerst eine kleinere Version Es klappt nicht immer ideal in genau 2 Stunden, aber ich bevorzuge es, früh eine erste Version auszurollen und die Funktion dann zu erweitern Wenn man versucht, alles fertigzustellen und erst dann zu deployen, verliert man eher die Motivation und den Fokus Funktionen schrittweise hinter Feature Flags fertigzustellen ist deutlich effektiver Gelernte Lektionen Lies nur ein paar Bücher und fang dann direkt an zu bauen Am Anfang habe ich Dutzende Business-Bücher gelesen, um Fehler zu vermeiden Aber am Ende wurde mir klar, dass man am effektivsten lernt, indem man selbst Fehler macht Beispiel: Ein Beitrag landete auf der Hacker-News-Startseite und brachte 6000 Besucher, aber nur eine einstellige Zahl davon erreichte tatsächlich die App Bereits im Signup-Formular sprangen 75% ab → durch nur eine zusätzliche OAuth-Login-Option sank die Abbruchrate auf 50% Wenn ich noch einmal anfangen würde, würde ich nur diese drei Bücher lesen und dann direkt loslegen: The Mom Test (Rob Fitzpatrick) Deploy Empathy (Michele Hansen) Badass: Making Users Awesome (Kathy Sierra) Wer mehr praktische Details zum Betrieb eines SaaS braucht, dem empfehle ich zusätzlich The SaaS Playbook (Rob Walling) Nicht das Verkaufen von Abos, sondern das Lösen von Problemen kommt zuerst Das Ziel eines SaaS ist nicht, Abonnements zu verkaufen, sondern den Schmerz der Kunden zu lösen Statt „Wenn wir weiter Features bauen, werden die Leute es irgendwann schon nutzen“ braucht es den Perspektivwechsel zu „Lösen wir ein frustrierendes Problem im Arbeitsalltag der Nutzer“ SaaS ist nur eine Art, Probleme zu lösen; daneben sind auch Screencasts, Dokumentation, Schreiben, Bücher, Workshops, Code-Beispiele und andere Ansätze möglich Klein bauen und häufig deployen Nutzer schlagen zwar Feature-Ideen vor, verwenden sie in der Praxis aber oft kaum Wer zum ersten Mal ein SaaS startet, ist oft schon begeistert, überhaupt mit jemandem zu sprechen, und baut dann vorschnell einfach das gewünschte Feature Man sollte fragen, wie das Feature genutzt werden soll, untersuchen, wie andere Nutzer ähnliche Probleme lösen, und dann zuerst mit minimalem Funktionsumfang implementieren, um die Reaktion zu prüfen Wichtiger als ein „Snowflake-Feature“ für genau eine Person zu bauen, ist ein strategischer Ansatz für Funktionen, die viele nutzen Es tut weh, ein Feature zu entfernen, in das man ein paar Stunden investiert hat, aber ein Feature zu entfernen, in das Monate geflossen sind, tut sehr viel mehr weh Erst deployen, über Skalierung später nachdenken Die erste Version von OnlineOrNot wurde ohne Architektur-Optimierung schnell veröffentlicht Tatsächlich gab es einen Bug, durch den das System auf etwa 100 Checks begrenzt war, und bei Problemen zeigte die UI den Nutzern einfach nur „Error!“ an — insgesamt also ein sehr unfertiger Zustand Trotzdem entschied sich der Autor lieber dafür, für eine unfertige UI kritisiert zu werden, als unnötige Features zu bauen Es gibt keine Garantie, dass von Anfang an Tausende Nutzer kommen, daher war schnelle Validierung wichtiger Übergangsweise wurde die Datenbank auf einen höheren Tarif hochgestuft, um mehr Checks zu verkraften Innerhalb weniger Stunden wurde dann auf eine Struktur refaktoriert, die Millionen von Checks verarbeiten konnte, und auch der Fehlerbildschirm wurde verbessert Ein Early-Access-Programm betreiben In der frühen Produktentwicklung sind die meisten Nutzer gegenüber unvollständigen Funktionen einigermaßen nachsichtig Mit der Zeit steigt jedoch die Zahl der Nutzer, die ein reiferes Produkt erwarten Um das zu lösen, wurde jedem Nutzerkonto eine Checkbox „Teilnahme am Early-Access-Programm“ hinzugefügt Teilnehmer können neueste, noch nicht fertige Funktionen früher ausprobieren und Feedback geben Das funktioniert gut als Methode, Testen und Feedback auszubalancieren Free Trial so früh wie möglich einführen Heute hört man oft den Rat: „Einen Free Plan vernünftig abzugrenzen ist zu schwer, also lieber nicht machen“ In der Anfangsphase war ein Free Plan jedoch wirksam für Mundpropaganda und Nutzergewinnung Der Nachteil ist: Wenn sich der Free Plan stark von den Bezahlfunktionen unterscheidet, braucht es eine Möglichkeit, die guten Funktionen zu erleben Erst 11 Monate nach dem Start wurde im Onboarding die Frage „Möchten Sie eine kostenlose Testphase starten?“ ergänzt Gemeint ist in Wirklichkeit: „Möchten Sie die guten Funktionen 14 Tage lang testen und dann entscheiden, oder lieber monatelang eine eingeschränkte Version nutzen und am Ende enttäuscht sein?“ Später wurde experimentell allen Nutzern standardmäßig eine kostenlose Testphase gegeben, und allein dieses eine Experiment verdoppelte die monatliche Wachstumsrate mehr als Fazit: Die Botschaft „Dies ist ein kostenpflichtiger Dienst. Wenn Sie die guten Funktionen weiter nutzen möchten, brauchen wir Ihre Zahlungsdaten“ ist geschäftlich deutlich wirksamer als „Dies ist ein kostenloser Dienst. Wenn Sie viel nutzen, kostet es vielleicht etwas“ Dokumentation ist selbst Teil des Produkts Früher hieß es oft „Entwickler lesen keine Dokumentation“, aber das ist komplett falsch Einige ideale Kunden lobten die Dokumentation von OnlineOrNot, und das war der Auslöser, gezielt in Dokumentation zu investieren Auch die API-Dokumentation wurde selbst aufgebaut, um die User Experience vollständig kontrollieren zu können Beobachtungen aus Produktanalyse-Tools zeigten: Wenn Nutzer in der UI auf ein Problem stoßen, dann in der Dokumentation nachsehen und die Funktion finden, bleiben sie beim Produkt Wenn sie die gewünschte Information nicht finden, erstellen sie keinen Check und springen ab Die Qualität der Dokumentation hängt direkt mit der Nutzerbindung zusammen Produkte mit Blick auf Mobile designen Anders als oft angenommen beginnen auch B2B-SaaS-Nutzer ihre Arbeit auf dem Smartphone Tatsächlich starten rund 50% aller Nutzer auf dem Mobilgerät mit dem Produkt Sie erstellen ein Konto, legen einige Seiten an und schauen später am PC noch einmal nach In den ersten 6 Monaten wurde Mobile nicht berücksichtigt, und die meisten mobilen Anmeldungen sprangen ab Nach Einführung einer responsiven UI stieg die Bindung mobiler Nutzer deutlich Nutzer direkt fragen, woher sie kommen Eine der wertvollsten Code-Änderungen in der Mitte des ersten Jahres war beim Signup die Frage „Wo haben Sie von OnlineOrNot erfahren?“ hinzuzufügen Zu wissen, über welche Kanäle Nutzer kommen, ist entscheidend, um Marketing effizienter zu machen Es gibt Dutzende Marketingkanäle, aber die Ressourcen für Fokus sind begrenzt Wenn klar ist, welcher Kanal funktioniert, sollte man genau dort gezielt investieren und weitermachen, bis die Wirkung nachlässt Keine invasiven Analyse-Tools verwenden Anfangs wurden wie bei typischen SaaS-Produkten Session-Tracking und Funnel-Analyse-Tools eingebaut, aber ihr praktischer Nutzen war gering Für große Teams kann das hilfreich sein, für kleine Services besteht jedoch ein hohes Risiko, zufällige Ergebnisse zu überinterpretieren Als Solo-Gründer mit nur 2 Stunden jeden Morgen war es effektiver, statt riesige Datenmengen auszuwerten direkt Meinungen von einer vertrauten Nutzergruppe (inner circle) einzuholen So bekam er ein Gespür für Features und Probleme und verbesserte das Produkt auf Basis intuitiver Einschätzungen Mit potenziellen Kunden sprechen, auch wenn die Funktion noch nicht existiert Eines Tages fragte ein CTO an, ob eine bestimmte Funktion unterstützt werde Eigentlich wollte ich nur mit „Tut mir leid, gibt es noch nicht“ antworten, aber aus Neugier fragte ich nach dem Problem, das sie hatten, und nach dem Ziel, das sie erreichen wollten ich fragte auch Nutzer aus dem inner circle, ob sie dasselbe Problem haben und teilte Ideen dazu, wie sich die Funktion gestalten ließe Das Ergebnis: Dieser CTO wurde schon am nächsten Tag zahlender Kunde und ist bis heute Kunde Auch andere Nutzer verwenden die betreffende Funktion erfolgreich Mehr Zeit für den Aufbau der Plattform als für das Lösen des eigentlichen Problems In den letzten 4 Jahren floss mehr als die Hälfte der Entwicklungszeit in den Aufbau der SaaS-Plattform das eigentliche Ziel „prüfen, ob eine Website down ist, und Benachrichtigungen senden“ war nur ein Teil davon Tatsächlich benötigte Funktionen waren unter anderem: verschiedene Authentifizierungsverfahren und Nutzerverwaltung Testversionen, Onboarding wiederkehrende DB-Arbeiten, Teamverwaltung, Rechnungsverarbeitung Lifecycle-E-Mails usw. Einiges wurde an Dienste wie Stripe ausgelagert, aber vieles musste wegen direkter Verarbeitung oder nötiger Individualisierung am Ende doch selbst implementiert werden Pricing ist wirklich schwierig Ist der Preis zu hoch, steigen die Erwartungen oder Nutzer zögern schon bei der Anmeldung Ist der Preis zu niedrig, verlangen Nutzer, die $9 zahlen, mitunter Anpassungen der gesamten App nach ihren persönlichen Wünschen Die Lösung: schwierigen Kunden ihr Geld zurückgeben und sie ziehen lassen Preise erhöhen und weitermachen besonders am Anfang sind kontinuierliche Pricing-Experimente unverzichtbar, je weiter man das Produkt ausbaut Sich nicht nur auf MRR fixieren MRR (Monthly Recurring Revenue) kann als Kennzahl ungeeignet sein, um den Geschäftserfolg zu messen Was man vor einigen Wochen oder Monaten getan hat, beeinflusst das heutige MRR, weshalb Effekte in Echtzeit schwer messbar sind Bei manchen SaaS-Produkten kann es mehr als 60 Tage dauern, bis Nutzer nach der Anmeldung tatsächlich zahlen Deshalb sollte man über andere Kennzahlen erfassen, ob das Produkt wirklich genutzt wird und Wert liefert z. B. Anzahl erzeugter Bilder, Anzahl eingereichter Formulare oder andere verhaltensbasierte Erfolgsmetriken Niemals „unbegrenzt“ anbieten Es gibt immer Kunden, die „unbegrenzt“ maximal ausreizen (whale customer) Beispiel: ein Kunde, der nur $250/Monat zahlt und dabei enorme Ressourcen verbraucht Wenn die unbegrenzte Einheit direkte Kosten verursacht, macht man damit zwangsläufig Verlust Dieser Rat gilt auch für Lifetime Deals Wenn man für $100 lebenslange Nutzung verspricht, kann man über Jahre hinweg zusätzliche Feature-Wünsche bekommen nutzt man dafür einen Drittanbieter-Marktplatz, erhält man eventuell nur 30% dieses Umsatzes Am Ende lädt man damit keine echten Kunden ein, sondern Nutzer, die kurzfristige Vorteile suchen und lange gebunden bleiben Bei kostenpflichtigen Ressourcen immer Rate Limits setzen Wenn man kostenpflichtige APIs wie für AI, SMS oder E-Mail-Versand nutzt, sind Nutzungslimits zwingend nötig „Sind zahlende Kunden nicht gerade diejenigen, die unbegrenzt nutzen dürfen sollten?“ → In Ausnahmefällen vielleicht, aber in den meisten Fällen drohen explodierende Kosten oder Spam-Labels von Anbietern Konkretes Beispiel: Auf einem Server mit Hunderten gehosteten WordPress-Sites kam es wegen RAM-Mangels zu Fehlern dadurch wurden automatisch Tausende SMS-Benachrichtigungen verschickt, was hohe Kosten verursachte Wenn ein Kunde wirklich großes Volumen braucht, wird er sich direkt melden Nicht versuchen, alles auf einer Seite zu erklären „Wenn man versucht, für alle alles zu sagen, sagt man am Ende niemandem etwas.“ Dieser Satz passt besonders gut auf Landing-Page-Copywriting Immer wenn OnlineOrNot neue Funktionen hinzufügte, wurde auf der Haupt-Landing-Page noch mehr erklärt, wodurch die Botschaft unübersichtlich wurde und das Verständnis der Nutzer sank Beispiel: Slack-Benachrichtigungen waren die zweite gebaute Funktion, aber viele wussten nicht einmal, dass es sie gibt Die Lösung: separate Landing Pages für einzelne Funktionen erstellen Hauptseite: https://onlineornot.com/ Uptime-Monitoring: https://onlineornot.com/website-monitoring API-Monitoring: https://onlineornot.com/api-monitoring Statusseiten: https://onlineornot.com/status-pages Cronjob-Monitoring: https://onlineornot.com/cron-job-monitoring Auf jeder Seite gibt es genügend Raum, um die jeweilige Funktion klar zu vermitteln Mehr Traffic zu bekommen ist schwierig, die Conversion zu verbessern kann man sofort Im Internet Aufmerksamkeit zu bekommen ist ein langfristiges und sehr langsames Spiel Selbst mit kontinuierlichem, hochwertigem Content-Marketing dauert es Monate bis Jahre, bis aus 1–2 Besuchern Hunderte werden Den Traffic selbst zu steigern, ist nicht einfach Das Verhalten der Menschen, die schon da sind, kann man dagegen sofort beeinflussen etwa indem man dem Signup-Formular eine OAuth-Login-Option hinzufügt — eine Verbesserung, die heute schon die Conversion erhöhen kann Konkurrenten sind nicht so wichtig Dass in diesem ganzen Artikel kaum von Konkurrenten die Rede ist, liegt daran, dass sie in Wirklichkeit keinen so großen Einfluss haben Natürlich braucht man die grundlegenden Funktionen, damit Kunden das Produkt überhaupt in Betracht ziehen, aber die eigentliche Konkurrenz ist, dass Nutzer gar nicht wissen, dass dieses Produkt existiert Wichtiger als Features sind Bekanntheit und Zugänglichkeit

(maxrozen.com)

74 Punkte von xguru 2025-04-14 | 4 Kommentare | Auf WhatsApp teilen

OnlineOrNot, gegründet von Max Rozen, startete in einem Markt, in dem bereits über 200 Konkurrenzprodukte existierten
Anfangs waren viele Produkte umständlich zu benutzen; später tauchten unzählige Wettbewerber auf und verschwanden schnell wieder
Einige Konkurrenzprodukte erhielten VC-Finanzierung und wurden von Großunternehmen übernommen, woraufhin sich die User Experience zunehmend verschlechterte
OnlineOrNot zielt auf ein langfristig tragfähiges Unternehmen ab, das aus eigenen Mitteln betrieben wird
Der Autor behält weiterhin seinen Vollzeitjob und entwickelt das SaaS konsequent weiter
Jedes Jahr schreibt er einen Rückblick, und einige Lehren aus der Vergangenheit haben sich mit der Zeit als falsch erwiesen

Unveränderte Prinzipien

Über die Jahre habe ich viel darüber gelernt, ein Unternehmen zu führen, aber es gibt weiterhin einige zentrale Prinzipien, die sich nicht verändert haben.

Jeden Werktag 2 Stunden investieren

Schon vor dem Start von OnlineOrNot habe ich mich jeden Morgen vor der Arbeit 2 Stunden lang auf persönliche Projekte konzentriert
In dieser Zeit habe ich Hunderte von Artikeln, ein Buch und mehrere Softwareprojekte fertiggestellt
Wichtiger als die Menge an Zeit pro Tag ist die tägliche Konsequenz selbst
Um diese Zeit freizuschaufeln, bin ich 2 Stunden früher aufgestanden und habe meinen Tagesablauf angepasst

Keine anderen Side Projects

Wie das Sprichwort sagt: Wer zwei Hasen jagt, fängt keinen — also fokussiere ich mich auf eine Sache
Manche Ausnahmen schaffen mehrere erfolgreiche Projekte, aber ich erkenne an, dass ich nicht so bin
Der Weg von $0 auf $500 MRR ist am schwierigsten, und ich hielt es nicht für sinnvoll, ihn immer wieder zu wiederholen
Ich konzentriere mich auf ein Modell, das bereits funktioniert, und treffe Marketingentscheidungen aus derselben Perspektive

Vorrang hat, den Schmerz der Kunden zu lösen

Wenn sich Nutzer anmelden, schicke ich per automatischer E-Mail die Frage: „Warum haben Sie sich angemeldet?“
Ich lese jede E-Mail und antworte persönlich; das liefert die wichtigsten Erkenntnisse für Produktverbesserungen
Herausfinden, was Nutzer frustriert, und es tatsächlich lösen

Hartnäckig iterieren und verbessern

Wenn ich etwas nicht innerhalb von 2 Stunden deployen kann, verkleinere ich den Umfang und deploye zuerst eine kleinere Version
Es klappt nicht immer ideal in genau 2 Stunden, aber ich bevorzuge es, früh eine erste Version auszurollen und die Funktion dann zu erweitern
Wenn man versucht, alles fertigzustellen und erst dann zu deployen, verliert man eher die Motivation und den Fokus
Funktionen schrittweise hinter Feature Flags fertigzustellen ist deutlich effektiver

Gelernte Lektionen

Lies nur ein paar Bücher und fang dann direkt an zu bauen

Am Anfang habe ich Dutzende Business-Bücher gelesen, um Fehler zu vermeiden
Aber am Ende wurde mir klar, dass man am effektivsten lernt, indem man selbst Fehler macht
Beispiel: Ein Beitrag landete auf der Hacker-News-Startseite und brachte 6000 Besucher, aber nur eine einstellige Zahl davon erreichte tatsächlich die App
Bereits im Signup-Formular sprangen 75% ab → durch nur eine zusätzliche OAuth-Login-Option sank die Abbruchrate auf 50%
Wenn ich noch einmal anfangen würde, würde ich nur diese drei Bücher lesen und dann direkt loslegen:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- Wer mehr praktische Details zum Betrieb eines SaaS braucht, dem empfehle ich zusätzlich The SaaS Playbook (Rob Walling)

Nicht das Verkaufen von Abos, sondern das Lösen von Problemen kommt zuerst

Das Ziel eines SaaS ist nicht, Abonnements zu verkaufen, sondern den Schmerz der Kunden zu lösen
Statt „Wenn wir weiter Features bauen, werden die Leute es irgendwann schon nutzen“ braucht es den Perspektivwechsel zu „Lösen wir ein frustrierendes Problem im Arbeitsalltag der Nutzer“
SaaS ist nur eine Art, Probleme zu lösen; daneben sind auch Screencasts, Dokumentation, Schreiben, Bücher, Workshops, Code-Beispiele und andere Ansätze möglich

Klein bauen und häufig deployen

Nutzer schlagen zwar Feature-Ideen vor, verwenden sie in der Praxis aber oft kaum
Wer zum ersten Mal ein SaaS startet, ist oft schon begeistert, überhaupt mit jemandem zu sprechen, und baut dann vorschnell einfach das gewünschte Feature
Man sollte fragen, wie das Feature genutzt werden soll, untersuchen, wie andere Nutzer ähnliche Probleme lösen, und dann
- zuerst mit minimalem Funktionsumfang implementieren, um die Reaktion zu prüfen
Wichtiger als ein „Snowflake-Feature“ für genau eine Person zu bauen, ist ein strategischer Ansatz für Funktionen, die viele nutzen
Es tut weh, ein Feature zu entfernen, in das man ein paar Stunden investiert hat, aber ein Feature zu entfernen, in das Monate geflossen sind, tut sehr viel mehr weh

Erst deployen, über Skalierung später nachdenken

Die erste Version von OnlineOrNot wurde ohne Architektur-Optimierung schnell veröffentlicht
Tatsächlich gab es einen Bug, durch den das System auf etwa 100 Checks begrenzt war, und
- bei Problemen zeigte die UI den Nutzern einfach nur „Error!“ an — insgesamt also ein sehr unfertiger Zustand
Trotzdem entschied sich der Autor lieber dafür, für eine unfertige UI kritisiert zu werden, als unnötige Features zu bauen
Es gibt keine Garantie, dass von Anfang an Tausende Nutzer kommen, daher war schnelle Validierung wichtiger
Übergangsweise wurde die Datenbank auf einen höheren Tarif hochgestuft, um mehr Checks zu verkraften
Innerhalb weniger Stunden wurde dann auf eine Struktur refaktoriert, die Millionen von Checks verarbeiten konnte, und auch der Fehlerbildschirm wurde verbessert

Ein Early-Access-Programm betreiben

In der frühen Produktentwicklung sind die meisten Nutzer gegenüber unvollständigen Funktionen einigermaßen nachsichtig
Mit der Zeit steigt jedoch die Zahl der Nutzer, die ein reiferes Produkt erwarten
Um das zu lösen, wurde jedem Nutzerkonto eine Checkbox „Teilnahme am Early-Access-Programm“ hinzugefügt
- Teilnehmer können neueste, noch nicht fertige Funktionen früher ausprobieren und Feedback geben
Das funktioniert gut als Methode, Testen und Feedback auszubalancieren

Free Trial so früh wie möglich einführen

Heute hört man oft den Rat: „Einen Free Plan vernünftig abzugrenzen ist zu schwer, also lieber nicht machen“
In der Anfangsphase war ein Free Plan jedoch wirksam für Mundpropaganda und Nutzergewinnung
Der Nachteil ist: Wenn sich der Free Plan stark von den Bezahlfunktionen unterscheidet, braucht es eine Möglichkeit, die guten Funktionen zu erleben
Erst 11 Monate nach dem Start wurde im Onboarding die Frage „Möchten Sie eine kostenlose Testphase starten?“ ergänzt
- Gemeint ist in Wirklichkeit:
  
  „Möchten Sie die guten Funktionen 14 Tage lang testen und dann entscheiden, oder lieber monatelang eine eingeschränkte Version nutzen und am Ende enttäuscht sein?“
Später wurde experimentell allen Nutzern standardmäßig eine kostenlose Testphase gegeben, und
- allein dieses eine Experiment verdoppelte die monatliche Wachstumsrate mehr als
Fazit:
- Die Botschaft „Dies ist ein kostenpflichtiger Dienst. Wenn Sie die guten Funktionen weiter nutzen möchten, brauchen wir Ihre Zahlungsdaten“
- ist geschäftlich deutlich wirksamer als „Dies ist ein kostenloser Dienst. Wenn Sie viel nutzen, kostet es vielleicht etwas“

Dokumentation ist selbst Teil des Produkts

Früher hieß es oft „Entwickler lesen keine Dokumentation“, aber das ist komplett falsch
Einige ideale Kunden lobten die Dokumentation von OnlineOrNot, und das war der Auslöser, gezielt in Dokumentation zu investieren
Auch die API-Dokumentation wurde selbst aufgebaut, um die User Experience vollständig kontrollieren zu können
Beobachtungen aus Produktanalyse-Tools zeigten:
1. Wenn Nutzer in der UI auf ein Problem stoßen, dann in der Dokumentation nachsehen und die Funktion finden, bleiben sie beim Produkt
2. Wenn sie die gewünschte Information nicht finden, erstellen sie keinen Check und springen ab
Die Qualität der Dokumentation hängt direkt mit der Nutzerbindung zusammen

Produkte mit Blick auf Mobile designen

Anders als oft angenommen beginnen auch B2B-SaaS-Nutzer ihre Arbeit auf dem Smartphone
Tatsächlich starten rund 50% aller Nutzer auf dem Mobilgerät mit dem Produkt
- Sie erstellen ein Konto, legen einige Seiten an und schauen später am PC noch einmal nach
In den ersten 6 Monaten wurde Mobile nicht berücksichtigt, und die meisten mobilen Anmeldungen sprangen ab
Nach Einführung einer responsiven UI stieg die Bindung mobiler Nutzer deutlich

Nutzer direkt fragen, woher sie kommen

Eine der wertvollsten Code-Änderungen in der Mitte des ersten Jahres war
- beim Signup die Frage „Wo haben Sie von OnlineOrNot erfahren?“ hinzuzufügen
Zu wissen, über welche Kanäle Nutzer kommen, ist entscheidend, um Marketing effizienter zu machen
Es gibt Dutzende Marketingkanäle, aber die Ressourcen für Fokus sind begrenzt
Wenn klar ist, welcher Kanal funktioniert, sollte man genau dort gezielt investieren und weitermachen, bis die Wirkung nachlässt

Keine invasiven Analyse-Tools verwenden

Anfangs wurden wie bei typischen SaaS-Produkten Session-Tracking und Funnel-Analyse-Tools eingebaut, aber ihr praktischer Nutzen war gering
Für große Teams kann das hilfreich sein, für kleine Services besteht jedoch ein hohes Risiko, zufällige Ergebnisse zu überinterpretieren
Als Solo-Gründer mit nur 2 Stunden jeden Morgen war es effektiver, statt riesige Datenmengen auszuwerten
- direkt Meinungen von einer vertrauten Nutzergruppe (inner circle) einzuholen
So bekam er ein Gespür für Features und Probleme und verbesserte das Produkt auf Basis intuitiver Einschätzungen

Mit potenziellen Kunden sprechen, auch wenn die Funktion noch nicht existiert

Eines Tages fragte ein CTO an, ob eine bestimmte Funktion unterstützt werde
Eigentlich wollte ich nur mit „Tut mir leid, gibt es noch nicht“ antworten, aber
- aus Neugier fragte ich nach dem Problem, das sie hatten, und nach dem Ziel, das sie erreichen wollten
- ich fragte auch Nutzer aus dem inner circle, ob sie dasselbe Problem haben
- und teilte Ideen dazu, wie sich die Funktion gestalten ließe
Das Ergebnis: Dieser CTO wurde schon am nächsten Tag zahlender Kunde und ist bis heute Kunde
Auch andere Nutzer verwenden die betreffende Funktion erfolgreich

Mehr Zeit für den Aufbau der Plattform als für das Lösen des eigentlichen Problems

In den letzten 4 Jahren floss mehr als die Hälfte der Entwicklungszeit in den Aufbau der SaaS-Plattform
- das eigentliche Ziel „prüfen, ob eine Website down ist, und Benachrichtigungen senden“ war nur ein Teil davon
Tatsächlich benötigte Funktionen waren unter anderem:
- verschiedene Authentifizierungsverfahren und Nutzerverwaltung
- Testversionen, Onboarding
- wiederkehrende DB-Arbeiten, Teamverwaltung, Rechnungsverarbeitung
- Lifecycle-E-Mails usw.
Einiges wurde an Dienste wie Stripe ausgelagert, aber
- vieles musste wegen direkter Verarbeitung oder nötiger Individualisierung am Ende doch selbst implementiert werden

Pricing ist wirklich schwierig

Ist der Preis zu hoch, steigen die Erwartungen oder Nutzer zögern schon bei der Anmeldung
Ist der Preis zu niedrig, verlangen Nutzer, die $9 zahlen, mitunter Anpassungen der gesamten App nach ihren persönlichen Wünschen
Die Lösung:
- schwierigen Kunden ihr Geld zurückgeben und sie ziehen lassen
- Preise erhöhen und weitermachen
- besonders am Anfang sind kontinuierliche Pricing-Experimente unverzichtbar, je weiter man das Produkt ausbaut

Sich nicht nur auf MRR fixieren

MRR (Monthly Recurring Revenue) kann als Kennzahl ungeeignet sein, um den Geschäftserfolg zu messen
Was man vor einigen Wochen oder Monaten getan hat, beeinflusst das heutige MRR, weshalb Effekte in Echtzeit schwer messbar sind
Bei manchen SaaS-Produkten kann es mehr als 60 Tage dauern, bis Nutzer nach der Anmeldung tatsächlich zahlen
Deshalb sollte man über andere Kennzahlen erfassen, ob das Produkt wirklich genutzt wird und Wert liefert
- z. B. Anzahl erzeugter Bilder, Anzahl eingereichter Formulare oder andere verhaltensbasierte Erfolgsmetriken

Niemals „unbegrenzt“ anbieten

Es gibt immer Kunden, die „unbegrenzt“ maximal ausreizen (whale customer)
Beispiel: ein Kunde, der nur $250/Monat zahlt und dabei enorme Ressourcen verbraucht
Wenn die unbegrenzte Einheit direkte Kosten verursacht, macht man damit zwangsläufig Verlust
Dieser Rat gilt auch für Lifetime Deals
- Wenn man für $100 lebenslange Nutzung verspricht, kann man über Jahre hinweg zusätzliche Feature-Wünsche bekommen
- nutzt man dafür einen Drittanbieter-Marktplatz, erhält man eventuell nur 30% dieses Umsatzes
Am Ende lädt man damit keine echten Kunden ein, sondern Nutzer, die kurzfristige Vorteile suchen und lange gebunden bleiben

Bei kostenpflichtigen Ressourcen immer Rate Limits setzen

Wenn man kostenpflichtige APIs wie für AI, SMS oder E-Mail-Versand nutzt, sind Nutzungslimits zwingend nötig
„Sind zahlende Kunden nicht gerade diejenigen, die unbegrenzt nutzen dürfen sollten?“ → In Ausnahmefällen vielleicht, aber
- in den meisten Fällen drohen explodierende Kosten oder Spam-Labels von Anbietern
Konkretes Beispiel:
- Auf einem Server mit Hunderten gehosteten WordPress-Sites kam es wegen RAM-Mangels zu Fehlern
- dadurch wurden automatisch Tausende SMS-Benachrichtigungen verschickt, was hohe Kosten verursachte
Wenn ein Kunde wirklich großes Volumen braucht, wird er sich direkt melden

Nicht versuchen, alles auf einer Seite zu erklären

„Wenn man versucht, für alle alles zu sagen, sagt man am Ende niemandem etwas.“

Dieser Satz passt besonders gut auf Landing-Page-Copywriting
Immer wenn OnlineOrNot neue Funktionen hinzufügte, wurde auf der Haupt-Landing-Page noch mehr erklärt, wodurch
- die Botschaft unübersichtlich wurde und das Verständnis der Nutzer sank
- Beispiel: Slack-Benachrichtigungen waren die zweite gebaute Funktion, aber viele wussten nicht einmal, dass es sie gibt
Die Lösung: separate Landing Pages für einzelne Funktionen erstellen
- Hauptseite: https://onlineornot.com/
- Uptime-Monitoring: https://onlineornot.com/website-monitoring
- API-Monitoring: https://onlineornot.com/api-monitoring
- Statusseiten: https://onlineornot.com/status-pages
- Cronjob-Monitoring: https://onlineornot.com/cron-job-monitoring
Auf jeder Seite gibt es genügend Raum, um die jeweilige Funktion klar zu vermitteln

Mehr Traffic zu bekommen ist schwierig, die Conversion zu verbessern kann man sofort

Im Internet Aufmerksamkeit zu bekommen ist ein langfristiges und sehr langsames Spiel
- Selbst mit kontinuierlichem, hochwertigem Content-Marketing dauert es Monate bis Jahre, bis aus 1–2 Besuchern Hunderte werden
Den Traffic selbst zu steigern, ist nicht einfach
Das Verhalten der Menschen, die schon da sind, kann man dagegen sofort beeinflussen
- etwa indem man dem Signup-Formular eine OAuth-Login-Option hinzufügt — eine Verbesserung, die heute schon die Conversion erhöhen kann

Konkurrenten sind nicht so wichtig

Dass in diesem ganzen Artikel kaum von Konkurrenten die Rede ist, liegt daran, dass sie in Wirklichkeit keinen so großen Einfluss haben
Natürlich braucht man die grundlegenden Funktionen, damit Kunden das Produkt überhaupt in Betracht ziehen, aber
- die eigentliche Konkurrenz ist, dass Nutzer gar nicht wissen, dass dieses Produkt existiert
Wichtiger als Features sind Bekanntheit und Zugänglichkeit

4 Kommentare

thenewseason 2025-04-22

Aus der Perspektive eines Service-Betreibers kann ich vieles davon gut nachvollziehen.
Ich habe auch meinen Schlaf reduziert, um zu entwickeln, und dadurch hat sich meine Gesundheit verschlechtert..

Was mich bei Menschen mit ähnlichen Erfahrungen interessiert, ist, ob ein solcher Zeiteinsatz auch mit Kindererziehung möglich ist.
Da Pendelzeit, die Zeit im Unternehmen und die Zeit zu Hause mit den Kindern fast den ganzen Tag ausmachen, muss man, um einen solchen Service zu entwickeln und zu betreiben, zwangsläufig auf etwas anderes verzichten — und ich hoffe, dass das nicht die Familie oder die Gesundheit ist..

tsboard 2025-04-15

Das ist wirklich ein sehr lehrreicher Beitrag. Morgens jeweils zwei Stunden dafür zu nutzen, zu schreiben und sogar mehrere Projekte abzuschließen …!

ethanhur 2025-04-14

Ein Text, aus dem man viel lernen kann. Letztlich darf man nicht vergessen, dass auch SaaS ein Produkt ist, das Kunden engagieren, um ihre Probleme zu lösen.

xguru 2025-04-14

Was ich gelernt habe, nachdem ich ein Jahr lang allein ein SaaS betrieben habe
Inzwischen sind schon 3 Jahre vergangen, haha. Vergleicht es, während ihr euch anseht, was sich geändert hat!