MVP
MVP nedir ve ilk sürümün kapsamı nasıl belirlenir?
MVP (minimum viable product, Türkçede minimum uygulanabilir ürün), bir ürün fikrinin en riskli varsayımını gerçek kullanıcılarla sınayabilecek en küçük çalışan sürümüdür. Amaç yarım bir ürün çıkarmak değil, büyük bütçeyi harcamadan önce “bunu isteyen ve parasını ödeyen biri var mı?” sorusuna kanıtla cevap almaktır.
Yazan Hatice Kölmük8 dk okuma
MVP kavramı nereden çıktı?
Wikipedia'daki maddeye göre terimi ilk kez 2001'de Frank Robinson kullandı ve tanımladı; kavram daha sonra Steve Blank ile Eric Ries'in yazılarıyla yaygınlaştı. Maddenin özetlediği haliyle MVP, erken müşterilerin kullanabileceği ve ürünün gelişimine geri bildirim verebileceği kadar özelliğe sahip bir ürün sürümüdür.
Eric Ries'in 2009'daki tanımında ağırlık ürünün kendisinde değil, öğrenmededir: ekip, müşteriyi en az emekle ve en çok kanıtla tanımak için bu sürümü çıkarır. Bu yüzden bir MVP'nin başarısı kaç özelliği olduğuyla değil, hangi soruya ne kadar net cevap verdiğiyle ölçülür.
MVP'nin ne olmadığını bilmek de önemlidir. Özensiz yapılmış bir ürün, bitmemiş bir demo ya da bütçesi kısıldığı için küçültülmüş bir proje MVP değildir. Bir MVP küçüktür, çünkü bilerek küçük tutulmuştur: hangi soruyu sınadığı ve neyin bilerek dışarıda bırakıldığı yazılıdır.
MVP, prototip ve PoC arasındaki fark nedir?
Bu üç kelime toplantılarda çoğu zaman birbirinin yerine kullanılır, ama farklı soruları cevaplar:
| Cevapladığı soru | Kim kullanır | Ortaya çıkan | |
|---|---|---|---|
| PoC (kavram kanıtı) | Teknik olarak yapılabilir mi? | Ekibin kendisi | Fikrin çalıştığını gösteren bir deneme |
| Prototip | Kullanıcı akışı anlıyor mu, sıralama doğru mu? | Test için seçilen birkaç kişi | Tıklanabilir ekranlar, çoğu zaman gerçek veri olmadan |
| MVP | İnsanlar bunu kullanır ve parasını öder mi? | Gerçek, erken müşteriler | Canlıda çalışan ve gerçek veriyle kullanılan ilk ürün |
Aynı maddedeki bir örnek farkı iyi gösterir. Sydney Üniversitesi'nden uzmanlar 2015'te tarla ve yabani ot yönetimini otomatikleştirmek için Rippa adlı bir robot geliştirdi. Robotun yabani otu ekinden ayırt edebildiği, yani teknik varsayım, robot piyasaya çıkmadan kanıtlanmıştı. Henüz kanıtlanmamış olan, robotun çalışan bir çiftlikte işe yarar bir araç olup olmadığıydı. MVP tam olarak bu ikinci soruyu sınamak için vardır.
MVP neden yapılır?
Çünkü yeni bir ürünün en pahalı hatası, kimsenin istemediği bir şeyi çok iyi yapmaktır. Aylarca süren bir geliştirme, ürün yayına girdiği gün yanlış bir varsayıma dayandığını gösterebilir. MVP bu riski öne çeker ve yanlış olma ihtimali en yüksek varsayımı en ucuz yoldan dener. Tipik sorular şunlardır:
- Talep: bu sorunu yaşayan yeterince insan var mı?
- Ödeme isteği: çözüm için para ödemeye razılar mı, ne kadar?
- Kullanım: ilk denemeden sonra geri geliyorlar mı?
- Kanal: bu kişilere makul bir maliyetle ulaşabiliyor musunuz?
Bu soruların bazılarına tek satır kod yazmadan cevap aramak da mümkündür. Önemli olan sırayı doğru kurmaktır: önce sizi en çok korkutan soru.
Yatırımcıyla ya da yönetim kuruluyla konuşan kurucular için bir fayda daha var: bir fikri slaytla anlatmak ile çalışan bir ürünü ve onu kullanan ilk müşterileri göstermek arasında büyük fark vardır. İyi kurulmuş bir ilk sürüm, sonraki bütçe konuşmasının en güçlü kanıtı olur.
MVP'yi kimlere göstermeli?
Wikipedia'daki açıklamaya göre MVP genellikle olası müşterilerin küçük bir kısmına, erken benimseyenlere sunulur: eksikleri daha kolay affeden, geri bildirim vermeye daha istekli ve ürünün nereye gittiğini erken bir sürümden görebilen kişiler. Bu kişileri bulmak, ilk sürümü yapmak kadar önemlidir.
Pratikte erken benimseyenler, sorunu en sık ve en can sıkıcı biçimde yaşayanlardır: işi bugün elle, tablolarla ya da birbirine bağlı olmayan üç ayrı araçla yürütmeye çalışanlar. Onlara ulaşmak için geniş bir reklam kampanyası gerekmez; doğru kişilerle yapılmış birkaç derin görüşme, ilk kullanıcı listesini çoğu zaman tek başına çıkarır.
Hangi MVP türleri var?
MVP her zaman kod demek değildir. Sınamak istediğiniz soruya göre şu yollardan biri seçilir:
- Açılış sayfası testi: ürünü anlatan tek bir sayfa ve bir kayıt ya da ön sipariş düğmesi. Düğmeye kaç kişinin bastığı, talebin ilk işaretidir.
- Elle yürütülen hizmet: ürünün yapacağı işi önce siz elle yaparsınız. Müşteri sonucu alır, siz de hangi adımın otomatikleşmeye değdiğini öğrenirsiniz.
- Perde arkası yöntemi: kullanıcı otomatik bir sistemle çalıştığını düşünür, ama bazı adımları arka planda bir insan yürütür.
- Tek özellikli ürün: yalnızca çekirdek işi yapan, gerçek kullanıcıların her gün kullanabildiği küçük bir yazılım.
- Hazır araçlarla kurulan ürün: form, tablo ve otomasyon araçlarıyla bir araya getirilmiş, kodu az bir ilk sürüm.
Seçim, sınamak istediğiniz soruya bağlıdır. Yalnızca talebi merak ediyorsanız açılış sayfası testi yeter. Müşterinin sonuç için para ödeyip ödemeyeceğini öğrenmek istiyorsanız elle yürütülen hizmet daha net cevap verir, çünkü gerçek bir sonuç teslim edersiniz. Ürünün her gün kullanılıp kullanılmayacağını görmek istiyorsanız tek özellikli bir yazılım gerekir; alışkanlık ancak gerçek bir ürünle ölçülür.
Yazılım geliştiren bir ekip için en doğal tür tek özellikli üründür. Diğerleri daha ucuzdur, ama talep doğrulandıktan sonra yerini gerçek bir ürüne bırakmak zorundadır.
MVP'nin kapsamı nasıl belirlenir?
Kapsamı özellik listesiyle değil, varsayımla belirlemek gerekir. Şu sıra işe yarar:
- En riskli varsayımı tek cümleyle yazın. Örneğin: “Muhasebe ofisleri, müşterilerinden belge toplamak için aylık bir ücret öder.”
- Başarı ölçüsünü önceden belirleyin: hangi sonuç varsayımın doğru, hangisi yanlış olduğunu gösterecek? Bu eşiği MVP'yi yayına almadan önce kâğıda dökün.
- Kullanıcının fikri denemek için atlayamayacağı adımları tek tek yazın. Geri kalan her şey sonraki sürüme kalır.
- Kestiğiniz özellikleri bir “şimdilik yok” listesinde toplayın. Ekip ve yatırımcı, neyin bilerek beklediğini bu listeden görür.
- Süreyi sabitleyin, kapsamı esnek tutun: takvim kayıyorsa tarih ertelenmez, özellik çıkarılır.
Kapsam için tek soru
Her özellik için “bu olmadan kullanıcı çekirdek işi yapabilir mi?” diye sorun. Cevap evetse o özellik ilk sürüme girmez.
Bu kesme işini müşterilerimizle bir kapsam atölyesinde yapıyoruz; MVP geliştirme sayfamızda kapsamı daraltmak için kullanılan küçük bir araç da var. Arayüz tarafında aynı kural geçerli: önce akış, sonra cila. Bu dengeyi UI/UX tasarım sayfamızda anlatıyoruz.
MVP'nin işe yarayıp yaramadığı nasıl anlaşılır?
Başarıyı ölçmek için çok sayıda grafik gerekmez; dört soru yeter. Her birinin cevabını MVP yayına girmeden önce bir eşik olarak yazın:
- Aktivasyon: kayıt olanların kaçı, ürünün vaat ettiği ilk sonuca ulaşıyor? Bir belge toplama aracında bu, ilk belgenin gerçekten toplanmasıdır.
- Geri dönüş: ilk haftadan sonra kaç kullanıcı ikinci ve üçüncü hafta da giriyor? Tek seferlik merak ile gerçek ihtiyaç burada ayrılır.
- Ödeme: deneme süresi biten kullanıcıların kaçı ödüyor, ödemeyenler bunun nedenini söylüyor mu?
- Tavsiye: kullanıcılar ürünü kendiliğinden başkalarına anlatıyor mu, size yeni birini yönlendiriyor mu?
Sayılar neyin olduğunu, görüşmeler ise nedenini anlatır. İlk haftalarda her hafta birkaç kullanıcıyla kısa bir görüşme yapmak, bir panodaki grafiğin açıklayamadığını gösterir: kullanıcının ürünü hangi işin yerine koyduğunu ve hangi adımda takıldığını.
MVP için bütçe nasıl planlanır?
MVP bütçesinin üç parçası vardır. İlki, kapsamın çıkarıldığı kısa bir keşif çalışmasıdır. İkincisi asıl geliştirmedir. Üçüncüsü en sık unutulan parçadır: yayından sonraki haftalarda gelen geri bildirime göre yapılacak düzeltmeler ve küçük eklemeler.
Bütçenin tamamını ilk sürüme harcamak, öğrendiklerinize göre hareket edecek para bırakmaz. Yayından sonrası için ayrılan pay, MVP'yi gerçek bir deneye dönüştüren şeydir. Fiyatı hangi etkenlerin belirlediğini özel yazılım ne kadar tutar yazımızda ayrıntılı anlattık.
MVP'de en sık yapılan hatalar neler?
- Çok büyük başlamak: “minimum” kısmı unutulur, ilk sürüm aylar süren bir projeye dönüşür.
- Cilaya zaman harcamak: kullanıcılar sade bir ekranı affeder, çekirdek iş çalışmadığında ise bırakıp gider.
- Ölçmeden yayınlamak: hangi sonucun başarı sayılacağı önceden yazılmazsa her sonuç başarı gibi okunur.
- Yanlış kişilerle test etmek: arkadaşlarınızın beğenisi talep değildir. Sorunu gerçekten yaşayan ve satın alma kararını veren kişilere ulaşın.
- Herkese hitap etmeye çalışmak: ilk sürüm tek bir müşteri tipinin tek bir sorununu çözer. İkinci bir kitle eklemek, iki ayrı ürünü yarım yapmak demektir.
- Yayından sonra susmak: MVP yayına girdiğinde iş bitmez, asıl iş başlar. İlk haftalarda kullanıcılarla konuşmak, sayıları okumak kadar önemlidir.
Yöntemin eleştirmenleri de var. Wikipedia'nın aktardığı bazı araştırmalara göre kolay taklit edilen bir ürünü çok erken göstermek rakiplere fikir verebilir, olumsuz ilk tepkiler de şirketin itibarını zedeleyebilir. Bu yüzden bazı ekipler “basit, sevilen, eksiksiz” bir ilk ürün gibi alternatif yaklaşımları tercih ediyor. Bizim pratik cevabımız şu: ilk sürüm küçük olabilir, ama yaptığı tek işi düzgün yapmalıdır.
MVP'den sonra ne olur?
Yayına çıkış, bir MVP'nin ortasıdır, sonu değil. İlk haftalarda üç sonuçtan biri ortaya çıkar: varsayım doğrulanır ve ürün büyütülür; kısmen doğrulanır ve yön değiştirilir; ya da yanlış çıkar ve fikir bırakılır. Üçü de büyük para harcamadan önce öğrenilmiş bir dersse MVP işini yapmıştır.
Bu kararı verirken iki tuzaktan kaçının: zayıf sonuçları “kullanıcılar henüz anlamadı” diyerek görmezden gelmek ve tek bir hevesli kullanıcının isteğini ürünün yönü sanmak. Yayından önce yazdığınız eşikler, tam bu anda sizi dürüst tutan şeydir.
Doğrulanan bir ürün çoğu zaman abonelikle satılan bir yazılıma dönüşür: hesaplar, paketler, faturalama ve birden fazla müşterinin verisini ayrı tutan bir yapı. Bu yolun devamını SaaS nedir yazımızda anlattık.
Yazan Hatice Kölmük
yop ortağı, Tallinn. Biz kimiz
Kaynaklar
Nerede yardımcı oluruz
Bu yazının arkasındaki hizmetler.
Projeniz
Bunu şirketiniz için birlikte yapalım mı?
Sitenizi ve neyi değiştirmek istediğinizi gönderin. İki iş günü içinde, ilk olarak ne yapacağımızı anlatan bir cevapla döneriz.
Sorular
Sık sorulanlar: MVP hakkında.
MVP ne demek, Türkçesi nedir?
MVP, “minimum viable product” sözünün baş harfleridir; Türkçede çoğunlukla “minimum uygulanabilir ürün” denir, bazen de “en küçük çalışır ürün”. Bir fikri gerçek kullanıcılarla sınamaya yetecek kadar özelliği olan ilk sürümü anlatır.
MVP geliştirmek ne kadar sürer?
Kapsamı doğru daraltılmış bir MVP genellikle birkaç haftalık geliştirme süresine sığar. Kesin süreyi çekirdek özellik ve gereken entegrasyonlar belirler; bunu da hazır bir şablon değil, kapsam atölyesi ortaya çıkarır.
MVP ile prototip aynı şey mi?
Hayır. Prototip, kullanıcının bir akışı anlayıp anlamadığını sınayan ve çoğu zaman gerçek veri kullanmayan bir modeldir. MVP ise gerçek kullanıcıların gerçek veriyle kullandığı ve mümkünse parasını ödediği ilk çalışan üründür.
MVP tutmazsa para boşa mı gider?
Hayır, MVP'nin amacı yanlış bir varsayımı ucuza öğrenmektir. Varsayım yanlış çıktıysa, aynı dersi tam bir ürün yaparak almaktan çok daha az harcamış olursunuz.
