05 Şub 2026·7 dk
AI ile Kurulan Bir SaaS'in İlk 30 Günü: Önce Neleri Düzeltmelisiniz?
AI ile kurulan bir SaaS'in ilk 30 gününde, büyük özellikler eklemeden önce destek, analitik, hızlı düzeltmeler ve fiyat geri bildirimlerine odaklanın.
AI ile kurulan bir SaaS'in ilk 30 gününde, büyük özellikler eklemeden önce destek, analitik, hızlı düzeltmeler ve fiyat geri bildirimlerine odaklanın.
Lansmandan sonraki ilk 30 gün nadiren sakin olur. Net sinyaller bekliyorsunuz, ama erken kullanıcılar aynı anda sorular, hatalar, özellik talepleri ve fiyat tereddütleri getirir. Her şeyin eşit derecede önemliymiş gibi görünmesi mümkün, oysa öyle değildir.
Bu gürültünün bir kısmı kullanıcıların kendisinden gelir. Erken benimseyenler farklı şeyler ister. Bir kişi hız ister, başka biri rafinelik ister, bir başkası ise siz hiç planlamadığınız bir özelliği talep eder. Koder.ai gibi bir araçla veya hızlı bir platformla hızlı başladıysanız, bu hız bir avantajdır. Ancak insanlar sınırları hemen test etmeye başlar.
Küçük problemler ilk ayda daha büyük hissedilir. Bir oturum açma sorunu, bozuk bir buton veya kafa karıştıran bir kurulum adımı eksik bir özellikten daha fazla zarar verebilir. Yeni kullanıcılar henüz size güvenip güvenmemeye karar veriyor. Temel bir şey işe yaramazsa, "Bu küçük bir hata" demezler. "Belki bu araç hazır değil" diye düşünürler.
Bu yüzden bu aşama dağınık hisseder. Sadece fikir toplamakla kalmazsınız. Sinyali gürültüden ayırıp insanların gerçekten ne kullandığını öğrenmeye çalışırsınız. Daha büyük bir yol haritası oluşturmadan önce, kullanıcıların mevcut sürümden değer alabildiğine dair kanıt gerekir. Bir avuç gerçek eylem, uzun bir dilek listesinden daha önemlidir.
Fiyatlandırma ayrı bir karışıklık katmanı ekler. İlk başta maliyetle ilgili yorumlar basit itirazlar gibi gelebilir. Çoğu zaman bunlar aslında güvenle ilgilidir. Kullanıcılar bir planın neden bu fiyatta olduğunu sorduklarında, ürünün ödemeye değecek kadar güvenilir, kullanışlı ve net olup olmadığını soruyor olabilirler.
Basit bir örnek görmek için işe yarar. Eğer üç erken kullanıcı farklı yeni özellikler isterse ama iki tanesi onboarding sırasında takıldıysa, daha büyük problem eksik işlevsellik değildir. Gerçek sorun, kullanıcıların ürünün çalıştığını görmeden önceki sürtünmedir. İlk ayda her zayıf nokta bir anda ortaya çıkar.
Daha fazla kanal daha iyi destek demek değildir. Canlı sohbet, e-posta, bir topluluk, sosyal DM'ler ve bir formu hepsini bir anda açarsanız, mesajlar kaçırılır ve kullanıcılar güveni hızla kaybeder.
Kullanıcılarınız için doğal hissettiren bir veya iki yerle başlayın. Çoğu erken ürün için bu, e-posta veya uygulama içi sohbet gibi doğrudan bir kanal ve basit bir yardım sayfası veya SSS gibi bir self-servis yerdir.
Bu kurulum, kendinizi fazla yormadan insanların neye ihtiyaç duyduğunu öğrenmek için yeterlidir.
İlk günden itibaren yanıt sürelerini netleştirin. Hafta içi genellikle dört saat içinde cevap veriyorsanız bunu söyleyin. Haftasonları daha yavaşsa onu da belirtin. İnsanlar ne bekleyeceklerini bildiklerinde biraz beklemeye genellikle razıdır. Kimsenin mesajı görüp görmediğini bilmemek sinir bozucu olur.
Kalabalıklaşan soruları bir yerde biriktirin; kalıplar ortaya çıkar çıkmaz. Henüz büyük bir bilgi tabanına ihtiyacınız yok. Sadece tekrar tekrar gelen sorunlar için kısa bir cevap listesi tutun: oturum açma problemleri, fatura karışıklığı veya beklenenden farklı davranan bir özellik gibi.
Burada işe yarayan basit bir kural: aynı soruyu üç kez yanıtladıysanız, not edin.
Kullanıcıların nereden yardım istediğine dikkat etmek kadar, sormadan nereden ayrıldıklarına da bakın. İnsanlar sürekli kurulumla ilgili e-posta atıyorsa onboarding'iniz net olmayabilir. Uygulamayı açıp tıklayıp kayboluyorlarsa, sormayı bile bilmiyor olmadan takılıyor olabilirler.
Bu, teknik olmayan kullanıcılara yönelik ürünler için daha da önemlidir. Örneğin Koder.ai'de sohbetten uygulama yapan biri teknik terimi bilmiyor olabilir. "Uygulamam mobilde yanlış görünüyor" diyebilir, bu bir düzen problemi tarif etmek yerine. Destek sisteminizin düz dilde sormalarını kolaylaştırması gerekir.
Tekrar eden soruları takip edin. Her mesaj bir özellik isteğine dönüştürülmemeli. Tekrarlanan destek sorunları genellikle daha iyi etiketler, daha net adımlar veya herkesin sürtünmesini kaldıracak küçük bir düzeltme işaret eder.
Kayıtlar heyecan verici görünebilir, ama ürünün çalışıp çalışmadığını söylemezler. Erken dönemde işe yarayan basit soru şudur: yeni kullanıcılar değeri yeterince hızlı alıp geri dönüyor mu?
Aktivasyonla başlayın. Kullanıcının ürünün ana faydasına ulaştığını gösteren bir erken eylem tanımlayın. Bir SaaS için bu bir proje oluşturmak olabilir. Koder.ai gibi bir platformda bu, bir sohbet istemini çalışan bir uygulama taslağına dönüştürmek olabilir. İnsanlar kayıt oluyor ama o noktaya ulaşmıyorsa, daha fazla trafik sorunu çözmez.
Tutunma (retention) da en az bunun kadar önemlidir. İlk oturumdan sonra, birkaç gün sonra ve bir hafta sonra kaç kullanıcının geri döndüğünü kontrol edin. Henüz büyük bir pano gerekmez. Kim kaydoldu, kim aktive oldu ve kim geri döndü sorularını cevaplayan basit bir haftalık tablo yeterlidir.
İzlemeniz gereken başka bir sayı başarısız eylemler. Bunlar kullanıcıların önemli bir şeyi yapmaya çalışıp takıldığı anlardır. Bozuk bir onboarding adımı, başarısız bir yayın akışı, zaman aşımına uğrayan bir üretim veya faturalama sırasında oluşan karışıklık olabilir. Başarısız eylemler genellikle kötü yorumların ortaya çıkmadan önceki nedenidir.
Ayrıca insanların nerede yardım istediğini takip etmek faydalıdır. Soruların çoğu aynı ekrandan veya kurulum adımından geliyorsa, o bölgeye dikkat edin. Destek mesajları analitikten ayrı değildir; onlar ürün sinyalinin parçasıdır.
İlk skor kartınızı küçük tutun:
Haftalık incelemenize iki etiket daha ekleyin: churn nedenleri ve iade talepleri. "Çok pahalı" yazmakla kalmayın. Gerçek nedeni not edin: eksik özellik, kafa karıştıran kurulum, zayıf sonuçlar veya güvenilirlik sorunları olabilir.
Aynı sayıları her hafta, aynı sırayla gözden geçirin. Bu alışkanlık mükemmel araçlardan daha önemlidir. Ölçmeyi sürekli değiştirdiğinizde küçük trendleri kaçırmak kolay olur.
Kullanıcılar ilk ay mükemmellik beklemez. Ancak önemli anlarda ürünün çalışmasını beklerler. Bir sayfa takılırsa, bir kaydetme başarısız olursa veya bir giriş e-postası hiç gelmezse, güven hızla düşer. Bu, sade tasarım veya eksik bir özellikten daha zararlıdır.
Kullanıcıların değere ulaşması için tamamlaması gereken akışlarla başlayın: kayıt olma, giriş yapma, bir şey oluşturma, kaydetme, ödeme ve sonra geri gelme. Bunlardan herhangi biri bozulmuşsa, renkler, boşluk veya küçük UI detaylarını cilalamadan önce bunları düzeltin.
Burada işe yarayan basit bir kural: manzarayı iyileştirmeden önce yolu onarın. Çalışan ama kaba bir ekran, veri kaybeden güzel bir ekrandan daha güven vericidir.
Acil düzeltmeler genellikle birkaç tahmin edilebilir gruba girer: faturalama sorunları, giriş problemleri, yavaş sayfalar ve kaydetme hataları veya ilerlemeyi durduran bozuk onboarding adımları. Bu problemler kullanıcıların ürünün kendisinden şüphe etmesine yol açar.
Onboarding özel dikkat gerektirir çünkü kafa karışıklığı ürün zayıflığı gibi görünür. Kullanıcıların sonraki ne yapacağını tahmin etmek zorundaysa veya ilk görev çok fazla adımdan oluşuyorsa, tüm uygulamanın kullanımı zor olduğu izlenimine kapılabilirler. Adımları azaltın, daha net etiketler ekleyin ve bir sonraki yapılacak açıkça gösterin.
Hız da güveni etkiler. Bir sayfanın anında olması şart değil, ama duyarlı hissettirmesi gerekir. Bir şey birkaç saniye sürüyorsa, ilerlemeyi gösterin ve başarıyı net şekilde onaylayın. Sessizlik insanların yeniden denemesine neden olur; yeniden denemeler ise çoğaltılmış eylemler, destek talepleri ve stres yaratır.
Bir düzeltme canlıya alındığında kullanıcılara söyleyin. Kısa bir mesaj, Dün yaşanan kaydetme hatasını düzelttik, döngüyü kapatır ve birilerinin dikkat ettiğini gösterir. Koder.ai üzerinde inşa ediyorsanız, snapshot ve rollback gibi özellikler bu hızlı onarımları daha güvenli hale getirebilir.
Problemler hızlı, net ve mazeret içermeden ele alındıkça güven artar.
Fiyat yorumları faydalıdır ama bağlam içinde okunmalı. Erken kullanıcılar genellikle "çok pahalı" dediğinde aslında "henüz güvenmiyorum" veya "değeri görmüyorum" demek istiyordur.
Fiyat tepkisi aldığınızda bir takip sorusu sorun: fiyatı yüksek veya düşük hissettiren nedir? Cevap genelde gerçek sorunu ortaya çıkarır. Küçük bütçesi olan biri, henüz sunmadığınız bir özelliği bekleyen birinden farklıdır.
Bu ayrım önemlidir. Bütçe endişeleri şu an için müşteri olmadığını söyleyebilir. Ürün boşlukları ise doğru müşterinin neden ödeme yapmadığını gösterir.
Fiyat geri bildirimi aldığınız her seferinde üç detayı not etmek yardımcı olur:
İlk gün deneyen bir deneme kullanıcısı, ürünüyle gerçek bir sorun çözmüş bir kullanıcıyla farklı düşünür. Örneğin Koder.ai'de ilk versiyonunu oluşturan bir kurucu, kurulumu bitirmeden fiyata itiraz edebilir. Bu her zaman planın yanlış olduğu anlamına gelmez; değerin bariz olduğu ana ulaşmamış olabilirler.
Tepkiler değil kalıplar arayın. Tek bir yüksek sesli görüş sizi yanlış yöne çekebilir. Beş benzer durumda insanın ücretsiz planın çok erken bittiğini söylemesi gerçek bir sinyaldir. Bir kişi başlangıç fiyatında kurumsal özellikler istiyorsa genellikle önemli değildir.
Büyük bir fiyat değişikliği yapmadan önce küçük ayarlamaları test edin. Daha net plan isimleri, farklı kullanım limitleri veya daha basit bir karşılaştırma tablosu fiyatın adil görünmesini değiştirebilir.
Ayrıca tekrar eden ifadeleri dinleyin. "Şu olsaydı öderdim..." gibi cümleler, aynı sonucun tekrarlandığı yerlerde işe yarar hale gelir. Bu, fiyat geri bildiriminin eyleme dönüştürülebilir bir şeye dönüşmesidir.
İlk ay her şey acilmiş gibi gelir; bu yüzden basit bir ritme ihtiyacınız vardır. Basit bir haftalık inceleme, sinyali gürültüden ayırmanıza ve her isteğin peşine düşmeden istikrarlı ilerleme sağlamanıza yardımcı olur.
Her gün için kısa bir inceleme bloğu seçin. Bir yangın durumu yoksa 30–60 dakikayı aşmayın. Amaç daha fazla toplantı değil. Amaç kalıpları erken fark etmek ve ürün küçükken bunlar üzerinde harekete geçmektir.
İşleyen bir örüntü şöyle görünebilir:
Bu işe yarar çünkü her gün farklı bir soruyu cevaplar. Destek insanların nerede takıldığını gösterir. Analitik bu sorunların davranışı etkileyip etkilemediğini söyler. Küçük düzeltmeler geri bildirimi görünür ilerlemeye dönüştürür. Kullanıcı görüşmeleri sayılar arkasındaki hikâyeyi açıklar. Cuma reset'i ise backlog'unuzun dilek listesine dönüşmesini engeller.
İncelemeyi hafif tutun. "Ne gördük", "ne değiştirdik" ve "gelecek hafta neyi izleyeceğiz" olmak üzere üç basit sütunlu bir paylaşılan doküman veya panoya sahip olun. Beş kullanıcı bozuk bir onboarding adımını rapor ettiyse, bu en üste gider. Bir kişi büyük bir yeni özellik isterse genellikle bekler.
Küçük bir ekip Koder.ai kullandığında, birkaç kullanıcının sohbette bir uygulama fikri oluşturup deploy etmeden takıldığını fark edebilir. Bu, başka bir şablon eklemektense haftalık odak için daha iyi bir problemdir. Engeli düzeltin, sayıları izleyin, sonra sıradaki dikkati ne hak ediyorsa ona karar verin.
İyi yapıldığında bu rutin güveni hızla inşa eder. Kullanıcılar hataların düzeldiğini, fiyat sorularının not alındığını ve ürünün her hafta daha kolay kullanıldığını görür.
Küçük bir ekibin 25 erken kullanıcısı olduğunu hayal edin. İlk hafta 10 kişi kaydolur ama sadece dördü kurulumu tamamlayıp ürünün faydalı olduğu noktaya ulaşır.
Bu fark neredeyse her şeyden daha önemlidir. Takımın büyüme değil, aktivasyon sorunu olduğunu anladığını gösterir.
Destek mesajlarını okuduktan sonra bir desen fark ederler. Soruların çoğu eksik özelliklerle ilgili değil. Bir kafa karıştıran onboarding adımıyla ilgilidir: kullanıcıların neden veri bağlamaları gerektiğini anlamadan veriyi bağlamaları isteniyor.
Takım planladıkları panoyu yapmak yerine küçük bir değişiklik yapar. Kurulum ekranını yeniden yazarlar, sade bir örnek eklerler ve bir isteğe bağlı adımı daha sonra alacak şekilde taşırlar.
Sonuç basit ama önemlidir:
Ayrıca aynı fiyat yorumu iki kere duyulur. İki kullanıcı fiyatın kendisinin çok yüksek olmadığını, ama planların belirsiz olduğunu söyler: şimdi ne aldıklarını, hangi limitlerin olduğunu ve ne zaman yükseltmeleri gerektiğini anlayamıyorlardır.
Bu bir mesajlaşma sorunudur, indirim sorunu değil. Takım fiyat sayfası metnini günceller, plan farklarını daha kolay taranır hale getirir ve yükseltme noktasını tek bir cümleyle açıklar.
Haftanın sonunda, büyük özellik üzerinde çalışmaya devam etmek veya her yeni kullanıcının önce gördüğü yolu düzeltmek arasında bir seçimleri olur.
Bir hafta daha büyük özelliği ertelemeye karar verirler.
Küçük bir SaaS için bu genellikle daha akıllıca bir hamledir. Küçük bir onboarding düzeltmesi, nadiren ulaşılacak parlak bir sürümden çok daha fazla aktivasyon sağlayabilir.
Erken ivme gerçek hayatta genellikle böyle görünür. En iyi sonraki adım en gürültülü olan değildir. Daha fazla kişinin yardım istemeden değer almasını sağlayan düzeltmedir.
İlk ay yanıltıcı şekilde yoğun hissedebilir. Aynı anda talepler, hata raporları, fiyat fikirleri ve yeni özellik önerileri gelir. Gerçek risk çok yavaş ilerlemek değil; her sinyali aynı önemdeymiş gibi ele almaktır.
Yaygın hatalardan biri en yüksek sesli kullanıcı için inşa etmektir. Erken bir müşteri özel bir özellik isterse, özellikle ürününüz hızlı güncellenebiliyorsa acilmiş gibi gelebilir. Ancak bir kişiye yardımcı olup herkesin kafasını karıştıran bir özellik erken borç yaratır. Bir şey eklemeden önce tekrar eden bir problemi çözüp çözmediğini yoksa sadece bir istisna mı olduğunu sorgulayın.
Bir başka hata her şeyi ölçmeye çalışmaktır. Yeni kurucular genellikle beş pano açıp her tıklamayı, sayfa görüntüsünü ve eventi takip eder. Bu dikkatli görünür ama genellikle temeli gizler. İlk ay için birkaç sayı yeterlidir: kayıtlar, aktivasyon, tutunma ve en yaygın destek sorunu.
Destek de hızla karışabilir. Kullanıcılar canlı sohbet, e-posta, X, Discord ve kişisel DM'lerde size ulaşmaya başlarsa basit sorular gözden kaçar. Küçük bir ürün bile net hatlara ihtiyaç duyar. Bir ana destek kanalı ve bir yedek seçin, sonra kullanıcılara nereye gideceklerini söyleyin.
Fiyatlandırma hataları genellikle zayıf kanıttan gelir. Bir kişi planınızın çok pahalı olduğunu söyler, siz indirirsiniz. Başka biri çok ucuz olduğunu söyler, siz daha çok katman eklersiniz. Bu öğrenmeye değil, gürültüye yol açar. Doğru tip kullanıcıdan aynı itirazı birkaç kez duyana kadar bekleyin.
En zararlı hata hataları saklamaktır. Erken kullanıcılar mükemmellik beklemez. Dürüstlük beklerler. Bir şey bozulduğunda ne olduğunu, kimi etkilediğini ve ne zaman düzeleceğini söyleyin. Basit bir açıklama sessizlikten daha çok güven korur.
İlk ay için daha iyi bir kural şudur:
Bu, Koder.ai gibi hızlı yayımlama yapabildiğiniz platformlarda daha bile önemlidir. Hız gerçek bir avantajdır, ama sadece güvene, netliğe ve kullanıcıların her gün karşılaştığı sorunlara odaklandığında işe yarar.
Başka bir özellik eklemeden önce ürünün insanları işe yarar bir sonuca ulaştırıp ulaştırmadığını kontrol edin. Erken dönemde daha fazla kod gerçek problemi gizleyebilir, çözmeyebilir.
Basit bir kural yardımcı olur: yeni kullanıcılar kafası karışık, takılı veya erken ayrılıyorsa, daha fazla inşa etmek genellikle işleri daha da kötüleştirir.
Koder.ai gibi hızlı inşa edilen bir platform kullanıyorsanız, her gün yeni fikirler yayınlamak cazip olabilir. Hız ancak doğru probleme yönelik olduğunda değerlidir. Bu hızı onboarding sürtüşmesini düzeltmek, tekrar eden destek sorunlarını kaldırmak ve değere giden yolu sıkılaştırmak için kullanın.
İyi bir test şöyle: bu hafta 10 yeni kullanıcı katıldıysa, nerede takıldıklarını, neden kaldıklarını ve neredeyse neden ayrıldıklarını bilir miydiniz? Cevabınız hayırsa, özellik çalışmalarını durdurup önce bunu temizleyin.
İlk aydan sonra işiniz değişir. Artık insanların meraklı olduğunu kanıtlamaya çalışmıyorsunuz. İnsanların ürünü kullanabildiğini, değeri aldığını ve geri döndüğünü kanıtlamaya çalışıyorsunuz.
Gelecek 30 gün için kısa bir öncelik listesi tutun. Büyük bir yol haritası veya dilek listesi değil. Sadece ürünü daha güvenilir ve kullanımı daha kolay yapacak birkaç değişiklik.
İyi bir liste genellikle şunları içerir:
Aynı istek aynı sebeple birden fazla defa gelmediği sürece özellik eklemeyin. Bir yüksek sesli kullanıcı sizi alabora edebilir. Tekrarlayan sinyaller heyecan verici fikirlerden daha değerlidir.
Eğer üç ödeyen kullanıcı daha basit bir dışa aktarma akışı isterse, bu önemlidir. Bir kişi beş gelişmiş ayar isterse ve kimse başkası bahsetmiyorsa, bekleyebilir.
Destek ve fiyatlandırma hakkında öğrendiklerinizi not edin; ayrıntılar tazeken. Hangi kanal en hızlı yanıt verdi? Hangi sorular tekrar tekrar geldi? İnsanlar fiyatta nerede duraksadı ve sizi neyle kıyasladılar? Böyle notlar hafızadan daha iyi kararlara götürür.
Çekirdek akış stabil hissedene kadar ürünü basit tutun. İnsanlar kayıt olup ana görevi tamamlayabilmeli ve yardım almadan ne yapacaklarını anlamalı. Eğer bu yol hâlâ sarsaksa, daha fazla özellik genellikle durumu kötüleştirir.
Koder.ai ile inşa ediyorsanız, bu aşama küçük, dikkatli sürümler için uygundur. Hedefli değişiklikler yapın, kullanıcıların nasıl tepki verdiğini izleyin ve gerekirse snapshot'larla daha güvenli bir dağıtım ve geri alma yolu kullanın.
Çoğu ekip birinci aydan sonra daha az inşa etmeyi tercih eder. Pürüzleri temizleyin, dinlemeye devam edin ve daha büyük adımlar atmadan önce bir ay daha kullanıcı güveni kazanın.
İlk ay için bir doğrudan destek kanalı ve kısa bir self-servis cevap yeriyle başlayın. Çoğu erken ürün için e-posta veya uygulama içi sohbet artı kısa bir SSS yeterlidir. Bu, mesajların dağılmasını engeller ve kalıpları daha hızlı görmenizi sağlar.
Kullanıcının ürünün ana faydasına ulaştığını gösteren tek bir eylem seçin. Bir AI uygulama oluşturucu için bu, bir istemden çalışan bir taslak üretmek olabilir. Kayıtlar yüksek ama aktivasyon düşükse, daha fazla trafik çekmeden önce bunu düzeltin.
Çünkü güven hâlâ kırılgandır. Bozuk bir giriş, başarısız bir kaydetme veya kafa karıştıran bir kurulum adımı yeni kullanıcıların tüm ürünü sorgulamasına neden olur. İlk ayda temel güvenilirlik, ekstra işlevsellikten daha önemlidir.
Her hafta küçük bir seti takip edin: yeni kayıtlar, aktive olan kullanıcılar, geri dönen kullanıcılar, en çok başarısız olan eylemler ve konu bazlı yardım talepleri. Bu, insanların değeri alıp almadığını ve nerede takıldıklarını gösterir.
Bunu nihai bir hüküm olarak değil işaret olarak ele alın. Fiyatla ilgili bir geribildirim aldığınızda, fiyatın yüksek veya düşük hissettiren şeyin ne olduğunu sorun. Çoğu erken fiyat şikayeti aslında belirsiz değer, zayıf onboarding veya güven eksikliğiyle ilgilidir.
Önce onboarding'i düzeltin. Kullanıcılar hızlıca faydalı bir sonuç elde edemiyorsa, yeni özellikler çok yardımcı olmaz. Etiketleri, adımları veya ilk görevi küçükçe değiştirerek aktivasyonu çoğu zaman daha çok iyileştirebilirsiniz.
Basit bir filtre kullanın: nadir talepler yerine tekrarlanan acıyı çözün. Birkaç kullanıcının aynı engelle karşılaşması durumunda onu öne alın. Tek sesli bir kullanıcının özel isteği genellikle bekleyebilir.
Dün yaşanan kaydetme hatasını düzelttik gibi kısa ve net bir bildirim gönderin. Kullanıcıları bilgilendirmek, biriyle ilgilenildiğini gösterir ve güveni artırır. Hızlı ve dürüst güncellemeler sessizlikten daha fazla güven sağlar.
Yeni kullanıcılar kafası karışık olduğunda, destek soruları tekrar ettiğinde veya aktivasyon ile bir haftalık tutunma zayıfsa, yeni özellik eklemeyi durdurun ve çekirdeği temizleyin. İnsanlar güvenilir şekilde değeri elde edemiyorsa, daha fazla özellik genellikle daha fazla sürtünme getirir.
Sonraki 30 günü birkaç değişikliğe odaklayın: onboarding'i sıkılaştırın, tekrarlanan destek problemlerini azaltın, bir fiyat sorusunu doğrulayın ve yalnızca aynı istek birden fazla uygun kullanıcıdan geldiğinde özellik ekleyin.