MVP nedir sorusunun kısa cevabı: yeni bir ürün fikrinin müşteriler tarafından gerçekten kullanılıp kullanılmayacağını en az emekle öğrenmek için yapılan ilk sürüm. Bu yazıda MVP'nin tanımını, prototip ve PoC ile farkını, türlerini, kapsamın nasıl belirleneceğini, neyin ölçüleceğini ve ilk sürümden sonra nasıl karar verileceğini anlatıyoruz.
Not: Aramalarda "MVP" kısaltması tıpta da kullanılır (mitral kapak prolapsusu). Bu yazı yalnızca ürün geliştirme ve yazılımdaki anlamını ele alıyor.
MVP nedir? Minimum uygulanabilir ürünün tanımı
MVP, İngilizce Minimum Viable Product ifadesinin kısaltmasıdır; Türkçede minimum uygulanabilir ürün ya da en küçük işe yarar ürün olarak çevrilir. Kavramı yaygınlaştıran Eric Ries, 3 Ağustos 2009 tarihli yazısında MVP'yi, bir ekibin müşteriler hakkında en az emekle en çok doğrulanmış öğrenmeyi toplamasını sağlayan yeni ürün sürümü olarak tanımlıyor.
Ries aynı yazıda önemli bir uyarı da yapıyor: Adına rağmen MVP, küçük ürün yapmakla ilgili değil; amaç öğrenmek. Bu ayrım pratikte şu anlama gelir: MVP'nin başarısı yazılan kodun azlığıyla değil, ilk sürümden sonra "devam mı, değişiklik mi?" sorusuna veriyle cevap verilebilmesiyle ölçülür.
Prototip nedir? MVP ile prototip arasındaki fark
Prototip, bir ürünün ekranlarını ve akışını kod yazılmadan ya da çok az kodla deneyebilmek için hazırlanan modeldir; çoğu zaman tıklanabilir bir tasarımdır. Prototip "kullanıcı ne yapacağını anlıyor mu?" sorusuna cevap verir. MVP ise "kullanıcı bunu gerçek bir iş için kullanıyor mu?" sorusuna cevap verir; bu yüzden ana iş akışının gerçekten çalışması gerekir.
Üçüncü bir kavram daha var: PoC (proof of concept, kavram kanıtı). PoC, projenin en riskli teknik parçasının yapılabilir olup olmadığını dener; örneğin bir sistemle entegrasyonun mümkün olup olmadığını. PoC'yi genellikle kullanıcı değil, geliştirme ekibi görür; MVP ise doğrudan kullanıcıya açılır.
MVP, prototip ve PoC karşılaştırması
Genel bir karşılaştırmadır; projelerde terimler bazen farklı anlamlarda kullanılır.
| Ölçüt | PoC (kavram kanıtı) | Prototip | MVP |
|---|---|---|---|
| Cevapladığı soru | Teknik olarak yapılabilir mi? | Kullanıcı ekranları ve akışı anlıyor mu? | Kullanıcı gerçek bir iş için kullanıyor ve değer buluyor mu? |
| Kim kullanır? | Geliştirme ekibi | Test kullanıcıları, karar vericiler | Gerçek müşteriler |
| Çalışan kod | Yalnız kritik parça | Gerekmeyebilir; tıklanabilir tasarım yeterli | Evet; ana iş akışı uçtan uca çalışır |
| Çıktı | Teknik karar | Tasarım kararı | Ürün kararı: devam, değişiklik ya da durma |
Üç adım sırayla ya da yalnızca ihtiyaç duyulanlarla yapılabilir; her proje PoC gerektirmez.
MVP türleri
MVP her zaman yazılım olmak zorunda değildir. Ürün geliştirmede yaygın olarak kullanılan yaklaşımlar şunlardır:
- Tek özellikli ürün: Ürünün yalnızca ana iş akışını yapan, gerçek kullanıcıya açılmış ilk sürümü. Yazılım projelerinde en sık görülen MVP türüdür.
- Elle yürütülen hizmet: MVP'nin yapacağı iş ilk müşteriler için ekip tarafından elle yapılır; talep ve iş akışı netleşince yazılıma dökülür.
- Arkada insan olan arayüz: Kullanıcı otomatik çalışan bir MVP görür, ama işin bir kısmı arka planda elle yapılır. Otomasyona yatırım yapmadan önce talebi ölçmeye yarar.
- Açılış sayfası testi: Ürün henüz yokken anlatıldığı bir sayfayla ilgi ve kayıt toplanır. Bu tür sayfanın nasıl kurulacağını landing page nedir yazımızda anlattık.
Hangi MVP türünün seçileceği, test edilen hipoteze bağlıdır. "İnsanlar bunu ister mi?" sorusu için açılış sayfası yeterli olabilir; "insanlar bunu her hafta kullanır mı?" sorusu için çalışan bir ürün gerekir.
MVP kapsamı nasıl belirlenir?
MVP projelerinin en sık zorlandığı yer kapsamdır: Her paydaşın "bu da olmazsa olmaz" dediği özellikler ilk sürümü büyütür ve öğrenmeyi geciktirir. MVP kapsamını daraltmak için aşağıdaki sıra işe yarar.
MVP kapsamı nasıl belirlenir: 5 adım
Adımlar bizim önerdiğimiz sıradır; amaç, ilk sürümü öğrenmeye yetecek kadar küçük tutmaktır.
Hipotezi yazın
Kimin, hangi sorununu, nasıl çözeceğinizi ve bunun doğru olduğunu neyle anlayacağınızı tek paragrafta yazın.
Tek kullanıcı tipi seçin
MVP'yi en çok ihtiyacı olan tek bir kullanıcı grubu için tasarlayın; diğerleri sonraki sürümlere kalır.
Tek ana iş akışını seçin
Kullanıcının ürünü kullanma nedeni olan tek akışı uçtan uca çalışır hale getirin; yan özellikleri listeye alın ama yapmayın.
Başarı ölçütünü baştan belirleyin
Kaç kullanıcının, hangi süre içinde, hangi eylemi yapması durumunda devam edeceğinizi yayından önce yazın.
Süreyi sınırlayın
İlk sürüm için bir takvim sınırı koyun; kapsam bu sınıra sığmıyorsa özellik çıkarın, süreyi uzatmayın.
MVP'de neyi ölçmeli?
MVP'nin amacı öğrenmek olduğu için ölçüm, ürünün kendisi kadar önemlidir. MVP'yi yayına almadan önce şu soruların hangi veriyle cevaplanacağını belirleyin:
- Kullanıma başlama: Kayıt olanların ne kadarı ana iş akışını en az bir kez tamamladı?
- Tekrar kullanım: Kullanıcılar ürüne geri dönüyor mu?
- Ödeme isteği: Ücretli bir ürünse kullanıcılar ödemeye razı mı?
- Nitel geri bildirim: Kullanıcılar neyi eksik buluyor, neyi hiç kullanmıyor?
MVP'de sayılar tek başına yeterli değildir. Az sayıda kullanıcıyla yapılan birebir görüşmeler, bir MVP'de rakamların nedenini anlamanın en hızlı yoludur.
MVP maliyeti hangi kalemlerden oluşur?
MVP maliyeti kapsamla doğrudan ilişkilidir; bu yüzden tek bir rakam vermek yanıltıcı olur. Bir MVP teklifinde şu kalemlerin ayrı görünmesi gerekir:
- Keşif ve prototip: Hipotezin, kullanıcı akışının ve ekranların netleşmesi.
- Geliştirme: Ana iş akışının arka ucu ve kullanıcı arayüzü.
- Ölçüm ve analitik: Kullanım verisini toplayan kurulum.
- Barındırma ve hizmetler: Sunucu, e-posta, ödeme altyapısı gibi aylık giderler.
- İlk dönem bakım: Kullanıcı geri bildirimiyle gelen düzeltmeler.
MVP'yi mobil uygulama olarak mı, web uygulaması olarak mı yapacağınızı düşünüyorsanız iki yolun maliyet farkını mobil uygulama mı web uygulaması mı rehberimizde anlattık.
MVP'den sonra: devam mı, değişiklik mi?
MVP yayına alındıktan sonra, baştan yazdığınız başarı ölçütüne göre üç karardan biri verilir: Ölçüt tuttuysa aynı yönde devam edilir ve kapsam genişletilir. Kısmen tuttuysa hedef kullanıcı, fiyat ya da ana iş akışı değiştirilerek yeni bir sürüm denenir; Lean Startup literatüründe buna yön değiştirme (pivot) denir. Hiç tutmadıysa fikri durdurmak da geçerli bir sonuçtur; MVP'nin varlık nedeni, bu kararı büyük bir yatırımdan önce verebilmektir.
MVP projelerinde sık yapılan hatalar
- Kapsamı büyütmek: "İlk sürümde şu da olsun" listesi büyüdükçe MVP tam ürüne dönüşür ve öğrenme gecikir.
- Kaliteyi tamamen bırakmak: Minimum, özensiz demek değildir; ana iş akışı güvenilir çalışmazsa kullanıcı fikri değil, hatayı değerlendirir.
- Ölçümsüz yayın: Veri toplanmayan bir MVP, karar için kullanılamaz.
- Yanlış kullanıcıyla test: Yalnızca tanıdıklarla yapılan MVP testleri gerçek talebi göstermez.
- Kodu sahiplenmemek: MVP başarılı olursa üzerine devam edilecektir; kaynak kodun ve hesapların ürün sahibinde olması baştan sağlanmalıdır.
MVP yayın öncesi kontrol listesi
İlk sürümü kullanıcıya açmadan önce bu maddelerin hepsine evet diyebilmelisiniz.
- Test edilen hipotez yazılı
- Hedef kullanıcı grubu ve onlara nasıl ulaşılacağı belli
- Ana iş akışı uçtan uca çalışıyor
- Başarı ölçütü ve karar tarihi yazılı
- Kullanım verisini toplayan ölçüm kurulu
- Kullanıcıdan geri bildirim almanın yolu belli
- Kişisel veri işleniyorsa KVKK aydınlatma metni hazır
- Kaynak kod ve hesaplar ürün sahibinin adına
Duman Dijital önerimiz: MVP'ye kod yazmadan önce hipotezi ve başarı ölçütünü yazılı hale getirerek başlayın; ilk sürümü tek kullanıcı tipi ve tek ana iş akışıyla sınırlayın. Gerekçemiz: Kavramı yaygınlaştıran Eric Ries'in tanımında MVP'nin amacı küçük ürün yapmak değil, en az emekle en çok doğrulanmış öğrenmeyi toplamaktır.
Fikrinizi abonelikle satılacak bir yazılıma dönüştürmeyi düşünüyorsanız yaklaşımımızı SaaS geliştirme sayfamızda, modelin temellerini SaaS nedir yazımızda anlattık. Şirket içi bir süreç için MVP yapıyorsanız özel yazılım geliştirme sayfamıza bakabilirsiniz.
Kaynaklar
- Eric Ries, Minimum Viable Product: a guide, Startup Lessons Learned, 3 Ağustos 2009 (okundu 2026-11-11).
Sıkça sorulan sorular
MVP'nin açılımı nedir?
MVP, Minimum Viable Product ifadesinin kısaltmasıdır. Ürün geliştirmede, bir fikrin gerçek kullanıcılarla en az emekle sınanmasını sağlayan ilk sürüm anlamında kullanılır.
MVP Türkçe ne demek?
Türkçede minimum uygulanabilir ürün ya da en küçük işe yarar ürün olarak çevrilir. Tıpta ise aynı kısaltma mitral kapak prolapsusu için kullanılır; bu yazı yalnızca ürün geliştirmedeki anlamını anlatıyor.
MVP ile prototip arasındaki fark nedir?
Prototip, ekranların ve akışın anlaşılır olup olmadığını dener; çoğu zaman çalışan kod gerektirmez. MVP ise gerçek kullanıcıların gerçek bir iş için kullandığı, ana iş akışı çalışan ilk sürümdür.
MVP için yazılım şart mı?
Hayır. Elle yürütülen bir hizmet ya da bir açılış sayfası testi de MVP olabilir. Test edilen soru "insanlar bunu düzenli kullanır mı?" ise çalışan bir yazılım gerekir.
MVP ne kadar sürede hazırlanır?
Kapsama bağlıdır. Önerimiz, ilk sürüm için bir takvim sınırı koymak ve kapsam bu sınıra sığmıyorsa süreyi uzatmak yerine özellik çıkarmaktır.
MVP başarılı olursa ne olur?
Başarı ölçütü tutarsa aynı yönde devam edilir ve ürün kapsamı genişletilir. Bu noktada MVP'nin kodu ve altyapısı ürünün temeli olacağı için kaynak kodun ve hesapların ürün sahibinde olması önemlidir.
İlgili hizmetler
SaaS Geliştirme
SaaS ürününüzü keşiften MVP'ye, çok kiracılı mimariden abonelik ve ödeme altyapısına kadar birlikte kuruyoruz. Kendi bulut ürünümüzü geliştirip işlettiğimiz için bu yolun zorluklarını içeriden biliyor, fikrinizi ilk ödeme yapan müşteriye en kısa yoldan taşıyoruz.
İnceleyinÖzel Yazılım Geliştirme
Özel yazılım geliştirme ile işinizin akışına göre web uygulamaları, yönetim panelleri ve API'ler kuruyoruz. Hazır bir paketin sizi zorladığı yerde sürecinizi araca değil, aracı sürecinize uyduruyoruz.
İnceleyin