MVP Nedir? Fikrinizi 6 Haftada Çalışan Bir Ürüne Dönüştürme Rehberi

Birkaç yıl önce bir kurucu bize harika bir fikirle geldi. On sekiz ay boyunca, kendi tabiriyle "kusursuz" ürününü geliştirmek için para ve emek harcamıştı. Sonunda lansman günü geldi, ürünü piyasaya sürdü ve... kimse umursamadı. Sorun fikrin kötü olması değildi; sorun, hiç kimseye sormadan, hiç test etmeden bir buçuk yılını tek bir varsayıma yatırmış olmasıydı. Eğer bunu altı haftada, küçük bir sürümle deneseydi, en pahalı dersini en ucuz fiyata öğrenmiş olacaktı.

İşte bu yüzden bir ürün stüdyosu olarak en sık verdiğimiz tavsiye şu: büyük başlamayın, doğru başlayın. Bu yazıda MVP'nin gerçekte ne olduğunu (ve ne olmadığını), kapsamı nasıl acımasızca daralttığınızı, fikrinizi gerçek kullanıcılarla nasıl doğruladığınızı ve tüm bunları 6 haftalık gerçekçi bir takvime nasıl sığdırdığınızı anlatıyoruz.

MVP nedir, ne değildir?

MVP, İngilizce "Minimum Viable Product" yani "asgari uygulanabilir ürün" ifadesinin kısaltmasıdır. Tanımdaki her kelime önemlidir. Asgari: en az sayıda özellikle. Uygulanabilir: ama yine de gerçek bir değer üreterek. Ürün: bir maket veya sunum değil, insanların gerçekten kullanabileceği bir şey. MVP'nin amacı, fikrinizin temelinde yatan en riskli varsayımı, en az çabayla, gerçek dünyada test etmektir.

Burada en büyük yanlış anlama şudur: MVP "ucuza yapılmış, yarım yamalak bir ürün" değildir. Az özelliği iyi yapan bir MVP ile çok özelliği kötü yapan bir ürün arasında dağlar kadar fark vardır. MVP'niz tek bir şey yapsın ama onu kusursuz yapsın. Bir başka deyişle, MVP'niz dar ama derin olmalıdır — geniş ve sığ değil.

MVP, fikrinizin küçültülmüş bir kopyası değildir; en riskli varsayımınızı sınamak için tasarlanmış en küçük deneydir.

MVP'nin ne olmadığını netleştirmek de aynı derecede önemli:

• Bir slayt sunumu ya da tıklanabilir maket değildir (o bir prototiptir).
• "Sonra ekleriz" diyerek yarıda bırakılmış özelliklerle dolu bir ürün değildir.
• Rakibinizin tüm özelliklerinin kötü bir kopyası değildir.
• Tek seferlik bir lansman değildir; öğrenmeye devam ettiğiniz bir başlangıçtır.

Kapsamı acımasızca daraltmak

Bir MVP projesinde başarının %80'i, daha tek satır kod yazılmadan, kapsam masasında belirlenir. Her kurucunun aklında bir özellik listesi vardır ve bu listenin neredeyse tamamı "olmazsa olmaz" gibi görünür. Bizim işimiz, bu listeyi acımasızca ikiye ayırmaktır: ürünün çekirdek değerini oluşturan tek bir şey, ve geri kalan her şey.

Bunu yapmanın en etkili yöntemlerinden biri şu soruyu sormaktır: "Eğer bu ürün yalnızca tek bir işi yapabilseydi, hangi tek işi yapması onu yine de kullanılır kılardı?" Bir teslimat uygulaması düşünün. Sadakat puanları, çoklu dil desteği, sürpriz indirim çarkı — bunların hepsi güzel. Ama çekirdek değer tek bir cümlededir: "kullanıcı bir şey sipariş edebilmeli ve o sipariş ulaşmalı." MVP'niz işte budur. Gerisi sonra gelir.

Burada en büyük düşman özellik şişmesidir (feature creep): "madem yapıyoruz, şunu da ekleyelim" cümlesiyle başlayan ve takvimi sessizce aylarca uzatan o sinsi süreç. Her yeni özellik, sadece geliştirme süresi değil; test, bakım ve karmaşıklık demektir. Disiplinli bir ekip, "hayır, şimdilik değil" demeyi bilir. Reddedilen her özellik, yarıda kalmış bir özellikten her zaman daha iyidir.

Yap-ölç-öğren döngüsü

MVP felsefesinin kalbinde, Eric Ries'in popülerleştirdiği basit bir döngü yatar: yap, ölç, öğren. En küçük sürümü yaparsınız, kullanıcıların onunla ne yaptığını ölçersiniz, bu veriden bir şey öğrenirsiniz ve sonra döngüyü tekrarlarsınız. Buradaki amaç mükemmel ürünü tek seferde inşa etmek değil; mümkün olan en kısa sürede gerçek geri bildirim alıp yönünüzü düzeltebilmektir.

Bu döngünün anlamlı olması için, daha ürünü yapmadan önce neyi başarı sayacağınızı tanımlamanız gerekir. "Çok kişi kullanırsa iyi olur" bir hedef değildir. "İlk haftada kayıt olan kullanıcıların en az dörtte biri ikinci kez geri dönerse, fikir tutmuş demektir" — işte bu ölçülebilir bir hedeftir. Hedefiniz ne olursa olsun, onu önceden, soğukkanlılıkla belirleyin; çünkü lansmandan sonra her veriyi kendinizi haklı çıkaracak şekilde yorumlama eğilimi insani ama tehlikelidir.

Gerçekçi bir 6 haftalık takvim

"6 hafta" kulağa iddialı gelebilir, ama doğru daraltılmış bir kapsamla tamamen gerçekçidir. Onlarca MVP projesinde işe yarayan ritmimiz kabaca şöyledir:

1. Hafta 1 — Keşif ve kapsam. Problemi, hedef kullanıcıyı ve en riskli varsayımı netleştiririz. Özellik listesini çekirdeğe indiririz. Bu haftanın çıktısı net bir kapsam ve öncelik sırasıdır.
2. Hafta 2 — Tasarım ve akış. Kullanıcının ürünü baştan sona nasıl deneyimleyeceğini tasarlarız. Süslü ekranlar değil, akıcı bir kullanıcı deneyimi hedefleriz.
3. Hafta 3-4 — Çekirdek geliştirme. Asıl değeri üreten ana akışı kodlarız. Bu iki hafta, ürünün "kalbinin atmaya" başladığı dönemdir.
4. Hafta 5 — Entegrasyon ve test. Parçaları birleştirir, gerçek verilerle test eder, kritik hataları temizleriz. Mükemmellik değil, çalışırlık peşindeyiz.
5. Hafta 6 — Lansman ve ölçüm. Ürünü sınırlı bir kullanıcı grubuna açar, ölçüm araçlarını kurar ve ilk gerçek geri bildirimi toplamaya başlarız.

Bu takvimin sırrı sürat değil, disiplindir. Her hafta net bir çıktıya bağlıdır ve kapsam genişlemediği sürece tarih kaymaz. Bu yaklaşımı ve ekibimizin nasıl çalıştığını MVP geliştirme sürecimizde ayrıntılı biçimde anlatıyoruz.

Gerçek kullanıcılarla doğrulama

Bir MVP'nin tüm varlık sebebi öğrenmektir; ve öğrenmek yalnızca gerçek kullanıcılarla olur. Lansmandan sonra en değerli iş, ofiste oturup yeni özellik düşünmek değil; ilk kullanıcılarınızla bizzat konuşmaktır. Hangi adımda takıldılar? Neyi anlamadılar? Hangi anda "vay, bu işe yarıyor" dediler? Bu cevaplar, hiçbir analitik panelinin tek başına veremeyeceği içgörüyü taşır.

Nicel veriyi (kaç kişi kaydoldu, nerede ayrıldı) nitel veriyle (neden ayrıldı, ne hissetti) birleştirin. Beş kullanıcıyla yapılan derinlemesine bir görüşme, beş yüz anonim tıklamadan daha fazlasını öğretebilir. Ve unutmayın: kullanıcılar size ne istediklerini değil, hangi sorunu yaşadıklarını söyler. Çözümü tasarlamak hâlâ sizin işiniz.

Sık yapılan hatalar

Yıllar içinde aynı tuzaklara düşen onlarca projeyi gördük. En sık karşılaştıklarımız şunlar:

• Çok fazla özellikle başlamak. En yaygın ve en pahalı hata. "Asgari" kelimesini ciddiye alın.
• Hiç doğrulamadan tam ölçekli geliştirmeye geçmek. Önce en riskli varsayımı test edin.
• Mükemmeliyetçilik. "Daha bir şey eksik" diyerek lansmanı sürekli ertelemek, en değerli kaynağınızı — zamanı — yakar.
• Yanlış metriklere bakmak. İndirilme sayısı sizi mutlu eder ama elde tutma oranı (retention) gerçeği söyler.
• Geri bildirimi görmezden gelmek. MVP'nin amacı haklı çıkmak değil, öğrenmektir.

Bu hatalardan kaçınan bir ekip, fikrini doğrulamak için aylar yerine haftalar harcar — ve yanılıyorsa bile, en ucuz şekilde yanılır.

---

Bir fikir, ancak gerçek dünyaya çıktığında bir ürüne dönüşür. Aklınızda haftalardır dönen bir fikir varsa, onu altı haftada çalışan bir ürüne nasıl dönüştürebileceğimizi birlikte planlayalım. MVP geliştirme veya daha kapsamlı bir yazılım geliştirme yaklaşımıyla nereden başlamanız gerektiğini netleştirelim. Konuşmak için bize ulaşın.