Minimum Viable Product (MVP): Neyi Ölçer, Neyi Ölçmez

MVP tartışması çoğu zaman özellik listesini kısaltmaya indirgeniyor. Oysa asıl mesele kaç özelliği çıkardığınız değil, çıkardığınız sürümün hangi soruyu cevapladığı. Yanlış soruyu ucuza cevaplamak, doğru soruyu pahalıya cevaplamaktan daha fazla zaman yakar.

MVP bir ürün değil, bir soru

Kitabi tanım şöyle: kullanıcıya gerçek değer üretebilen en küçük çalışan sürüm. Doğru ama eksik. O sürümün varlık nedeni satmak değil, bir varsayımı sınamak. Eric Ries'in cümlesi hâlâ en kullanışlı ölçüt: “Öğrenmeye katkısı olmayan tüm işlev, süreç ve gereksiz çabaları ortadan kaldırın.”

Buradan basit bir kontrol çıkıyor. Geliştirmeye başlamadan önce şu cümleyi tamamlayın: “Bu sürümü çıkarıyoruz, çünkü şunu bilmiyoruz: ...” Cümle tamamlanmıyorsa elinizde MVP yok, küçültülmüş bir ürün planı var. İkisi çok benzer görünür, biri size bilgi getirir, diğeri sadece takvim kazandırır.

“Minimum” ile “çalışan” birbirini çeker

MVP anlatılarının çoğunda aynı sayfada iki zıt öğüt bulunur: en küçük sürümü çıkarın, ama ürün kullanışsız hissettirmesin. Bu ikisi aynı eksende sağlanamaz, çünkü kısmak istediğiniz şeyle korumak istediğiniz şey aynı bütçeden beslenir.

Çelişkiyi çözmenin yolu, iki kelimeyi iki farklı boyuta bağlamak. Minimum, kaç ayrı işi yaptığınıza bakar. Çalışan, seçtiğiniz o tek işi ne kadar iyi yaptığınıza. Yani yolları azaltın, kalan yolun kalitesini değil. Beş özelliği yarım yamalak sunan bir ürün MVP değildir, sadece bozuk bir üründür; tek bir işi baştan sona düzgün yapan sürüm ise özellik sayısı ne kadar az olursa olsun test edilebilir.

Kime gösterdiğiniz sonucu belirler

Erken kullanıcılar (early adopters) yeni şeylere açıktır, eksikleri hoş görür, geri bildirim vermeye isteklidir. Avantaj burada. Tuzak da burada: aynı hoşgörü, ürününüzün ne kadar hazır olduğu konusunda sizi yanıltır. “Olsun, ben idare ederim” tepkisi ana kitlede karşılığı olmayan bir tepkidir. Erken kullanıcıdan alınacak sinyal, ürünün yönü için değerlidir; olgunluk seviyesi için değil.

Sinyalin fiyatı, sinyalin değeridir

Test yöntemleri arasındaki asıl fark teknik değil, ekonomik. Bir kullanıcı size sinyal verirken kendi cebinden ne kadar harcıyorsa, o sinyal o kadar bilgi taşır.

• Sahte kapı sayfası: Henüz var olmayan ürünün tanıtım sayfasını yayınlar, tıklamaları sayarsınız. Kurulumu bir günlük iş. Ölçtüğü şey merak, satın alma niyeti değil.
• Bekleme listesi: E-posta bırakmak birkaç saniye tutar. Listede bin kişi olması hoştur ama ödeme yapmış beş müşteri kadar bilgi vermez.
• Concierge yöntemi: Yazılımı yazmadan hizmeti elle verirsiniz. Ölçeklenmez, zaten amacı da o değil. Karşılığında gerçek kullanım ve gerçek ödeme isteği görürsünüz.
• Mevcut ürüne özellik duyurusu: Özelliği geliştirmeden önce panelde bir giriş noktası açıp kaç kişinin tıkladığına bakarsınız. Ucuz ama aynı sınırla malul: tıklama talebi değil, ilgiyi ölçer.

Pratikte bunları sıralı kullanmak işe yarıyor. Ucuz sinyalle konuyu eleyin, ayakta kalan fikri pahalı sinyale sokun. Ters sırada çalışmak, en çok emek isteyen testi en belirsiz fikre harcamak demek.

“Erken sürüm, sık sürüm” ile aynı şey değil

İkisi karıştırılıyor, oysa farklı sorulara hizmet ediyorlar. MVP'de yön sizde: belirli bir kitleye, önceden yazdığınız bir değer önerisini test edersiniz. Erken ve sık sürüm modelinde yön kullanıcıda: ürün zaten bir yere oturmuştur, geri bildirim akışı rotayı düzeltir.

Sıralama da buradan çıkıyor. Ürün-pazar uyumunu bulana kadar MVP mantığı, bulduktan sonra sık sürüm mantığı. MVP disiplinini uyumu bulduktan sonra da sürdürmek pahalıya patlar, çünkü her küçük iyileştirmeyi bir varsayım sınamasına bağlamak zorunda kalırsınız ve ekip karar veremez hâle gelir.

Ölçeceğinizi baştan yazın

MVP'nin en sık atlanan adımı, sürüm çıkmadan önce başarı eşiğinin yazılması. Rakam sonradan belirlenirse, gelen veri her zaman yorumlanabilir görünür. Yüz ziyaretçiden üçünün kayıt olması iyi mi kötü mü? Cevap, sayıyı görmeden önce ne dediğinize bağlı. Eşiği önceden yazmak, MVP'yi bir ölçüm aracı olarak ayakta tutan tek şey.