MVP nedir? Uygulama fikrinizi büyük bütçe harcamadan test etmek

MVP nedir sorusunun kısa cevabı: kullanıcıya gerçek bir değer veren ve sizin en riskli varsayımınızı test eden, olabilecek en küçük ürün. İngilizce minimum viable product ifadesinin kısaltması; Türkçede minimum uygulanabilir ürün diye geçiyor. Buradaki kilit kelime "uygulanabilir". MVP yarım bir uygulama değil, küçük ama baştan sona çalışan bir uygulama.

MVP'yi sık karıştırılan iki şeyden ayırmak gerekiyor. Prototip tıklanabilir ekranlardan oluşur ve gerçek veriyle çalışmaz; fikri anlatmak için iyidir, ama kullanıcı davranışını ölçmez. Tam sürüm ise aklınızdaki her özelliği içerir ve aylar sürer. MVP ikisinin arasında durur: gerçek kullanıcılar gerçek bir işi yapar, siz de ne olduğunu ölçersiniz.

MVP planlamasında en zor kısım, ürünün kalbini oluşturan tek akışı bulmak. Ben bunun için müşterilerime tek bir cümle yazdırıyorum: "Kullanıcı bu uygulamayı açtığında, ... yapabilmeli." Boşluğa birden fazla şey yazılıyorsa henüz seçim yapılmamış demektir.

Örneğin bir saha ekibi uygulamasında çekirdek akış "sahadaki kişi yaptığı işi fotoğrafıyla birlikte kaydeder, ofis bunu anında görür" olabilir. Raporlar, prim hesabı, takvim entegrasyonu bu akış çalıştıktan sonra anlam kazanır. Geliştirdiğim Wingardium tarım uygulamasının öne çıkan özelliği gerçek zamanlı takip; bu tür bir üründe de ilk soru, kullanıcının takip ettiği bilgiyi en kısa yoldan görebilmesi oluyor.

• Kullanıcının bugün bu işi nasıl yaptığını yazın. Excel, WhatsApp grubu, kağıt defter ne kullanıyorsa.
• O mevcut yolun en çok vakit kaybettiren veya en çok hata çıkaran adımını bulun.
• MVP'nin tek görevi o adımı belirgin şekilde kolaylaştırmak olsun.
• Bu akış için gereken en az ekran sayısını çıkarın; genellikle 5 ile 10 arası yetiyor.

MVP'nin bütçesini belirleyen şey, içine koyduklarınızdan çok dışarıda bıraktıklarınız. İlk sürümde genellikle şunları erteliyoruz:

• Ayrıntılı yönetim paneli: başta veritabanı arayüzü veya basit bir tablo ekranı çoğu zaman yeter.
• Birden fazla giriş yöntemi: e-posta ile giriş yeterliyse Google, Apple ve telefonla girişi sonraya bırakın.
• Uygulama içi ödeme: ilk kullanıcılardan ödemeyi havale veya bağlantı ile almak, ödeme entegrasyonunu kanıtlanmış talebe göre yapmanızı sağlar.
• Çoklu dil, karanlık tema, ayrıntılı bildirim ayarları gibi kullanıcının ilk hafta fark etmeyeceği özellikler.
• Otomatik raporlar: ilk aylarda veriyi elle dışa aktarıp incelemek daha ucuz.

Dışarıda bırakmak güvenlikten ödün vermek anlamına gelmiyor. Giriş, veri yetkilendirmesi, gizlilik politikası ve mağaza kuralları MVP'de de eksiksiz olmalı. App Store ve Google Play, ilk sürüm olduğu için daha esnek davranmıyor.

Ölçmediğiniz bir MVP sadece küçük bir uygulamadır. Yayından önce hangi sonucun fikri doğrulayacağını, hangisinin çürüteceğini yazmanızı öneririm. İndirme sayısı tek başına iyi bir ölçü değil; insanlar merakla indirir ve bir daha açmaz.

• Aktivasyon: uygulamayı indirenlerin kaçı çekirdek akışı en az bir kez tamamladı?
• Geri dönüş: ilk hafta kullananların kaçı sonraki haftalarda da açıyor?
• Tamamlama süresi: çekirdek iş eski yönteme göre ne kadar kısa sürüyor?
• Nitel geri bildirim: ilk kullanıcılarla yapılan kısa görüşmelerde en çok tekrar eden şikayet ve istek.
• Ödeme isteği: ücretli bir model düşünüyorsanız, kaç kişi ödemeyi kabul ediyor?

Bu ölçümler için ağır bir analitik kurulumuna gerek yok. Birkaç temel olayın (kayıt, akışın başlaması, akışın bitmesi) kaydedilmesi ve haftalık olarak bakılması ilk aşamada yeterli. Analitik araç eklerseniz mağazadaki veri beyanlarına da eklemeyi unutmayın.

React Native ile iOS ve Android için 5 ile 10 ekranlık, basit bir backend'e sahip bir MVP'nin başlangıç aralığı 150.000 – 350.000 TL civarında. Hesaplar, ödeme, bildirim ve yönetim paneli gibi özellikler eklendikçe proje orta ölçekli bir uygulamaya dönüşüyor ve aralık 350.000 – 900.000 TL seviyesine çıkıyor. Bu fark, kapsamı neden dar tutmanız gerektiğini tek başına anlatıyor.

Süre de kapsama bağlı. Çekirdek akışı net, tasarımı sade bir MVP birkaç hafta ile üç ay arasında test edilebilir hale gelebiliyor. Bu süreye mağaza incelemesi ve ilk kullanıcılardan gelen düzeltmeler için birkaç hafta eklemek gerçekçi. Takvimi uzatan şey çoğu zaman kod değil, proje sırasında eklenen yeni özellik istekleri oluyor.

Adana'da çalışan bir işletme ya da başka bir şehirden bir girişimci olmanız süreci değiştirmiyor; uzaktan çalışıyorum ve her hafta çalışan bir sürüm gösteriyorum. Böylece kapsamın nereye gittiğini proje sonunda değil, her hafta görürsünüz.

1. 01

   Varsayımı yazın

   "Bu kişiler bu sorunu yaşıyor ve bu çözümü kullanırlar" cümlesini somut hale getirin. Kim, hangi sorun, hangi çözüm.

2. 02

   Çekirdek akışı ve ölçütü seçin

   Tek akış, onu ölçecek iki üç sayı ve başarı için bir eşik belirleyin.

3. 03

   Ekranları prototipleyin

   Kod yazmadan önce akışı birkaç potansiyel kullanıcıya gösterin. En ucuz düzeltme bu aşamada yapılır.

4. 04

   Geliştirin ve gerçek cihazda test edin

   Haftalık demolarla ilerleyin, test sürümünü TestFlight ve Google Play test kanalıyla dağıtın.

5. 05

   Yayınlayın ve ilk kullanıcıları getirin

   Kimin kullanacağını yayından önce bilin. İlk kullanıcıları reklamdan değil, sizi tanıyan çevreden getirmek geri bildirimi hızlandırır.

6. 06

   Ölçün ve karar verin

   Sonuçlara göre devam, değişiklik veya durma kararı verin. Durmak da başarılı bir MVP sonucudur; büyük bütçeyi yanlış fikre harcamamış olursunuz.

• Her şeyi ilk sürüme koymak: "Bu da olmazsa kullanmazlar" düşüncesiyle kapsam büyür, MVP tam sürüme dönüşür.
• Ölçüt belirlememek: yayından sonra sayılar iyi mi kötü mü, kimse karar veremez.
• Tasarımı ertelemek: sade olmak özensiz olmak demek değil. Kullanıcı karmaşık bir ekranda fikri değil arayüzü test eder.
• Teknik temeli atlamak: hızlı çıkmak için yazılan dağınık kod, MVP başarılı olduğunda baştan yazılmak zorunda kalır. React Native ile ortak bir kod tabanı ve düzgün bir backend yapısı bu riski azaltıyor.
• Mağaza sürecini son haftaya bırakmak: hesap doğrulaması, gizlilik politikası ve inceleme takvimi baştan planlanmazsa lansman kayar.