Geliştiricilerle Logto'nun büyümesini yönetirken öğrenilen dersler ve uygulamalar.
Logto, açık kaynaklı, geliştirici odaklı bir üründür. İşte pazara çıkış zaman çizelgemiz:
Verimlilik araçları için ürün odaklı büyüme geçmişinden geldiğim için, ekiplerim ve ben Logto için farklı pazara çıkış stratejileri denedik. İki yılın ardından, bu çabaları ve attığımız adımları düşündüm. Bu yolculuğun bir kısmını paylaşmak ve neden bazı şeylerin o zaman işe yaramadığını açıklamak istiyorum. Bunlar "hatalar" değil, deneyimlerimizden elde edilen değerli derslerdir. Umarım bu görüşler, benzer projelerde veya girişimlerde çalışan diğer kişilere yardımcı olur.
Ürününüzü ilk kez piyasaya sürdüğünüzde, özellikle bir ürün büyüme zihniyeti veya biraz deneyimle, her türlü heyecan verici fikri düşünmek kolaydır: şık karşılama süreçleri, web sitesinde harika bir demo, kullanıcılar için değeri vurgulamanın havalı yolları ve onları hızlıca "ah-ha" anına götürme. Ürünümüzü cilalı ve ticarete hazır göstermek için iki aktivasyon stratejisi uyguladım:
Bu stratejiler, geçmiş deneyimlerimde çok başarılı olmuştu. Bu yüzden Logto'nun bulut barındırılan sürümünü başlattığında, hemen uyguladım. Ancak, bazı karışıklıklar ve zorluklarla karşılaştım:
Geliştirici ürünleri için, sorunları kısa sürede çözmek zordur, hatta gerçekten kendin-yap-tarzında olsa bile. Tek bir geliştirici için bile süreç, doğru teknoloji yığını ile bütünleşmeyi, bir kavram kanıtı oluşturmayı, bir geliştirme ortamında test yapmayı ve ardından üretime geçmeyi içerir. Bu yolculuğun herhangi bir noktasında kullanıcılar ayrılabilir. "Yapılması gereken iş" basit, tek adımlı bir görev değildir. Geliştirici ihtiyaçları genellikle karmaşıktır ve mevcut yeteneklerimizi değerlendirerek kapsamlı bir tasarım gerektiren bir dizi özellik veya teknik senaryoyu gerektirir. Bu tür sorunları çözmek zaman alır ve aceleye getirilemez.
Geriye dönüp baktığımda, neden bu yaklaşımın başarıya ulaşmadığına dair net bir görüşüm var. İlk başlattığımızda, günlük kayıtlarımız ve organik trafiğimiz oldukça düşüktü. Trafiğimizin çoğu, doğal olarak daha büyük müşteriler getirmeyen açık kaynak topluluğundan geliyordu. Bu aşamada daha büyük müşterilerin çağrı rezervasyonu yapmaması şaşırtıcı değildir. Düşük trafik ve kullanıcılarımızın kaynağı, erken aşamada önemli çağrı rezervasyonları beklemeyi gerçekçi kılmadı.
Kullanıcı aktivasyonu için gereken süreye bağlı olarak ürününüze uygun modeli seçin. Sektörel normların sizi kısıtlamasına izin vermeyin.
Bir SaaS ürünü oluştururken, en önemli pazara çıkış (GTM) sorularından biri, ücretsiz mi yoksa ücretsiz deneme mi seçileceğidir. Genel olarak bilinen öneriler şöyledir:
Hızlı bir başlatma için başlangıçta ücretsiz bir model seçtik, ücretsiz ve ücretli planlar arasında katı bir ödeme duvarı koyduk. Ancak, geliştiriciler ücretsiz katmanda SSO veya Organizasyon gibi gelişmiş özelliklere erişemediler.
Hangi modelin daha iyi olduğuna dair çevrimiçi çok sayıda tartışma olsa da, ürününüzün aktivasyon zaman çizelgesini düşünmek önemlidir. Logto için gerçek dünyada test aşamasının 6 aya kadar sürebileceğini gözlemledik. Bu, Logto'nun karmaşıklığından değil, mühendislerin çalışma programı, proje planlaması, takım iş akışları ve tahmin etmediğimiz diğer faktörlerden kaynaklanıyor.
Bu uzun aktivasyon süresi düşünüldüğünde, geliştiricilere tüm özelliklere test için tam erişim sağlamak önemlidir. Bu nedenle, geliştirme kiracısını tamamen kullanarak ürünün tüm yeteneklerini açıyoruz. Bu, geliştirici araçlarında yaygın bir uygulamadır ancak bizim için neden geleneksel ücretsiz veya ücretsiz deneme stratejilerinin işe yaramayabileceğini açıklamaktadır.
Seçim, ürününüzün doğası ve benimsenme zaman çizelgesi ile uyumlu olmalıdır. Ürününüzün benzersiz özelliklerini anlayın ve kullanıcıları dönüşüm kanalınızdan çok hızlı itmeden uygun bir model seçin.
Aşağıdan yukarıya bir stratejiyle GTM uygulamak, genellikle SEO, ürün pazarlaması ve içerik pazarlaması içerir. Hepimiz erken başlamanın önemli olduğunu biliyoruz, bu yüzden açık kaynak sürümünü başlattıktan hemen sonra içerik oluşturmaya başladık. Ancak ilk kez makaleler yazmaya karar verdiğimizde, büyük bir sorum vardı: Ne yazmalıyım?
Bir ürün tasarımcısı olarak içgüdüm, belirli özellikleri neden tasarladığımızı, bunların ardındaki düşünce sürecini ve felsefeyi açıklayan yazılar yazmak idi.
"Bu yazıda, Oturum Açma Deneyimimizin tarihçesini, oluşturulma konseptini, tasarım kararlarını ve ürün ödünleşimlerini ele alacağız. Ayrıca başarılı ve sürtünmesiz bir oturum açma veya kayıt olma deneyimi nasıl inşa edileceğine dair daha iyi bir kavrayış kazanacaksınız." - 2 yıl önceki blog yazımız Sürtünmesiz oturum açma deneyimi için tasarım düşünceleri (Birinci Bölüm)
Özelliklerimizi ve tasarımımı paylaşmak için çok hevesliyim çünkü onlara çok fazla çaba sarf ettim. Ama geriye dönüp baktığımda, bunun "bencil" içerik olduğunu fark ettim. İyi geliştirilen bir EPD (Mühendislik, Ürün, Tasarım) kültürüne sahip yerleşik şirketlerde yaygındır.
Ürün tarafından yönlendirilen bir büyüme yapıyorsanız, özellikle ürününüz hâlâ "insanların sizden bahsedeceği" aşamaya ulaşmadıysa, içeriğinizin hedef kitleniz için açık bir değeri ve amacı olması gerekir. Çok fazla kendiniz odaklı olmaktan kaçının.
Örneğin, bir özelliğin neden tasarlandığına odaklanmak yerine, belirli terimlerin açıklandığı eğitim makaleleri oluşturun veya yaygın bir teknik sorunu çözmek için havalı bir teknoloji veya araç entegre etme yollarını gösteren eğitimler hazırlayın.
Ürününüzü ve müşterilerinizi daha iyi tanıdıkça, neyin izleyicinize gerçekten önemli olduğuna dair güçlü düşünceler doğal olarak gelişecektir. "Müşteri odaklı" bir yaklaşım benimsemek, içerik kalitenizi iyileştirmenize yardımcı olacaktır. Zamanla, izleyicinizle rezonansa giren içerikler yazabileceksiniz. Aksi takdirde, içeriğiniz bencil gibi hissedilmeyecek.
Geleneksel pazarlama, işletmelere veya bireylere satış yaparken sıklıkla "en iyi uygulamalar" veya "çözümler" üzerine vurgu yapar, çünkü SaaS ürünleri esas olarak verimlilik ve üretkenliği sağlar. Birçok strateji, yararları vurgulamak için finansal tasarrufları gösteren rakamlara odaklanır. Bu, geniş bir müşteri tabanına sahip olgun şirketler için iyi çalışabilir, ancak gelişimciler için itici olabilir.
İki yıl önce, ürünümüz için değer önerileri oluşturmaya ve üst düzey bir anlatı oluşturmaya yoğun bir şekilde odaklandım. Ancak, bu yaklaşım her zaman geliştirici kitle ile bağlantı kurmadı.
İki yıl önce sahip olduğumuz web sayfasına bir göz atın—"Geleceği şekillendirmek"... Vay!
Geliştiricileri memnun etmek ve sorunlarını çözmek söz konusu olduğunda, çok pratik ve gerçekçi olmak gerekir. Geliştiriciler, yüksek faydalardan etkilenmezler; özelliklerin bulunabilirliği ve esneklikleri önemserler—özellikle, ürününüzün mevcut teknoloji yığınlarına ne kadar kolay entegre olabileceği. Eğer olamıyorsa, satmaya çalışmayın.
Artık içerik stratejimiz çok daha odaklı. Sunmuş olduğumuz belirli özellikleri vurguluyoruz, böylece kullanıcılar ilk ekrandan itibaren ne sunduğumuzu hızlıca anlayabiliyorlar, anahtar kelimelere veya üst düzey mesajlara bağımlı olmadan.
Barındırılan ticari sürümümüzü ilk başlattığımızda, ekip içinde her zaman ateşli bir tartışma vardı: Açık kaynak barındırma sürümümüze zarar verir mi, çünkü o ücretsizdir ve hedef kitlemiz geliştiricilerdir? İleri düzey özelliklerimizin bazılarını açık kaynak sürümde sınırlamalı mıyız diye de tartıştık.
Şu ana kadar, hem açık kaynak hem de barındırılan sürümde çekirdek özelliklerin neredeyse aynı kalmasını sağladık. Açık kaynak topluluğumuzun büyümesi, kurumsal müşterilerle önemli bir güven oluşturdu ve daha büyük işletmeler ekibimize katıldı. İlginç bir şekilde, bu işletmelerin bazıları topluluğumuzdaki geliştiriciler olarak başladı. Bu bize büyük bir güven verdi. Harika ürünler yapmaya, mükemmel hizmetler sunmaya ve geliştiricilerin sorunlarını çözmelerine yardım etmeye devam ettiğimiz sürece, ister kendin-yap büyümesi ister doğrudan kurumsal satışlar yoluyla olsun, başarı doğal olarak gelecektir.
Sonuç olarak, geliştirici sorunlarını ürün veya hizmet yoluyla çözmekle ilgilidir. Sabırlı olun ve odaklı kalın, her şey doğal olarak yerine oturacaktır.
Okuduğunuz için teşekkürler, benzer bir şey üzerinde çalışıyorsanız, deneyimlerinizi ve düşüncelerinizi paylaşmaktan çekinmeyin!