MVP (Minimum Viable Product, Türkçesiyle minimum uygulanabilir ürün), bir ürün fikrinin değerini kanıtlayan en küçük çalışan sürümdür. Amacı tüm özellikleri sunmak değil, ürünün çözdüğünü iddia ettiği tek bir sorunu gerçekten çözdüğünü gerçek kullanıcılarla göstermektir. Doğru kurulan bir MVP, büyük bir bütçeyi yanlış özelliklere harcamadan önce en önemli soruya cevap verir: İnsanlar bunu gerçekten kullanacak mı?
MVP ne değildir?
MVP, bilinçli olarak küçük tutulmuş bir üründür; eksik ya da özensiz bırakılmış bir sürümle karıştırılmamalıdır. Bu ayrımı baştan yapmak, hem ekibin hem de ilk kullanıcıların beklentisini doğru kurar.
- Kötü yapılmış bir ürün değildir. Az şey yapar, ama yaptığını düzgün yapar.
- Prototip değildir. Prototip tıklanabilir bir taslaktır; MVP ise gerçek veriyle çalışan, gerçek kullanıcının kullandığı üründür.
- Son ürünün küçültülmüş hâli değildir. Her özellikten biraz koymak yerine, tek bir iş akışını baştan sona eksiksiz kurar.
MVP, prototip, PoC ve pilot arasındaki fark
Dördü de risk azaltmak için yapılır, ama her biri farklı bir soruya cevap verir. Hangi soruyu sorduğunuzu bilirseniz hangisine ihtiyacınız olduğu da netleşir.
| Kavram | Cevapladığı soru | Kim kullanır? | Gerçek veriyle çalışır mı? |
|---|---|---|---|
| PoC (kavram kanıtı) | Bu teknik olarak yapılabilir mi? | Ekip içi | Genellikle hayır, deneme verisiyle |
| Prototip | Kullanıcı akışı anlaşılır mı, ekranlar mantıklı mı? | Ekip ve birkaç test kullanıcısı | Hayır, tıklanabilir taslaktır |
| MVP | İnsanlar bunu gerçekten kullanır mı, karşılığını öder mi? | Gerçek hedef kullanıcılar | Evet |
| Pilot | Hazır bir çözüm belirli bir kurumda sorunsuz işler mi? | Tek bir kurum ya da şube | Evet, sınırlı bir ortamda |
Bu adımlar sırayla da gelebilir. Teknik açıdan belirsiz bir fikirde önce PoC, ardından prototip, sonra MVP yapılır. Kurumsal bir müşteriye satılacak üründe ise MVP'den sonra bir pilot uygulama gelir.
Neden önce MVP?
MVP, en pahalı soruyu en ucuz yoldan cevaplamanın yoludur. Yazılım projelerinin en pahalı hatası, kimsenin kullanmayacağı özellikleri inşa etmektir. MVP bu riski üç şekilde azaltır:
- Öğrenme hızı: Kullanıcı davranışı, toplantıda yapılan tahminlerden daha güvenilirdir.
- Bütçe kontrolü: Yatırımın büyük kısmı, ürünün işe yaradığı görüldükten sonra yapılır.
- Pazara erken çıkış: Rakiplerden önce kullanıcıya ulaşır, geri bildirim toplamaya başlarsınız.
MVP türleri
Her MVP'nin bir uygulama olması gerekmez; bazen fikri test etmenin en hızlı yolu hiç kod yazmamaktır. Aşağıdaki türler, ne kadar yazılım geliştirildiğine göre kabaca küçükten büyüğe sıralanmıştır.
Concierge MVP
Bu yaklaşımda hizmeti elle, birebir siz verirsiniz ve kullanıcı da bunu bilir. Örneğin evde bakım hizmeti için eşleştirme platformu kurmak isteyen biri, önce birkaç aileyle telefon ve mesaj üzerinden görüşüp bakıcı eşleştirmesini kendisi yapabilir. Bu süreçte ailelerin hangi bilgiyi önemsediğini, hangi soruları tekrar tekrar sorduğunu ve nerede vazgeçtiğini öğrenirsiniz. Yazılım, ancak bu işin elle yürümez hâle geldiği noktada devreye girer. Mesajlaşma tarafında basit otomasyonlar işinizi kolaylaştırabilir; bunun örneklerini WhatsApp ile iş süreci otomasyonu yazımızda bulabilirsiniz.
Wizard of Oz MVP
Kullanıcı karşısında otomatik çalışan bir ürün görür, ama perde arkasında işi bir insan yapar. Diyelim ki bir muhasebe bürosu, müşterilerinin fiş fotoğrafı yükleyip masraf kaydının otomatik oluşmasını sağlayan bir uygulama düşünüyor. İlk sürümde fotoğraf yükleme ekranı gerçektir, fakat kayıtları büro çalışanı elle girer. Böylece okuma teknolojisine yatırım yapmadan önce müşterilerin bu özelliği gerçekten kullanıp kullanmadığı görülür.
Tek özellikli MVP
Ürün, tek bir işi uçtan uca yapan gerçek bir yazılımdır. Bir fizik tedavi kliniği için düşünülen hasta uygulaması, ilk sürümde yalnızca randevu almayı ve randevu hatırlatmasını içerebilir. Egzersiz videoları, ödeme ve mesajlaşma sonraki sürümlere kalır. Bu tür, yukarıda anlatılan MVP tanımına en yakın olanıdır ve çoğu ürün fikri sonunda bu noktaya gelir.
Açılış sayfası ve ön satış
Ürün henüz yokken onu anlatan bir sayfa yayınlar ve ilgilenenlerden kayıt ya da ön ödeme istersiniz. Örneğin yöresel ürünleri abonelik kutusuyla satmak isteyen bir girişimci, kutunun içeriğini ve teslimat düzenini anlatan bir sayfa açıp ilk siparişleri toplayabilir. Ziyaretçinin kayıt olması bir ilgi işaretidir; para ödemesi ise çok daha güçlü bir kanıttır. Sayfanın kendisi için sade ve tek bir eyleme odaklanan bir tasarım yeterlidir.
MVP kapsamı nasıl belirlenir?
Kapsam, bir kullanıcı, bir sorun ve bir ana akış etrafında çizilir. Kapsamı daraltmak, MVP sürecinin en zor ve en değerli kısmıdır. Şu adımlar işe yarar:
Tek bir kullanıcı ve tek bir sorun seçin
"Herkes için" tasarlanan bir ürünün ilk sürümü kimseye tam uymaz. İlk sürümün kimin, hangi sorununu çözeceğini tek cümleyle yazın. Örneğin: "Mahalle bakkalı, veresiye defterindeki borçları telefondan takip etsin."
Ana iş akışını uçtan uca çizin
O kullanıcının sorunu çözmek için izleyeceği adımları sıralayın. Bu akışın dışında kalan her şey ikinci sürüme bırakılabilir.
Özellikleri "olmazsa olmaz" ve "sonra" diye ayırın
Her özellik için şunu sorun: Bu olmadan kullanıcı ana işi yapabilir mi? Yapabiliyorsa o özellik MVP'ye girmez. Raporlar, gelişmiş ayarlar, çoklu dil ve rol yetkilendirmesi genellikle bu gruptadır.
Başarı ölçütünü baştan yazın
MVP'nin başarılı sayılması için ne olması gerektiğini önceden tanımlayın: Belirli sayıda aktif kullanıcı, tekrar kullanım oranı ya da ödeme yapan ilk müşteriler gibi.
Örnek: bir fikri adım adım kapsamlandırmak
Yukarıdaki dört adımı hayali bir fikir üzerinden uygulayalım. Fikir şu: Bir kuru temizleme dükkânı, müşterilerin kıyafetlerinin hazır olup olmadığını sormak için sürekli telefon ettiğinden şikâyetçi ve bunu çözecek bir uygulama düşünüyor.
Kullanıcı ve sorun. İlk taslakta liste uzun: müşteri uygulaması, kurye takibi, online ödeme, sadakat puanı, birden fazla şube. Tek cümleye indirildiğinde sorun şu: "Dükkân sahibi, kıyafet hazır olduğunda müşteriye kendiliğinden haber verebilsin."
Ana akış. Müşteri kıyafeti bırakır, çalışan siparişi müşterinin telefon numarasıyla kaydeder, kıyafet hazır olunca tek dokunuşla "hazır" işaretler, müşteriye bir mesaj gider, müşteri gelip teslim alır ve sipariş kapanır. Akış bu kadar.
Olmazsa olmaz ve sonra. Sipariş kaydı, hazır bildirimi ve teslim işareti olmazsa olmazdır. Müşteri uygulaması gerekmez, çünkü mesaj zaten müşterinin telefonuna ulaşır. Online ödeme, kurye, sadakat puanı ve şube yönetimi "sonra" listesine gider. Ortaya çıkan ürün, tezgâhtaki tablette çalışan tek ekranlı bir uygulamadır.
Başarı ölçütü. Dükkân sahibiyle birlikte şu yazılır: Çalışanlar her siparişi sisteme giriyor mu, "hazır mı" telefonları gözle görülür biçimde azalıyor mu ve dükkân sahibi bu aracı bırakmak istemiyor mu? Bu sorulara olumlu cevap gelirse sıradaki sürüm konuşulur.
İlk listedeki fikirler çöpe atılmaz; sıraya konur ve sırayı kullanıcının davranışı belirler.
MVP'den sonra ne olur?
Yayından sonra iş, öğrendiklerinizi bir sonraki karara çevirmektir. Yayından sonraki ilk haftalar, geliştirmenin kendisi kadar önemlidir:
- Kullanıcıların nerede takıldığını izleyin.
- Doğrudan konuşun: Neden kullandılar, neyi eksik buldular?
- Topladığınız bilgiyle sıradaki sürümün önceliklerini belirleyin.
Bazen veri, fikrin olduğu gibi büyütülmesi gerektiğini gösterir; bazen yön değiştirmek gerektiğini. İkisi de MVP'nin başarısıdır, çünkü ikisi de büyük bir bütçe harcanmadan öğrenilmiştir.
Yayından sonra neyi ölçmelisiniz?
İndirme ya da kayıt sayısı tek başına pek bir şey söylemez; asıl bakılması gereken, insanların ürünü kullanıp kullanmadığı ve ona değer verip vermediğidir. Bunun için üç tür ölçüt yeterli bir başlangıçtır.
- Aktivasyon: Kayıt olan kullanıcı, ürünün ana işini en az bir kez baştan sona yaptı mı? Kuru temizleme örneğinde bu, ilk siparişin kaydedilip "hazır" mesajının gönderilmesidir. Kullanıcılar bu noktaya gelmeden bırakıyorsa sorun genellikle ilk deneyimdedir.
- Tutunma: Kullanıcı ürüne geri dönüyor mu? Tek seferlik merak ile gerçek ihtiyaç arasındaki farkı en iyi bu gösterir. Haftalar içinde kullanımın sönmesi, ürünün bir alışkanlığa dönüşmediğini anlatır.
- Ödeme isteği: Kullanıcı bu ürün için para öder mi ya da ödemeye hazır olduğunu davranışıyla gösteriyor mu? "Güzel olmuş" demek ile kart bilgisini girmek arasında büyük fark vardır.
Kullanıcılarla konuşmayı da bırakmayın: sayı size neyin olduğunu, görüşme ise neden olduğunu söyler.
Sık yapılan MVP hataları
Hataların çoğu, MVP'yi küçük bir ürün olarak değil, ertelenmiş bir büyük ürün olarak görmekten kaynaklanır. En sık karşılaşılanlar şunlardır:
- Kapsamın yolda büyümesi. Geliştirme sürerken her toplantıda "bunu da ekleyelim" denir ve MVP fark edilmeden tam ürüne dönüşür.
- Başarı ölçütü olmadan yayına çıkmak. Neyin başarı sayılacağı baştan yazılmazsa her sonuç yoruma açık kalır ve karar verilemez.
- Yanlış kişilerle test etmek. Aile ve arkadaşlar nazik davranır; hedef kullanıcı ise ürünü ya kullanır ya kullanmaz.
- Görünüşü ihmal etmek ya da abartmak. Güven vermeyen bir arayüz kullanıcıyı kaçırır, ama ilk sürümde her ekranı cilalamak da zamanı yanlış yere harcar.
- Geri bildirimi toplayıp kullanmamak. Veri toplanır, ama sıradaki sürümün öncelikleri yine ilk plana göre belirlenir.
Ne zaman MVP yapmamalısınız?
Her fikir MVP ile test edilmeye uygun değildir; bazı durumlarda doğrudan tam ürün ya da hazır bir çözüm daha mantıklıdır. Şu durumlarda iki kez düşünün:
- Sorun zaten kanıtlanmışsa. Şirket içinde kullanılacak, ihtiyacı net ve kullanıcısı belli bir araçta "insanlar kullanır mı" sorusu zaten cevaplanmıştır. Burada önemli olan doğru kapsam ve sağlam teslimdir.
- Yasal ya da güvenlik gereksinimleri tam ürünü zorunlu kılıyorsa. Sağlık, finans ve kişisel veri gibi alanlarda "eksik ama çalışan" bir sürüm kabul edilmeyebilir. Uyumluluk gereksinimleri ilk günden karşılanmalıdır.
- Hazır bir yazılım işi görüyorsa. İhtiyacınız piyasadaki bir ürünle karşılanabiliyorsa yeni bir şey inşa etmek gereksizdir. Bu kararı hazır yazılım mı özel yazılım mı yazımızda ayrıntılı ele aldık.
- Kullanıcıya ulaşma yolunuz yoksa. MVP'nin değeri, gerçek kullanıcıdan gelen geri bildirimdedir. Ürünü deneyecek kimse yoksa önce kullanıcıya ulaşma yolunu kurmak gerekir.
MVP için teknik tercihler
İlk sürümde hız ve değiştirilebilirlik, mükemmel mimariden daha önemlidir. Ancak "nasılsa atacağız" diye yazılan kod çoğu zaman atılmaz ve ürünün temeli olur. Bu yüzden:
- Yaygın, iyi belgelenmiş teknolojiler seçin.
- Web ve mobil gerekiyorsa çapraz platform çözümleri değerlendirin.
- Ödeme, kimlik doğrulama, bildirim gibi standart işler için hazır servisleri kullanın.
- Veri modelini dikkatle kurun; ekranlar sonra kolayca değişir, veri yapısı zor değişir.
Maliyet tarafını mobil uygulama yaptırma maliyeti yazımızda ayrıntılı ele aldık.
Sık sorulan sorular
Aşağıda MVP fikri olan girişimcilerin ve işletme sahiplerinin en sık sorduğu soruları kısaca cevapladık.
MVP için ne kadar bütçe ayırmalıyım?
Bütçeyi ekran sayısı değil, ana iş akışının karmaşıklığı belirler. Kapsamı yukarıdaki adımlarla daralttıktan sonra alınan teklifler, "her şey dahil" bir ürün için alınanlardan çok daha gerçekçi olur.
MVP'yi kendim mi test etmeliyim, gerçek kullanıcıyla mı?
Gerçek kullanıcıyla. Ekip içi testler hataları bulur; ama ürünün değerli olup olmadığını yalnızca hedef kullanıcı gösterir.
MVP yayına çıktıktan sonra baştan yazılması gerekir mi?
Teknik tercihler baştan dikkatli yapıldıysa genellikle gerekmez. Ürün, aynı temel üzerine yeni özellikler eklenerek büyür. Baştan yazma ihtiyacı daha çok veri modelinin aceleyle kurulduğu ya da ürünün tamamen yön değiştirdiği durumlarda ortaya çıkar.
Kodsuz araçlarla MVP yapılabilir mi?
Concierge, Wizard of Oz ve açılış sayfası türleri için çoğu zaman yapılabilir; form, tablo ve mesajlaşma araçları bu aşamada yeterlidir. Ürünün kendisi bir yazılım olduğunda ya da kullanıcı sayısı arttığında bu araçların sınırlarına takılırsınız ve gerçek geliştirme gündeme gelir.
MVP için aldığım teklifleri nasıl karşılaştırmalıyım?
Önce her teklifin aynı kapsamı anlatıp anlatmadığına bakın; "MVP" kelimesi her firmada farklı bir özellik listesi anlamına gelebilir. Neyin dahil olduğunu, neyin sonraya bırakıldığını ve yayından sonraki desteği sorun. Ayrıntılı bir kontrol listesini yazılım projesi teklifi nasıl değerlendirilir yazımızda bulabilirsiniz.
Bir ürün fikriniz varsa, kapsamı birlikte daraltıp ilk sürümü planlayabiliriz. Yayındaki ürünlerimize göz atın ya da fikrinizi bizimle paylaşın.