MVP neden küçük olmalı? Kapsamı daraltmanın disiplini
Her ürün fikri, ilk haftalarda büyüme eğilimindedir: bir özellik daha, bir ekran daha, bir entegrasyon daha. Oysa ilk sürümün tek görevi, ürünün en kritik varsayımını gerçek kullanıcıyla test etmektir. Bu yazıda Site Sakinim ve Bookra deneyimlerimizden süzdüğümüz kapsam daraltma pratiklerini paylaşıyoruz.
İlk sürümün tek görevi
MVP'nin amacı yatırımcıyı ya da paydaşı etkilemek değil, ürünün en riskli varsayımını en düşük maliyetle test etmektir. "Kullanıcı bu problemi bizim çözdüğümüz şekilde çözmek istiyor mu?" sorusuna cevap vermeyen her özellik, ilk sürümde fazlalıktır. Kapsam tartışmalarında kullandığımız ölçüt basit: bu özellik çıkarılırsa öğrenme hedefimiz zarar görür mü? Görmüyorsa sonraki sürüme kalır.
Tek çekirdek akış
Bookra'nın ilk sürümünde yalnızca tek bir akışa odaklandık: kullanıcının uygun saati bulup rezervasyon yapması. İptal politikaları, hatırlatma bildirimleri, raporlama ekranları — hepsi bilinçli olarak sonraya bırakıldı. Çekirdek akış gerçek kullanıcıyla doğrulanmadan çevresine özellik örmek, temeli test edilmemiş bir binaya kat çıkmaya benziyor.
Kapsam tartışmasında kaybedilen her hafta, gerçek kullanıcıdan öğrenilemeyen bir haftadır.
Küçük kapsam, tam kalite
Küçük kapsam, özensiz iş demek değildir. MVP'de daralttığımız şey özellik sayısıdır; güvenlik, veri bütünlüğü ve temel kullanıcı deneyimi standartlarımız ilk sürümde de aynıdır. Bu ayrım önemli, çünkü "nasıl olsa MVP" diye verilen kalite tavizleri, ürün tuttuğunda teknik borç olarak katlanarak geri döner.
Ölçmeden çıkmayın
Kapsamı daraltmak kadar önemlisi, öğrenme hedefini ölçülebilir kılmak: aktivasyon oranı, ilk hafta tekrar kullanımı, tamamlanan çekirdek akış sayısı. Bu metrikler olmadan MVP yalnızca küçük bir üründür; onu değerli kılan, cevapladığı sorudur. Kendi ürün geliştirme yaklaşımımızı ürünler sayfasında daha ayrıntılı anlatıyoruz.