MVP Rehberi: Minimum Ürünle Maksimum Öğrenme
MVP (minimum uygulanabilir ürün), ürününüzün ilk sürümü değil, çözüm hipotezinizi gerçek kullanımla test eden en küçük deneydir. "Minimum"un ölçüsü mühendislik eforu değil öğrenmedir: "insanlar bunu gerçekten kullanıyor ve geri geliyor mu?" sorusunu cevaplayabilen en küçük şey. MVP'lerin çoğunun asıl hatası fazla küçük değil, fazla büyük olmalarıdır.
Tek Akış Kuralı: Kapsamı Belirlemek
MVP kapsamının pratik formülü: bir segment, bir problem, bir uçtan uca akış eksiksiz çalışan tek yol, yarım çalışan beş özellikten iyidir. Kapsam kararının testi şudur: "Bu özellik çıkarılırsa çekirdek hipotez test edilemez mi?" Cevap hayırsa özellik MVP dışıdır. Vardiya planlama örneği: plan oluşturma + paylaşma + değişiklik bildirimi = çekirdek akış; raporlama, izin yönetimi, bordro entegrasyonu = sonra. Ayarlar sayfası, profil düzenleme, şifre sıfırlama gibi "hijyen" özellikler bile ilk turda manuel/elle destekli olabilir.
MVP'nin Türleri: Kod Miktarına Göre Merdiven
"MVP = küçük yazılım" varsayımı gereksizce pahalıdır; kod yoğunluğuna göre merdiven:
| Tür | Kurgu | Ne zaman |
|---|---|---|
| Concierge | Hizmeti tamamen elle, açıkça insan eliyle verme | Değer teklifi belirsizken; süreç öğrenilirken |
| Sihirbaz (Wizard of Oz) | Önyüz otomatik görünür, arka plan insan | Otomasyonun değerini kanıtlamadan önce |
| Tek özellik MVP | Çekirdek akışın gerçek yazılımı | Kavram prototipte doğrulandıktan sonra |
| No-code MVP | Hazır araçlarla kurulmuş akış | Hız kritikken; teknik ekip yokken |
Merdivenin mantığı: her basamak bir üst basamağın yatırım kararını doğrular. Concierge'la 10 müşteriye elle hizmet verip süreci öğrenmeden yazılım yazmak, öğrenilmemiş sürecin otomasyonudur.
MVP Metrikleri: Kullanım > Kayıt
MVP'nin başarı ölçüsü indirme/kayıt değil, değer anına ulaşma ve geri gelme davranışıdır:
- Aktivasyon: İlk oturumda çekirdek değeri yaşayanların oranı ("ilk vardiya planını oluşturdu") kayıt olan değil, değer gören sayılır
- Elde tutma: Hafta 1-2-4 geri dönüş eğrisi; MVP'nin en dürüst metriği. Eğri bir yerde yataylaşıyorsa (herkes gitmiyor) çekirdek değer bir grup için çalışıyordur
- Kullanım derinliği: Çekirdek akışın tekrar sıklığı (haftalık planlama aracıysa haftada bir kullanım "iyi"dir metrik, ürünün doğal frekansına göre yorumlanır)
- Niteliksel sinyal: Kullanıcı şikâyeti aslında olumludur şikâyet eden, ürünü umursayandır. Sessizlik en kötü sinyaldir
Hipotez disiplini burada da geçerli: MVP'ye başlamadan "hangi metrik, hangi eşikte hipotezi doğrular?" yazılmalıdır ("4. haftada %25 elde tutma" gibi).
"Uygulanabilir"in Unutulan Yarısı
Minimum'a odaklanan kurucular "uygulanabilir"i unutur: MVP küçük olabilir ama çekirdek işi gerçekten yapmalıdır. Yarım çalışan çekirdek akış, hipotezi test etmez kullanıcının gitme sebebi "değer yok" mu "bug var" mı ayırt edilemez. Pratik çizgi: kapsam dar, kalite çizgisi çekirdek akışta yüksek. Kenar senaryolar (edge case) elle çözülebilir ("bir sorun olursa WhatsApp'tan yazın" erken dönemde meşru bir destek kanalıdır) ama ana yol güvenilir olmalıdır.
Sık Sorulan Sorular
MVP'yi ne kadar sürede çıkarmalıyım?
Takvim hedefi bağlamına göre değişir ama yön hep aynıdır: haftalar, aylar değil. 6 aydan uzun MVP planı neredeyse kesin kapsam hatasıdır "MVP" adı verilmiş v1.0'dır. Süreyi kısaltmanın yolu daha hızlı kodlamak değil, merdivenden basamak inmektir: yazılım MVP'si 4 ay sürüyorsa, aynı hipotezi 2 haftalık sihirbaz kurgusuyla test edebilir misiniz? Sürenin uzaması genellikle hipotezin birden fazla oluşundandır tek hipoteze indirin, kapsam kendiliğinden küçülür.
Kullanıcılar MVP'yi "eksik" diye eleştiriyor; özellik mi eklemeliyim?
Önce eleştirinin kimden geldiğine bakın: çekirdek akışı aktif kullananın "şu da olsa" talebi değerlidir (yol haritası sinyali); hiç aktive olmayanın "şu yok, bu yok" eleştirisi ise çoğu zaman segment uyumsuzluğudur o kullanıcı için değil zaten. İkinci filtre hipotez bağı: talep edilen özellik çekirdek değeri mi güçlendiriyor, yoksa yeni bir problem alanı mı açıyor? Elde tutması kanıtlanmamış çekirdeğe yeni alan eklemek, iki yarım ürün üretir. Eksiklik eleştirisi + güçlü elde tutma kombinasyonu ise idealdir: değer var, genişletme sırası sizde.
MVP için para almalı mıyım yoksa ücretsiz mi başlatmalıyım?
Mümkünse ilk günden para alın: ödeme, en güçlü doğrulama sinyalidir ve "ücretsizken seviyorlardı, paralı olunca gittiler" senaryosunu baştan engeller. Erken dönem meşru yumuşatıcılar: kurucu fiyatı (ömür boyu indirim), uzun deneme, koşulsuz iade. Ücretsiz başlatmanın savunulabilir olduğu durumlar: ağ etkili ürünler (kitle likidite için şart) ve kullanım verisinin kendisinin hipotez olduğu durumlar. Ama bu durumlarda bile ödeme istekliliği ayrı bir deneyle (ön satış, sahte kapı fiyat sayfası) paralel test edilmelidir.
MVP başarısız görünüyor; ürünü mü, segmenti mi değiştirmeliyim?
Önce teşhis katmanını ayırın: aktivasyon düşükse (kayıt olan değeri hiç görmüyor) sorun genellikle onboarding veya değer iletişimindedir ürün değişmeden düzeltilebilir. Aktivasyon iyi ama elde tutma zayıfsa çekirdek değer hipotezi sorgulanmalıdır: kullanıcılarla çıkış görüşmeleri yapın ("neden geri gelmediniz?"). Bir alt segment güçlü tutunuyorsa (kohort kırılımına bakın), ürün değil odak değişmelidir: o segmente daralın. Hiçbir katmanda sinyal yoksa, MVP görevini yapmıştır pivotu veri toplanmış olarak yaparsınız.