Yalın Başlangıç ve MVP Yaklaşımı

İki ekip düşünün. İkisi de aynı sektörde, aynı bütçeyle, aynı fikirle başlıyor. Birincisi sekiz ay sonra “lansman” yapıyor ve ilk gerçek kullanıcı geri bildirimini orada alıyor. İkincisi aynı sürede on dört küçük deney yürütmüş, ilk üçünde fikrin yarısının yanlış olduğunu bulmuş ve gerisini buna göre kurmuş.

Fark zekâda ya da çalışkanlıkta değil, çalışma biçiminde. Yalın başlangıç, bir ürünü “küçük” yapma tekniği olarak anlaşılırsa kaybedersiniz. Gerçekte bu, bir ekibin işletim sistemidir: varsayım yaz, test et, ölç, karar ver, tekrarla.

Ne zaman ihtiyacınız var?

Yalın yaklaşım, belirsizliğin yüksek olduğu her yerde işe yarar. Tipik işaretler:

• Yeni bir ürün, segment veya kanal deniyorsunuz ve “ne istendiğini” tahmin ediyorsunuz.
• Ekip aylardır bir şey inşa ediyor ama kimseyle gerçek müşteri görüşmesi yapılmadı.
• Her sprint sonunda “çıkardık” diyorsunuz, “öğrendik” diyemiyorsunuz.
• Büyük bir yatırım kararına yaklaşıyorsunuz (işe alım, altyapı, pazarlama bütçesi) ve dayanağınız bir sunum.

Henüz erken olan hâl ise tersine bir durum: problem ve çözüm kanıtlanmış, tekrarlanabilir bir satış hareketi var ve şimdi yapılacak iş yürütmek. Orada deney, yürütme hızını kesen bir tören olur. Yalın yaklaşımı keşif ile yürütmeyi ayırarak kullanın.

Çoğu ekibin atladığı nokta

Eric Ries'ın Oluştur-Ölç-Öğren döngüsünü çoğu ekip “oluştur” kısmından okur. Oysa döngü tersten tasarlanır: önce neyi öğrenmek istediğinize karar verirsiniz, sonra bunu öğrenmek için ölçmeniz gerekeni belirlersiniz, en son onu ölçecek en küçük şeyi inşa edersiniz.

Bu yüzden yalın başlangıçta üretilen şey ürün değil, öğrenmedir. Ve öğrenmenin birimi sprint hızı ya da çıkan özellik sayısı değil; çürütülen ya da kanıtlanan varsayım sayısıdır. Ries'ın “innovation accounting” dediği şey budur: erken aşamada gelir ya da MAU gibi metrikler gürültülüdür; ilerlemeyi bir varsayımın kanıtlanma düzeyi ile ölçersiniz.

Erken aşamada tek gerçek ilerleme, bir varsayımın hakkında daha az belirsiz kalmanızdır.

Bu yazının komşusu olan MVP yazısıyla farkı şöyle koyayım: MVP bir araçtır, bir deneyin ürünü. Yalın başlangıç ise o aracı ne zaman, neden, hangi karar için kullanacağınızı belirleyen çalışma düzenidir. Düzen olmadan MVP, “yarım ürün” olarak kalır ve neyi kanıtladığı belli olmaz.

Farkı toplantıda hemen görürsünüz. Yalın olmayan ekipte ilerleme raporu “şu modülü bitirdik” der. Yalın ekipte aynı rapor “şu varsayımı çürüttük, bu yüzden şu planı bıraktık” der. İkincisi daha az heyecan verici duyulur ama bir işi sekiz ay erken durdurmuş olabilir.

Bir de maliyet meselesi var. Yalın olmak ucuz olmak demek değildir. Bir deneyin bedeli düşük olabilir ama öğrenilen şey çok pahalı bir kararı engelliyorsa değeri yüksektir. Doğru oran, öğrenmenin değeri bölü deneyin maliyetidir; bu oranı en yüksek tutan ekip kazanır.

Uygulama planı

1. Varsayımları yazın ve sıralayın

Fikrin dayandığı her şeyi cümle cümle dökün: “Müşteri bu problemi haftada en az bir kez yaşıyor.” “Bunun için bütçe ayırıyor.” “Bizi bulabileceği bir kanal var.” Sonra iki eksende sıralayın: yanılırsak ne kadar büyük hasar, ve şu an ne kadar az kanıtımız var. Sağ üst köşe, ilk testiniz.

2. Her varsayım için başarı ve ölüm kriteri koyun

Test başlamadan önce yazın: “Yirmi görüşmenin en az sekizinde bu problemi kendiliğinden anlatırsa varsayım geçer; ikinin altında kalırsa bırakırız.” Eşiği sonradan belirlemek, çoğu zaman sonucu yorumla kurtarmaya dönüşür.

3. En ucuz testi seçin

Görüşme, landing page, sahte buton, elle yapılan hizmet, ön satış. Kod yazmak en son seçenektir. Testin maliyetini gün cinsinden tahmin edin; birkaç haftadan uzunsa küçültmenin bir yolunu arayın. En sık yapılan hata, “ödeme almak isteyen müşteri var mı?” sorusunu cevaplamak için ödeme altyapısını entegre etmeye başlamaktır. Aynı soruyu bir e-posta ve bir banka havalesi talebiyle iki günde cevaplayabilirsiniz.

4. Kısa ve düzenli bir öğrenme ritmi kurun

Haftalık bir “öğrenme toplantısı”: hangi varsayımı test ettik, sonuç ne, ne değişti, bu hafta neyi test ediyoruz. Toplantının çıktısı bir karar listesi, durum güncellemesi değil. Ekibin yaptığı iş değil, öğrendiği şey konuşulur.

5. Sürdür ya da dön kararını disipline edin

Ries'ın “pivot or persevere” toplantısını, belirli aralıklarla (örneğin altı haftada bir) yapın. Soru basit: öğrenme hızımız artıyor mu ve ana hipotez güçleniyor mu? İki turdur cevap hayırsa, yön değişimini konuşmanın zamanı gelmiştir.

Neyi ölçmeli?

• Haftalık tamamlanan deney sayısı: Öğrenme hızının öncü göstergesi; sıfırsa ritim yoktur.
• Karar alınan varsayım oranı: Başlatılan deneylerden net bir “geçti/kaldı” ile kapananlar. Belirsiz kalanlar kötü tasarım işaretidir.
• Öğrenmeye harcanan süre ve maliyet: Bir varsayımı sonuçlandırmanın ortalama bedeli, zamanla düşmeli.
• Gerçek müşteri temas sayısı: Haftada kaç farklı gerçek kullanıcı ile konuştunuz veya ürünü kaç kişiye gösterdiniz?

Tuzaklar

Yalın kılıfında özensizlik. Düşük kaliteyi “MVP” diye savunmak. Sorun, ürünün yarım olması değil, hangi sorunun testi olduğunun belli olmaması. Özenin yeri, deneyin tasarımıdır.

Doğrulama peşinde koşmak. Varsayımı kanıtlamak yerine savunmak: dost kullanıcılarla konuşmak, soruyu yönlendirmek. İyi bir deney yanlışlanabilmelidir.

Sonsuz deney. Öğrenip hiç karar vermemek. Her deneyin sonunda ya yatırımı artırır, ya yön değiştirir ya da bırakırsınız. “Biraz daha veri toplayalım” çoğu zaman karar vermekten kaçınmaktır.

Bu hafta başlayın

1. Mevcut fikrinizin dayandığı on varsayımı yazın ve “yanılırsak hasar” ile “kanıt eksikliği” eksenlerinde sıralayın.
2. En üstteki varsayım için tek cümlelik bir başarı ve bırakma eşiği yazıp ekiple paylaşın.
3. Takvime, her hafta aynı saatte yapılacak 30 dakikalık bir öğrenme toplantısı koyun; ilk gündem maddesi birinci varsayımın testi olsun.