Erken Aşama Girişimleri Sessizce Batıran 9 SaaS Geliştirme Hatası

Neredeyse hiç kimse bir SaaS ürününü bilerek yanlış kurmaz. Erken girişimleri batıran hatalar, baskı altındaki akıllı insanların aldığı sessiz, makul görünen kararlardır — ve o anda hepsi doğru hissettirir. Aynı dokuz hatayı düzinelerce üründe, kurucuların garajlarında da iyi finanse edilmiş ekiplerde de izledik. İyi haber şu: bunlar öngörülebilir, yani kaçınılabilir. Bu, her kurucunun ilk kod satırını yazmadan önce monitörüne yapıştırmasını dilediğimiz listedir.

Küçük ve orta ölçekli işletmeler için yazılım geliştiriyoruz; bu da bizi çok farklı iki anda çağırdıkları anlamına geliyor. Bazen birinci gündür, ortada bir taslak ve bir fikirden başka bir şey yoktur. Çoğu zaman ise, ne yazık ki, dokuzuncu aydır — kurucu birikimini harcamış, ürün teknik olarak çalışıyor, ama yine de kimse bunun için ödeme yapmıyordur. İşte bu ikinci tür çağrı bize bu listeyi öğretti. Her seferinde, otopsi aynı küçük yara grubunu ortaya çıkarır: erken açılmış ve iltihaplanmaya bırakılmış.

Bu hataların hiçbiri yetenekle ilgili değil. Bunları yapanlar genellikle yetkin ve çalışkan kişilerdir. Sorun şu ki SaaS kurmak, kendi fikrinize heyecanlandığınızda doğal olarak gelmeyen, çok belirli bir özdenetimi ödüllendirir. O halde dokuzu, sizi ısırma eğiliminde oldukları kabaca sırayla gözden geçirelim ve her birinin neden bu kadar cazip olduğu konusunda dürüst olalım.

1. Tek bir müşteriyle konuşmadan altı ay boyunca geliştirmek

Bu, asıl günahtır ve en pahalı olanıdır. Bir kurucu fikrin iyi olduğuna ikna olur — ve olabilir de — bu yüzden sessizliğe gömülür, yarım yıl başını kaldırmadan geliştirir ve kimsenin istemediği cilalı bir ürünle ortaya çıkar. Pazar çabayı ödüllendirmez. Birinin ortadan kaldırmak için para ödeyeceği bir sorunu çözmeyi ödüllendirir.

Çözüm karmaşık değil, yalnızca rahatsız edici: hazır olmadan önce kaba bir şeyi gerçek potansiyel müşterilere gösterin. Tıklanabilir bir maket, bir açılış sayfası, hatta hizmetin e-posta üzerinden elle yapılmış manuel bir versiyonu. İnsanların onu istediğini doğrulamadan geliştirdiğiniz her hafta, yanlış sokaktaki bir evi dekore etmekle geçirebileceğiniz bir haftadır.

2. Sahip olmadığınız bir milyon kullanıcı için geliştirmek

İkinci hata profesyonellik kostümü giyer. Kurucu ya da hırslı bir erken mühendis, sistemi birinci günden devasa ölçeği kaldıracak şekilde tasarlar — mikroservisler, Kubernetes, çok bölgeli veritabanları, ayrıntılı önbellek katmanları. Sorumluluk sahibi gibi hissettirir. Aslında bir tuzaktır. En kıt kaynağınızı — zamanı — şanslıysanız sahip olacağınız bir soruna karşı savunmaya harcıyorsunuz.

Sıkıcı, tek veritabanlı bir monolit sizi rahatlıkla ilk birkaç bin kullanıcıya ve ilk gelirinizin çok ötesine taşır. Ölçekte önemli olan mimari kararlar neredeyse hiçbir zaman başlangıçta öngörebileceğiniz kararlar değildir ve erken karmaşıklık ürünü değiştirmeyi yavaşlatır — ki bu, ilk günlerde sizi gerçekten öldüren tek şeydir. Hayali milyonuncu için değil, sonraki on müşteri için geliştirin.

3. Ne minimum, ne uygulanabilir, ne de ürün olan bir MVP

Herkes bir MVP geliştirme konusunda hemfikir. Neredeyse hiç kimse bunu gerçekten yapmaz. Bunun yerine yayınlanan şey, kurucunun hayal edebildiği her özellikle tıka basa dolu, dağınık bir "sürüm bir"dir, çünkü özellik kesmek hırsı kesmek gibi hissettirir. Sonuç üç kat uzun sürer, üç kat pahalıya mal olur ve öğrenmesi daha zordur — çünkü şişmiş bir ürün başarısız olduğunda, hangi parçanın yanlış olduğunu söyleyemezsiniz.

Gerçek bir MVP, birinin ödeme yapacağı kadar iyi tek bir şeyi yapar. Hepsi bu. Disiplin neyi dahil edeceğinize karar vermek değildir; neyi dışarıda bırakacağınıza karar vermektir; ertelediğiniz her "bariz" özelliğin geri kazandığınız bir hafta ve tahmin yerine gerçek kullanıcılarla yanıtlayacağınız bir soru olduğunu bilerek.

Hızlı bir kapsam aklı başında mı testi

Herhangi bir özellik ilk sürüme girmeden önce, kuruculara yüksek sesle tek bir soruyu yanıtlatıyoruz: "Bunsuz yayınlasaydık, ödeme yapan tek bir müşteri ürünü kullanmayı reddeder miydi?" Dürüst yanıt hayırsa, bekler. "Olmazsa olmaz" özellik listenizin ne kadarının bu tek cümlenin altında buharlaştığına şaşıracaksınız.

• Bir özellik kullanıcıya hizmet etmek için değil de yatırımcıları etkilemek için varsa, bekler.
• Bir özellik 20 kullanıcıdan birinden azının karşılaşacağı bir uç durumu ele alıyorsa, bekler.
• Henüz kimsenin değiştirmek istemediği bir davranışı yapılandırmak için ayarlar geliştiriyorsanız, bekler.
• Listede olmasının tek nedeni 'rakipte var' ise, bekler.
• Onu kaldırmak tek bir satışı bile durdurmayacaksa, bekler.

4. Faturalandırma ve katılımı sonradan akla gelen bir şey olarak görmek

Kurucular sevgilerini temel özelliğe dökerler ve lansmandan iki hafta önce, müşterilerin kaydolmaya, ödeme yapmaya ve şeyi gerçekten kullanmaya başlamaya bir yola ihtiyacı olduğunu hatırlarlar. Faturalandırma panik içinde sonradan eklenir. Katılım, bir giriş ekranı ve bir omuz silkmedir. Ama "ilgili ziyaretçi"den "ödeme yapan, etkinleştirilmiş kullanıcı"ya giden yol, işinizin ta kendisidir — ve gelirinizin çoğunun sessizce sızdığı yer burasıdır.

Gerçekten mükemmel bir temel özelliğe sahip ürünlerin, kimse kayıttan sonra ne yapacağını çözemediği için ilk beş dakikada kayıtların çoğunu kaybettiğini gördük. Abonelikler, denemeler, oranlama, başarısız ödemeler, iptaller, yepyeni bir hesabın boş durum deneyimi — bunlar evrak işi değildir. Müşteri için, kalıp kalmamaya karar verdiği anda, gerçek ürünün ta kendisidir.

5. Çok kiracılılığı yanlış yapmak (ya da atlamak)

Bu, felakete dönüşene kadar gayet iyi görünen hatadır. SaaS, çok müşterinin tek bir sistemi paylaşması demektir ve verilerini nasıl ayırdığınız — çok kiracılılık — temel bir karardır. Yanlış yaparsanız ya müşterileri düzgün izole edemeyen bir şey kurarsınız ya da daha kötüsü, bir şirketin başka bir şirketin verilerini görebildiği bir hata yayınlarsınız. Kiracılar arasında bir veri sızıntısından daha hızlı her müşteriyi aynı anda kaybetmenin başka yolu yoktur.

Egzotik bir kuruluma ihtiyacınız yok. Çoğu erken aşama ürünü için, her tabloda ve her sorguda katı biçimde uygulanan bir kiracı kimliğine sahip tek bir paylaşımlı veritabanı gayet yeterlidir — izolasyonun temele inşa edilmesi ve test edilmesi şartıyla, sonradan serpiştirilmesi değil. Hata, basit yaklaşımı seçmek değildir. Hata, bilinçli olarak karar vermemek ve boşluğu zaten üretimdeyken keşfetmektir.

6. Kullanıcıların ne yaptığını görecek bir yol olmadan karanlığa yayınlamak

Yayınlıyorsunuz. İnsanlar kaydoluyor. Ve sonra... sessizlik. Hangi özelliklere dokunduklarına, nerede takıldıklarına ya da neden ayrıldıklarına dair hiçbir fikriniz yok. Bu yüzden tahmin ediyorsunuz. Bir önseziye, en yüksek sesli müşteri e-postasına ya da kendi sezginize dayanarak sonraki özelliği geliştiriyorsunuz — ki bu, kendi ürününüzün içinde aylar geçirdikten sonra sahip olduğunuz en güvenilmez araçtır.

Temel ürün analitiği ve geri bildirim toplamak için basit bir yol, büyüme aşamasına özgü bir lüks değildir. Yön bulma şeklinizdir. Bunlar olmadan bir iş yürütmüyorsunuz, pahalı bir kanı yürütüyorsunuz. "Kullanıcıların %80'i iki ayımı verdiğim özelliği hiç açmıyor" kadar basit bir şeyi bilmek bile, körlemesine iki ay daha geliştirmekten daha değerlidir.

7. Güvenliği ve yedeklemeleri 'sonraya' bırakmak

Hız, erken aşamanın dinidir ve çoğunlukla bu doğrudur. Ama sonradan eklenmesi felaket derecede pahalı olan küçük bir şeyler grubu vardır ve güvenlik listenin başındadır. Parolaları düzgün saklamak, kimin neye erişebileceğini kilitlemek ve — lütfen — çalışan, test edilmiş yedeklere sahip olmak, vaktiniz olunca eklediğiniz isteğe bağlı özellikler değildir. Üzerine inşa ettiğiniz zemindir.

Bu kategorinin acımasız yanı, yapmayana kadar yanına kâr kalmasıdır. Bir yıl boyunca her şey yolundadır, sonra tek bir ihlal, tek bir kazara toplu silme, tek bir fidye yazılımı sabahı, o yıl inşa ettiğiniz güveni ve veriyi siler. Bir güvenlik departmanı istemiyoruz. Temellerin baştan var olmasını istiyoruz, çünkü bir olaydan sonra eklemenin maliyeti ölü şirketlerle ölçülür.

8. Yanlış aşama için yanlış geliştiriciyi işe almak

Teknik olmayan kurucular acımasız bir seçimle yüzleşir: bunu gerçekten kim kuracak? İki klasik hata birbirinin aynasıdır. Biri, doğru görünen ama bantla tutturulmuş bir şey teslim eden, sonra değiştirmeniz gerektiği an dağılan, mümkün olan en ucuz serbest çalışanı işe almaktır. Diğeri ise fazla işe almaktır — henüz tek bir müşteri kazanmamış bir ürünü geliştirmek için tam maaşlı tam bir kıdemli ekip.

Dürüst yanıt tamamen nerede olduğunuza bağlıdır. Bir fikri doğrulamak için, daha önce erken aşama ürünler kurmuş, neyi dışarıda bırakacağını tam olarak bilen küçük, kıdemli, pragmatik bir ekip istersiniz. Kanıtlanmış bir ürünü ölçeklemek için farklı içgüdülere sahip farklı insanlar istersiniz. Geliştiriciyi aşamaya uydurmak başlı başına bir beceridir — ve bunu yanlış yapmak, bu listedeki herhangi bir teknik karardan daha çok para harcatır.

9. Lansmanı bitiş çizgisi olarak görmek

Son hata en üzücü olanı, çünkü onca zorlu çalışmadan sonra gelir. Ekip lansman gününü hedef olarak görür, oraya varmak için her şeyi ortaya koyar ve plansız, bütçesiz ve bundan sonra geleni için enerjisiz, tükenmiş halde varır. Ama lansman bitiş çizgisi değildir. Önemli olan tek aşamanın başlangıcıdır: gerçek kullanıcılardan öğrenmek ve hafta hafta iyileştirmek.

Bir SaaS ürünü asla "bitmiş" değildir. İlk sürüm bir hipotezdir ve lansmandan sonraki aylar, onun ne kadar yanlış olduğunu — iyi anlamda — keşfettiğiniz zamandır. Bunu planlayan, yedekte biraz pist ve bolca merak tutan kurucular, sallantılı bir lansmanı gerçek bir işe dönüştürenlerdir. Başlangıç çizgisine ulaşmak için her şeyini harcayanlar genellikle bundan çok daha ileriye gidemez.

Dokuzundan da gerçekten nasıl kaçınılır

Bir hata listesi okumak kolaydır. Teslim tarihi baskısı altında, kendi paranız ortadayken ve kendi fikriniz kalbinizdeyken onlardan kaçınmak gerçekten zordur. İşte doğru yapan kurucuların nasıl çalışma eğiliminde olduğunun kısa versiyonu — kurallar olarak değil, çalınmaya değer alışkanlıklar olarak.

1. 1
   Geliştirmeden önce doğrulayın

   Ciddi kod yazmadan önce kaba bir şeyi gerçek potansiyel müşterilerin önüne koyun ve ödeyeceklerini doğrulayın. Yapması ucuz, atlaması acımasız.
2. 2
   En küçük gerçek ürünü seçin

   Ürününüzün yapması gereken tek şeyi tanımlayın ve geri kalan her şeyi acımasızca erteleyin. 'Sürüm bir'in bilerek neyi içermediğini yazın.
3. 3
   Sıkıcı kurun ve kiracıları izole edin

   İşe yarayan en basit mimariyi kullanın, ama müşteriler arası veri ayrımını birinci günden temel, test edilmiş bir karar yapın.
4. 4
   Para yolunu erken tasarlayın

   Kaydı, katılımı ve faturalandırmayı evrak işi değil, temel ürün olarak görün. İlk beş dakika, geri kalanın görülüp görülmeyeceğini belirler.
5. 5
   Ölçümleyin, sonra öğrenmek için yayınlayın

   Temel analitik ve geri bildirim hazırken yayınlayın, lansman sonrası aşama için pist tutun ve ilk sürümü bir yanıt değil, bir soru olarak görün.

Bunların neredeyse hiçbirinin kodlama becerisiyle ilgili olmadığına dikkat edin. Muhakemeyle ilgili — ne geliştireceğinizi, neyi atlayacağınızı ve ne zaman olduğunu bilmek. İşte tam da bu yüzden teknik olarak çok yetenekli ekipler bile başarısız ürünler üretir: SaaS'ın zor kısmı asla mühendislik değildi. Özdenetimdi.

Sık sorulan sorular