Bu ürünü tamamen tek başıma, çoğunlukla akşamları, hafta sonlarında ve itiraf etmek istediğimden daha fazla tatil gününü harcayarak yaptım. Uzun süre, internette yayında olsa bile hâlâ kişisel bir proje gibi hissettirdi.
Ödemeleri açmak bu hissi anında değiştirdi. Kod bir anda daha karmaşık olmadı, ama ürüne karşı sorumluluğum değişti. Birisi ödeme yapabildiği anda kırık bir flow artık yalnızca sonra düzeltilecek bir edge case değildir. Onboarding, moderasyon, retention, güven ve güvenilirlik gelecekte ele alınacak konular olmaktan çıkar. Ürünün o anda verdiği sözün bir parçası olur.
Lansmandan çıkardığım en önemli ders bu oldu: çok özellikli bir solo proje inşa etmek ile gerçek bir ürünü işletmek aynı iş değil.
Solo geliştirmede asıl darboğaz dikkat oldu
Ürünü geliştirirken sosyal medyadan neredeyse tamamen kayboldum. Bu bir lansman stratejisi değildi. Ürün kararları, implementasyon, edge case'ler, flow testleri ve release hazırlığı aynı sınırlı saatler için yarışıyordu.
Solo geliştirmeyle ilgili bu kısmı artık çok daha iyi anlıyorum. Darboğaz her zaman ne kadar hızlı kod yazabildiğim değil. Üründeki giderek artan state, geçiş ve hata senaryolarına ne kadar dikkat ayırabildiğim.
Başarılı bir build bu soruları cevaplamaz. Başarılı bir ödeme de cevaplamaz.
Ödemeler bir bug'ın anlamını değiştirdi
Ödemelerden önce bazı pürüzleri “sonra düzeltirim” diye düşünebiliyordum. Ödemeler yayına girdikten sonra bu zihinsel model benim için çalışmamaya başladı. Ücretli bir ürünün hiç bug içermemesi gerekmez; bu gerçekçi değil. Ama başka biri ürüne para emanet ettiğinde bilinen bir sorunu çözmeden bırakmanın maliyeti değişir.
Aynı şey onboarding ve moderasyon için de geçerli. Geliştirme sırasında bunlar “asıl” özelliğin etrafındaki destek sistemleri gibi görünebilir. Production'da ise kullanıcı bunları doğrudan yaşadığı için özelliğin bir parçasıdır. Retention da benzer: iyi bir ilk oturum, ürünün geri dönmek için yeterli bir neden verdiğini kanıtlamaz.
Ödemeler ürünün bitmiş olduğunu kanıtlamadı. “Bitti” kelimesinin arkasında ne kadar iş saklandığını gösterdi.
Lansman bana farklı türde bilgi verdi
Release'den sonra daha az gösterişli işler başladı: yalnızca yayınlandıktan sonra görünür olan bug'lar, kırık flow'lar, kullanıcılar geldiğinde gerçek hale gelen moderasyon sorunları ve iyi bir ilk izlenim yaratmaktan çok daha zor retention soruları.
Bu sinyalleri gereğinden fazla yorumlamamaya çalışıyorum. Release sonrası bir bug otomatik olarak mimarinin kötü olduğu anlamına gelmez. Retention sorunu tek başına product-market fit teşhisi değildir. Bir moderasyon problemi tüm sistemin güvensiz olduğunu kanıtlamaz. Bir belirti bana nereye bakacağımı söyler; nedeni otomatik olarak açıklamaz.
Değişen şey kanıtın niteliğidir. Lansmandan önce kullanıcıların ne yapacağını bekliyorsam onu test edebilirim. Lansmandan sonra gerçekten ne yaptıklarıyla uğraşmam gerekir. Release, belirsizliğin kaybolduğu an değildir. En önemli belirsizliklerin bir kısmının ilk kez gözlemlenebilir olduğu andır.
Şimdi kullandığım post-launch döngüsü
Artık lansman hikâyesini parlatmaktan çok sonrasındaki işle ilgileniyorum: ödemelerden çıkan dersler, kırık flow'lar, moderasyon zorlukları, kullanıcı davranışı, retention sürprizleri ve ürünü adım adım daha güvenilir yapan küçük düzeltmeler.
- Gerçek flow'u gözlemle. Tasarladığım yolun kullanıcıların gerçekten izlediği yol olduğunu varsaymıyorum.
- Belirtiyi nedenden ayır. Başarısız bir adım bana nerede bir sorun olduğunu gösterir, nedenini otomatik olarak göstermez.
- Güveni etkileyen hatalara öncelik ver. Ödemeler, erişim, onboarding ve moderasyon, hata maliyeti daha yüksek olduğu için kozmetik kusurlardan daha acildir.
- Önce doğrulanmış en küçük problemi düzelt. Bir varsayıma göre sistemi yeniden tasarlamak yerine doğrulanmış tek bir sürtünme noktasını kaldırmayı tercih ederim.
- Düzeltmeden sonra kullanıcı deneyimini yeniden kontrol et. Kod değişikliği teknik olarak doğru olabilir ama kullanıcı sorununu çözmemiş olabilir.
Bu evrensel bir framework değil. ürünü inşa etmekten işletmeye geçtikten sonra bana en mantıklı gelen çalışma disiplini bu.
Lansman benim için doğruluk kaynağını değiştirdi
Bugün en çok önemsediğim ayrım, ürünü yapmış olmak ile ürünü işletmeye hazır olmak arasındaki fark. Geliştirme “sistem tasarladığım şeyi yapabiliyor mu?” diye sorar. İşletme ise gerçek insanlar kullandığında, yanlış anladığında, ayrıldığında, geri döndüğünde, ödeme yaptığında veya beklemediğim bir yola girdiğinde ne olduğunu sorar.
Bu yüzden lansmanı artık bitiş çizgisi olarak görmüyorum. Lansmandan önce kanıtların çoğu kendi varsayımlarımdan ve testlerimden gelir. Lansmandan sonra ürün gerçek davranış, hatalar ve tekrar kullanım üzerinden cevap vermeye başlar.