Kaybolan güven (Lost confidence)

• RICE gibi güvene dayalı önceliklendirme çerçeveleri çoğunlukla gürültüden ibaret; bilinmeyen geleceği biliyormuş gibi yapmadan karar vermenin bir yoluna ihtiyaç var
• Güven puanları küçük (small) projelerde yüksek, büyük (large) projelerde düşük verildiği için, yüksek değerli projeleri sistematik olarak geri iter ve öncelikleri çarpıtır
• Güven puanlarının tanımı belirsizdir, doğrulama verisi yetersizdir ve projeler neredeyse her zaman gecikir, beklenenden daha düşük etki yaratır; bu yüzden güvenilir değildir
• Çözüm, olasılık (probability) değil belirsizlik (uncertainty) alanında, "hangi olasılık dağılımı olursa olsun akıllıca davranış nedir?" diye sormaktır
• Güven yerine her zaman doğru olanlar, müşteri etkisi, opsiyonları koruma, asimetrik bahisler gibi tekniklerle öncelik belirlemek önemlidir

---

Güven oyunları (Confidence games)

• Birçok önceliklendirme çerçevesi, öngörülen çabayla öngörülen etkiyi yaratabileceğine dair güveni puana dahil eder
  • Aynı değer ve aynı çabaya sahip iki projeden, uygulama güveni daha yüksek olanı seçmek başlı başına mantıklıdır
  • Ancak pratikte kullanım şekli "1) puanlama → 2) net kazananı uygulama → 3) eşitse güveni yüksek olanı seçme" değildir
• RICE, ilk adımda puan hesaplamasına güveni doğrudan çarpar
  • RICE formülü: Score = (Reach × Impact × Confidence) / Effort
  • RPS formülü: Score = Reach × Potential × Solution Confidence
• Bu yaklaşım, iki farklı senaryoyu aynı seviyede ele alarak sahte bir eşdeğerlik yaratır
  • Küçük ama kesin olarak uygulanabilir kademeli bir özellik
  • Etkisi büyük ama risk taşıyan büyük bir özellik
• Genellikle küçük projelerde güven yüksek, büyük projelerde düşüktür; bu nedenle güveni çarpmak, maksimum değeri sunma yönünden sistematik olarak uzaklaşmaya yol açar
  • Agile hareketinin temel motivasyonlarından biri zaten "büyük projelerde başarı güveni her zaman düşük olmalıdır" içgörüsüydü
• Güven puanlarına neden güvenilmez?
  • Tanım belirsizdir: "%30"un ne anlama geldiği açık değildir. Aslında tüm projelerin güven puanlarını kaydedip gerçek sonuçlarla karşılaştırarak doğruluğu sayısal olarak hesaplamak gerekir, ama pratikte bu yapılmaz
  • Her yıl yalnızca az sayıda büyük özellik yayınlanıyorsa, sonradan doğrulama yapacak verinin kendisi bile yetersizdir
  • Projeler neredeyse her zaman geç kalır; etkileri beklenenden daha küçük ve daha yavaştır. 9 ay süren, 6 ekibin çalıştığı bir proje de başlangıçta "bir ölçüde güven" olduğu için başlamıştı
• Hofstadter's Law alıntısı: "Hofstadter's Law hesaba katılsa bile işler her zaman beklenenden uzun sürer"
• Deneyimli PM'lere "kesinlikle sevileceğinden emindim ama öyle olmayan özellik" sorulursa herkesin aklına birçok örnek gelir
  • Müşteri görüşmeleri, açık talepler, satın alma sözü gibi dayanaklar olsa bile, gerçekten yapıldığında bunu isteyen kişiler bile neredeyse hiç kullanmayabilir
  • Tahmini iyileştirme tekniği: müşteriden gerçek iş akışı içinde bunu adım adım nasıl kullanacağını anlatmasını istemek. Adımları geçerken, "bunun için kodu yeniden yazmam gerekir, o yüzden kullanmam" gibi bir farkındalığa kendisi varır
• İçerik üreticileri için de durum aynıdır; beklentisiz ve aceleyle yayımlanan bir yazı o yılın en yüksek görüntüleme ve etkileşimini alırken, onlarca saat emek verilen başyapıt görmezden gelinebilir
  • "güven var/yok × sonuç (sevildi/ilgi görmedi)" 2×2 tablosunun dört kutusu da örneklerle doludur

Güven ve risk yerine ne kullanılmalı? (What to use in place of confidence and risk)

• Cevap, olasılıkta değil belirsizlik (uncertainty) alanında yatıyor
  • Olasılık, dağılımı bildiğimiz varsayımına dayanır. Adil bir madeni parayı 100 kez atarsanız, yazının 40 ila 60 kez gelmesi çok muhtemeldir
  • Startup dünyasında neredeyse her şey bundan farklıdır. Başarı, strateji ve özellikler ya emsalsizdir ya fazla karmaşıktır ya da girdiler yeterince hassas değildir; bu yüzden anlamlı olasılıklar atamak mümkün değildir
  • Kavram, ekonomist Frank Knight'ın 1921 tarihli eserinden gelen "Knightian Uncertainty" kavramıdır
  • Bayesian yöntemler de sayısal öncül olasılıklar ve koşullu olasılıklar gerektirir; ama ikisi de bilinemez ve tanımlanamaz
• Belirsizlik alanındaki soru şudur: "Olasılık dağılımından bağımsız olarak hangi eylem akıllıcadır?"

• Her zaman doğru olanlar (True always)

  • Her durumda doğru kalan şeylere odaklanın — Bezos'un uzun vadeli sabitler (long-term constants) ilkesi
    • Kullanıcılar genel olarak hızlı ve yüksek tepki veren yazılımları tercih eder. Arka plan senkronizasyonu, anlık etkileşim ve tüm cihazlarda çalışma onlar için değerlidir
    • En kötü senaryoda bile (hıza kayıtsız kullanıcılar) kimse hızı olumsuz görmez. En iyi senaryoda ise Notion, Figma, Miro, Gmail, Google Docs gibi ürünlerde performans temel farklılaştırıcı olur
  • Her özelliğin evrensel çekiciliği yoktur. Hassas sayısal ayrıştırmalar yerine, neredeyse tüm müşterilerin değerli bulduğu ya da en azından hoş karşıladığı özellikleri belirlemek gerekir
    • Bazen zorunluluk bunu kesin kılar. SOC 2 uyumluluğu gibi kurumsal gereksinimler heyecan verici olmayabilir ama kurumsal satışta kesin değer taşır
    • Bu tür bir kesinlik, farklılaşma eksikliğini telafi eder
  • Ancak en yenilikçi ve en farklılaştırıcı fikirler neredeyse hiçbir zaman "mutlak kesinlik" kategorisine girmez
    • Kesin olan şeyler değerlidir ama stratejik farklılaştırıcı olmaları zordur
    • Harika ürünlerin hem güvenilir iyileştirmelere hem de yenilikçi sıçramalara ihtiyacı vardır

• Hızlı keşif, hızlı toparlanma (Quick discovery, quick recovery)

  • Fikirleri doğrulamak için potansiyel müşterilerle ürün geliştirmeden önce sistematik görüşmeler yapmayı uzun zamandır savunuyorum; ancak bu da "güven tuzağına" düşebilir
    • Gerçekte inşa etmeden önce asla kesin olarak bilemezsiniz
    • Yine de ürünü geliştirmeden önce geçersiz kılma (invalidate) mümkündür; bu da aylarca hatta yıllarca israfı önleyebilir, dolayısıyla hâlâ doğru başlangıç noktasıdır
  • Tipik çözüm SLC oluşturmaktır (MVP'nin geliştirilmiş bir versiyonu) — gerçek geri bildirim almak için basit ama tamamlanmış bir ürün sunmak; tahmin değil deneyim elde etmek
    • Mevcut ürünlerde kesin kazanımlar ile yenilikçi bahisler arasında dengeli bir portföy korunmalı ve her biri için farklı doğrulama yöntemleri kullanılmalıdır
  • "Dummy features" örneği: tıklanınca "Bu özellik henüz yok. Bunu nasıl kullanırdınız, bize söyleyin" mesajı gösteren bir buton
    • İlgi duyan kullanıcı sayısı ve potansiyel görüşme adayları hakkında davranışa dayalı gerçek sinyal verir
    • Anketlerden 100 kat daha iyi bir sinyaldir. Anketlerde insanlar kolayca "evet" der; ama bir butona tıklamak gibi davranışlar gerçek ilgi gerektirir. Gözlemlenen davranış, beyan edilen niyetten üstündür

• Güven yerine müşteri etkisine odaklanın (Focus instead on customer impact)

  • Güveni etkiyle değiştirin. Etki iki şekilde tanımlanır
    • Çoğunluk kuralı (Majority rule): kullanıcıların çoğunluğunun düzenli kullandığı bir özellik açıkça önemlidir ve benimseme ile elde tutmanın temel nedenlerinden biri olabilir
    • Tutkulu savunucular (Passionate advocates): az sayıda kullanıcıda fanatik bağlılık yaratan özellikler. "Sadece bunun için satın aldım" diyen insanlar. Evrensel olmayabilir ama belirli bir segmentte derin sadakat yaratır (magnificent delighters)
  • Kullanıcılar bir ürünün belirli bir kısmını gerçekten seviyorsa diğer kusurlara katlanır
    • iPod'un cazibesi sayesinde milyarlarca insan tarihin en kötü yazılımı olan iTunes'a katlandı
    • Güzel tasarlanmış yazılımlar, eksik özellikleri ya da platform sınırlamaları olsa bile sırf tasarım deneyimi nedeniyle kabul görebilir
  • Yüksek etkili özelliğin nicel tanımı
    • (1) müşterilerin en az %51'i tarafından düzenli kullanılıyor olması veya
    • (2) müşterilerin en az %15'i tarafından seçme ya da elde tutma nedenleri arasında ilk 3'te anılması
    • Bu yüksek bir çıta ama yenilikçi ve riskli özelliklerde yüksek çıta doğaldır; ödülün büyüklüğü riski haklı çıkarmalıdır

• Kaldıraca yatırım yapın (Invest in leverage)

  • Küçük ve kademeli değişikliklerin büyük sonuçlar üretebildiği alanlar vardır
  • Matematiksel ve yapısal olarak neredeyse her zaman geçerli olan kaldıraç alanları mevcuttur
    • (İlgili kitap tanıtımı bölümü reklam olduğu için çıkarılmıştır)

• Opsiyonelliği en üst düzeye çıkarın (Maximize optionality)

  • Geleceği bilmiyorsanız, oraya vardığınızda sahip olacağınız seçenek sayısını en üst düzeye çıkaran tercihleri yapın
    • Bu yalnızca esneklik ya da lock-in'den kaçınma değil; ne olursa olsun başa çıkabilecek şekilde tasarlamaktır
  • Örnekler
    • Düşük maliyet yapısını korumak → kârlılığı sürdürürken farklı fiyatlandırma ve paketleme deneyleri ile gelecekteki dayanıklılığı mümkün kılar
    • İyi doğrulanmış ve aktif geliştirilen cross-platform UI kütüphaneleri ve framework'leri seçmek → platform ve cihaz evrimine uyum sağlar
    • Plugin mimarisi → sizin ve topluluğun bugün hayal bile etmediği şeyleri inşa etmesine olanak tanır
    • API-first mimari → ekip izolasyonu, frontend-backend ayrımı ve müşteri entegrasyonlarını bağlar
    • Vendor servis sarmalayıcıları → istikrarsız, pahalı ya da geri kalmış vendor'ları değiştirebilmeyi sağlar
  • Gelecekteki seçenekleri korumak, bugün ek iş gerektirir
    • Bir vendor'ı saran API bugün hemen bir değer yaratmaz
    • Bu yaklaşım, istikrar ve öngörülebilirliğin önemli olduğu olgun şirketler için akıllıcadır; ama hızla yerleşik oyuncuları yenmesi gereken erken aşama şirketler için yanlış tercih olabilir
  • Şirket genelinde opsiyonelliği en üst düzeye çıkarmanın yolu harika bir şirket kurmaktır
    • Sağlıklı ve sürdürülebilir büyüme, büyük ve genişleyen brüt marj, müşterilerin elde tutma, yükseltme ve ağızdan ağıza tavsiyeyle gösterdiği sevgi, çalışanların uzun süre kalması ve kariyer gelişimiyle gösterdiği bağlılık
    • Harika şirketlerin satın alma, bağımsız kalma, fon toplama, IPO, halefiyet gibi pek çok seçeneği olur

• Bahis portföyü (Portfolio of bets)

  • Portföyler oynaklığı azaltır ama maksimum yukarı yönlü potansiyeli de azaltır
    • Hiç kazanç olmama ihtimali düşüktür, bu yüzden aşağı yön o kadar kötü değildir; ancak kazananların kayıpları telafi etmesi gerektiğinden, ara sıra gelen büyük başarılar bile tekli bahis kadar büyük olmaz
    • Benzetme: Amazon'u IPO'da alıp sonsuza dek tutmak en iyi sonuç olurdu; ama aynı yıl diğer IPO'lara aynısını uygulamış olsaydınız sonuç $0 da olabilirdi. Portföy sıfıra inmez ama en yüksek büyümesi en iyi tek hisseden çok daha düşüktür
  • Matematiksel not: portföylerin dağılımdan bağımsız çalışmasının nedeni Merkezi Limit Teoremi (Central Limit Theorem)
    • Kararlı ama bilinmeyen bir dağılıma sahip bir popülasyondan N örnek tekrar tekrar çekilip örnek ortalamalarının histogramı çizilirse, bu dağılım Gauss'a (normal dağılıma) yaklaşır; ortalaması anakütle ortalamasına, varyansı ise anakütle varyansının 1/n'ine yaklaşır
    • Lindeberg–Lévy CLT, her örnek farklı dağılımlardan gelse bile bunun geçerli olduğunu gösterir (bağımsızlık, sonlu varyans ve tek bir değişkenin baskın olmaması koşullarında)
    • Ancak startup ortamında sık görülen bazı dağılımlarda bu koşullar bozulabilir (bazı power law dağılımlarında varyans sonsuzdur)
  • Portföyler, öngörülebilir ama sıradan sonuçlar istendiğinde işe yarar; outlier aranıyorsa yaramaz
    • Venture ve angel portföylerinde örnek: yatırımların %65'i zarar eder, yalnızca yaklaşık %10'u risk ve düşük likiditeyi haklı çıkaracak getiri sağlar
    • Outlier peşindeyseniz portföy değil all-in yatırım gerekir (çünkü startup getiri dağılımları, Lindeberg koşullarını ihlal eden power law yapısındadır)
  • Sonuç: pazar farklılaşması ve büyüme motoru arayan önceliklendirmede portföy yanlış araçtır. Küçük ve güvenilir artımlı sonuçlar için uygundur; bu durumda da güven üzerine tartışmaya gerek yoktur

• Asimetrik bahisler (Asymmetric bets)

  • Portföylerin doğal karşı kutbudur. Portföy güvenilirlik içinken, asimetrik bahisler outlier içindir
    • Bahsin başarı şansını tahmin etmeye çalışmazsınız; bunun yerine aşağı yönü sınırlı ve ölçülebilir, yukarı yönü ise büyük olan bahisler alırsınız
  • En kötü senaryo "2 ay kayıp", en iyi senaryo "tam farklılaşma" ise olasılık neredeyse anlamsızdır
    • Yeter ki aşağı yön hayatta kalınabilir olsun ve yukarı yön, tek bir galibiyetle on kaybı telafi edecek kadar büyük olsun
    • Kesin olasılığı bilemeyebilirsiniz ama her bahsin şeklini (shape) bilebilirsiniz
  • Strateji seviyesindeki asimetrik bahislerde bu şekil çoğu zaman önceden bellidir (biriken bileşik tavsiyelerle büyüyen yeni pazarlar, sattıkça derinleşen hendekler)
    • Özellik seviyesinde ise asimetriyi sizin kurmanız gerekir. Çünkü yazılım projelerinin varsayılan şekli "2 hafta → 2 ay → artık çok zaman harcandığı için bitirmek zorundayız" şeklinde sürüklenir
    • Mekanizma, başlamadan önce yazılan bütçedir: "2 mühendis, 3 hafta, sonra durup gözden geçireceğiz." Timebox, sınırlı aşağı yön demektir
  • Güveni "ne kadar asimetrik?" sorusuyla değiştirmek de bir yöntemdir
    • RICE, bilinemez olduğunu kabul ettiği bir olasılığı tahmin etmenizi ister
    • Asimetri ise gerçekten tahmin edilebilen iki şeyi sorar: zaman/maliyet açısından en kötü durum ve müşteri değeri açısından en iyi durum. İkisi de somuttur; tüm sayıları 10'un kuvvetleriyle sınırlarsanız toplantılarda üzerinde uzlaşılabilen rakamlara yaklaşmak mümkündür

Sonuç

• Güveni nicelleştirebiliyormuş ya da tanımlayabiliyormuş gibi yapmayı bırakın
• Bunun yerine gelecek öngörülemediğinde de işe yarayan teknikleri kullanın — çünkü gelecek her zaman öngörülemez

[hmmhmmhm]

"Bunun yerine, gelecek öngörülemez olduğunda her seferinde işe yarayan bir teknik kullan; çünkü gelecek her zaman öngörülemezdir" — harika.

[spilist2]

Çok güzel bir yazı.