Fizibilite ve Ticari Uygulanabilirlik: Tasarımı Neyin Ayakta Tuttuğu
Beğenilen bir tasarım fikriyle ayakta kalan bir ürün arasındaki mesafe çoğu zaman teknik değil, ticaridir. Fizibilite sorusu "bunu yapabilir miyiz" diye başlar; asıl pahalı soru ise yaptıktan sonra kimin, neden ve ne kadar ödeyeceğidir. İkisi genelde aynı toplantıda birbirine karıştırılır ve sonuçta yapılabilir ama kimsenin parasını vermediği bir şey çıkar.
Fizibilite ile uygulanabilirlik aynı soru değil
Tasarım kitaplarında arzu edilirlik, fizibilite ve ticari uygulanabilirlik eşit büyüklükte üç daire olarak çizilir, kesişimlerine de ürün denir. Şema hoş ama yanıltıcı. Bu üç soru ne eşit maliyetlidir ne de aynı anda cevaplanır.
Fizibilite soruları ucuzdur. Hangi teknoloji, hangi entegrasyon, hangi ekip, ne kadar süre. Bir haftalık deneme kodu, bir sağlayıcının API dokümanı ya da ekipteki iki kişiyle yapılan yarım saatlik konuşma çoğunu kapatır. Ticari uygulanabilirlik ise ancak gerçek para el değiştirdiğinde cevap verir, ondan önce söylenen her şey tahmindir.
Kapasite eksiği çıktığında iki yol vardır: eksik parçayı dışarıdan alırsın ya da kapsamı daraltırsın. Dış kaynak kullanımı genelde ilk seçenek olarak önerilir, ben burada seçici davranırım. Sınırları net ve değişmeyecek işler (ödeme entegrasyonu, fatura formatı, altyapı kurulumu) dışarıya rahat verilir. Ürünün her hafta değişen çekirdeği dışarı verildiğinde ise fatura değişiklik sayısıyla birlikte büyür.
Dağıtım kararı tasarımın kendisini değiştirir
Ürünü kullanıcıya nasıl ulaştıracağın pazarlama sonrası düşünülecek bir ayrıntı değil, fiyatı ve özellik setini belirleyen bir kısıttır.
Kendi sitenden satarsan marka ve fiyat kontrolü sende kalır, karşılığında trafiği kendin bulursun. Pazar yerine girersen hazır kitleye ulaşırsın ama komisyon oranı doğrudan marjını yer ve satın alma anında müşteri senin değil, platformun müşterisi olur. Yüzde yirmilik bir komisyon, kâr marjı yüzde otuz olan bir üründe kârın üçte ikisini alıp götürür. Bu bir tasarım kısıtıdır: o marjla hangi özelliği sürdürebileceğini baştan bilirsin.
İlk sürümde ikisini birden kurmaya çalışmak yaygın bir hatadır, iki kanalın da yarım kalmasıyla biter. Yeni bir üründe önce tahsilat yolunu kurmayı tercih ederim; para akışı çalışmadan yapılan her ölçüm, olsa olsa ilgi ölçer.
Gelir modeli listeden madde seçmek değil
Abonelik, tek satış, komisyon, kullanım başına ödeme. Bu seçenekler her yazıda alt alta sıralanır, hangisinin ne zaman doğru olduğu söylenmez. Oysa seçim büyük ölçüde ürünün kullanım sıklığına ve maliyet yapısına bağlıdır.
Abonelik, ürün düzenli kullanılıyorsa çalışır. Yılda iki kez açılan bir araca abonelik satmak, iptal oranını finanse etmek anlamına gelir. Komisyon modeli, işlemin içinde durabildiğin sürece ayakta kalır; alıcıyla satıcı bir kez tanışıp seni atlayarak anlaşabiliyorsa model her başarılı eşleşmede biraz daha sızdırır. Kullanım başına ödeme ise maliyetin de kullanımla birlikte arttığı yerlerde doğaldır, sabit maliyetli bir üründe düşük kullanan müşteriyi sübvanse etmeye dönüşür.
Pilotun ölçebildiği ve ölçemediği
Prototip ve pilot çalışması hemen her metinde koşulsuz tavsiye edilir. Faydalıdır, ama neyi ölçtüğü konusunda net olmak gerekir.
İki yüz kullanıcılık dar kapsamlı bir pilot operasyonel soruları iyi cevaplar. Teslimat gecikiyor mu, ödeme hangi oranda başarısız oluyor, destek talepleri ekibi boğuyor mu, kurulum adımında insanlar nerede takılıyor. Bunların hepsi fizibilite sorusudur ve küçük örneklemde bile görünür hale gelir.
Aynı pilot, gelir modeli hakkında neredeyse hiçbir şey söylemez. Yüzde iki ile yüzde dört arasındaki bir dönüşüm farkını makul bir güvenle ayırt etmek için grup başına bin civarında gözleme ihtiyaç duyarsın. İki yüz kişide bu fark dört ziyaretçiyle sekiz ziyaretçi arasındaki salınımdır ve tamamen rastlantıyla açıklanabilir. Pilottan "fiyatlandırma tuttu" sonucunu çıkarmak, gürültüyü sinyal saymaktır.
Pratik sonuç şu: pilot fizibiliteyi test eder, ticari uygulanabilirliği değil. İkincisi için ya daha büyük bir kitle ya da daha uzun bir süre gerekir. Karmaşık ve çok taraflı sistemlerde pilot şarttır çünkü orada operasyonel sürprizler ölümcüldür. Tek bir web sitesi ya da küçük bir güncelleme için beş kişiyle yapılan kullanıcı testi çoğu zaman aynı bilgiyi verir.
Paydaşlar itiraz etmeden önce
Çözümün yalnızca kullanıcıyı değil, akışın içindeki herkesi etkiler. Burada asıl mesele paydaşları listelemek değil, aralarında kimin çıkarının senin çözümüne ters düştüğünü bulmaktır.
Bayi üzerinden satarken doğrudan satış kanalı açarsan o bayi ürünü önermeyi bırakır. Bir süreci otomatikleştiren araç, o süreçten iş çıkaran ekibin işini küçültür ve onay o ekipten geçiyorsa proje sessizce yavaşlar. Bu tür bir çatışma bulduğunda üç seçenek kalır: aktöre yeni bir rol vererek kazançlı çıkmasını sağlarsın, kanalı tümden değiştirip onu devreden çıkarırsın ya da direnci maliyet olarak kabul edip planına yazarsın. Herkesin mutlu olacağını varsayan dördüncü seçenek yok.
Sıralamayı doğru kur
Ucuz soruları önce sor. Teknik fizibilite, dağıtım yolu ve kaba maliyet birkaç gün içinde netleşir; bunlar kapanmadan gelir modeli tartışması havada kalır.
Sonra ölçebileceğin en küçük gerçek işlemi kur ve ilk parayı tahsil et. Tek bir gerçek satış, kırk kişilik anketin verdiğinden fazlasını söyler. Ürünün geri kalanını bundan sonra büyütürsün ve o noktadan itibaren tasarım süreci artık tahmin üzerine değil, ölçüm üzerine ilerler.