CB Insights, startupların neden başarısız olduğuna dair yıllık bir analiz yayınlıyor. Yıllardır bir numaralı neden hep aynı: "pazar ihtiyacı yok." Kötü uygulama değil. Para bitmesi değil. Kötü bir ekip değil. Ürün basitçe, insanların davranışlarını değiştirmeye yetecek kadar önem verdikleri bir sorunu çözmüyordu.
Bu istatistik, ürün geliştirmeye ne kadar emek harcandığını düşününce şaşırtıcı. Ekipler aylar — bazen yıllar — harcayarak sistemler tasarlıyor, kod yazıyor, mimari üzerine tartışıyor ve akışları mükemmelleştiriyor. Ve başarısızlığın en yaygın nedeni, kimsenin tüm bunların gerçek bir sorunu çözüp çözmediğini sormamış olması.
İnsanların gerçekten istediği ürünleri geliştirmek bir yetenek değildir. Bu bir disiplindir. Bir yöntemi vardır ve bu yöntem öğrenilebilir.
En yaygın ürün hatası, problemi derinlemesine anlamadan önce bir çözüme aşık olmaktır. Bu, ilk kez kurucu olan kişilerde neredeyse evrenseldir ve deneyimlilerde de şaşırtıcı derecede yaygındır. Kalıp her zaman aynıdır: birinin bir fikri olur, bunu ikna edici bulur ve inşa etmeye başlar. Müşteri bir sonradan akla gelendir — anlaşılacak biri değil, ikna edilecek biri.
Panzehiri karmaşık değildir, ancak disiplin gerektirir: çözümler hakkında düşünmeden önce, gerekli olduğunu düşündüğünüzden daha fazla zaman probleme ayırın. Problemi yaşayan insanlarla konuşun. Onların çalışmalarını izleyin. Bugün kullandıkları geçici çözümleri ve bu geçici çözümlerin neden kusurlu olduğunu anlayın. Ancak o zaman gerçekten uyan bir şey tasarlamak için yeterli bağlamınız olur.
İyi ürün geliştirme düz bir çizgi değil — bir döngüdür. Döngüdeki her turda varsayımları kanıtlarla değiştirme fırsatı doğar. İnsanların istediği ürünleri inşa eden ekipler, bu döngüyü hızlı ve sık tamamlayanlardır.
Döngü bir formalite değildir. Her aşamanın, bir sonraki aşamanın girdisi haline gelen belirli bir çıktısı vardır. Aşamaları atlamak — en yaygın olarak doğrudan Problemden İnşa Etmeye geçmek — hedefi kaçıran ürünler üretendir.
Her problem çözülmeye değer değildir. İyi bir ürün problemi üç özelliğe sahiptir: sık yaşanır (insanları nadiren değil sıkça etkiler), yoğundur (insanlar rahatlama isteyecek kadar hisseder) ve mevcut çözümler gerçekten yetersizdir (sadece inşa edeceğinizden biraz farklı değil).
Hata, birinci özelliği optimize ederken diğer ikisini görmezden gelmektir. "İnsanlar toplantılarda zaman harcıyor" sıktır. Ancak acı düşükse — insanlar yeterince iyi geçici çözümler bulmuşsa — bu problem ticari olarak çözülmeye değer olmayabilir. Ve zaten istediğinizi yapan on iki araç varsa, sizinkinin tercih edilmesi için çok özel bir nedeninizin olması gerekir.
Araştırma, ürün çevrelerinde kötü bir üne sahiptir — yavaş danışmanlık firmalarıyla, kalın raporlarla ve kimsenin okumadığı bulgularla ilişkilendirilir. Bu uygulamanın değil, uygulamanın başarısızlığıdır. İyi ürün araştırması hızlı, spesifik ve inşa ettiğiniz şeyi değiştirendir.
Araştırmanın amacı, problemin gerçek olduğunu doğrulamak değildir. Araştırmaya ağırlıklı olarak yatırım yapmadan önce buna zaten inanmalısınız. Amaç, iyi bir çözümün nasıl görüneceğini bilmek için problemi yeterince derinlemesine anlamaktır: spesifik olarak kimin problemi olduğu, hangi bağlamda, daha önce ne denediklerini, onu tanımlamak için hangi kelimeleri kullandıklarını ve "çözüldü"nün onlar için nasıl görüneceğini.
Hipotez, doğru olduğuna inandığınız şey hakkında spesifik, yanlışlanabilir bir tahmindir. Netliği zorlar. Net bir hipotez yazamıyorsanız, bir çözüm inşa edecek kadar problemi henüz anlamamışsınızdır.
Kullanışlı bir ürün hipotezinin üç parçası vardır:
Sinyal en önemli parçadır — ve en sık atlanan. Önceden belirlenmiş bir sinyal olmadan her deney "bir şekilde işe yaradı." Ekipler belirsiz verileri olumlu yorumlamanın yollarını bulur. Yanlışlama koşulu olmayan bir hipotez yalnızca bir dilektir.
İnşa etme aşaması, çoğu ekibin çok fazla zaman harcadığı aşamadır. Amaç ürünü inşa etmek değil — hipoteziniz hakkında sinyal verecek minimum şeyi inşa etmektir. Bunlar farklı hedeflerdir ve çok farklı çıktılar üretir.
Çoğu erken aşama hipotezi için minimum, ekiplerin düşündüğünden çok daha azdır. Sonuçta değer verip vermediklerini test etmek için yazılımın yapacağı şeyi on kişi için manuel olarak yapabilir misiniz? Yeni altyapı inşa etmeden önce mevcut araçları bir araya getirip iş akışını test edebilir misiniz? Herhangi bir kod yazmadan önce bir prototip çizip beş kullanıcıyla inceleyebilir misiniz?
Buradaki disiplin, herhangi bir şey inşa etmeden önce sormaktır: "Ne öğrenmeye çalışıyorum?" ve "Bunu öğrenmeme izin verecek minimum şey nedir?" Cevap neredeyse her zaman ekibin inşa etmek istediğinden daha küçüktür.
Lansmandan sonra — ister bir prototip, manuel pilot ya da dağıtılmış bir özellik olsun — ölçüm aşaması, ekiplerin kendilerini en sık kandırdığı yerdir. Kullanıcılara beğenip beğenmediklerini sorarlar. Kullanıcılar evet der. Ekip deneyi doğrulanmış olarak işaretler.
Duygu sinyal değildir. Tek güvenilir sinyal davranıştır: insanlar o şeyi yaptı mı? Geri döndüler mi? Ödediler mi? Başkasına söylediler mi?
Nicel ölçüm için lansmandan önce araç kurun. Hangi spesifik eylemleri takip ettiğinizi bilin. Önceden bir eşik belirleyin — "kullanıcıların X%'i Z gün içinde Y'yi tamamlarsa bunu doğrulanmış sayacağız." Nitel ölçüm için açık uçlu memnuniyet anketleri değil, yapılandırılmış takip görüşmeleri yapın.
Öğrenme aşaması, sadece bir sonraki inşa edilecek şeye karar vermekle değil, kullanıcı ve problem hakkındaki zihinsel modelinizi güncellemekle ilgilidir. Bu adımı atlayan ekipler veri toplar ama anlayış biriktirmez. Hızlı uygularlar ama zamanla yargılarını geliştirmezler.
İyi bir öğrenme oturumu şunu sorar: Ne tahmin ettik? Gerçekte ne oldu? Aradaki fark varsayımlarımız hakkında ne söylüyor? Şu an bilmediğimiz en önemli şey nedir?
Öğrenme aşamasının çıktısı daha keskin bir problem tanımı, revize edilmiş bir hipotez veya — deney açıkça başarısız olduysa — tamamen farklı bir yönü izleme kararıdır. Bu sonuçların hepsi değerlidir. En kötü sonuç belirsizliktir: "bazı şeyler öğrendik ama ne yapacağımızdan emin değiliz." Bu, deneyin yeterince spesifik olmadığının işaretidir.
Ürün geliştirme asla bu döngüyü çalıştırmayı bıraktığınız bir aşamaya ulaşmaz. Sorular değişir — erken aşamada problemin gerçek olup olmadığını doğrularsınız; daha sonra belirli bir çözüm unsurunun işe yarayıp yaramadığını doğrularsınız — ancak yapı her zaman aynıdır. Gözlemle, hipotez kur, test et, öğren.
İnsanların istediği ürünleri inşa eden ekipler, en zekice ilk içgörüye sahip olanlar değildir. Döngüyü en hızlı ve en dürüstçe tamamlayanlardır. Öğrenme hızı, teslimat hızı değil, rekabet avantajıdır.