- Max Rozen tarafından kurulan OnlineOrNot, halihazırda 200’den fazla rakip ürünün bulunduğu bir pazarda başladı
- İlk dönemde birçok ürünün kullanımı zordu; sonrasında da sayısız rakip ortaya çıkıp hızla ortadan kayboldu
- Bazı rakip ürünler VC yatırımı aldı ve büyük şirketlere satıldı; bu süreçte kullanıcı deneyimi giderek kötüleşti
- OnlineOrNot, kendi geliriyle yürüyen uzun vadede sürdürülebilir bir iş olmayı hedefliyor
- Yazar hâlâ tam zamanlı işini sürdürürken düzenli olarak SaaS geliştirmeye devam ediyor
- Her yıl bir değerlendirme yazısı yazıyor ve geçmişte öğrendiği bazı derslerin zamanla yanlış çıktığını fark etti
Değişmeyen ilkeler
Yıllar içinde iş yürütme konusunda çok şey öğrendim, ancak hâlâ değişmeden koruduğum bazı temel ilkeler var
Her iş gününde 2 saat ayırmak
- OnlineOrNot’u başlatmadan önce de her sabah işe gitmeden önce 2 saat boyunca kişisel projelerime odaklanıyordum
- Bu zamanı kullanarak yüzlerce yazı, bir kitap ve çeşitli yazılım projeleri tamamladım
- Günde ne kadar zaman ayırdığınızdan çok, her gün istikrarlı şekilde emek vermenin kendisi daha önemli
- Bu zamanı yaratmak için 2 saat daha erken kalkıyor ve rutinimi buna göre düzenliyorum
Başka yan projeler yapmamak
- “İki tavşanı kovalayan, hiçbirini yakalayamaz” sözündeki gibi, tek bir şeye odaklanıyorum
- Bazı istisnai kişiler birden fazla projeyi başarıya ulaştırabiliyor, ama ben onlardan biri olmadığımı kabul ediyorum
- $0’dan $500 MRR’ye çıkma sürecinin en zor kısım olduğunu ve bunu tekrar tekrar yaşamaya gerek olmadığını düşünüyorum
- Bu yüzden zaten çalışan modele odaklanıyor, pazarlama yöntemlerini de aynı bakış açısıyla seçiyorum
Öncelik müşterinin acısını çözmek
- Bir kullanıcı kaydolduğunda otomatik e-postayla “Neden kaydoldunuz?” diye soruyorum
- Tüm e-postaları okuyup bizzat yanıtlıyorum; bu da ürün geliştirme için en önemli içgörü kaynağı oluyor
- Kullanıcıların zorlandığı noktayı bulup gerçekten onu çözmek gerekiyor
Israrla yinelemek ve geliştirmek
- Herhangi bir işi 2 saat içinde yayına alamıyorsam, kapsamını küçültüp önce öyle yayınlıyorum
- Her zaman tam 2 saate sığdırmak mümkün olmasa da, ilk sürümü hızlıca yayınlayıp sonradan genişletmeyi tercih ediyorum
- Her şeyi tamamlayıp öyle yayınlamaya çalışırsanız motivasyon düşüyor ve odak dağılıyor
- Özellikleri feature flag arkasında kademeli olarak tamamlama yaklaşımı çok daha etkili
Öğrendiğim dersler
Birkaç kitap oku, sonra hemen bir şey inşa et
- Başlarken hataları azaltmak için onlarca iş kitabı okudum
- Ama sonunda en etkili öğrenme yolunun doğrudan hata yaparak öğrenmek olduğunu fark ettim
- Örneğin: Hacker News ana sayfasına çıktım ve 6000 kişi geldi, ama gerçek uygulamaya ulaşan kullanıcı sayısı tek haneli kaldı
- Sadece kayıt formunda %75 kayıp vardı → tek bir OAuth giriş seçeneği ekleyince bu oran %50’ye kadar düştü
- Bugün yeniden başlasaydım yalnızca şu üç kitabı okuyup hemen başlardım:
- The Mom Test (Rob Fitzpatrick)
- Deploy Empathy (Michele Hansen)
- Badass: Making Users Awesome (Kathy Sierra)
- SaaS işletmenin pratik detayları gerekiyorsa ayrıca The SaaS Playbook (Rob Walling) önerilir
Abonelik satmaktan önce sorun çözmek gelir
- SaaS’ın amacı abonelik satmak değil, müşterinin acısını çözmektir
- “Sürekli özellik yaparsam bir gün insanlar kullanır” düşüncesinden, “Kullanıcının iş akışındaki sinir bozucu sorunu çözelim” düşüncesine geçmek gerekiyor
- SaaS sadece sorun çözmenin bir yolu; bunun dışında screencast, dokümantasyon, yazı, kitap, atölye, kod örnekleri gibi farklı yaklaşımlar da mümkün
Küçük yap ve sık yayınla
- Kullanıcılar özellik fikri önerir, ama çoğunu gerçekte neredeyse hiç kullanmaz
- SaaS’a yeni başlayan biri, biriyle konuşmuş olmanın heyecanıyla gidip o özelliği hemen yapmaya çok yatkındır
- O özelliği nasıl kullanacaklarını sormak, diğer kullanıcıların aynı sorunu nasıl çözdüğünü araştırmak ve ardından
- önce mümkün olan en küçük haliyle uygulayıp tepkiyi görmek gerekir
- Yalnızca tek kişinin kullandığı “snowflake feature” üretmektense, birçok kişinin kullanacağı şeyleri yapmak için stratejik davranmak daha önemlidir
- Birkaç saat harcadığınız bir özelliği silmek can yakar, ama aylar harcadığınız bir özelliği silmek çok daha acı vericidir
Önce yayınla, ölçeklenmeyi sonra düşün
- OnlineOrNot’un ilk sürümü mimari optimizasyon olmadan hızla yayına alındı
- Gerçekte sistemin işleyebildiği kontrol sayısını yaklaşık 100 ile sınırlayan bir bug vardı ve
- sorun çıktığında kullanıcıya sadece “Error!” gösteren, son derece ham bir arayüz söz konusuydu
- Ama yazar, gereksiz özellikler inşa etmek yerine eksik bir arayüz yüzünden eleştirilmesini tercih etti
- En baştan binlerce kullanıcı geleceğinin garantisi olmadığı için, hızlı doğrulama daha önemliydi
- Geçici olarak veritabanını daha üst bir plana geçirerek kontrol kapasitesini artırdı
- Sonrasında birkaç saat içinde milyonlarca kontrolü işleyebilecek yapıya refactor edip hata ekranını da iyileştirdi
Early access programı yürütmek
- Ürün geliştirme aşamasının başlarında kullanıcıların çoğu eksik özelliklere karşı belli ölçüde toleranslıdır
- Zaman geçtikçe daha olgun bir ürün bekleyen kullanıcı sayısı artar
- Bunu çözmek için her kullanıcı hesabına “early access programına katılım” kutusu eklendi
- Katılanlar henüz tamamlanmamış yeni özellikleri önce deneyip geri bildirim veriyor
- Bu, test ile geri bildirim arasında denge kurmanın bir yolu olarak faydalı oldu
Ücretsiz denemeyi mümkün olduğunca erken ekle
- Bugünlerde “ücretsiz planı dengelemek çok zor, hiç yapma” tavsiyesi yaygın
- Buna rağmen başlangıçta ücretsiz plan kulaktan kulağa yayılma ve kullanıcı kazanımı açısından etkiliydi
- Dezavantajı ise ücretsiz plan ile ücretli özellikler arasında büyük fark varsa, iyi özellikleri deneme imkânı sunmanız gerekmesi
- Ancak başlangıçtan 11 ay sonra onboarding sürecine “Ücretsiz denemeyi başlatmak ister misiniz?” sorusunu ekledi
- Bunun asıl anlamı şuydu:
> “İyi özellikleri 14 gün deneyip karar vermek ister misiniz, yoksa aylarca kısıtlı özelliklerle kullanıp sonunda hayal kırıklığına mı uğramak istersiniz?”
- Bunun asıl anlamı şuydu:
- Sonrasında deneysel olarak tüm kullanıcılara varsayılan olarak ücretsiz deneme sunmaya başladı ve
- sadece bu deney bile aylık büyüme oranını 2 katından fazla artırdı
- Sonuç:
- “Bu ücretli bir hizmettir. İyi özellikleri kullanmaya devam etmek için ödeme bilgisi gerekir” mesajı,
- “Bu ücretsiz bir hizmet. Çok kullanırsanız belki ücretli olur” mesajına göre iş açısından çok daha etkilidir
Dokümantasyon da ürünün kendisidir
- Eskiden “geliştiriciler dokümantasyon okumaz” sözü yaygındı, ama bu tamamen yanlış
- İdeal müşterilerden bazıları OnlineOrNot’un dokümantasyonunu övdü; bunun üzerine dokümantasyona ciddi yatırım yapıldı
- API dokümantasyonu da doğrudan kendileri tarafından inşa edilerek kullanıcı deneyiminin tamamen kontrol edilmesi sağlandı
- Ürün analiz araçlarıyla gözlemlenenler:
- Kullanıcı arayüzde sorun yaşayıp dokümantasyona bakıyor ve özelliği bulursa ürünü kullanmaya devam ediyor
- Aradığı bilgiyi bulamazsa kontrol oluşturmadan ayrılıyor
- Dokümantasyon kalitesi, kullanıcı tutma oranını doğrudan etkiler
Ürünü mobil kullanımı düşünerek tasarla
- Yaygın kanının aksine, B2B SaaS kullanıcıları da işlerine akıllı telefondan başlıyor
- Gerçekte tüm kullanıcıların yaklaşık %50’si ürünü ilk kez mobilde kullanmaya başlıyor
- hesap oluşturup birkaç sayfa ekledikten sonra PC’den tekrar dönüp bakıyorlar
- İlk 6 ay boyunca mobil deneyim düşünülmedi ve mobil kaydolanların çoğu ayrıldı
- Sonrasında responsive UI eklendiğinde mobil kullanıcı tutma oranı belirgin biçimde arttı
Kullanıcıya sizi nereden bulduğunu doğrudan sorun
- İlk yılın ortasında eklenen en değerli kod değişikliklerinden biri,
- kayıt sırasında “OnlineOrNot’u nereden duydunuz?” sorusunu eklemek oldu
- Kullanıcı edinim kanallarını anlamak, pazarlama verimliliğini en üst düzeye çıkarmak için çok önemlidir
- Düzinelerce pazarlama kanalı vardır, ama odaklanılabilecek kaynak sınırlıdır
- Hangi kanalın iyi çalıştığı ortaya çıktığında o kanala yoğun yatırım yapıp, etkisi düşene kadar sürdürmek gerekir
Müdahaleci analiz araçlarını kullanmamak
- Başlangıçta tipik bir SaaS ürünü gibi oturum takibi ve funnel analiz araçları kullandı, ama bunlar pek işe yaramadı
- Büyük ekiplerde faydalı olabilirler; ancak küçük servislerde rastgele sonuçları yanlış yorumlama riski yüksektir
- Tek kurucu olarak her sabah yalnızca 2 saati varken,
- devasa veri setlerini incelemek yerine güvendiği bir kullanıcı grubundan (inner-circle) doğrudan görüş almak daha etkili oldu
- Özellikler ve sorunlar hakkında sezgisel geri bildirim alıp, duygu ve sezgi temelli kararlarla ürünü iyileştirdi
Özellik henüz yokken bile potansiyel müşterilerle konuş
- Bir gün bir CTO, belirli bir özelliğin desteklenip desteklenmediğini sordu
- İlk tepkisi “Üzgünüm, henüz yok” deyip geçmekti, ama
- merak edip onların yaşadığı sorunu ve ulaşmak istedikleri hedefi sordu
- inner-circle kullanıcılarına da aynı sorunu yaşayıp yaşamadıklarını sordu
- özelliği nasıl tasarlayabileceğine dair fikirlerini paylaştı
- Sonuç olarak bu CTO ertesi gün ücretli müşteri oldu ve hâlâ müşteri olarak kalmaya devam ediyor
- İlgili özellik de diğer kullanıcılar tarafından iyi şekilde kullanılıyor
Sorun çözmekten çok platform kurmaya zaman harcanıyor
- Son 4 yıldaki geliştirme zamanının yarısından fazlası SaaS platformunu inşa etmeye gitti
- asıl amaç olan “web sitesinin çöküp çökmediğini kontrol etmek ve bildirim göndermek” bunun yalnızca bir parçasıydı
- Gerçekte ihtiyaç duyulan şeyler şunlardı:
- farklı kimlik doğrulama yöntemleri ve kullanıcı yönetimi
- deneme sürümleri, onboarding
- tekrarlayan DB işleri, ekip yönetimi, fatura işlemleri
- yaşam döngüsü e-postaları gibi alanlar
- Bunların bir kısmı Stripe gibi servislerle dışarı verildi, ancak
- doğrudan ele alınması veya özelleştirilmesi gereken çok şey olduğu için sonuçta pek çoğu içeride geliştirildi
Fiyatlandırma gerçekten çok zor
- Fiyat çok yüksek olursa beklenti artar ya da insanlar en baştan kaydolmak istemez
- Fiyat çok düşük olursa $9 ödeyen kullanıcı tüm uygulamanın kendi istediği gibi değiştirilmesini talep edebilir
- Çözüm:
- zor müşterilere para iadesi yapıp yollarını ayırmak
- fiyatı yükseltmek ve yoluna devam etmek
- özellikle erken aşamada özellikler genişledikçe sürekli fiyat deneyi yapmak zorunludur
Sadece MRR’ye takılıp kalma
- MRR (Monthly Recurring Revenue), iş performansını ölçmek için uygun olmayan bir metrik olabilir
- Haftalar ya da aylar önce yaptığınız şeyler bugünkü MRR’yi etkilediği için, gerçek zamanlı etkiyi ölçmek zordur
- Bazı SaaS ürünlerinde kullanıcıların kaydolduktan sonra gerçekten ödeme yapması 60 günden uzun sürebilir
- Bu nedenle, ürünün gerçekten kullanılıp kullanılmadığını ve değer üretip üretmediğini başka metriklerle anlamak gerekir
- örneğin oluşturulan görsel sayısı, gönderilen form sayısı gibi davranış temelli başarı metrikleri önerilir
Asla “sınırsız” sunma
- Her zaman “sınırsız”ı sonuna kadar kullanacak bir whale customer vardır
- Örneğin ayda sadece $250 ödeyip devasa kaynak tüketen bir müşteri
- Sınırsız sunduğunuz birim maliyet oluşturan bir şeyse, bu kaçınılmaz olarak zarar getirir
- Bu tavsiye lifetime deal için de geçerlidir
- $100 karşılığında ömür boyu kullanım sözü verirseniz, sonraki yıllar boyunca yeni özellik talepleriyle karşılaşabilirsiniz
- üçüncü taraf bir marketplace kullandıysanız, bunun yalnızca %30’unu fiilen alıyor bile olabilirsiniz
- Sonuçta gerçek müşteri çekmek yerine, kısa vadeli kazanç peşinde olup sizi uzun süre bağlayacak kullanıcıları davet etmiş olursunuz
Ücretli kaynaklara mutlaka rate limit koy
- AI, SMS, e-posta gönderimi gibi ücretli API’ler kullanılıyorsa, kullanım sınırı şarttır
- “Ama ücretli müşteri, sınırsız kullanamaz mı?” → istisnalar olabilir, ancak
- çoğu durumda maliyet patlaması ya da sağlayıcı tarafından spam olarak etiketlenme riski doğar
- Gerçek örnek:
- yüzlerce WordPress sitesinin barındığı bir sunucuda RAM yetersizliği nedeniyle hata oluştu
- bunun sonucu olarak binlerce SMS uyarısı otomatik gönderildi ve büyük maliyet çıktı
- Gerçekten yüksek hacimli kullanıma ihtiyacı olan müşteri varsa zaten sizinle doğrudan iletişime geçer
Her şeyi tek sayfada anlatmaya çalışma
> “Herkese her şeyi anlatmaya çalışırsanız, kimseye hiçbir şey anlatamazsınız”
- Bu söz, özellikle landing page metin yazımı için çok geçerlidir
- OnlineOrNot’a her yeni özellik eklendiğinde ana landing page’e bunları anlatan yeni kısımlar da eklenince
- mesaj dağınık hâle geldi ve kullanıcıların anlama düzeyi düştü
- örneğin Slack bildirimleri ikinci yapılan özellikti, ama birçok kişi böyle bir özellik olduğunu bile bilmiyordu
- Çözüm: özellik bazlı ayrı landing page’ler oluşturmak
- Ana sayfa: https://onlineornot.com/
- Uptime monitoring: https://onlineornot.com/website-monitoring
- API monitoring: https://onlineornot.com/api-monitoring
- Status pages: https://onlineornot.com/status-pages
- Cron job monitoring: https://onlineornot.com/cron-job-monitoring
- Böylece her sayfada yeterli alan ayırıp özelliği net biçimde anlatmak mümkün oluyor
Trafiği artırmak zordur, dönüşüm oranını iyileştirmek ise hemen yapılabilir
- İnternette dikkat çekmek uzun vadeli ve çok yavaş bir süreçtir
- düzenli olarak kaliteli içerik pazarlaması yapsanız bile, 1-2 ziyaretçiden yüzlerce kişiye çıkmak aylar hatta yıllar alabilir
- Trafiğin kendisini artırmak kolay değildir
- Buna karşılık zaten gelmiş kullanıcıların davranışını hemen değiştirebilirsiniz
- örneğin kayıt formuna OAuth giriş seçeneği eklemek gibi, bugün yapılabilecek iyileştirmeler dönüşümü artırır
Rakipler o kadar da önemli değil
- Bu yazıda rakiplerden neredeyse hiç söz edilmemesinin nedeni, gerçekte çok büyük etkileri olmamasıdır
- Elbette müşterinin sizi değerlendirmeye alması için temel özelliklere sahip olmanız gerekir, ancak
- asıl rakip, kullanıcının bu ürünün varlığından habersiz olmasıdır
- Özelliklerden bile daha önemli olan rekabet unsuru farkındalık ve erişilebilirliktir
4 yorum
Hizmeti işleten biri olarak, söylenenlerin çoğuna katılıyorum.
Ben de uykumdan kısarak geliştirme yapmıştım ama sağlığım bozuldu..
Benzer deneyimler yaşamış olanlara merak ettiğim şey, bu tür bir zaman yatırımının çocuk yetiştirirken mümkün olup olmadığı.
İşe gidiş geliş süresi, şirkette geçirilen zaman ve evde çocuklarla olunan zaman günün neredeyse tamamını kapladığı için, böyle bir hizmeti oluşturup işletmek için başka bir şeyden vazgeçmek gerekiyor; umarım bu şey aile ya da sağlık olmaz..
Gerçekten öğrenilecek çok şey olan bir yazı. Sabahları ikişer saat ayırıp hem yazı yazması hem de çeşitli projeleri tamamlaması...!
Öğrenecek çok şey barındıran bir yazı. Sonuçta SaaS’in de müşterinin bir sorunu çözmek için işe aldığı bir ürün olduğu gerçeğini unutmamak gerekir.
SaaS'ı tek başıma 1 yıl işletip öğrendiklerim
Aradan şimdiden 3 yıl geçti :) Nelerin değiştiğini karşılaştırarak bakın!