Minimum Uygulanabilir Ürün (MVP)

MVP kelimesi, startup dünyasında en çok yanlış kullanılan kelimelerden biri. Bir ekip “MVP'yi altı ayda çıkaracağız” dediğinde, genelde kastettiği şey “ilk sürümü” oluyor. Altı ay, üç mühendis, bir tasarımcı. Çıkış gününde ilk gerçek müşteri soruyor: “Bunu zaten Excel'de yapıyordum, neden geçeyim?”

MVP'nin tanımındaki kelimeler sırayla okunmalı. Minimum: en az ne? Uygulanabilir: gerçek bir kişiyle gerçek koşulda denenebilir mi? Ürün: biri bunun için bir şey verir mi? Üç kelimenin hepsi bir deneyin parçası; hiçbiri “küçük” kelimesinin eş anlamlısı değil.

Ne zaman ihtiyacınız var?

Bir şey inşa etmeden önce, ama bir şeyi inşa etmeye karar vermişken. Yani şu işaretler varsa:

• Roadmap'te büyük bir iş var ve tek dayanağı “müşteriler istiyor gibi görünüyor.”
• Fikrin en riskli kısmı belli değil ya da ekip farklı kısımları riskli görüyor.
• Bir özelliğin geliştirme maliyeti birkaç sprint, ama kullanım ihtimali bir tahmin.
• Yatırımcıya ya da yönetime “kanıt” göstermeniz gerekiyor ama elinizde yalnızca bir sunum var.

Henüz erken olan durum: problemi kimin yaşadığını bilmiyorsanız MVP kurmak erken. MVP bir çözümün testidir; problemin varlığını anlamak, önce görüşmelerle yapılır. Çözümü test etmeden önce problemin gerçekliğini kontrol edin.

Çoğu ekibin atladığı nokta

MVP bir ürün boyutu değil, bir deney türüdür. Ve deney türü, test etmek istediğiniz riskle belirlenir. Bu yüzden önce şu soru gelir: bu fikrin üzerinde yıkılabileceği en zayıf varsayım hangisi? Talep mi? Teslimat mı? Fiyat mı? Teknik fizibilite mi? Her risk için farklı bir MVP gerekir.

Birkaç bilinen örnek: Dropbox'ın kurucusu Drew Houston, ürünü tam çalışır hâle getirmeden önce kısa bir demo videosuyla fikri yayınladı; amaç, insanların bunu isteyip istemediğini görmekti. Teknik zorluk zaten biliniyordu; belirsiz olan talepti. Zappos'un başlangıcı için sık anlatılan hikâye ise, kurucunun yerel mağazalardaki ayakkabıların fotoğrafını siteye koyup sipariş gelince ayakkabıyı satın alarak göndermesidir. Burada test edilen şey depo ya da tedarik değil, insanların ayakkabıyı internetten alıp almayacağıydı. Her iki örnekte de ürün küçük değildi, soru küçüktü.

İyi MVP'nin ölçüsü ne kadar az şey içerdiği değil, hangi pahalı soruyu ne kadar ucuza cevapladığıdır.

Sık yapılan ikinci yanlış, MVP'yi “kötü ürün” sanmak. Müşteri açısından deneyim, hizmet verdiğiniz kısımda kusursuz çalışmalıdır; eksik olan, kapsamdır. Bir MVP'de on özellik yarım yamalak olmak yerine bir özellik uçtan uca çalışmalıdır. Aksi halde alacağınız geri bildirim, ürünün zayıflığından mı yoksa fikrin zayıflığından mı geldiğini ayırt edilemez kılar.

Bu farkı kavrayan ekip, “MVP'yi ne zaman bitiririz?” yerine “MVP bize hangi kararı verdirecek?” diye sorar. İlk soru takvim konuşur, ikincisi öğrenme.

Bu yazının yalın başlangıç yazısından farkı şu: yalın başlangıç deney ritmini ve karar disiplinini anlatır, MVP ise o ritmin içindeki tek bir deneyin tasarımıdır.

Uygulama planı

1. En riskli varsayımı seçin

Fikrin dayandığı varsayımları listeleyin ve “yanılırsak her şey çöker” olanı işaretleyin. Genellikle talep ya da ödeme isteği olur, ama bazen teknik bir engel, bazen bir kanalın ulaşılabilirliğidir. Tek bir MVP, tek bir varsayımı hedeflemeli.

2. Geçme ve kalma kriterini yazın

Deneyden önce: “Beş yüz ziyaretçiden en az yirmisi e-posta bırakırsa, yirmi kişiyle görüşürüz; bundan azsa mesajı değiştiririz.” Rakam keyfi olabilir ama önceden yazılı olmalı. Sonuç geldikten sonra eşik yorumlanırsa, deney bir inanç ritüeline dönüşür.

3. MVP türünü riske göre seçin

Talep riski için: landing page ve duman testi, demo videosu, ön satış. Çözüm riski için: concierge MVP (hizmeti elle ve müşteriyle birlikte sunmak). Teknik risk için: “Wizard of Oz” (arka planda insan çalışır, müşteri otomatik sanır) ya da küçük bir prototip. Fiyat riski için: gerçek ödeme isteyen bir teklif sayfası.

4. Gerçek davranış üretin

Beğeni ve söz değil, bir eylem isteyin: ödeme, randevu, mevcut aracından veri aktarımı. E-posta bırakmak en ucuz eylemdir; onu bir sonraki adıma, yani görüşmeye ya da ön ödemeye çevirebiliyor musunuz? Eylem ne kadar maliyetliyse (müşteri için), kanıt o kadar güçlüdür. Bedava bir beğeni zayıf, ön ödeme güçlüdür.

5. Sonucu karara bağlayın

Deney bittiğinde üç seçenek var: büyüt, değiştir, bırak. Sonuç belirsizse deney yetersiz tasarlanmıştır; daha keskin bir ikinci test kurun. Her MVP bir sonraki MVP'yi ya da bir kararı doğurmalı.

Neyi ölçmeli?

• Dönüşüm eylemi oranı: Teklifi gören kişilerden istediğiniz eylemi yapanların oranı. Öncü gösterge.
• Öğrenme başına maliyet: Bir varsayımı karara bağlamanın toplam bedeli (zaman, para). Sonraki deneylerde düşmeli.
• Kullanıcının kendiliğinden geri dönüşü: Hatırlatmadan sonra bile ürüne dönen kullanıcı oranı. Gecikmeli ama en güçlü kanıt.
• Ön ödeme ya da taahhüt sayısı: Söz ile para arasındaki fark, talebin gerçekliğini gösterir.

Tuzaklar

MVP'yi ilk sürüm sanmak. Ürün tamamlanana kadar geri bildirim almamak. Bu, maliyetli bir tahmindir.

Kapsam kayması. “Bir de şunu eklesek” cümlesi, MVP'yi ürüne dönüştürür. Her yeni özellik için sorun: bu, test ettiğimiz varsayımı güçlendiriyor mu, yoksa bizi rahatlatıyor mu?

Dostça test. Arkadaşlara, takipçilere ya da yatırımcı dostlara denetmek. Onlar nazik davranır. Ürünü hiç tanımayan, sorununu yaşayan insanlardan veri alın.

Bu hafta başlayın

1. Fikrinizin en riskli varsayımını tek cümleyle yazın ve ekibin aynı cümleyi seçip seçmediğini kontrol edin.
2. Bu varsayımı sınayacak en ucuz deneyi (landing page, demo videosu, elle teslim) tasarlayın ve geçme-kalma eşiğini yazın.
3. Deneyi on gün içinde en az elli gerçek potansiyel müşteriye ulaşacak şekilde yayına alın ve takvime sonuç toplantısı koyun.